ChangeLog-2017-03-23   [plain text]


2017-03-23  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] MachineThreads does not consider situation that one thread has multiple VMs
        https://bugs.webkit.org/show_bug.cgi?id=169819

        Reviewed by Mark Lam.

        The Linux port of PlatformThread suspend/resume mechanism relies on having a thread
        specific singleton thread data, and was relying on MachineThreads::Thread to be this
        thread specific singleton. But because MachineThreads::Thread is not a thread specific
        singleton, we can get a deadlock in the GTK port's DatabaseProcess.

        This patch fixes this issue by moving per thread data from MachineThreads::Thread to
        MachineThreads::ThreadData, where there will only be one instance of
        MachineThreads::ThreadData per thread. Each MachineThreads::Thread will now point to
        the same MachineThreads::ThreadData for any given thread.

        * heap/MachineStackMarker.cpp:
        (pthreadSignalHandlerSuspendResume):
        (JSC::threadData):
        (JSC::MachineThreads::Thread::Thread):
        (JSC::MachineThreads::Thread::createForCurrentThread):
        (JSC::MachineThreads::Thread::operator==):
        (JSC::MachineThreads::ThreadData::ThreadData):
        (JSC::MachineThreads::ThreadData::~ThreadData):
        (JSC::MachineThreads::ThreadData::suspend):
        (JSC::MachineThreads::ThreadData::resume):
        (JSC::MachineThreads::ThreadData::getRegisters):
        (JSC::MachineThreads::ThreadData::Registers::stackPointer):
        (JSC::MachineThreads::ThreadData::Registers::framePointer):
        (JSC::MachineThreads::ThreadData::Registers::instructionPointer):
        (JSC::MachineThreads::ThreadData::Registers::llintPC):
        (JSC::MachineThreads::ThreadData::freeRegisters):
        (JSC::MachineThreads::ThreadData::captureStack):
        (JSC::MachineThreads::tryCopyOtherThreadStacks):
        (JSC::MachineThreads::Thread::~Thread): Deleted.
        (JSC::MachineThreads::Thread::suspend): Deleted.
        (JSC::MachineThreads::Thread::resume): Deleted.
        (JSC::MachineThreads::Thread::getRegisters): Deleted.
        (JSC::MachineThreads::Thread::Registers::stackPointer): Deleted.
        (JSC::MachineThreads::Thread::Registers::framePointer): Deleted.
        (JSC::MachineThreads::Thread::Registers::instructionPointer): Deleted.
        (JSC::MachineThreads::Thread::Registers::llintPC): Deleted.
        (JSC::MachineThreads::Thread::freeRegisters): Deleted.
        (JSC::MachineThreads::Thread::captureStack): Deleted.
        * heap/MachineStackMarker.h:
        (JSC::MachineThreads::Thread::operator!=):
        (JSC::MachineThreads::Thread::suspend):
        (JSC::MachineThreads::Thread::resume):
        (JSC::MachineThreads::Thread::getRegisters):
        (JSC::MachineThreads::Thread::freeRegisters):
        (JSC::MachineThreads::Thread::captureStack):
        (JSC::MachineThreads::Thread::platformThread):
        (JSC::MachineThreads::Thread::stackBase):
        (JSC::MachineThreads::Thread::stackEnd):
        * runtime/SamplingProfiler.cpp:
        (JSC::FrameWalker::isValidFramePointer):
        * runtime/VMTraps.cpp:
        (JSC::findActiveVMAndStackBounds):

2017-03-23  Mark Lam  <mark.lam@apple.com>

        Clients of JSArray::tryCreateForInitializationPrivate() should do their own null checks.
        https://bugs.webkit.org/show_bug.cgi?id=169783

        Reviewed by Saam Barati.

        Fixed clients of tryCreateForInitializationPrivate() to do a null check and throw
        an OutOfMemoryError if allocation fails, or RELEASE_ASSERT that the allocation
        succeeds.

        * dfg/DFGOperations.cpp:
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationMaterializeObjectInOSR):
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncSplice):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/JSArray.cpp:
        (JSC::JSArray::tryCreateForInitializationPrivate):
        (JSC::JSArray::fastSlice):
        * runtime/JSArray.h:
        (JSC::constructArray):
        (JSC::constructArrayNegativeIndexed):
        * runtime/RegExpMatchesArray.cpp:
        (JSC::createEmptyRegExpMatchesArray):
        * runtime/RegExpMatchesArray.h:
        (JSC::createRegExpMatchesArray):

2017-03-23  Guillaume Emont  <guijemont@igalia.com>

        [jsc] Add MacroAssemblerMIPS::storeFence()
        https://bugs.webkit.org/show_bug.cgi?id=169705

        Reviewed by Yusuke Suzuki.

        There doesn't seem to be anything more fine grained than "sync" that
        guarantees that all memory operations following it are going to happen
        after all stores before it, so we just use sync.

        * assembler/MIPSAssembler.h:
        (JSC::MIPSAssembler::sync): Added a FIXME about SYNC_MB.
        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::storeFence): Added.

2017-03-22  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC][DFG] Propagate AnyIntAsDouble information carefully to utilize it in fixup
        https://bugs.webkit.org/show_bug.cgi?id=169914

        Reviewed by Saam Barati.

        In DFG prediction propagation phase, we pollute the prediction of GetByVal for Array::Double
        as SpecDoubleReal even if the heap prediction says the proper prediction is SpecAnyIntAsDouble.
        Thus, the following nodes just see the result of GetByVal(Array::Double) as double value,
        and select suboptimal edge filters in fixup phase. For example, if the result of GetByVal is
        SpecAnyIntAsDouble, we can see the node like ArithAdd(SpecAnyIntAsDouble, Int52) and we should
        have a chance to make it ArithAdd(Check:Int52, Int52) instead of ArithAdd(Double, Double).

        This patch propagates SpecAnyIntAsDouble in GetByVal(Array::Double) properly. And ValueAdd,
        ArithAdd and ArithSub select AnyInt edge filters for SpecAnyIntAsDouble values. It finally
        produces a Int52 specialized DFG node. And subsequent nodes using the produced one also
        become Int52 specialized.

        One considerable problem is that the heap prediction misses the non any int doubles. In that case,
        if Int52 edge filter is used, BadType exit will occur. It updates the prediction of the value profile
        of GetByVal. So, in the next time, GetByVal(Array::Double) produces more conservative predictions
        and avoids exit-and-recompile loop correctly.

        This change is very sensitive to the correct AI and appropriate predictions. Thus, this patch finds
        and fixes some related issues. One is incorrect prediction of ToThis and another is incorrect
        AI logic for Int52Rep.

        This change dramatically improves kraken benchmarks' crypto-pbkdf2 and crypto-sha256-iterative
        by 42.0% and 30.7%, respectively.

                                                     baseline                  patched
        Kraken:
        ai-astar                                  158.851+-4.132      ?     159.433+-5.176         ?
        audio-beat-detection                       53.193+-1.621      ?      53.391+-2.072         ?
        audio-dft                                 103.589+-2.277      ?     104.902+-1.924         ? might be 1.0127x slower
        audio-fft                                  40.491+-1.102             39.854+-0.755           might be 1.0160x faster
        audio-oscillator                           68.504+-1.721      ?      68.957+-1.725         ?
        imaging-darkroom                          118.367+-2.171      ?     119.581+-2.310         ? might be 1.0103x slower
        imaging-desaturate                         71.443+-1.461      ?      72.398+-1.918         ? might be 1.0134x slower
        imaging-gaussian-blur                     110.648+-4.035            109.184+-3.373           might be 1.0134x faster
        json-parse-financial                       60.363+-1.628      ?      61.936+-1.585         ? might be 1.0261x slower
        json-stringify-tinderbox                   37.903+-0.869      ?      39.559+-1.607         ? might be 1.0437x slower
        stanford-crypto-aes                        56.313+-1.512      ?      56.675+-1.715         ?
        stanford-crypto-ccm                        51.564+-1.900      ?      53.456+-2.548         ? might be 1.0367x slower
        stanford-crypto-pbkdf2                    129.546+-2.738      ^      91.214+-2.027         ^ definitely 1.4202x faster
        stanford-crypto-sha256-iterative           43.515+-0.730      ^      33.292+-0.653         ^ definitely 1.3071x faster

        <arithmetic>                               78.878+-0.528      ^      75.988+-0.621         ^ definitely 1.0380x faster

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::addShouldSpeculateAnyInt):
        * dfg/DFGPredictionPropagationPhase.cpp:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileArithNegate):

2017-03-22  Mark Lam  <mark.lam@apple.com>

        Add support for Error.stackTraceLimit.
        https://bugs.webkit.org/show_bug.cgi?id=169904

        Reviewed by Saam Barati.

        Since there's no standard for this yet, we'll implement Error.stackTraceLimit
        based on how Chrome does it.  This includes some idiosyncrasies like:
        1. If we set Error.stackTraceLimit = 0, then new Error().stack yields an empty
           stack trace (Chrome has a title with no stack frame entries).
        2. If we set Error.stackTraceLimit = {] (i.e. to a non-number value), then
           new Error().stack is undefined.

        Chrome and IE defaults their Error.stackTraceLimit to 10.  We'll default ours to
        100 because 10 may be a bit too skimpy and it is not that costly to allow up to
        100 frames instead of 10.

        The default value for Error.stackTraceLimit is specified by
        Options::defaultErrorStackTraceLimit().

        Also, the Exception object now limits the number of stack trace frames it captures
        to the limit specified by Options::exceptionStackTraceLimit().

        Note: the Exception object captures a stack trace that is not necessarily the
        same as the one in an Error object being thrown:

        - The Error object captures the stack trace at the point of object creation.

        - The Exception object captures the stack trace at the point that the exception
          is thrown.  This stack trace is captured even when throwing a value that is not
          an Error object e.g. a primitive value.  The Exception object stack trace is
          only used by WebInspector to identify where a value is thrown from.  Hence,
          it does not necessary make sense the Exception object stack trace limited by
          Error.stackTraceLimit.  Instead, we have it use own Options::exceptionStackTraceLimit().

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::unwind):
        * jsc.cpp:
        (dumpException):
        * runtime/CommonIdentifiers.h:
        * runtime/Error.cpp:
        (JSC::addErrorInfoAndGetBytecodeOffset):
        * runtime/ErrorConstructor.cpp:
        (JSC::ErrorConstructor::finishCreation):
        (JSC::ErrorConstructor::put):
        (JSC::ErrorConstructor::deleteProperty):
        * runtime/ErrorConstructor.h:
        (JSC::ErrorConstructor::stackTraceLimit):
        * runtime/Exception.cpp:
        (JSC::Exception::finishCreation):
        * runtime/Options.h:

2017-03-22  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Use jsNontrivialString for Number toString operations
        https://bugs.webkit.org/show_bug.cgi?id=169965

        Reviewed by Mark Lam.

        After single character check, produced string is always longer than 1.
        Thus, we can use jsNontrivialString.

        * runtime/NumberPrototype.cpp:
        (JSC::int32ToStringInternal):

2017-03-22  JF Bastien  <jfbastien@apple.com>

        WebAssembly: name ExecState consistently
        https://bugs.webkit.org/show_bug.cgi?id=169954

        Reviewed by Saam Barati.

        No functional change.

        * wasm/js/JSWebAssemblyCompileError.cpp:
        (JSC::JSWebAssemblyCompileError::create):
        (JSC::createJSWebAssemblyCompileError):
        * wasm/js/JSWebAssemblyCompileError.h:
        (JSC::JSWebAssemblyCompileError::create):
        * wasm/js/JSWebAssemblyLinkError.cpp:
        (JSC::JSWebAssemblyLinkError::create):
        (JSC::createJSWebAssemblyLinkError):
        * wasm/js/JSWebAssemblyLinkError.h:
        (JSC::JSWebAssemblyLinkError::create):
        * wasm/js/JSWebAssemblyRuntimeError.cpp:
        (JSC::JSWebAssemblyRuntimeError::create):
        * wasm/js/JSWebAssemblyRuntimeError.h:
        (JSC::JSWebAssemblyRuntimeError::create):
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::callJSWebAssemblyInstance):
        * wasm/js/WebAssemblyMemoryConstructor.cpp:
        (JSC::callJSWebAssemblyMemory):
        * wasm/js/WebAssemblyModuleConstructor.cpp:
        (JSC::callJSWebAssemblyModule):
        (JSC::WebAssemblyModuleConstructor::createModule):
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::link):
        (JSC::dataSegmentFail):
        (JSC::WebAssemblyModuleRecord::evaluate):
        * wasm/js/WebAssemblyPrototype.cpp:
        (JSC::webAssemblyFunctionValidate):
        (JSC::webAssemblyFunctionCompile):
        * wasm/js/WebAssemblyTableConstructor.cpp:
        (JSC::callJSWebAssemblyTable):

2017-03-22  JF Bastien  <jfbastien@apple.com>

        WebAssembly: constructors without new don't throw
        https://bugs.webkit.org/show_bug.cgi?id=165995

        Reviewed by Saam Barati.

        * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
        (JSC::constructJSWebAssemblyCompileError):
        (JSC::callJSWebAssemblyCompileError):
        * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
        (JSC::constructJSWebAssemblyLinkError):
        (JSC::callJSWebAssemblyLinkError):
        * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
        (JSC::constructJSWebAssemblyRuntimeError):
        (JSC::callJSWebAssemblyRuntimeError):

2017-03-22  Guillaume Emont  <guijemont@igalia.com>

        [DFG] Don't use ArraySlice intrinsic on MIPS
        https://bugs.webkit.org/show_bug.cgi?id=169721

        Reviewed by Yusuke Suzuki.

        Like on x86, we don't have enough registers available for this.

        * assembler/CPU.h:
        (JSC::isMIPS): Added.
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        Don't use the ArraySlice intrinsic on MIPS.

2017-03-21  Mark Lam  <mark.lam@apple.com>

        The DFG Integer Check Combining phase should force an OSR exit for CheckInBounds on a negative constant min bound.
        https://bugs.webkit.org/show_bug.cgi?id=169933
        <rdar://problem/31105125>

        Reviewed by Filip Pizlo and Geoffrey Garen.

        Also fixed the bit-rotted RangeKey::dump() function.

        * dfg/DFGIntegerCheckCombiningPhase.cpp:
        (JSC::DFG::IntegerCheckCombiningPhase::handleBlock):

2017-03-21  Csaba Osztrogonác  <ossy@webkit.org>

        [ARM] Add missing MacroAssembler functions after r214187
        https://bugs.webkit.org/show_bug.cgi?id=169912

        Reviewed by Yusuke Suzuki.

        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::loadFloat):
        (JSC::MacroAssemblerARM::storeFloat):

2017-03-21  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Optimize Number.prototype.toString on Int32 / Int52 / Double
        https://bugs.webkit.org/show_bug.cgi?id=167454

        Reviewed by Saam Barati.

        This patch improves Number.toString(radix) performance
        by introducing NumberToStringWithRadix DFG node. It directly
        calls the operation and it always returns String.

                                                       baseline                  patched

            stanford-crypto-sha256-iterative        45.130+-0.928             44.032+-1.184           might be 1.0250x faster

2017-03-21  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Add JSPromiseDeferred::reject(ExecState*, Exception*) interface
        https://bugs.webkit.org/show_bug.cgi?id=169908

        Reviewed by Sam Weinig.

        To avoid calling reject(ExecState*, JSValue) with Exception* accidentally,
        we add a new interface reject(ExecState*, Exception*).
        Such an interface is already added in DOMPromise in WebCore.

        * runtime/JSInternalPromiseDeferred.cpp:
        (JSC::JSInternalPromiseDeferred::reject):
        * runtime/JSInternalPromiseDeferred.h:
        * runtime/JSPromiseDeferred.cpp:
        (JSC::JSPromiseDeferred::reject):
        * runtime/JSPromiseDeferred.h:

2017-03-21  Zan Dobersek  <zdobersek@igalia.com>

        [jsc] MacroAssemblerMIPS: implement the branchPtr(RelationalCondition, BaseIndex, RegisterID) overload.
        https://bugs.webkit.org/show_bug.cgi?id=169717

        Reviewed by Yusuke Suzuki.

        * assembler/MacroAssembler.h: Expose branchPtr() on MIPS as well.
        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::branchPtr): Added.

        * 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::fixupToStringOrCallStringConstructor):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructor):
        (JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOnNumber):
        (JSC::DFG::SpeculativeJIT::compileNumberToStringWithRadix):
        (JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOnCell): Deleted.
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * 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):
        (JSC::FTL::DFG::LowerDFGToB3::compileToStringOrCallStringConstructor):
        (JSC::FTL::DFG::LowerDFGToB3::compileNumberToStringWithRadix):
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgumentsWithExecState):
        * jit/JITOperations.h:
        * runtime/Intrinsic.h:
        * runtime/NumberPrototype.cpp:
        (JSC::int52ToStringWithRadix):
        (JSC::int32ToStringInternal):
        (JSC::numberToStringInternal):
        (JSC::int32ToString):
        (JSC::int52ToString):
        (JSC::numberToString):
        (JSC::numberProtoFuncToString):
        (JSC::integerValueToString): Deleted.
        * runtime/NumberPrototype.h:
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):

2017-03-20  Filip Pizlo  <fpizlo@apple.com>

        Graph coloring should use coalescable moves when spilling
        https://bugs.webkit.org/show_bug.cgi?id=169820

        Reviewed by Michael Saboff.
        
        This makes our graph coloring register allocator use a new family of move instructions when
        spilling both operands of the move. It's a three-operand move:
        
            Move (src), (dst), %scratch
        
        Previously, if both operands got spilled, we would emit a new instruction to load or store that
        spill slot. But this made it hard for allocateStack to see that the two spill locations are
        coalescable. This new kind of instruction makes it obvious that it's a coalescable move.
        
        This change implements the coalescing of spill slots inside allocateStack.
        
        This is an outrageous speed-up on the tsf_ir_speed benchmark from http://filpizlo.com/tsf/. This
        is an interesting benchmark because it has a super ugly interpreter loop with ~20 live variables
        carried around the loop back edge. This change makes that interpreter run 5x faster.
        
        This isn't a speed-up on any other benchmarks. It also doesn't regress anything. Compile time is
        neither progressed or regressed, since the coalescing is super cheap, and this does not add any
        significant new machinery to the register allocator (it's just a small change to spill codegen).
        Overall on our wasm benchmarks, this is a 16% throughput progression.
        
        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::move):
        (JSC::MacroAssembler::move32):
        (JSC::MacroAssembler::moveFloat):
        (JSC::MacroAssembler::moveDouble):
        * b3/air/AirAllocateRegistersByGraphColoring.cpp:
        (JSC::B3::Air::allocateRegistersByGraphColoring):
        * b3/air/AirAllocateStack.cpp:
        (JSC::B3::Air::allocateStack):
        * b3/air/AirInst.cpp:
        (JSC::B3::Air::Inst::hasEarlyDef):
        (JSC::B3::Air::Inst::hasLateUseOrDef):
        (JSC::B3::Air::Inst::needsPadding):
        * b3/air/AirInst.h:
        * b3/air/AirOpcode.opcodes:
        * b3/air/AirPadInterference.cpp:
        (JSC::B3::Air::padInterference):
        * runtime/Options.h:

2017-03-19  Chris Dumez  <cdumez@apple.com>

        `const location = "foo"` throws in a worker
        https://bugs.webkit.org/show_bug.cgi?id=169839

        Reviewed by Mark Lam.

        Our HasRestrictedGlobalProperty check in JSC was slightly wrong, causing us
        to sometimes throw a Syntax exception when we shouldn't when declaring a
        const/let variable and sometimes not throw an exception when we should have.

        This aligns our behavior with ES6, Firefox and Chrome.

        * runtime/ProgramExecutable.cpp:
        (JSC::hasRestrictedGlobalProperty):
        (JSC::ProgramExecutable::initializeGlobalProperties):
        Rewrite hasRestrictedGlobalProperty logic as per the EcmaScript spec:
        - http://www.ecma-international.org/ecma-262/6.0/index.html#sec-hasproperty
        In particular, they were 2 issues:
        - We should throw a SyntaxError if hasProperty() returned true but getOwnProperty()
          would fail to return a descriptor. This would happen for properties that are
          not OWN properties, but defined somewhere in the prototype chain. The spec does
          not say to use hasProperty(), only getOwnProperty() and says we should return
          false if getOwnProperty() does not return a descriptor. This is what we do now.
        - We would fail to throw when declaring a let/const variable that shadows an own
          property whose value is undefined. This is because the previous code was
          explicitly checking for this case. I believe this was a misinterpretation of
          ES6 which says:
          """
          Let desc be O.[[GetOwnProperty]](P).
          If desc is undefined, return false.
          """
          We should check that desc is undefined, not desc.value. This is now fixed.

2017-03-19  Yusuke Suzuki  <utatane.tea@gmail.com>

        import(arg) crashes when ToString(arg) throws
        https://bugs.webkit.org/show_bug.cgi?id=169778

        Reviewed by Saam Barati.

        JSPromiseDeferred should not be rejected with Exception*.

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

2017-03-18  Oleksandr Skachkov  <gskachkov@gmail.com>

        [JSC] Remove unnecessary condition from needsDerivedConstructorInArrowFunctionLexicalEnvironment in BytecodeGenerator.cpp 
        https://bugs.webkit.org/show_bug.cgi?id=169832

        Reviewed by Mark Lam.

        Remove already covered condition in needsDerivedConstructorInArrowFunctionLexicalEnvironment 
        function. Condition isConstructor() && constructorKind() == ConstructorKind::Extends is already
        isClassContext.

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

2017-03-18  Chris Dumez  <cdumez@apple.com>

        Allow setting the prototype of cross-origin objects, as long as they don't change
        https://bugs.webkit.org/show_bug.cgi?id=169787

        Reviewed by Mark Lam.

        * runtime/JSGlobalObject.h:
        Mark JS global object as an immutable prototype exotic object to match Window.

        * runtime/JSObject.cpp:
        (JSC::JSObject::setPrototypeWithCycleCheck):
        Update setPrototypeWithCycleCheck() for immutable prototype exotic objects in order
        to align with:
        - https://tc39.github.io/ecma262/#sec-set-immutable-prototype

        In particular, we need to call [[GetPrototypeOf]] and return true if it returns the same
        value as the new prototype. We really need to call [[GetPrototypeOf]] and not merely
        getting the prototype slot via getPrototypeDirect() since Location and Window override
        [[GetPrototypeOf]] to return null in the cross-origin case.

        * runtime/JSProxy.cpp:
        (JSC::JSProxy::setPrototype):
        Update JSProxy::setPrototype() to forward such calls to its target. This is needed so
        we end up calling JSObject::setPrototypeWithCycleCheck() for the Window object.
        Handling immutable prototype exotic objects in that method does the right thing for
        Window.

2017-03-17  Michael Saboff  <msaboff@apple.com>

        Use USE_INTERNAL_SDK to compute ENABLE_FAST_JIT_PERMISSIONS instead of HAVE_INTERNAL_SDK
        https://bugs.webkit.org/show_bug.cgi?id=169817

        Reviewed by Filip Pizlo.

        * Configurations/FeatureDefines.xcconfig:

2017-03-11  Filip Pizlo  <fpizlo@apple.com>

        Air should be powerful enough to support Tmp-splitting
        https://bugs.webkit.org/show_bug.cgi?id=169515

        Reviewed by Saam Barati.
        
        In the process of implementing the Tmp-splitting optimization, I made some small
        clean-ups. They don't affect anything - it's basically moving code around and adding
        utility functions.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/LinkBuffer.cpp:
        (JSC::LinkBuffer::allocate): testb3 was sometimes failing its checkDoesNotUseInstruction check because of uninitialized memory. This initializes the internal fragmentation slop of every JIT allocation.
        * b3/air/AirAllocateRegistersByGraphColoring.cpp:
        * b3/air/AirAllocateRegistersByGraphColoring.h:
        (JSC::B3::Air::useIRC): It's useful to be able to query which register allocator we're using.
        * b3/air/AirArg.cpp:
        (WTF::printInternal):
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::temperature): The temperature of a role is a useful concept to have factored out.
        * b3/air/AirBreakCriticalEdges.cpp: Added.
        (JSC::B3::Air::breakCriticalEdges): I was surprised that we didn't have this already. It's a pretty fundamental CFG utility.
        * b3/air/AirBreakCriticalEdges.h: Added.
        * b3/air/AirGenerate.cpp:
        * b3/air/AirInsertionSet.h: You can't use & if you want copy-constructibility, which seems to be a prerequisite to IndexMap<BasicBlock, InsertionSet>.
        (JSC::B3::Air::InsertionSet::InsertionSet):
        (JSC::B3::Air::InsertionSet::code):
        * b3/air/AirLiveness.h: Teach Liveness to track only warm liveness.
        (JSC::B3::Air::TmpLivenessAdapter::acceptsRole):
        (JSC::B3::Air::StackSlotLivenessAdapter::acceptsRole):
        (JSC::B3::Air::RegLivenessAdapter::acceptsRole):
        (JSC::B3::Air::AbstractLiveness::AbstractLiveness):
        (JSC::B3::Air::AbstractLiveness::LocalCalc::execute):

2017-03-16  Mark Lam  <mark.lam@apple.com>

        Fix exception scope verification failures in GenericArgumentsInlines.h.
        https://bugs.webkit.org/show_bug.cgi?id=165012

        Reviewed by Saam Barati.

        * runtime/GenericArgumentsInlines.h:
        (JSC::GenericArguments<Type>::defineOwnProperty):

2017-03-16  Simon Fraser  <simon.fraser@apple.com>

        Improve the system tracing points
        https://bugs.webkit.org/show_bug.cgi?id=169790

        Reviewed by Zalan Bujtas.

        Use a more cohesive set of system trace points that give a good overview of what
        WebKit is doing. Added points for resource loading, render tree building, sync messages
        to the web process, async image decode, WASM and fetching cookies.

        * wasm/WasmPlan.cpp:
        (JSC::Wasm::Plan::run):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction):

2017-03-16  Mark Lam  <mark.lam@apple.com>

        Array concat operation should check for length overflows.
        https://bugs.webkit.org/show_bug.cgi?id=169796
        <rdar://problem/31095276>

        Reviewed by Keith Miller.

        * runtime/ArrayPrototype.cpp:
        (JSC::concatAppendOne):
        (JSC::arrayProtoPrivateFuncConcatMemcpy):

2017-03-16  Mark Lam  <mark.lam@apple.com>

        The new array with spread operation needs to check for length overflows.
        https://bugs.webkit.org/show_bug.cgi?id=169780
        <rdar://problem/31072182>

        Reviewed by Filip Pizlo.

        * dfg/DFGOperations.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNewArrayWithSpread):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread):
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationMaterializeObjectInOSR):
        * llint/LLIntSlowPaths.cpp:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/JSGlobalObject.cpp:

2017-03-16  Filip Pizlo  <fpizlo@apple.com>

        FTL should support global and eval code
        https://bugs.webkit.org/show_bug.cgi?id=169656

        Reviewed by Geoffrey Garen and Saam Barati.
        
        Turned off the restriction against global and eval code running in the FTL, and then fixed all of
        the things that didn't work.
        
        This is a big speed-up on microbenchmarks that I wrote for this patch. One of the reasons why we
        hadn't done this earlier is that we've never seen a benchmark that needed it. Global and eval
        code rarely gets FTL-hot. Still, this seems like possibly a small JetStream speed-up.

        * dfg/DFGJITCode.cpp:
        (JSC::DFG::JITCode::setOSREntryBlock): I outlined this for better debugging.
        * dfg/DFGJITCode.h:
        (JSC::DFG::JITCode::setOSREntryBlock): Deleted.
        * dfg/DFGNode.h:
        (JSC::DFG::Node::isSemanticallySkippable): It turns out that global code often has InvalidationPoints before LoopHints. They are also skippable from the standpoint of OSR entrypoint analysis.
        * dfg/DFGOperations.cpp: Don't do any normal compiles of global code - just do OSR compiles.
        * ftl/FTLCapabilities.cpp: Enable FTL for global and eval code.
        (JSC::FTL::canCompile):
        * ftl/FTLCompile.cpp: Just debugging clean-ups.
        (JSC::FTL::compile):
        * ftl/FTLJITFinalizer.cpp: Implement finalize() and ensure that we only do things with the entrypoint buffer if we have one. We won't have one for eval code that we aren't OSR entering into.
        (JSC::FTL::JITFinalizer::finalize):
        (JSC::FTL::JITFinalizer::finalizeFunction):
        (JSC::FTL::JITFinalizer::finalizeCommon):
        * ftl/FTLJITFinalizer.h:
        * ftl/FTLLink.cpp: When entering a function normally, we need the "entrypoint" to put the arity check code. Global and eval code don't need this.
        (JSC::FTL::link):
        * ftl/FTLOSREntry.cpp: Fix a dataLog statement.
        (JSC::FTL::prepareOSREntry):
        * ftl/FTLOSRExitCompiler.cpp: Remove dead code that happened to assert that we're exiting from a function.
        (JSC::FTL::compileStub):

2017-03-16  Michael Saboff  <msaboff@apple.com>

        WebAssembly: function-tests/load-offset.js fails on ARM64
        https://bugs.webkit.org/show_bug.cgi?id=169724

        Reviewed by Keith Miller.

        We need to use the two source version of Add64 to create a Wasm address with the
        other source the first child.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):

2017-03-16  Jon Lee  <jonlee@apple.com>

        Add FIXMEs to update WebRTC
        https://bugs.webkit.org/show_bug.cgi?id=169735

        Reviewed by Youenn Fablet.

        * runtime/CommonIdentifiers.h: Add RTCIceTransport.

2017-03-16  Yusuke Suzuki  <utatane.tea@gmail.com>

        Unreviewed, copy m_numberOfArgumentsToSkip
        https://bugs.webkit.org/show_bug.cgi?id=164582

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

2017-03-16  Yusuke Suzuki  <utatane.tea@gmail.com>

        Unreviewed, fix numParameter() - 1 OSRExit materialization
        https://bugs.webkit.org/show_bug.cgi?id=164582

        When materializing rest parameters, we rely on that numParameter() - 1 equals to
        the numberOfArgumentsToSkip. But this assumption is broken in r214029.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::numberOfArgumentsToSkip):
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationMaterializeObjectInOSR):

2017-03-16  Caio Lima  <ticaiolima@gmail.com>

        [ESnext] Implement Object Spread
        https://bugs.webkit.org/show_bug.cgi?id=167963

        Reviewed by Yusuke Suzuki.

        This patch implements ECMA262 stage 3 Object Spread proposal [1].
        It's implemented using CopyDataProperties to copy all enumerable keys
        from object being spreaded.

        It's also fixing CopyDataProperties that was using
        Object.getOwnPropertyNames to list all keys to be copied, and now is
        using Relect.ownKeys.

        [1] - https://github.com/sebmarkbage/ecmascript-rest-spread

        * builtins/GlobalOperations.js:
        (globalPrivate.copyDataProperties):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::setConstantIdentifierSetRegisters):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::addSetConstant):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitLoad):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::PropertyListNode::emitBytecode):
        (JSC::ObjectPatternNode::bindValue):
        (JSC::ObjectSpreadExpressionNode::emitBytecode):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createObjectSpreadExpression):
        (JSC::ASTBuilder::createProperty):
        * parser/NodeConstructors.h:
        (JSC::PropertyNode::PropertyNode):
        (JSC::ObjectSpreadExpressionNode::ObjectSpreadExpressionNode):
        * parser/Nodes.h:
        (JSC::ObjectSpreadExpressionNode::expression):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseProperty):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createObjectSpreadExpression):
        (JSC::SyntaxChecker::createProperty):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::privateToObject): Deleted.
        * runtime/JSGlobalObjectFunctions.h:

2017-03-15  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Default parameter part should be retrieved by op_get_argument opcode instead of changing arity
        https://bugs.webkit.org/show_bug.cgi?id=164582

        Reviewed by Saam Barati.

        Previously we implement the default parameters as follows.

            1. We count the default parameters as the usual parameters.
            2. We just get the argument register.
            3. Check it with op_is_undefined.
            4. And fill the binding with either the argument register or default value.

        The above is simple. However, it has the side effect that it always increase the arity of the function.
        While `function.length` does not increase, internally, the number of parameters of CodeBlock increases.
        This effectively prevent our DFG / FTL to perform inlining: currently we only allows DFG to inline
        the function with the arity less than or equal the number of passing arguments. It is OK. But when using
        default parameters, we frequently do not pass the argument for the parameter with the default value.
        Thus, in our current implementation, we frequently need to fixup the arity. And we frequently fail
        to inline the function.

        This patch fixes the above problem by not increasing the arity of the function. When we encounter the
        parameter with the default value, we use `op_argument` to get the argument instead of using the argument
        registers.

        This improves six-speed defaults.es6 performance by 4.45x.

            defaults.es6        968.4126+-101.2350   ^    217.6602+-14.8831       ^ definitely 4.4492x faster

        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
        (JSC::BytecodeGenerator::initializeNextParameter):
        (JSC::BytecodeGenerator::initializeParameters):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::FunctionNode::emitBytecode):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::inliningCost):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createFunctionMetadata):
        * parser/Nodes.cpp:
        (JSC::FunctionMetadataNode::FunctionMetadataNode):
        * parser/Nodes.h:
        (JSC::FunctionParameters::size):
        (JSC::FunctionParameters::at):
        (JSC::FunctionParameters::append):
        (JSC::FunctionParameters::isSimpleParameterList):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::isArrowFunctionParameters):
        (JSC::Parser<LexerType>::parseGeneratorFunctionSourceElements):
        (JSC::Parser<LexerType>::parseAsyncFunctionSourceElements):
        (JSC::Parser<LexerType>::parseFormalParameters):
        (JSC::Parser<LexerType>::parseFunctionBody):
        (JSC::Parser<LexerType>::parseFunctionParameters):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        * parser/Parser.h:
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createFunctionMetadata):
        * runtime/FunctionExecutable.h:
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::createBuiltinFunction):
        (JSC::JSFunction::reifyLength):

2017-03-15  Yusuke Suzuki  <utatane.tea@gmail.com>

        [DFG] ToString operation should have fixup for primitives to say this node does not have side effects
        https://bugs.webkit.org/show_bug.cgi?id=169544

        Reviewed by Saam Barati.

        Our DFG ToString only considers well about String operands. While ToString(non cell operand) does not have
        any side effect, it is not modeled well in DFG.

        This patch introduces a fixup for ToString with NonCellUse edge. If this edge is set, ToString does not
        clobber things (like ToLowerCase, producing String). And ToString(NonCellUse) allows us to perform CSE!

        Our microbenchmark shows 32.9% improvement due to dropped GetButterfly and CSE for ToString().

                                            baseline                  patched

            template-string-array       12.6284+-0.2766     ^      9.4998+-0.2295        ^ definitely 1.3293x faster

        And SixSpeed template_string.es6 shows 16.68x performance improvement due to LICM onto this non-side-effectful ToString().

                                          baseline                  patched

            template_string.es6     3229.7343+-40.5705    ^    193.6077+-36.3349       ^ definitely 16.6818x faster

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupToStringOrCallStringConstructor):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOnCell):
        (JSC::DFG::SpeculativeJIT::speculateNotCell):
        * 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::compileToStringOrCallStringConstructor):
        (JSC::FTL::DFG::LowerDFGToB3::lowNotCell):
        (JSC::FTL::DFG::LowerDFGToB3::speculateNotCell):

2017-03-15  Ryan Haddad  <ryanhaddad@apple.com>

        Revert part of r213978 to see if it resolves LayoutTest crashes.
        https://bugs.webkit.org/show_bug.cgi?id=169729

        Reviewed by Alexey Proskuryakov.

        * JavaScriptCore.xcodeproj/project.pbxproj:

2017-03-15  Guillaume Emont  <guijemont@igalia.com>

        [jsc][mips] Fix compilation error introduced in r213652
        https://bugs.webkit.org/show_bug.cgi?id=169723

        Reviewed by Mark Lam.

        The new replaceWithBkpt() contains a lapsus in it
        (s/code/instructionStart) and won't compile.

        * assembler/MIPSAssembler.h:
        (JSC::MIPSAssembler::replaceWithBkpt):

2017-03-15  Daniel Ehrenberg  <littledan@chromium.org>

        Switch back to ISO 4217 for Intl CurrencyDigits data
        https://bugs.webkit.org/show_bug.cgi?id=169182
    
        Previously, a patch switched Intl.NumberFormat to use CLDR data through
        ICU to get the default number of decimal digits for a currency.
        However, that change actually violated the ECMA 402 specification,
        which references ISO 4217 as the data source. This patch reverts to
        an in-line implementation of that data.

        Reviewed by Saam Barati.

        * runtime/IntlNumberFormat.cpp:
        (JSC::computeCurrencySortKey):
        (JSC::extractCurrencySortKey):
        (JSC::computeCurrencyDigits):

2017-03-15  Saam Barati  <sbarati@apple.com>

        WebAssembly: When we GC to try to get a fast memory, we should call collectAllGarbage(), not collectSync()
        https://bugs.webkit.org/show_bug.cgi?id=169704

        Reviewed by Mark Lam.

        We weren't always sweeping the memory needed to free
        the WasmMemory we wanted to use. collectAllGarbage()
        will do this if the JS objects wrapping WasmMemory
        are dead.

        This patch also moves the increment of the allocatedFastMemories
        integer to be thread safe.

        * wasm/WasmMemory.cpp:
        (JSC::Wasm::tryGetFastMemory):

2017-03-15  Mark Lam  <mark.lam@apple.com>

        Fix exception scope verification failures in jsc.cpp.
        https://bugs.webkit.org/show_bug.cgi?id=164968

        Reviewed by Saam Barati.

        * jsc.cpp:
        (WTF::CustomGetter::customGetter):

        (GlobalObject::moduleLoaderResolve):
        (GlobalObject::moduleLoaderFetch):
        - The only way modules would throw an exception is if we encounter an OutOfMemory
          error.  This should be extremely rare.  At this point, I don't think it's worth
          doing the dance to propagate the exception when this happens.  Instead, we'll
          simply do a RELEASE_ASSERT that we don't see any exceptions here.

        (functionRun):
        (functionRunString):
        (functionLoadModule):
        (functionCheckModuleSyntax):
        (box):
        (dumpException):
        (runWithScripts):

2017-03-15  Mark Lam  <mark.lam@apple.com>

        Fix missing exception checks in Interpreter.cpp.
        https://bugs.webkit.org/show_bug.cgi?id=164964

        Reviewed by Saam Barati.

        * interpreter/Interpreter.cpp:
        (JSC::eval):
        (JSC::sizeOfVarargs):
        (JSC::sizeFrameForVarargs):
        (JSC::Interpreter::executeProgram):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        (JSC::Interpreter::prepareForRepeatCall):
        (JSC::Interpreter::execute):

2017-03-15  Dean Jackson  <dino@apple.com>

        Sort Xcode project files
        https://bugs.webkit.org/show_bug.cgi?id=169669

        Reviewed by Antoine Quint.

        * JavaScriptCore.xcodeproj/project.pbxproj:

2017-03-14  Tomas Popela  <tpopela@redhat.com>

        Wrong condition in offlineasm/risc.rb
        https://bugs.webkit.org/show_bug.cgi?id=169597

        Reviewed by Mark Lam.

        It's missing the 'and' operator between the conditions.

        * offlineasm/risc.rb:

2017-03-14  Mark Lam  <mark.lam@apple.com>

        BytecodeGenerator should use the same function to determine if it needs to store the DerivedConstructor in an ArrowFunction lexical environment.
        https://bugs.webkit.org/show_bug.cgi?id=169647
        <rdar://problem/31051832>

        Reviewed by Michael Saboff.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::usesDerivedConstructorInArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
        (JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope):
        * bytecompiler/BytecodeGenerator.h:

2017-03-14  Brian Burg  <bburg@apple.com>

        [Cocoa] Web Inspector: generated code for parsing an array of primitive-type enums from payload does not work
        https://bugs.webkit.org/show_bug.cgi?id=169629

        Reviewed by Joseph Pecoraro.

        This was encountered while trying to compile new protocol definitions that support the Actions API.

        * inspector/scripts/codegen/models.py:
        (EnumType.__repr__): Improve debug logging so fields match the class member names.

        * inspector/scripts/codegen/objc_generator.py:
        (ObjCGenerator.payload_to_objc_expression_for_member):
        If the array elements are actually a primitive type, then there's no need to do any
        conversion from a payload. This happens for free since the payload is a tree of
        NSDictionary, NSString, NSNumber, etc. 

        * inspector/scripts/tests/generic/expected/shadowed-optional-type-setters.json-result:
        * inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result:
        Rebaseline.

        * inspector/scripts/tests/generic/type-declaration-object-type.json:
        Add new cases for properties that contain an array with enum type references and an array of anonymous enums.

2017-03-14  Filip Pizlo  <fpizlo@apple.com>

        Record the HashSet/HashMap operations in DFG/FTL/B3 and replay them in a benchmark
        https://bugs.webkit.org/show_bug.cgi?id=169590

        Reviewed by Saam Barati.
        
        Adds code to support logging some hashtable stuff in the DFG.

        * dfg/DFGAvailabilityMap.cpp:
        (JSC::DFG::AvailabilityMap::pruneHeap):
        * dfg/DFGCombinedLiveness.cpp:
        (JSC::DFG::liveNodesAtHead):
        (JSC::DFG::CombinedLiveness::CombinedLiveness):
        * dfg/DFGCombinedLiveness.h:
        * dfg/DFGLivenessAnalysisPhase.cpp:
        (JSC::DFG::LivenessAnalysisPhase::run):
        (JSC::DFG::LivenessAnalysisPhase::processBlock):
        * dfg/DFGNode.cpp:
        * dfg/DFGNode.h:
        * dfg/DFGObjectAllocationSinkingPhase.cpp:

2017-03-14  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Remove unused Network protocol event
        https://bugs.webkit.org/show_bug.cgi?id=169619

        Reviewed by Mark Lam.

        * inspector/protocol/Network.json:
        This became unused in r213621 and should have been removed
        from the protocol file then.

2017-03-14  Mark Lam  <mark.lam@apple.com>

        Add a null check in VMTraps::willDestroyVM() to handle a race condition.
        https://bugs.webkit.org/show_bug.cgi?id=169620

        Reviewed by Filip Pizlo.

        There exists a race between VMTraps::willDestroyVM() (which removed SignalSenders
        from its m_signalSenders list) and SignalSender::send() (which removes itself
        from the list).  In the event that SignalSender::send() removes itself between
        the time that VMTraps::willDestroyVM() checks if m_signalSenders is empty and the
        time it takes a sender from m_signalSenders, VMTraps::willDestroyVM() may end up
        with a NULL sender pointer.  The fix is to add the missing null check before using
        the sender pointer.

        * runtime/VMTraps.cpp:
        (JSC::VMTraps::willDestroyVM):
        (JSC::VMTraps::fireTrap):
        * runtime/VMTraps.h:

2017-03-14  Mark Lam  <mark.lam@apple.com>

        Gardening: Speculative build fix for CLoop after r213886.
        https://bugs.webkit.org/show_bug.cgi?id=169436

        Not reviewed.

        * runtime/MachineContext.h:

2017-03-14  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Drop unnecessary pthread_attr_t for JIT enabled Linux / FreeBSD environment
        https://bugs.webkit.org/show_bug.cgi?id=169592

        Reviewed by Carlos Garcia Campos.

        Since suspended mcontext_t has all the necessary information, we can drop
        pthread_attr_t allocation and destroy for JIT enabled Linux / FreeBSD environment.

        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::Thread::getRegisters):
        (JSC::MachineThreads::Thread::Registers::stackPointer):
        (JSC::MachineThreads::Thread::Registers::framePointer):
        (JSC::MachineThreads::Thread::Registers::instructionPointer):
        (JSC::MachineThreads::Thread::Registers::llintPC):
        (JSC::MachineThreads::Thread::freeRegisters):
        * heap/MachineStackMarker.h:

2017-03-14  Zan Dobersek  <zdobersek@igalia.com>

        [GLib] Use USE(GLIB) guards in JavaScriptCore/inspector/EventLoop.cpp
        https://bugs.webkit.org/show_bug.cgi?id=169594

        Reviewed by Carlos Garcia Campos.

        Instead of PLATFORM(GTK) guards, utilize the USE(GLIB) build guards
        to guard the GLib-specific includes and invocations in the JSC
        inspector's EventLoop class implementation.

        * inspector/EventLoop.cpp:
        (Inspector::EventLoop::cycle):

2017-03-13  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC][Linux] Implement VMTrap in Linux ports
        https://bugs.webkit.org/show_bug.cgi?id=169436

        Reviewed by Mark Lam.

        This patch port VMTrap to Linux ports.
        We extract MachineContext accessors from various places (wasm/, heap/ and tools/)
        and use them in all the JSC code.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::Thread::Registers::stackPointer):
        (JSC::MachineThreads::Thread::Registers::framePointer):
        (JSC::MachineThreads::Thread::Registers::instructionPointer):
        (JSC::MachineThreads::Thread::Registers::llintPC):
        * heap/MachineStackMarker.h:
        * runtime/MachineContext.h: Added.
        (JSC::MachineContext::stackPointer):
        (JSC::MachineContext::framePointer):
        (JSC::MachineContext::instructionPointer):
        (JSC::MachineContext::argumentPointer<1>):
        (JSC::MachineContext::argumentPointer):
        (JSC::MachineContext::llintInstructionPointer):
        * runtime/PlatformThread.h:
        (JSC::platformThreadSignal):
        * runtime/VMTraps.cpp:
        (JSC::SignalContext::SignalContext):
        (JSC::SignalContext::adjustPCToPointToTrappingInstruction):
        * tools/CodeProfiling.cpp:
        (JSC::profilingTimer):
        * tools/SigillCrashAnalyzer.cpp:
        (JSC::SignalContext::SignalContext):
        (JSC::SignalContext::dump):
        * tools/VMInspector.cpp:
        * wasm/WasmFaultSignalHandler.cpp:
        (JSC::Wasm::trapHandler):

2017-03-13  Mark Lam  <mark.lam@apple.com>

        Make the HeapVerifier useful again.
        https://bugs.webkit.org/show_bug.cgi?id=161752

        Reviewed by Filip Pizlo.

        Resurrect the HeapVerifier.  Here's what the verifier now offers:

        1. It captures the list of cells before and after GCs up to N GC cycles.
           N is set by JSC_numberOfGCCyclesToRecordForVerification.
           Currently, N defaults to 3.

           This is useful if we're debugging in lldb and want to check if a candidate
           cell pointer was observed by the GC during the last N GC cycles.  We can do
           this check buy calling HeapVerifier::checkIfRecorded() with the cell address.

           HeapVerifier::checkIfRecorded() is robust and can be used on bogus addresses.
           If the candidate cell was previously recorded by the HeapVerifier during a
           GC cycle, checkIfRecorded() will dump any useful info it has on that cell.

        2. The HeapVerifier will verify that cells in its captured list after a GC are
           sane.  Some examples of cell insanity are:
           - the cell claims to belong to a different VM.
           - the cell has a NULL structureID.
           - the cell has a NULL structure.
           - the cell's structure has a NULL structureID.
           - the cell's structure has a NULL structure.
           - the cell's structure's structure has a NULL structureID.
           - the cell's structure's structure has a NULL structure.

           These are all signs of corruption or a GC bug.  The verifier will report any
           insanity it finds, and then crash with a RELEASE_ASSERT.

        3. Since the HeapVerifier captures list of cells in the heap before and after GCs
           for the last N GCs, it will also automatically "trim" dead cells those list
           after the most recent GC.

           "trim" here means that the CellProfile in the HeapVerifier's lists will be
           updated to reflect that the cell is now dead.  It still keeps a record of the
           dead cell pointer and the meta data collected about it back when it was alive.
           As a result, checkIfRecorded() will also report if the candidate cell passed
           to it is a dead object from a previous GC cycle. 

        4. Each CellProfile captured by the HeapVerifier now track the following info:
           - the cell's HeapCell::Kind.
           - the cell's liveness.
           - if is JSCell, the cell's classInfo()->className.
           - an associated timestamp.
           - an associated stack trace.

           Currently, the timestamp is only used for the time when the cell was recorded
           by the HeapVerifier during GC.  The stack trace is currently unused.

           However, these fields are kept there so that we can instrument the VM (during
           a debugging session, which requires rebuilding the VM) and record interesting
           stack traces like that of the time of allocation of the cell.  Since
           capturing the stack traces for each cell is a very heavy weight operation,
           the HeapVerifier code does not do this by default.  Instead, we just leave
           the building blocks for doing so in place to ease future debugging efforts.

        * heap/Heap.cpp:
        (JSC::Heap::runBeginPhase):
        (JSC::Heap::runEndPhase):
        (JSC::Heap::didFinishCollection):
        * heap/Heap.h:
        (JSC::Heap::verifier):
        * heap/MarkedAllocator.h:
        (JSC::MarkedAllocator::takeLastActiveBlock): Deleted.
        * heap/MarkedSpace.h:
        * heap/MarkedSpaceInlines.h:
        (JSC::MarkedSpace::forEachLiveCell):
        * tools/CellList.cpp:
        (JSC::CellList::find):
        (JSC::CellList::reset):
        (JSC::CellList::findCell): Deleted.
        * tools/CellList.h:
        (JSC::CellList::CellList):
        (JSC::CellList::name):
        (JSC::CellList::size):
        (JSC::CellList::cells):
        (JSC::CellList::add):
        (JSC::CellList::reset): Deleted.
        * tools/CellProfile.h:
        (JSC::CellProfile::CellProfile):
        (JSC::CellProfile::cell):
        (JSC::CellProfile::jsCell):
        (JSC::CellProfile::isJSCell):
        (JSC::CellProfile::kind):
        (JSC::CellProfile::isLive):
        (JSC::CellProfile::isDead):
        (JSC::CellProfile::setIsLive):
        (JSC::CellProfile::setIsDead):
        (JSC::CellProfile::timestamp):
        (JSC::CellProfile::className):
        (JSC::CellProfile::stackTrace):
        (JSC::CellProfile::setStackTrace):
        * tools/HeapVerifier.cpp:
        (JSC::HeapVerifier::startGC):
        (JSC::HeapVerifier::endGC):
        (JSC::HeapVerifier::gatherLiveCells):
        (JSC::trimDeadCellsFromList):
        (JSC::HeapVerifier::trimDeadCells):
        (JSC::HeapVerifier::printVerificationHeader):
        (JSC::HeapVerifier::verifyCellList):
        (JSC::HeapVerifier::validateCell):
        (JSC::HeapVerifier::validateJSCell):
        (JSC::HeapVerifier::verify):
        (JSC::HeapVerifier::reportCell):
        (JSC::HeapVerifier::checkIfRecorded):
        (JSC::HeapVerifier::initializeGCCycle): Deleted.
        (JSC::GatherCellFunctor::GatherCellFunctor): Deleted.
        (JSC::GatherCellFunctor::visit): Deleted.
        (JSC::GatherCellFunctor::operator()): Deleted.
        (JSC::HeapVerifier::verifyButterflyIsInStorageSpace): Deleted.
        * tools/HeapVerifier.h:
        (JSC::HeapVerifier::GCCycle::reset):

2017-03-13  SKumarMetro  <s.kumar@metrological.com>

        JSC: fix compilation errors for MIPS
        https://bugs.webkit.org/show_bug.cgi?id=168402

        Reviewed by Mark Lam.

        * assembler/MIPSAssembler.h:
        (JSC::MIPSAssembler::fillNops):
        Added.
        * assembler/MacroAssemblerMIPS.h:
        Added MacroAssemblerMIPS::numGPRs and MacroAssemblerMIPS::numFPRs .
        * bytecode/InlineAccess.h:
        (JSC::InlineAccess::sizeForPropertyAccess):
        (JSC::InlineAccess::sizeForPropertyReplace):
        (JSC::InlineAccess::sizeForLengthAccess):
        Added MIPS cases.

2017-03-13  Filip Pizlo  <fpizlo@apple.com>

        FTL should not flush strict arguments unless it really needs to
        https://bugs.webkit.org/show_bug.cgi?id=169519

        Reviewed by Mark Lam.
        
        This is a refinement that we should have done ages ago. This kills some pointless PutStacks
        in DFG SSA IR. It can sometimes unlock other optimizations.
        
        Relanding after I fixed the special cases for CreateArguments-style nodes. 

        * dfg/DFGPreciseLocalClobberize.h:
        (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):

2017-03-13  Devin Rousso  <webkit@devinrousso.com>

        Web Inspector: Event Listeners section is missing 'once', 'passive' event listener flags
        https://bugs.webkit.org/show_bug.cgi?id=167080

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/DOM.json:
        Add "passive" and "once" items to the EventListener type.

2017-03-13  Mark Lam  <mark.lam@apple.com>

        Remove obsolete experimental ObjC SPI.
        https://bugs.webkit.org/show_bug.cgi?id=169569

        Reviewed by Saam Barati.

        * API/JSVirtualMachine.mm:
        (-[JSVirtualMachine enableSigillCrashAnalyzer]): Deleted.
        * API/JSVirtualMachinePrivate.h: Removed.
        * JavaScriptCore.xcodeproj/project.pbxproj:

2017-03-13  Commit Queue  <commit-queue@webkit.org>

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

        Breaks JSC stress test stress/super-property-access.js.ftl-
        eager failing (Requested by mlam|g on #webkit).

        Reverted changeset:

        "FTL should not flush strict arguments unless it really needs
        to"
        https://bugs.webkit.org/show_bug.cgi?id=169519
        http://trac.webkit.org/changeset/213856

2017-03-13  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC][Linux] Allow profilers to demangle C++ names
        https://bugs.webkit.org/show_bug.cgi?id=169559

        Reviewed by Michael Catanzaro.

        Linux also offers dladdr & demangling feature.
        Thus, we can use it to show the names in profilers.
        For example, SamplingProfiler tells us the C function names.

        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::StackFrame::displayName):
        * tools/CodeProfile.cpp:
        (JSC::symbolName):

2017-03-13  Yusuke Suzuki  <utatane.tea@gmail.com>

        [WTF] Clean up RunLoop and WorkQueue with Seconds and Function
        https://bugs.webkit.org/show_bug.cgi?id=169537

        Reviewed by Sam Weinig.

        * runtime/Watchdog.cpp:
        (JSC::Watchdog::startTimer):

2017-03-11  Filip Pizlo  <fpizlo@apple.com>

        FTL should not flush strict arguments unless it really needs to
        https://bugs.webkit.org/show_bug.cgi?id=169519

        Reviewed by Mark Lam.
        
        This is a refinement that we should have done ages ago. This kills some pointless PutStacks
        in DFG SSA IR. It can sometimes unlock other optimizations.

        * dfg/DFGPreciseLocalClobberize.h:
        (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):

2017-03-13  Caio Lima  <ticaiolima@gmail.com>

        [JSC] It should be possible create a label named let when parsing Statement in non strict mode
        https://bugs.webkit.org/show_bug.cgi?id=168684

        Reviewed by Saam Barati.

        This patch is fixing a Parser bug to allow define a label named
        ```let``` in sloppy mode when parsing a Statement.

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

2017-03-11  Filip Pizlo  <fpizlo@apple.com>

        Structure::willStoreValueSlow needs to keep the property table alive until the end
        https://bugs.webkit.org/show_bug.cgi?id=169520

        Reviewed by Michael Saboff.

        We use pointers logically interior to `propertyTable` after doing a GC. We need to prevent the
        compiler from optimizing away pointers to `propertyTable`.
        
        * heap/HeapCell.cpp:
        (JSC::HeapCell::use):
        * heap/HeapCell.h:
        (JSC::HeapCell::use): Introduce API for keeping a pointer alive until some point in execution.
        * runtime/Structure.cpp:
        (JSC::Structure::willStoreValueSlow): Use HeapCell::use() to keep the pointer alive.

2017-03-11  Yusuke Suzuki  <utatane.tea@gmail.com>

        Unreviewed, suprress warnings in JSC B3

        * b3/B3Opcode.cpp:

2017-03-11  Michael Saboff  <msaboff@apple.com>

        Allow regular expressions to be used when selecting a process name in JSC config file
        https://bugs.webkit.org/show_bug.cgi?id=169495

        Reviewed by Saam Barati.

        Only added regular expression selectors for unix like platforms.

        * runtime/ConfigFile.cpp:
        (JSC::ConfigFileScanner::tryConsumeRegExPattern):
        (JSC::ConfigFile::parse):

2017-03-11  Jon Lee  <jonlee@apple.com>

        WebGPU prototype - Front-End
        https://bugs.webkit.org/show_bug.cgi?id=167952

        Reviewed by Dean Jackson.

        * runtime/CommonIdentifiers.h: Add WebGPU objects.

2017-03-10  Filip Pizlo  <fpizlo@apple.com>

        The JITs should be able to emit fast TLS loads
        https://bugs.webkit.org/show_bug.cgi?id=169483

        Reviewed by Keith Miller.
        
        Added loadFromTLS32/64/Ptr to the MacroAssembler and added a B3 test for this.

        * assembler/ARM64Assembler.h:
        (JSC::ARM64Assembler::mrs_TPIDRRO_EL0):
        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::loadFromTLSPtr):
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::loadFromTLS32):
        (JSC::MacroAssemblerARM64::loadFromTLS64):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::loadFromTLS32):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::loadFromTLS64):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::adcl_im):
        (JSC::X86Assembler::addl_mr):
        (JSC::X86Assembler::addl_im):
        (JSC::X86Assembler::andl_im):
        (JSC::X86Assembler::orl_im):
        (JSC::X86Assembler::orl_rm):
        (JSC::X86Assembler::subl_im):
        (JSC::X86Assembler::cmpb_im):
        (JSC::X86Assembler::cmpl_rm):
        (JSC::X86Assembler::cmpl_im):
        (JSC::X86Assembler::testb_im):
        (JSC::X86Assembler::movb_i8m):
        (JSC::X86Assembler::movb_rm):
        (JSC::X86Assembler::movl_mr):
        (JSC::X86Assembler::movq_mr):
        (JSC::X86Assembler::movsxd_rr):
        (JSC::X86Assembler::gs):
        (JSC::X86Assembler::X86InstructionFormatter::SingleInstructionBufferWriter::memoryModRM):
        * b3/testb3.cpp:
        (JSC::B3::testFastTLS):
        (JSC::B3::run):

2017-03-10  Alex Christensen  <achristensen@webkit.org>

        Fix watch and tv builds after r213294
        https://bugs.webkit.org/show_bug.cgi?id=169508

        Reviewed by Dan Bernstein.

        * Configurations/FeatureDefines.xcconfig:

2017-03-10  Saam Barati  <sbarati@apple.com>

        WebAssembly: Make more demos run
        https://bugs.webkit.org/show_bug.cgi?id=165510
        <rdar://problem/29760310>

        Reviewed by Keith Miller.

        This patch makes another Wasm demo run:
        https://kripken.github.io/BananaBread/cube2/bb.html
        
        This patch fixes two bugs:
        1. When WebAssemblyFunctionType was added, we did not properly
        update the last JS type value.
        2. Our code for our JS -> Wasm entrypoint was wrong. It lead to bad
        code generation where we would emit B3 that would write over r12
        and rbx (on x86) which is invalid since those are our pinned registers.
        This patch just rewrites the entrypoint to use hand written assembler
        code. I was planning on doing this anyways because it's a compile
        time speed boost.
        
        Also, this patch adds support for some new API features:
        We can now export an import, either via a direct export, or via a Table and the
        Element section. I've added a new class called WebAssemblyWrapperFunction that
        just wraps over a JSObject that is a function. Wrapper functions have types
        associated with them, so if they're re-imported, or called via call_indirect,
        they can be type checked.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::webAssemblyWrapperFunctionStructure):
        * runtime/JSType.h:
        * wasm/JSWebAssemblyCodeBlock.h:
        (JSC::JSWebAssemblyCodeBlock::wasmToJsCallStubForImport):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::createJSToWasmWrapper):
        * wasm/WasmCallingConvention.h:
        (JSC::Wasm::CallingConvention::headerSizeInBytes):
        * wasm/js/JSWebAssemblyHelpers.h:
        (JSC::isWebAssemblyHostFunction):
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
        * wasm/js/JSWebAssemblyInstance.h:
        (JSC::JSWebAssemblyInstance::importFunction):
        (JSC::JSWebAssemblyInstance::importFunctions):
        (JSC::JSWebAssemblyInstance::setImportFunction):
        * wasm/js/JSWebAssemblyTable.cpp:
        (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
        (JSC::JSWebAssemblyTable::grow):
        (JSC::JSWebAssemblyTable::clearFunction):
        (JSC::JSWebAssemblyTable::setFunction):
        * wasm/js/JSWebAssemblyTable.h:
        (JSC::JSWebAssemblyTable::getFunction):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction):
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::WebAssemblyInstanceConstructor::createInstance):
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::link):
        (JSC::WebAssemblyModuleRecord::evaluate):
        * wasm/js/WebAssemblyModuleRecord.h:
        * wasm/js/WebAssemblyTablePrototype.cpp:
        (JSC::webAssemblyTableProtoFuncGet):
        (JSC::webAssemblyTableProtoFuncSet):
        * wasm/js/WebAssemblyWrapperFunction.cpp: Added.
        (JSC::callWebAssemblyWrapperFunction):
        (JSC::WebAssemblyWrapperFunction::WebAssemblyWrapperFunction):
        (JSC::WebAssemblyWrapperFunction::create):
        (JSC::WebAssemblyWrapperFunction::finishCreation):
        (JSC::WebAssemblyWrapperFunction::createStructure):
        (JSC::WebAssemblyWrapperFunction::visitChildren):
        * wasm/js/WebAssemblyWrapperFunction.h: Added.
        (JSC::WebAssemblyWrapperFunction::signatureIndex):
        (JSC::WebAssemblyWrapperFunction::wasmEntrypoint):
        (JSC::WebAssemblyWrapperFunction::function):

2017-03-10  Mark Lam  <mark.lam@apple.com>

        JSC: BindingNode::bindValue doesn't increase the scope's reference count.
        https://bugs.webkit.org/show_bug.cgi?id=168546
        <rdar://problem/30589551>

        Reviewed by Saam Barati.

        We should protect the scope RegisterID with a RefPtr while it is still needed.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::ForInNode::emitLoopHeader):
        (JSC::ForOfNode::emitBytecode):
        (JSC::BindingNode::bindValue):

2017-03-10  Alex Christensen  <achristensen@webkit.org>

        Fix CMake build.

        * CMakeLists.txt:
        Make more forwarding headers so we can find WasmFaultSignalHandler.h from WebProcess.cpp.

2017-03-10  Mark Lam  <mark.lam@apple.com>

        [Re-landing] Implement a StackTrace utility object that can capture stack traces for debugging.
        https://bugs.webkit.org/show_bug.cgi?id=169454

        Reviewed by Michael Saboff.

        The underlying implementation is hoisted right out of Assertions.cpp from the
        implementations of WTFPrintBacktrace().

        The reason we need this StackTrace object is because during heap debugging, we
        sometimes want to capture the stack trace that allocated the objects of interest.
        Dumping the stack trace directly to stdout (using WTFReportBacktrace()) may
        perturb the execution profile sufficiently that an issue may not reproduce,
        while alternatively, just capturing the stack trace and deferring printing it
        till we actually need it later perturbs the execution profile less.

        In addition, just capturing the stack traces (instead of printing them
        immediately at each capture site) allows us to avoid polluting stdout with tons
        of stack traces that may be irrelevant.

        For now, we only capture the native stack trace.  We'll leave capturing and
        integrating the JS stack trace as an exercise for the future if we need it then.

        Here's an example of how to use this StackTrace utility:

            // Capture a stack trace of the top 10 frames.
            std::unique_ptr<StackTrace> trace(StackTrace::captureStackTrace(10));
            // Print the trace.
            dataLog(*trace);

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * tools/StackTrace.cpp: Added.
        (JSC::StackTrace::instanceSize):
        (JSC::StackTrace::captureStackTrace):
        (JSC::StackTrace::dump):
        * tools/StackTrace.h: Added.
        (JSC::StackTrace::size):
        (JSC::StackTrace::StackTrace):

2017-03-04  Filip Pizlo  <fpizlo@apple.com>

        B3 should have comprehensive support for atomic operations
        https://bugs.webkit.org/show_bug.cgi?id=162349

        Reviewed by Keith Miller.
        
        This adds the following capabilities to B3:
        
        - Atomic weak/strong unfenced/fenced compare-and-swap
        - Atomic add/sub/or/and/xor/xchg
        - Acquire/release fencing on loads/stores
        - Fenceless load-load dependencies
        
        This adds lowering to the following instructions on x86:
        
        - lock cmpxchg
        - lock xadd
        - lock add/sub/or/and/xor/xchg
        
        This adds lowering to the following instructions on ARM64:
        
        - ldar and friends
        - stlr and friends
        - ldxr and friends (unfenced LL)
        - stxr and friends (unfended SC)
        - ldaxr and friends (fenced LL)
        - stlxr and friends (fenced SC)
        - eor as a fenceless load-load dependency
        
        This does instruction selection pattern matching to ensure that weak/strong CAS and all of the
        variants of fences and atomic math ops get lowered to the best possible instruction sequence.
        For example, we support the Equal(AtomicStrongCAS(expected, ...), expected) pattern and a bunch
        of its friends. You can say Branch(Equal(AtomicStrongCAS(expected, ...), expected)) and it will
        generate the best possible branch sequence on x86 and ARM64.
        
        B3 now knows how to model all of the kinds of fencing. It knows that acq loads are ordered with
        respect to each other and with respect to rel stores, creating sequential consistency that
        transcends just the acq/rel fences themselves (see Effects::fence). It knows that the phantom
        fence effects may only target some abstract heaps but not others, so that load elimination and
        store sinking can still operate across fences if you just tell B3 that the fence does not alias
        those accesses. This makes it super easy to teach B3 that some of your heap is thread-local.
        Even better, it lets you express fine-grained dependencies where the atomics that affect one
        property in shared memory do not clobber non-atomics that ffect some other property in shared
        memory.
        
        One of my favorite features is Depend, which allows you to express load-load dependencies. On
        x86 it lowers to nothing, while on ARM64 it lowers to eor.
        
        This also exposes a common atomicWeakCAS API to the x86_64/ARM64 MacroAssemblers. Same for
        acq/rel. JSC's 64-bit JITs are now a happy concurrency playground.
        
        This doesn't yet expose the functionality to JS or wasm. SAB still uses the non-intrinsic
        implementations of the Atomics object, for now.
        
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/ARM64Assembler.h:
        (JSC::ARM64Assembler::ldar):
        (JSC::ARM64Assembler::ldxr):
        (JSC::ARM64Assembler::ldaxr):
        (JSC::ARM64Assembler::stxr):
        (JSC::ARM64Assembler::stlr):
        (JSC::ARM64Assembler::stlxr):
        (JSC::ARM64Assembler::excepnGenerationImmMask):
        (JSC::ARM64Assembler::exoticLoad):
        (JSC::ARM64Assembler::storeRelease):
        (JSC::ARM64Assembler::exoticStore):
        * assembler/AbstractMacroAssembler.cpp: Added.
        (WTF::printInternal):
        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssemblerBase::invert):
        * assembler/MacroAssembler.h:
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::loadAcq8SignedExtendTo32):
        (JSC::MacroAssemblerARM64::loadAcq8):
        (JSC::MacroAssemblerARM64::storeRel8):
        (JSC::MacroAssemblerARM64::loadAcq16SignedExtendTo32):
        (JSC::MacroAssemblerARM64::loadAcq16):
        (JSC::MacroAssemblerARM64::storeRel16):
        (JSC::MacroAssemblerARM64::loadAcq32):
        (JSC::MacroAssemblerARM64::loadAcq64):
        (JSC::MacroAssemblerARM64::storeRel32):
        (JSC::MacroAssemblerARM64::storeRel64):
        (JSC::MacroAssemblerARM64::loadLink8):
        (JSC::MacroAssemblerARM64::loadLinkAcq8):
        (JSC::MacroAssemblerARM64::storeCond8):
        (JSC::MacroAssemblerARM64::storeCondRel8):
        (JSC::MacroAssemblerARM64::loadLink16):
        (JSC::MacroAssemblerARM64::loadLinkAcq16):
        (JSC::MacroAssemblerARM64::storeCond16):
        (JSC::MacroAssemblerARM64::storeCondRel16):
        (JSC::MacroAssemblerARM64::loadLink32):
        (JSC::MacroAssemblerARM64::loadLinkAcq32):
        (JSC::MacroAssemblerARM64::storeCond32):
        (JSC::MacroAssemblerARM64::storeCondRel32):
        (JSC::MacroAssemblerARM64::loadLink64):
        (JSC::MacroAssemblerARM64::loadLinkAcq64):
        (JSC::MacroAssemblerARM64::storeCond64):
        (JSC::MacroAssemblerARM64::storeCondRel64):
        (JSC::MacroAssemblerARM64::atomicStrongCAS8):
        (JSC::MacroAssemblerARM64::atomicStrongCAS16):
        (JSC::MacroAssemblerARM64::atomicStrongCAS32):
        (JSC::MacroAssemblerARM64::atomicStrongCAS64):
        (JSC::MacroAssemblerARM64::atomicRelaxedStrongCAS8):
        (JSC::MacroAssemblerARM64::atomicRelaxedStrongCAS16):
        (JSC::MacroAssemblerARM64::atomicRelaxedStrongCAS32):
        (JSC::MacroAssemblerARM64::atomicRelaxedStrongCAS64):
        (JSC::MacroAssemblerARM64::branchAtomicWeakCAS8):
        (JSC::MacroAssemblerARM64::branchAtomicWeakCAS16):
        (JSC::MacroAssemblerARM64::branchAtomicWeakCAS32):
        (JSC::MacroAssemblerARM64::branchAtomicWeakCAS64):
        (JSC::MacroAssemblerARM64::branchAtomicRelaxedWeakCAS8):
        (JSC::MacroAssemblerARM64::branchAtomicRelaxedWeakCAS16):
        (JSC::MacroAssemblerARM64::branchAtomicRelaxedWeakCAS32):
        (JSC::MacroAssemblerARM64::branchAtomicRelaxedWeakCAS64):
        (JSC::MacroAssemblerARM64::depend32):
        (JSC::MacroAssemblerARM64::depend64):
        (JSC::MacroAssemblerARM64::loadLink):
        (JSC::MacroAssemblerARM64::loadLinkAcq):
        (JSC::MacroAssemblerARM64::storeCond):
        (JSC::MacroAssemblerARM64::storeCondRel):
        (JSC::MacroAssemblerARM64::signExtend):
        (JSC::MacroAssemblerARM64::branch):
        (JSC::MacroAssemblerARM64::atomicStrongCAS):
        (JSC::MacroAssemblerARM64::atomicRelaxedStrongCAS):
        (JSC::MacroAssemblerARM64::branchAtomicWeakCAS):
        (JSC::MacroAssemblerARM64::branchAtomicRelaxedWeakCAS):
        (JSC::MacroAssemblerARM64::extractSimpleAddress):
        (JSC::MacroAssemblerARM64::signExtend<8>):
        (JSC::MacroAssemblerARM64::signExtend<16>):
        (JSC::MacroAssemblerARM64::branch<64>):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::add32):
        (JSC::MacroAssemblerX86Common::and32):
        (JSC::MacroAssemblerX86Common::and16):
        (JSC::MacroAssemblerX86Common::and8):
        (JSC::MacroAssemblerX86Common::neg32):
        (JSC::MacroAssemblerX86Common::neg16):
        (JSC::MacroAssemblerX86Common::neg8):
        (JSC::MacroAssemblerX86Common::or32):
        (JSC::MacroAssemblerX86Common::or16):
        (JSC::MacroAssemblerX86Common::or8):
        (JSC::MacroAssemblerX86Common::sub16):
        (JSC::MacroAssemblerX86Common::sub8):
        (JSC::MacroAssemblerX86Common::sub32):
        (JSC::MacroAssemblerX86Common::xor32):
        (JSC::MacroAssemblerX86Common::xor16):
        (JSC::MacroAssemblerX86Common::xor8):
        (JSC::MacroAssemblerX86Common::not32):
        (JSC::MacroAssemblerX86Common::not16):
        (JSC::MacroAssemblerX86Common::not8):
        (JSC::MacroAssemblerX86Common::store16):
        (JSC::MacroAssemblerX86Common::atomicStrongCAS8):
        (JSC::MacroAssemblerX86Common::atomicStrongCAS16):
        (JSC::MacroAssemblerX86Common::atomicStrongCAS32):
        (JSC::MacroAssemblerX86Common::branchAtomicStrongCAS8):
        (JSC::MacroAssemblerX86Common::branchAtomicStrongCAS16):
        (JSC::MacroAssemblerX86Common::branchAtomicStrongCAS32):
        (JSC::MacroAssemblerX86Common::atomicWeakCAS8):
        (JSC::MacroAssemblerX86Common::atomicWeakCAS16):
        (JSC::MacroAssemblerX86Common::atomicWeakCAS32):
        (JSC::MacroAssemblerX86Common::branchAtomicWeakCAS8):
        (JSC::MacroAssemblerX86Common::branchAtomicWeakCAS16):
        (JSC::MacroAssemblerX86Common::branchAtomicWeakCAS32):
        (JSC::MacroAssemblerX86Common::atomicRelaxedWeakCAS8):
        (JSC::MacroAssemblerX86Common::atomicRelaxedWeakCAS16):
        (JSC::MacroAssemblerX86Common::atomicRelaxedWeakCAS32):
        (JSC::MacroAssemblerX86Common::branchAtomicRelaxedWeakCAS8):
        (JSC::MacroAssemblerX86Common::branchAtomicRelaxedWeakCAS16):
        (JSC::MacroAssemblerX86Common::branchAtomicRelaxedWeakCAS32):
        (JSC::MacroAssemblerX86Common::atomicAdd8):
        (JSC::MacroAssemblerX86Common::atomicAdd16):
        (JSC::MacroAssemblerX86Common::atomicAdd32):
        (JSC::MacroAssemblerX86Common::atomicSub8):
        (JSC::MacroAssemblerX86Common::atomicSub16):
        (JSC::MacroAssemblerX86Common::atomicSub32):
        (JSC::MacroAssemblerX86Common::atomicAnd8):
        (JSC::MacroAssemblerX86Common::atomicAnd16):
        (JSC::MacroAssemblerX86Common::atomicAnd32):
        (JSC::MacroAssemblerX86Common::atomicOr8):
        (JSC::MacroAssemblerX86Common::atomicOr16):
        (JSC::MacroAssemblerX86Common::atomicOr32):
        (JSC::MacroAssemblerX86Common::atomicXor8):
        (JSC::MacroAssemblerX86Common::atomicXor16):
        (JSC::MacroAssemblerX86Common::atomicXor32):
        (JSC::MacroAssemblerX86Common::atomicNeg8):
        (JSC::MacroAssemblerX86Common::atomicNeg16):
        (JSC::MacroAssemblerX86Common::atomicNeg32):
        (JSC::MacroAssemblerX86Common::atomicNot8):
        (JSC::MacroAssemblerX86Common::atomicNot16):
        (JSC::MacroAssemblerX86Common::atomicNot32):
        (JSC::MacroAssemblerX86Common::atomicXchgAdd8):
        (JSC::MacroAssemblerX86Common::atomicXchgAdd16):
        (JSC::MacroAssemblerX86Common::atomicXchgAdd32):
        (JSC::MacroAssemblerX86Common::atomicXchg8):
        (JSC::MacroAssemblerX86Common::atomicXchg16):
        (JSC::MacroAssemblerX86Common::atomicXchg32):
        (JSC::MacroAssemblerX86Common::loadAcq8):
        (JSC::MacroAssemblerX86Common::loadAcq8SignedExtendTo32):
        (JSC::MacroAssemblerX86Common::loadAcq16):
        (JSC::MacroAssemblerX86Common::loadAcq16SignedExtendTo32):
        (JSC::MacroAssemblerX86Common::loadAcq32):
        (JSC::MacroAssemblerX86Common::storeRel8):
        (JSC::MacroAssemblerX86Common::storeRel16):
        (JSC::MacroAssemblerX86Common::storeRel32):
        (JSC::MacroAssemblerX86Common::storeFence):
        (JSC::MacroAssemblerX86Common::loadFence):
        (JSC::MacroAssemblerX86Common::replaceWithJump):
        (JSC::MacroAssemblerX86Common::maxJumpReplacementSize):
        (JSC::MacroAssemblerX86Common::patchableJumpSize):
        (JSC::MacroAssemblerX86Common::supportsFloatingPointRounding):
        (JSC::MacroAssemblerX86Common::supportsAVX):
        (JSC::MacroAssemblerX86Common::updateEax1EcxFlags):
        (JSC::MacroAssemblerX86Common::x86Condition):
        (JSC::MacroAssemblerX86Common::atomicStrongCAS):
        (JSC::MacroAssemblerX86Common::branchAtomicStrongCAS):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::add64):
        (JSC::MacroAssemblerX86_64::and64):
        (JSC::MacroAssemblerX86_64::neg64):
        (JSC::MacroAssemblerX86_64::or64):
        (JSC::MacroAssemblerX86_64::sub64):
        (JSC::MacroAssemblerX86_64::xor64):
        (JSC::MacroAssemblerX86_64::not64):
        (JSC::MacroAssemblerX86_64::store64):
        (JSC::MacroAssemblerX86_64::atomicStrongCAS64):
        (JSC::MacroAssemblerX86_64::branchAtomicStrongCAS64):
        (JSC::MacroAssemblerX86_64::atomicWeakCAS64):
        (JSC::MacroAssemblerX86_64::branchAtomicWeakCAS64):
        (JSC::MacroAssemblerX86_64::atomicRelaxedWeakCAS64):
        (JSC::MacroAssemblerX86_64::branchAtomicRelaxedWeakCAS64):
        (JSC::MacroAssemblerX86_64::atomicAdd64):
        (JSC::MacroAssemblerX86_64::atomicSub64):
        (JSC::MacroAssemblerX86_64::atomicAnd64):
        (JSC::MacroAssemblerX86_64::atomicOr64):
        (JSC::MacroAssemblerX86_64::atomicXor64):
        (JSC::MacroAssemblerX86_64::atomicNeg64):
        (JSC::MacroAssemblerX86_64::atomicNot64):
        (JSC::MacroAssemblerX86_64::atomicXchgAdd64):
        (JSC::MacroAssemblerX86_64::atomicXchg64):
        (JSC::MacroAssemblerX86_64::loadAcq64):
        (JSC::MacroAssemblerX86_64::storeRel64):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::addl_mr):
        (JSC::X86Assembler::addq_mr):
        (JSC::X86Assembler::addq_rm):
        (JSC::X86Assembler::addq_im):
        (JSC::X86Assembler::andl_mr):
        (JSC::X86Assembler::andl_rm):
        (JSC::X86Assembler::andw_rm):
        (JSC::X86Assembler::andb_rm):
        (JSC::X86Assembler::andl_im):
        (JSC::X86Assembler::andw_im):
        (JSC::X86Assembler::andb_im):
        (JSC::X86Assembler::andq_mr):
        (JSC::X86Assembler::andq_rm):
        (JSC::X86Assembler::andq_im):
        (JSC::X86Assembler::incq_m):
        (JSC::X86Assembler::negq_m):
        (JSC::X86Assembler::negl_m):
        (JSC::X86Assembler::negw_m):
        (JSC::X86Assembler::negb_m):
        (JSC::X86Assembler::notl_m):
        (JSC::X86Assembler::notw_m):
        (JSC::X86Assembler::notb_m):
        (JSC::X86Assembler::notq_m):
        (JSC::X86Assembler::orl_mr):
        (JSC::X86Assembler::orl_rm):
        (JSC::X86Assembler::orw_rm):
        (JSC::X86Assembler::orb_rm):
        (JSC::X86Assembler::orl_im):
        (JSC::X86Assembler::orw_im):
        (JSC::X86Assembler::orb_im):
        (JSC::X86Assembler::orq_mr):
        (JSC::X86Assembler::orq_rm):
        (JSC::X86Assembler::orq_im):
        (JSC::X86Assembler::subl_mr):
        (JSC::X86Assembler::subl_rm):
        (JSC::X86Assembler::subw_rm):
        (JSC::X86Assembler::subb_rm):
        (JSC::X86Assembler::subl_im):
        (JSC::X86Assembler::subw_im):
        (JSC::X86Assembler::subb_im):
        (JSC::X86Assembler::subq_mr):
        (JSC::X86Assembler::subq_rm):
        (JSC::X86Assembler::subq_im):
        (JSC::X86Assembler::xorl_mr):
        (JSC::X86Assembler::xorl_rm):
        (JSC::X86Assembler::xorl_im):
        (JSC::X86Assembler::xorw_rm):
        (JSC::X86Assembler::xorw_im):
        (JSC::X86Assembler::xorb_rm):
        (JSC::X86Assembler::xorb_im):
        (JSC::X86Assembler::xorq_im):
        (JSC::X86Assembler::xorq_rm):
        (JSC::X86Assembler::xorq_mr):
        (JSC::X86Assembler::xchgb_rm):
        (JSC::X86Assembler::xchgw_rm):
        (JSC::X86Assembler::xchgl_rm):
        (JSC::X86Assembler::xchgq_rm):
        (JSC::X86Assembler::movw_im):
        (JSC::X86Assembler::movq_i32m):
        (JSC::X86Assembler::cmpxchgb_rm):
        (JSC::X86Assembler::cmpxchgw_rm):
        (JSC::X86Assembler::cmpxchgl_rm):
        (JSC::X86Assembler::cmpxchgq_rm):
        (JSC::X86Assembler::xaddb_rm):
        (JSC::X86Assembler::xaddw_rm):
        (JSC::X86Assembler::xaddl_rm):
        (JSC::X86Assembler::xaddq_rm):
        (JSC::X86Assembler::X86InstructionFormatter::SingleInstructionBufferWriter::memoryModRM):
        * b3/B3AtomicValue.cpp: Added.
        (JSC::B3::AtomicValue::~AtomicValue):
        (JSC::B3::AtomicValue::dumpMeta):
        (JSC::B3::AtomicValue::cloneImpl):
        (JSC::B3::AtomicValue::AtomicValue):
        * b3/B3AtomicValue.h: Added.
        * b3/B3BasicBlock.h:
        * b3/B3BlockInsertionSet.cpp:
        (JSC::B3::BlockInsertionSet::BlockInsertionSet):
        (JSC::B3::BlockInsertionSet::insert): Deleted.
        (JSC::B3::BlockInsertionSet::insertBefore): Deleted.
        (JSC::B3::BlockInsertionSet::insertAfter): Deleted.
        (JSC::B3::BlockInsertionSet::execute): Deleted.
        * b3/B3BlockInsertionSet.h:
        * b3/B3Effects.cpp:
        (JSC::B3::Effects::interferes):
        (JSC::B3::Effects::operator==):
        (JSC::B3::Effects::dump):
        * b3/B3Effects.h:
        (JSC::B3::Effects::forCall):
        (JSC::B3::Effects::mustExecute):
        * b3/B3EliminateCommonSubexpressions.cpp:
        * b3/B3Generate.cpp:
        (JSC::B3::generateToAir):
        * b3/B3GenericBlockInsertionSet.h: Added.
        (JSC::B3::GenericBlockInsertionSet::GenericBlockInsertionSet):
        (JSC::B3::GenericBlockInsertionSet::insert):
        (JSC::B3::GenericBlockInsertionSet::insertBefore):
        (JSC::B3::GenericBlockInsertionSet::insertAfter):
        (JSC::B3::GenericBlockInsertionSet::execute):
        * b3/B3HeapRange.h:
        (JSC::B3::HeapRange::operator|):
        * b3/B3InsertionSet.cpp:
        (JSC::B3::InsertionSet::insertClone):
        * b3/B3InsertionSet.h:
        * b3/B3LegalizeMemoryOffsets.cpp:
        * b3/B3LowerMacros.cpp:
        (JSC::B3::lowerMacros):
        * b3/B3LowerMacrosAfterOptimizations.cpp:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::LowerToAir):
        (JSC::B3::Air::LowerToAir::run):
        (JSC::B3::Air::LowerToAir::effectiveAddr):
        (JSC::B3::Air::LowerToAir::addr):
        (JSC::B3::Air::LowerToAir::loadPromiseAnyOpcode):
        (JSC::B3::Air::LowerToAir::appendShift):
        (JSC::B3::Air::LowerToAir::tryAppendStoreBinOp):
        (JSC::B3::Air::LowerToAir::storeOpcode):
        (JSC::B3::Air::LowerToAir::createStore):
        (JSC::B3::Air::LowerToAir::finishAppendingInstructions):
        (JSC::B3::Air::LowerToAir::newBlock):
        (JSC::B3::Air::LowerToAir::splitBlock):
        (JSC::B3::Air::LowerToAir::fillStackmap):
        (JSC::B3::Air::LowerToAir::appendX86Div):
        (JSC::B3::Air::LowerToAir::appendX86UDiv):
        (JSC::B3::Air::LowerToAir::loadLinkOpcode):
        (JSC::B3::Air::LowerToAir::storeCondOpcode):
        (JSC::B3::Air::LowerToAir::appendCAS):
        (JSC::B3::Air::LowerToAir::appendVoidAtomic):
        (JSC::B3::Air::LowerToAir::appendGeneralAtomic):
        (JSC::B3::Air::LowerToAir::lower):
        (JSC::B3::Air::LowerToAir::lowerX86Div): Deleted.
        (JSC::B3::Air::LowerToAir::lowerX86UDiv): Deleted.
        * b3/B3LowerToAir.h:
        * b3/B3MemoryValue.cpp:
        (JSC::B3::MemoryValue::isLegalOffset):
        (JSC::B3::MemoryValue::accessType):
        (JSC::B3::MemoryValue::accessBank):
        (JSC::B3::MemoryValue::accessByteSize):
        (JSC::B3::MemoryValue::dumpMeta):
        (JSC::B3::MemoryValue::MemoryValue):
        (JSC::B3::MemoryValue::accessWidth): Deleted.
        * b3/B3MemoryValue.h:
        * b3/B3MemoryValueInlines.h: Added.
        (JSC::B3::MemoryValue::isLegalOffset):
        (JSC::B3::MemoryValue::requiresSimpleAddr):
        (JSC::B3::MemoryValue::accessWidth):
        * b3/B3MoveConstants.cpp:
        * b3/B3NativeTraits.h: Added.
        * b3/B3Opcode.cpp:
        (JSC::B3::storeOpcode):
        (WTF::printInternal):
        * b3/B3Opcode.h:
        (JSC::B3::isLoad):
        (JSC::B3::isStore):
        (JSC::B3::isLoadStore):
        (JSC::B3::isAtomic):
        (JSC::B3::isAtomicCAS):
        (JSC::B3::isAtomicXchg):
        (JSC::B3::isMemoryAccess):
        (JSC::B3::signExtendOpcode):
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::dump):
        * b3/B3Procedure.h:
        (JSC::B3::Procedure::hasQuirks):
        (JSC::B3::Procedure::setHasQuirks):
        * b3/B3PureCSE.cpp:
        (JSC::B3::pureCSE):
        * b3/B3PureCSE.h:
        * b3/B3ReduceStrength.cpp:
        * b3/B3Validate.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::returnsBool):
        (JSC::B3::Value::effects):
        (JSC::B3::Value::key):
        (JSC::B3::Value::performSubstitution):
        (JSC::B3::Value::typeFor):
        * b3/B3Value.h:
        * b3/B3Width.cpp:
        (JSC::B3::bestType):
        * b3/B3Width.h:
        (JSC::B3::canonicalWidth):
        (JSC::B3::isCanonicalWidth):
        (JSC::B3::mask):
        * b3/air/AirArg.cpp:
        (JSC::B3::Air::Arg::jsHash):
        (JSC::B3::Air::Arg::dump):
        (WTF::printInternal):
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::isAnyUse):
        (JSC::B3::Air::Arg::isColdUse):
        (JSC::B3::Air::Arg::cooled):
        (JSC::B3::Air::Arg::isEarlyUse):
        (JSC::B3::Air::Arg::isLateUse):
        (JSC::B3::Air::Arg::isAnyDef):
        (JSC::B3::Air::Arg::isEarlyDef):
        (JSC::B3::Air::Arg::isLateDef):
        (JSC::B3::Air::Arg::isZDef):
        (JSC::B3::Air::Arg::simpleAddr):
        (JSC::B3::Air::Arg::statusCond):
        (JSC::B3::Air::Arg::isSimpleAddr):
        (JSC::B3::Air::Arg::isMemory):
        (JSC::B3::Air::Arg::isStatusCond):
        (JSC::B3::Air::Arg::isCondition):
        (JSC::B3::Air::Arg::ptr):
        (JSC::B3::Air::Arg::base):
        (JSC::B3::Air::Arg::isGP):
        (JSC::B3::Air::Arg::isFP):
        (JSC::B3::Air::Arg::isValidForm):
        (JSC::B3::Air::Arg::forEachTmpFast):
        (JSC::B3::Air::Arg::forEachTmp):
        (JSC::B3::Air::Arg::asAddress):
        (JSC::B3::Air::Arg::asStatusCondition):
        (JSC::B3::Air::Arg::isInvertible):
        (JSC::B3::Air::Arg::inverted):
        * b3/air/AirBasicBlock.cpp:
        (JSC::B3::Air::BasicBlock::setSuccessors):
        * b3/air/AirBasicBlock.h:
        * b3/air/AirBlockInsertionSet.cpp: Added.
        (JSC::B3::Air::BlockInsertionSet::BlockInsertionSet):
        (JSC::B3::Air::BlockInsertionSet::~BlockInsertionSet):
        * b3/air/AirBlockInsertionSet.h: Added.
        * b3/air/AirDumpAsJS.cpp: Removed.
        * b3/air/AirDumpAsJS.h: Removed.
        * b3/air/AirEliminateDeadCode.cpp:
        (JSC::B3::Air::eliminateDeadCode):
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::prepareForGeneration):
        * b3/air/AirInstInlines.h:
        (JSC::B3::Air::isAtomicStrongCASValid):
        (JSC::B3::Air::isBranchAtomicStrongCASValid):
        (JSC::B3::Air::isAtomicStrongCAS8Valid):
        (JSC::B3::Air::isAtomicStrongCAS16Valid):
        (JSC::B3::Air::isAtomicStrongCAS32Valid):
        (JSC::B3::Air::isAtomicStrongCAS64Valid):
        (JSC::B3::Air::isBranchAtomicStrongCAS8Valid):
        (JSC::B3::Air::isBranchAtomicStrongCAS16Valid):
        (JSC::B3::Air::isBranchAtomicStrongCAS32Valid):
        (JSC::B3::Air::isBranchAtomicStrongCAS64Valid):
        * b3/air/AirOpcode.opcodes:
        * b3/air/AirOptimizeBlockOrder.cpp:
        (JSC::B3::Air::optimizeBlockOrder):
        * b3/air/AirPadInterference.cpp:
        (JSC::B3::Air::padInterference):
        * b3/air/AirSpillEverything.cpp:
        (JSC::B3::Air::spillEverything):
        * b3/air/opcode_generator.rb:
        * b3/testb3.cpp:
        (JSC::B3::testLoadAcq42):
        (JSC::B3::testStoreRelAddLoadAcq32):
        (JSC::B3::testStoreRelAddLoadAcq8):
        (JSC::B3::testStoreRelAddFenceLoadAcq8):
        (JSC::B3::testStoreRelAddLoadAcq16):
        (JSC::B3::testStoreRelAddLoadAcq64):
        (JSC::B3::testTrappingStoreElimination):
        (JSC::B3::testX86LeaAddAdd):
        (JSC::B3::testX86LeaAddShlLeftScale1):
        (JSC::B3::testAtomicWeakCAS):
        (JSC::B3::testAtomicStrongCAS):
        (JSC::B3::testAtomicXchg):
        (JSC::B3::testDepend32):
        (JSC::B3::testDepend64):
        (JSC::B3::run):
        * runtime/Options.h:

2017-03-10  Csaba Osztrogonác  <ossy@webkit.org>

        Unreviewed typo fixes after r213652.
        https://bugs.webkit.org/show_bug.cgi?id=168920

        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::replaceWithBreakpoint):
        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::replaceWithBreakpoint):

2017-03-10  Csaba Osztrogonác  <ossy@webkit.org>

        Unreviewed ARM buildfix after r213652.
        https://bugs.webkit.org/show_bug.cgi?id=168920

        r213652 used replaceWithBrk and replaceWithBkpt names for the same
        function, which was inconsistent and caused build error in ARMAssembler.

        * assembler/ARM64Assembler.h:
        (JSC::ARM64Assembler::replaceWithBkpt): Renamed replaceWithBrk to replaceWithBkpt.
        (JSC::ARM64Assembler::replaceWithBrk): Deleted.
        * assembler/ARMAssembler.h:
        (JSC::ARMAssembler::replaceWithBkpt): Renamed replaceWithBrk to replaceWithBkpt.
        (JSC::ARMAssembler::replaceWithBrk): Deleted.
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::replaceWithBreakpoint):

2017-03-10  Alex Christensen  <achristensen@webkit.org>

        Win64 build fix.

        * b3/B3FenceValue.h:
        * b3/B3Value.h:
        Putting JS_EXPORT_PRIVATE on member functions in classes that are declared with JS_EXPORT_PRIVATE
        doesn't accomplish anything except making Visual Studio mad.
        * b3/air/opcode_generator.rb:
        winnt.h has naming collisions with enum values from AirOpcode.h.
        For example, MemoryFence is #defined to be _mm_mfence, which is declared to be a function in emmintrin.h.
        RotateLeft32 is #defined to be _rotl, which is declared to be a function in <stdlib.h>
        A clean solution is just to put Opcode:: before the references to the opcode names to tell Visual Studio
        that it is referring to the enum value in AirOpcode.h and not the function declaration elsewhere.

2017-03-09  Ryan Haddad  <ryanhaddad@apple.com>

        Unreviewed, rolling out r213695.

        This change broke the Windows build.

        Reverted changeset:

        "Implement a StackTrace utility object that can capture stack
        traces for debugging."
        https://bugs.webkit.org/show_bug.cgi?id=169454
        http://trac.webkit.org/changeset/213695

2017-03-09  Caio Lima  <ticaiolima@gmail.com>

        [ESnext] Implement Object Rest - Implementing Object Rest Destructuring
        https://bugs.webkit.org/show_bug.cgi?id=167962

        Reviewed by Keith Miller.

        Object Rest/Spread Destructing proposal is in stage 3[1] and this
        Patch is a prototype implementation of it. A simple change over the
        parser was necessary to support the new '...' token on Object Pattern
        destruction rule. In the bytecode generator side, We changed the
        bytecode generated on ObjectPatternNode::bindValue to store in an
        array identifiers of already destructed properties, following spec draft
        section[2], and then pass it as excludedNames to CopyDataProperties.
        The rest destruction the calls copyDataProperties to perform the
        copy of rest properties in rhs.

        We also implemented CopyDataProperties as private JS global operation
        on builtins/GlobalOperations.js following it's specification on [3].
        It is implemented using Set object to verify if a property is on
        excludedNames to keep this algorithm with O(n + m) complexity, where n
        = number of source's own properties and m = excludedNames.length. 

        As a requirement to use JSSets as constants, a change in
        CodeBlock::create API was necessary, because JSSet creation can throws OOM
        exception. Now, CodeBlock::finishCreation returns ```false``` if an
        execption is throwed by
        CodeBlock::setConstantIdentifierSetRegisters and then we return
        nullptr to ScriptExecutable::newCodeBlockFor. It is responsible to
        check if CodeBlock was constructed properly and then, throw OOM
        exception to the correct scope.

        [1] - https://github.com/sebmarkbage/ecmascript-rest-spread
        [2] - http://sebmarkbage.github.io/ecmascript-rest-spread/#Rest-RuntimeSemantics-PropertyDestructuringAssignmentEvaluation
        [3] - http://sebmarkbage.github.io/ecmascript-rest-spread/#AbstractOperations-CopyDataProperties

        * builtins/BuiltinNames.h:
        * builtins/GlobalOperations.js:
        (globalPrivate.copyDataProperties):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::setConstantIdentifierSetRegisters):
        * bytecode/CodeBlock.h:
        * bytecode/EvalCodeBlock.h:
        (JSC::EvalCodeBlock::create):
        * bytecode/FunctionCodeBlock.h:
        (JSC::FunctionCodeBlock::create):
        * bytecode/ModuleProgramCodeBlock.h:
        (JSC::ModuleProgramCodeBlock::create):
        * bytecode/ProgramCodeBlock.h:
        (JSC::ProgramCodeBlock::create):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::addSetConstant):
        (JSC::UnlinkedCodeBlock::constantIdentifierSets):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitLoad):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ObjectPatternNode::bindValue):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::appendObjectPatternEntry):
        (JSC::ASTBuilder::appendObjectPatternRestEntry):
        (JSC::ASTBuilder::setContainsObjectRestElement):
        * parser/Nodes.h:
        (JSC::ObjectPatternNode::appendEntry):
        (JSC::ObjectPatternNode::setContainsRestElement):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseDestructuringPattern):
        (JSC::Parser<LexerType>::parseProperty):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::operatorStackPop):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::privateToObject):
        * runtime/JSGlobalObjectFunctions.h:
        * runtime/ScriptExecutable.cpp:
        (JSC::ScriptExecutable::newCodeBlockFor):

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

        Implement a StackTrace utility object that can capture stack traces for debugging.
        https://bugs.webkit.org/show_bug.cgi?id=169454

        Reviewed by Michael Saboff.

        The underlying implementation is hoisted right out of Assertions.cpp from the
        implementations of WTFPrintBacktrace().

        The reason we need this StackTrace object is because during heap debugging, we
        sometimes want to capture the stack trace that allocated the objects of interest.
        Dumping the stack trace directly to stdout (using WTFReportBacktrace()) may
        perturb the execution profile sufficiently that an issue may not reproduce,
        while alternatively, just capturing the stack trace and deferring printing it
        till we actually need it later perturbs the execution profile less.

        In addition, just capturing the stack traces (instead of printing them
        immediately at each capture site) allows us to avoid polluting stdout with tons
        of stack traces that may be irrelevant.

        For now, we only capture the native stack trace.  We'll leave capturing and
        integrating the JS stack trace as an exercise for the future if we need it then.

        Here's an example of how to use this StackTrace utility:

            // Capture a stack trace of the top 10 frames.
            std::unique_ptr<StackTrace> trace(StackTrace::captureStackTrace(10));
            // Print the trace.
            dataLog(*trace);

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * tools/StackTrace.cpp: Added.
        (JSC::StackTrace::instanceSize):
        (JSC::StackTrace::captureStackTrace):
        (JSC::StackTrace::dump):
        * tools/StackTrace.h: Added.
        (JSC::StackTrace::StackTrace):
        (JSC::StackTrace::size):

2017-03-09  Keith Miller  <keith_miller@apple.com>

        WebAssembly: Enable fast memory for WK2
        https://bugs.webkit.org/show_bug.cgi?id=169437

        Reviewed by Tim Horton.

        * JavaScriptCore.xcodeproj/project.pbxproj:

2017-03-09  Matt Baker  <mattbaker@apple.com>

        Web Inspector: Add XHR breakpoints UI
        https://bugs.webkit.org/show_bug.cgi?id=168763
        <rdar://problem/30952439>

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/DOMDebugger.json:
        Added clarifying comments to command descriptions.

2017-03-09  Michael Saboff  <msaboff@apple.com>

        Add plumbing to WebProcess to enable JavaScriptCore configuration and logging
        https://bugs.webkit.org/show_bug.cgi?id=169387

        Reviewed by Filip Pizlo.

        Added a helper function, processConfigFile(), to process configuration file.
        Changed jsc.cpp to use that function in lieu of processing the config file
        manually.

        * JavaScriptCore.xcodeproj/project.pbxproj: Made ConfigFile.h a private header file.
        * jsc.cpp:
        (jscmain):
        * runtime/ConfigFile.cpp:
        (JSC::processConfigFile):
        * runtime/ConfigFile.h:

2017-03-09  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Show HTTP protocol version and other Network Load Metrics (IP Address, Priority, Connection ID)
        https://bugs.webkit.org/show_bug.cgi?id=29687
        <rdar://problem/19281586>

        Reviewed by Matt Baker and Brian Burg.

        * inspector/protocol/Network.json:
        Add metrics object with optional properties to loadingFinished event.

2017-03-09  Youenn Fablet  <youenn@apple.com>

        Minimal build is broken
        https://bugs.webkit.org/show_bug.cgi?id=169416

        Reviewed by Chris Dumez.

        Since we now have some JS built-ins that are not tied to a compilation flag, we can remove compilation guards around m_vm.
        We could probably remove m_vm by ensuring m_jsDOMBindingInternals appear first but this might break very easily.

        * Scripts/builtins/builtins_generate_internals_wrapper_header.py:
        (generate_members):
        * Scripts/builtins/builtins_generate_internals_wrapper_implementation.py:
        (BuiltinsInternalsWrapperImplementationGenerator.generate_constructor):
        * Scripts/tests/builtins/expected/WebCoreJSBuiltins.h-result:

2017-03-09  Daniel Bates  <dabates@apple.com>

        Guard Credential Management implementation behind a runtime enabled feature flag
        https://bugs.webkit.org/show_bug.cgi?id=169364
        <rdar://problem/30957425>

        Reviewed by Brent Fulgham.

        Add common identifiers for Credential, PasswordCredential, and SiteBoundCredential that are
        needed to guard these interfaces behind a runtime enabled feature flag.

        * runtime/CommonIdentifiers.h:

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

        Refactoring some HeapVerifier code.
        https://bugs.webkit.org/show_bug.cgi?id=169443

        Reviewed by Filip Pizlo.

        Renamed LiveObjectData to CellProfile.
        Renamed LiveObjectList to CellList.
        Moved CellProfile.*, CellList.*, and HeapVerifier.* from the heap folder to the tools folder.
        Updated the HeapVerifier to handle JSCells instead of just JSObjects.

        This is in preparation for subsequent patches to fix up the HeapVerifier for service again.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/Heap.cpp:
        (JSC::Heap::runBeginPhase):
        (JSC::Heap::runEndPhase):
        * heap/HeapVerifier.cpp: Removed.
        * heap/HeapVerifier.h: Removed.
        * heap/LiveObjectData.h: Removed.
        * heap/LiveObjectList.cpp: Removed.
        * heap/LiveObjectList.h: Removed.
        * tools/CellList.cpp: Copied from Source/JavaScriptCore/heap/LiveObjectList.cpp.
        (JSC::CellList::findCell):
        (JSC::LiveObjectList::findObject): Deleted.
        * tools/CellList.h: Copied from Source/JavaScriptCore/heap/LiveObjectList.h.
        (JSC::CellList::CellList):
        (JSC::CellList::reset):
        (JSC::LiveObjectList::LiveObjectList): Deleted.
        (JSC::LiveObjectList::reset): Deleted.
        * tools/CellProfile.h: Copied from Source/JavaScriptCore/heap/LiveObjectData.h.
        (JSC::CellProfile::CellProfile):
        (JSC::LiveObjectData::LiveObjectData): Deleted.
        * tools/HeapVerifier.cpp: Copied from Source/JavaScriptCore/heap/HeapVerifier.cpp.
        (JSC::GatherCellFunctor::GatherCellFunctor):
        (JSC::GatherCellFunctor::visit):
        (JSC::GatherCellFunctor::operator()):
        (JSC::HeapVerifier::gatherLiveCells):
        (JSC::HeapVerifier::cellListForGathering):
        (JSC::trimDeadCellsFromList):
        (JSC::HeapVerifier::trimDeadCells):
        (JSC::HeapVerifier::verifyButterflyIsInStorageSpace):
        (JSC::HeapVerifier::reportCell):
        (JSC::HeapVerifier::checkIfRecorded):
        (JSC::GatherLiveObjFunctor::GatherLiveObjFunctor): Deleted.
        (JSC::GatherLiveObjFunctor::visit): Deleted.
        (JSC::GatherLiveObjFunctor::operator()): Deleted.
        (JSC::HeapVerifier::gatherLiveObjects): Deleted.
        (JSC::HeapVerifier::liveObjectListForGathering): Deleted.
        (JSC::trimDeadObjectsFromList): Deleted.
        (JSC::HeapVerifier::trimDeadObjects): Deleted.
        (JSC::HeapVerifier::reportObject): Deleted.
        * tools/HeapVerifier.h: Copied from Source/JavaScriptCore/heap/HeapVerifier.h.

2017-03-09  Anders Carlsson  <andersca@apple.com>

        Add delegate support to WebCore
        https://bugs.webkit.org/show_bug.cgi?id=169427
        Part of rdar://problem/28880714.

        Reviewed by Geoffrey Garen.

        * Configurations/FeatureDefines.xcconfig:
        Add feature define.

2017-03-09  Nikita Vasilyev  <nvasilyev@apple.com>

        Web Inspector: Show individual messages in the content pane for a WebSocket
        https://bugs.webkit.org/show_bug.cgi?id=169011

        Reviewed by Joseph Pecoraro.

        Add walltime parameter and correct the description of Timestamp type.

        * inspector/protocol/Network.json:

2017-03-09  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix weak external symbol error.

        * heap/SlotVisitor.h:

2017-03-09  Filip Pizlo  <fpizlo@apple.com>

        std::isnan/isinf should work with WTF time classes
        https://bugs.webkit.org/show_bug.cgi?id=164991

        Reviewed by Darin Adler.
        
        Changes AtomicsObject to use std::isnan() instead of operator== to detect NaN.

        * runtime/AtomicsObject.cpp:
        (JSC::atomicsFuncWait):

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

        Use const AbstractLocker& (instead of const LockHolder&) in more places.
        https://bugs.webkit.org/show_bug.cgi?id=169424

        Reviewed by Filip Pizlo.

        * heap/CodeBlockSet.cpp:
        (JSC::CodeBlockSet::promoteYoungCodeBlocks):
        * heap/CodeBlockSet.h:
        * heap/CodeBlockSetInlines.h:
        (JSC::CodeBlockSet::mark):
        * heap/ConservativeRoots.cpp:
        (JSC::CompositeMarkHook::CompositeMarkHook):
        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::tryCopyOtherThreadStacks):
        * heap/MachineStackMarker.h:
        * profiler/ProfilerDatabase.cpp:
        (JSC::Profiler::Database::ensureBytecodesFor):
        * profiler/ProfilerDatabase.h:
        * runtime/SamplingProfiler.cpp:
        (JSC::FrameWalker::FrameWalker):
        (JSC::CFrameWalker::CFrameWalker):
        (JSC::SamplingProfiler::createThreadIfNecessary):
        (JSC::SamplingProfiler::takeSample):
        (JSC::SamplingProfiler::start):
        (JSC::SamplingProfiler::pause):
        (JSC::SamplingProfiler::noticeCurrentThreadAsJSCExecutionThread):
        (JSC::SamplingProfiler::clearData):
        (JSC::SamplingProfiler::releaseStackTraces):
        * runtime/SamplingProfiler.h:
        (JSC::SamplingProfiler::setStopWatch):
        * wasm/WasmMemory.cpp:
        (JSC::Wasm::availableFastMemories):
        (JSC::Wasm::activeFastMemories):
        (JSC::Wasm::viewActiveFastMemories):
        * wasm/WasmMemory.h:

2017-03-09  Saam Barati  <sbarati@apple.com>

        WebAssembly: Make the Unity AngryBots demo run
        https://bugs.webkit.org/show_bug.cgi?id=169268

        Reviewed by Keith Miller.

        This patch fixes three bugs:
        1. The WasmBinding code for making a JS call was off
        by 1 in its stack layout code.
        2. The WasmBinding code had a "<" comparison instead
        of a ">=" comparison. This would cause us to calculate
        the wrong frame pointer offset.
        3. The code to reload wasm state inside B3IRGenerator didn't
        properly represent its effects.

        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::restoreWebAssemblyGlobalState):
        (JSC::Wasm::parseAndCompile):
        * wasm/WasmBinding.cpp:
        (JSC::Wasm::wasmToJs):
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::WebAssemblyInstanceConstructor::createInstance):

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

        Make the VM Traps mechanism non-polling for the DFG and FTL.
        https://bugs.webkit.org/show_bug.cgi?id=168920
        <rdar://problem/30738588>

        Reviewed by Filip Pizlo.

        1. Added a ENABLE(SIGNAL_BASED_VM_TRAPS) configuration in Platform.h.
           This is currently only enabled for OS(DARWIN) and ENABLE(JIT). 
        2. Added assembler functions for overwriting an instruction with a breakpoint.
        3. Added a new JettisonDueToVMTraps jettison reason.
        4. Added CodeBlock and DFG::CommonData utility functions for over-writing
           invalidation points with breakpoint instructions.
        5. The BytecodeGenerator now emits the op_check_traps bytecode unconditionally.
        6. Remove the JSC_alwaysCheckTraps option because of (4) above.
           For ports that don't ENABLE(SIGNAL_BASED_VM_TRAPS), we'll force
           Options::usePollingTraps() to always be true.  This makes the VMTraps
           implementation fall back to using polling based traps only.

        7. Make VMTraps support signal based traps.

        Some design and implementation details of signal based VM traps:

        - The implementation makes use of 2 signal handlers for SIGUSR1 and SIGTRAP.

        - VMTraps::fireTrap() will set the flag for the requested trap and instantiate
          a SignalSender.  The SignalSender will send SIGUSR1 to the mutator thread that
          we want to trap, and check for the occurence of one of the following events:

          a. VMTraps::handleTraps() has been called for the requested trap, or

          b. the VM is inactive and is no longer executing any JS code.  We determine
             this to be the case if the thread no longer owns the JSLock and the VM's
             entryScope is null.

             Note: the thread can relinquish the JSLock while the VM's entryScope is not
             null.  This happens when the thread calls JSLock::dropAllLocks() before
             calling a host function that may block on IO (or whatever).  For our purpose,
             this counts as the VM still running JS code, and VM::fireTrap() will still
             be waiting.

          If the SignalSender does not see either of these events, it will sleep for a
          while and then re-send SIGUSR1 and check for the events again.  When it sees
          one of these events, it will consider the mutator to have received the trap
          request.

        - The SIGUSR1 handler will try to insert breakpoints at the invalidation points
          in the DFG/FTL codeBlock at the top of the stack.  This allows the mutator
          thread to break (with a SIGTRAP) exactly at an invalidation point, where it's
          safe to jettison the codeBlock.

          Note: we cannot have the requester thread (that called VMTraps::fireTrap())
          insert the breakpoint instructions itself.  This is because we need the
          register state of the the mutator thread (that we want to trap in) in order to
          find the codeBlocks that we wish to insert the breakpoints in.  Currently,
          we don't have a generic way for the requester thread to get the register state
          of another thread.

        - The SIGTRAP handler will check to see if it is trapping on a breakpoint at an
          invalidation point.  If so, it will jettison the codeBlock and adjust the PC
          to re-execute the invalidation OSR exit off-ramp.  After the OSR exit, the
          baseline JIT code will eventually reach an op_check_traps and call
          VMTraps::handleTraps().

          If the handler is not trapping at an invalidation point, then it must be
          observing an assertion failure (which also uses the breakpoint instruction).
          In this case, the handler will defer to the default SIGTRAP handler and crash.

        - The reason we need the SignalSender is because SignalSender::send() is called
          from another thread in a loop, so that VMTraps::fireTrap() can return sooner.
          send() needs to make use of the VM pointer, and it is not guaranteed that the
          VM will outlive the thread.  SignalSender provides the mechanism by which we
          can nullify the VM pointer when the VM dies so that the thread does not
          continue to use it.

        * assembler/ARM64Assembler.h:
        (JSC::ARM64Assembler::replaceWithBrk):
        * assembler/ARMAssembler.h:
        (JSC::ARMAssembler::replaceWithBrk):
        * assembler/ARMv7Assembler.h:
        (JSC::ARMv7Assembler::replaceWithBkpt):
        * assembler/MIPSAssembler.h:
        (JSC::MIPSAssembler::replaceWithBkpt):
        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::replaceWithJump):
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::replaceWithBreakpoint):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::replaceWithBreakpoint):
        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::replaceWithJump):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::replaceWithBreakpoint):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::replaceWithInt3):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::jettison):
        (JSC::CodeBlock::hasInstalledVMTrapBreakpoints):
        (JSC::CodeBlock::installVMTrapBreakpoints):
        * bytecode/CodeBlock.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitCheckTraps):
        * dfg/DFGCommonData.cpp:
        (JSC::DFG::CommonData::installVMTrapBreakpoints):
        (JSC::DFG::CommonData::isVMTrapBreakpoint):
        * dfg/DFGCommonData.h:
        (JSC::DFG::CommonData::hasInstalledVMTrapsBreakpoints):
        * dfg/DFGJumpReplacement.cpp:
        (JSC::DFG::JumpReplacement::installVMTrapBreakpoint):
        * dfg/DFGJumpReplacement.h:
        (JSC::DFG::JumpReplacement::dataLocation):
        * dfg/DFGNodeType.h:
        * heap/CodeBlockSet.cpp:
        (JSC::CodeBlockSet::contains):
        * heap/CodeBlockSet.h:
        * heap/CodeBlockSetInlines.h:
        (JSC::CodeBlockSet::iterate):
        * heap/Heap.cpp:
        (JSC::Heap::forEachCodeBlockIgnoringJITPlansImpl):
        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::forEachCodeBlockIgnoringJITPlans):
        * heap/MachineStackMarker.h:
        (JSC::MachineThreads::threadsListHead):
        * jit/ExecutableAllocator.cpp:
        (JSC::ExecutableAllocator::isValidExecutableMemory):
        * jit/ExecutableAllocator.h:
        * profiler/ProfilerJettisonReason.cpp:
        (WTF::printInternal):
        * profiler/ProfilerJettisonReason.h:
        * runtime/JSLock.cpp:
        (JSC::JSLock::didAcquireLock):
        * runtime/Options.cpp:
        (JSC::overrideDefaults):
        * runtime/Options.h:
        * runtime/PlatformThread.h:
        (JSC::platformThreadSignal):
        * runtime/VM.cpp:
        (JSC::VM::~VM):
        (JSC::VM::ensureWatchdog):
        (JSC::VM::handleTraps): Deleted.
        (JSC::VM::setNeedAsynchronousTerminationSupport): Deleted.
        * runtime/VM.h:
        (JSC::VM::ownerThread):
        (JSC::VM::traps):
        (JSC::VM::handleTraps):
        (JSC::VM::needTrapHandling):
        (JSC::VM::needAsynchronousTerminationSupport): Deleted.
        * runtime/VMTraps.cpp:
        (JSC::VMTraps::vm):
        (JSC::SignalContext::SignalContext):
        (JSC::SignalContext::adjustPCToPointToTrappingInstruction):
        (JSC::vmIsInactive):
        (JSC::findActiveVMAndStackBounds):
        (JSC::handleSigusr1):
        (JSC::handleSigtrap):
        (JSC::installSignalHandlers):
        (JSC::sanitizedTopCallFrame):
        (JSC::isSaneFrame):
        (JSC::VMTraps::tryInstallTrapBreakpoints):
        (JSC::VMTraps::invalidateCodeBlocksOnStack):
        (JSC::VMTraps::VMTraps):
        (JSC::VMTraps::willDestroyVM):
        (JSC::VMTraps::addSignalSender):
        (JSC::VMTraps::removeSignalSender):
        (JSC::VMTraps::SignalSender::willDestroyVM):
        (JSC::VMTraps::SignalSender::send):
        (JSC::VMTraps::fireTrap):
        (JSC::VMTraps::handleTraps):
        * runtime/VMTraps.h:
        (JSC::VMTraps::~VMTraps):
        (JSC::VMTraps::needTrapHandling):
        (JSC::VMTraps::notifyGrabAllLocks):
        (JSC::VMTraps::SignalSender::SignalSender):
        (JSC::VMTraps::invalidateCodeBlocksOnStack):
        * tools/VMInspector.cpp:
        * tools/VMInspector.h:
        (JSC::VMInspector::getLock):
        (JSC::VMInspector::iterate):

2017-03-09  Filip Pizlo  <fpizlo@apple.com>

        WebKit: JSC: JSObject::ensureLength doesn't check if ensureLengthSlow failed
        https://bugs.webkit.org/show_bug.cgi?id=169215

        Reviewed by Mark Lam.
        
        This doesn't have a test because it would be a very complicated test.

        * runtime/JSObject.h:
        (JSC::JSObject::ensureLength): If ensureLengthSlow returns false, we need to return false.

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

        WTF should make it super easy to do ARM concurrency tricks
        https://bugs.webkit.org/show_bug.cgi?id=169300

        Reviewed by Mark Lam.
        
        This changes a bunch of GC hot paths to use new concurrency APIs that lead to optimal
        code on both x86 (fully leverage TSO, transactions become CAS loops) and ARM (use
        dependency chains for fencing, transactions become LL/SC loops). While inspecting the
        machine code, I found other opportunities for improvement, like inlining the "am I
        marked" part of the marking functions.

        * heap/Heap.cpp:
        (JSC::Heap::setGCDidJIT):
        * heap/HeapInlines.h:
        (JSC::Heap::testAndSetMarked):
        * heap/LargeAllocation.h:
        (JSC::LargeAllocation::isMarked):
        (JSC::LargeAllocation::isMarkedConcurrently):
        (JSC::LargeAllocation::aboutToMark):
        (JSC::LargeAllocation::testAndSetMarked):
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::areMarksStaleWithDependency):
        (JSC::MarkedBlock::aboutToMark):
        (JSC::MarkedBlock::isMarkedConcurrently):
        (JSC::MarkedBlock::isMarked):
        (JSC::MarkedBlock::testAndSetMarked):
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::appendSlow):
        (JSC::SlotVisitor::appendHiddenSlow):
        (JSC::SlotVisitor::appendHiddenSlowImpl):
        (JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
        (JSC::SlotVisitor::appendUnbarriered): Deleted.
        (JSC::SlotVisitor::appendHidden): Deleted.
        * heap/SlotVisitor.h:
        * heap/SlotVisitorInlines.h:
        (JSC::SlotVisitor::appendUnbarriered):
        (JSC::SlotVisitor::appendHidden):
        (JSC::SlotVisitor::append):
        (JSC::SlotVisitor::appendValues):
        (JSC::SlotVisitor::appendValuesHidden):
        * runtime/CustomGetterSetter.cpp:
        * runtime/JSObject.cpp:
        (JSC::JSObject::visitButterflyImpl):
        * runtime/JSObject.h:

2017-03-08  Yusuke Suzuki  <utatane.tea@gmail.com>

        [GTK] JSC test stress/arity-check-ftl-throw.js.ftl-no-cjit-validate-sampling-profiler crashing on GTK bot
        https://bugs.webkit.org/show_bug.cgi?id=160124

        Reviewed by Mark Lam.

        When performing CallVarargs, we will copy values to the stack.
        Before actually copying values, we need to adjust the stackPointerRegister
        to ensure copied values are in the allocated stack area.
        If we do not that, OS can break the values that is stored beyond the stack
        pointer. For example, signal stack can be constructed on these area, and
        breaks values.

        This patch fixes the crash in stress/spread-forward-call-varargs-stack-overflow.js
        in Linux port. Since Linux ports use signal to suspend and resume threads,
        signal handler is frequently called when enabling sampling profiler. Thus this
        crash occurs.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
        * jit/SetupVarargsFrame.cpp:
        (JSC::emitSetupVarargsFrameFastCase):
        * jit/SetupVarargsFrame.h:

2017-03-08  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Should be able to see where Resources came from (Memory Cache, Disk Cache)
        https://bugs.webkit.org/show_bug.cgi?id=164892
        <rdar://problem/29320562>

        Reviewed by Brian Burg.

        * inspector/protocol/Network.json:
        Replace "fromDiskCache" property with "source" property which includes
        more complete information about the source of this response (network,
        memory cache, disk cache, or unknown).

        * inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
        (_generate_class_for_object_declaration):
        * inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py:
        (CppProtocolTypesImplementationGenerator._generate_open_field_names):
        * inspector/scripts/codegen/generator.py:
        (Generator):
        (Generator.open_fields):
        To avoid conflicts between the Inspector::Protocol::Network::Response::Source
        enum and open accessor string symbol that would have the same name, only generate
        a specific list of open accessor strings. This reduces the list of exported
        symbols from all properties to just the ones that are needed. This can be
        cleaned up later if needed.

        * inspector/scripts/tests/generic/expected/type-with-open-parameters.json-result: Added.
        * inspector/scripts/tests/generic/type-with-open-parameters.json: Added.
        Test for open accessors generation.

2017-03-08  Keith Miller  <keith_miller@apple.com>

        WebAssembly: Make OOB for fast memory do an extra safety check by ensuring the faulting address is in the range we allocated for fast memory
        https://bugs.webkit.org/show_bug.cgi?id=169290

        Reviewed by Saam Barati.

        This patch adds an extra sanity check by ensuring that the the memory address we faulting trying to load is in range
        of some wasm fast memory.

        * wasm/WasmFaultSignalHandler.cpp:
        (JSC::Wasm::trapHandler):
        (JSC::Wasm::enableFastMemory):
        * wasm/WasmMemory.cpp:
        (JSC::Wasm::activeFastMemories):
        (JSC::Wasm::viewActiveFastMemories):
        (JSC::Wasm::tryGetFastMemory):
        (JSC::Wasm::releaseFastMemory):
        * wasm/WasmMemory.h:

2017-03-07  Dean Jackson  <dino@apple.com>

        Some platforms won't be able to create a GPUDevice
        https://bugs.webkit.org/show_bug.cgi?id=169314
        <rdar://problems/30907521>

        Reviewed by Jon Lee.

        Disable WEB_GPU on the iOS Simulator.

        * Configurations/FeatureDefines.xcconfig:

2017-03-06  Saam Barati  <sbarati@apple.com>

        WebAssembly: Implement the WebAssembly.instantiate API
        https://bugs.webkit.org/show_bug.cgi?id=165982
        <rdar://problem/29760110>

        Reviewed by Keith Miller.

        This patch is a straight forward implementation of the WebAssembly.instantiate
        API: https://github.com/WebAssembly/design/blob/master/JS.md#webassemblyinstantiate
        
        I implemented the API in a synchronous manner. We should make it
        asynchronous: https://bugs.webkit.org/show_bug.cgi?id=169187

        * wasm/JSWebAssembly.cpp:
        (JSC::webAssemblyCompileFunc):
        (JSC::webAssemblyInstantiateFunc):
        (JSC::JSWebAssembly::finishCreation):
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::constructJSWebAssemblyInstance):
        (JSC::WebAssemblyInstanceConstructor::createInstance):
        * wasm/js/WebAssemblyInstanceConstructor.h:
        * wasm/js/WebAssemblyModuleConstructor.cpp:
        (JSC::constructJSWebAssemblyModule):
        (JSC::WebAssemblyModuleConstructor::createModule):
        * wasm/js/WebAssemblyModuleConstructor.h:

2017-03-06  Michael Saboff  <msaboff@apple.com>

        Take advantage of fast permissions switching of JIT memory for devices that support it
        https://bugs.webkit.org/show_bug.cgi?id=169155

        Reviewed by Saam Barati.

        Start using the os_thread_self_restrict_rwx_to_XX() SPIs when available to
        control access to JIT memory.

        Had to update the Xcode config files to handle various build variations of
        public and internal SDKs.

        * Configurations/Base.xcconfig:
        * Configurations/FeatureDefines.xcconfig:
        * jit/ExecutableAllocator.cpp:
        (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator):
        (JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps):
        * jit/ExecutableAllocator.h:
        (JSC::performJITMemcpy):

2017-03-06  Csaba Osztrogonác  <ossy@webkit.org>

        REGRESSION(r212778): It made 400 tests crash on AArch64 Linux
        https://bugs.webkit.org/show_bug.cgi?id=168502

        Reviewed by Filip Pizlo.

        * heap/RegisterState.h: Use setjmp code path on AArch64 Linux too to fix crashes.

2017-03-06  Caio Lima  <ticaiolima@gmail.com>

        op_get_by_id_with_this should use inline caching
        https://bugs.webkit.org/show_bug.cgi?id=162124

        Reviewed by Saam Barati.

        This patch is enabling inline cache for op_get_by_id_with_this in all
        tiers. It means that operations using ```super.member``` are going to
        be able to be optimized by PIC. To enable it, we introduced a new
        member of StructureStubInfo.patch named thisGPR, created a new class
        to manage the IC named JITGetByIdWithThisGenerator and changed
        PolymorphicAccess.regenerate that uses StructureStubInfo.patch.thisGPR
        to decide the correct this value on inline caches.
        With inline cached enabled, ```super.member``` are ~4.5x faster,
        according microbenchmarks.

        * bytecode/AccessCase.cpp:
        (JSC::AccessCase::generateImpl):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::PolymorphicAccess::regenerate):
        * bytecode/PolymorphicAccess.h:
        * bytecode/StructureStubInfo.cpp:
        (JSC::StructureStubInfo::reset):
        * bytecode/StructureStubInfo.h:
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::link):
        * dfg/DFGJITCompiler.h:
        (JSC::DFG::JITCompiler::addGetByIdWithThis):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileIn):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetByIdWithThis):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetByIdWithThis):
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByIdWithThis):
        (JSC::FTL::DFG::LowerDFGToB3::compileIn):
        (JSC::FTL::DFG::LowerDFGToB3::getByIdWithThis):
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgumentsWithExecState):
        * jit/ICStats.h:
        * jit/JIT.cpp:
        (JSC::JIT::JIT):
        (JSC::JIT::privateCompileSlowCases):
        (JSC::JIT::link):
        * jit/JIT.h:
        * jit/JITInlineCacheGenerator.cpp:
        (JSC::JITByIdGenerator::JITByIdGenerator):
        (JSC::JITGetByIdWithThisGenerator::JITGetByIdWithThisGenerator):
        (JSC::JITGetByIdWithThisGenerator::generateFastPath):
        * jit/JITInlineCacheGenerator.h:
        (JSC::JITGetByIdWithThisGenerator::JITGetByIdWithThisGenerator):
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_get_by_id_with_this):
        (JSC::JIT::emitSlow_op_get_by_id_with_this):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_get_by_id_with_this):
        (JSC::JIT::emitSlow_op_get_by_id_with_this):
        * jit/Repatch.cpp:
        (JSC::appropriateOptimizingGetByIdFunction):
        (JSC::appropriateGenericGetByIdFunction):
        (JSC::tryCacheGetByID):
        * jit/Repatch.h:
        * jsc.cpp:
        (WTF::CustomGetter::getOwnPropertySlot):
        (WTF::CustomGetter::customGetterAcessor):

2017-03-06  Saam Barati  <sbarati@apple.com>

        WebAssembly: implement init_expr for Element
        https://bugs.webkit.org/show_bug.cgi?id=165888
        <rdar://problem/29760199>

        Reviewed by Keith Miller.

        This patch fixes a few bugs. The main change is allowing init_expr
        for the Element's offset. To do this, I had to fix a couple of
        other bugs:
        
        - I removed our invalid early module-parse-time invalidation
        of out of bound Element sections. This is not in the spec because
        it can't be validated in the general case when the offset is a
        get_global.
        
        - Our get_global validation inside our init_expr parsing code was simply wrong.
        It thought that the index operand to get_global went into the pool of imports,
        but it does not. It indexes into the pool of globals. I changed the code to
        refer to the global pool instead.

        * wasm/WasmFormat.h:
        (JSC::Wasm::Element::Element):
        * wasm/WasmModuleParser.cpp:
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::evaluate):

2017-03-06  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Allow indexed module namespace object fields
        https://bugs.webkit.org/show_bug.cgi?id=168870

        Reviewed by Saam Barati.

        While JS modules cannot expose any indexed bindings,
        Wasm modules can expose them. However, module namespace
        object currently does not support indexed properties.
        This patch allows module namespace objects to offer
        indexed binding accesses.

        * runtime/JSModuleNamespaceObject.cpp:
        (JSC::JSModuleNamespaceObject::getOwnPropertySlotCommon):
        (JSC::JSModuleNamespaceObject::getOwnPropertySlot):
        (JSC::JSModuleNamespaceObject::getOwnPropertySlotByIndex):
        * runtime/JSModuleNamespaceObject.h:

2017-03-06  Yusuke Suzuki  <utatane.tea@gmail.com>

        Null pointer crash when loading module with unresolved import also as a script file
        https://bugs.webkit.org/show_bug.cgi?id=168971

        Reviewed by Saam Barati.

        If linking throws an error, this error should be re-thrown
        when requesting the same module.

        * builtins/ModuleLoaderPrototype.js:
        (globalPrivate.newRegistryEntry):
        * runtime/JSModuleRecord.cpp:
        (JSC::JSModuleRecord::link):

2017-03-06  Yusuke Suzuki  <utatane.tea@gmail.com>

        [GTK][JSCOnly] Enable WebAssembly on Linux environment
        https://bugs.webkit.org/show_bug.cgi?id=164032

        Reviewed by Michael Catanzaro.

        This patch enables WebAssembly on JSCOnly and GTK ports.
        Basically, almost all the WASM code is portable to Linux.
        One platform-dependent part is faster memory load using SIGBUS
        signal handler. This patch ports this part to Linux.

        * CMakeLists.txt:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * wasm/WasmFaultSignalHandler.cpp:
        (JSC::Wasm::trapHandler):
        (JSC::Wasm::enableFastMemory):

2017-03-06  Daniel Ehrenberg  <littledan@igalia.com>

        Currency digits calculation in Intl.NumberFormat should call out to ICU
        https://bugs.webkit.org/show_bug.cgi?id=169182

        Reviewed by Yusuke Suzuki.

        * runtime/IntlNumberFormat.cpp:
        (JSC::computeCurrencyDigits):
        (JSC::computeCurrencySortKey): Deleted.
        (JSC::extractCurrencySortKey): Deleted.

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

        [JSCOnly][GTK] Suppress warnings on return type in B3 and WASM
        https://bugs.webkit.org/show_bug.cgi?id=168869

        Reviewed by Keith Miller.

        * b3/B3Width.h:
        * wasm/WasmSections.h:

2017-03-04  Csaba Osztrogonác  <ossy@webkit.org>

        [ARM] Unreviewed buildfix after r213376.

        * assembler/ARMAssembler.h:
        (JSC::ARMAssembler::isBkpt): Typo fixed.

2017-03-03  Carlos Alberto Lopez Perez  <clopez@igalia.com>

        [JSC] build fix after r213399
        https://bugs.webkit.org/show_bug.cgi?id=169154

        Unreviewed.

        * runtime/ConfigFile.cpp: Include unistd.h since its where getcwd() is defined.

2017-03-03  Dean Jackson  <dino@apple.com>

        Add WebGPU compile flag and experimental feature flag
        https://bugs.webkit.org/show_bug.cgi?id=169161
        <rdar://problem/30846689>

        Reviewed by Tim Horton.

        Add ENABLE_WEBGPU, an experimental feature flag, a RuntimeEnabledFeature,
        and an InternalSetting.

        * Configurations/FeatureDefines.xcconfig:

2017-03-03  Michael Saboff  <msaboff@apple.com>

        Add support for relative pathnames to JSC config files
        https://bugs.webkit.org/show_bug.cgi?id=169154

        Reviewed by Saam Barati.

        If the config file is a relative path, prepend the current working directory.
        After canonicalizing the config file path, we extract its directory path and
        use that for the directory for a relative log pathname.

        * runtime/ConfigFile.cpp:
        (JSC::ConfigFile::ConfigFile):
        (JSC::ConfigFile::parse):
        (JSC::ConfigFile::canonicalizePaths):
        * runtime/ConfigFile.h:

2017-03-03  Michael Saboff  <msaboff@apple.com>

        Add load / store exclusive instruction group to ARM64 disassembler
        https://bugs.webkit.org/show_bug.cgi?id=169152

        Reviewed by Filip Pizlo.

        * disassembler/ARM64/A64DOpcode.cpp:
        (JSC::ARM64Disassembler::A64DOpcodeLoadStoreExclusive::format):
        * disassembler/ARM64/A64DOpcode.h:
        (JSC::ARM64Disassembler::A64DOpcodeLoadStoreExclusive::opName):
        (JSC::ARM64Disassembler::A64DOpcodeLoadStoreExclusive::rs):
        (JSC::ARM64Disassembler::A64DOpcodeLoadStoreExclusive::rt2):
        (JSC::ARM64Disassembler::A64DOpcodeLoadStoreExclusive::o0):
        (JSC::ARM64Disassembler::A64DOpcodeLoadStoreExclusive::o1):
        (JSC::ARM64Disassembler::A64DOpcodeLoadStoreExclusive::o2):
        (JSC::ARM64Disassembler::A64DOpcodeLoadStoreExclusive::loadBit):
        (JSC::ARM64Disassembler::A64DOpcodeLoadStoreExclusive::opNumber):
        (JSC::ARM64Disassembler::A64DOpcodeLoadStoreExclusive::isPairOp):

2017-03-03  Keith Miller  <keith_miller@apple.com>

        WASM should support faster loads.
        https://bugs.webkit.org/show_bug.cgi?id=162693

        Reviewed by Saam Barati.

        This patch adds support for WebAssembly using a 32-bit address
        space for memory (along with some extra space for offset
        overflow). With a 32-bit address space (we call them
        Signaling/fast memories), we reserve the virtual address space for
        2^32 + offset bytes of memory and only mark the usable section as
        read/write. If wasm code would read/write out of bounds we use a
        custom signal handler to catch the SIGBUS. The signal handler then
        checks if the faulting instruction is wasm code and tells the
        thread to resume executing from the wasm exception
        handler. Otherwise, the signal handler crashes the process, as
        usual.

        All of the allocations of these memories are managed by the
        Wasm::Memory class. In order to avoid TLB churn in the OS we cache
        old Signaling memories that are no longer in use. Since getting
        the wrong memory can cause recompiles, we try to reserve a memory
        for modules that do not import a memory. If a module does import a
        memory, we try to guess the type of memory we are going to get
        based on the last one allocated.

        This patch also changes how the wasm JS-api manages objects. Since
        we can compile different versions of code, this patch adds a new
        JSWebAssemblyCodeBlock class that holds all the information
        specific to running a module in a particular bounds checking
        mode. Additionally, the Wasm::Memory object is now a reference
        counted class that is shared between the JSWebAssemblyMemory
        object and the ArrayBuffer that also views it.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * jit/JITThunks.cpp:
        (JSC::JITThunks::existingCTIStub):
        * jit/JITThunks.h:
        * jsc.cpp:
        (jscmain):
        * runtime/Options.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        * wasm/JSWebAssemblyCodeBlock.h: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyModule.h.
        (JSC::JSWebAssemblyCodeBlock::create):
        (JSC::JSWebAssemblyCodeBlock::createStructure):
        (JSC::JSWebAssemblyCodeBlock::functionImportCount):
        (JSC::JSWebAssemblyCodeBlock::mode):
        (JSC::JSWebAssemblyCodeBlock::module):
        (JSC::JSWebAssemblyCodeBlock::jsEntrypointCalleeFromFunctionIndexSpace):
        (JSC::JSWebAssemblyCodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace):
        (JSC::JSWebAssemblyCodeBlock::setJSEntrypointCallee):
        (JSC::JSWebAssemblyCodeBlock::setWasmEntrypointCallee):
        (JSC::JSWebAssemblyCodeBlock::callees):
        (JSC::JSWebAssemblyCodeBlock::offsetOfCallees):
        (JSC::JSWebAssemblyCodeBlock::allocationSize):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        (JSC::Wasm::getMemoryBaseAndSize):
        (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
        (JSC::Wasm::B3IRGenerator::emitLoadOp):
        (JSC::Wasm::B3IRGenerator::emitStoreOp):
        * wasm/WasmCallingConvention.h:
        * wasm/WasmFaultSignalHandler.cpp: Added.
        (JSC::Wasm::trapHandler):
        (JSC::Wasm::registerCode):
        (JSC::Wasm::unregisterCode):
        (JSC::Wasm::fastMemoryEnabled):
        (JSC::Wasm::enableFastMemory):
        * wasm/WasmFaultSignalHandler.h: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyCallee.cpp.
        * wasm/WasmFormat.h:
        (JSC::Wasm::ModuleInformation::importFunctionCount):
        (JSC::Wasm::ModuleInformation::hasMemory): Deleted.
        * wasm/WasmMemory.cpp:
        (JSC::Wasm::mmapBytes):
        (JSC::Wasm::Memory::lastAllocatedMode):
        (JSC::Wasm::availableFastMemories):
        (JSC::Wasm::tryGetFastMemory):
        (JSC::Wasm::releaseFastMemory):
        (JSC::Wasm::Memory::Memory):
        (JSC::Wasm::Memory::createImpl):
        (JSC::Wasm::Memory::create):
        (JSC::Wasm::Memory::~Memory):
        (JSC::Wasm::Memory::grow):
        (JSC::Wasm::Memory::dump):
        (JSC::Wasm::Memory::makeString):
        * wasm/WasmMemory.h:
        (JSC::Wasm::Memory::operator bool):
        (JSC::Wasm::Memory::size):
        (JSC::Wasm::Memory::check):
        (JSC::Wasm::Memory::Memory): Deleted.
        (JSC::Wasm::Memory::offsetOfMemory): Deleted.
        (JSC::Wasm::Memory::offsetOfSize): Deleted.
        * wasm/WasmMemoryInformation.cpp:
        (JSC::Wasm::MemoryInformation::MemoryInformation):
        * wasm/WasmMemoryInformation.h:
        (JSC::Wasm::MemoryInformation::hasReservedMemory):
        (JSC::Wasm::MemoryInformation::takeReservedMemory):
        (JSC::Wasm::MemoryInformation::mode):
        * wasm/WasmModuleParser.cpp:
        * wasm/WasmModuleParser.h:
        (JSC::Wasm::ModuleParser::ModuleParser):
        * wasm/WasmPlan.cpp:
        (JSC::Wasm::Plan::parseAndValidateModule):
        (JSC::Wasm::Plan::run):
        * wasm/WasmPlan.h:
        (JSC::Wasm::Plan::mode):
        * wasm/js/JSWebAssemblyCallee.cpp:
        (JSC::JSWebAssemblyCallee::finishCreation):
        (JSC::JSWebAssemblyCallee::destroy):
        * wasm/js/JSWebAssemblyCodeBlock.cpp: Added.
        (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock):
        (JSC::JSWebAssemblyCodeBlock::destroy):
        (JSC::JSWebAssemblyCodeBlock::isSafeToRun):
        (JSC::JSWebAssemblyCodeBlock::visitChildren):
        (JSC::JSWebAssemblyCodeBlock::UnconditionalFinalizer::finalizeUnconditionally):
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::setMemory):
        (JSC::JSWebAssemblyInstance::finishCreation):
        (JSC::JSWebAssemblyInstance::visitChildren):
        * wasm/js/JSWebAssemblyInstance.h:
        (JSC::JSWebAssemblyInstance::module):
        (JSC::JSWebAssemblyInstance::codeBlock):
        (JSC::JSWebAssemblyInstance::memoryMode):
        (JSC::JSWebAssemblyInstance::setMemory): Deleted.
        * wasm/js/JSWebAssemblyMemory.cpp:
        (JSC::JSWebAssemblyMemory::create):
        (JSC::JSWebAssemblyMemory::JSWebAssemblyMemory):
        (JSC::JSWebAssemblyMemory::buffer):
        (JSC::JSWebAssemblyMemory::grow):
        (JSC::JSWebAssemblyMemory::destroy):
        * wasm/js/JSWebAssemblyMemory.h:
        (JSC::JSWebAssemblyMemory::memory):
        (JSC::JSWebAssemblyMemory::offsetOfMemory):
        (JSC::JSWebAssemblyMemory::offsetOfSize):
        * wasm/js/JSWebAssemblyModule.cpp:
        (JSC::JSWebAssemblyModule::buildCodeBlock):
        (JSC::JSWebAssemblyModule::create):
        (JSC::JSWebAssemblyModule::JSWebAssemblyModule):
        (JSC::JSWebAssemblyModule::codeBlock):
        (JSC::JSWebAssemblyModule::finishCreation):
        (JSC::JSWebAssemblyModule::visitChildren):
        (JSC::JSWebAssemblyModule::UnconditionalFinalizer::finalizeUnconditionally): Deleted.
        * wasm/js/JSWebAssemblyModule.h:
        (JSC::JSWebAssemblyModule::takeReservedMemory):
        (JSC::JSWebAssemblyModule::signatureIndexFromFunctionIndexSpace):
        (JSC::JSWebAssemblyModule::codeBlock):
        (JSC::JSWebAssemblyModule::functionImportCount): Deleted.
        (JSC::JSWebAssemblyModule::jsEntrypointCalleeFromFunctionIndexSpace): Deleted.
        (JSC::JSWebAssemblyModule::wasmEntrypointCalleeFromFunctionIndexSpace): Deleted.
        (JSC::JSWebAssemblyModule::setJSEntrypointCallee): Deleted.
        (JSC::JSWebAssemblyModule::setWasmEntrypointCallee): Deleted.
        (JSC::JSWebAssemblyModule::callees): Deleted.
        (JSC::JSWebAssemblyModule::offsetOfCallees): Deleted.
        (JSC::JSWebAssemblyModule::allocationSize): Deleted.
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction):
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::constructJSWebAssemblyInstance):
        * wasm/js/WebAssemblyMemoryConstructor.cpp:
        (JSC::constructJSWebAssemblyMemory):
        * wasm/js/WebAssemblyModuleConstructor.cpp:
        (JSC::WebAssemblyModuleConstructor::createModule):
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::link):
        (JSC::WebAssemblyModuleRecord::evaluate):

2017-03-03  Mark Lam  <mark.lam@apple.com>

        Gardening: fix broken ARM64 build.
        https://bugs.webkit.org/show_bug.cgi?id=169139

        Not reviewed.

        * assembler/ARM64Assembler.h:
        (JSC::ARM64Assembler::excepnGenerationImmMask):

2017-03-03  Mark Lam  <mark.lam@apple.com>

        Add MacroAssembler::isBreakpoint() query function.
        https://bugs.webkit.org/show_bug.cgi?id=169139

        Reviewed by Michael Saboff.

        This will be needed soon when we use breakpoint instructions to implement
        non-polling VM traps, and need to discern between a VM trap signal and a genuine
        assertion breakpoint.

        * assembler/ARM64Assembler.h:
        (JSC::ARM64Assembler::isBrk):
        (JSC::ARM64Assembler::excepnGenerationImmMask):
        * assembler/ARMAssembler.h:
        (JSC::ARMAssembler::isBkpt):
        * assembler/ARMv7Assembler.h:
        (JSC::ARMv7Assembler::isBkpt):
        * assembler/MIPSAssembler.h:
        (JSC::MIPSAssembler::isBkpt):
        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::isBreakpoint):
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::isBreakpoint):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::isBreakpoint):
        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::isBreakpoint):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::isBreakpoint):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::isInt3):

2017-03-03  Mark Lam  <mark.lam@apple.com>

        We should only check for traps that we're able to handle.
        https://bugs.webkit.org/show_bug.cgi?id=169136

        Reviewed by Michael Saboff.

        The execute methods in interpreter were checking for the existence of any traps
        (without masking) and only handling a subset of those via a mask.  This can
        result in a failed assertion on debug builds.

        This patch fixes this by applying the same mask for both the needTrapHandling()
        check and the handleTraps() call.  Also added a few assertions.

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::executeProgram):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        (JSC::Interpreter::execute):
        * jit/JITOperations.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):

2017-03-02  Carlos Garcia Campos  <cgarcia@igalia.com>

        Remote Inspector: Move updateTargetListing() methods to RemoteInspector.cpp
        https://bugs.webkit.org/show_bug.cgi?id=169074

        Reviewed by Joseph Pecoraro.

        They are not actually cocoa specific.

        * inspector/remote/RemoteInspector.cpp:
        (Inspector::RemoteInspector::updateTargetListing):
        * inspector/remote/RemoteInspector.h:
        * inspector/remote/cocoa/RemoteInspectorCocoa.mm:

2017-03-02  Mark Lam  <mark.lam@apple.com>

        Add WebKit2 hooks to notify the VM that the user has requested a debugger break.
        https://bugs.webkit.org/show_bug.cgi?id=169089

        Reviewed by Tim Horton and Joseph Pecoraro.

        * runtime/VM.cpp:
        (JSC::VM::handleTraps):
        * runtime/VM.h:
        (JSC::VM::notifyNeedDebuggerBreak):

2017-03-02  Michael Saboff  <msaboff@apple.com>

        Add JSC identity when code signing to allow debugging on iOS
        https://bugs.webkit.org/show_bug.cgi?id=169099

        Reviewed by Filip Pizlo.

        * Configurations/JSC.xcconfig:
        * Configurations/ToolExecutable.xcconfig:

2017-03-02  Keith Miller  <keith_miller@apple.com>

        WebAssemblyFunction should have Function.prototype as its prototype
        https://bugs.webkit.org/show_bug.cgi?id=169101

        Reviewed by Filip Pizlo.

        Per https://github.com/WebAssembly/design/blob/master/JS.md#exported-function-exotic-objects our JSWebAssemblyFunction
        objects should have Function.prototype as their prototype.

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

2017-03-02  Mark Lam  <mark.lam@apple.com>

        Add Options::alwaysCheckTraps() and Options::usePollingTraps() options.
        https://bugs.webkit.org/show_bug.cgi?id=169088

        Reviewed by Keith Miller.

        Options::alwaysCheckTraps() forces the op_check_traps bytecode to always be
        generated.  This is useful for testing purposes until we have signal based
        traps, at which point, we will always emit the op_check_traps bytecode and remove
        this option.

        Options::usePollingTraps() enables the use of polling VM traps all the time.
        This will be useful for benchmark comparisons, (between polling and non-polling
        traps), as well as for forcing polling traps later for ports that don't support
        signal based traps.

        Note: signal based traps are not fully implemented yet.  As a result, if the VM
        watchdog is in use, we will force Options::usePollingTraps() to be true.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitCheckTraps):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCheckTraps):
        * 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::compileCheckTraps):
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):
        * runtime/Options.h:

2017-03-02  Keith Miller  <keith_miller@apple.com>

        Fix addressing mode for B3WasmAddress
        https://bugs.webkit.org/show_bug.cgi?id=169092

        Reviewed by Filip Pizlo.

        Fix the potential addressing modes for B3WasmAddress. ARM does not
        support a base + index*1 + offset addressing mode. I think when I
        read it the first time I assumed it would always work on both ARM
        and X86. While true for X86 it's not true for ARM.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::effectiveAddr):

2017-03-02  Mark Lam  <mark.lam@apple.com>

        Add support for selective handling of VM traps.
        https://bugs.webkit.org/show_bug.cgi?id=169087

        Reviewed by Keith Miller.

        This is needed because there are some places in the VM where it's appropriate to
        handle some types of VM traps but not others.

        We implement this selection by using a VMTraps::Mask that allows the user to
        specify which traps should be serviced.

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::executeProgram):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        (JSC::Interpreter::execute):
        * runtime/VM.cpp:
        (JSC::VM::handleTraps):
        * runtime/VM.h:
        * runtime/VMTraps.cpp:
        (JSC::VMTraps::takeTrap): Deleted.
        * runtime/VMTraps.h:
        (JSC::VMTraps::Mask::Mask):
        (JSC::VMTraps::Mask::allEventTypes):
        (JSC::VMTraps::Mask::bits):
        (JSC::VMTraps::Mask::init):
        (JSC::VMTraps::needTrapHandling):
        (JSC::VMTraps::hasTrapForEvent):

2017-03-02  Alex Christensen  <achristensen@webkit.org>

        Continue enabling WebRTC
        https://bugs.webkit.org/show_bug.cgi?id=169056

        Reviewed by Jon Lee.

        * Configurations/FeatureDefines.xcconfig:

2017-03-02  Tomas Popela  <tpopela@redhat.com>

        Incorrect RELEASE_ASSERT in JSGlobalObject::addStaticGlobals()
        https://bugs.webkit.org/show_bug.cgi?id=169034

        Reviewed by Mark Lam.

        It should not assign to offset, but compare to offset.

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

2017-03-01  Alex Christensen  <achristensen@webkit.org>

        Unreviewed, rolling out r213259.

        Broke an internal build

        Reverted changeset:

        "Continue enabling WebRTC"
        https://bugs.webkit.org/show_bug.cgi?id=169056
        http://trac.webkit.org/changeset/213259

2017-03-01  Alex Christensen  <achristensen@webkit.org>

        Continue enabling WebRTC
        https://bugs.webkit.org/show_bug.cgi?id=169056

        Reviewed by Jon Lee.

        * Configurations/FeatureDefines.xcconfig:

2017-03-01  Michael Saboff  <msaboff@apple.com>

        Source/JavaScriptCore/ChangeLog
        https://bugs.webkit.org/show_bug.cgi?id=169055

        Reviewed by Mark Lam.

        Made local copies of options strings for OptionRange and string typed options.

        * runtime/Options.cpp:
        (JSC::parse):
        (JSC::OptionRange::init):

2017-03-01  Mark Lam  <mark.lam@apple.com>

        [Re-landing] Change JSLock to stash PlatformThread instead of std::thread::id.
        https://bugs.webkit.org/show_bug.cgi?id=168996

        Reviewed by Filip Pizlo and Saam Barati.

        PlatformThread is more useful because it allows us to:
        1. find the MachineThreads::Thread which is associated with it.
        2. suspend / resume threads.
        3. send a signal to a thread.

        We can't do those with std::thread::id.  We will need one or more of these
        capabilities to implement non-polling VM traps later.

        Update: Since we don't have a canonical "uninitialized" value for PlatformThread,
        we now have a JSLock::m_hasOwnerThread flag that is set to true if and only the
        m_ownerThread value is valid.  JSLock::currentThreadIsHoldingLock() now checks
        JSLock::m_hasOwnerThread before doing the thread identity comparison.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::Thread::createForCurrentThread):
        (JSC::MachineThreads::machineThreadForCurrentThread):
        (JSC::MachineThreads::removeThread):
        (JSC::MachineThreads::Thread::suspend):
        (JSC::MachineThreads::tryCopyOtherThreadStacks):
        (JSC::getCurrentPlatformThread): Deleted.
        * heap/MachineStackMarker.h:
        * runtime/JSCellInlines.h:
        (JSC::JSCell::classInfo):
        * runtime/JSLock.cpp:
        (JSC::JSLock::JSLock):
        (JSC::JSLock::lock):
        (JSC::JSLock::unlock):
        (JSC::JSLock::currentThreadIsHoldingLock): Deleted.
        * runtime/JSLock.h:
        (JSC::JSLock::ownerThread):
        (JSC::JSLock::currentThreadIsHoldingLock):
        * runtime/PlatformThread.h: Added.
        (JSC::currentPlatformThread):
        * runtime/VM.cpp:
        (JSC::VM::~VM):
        * runtime/VM.h:
        (JSC::VM::ownerThread):
        * runtime/Watchdog.cpp:
        (JSC::Watchdog::setTimeLimit):
        (JSC::Watchdog::shouldTerminate):
        (JSC::Watchdog::startTimer):
        (JSC::Watchdog::stopTimer):
        * tools/JSDollarVMPrototype.cpp:
        (JSC::JSDollarVMPrototype::currentThreadOwnsJSLock):
        * tools/VMInspector.cpp:

2017-03-01  Saam Barati  <sbarati@apple.com>

        Implement a mega-disassembler that'll be used in the FTL
        https://bugs.webkit.org/show_bug.cgi?id=168685

        Reviewed by Mark Lam.

        This patch extends the previous Air disassembler to print the
        DFG and B3 nodes belonging to particular Air instructions.
        The algorithm I'm using to do this is not perfect. For example,
        it won't try to print the entire DFG/B3 graph. It'll just print
        the related nodes for particular Air instructions. We can make the
        algorithm more sophisticated as we get more experience looking at
        these IR dumps and get a better feel for what we want out of them.

        This is an example of the output:

        ...
        ...
        200:<!0:->  InvalidationPoint(MustGen, W:SideState, Exits, bc#28, exit: bc#25 --> _getEntry#DlGw2r:<0x10276f980> bc#37)
           Void @54 = Patchpoint(@29:ColdAny, @29:ColdAny, @53:ColdAny, DFG:@200, generator = 0x1015d6c18, earlyClobbered = [], lateClobbered = [], usedRegisters = [%r0, %r19, %r20, %r21, %r22, %fp], resultConstraint = WarmAny, ExitsSideways|WritesPinned|ReadsPinned|Reads:Top)
               Patch &Patchpoint2, %r20, %r20, %r0, @54
         76:< 6:->  GetByOffset(KnownCell:@44, KnownCell:@44, JS|UseAsOther, Array, id3{_elementData}, 2, inferredType = Object, R:NamedProperties(3), Exits, bc#37)  predicting Array
           Int64 @57 = Load(@29, DFG:@76, offset = 32, ControlDependent|Reads:100...101)
               Move 32(%r20), %r5, @57
                      0x389cc9ac0:    ldur   x5, [x20, #32]
        115:<!0:->  CheckStructure(Cell:@76, MustGen, [0x1027eae20:[Array, {}, ArrayWithContiguous, Proto:0x1027e0140]], R:JSCell_structureID, Exits, bc#46)
           Int32 @58 = Load(@57, DFG:@115, ControlDependent|Reads:16...17)
               Move32 (%r5), %r1, @58
                      0x389cc9ac4:    ldur   w1, [x5]
           Int32 @59 = Const32(DFG:@115, 92)
           Int32 @60 = NotEqual(@58, $92(@59), DFG:@115)
           Void @61 = Check(@60:WarmAny, @57:ColdAny, @29:ColdAny, @29:ColdAny, @53:ColdAny, @57:ColdAny, DFG:@115, generator = 0x1057991e0, earlyClobbered = [], lateClobbered = [], usedRegisters = [%r0, %r5, %r19, %r20, %r21, %r22, %fp], ExitsSideways|Reads:Top)
               Patch &Branch32(3,SameAsRep)1, NotEqual, %r1, $92, %r5, %r20, %r20, %r0, %r5, @61
                      0x389cc9ac8:    cmp    w1, #92
                      0x389cc9acc:    b.ne   0x389cc9dac
        117:< 2:->  GetButterfly(Cell:@76, Storage|PureInt, R:JSObject_butterfly, Exits, bc#46)
           Int64 @64 = Load(@57, DFG:@117, offset = 8, ControlDependent|Reads:24...25)
               Move 8(%r5), %r4, @64
                      0x389cc9ad0:    ldur   x4, [x5, #8]
         79:< 2:->  GetArrayLength(KnownCell:@76, Untyped:@117, JS|PureInt|UseAsInt, Nonboolint32, Contiguous+OriginalArray+InBounds+AsIs, R:Butterfly_publicLength, Exits, bc#46)
           Int32 @67 = Load(@64, DFG:@79, offset = -8, ControlDependent|Reads:3...4)
               Move32 -8(%r4), %r2, @67
                      0x389cc9ad4:    ldur   w2, [x4, #-8]
      192:< 1:->  JSConstant(JS|PureInt, Nonboolint32, Int32: -1, bc#0)
           Int32 @68 = Const32(DFG:@192, -1)
               Move $0xffffffffffffffff, %r1, $-1(@68)
                      0x389cc9ad8:    mov    x1, #-1
         83:<!2:->  ArithAdd(Int32:Kill:@79, Int32:Kill:@192, Number|MustGen|PureInt|UseAsInt, Int32, Unchecked, Exits, bc#55)
           Int32 @69 = Add(@67, $-1(@68), DFG:@83)
               Add32 %r2, %r1, %r1, @69
                      0x389cc9adc:    add    w1, w2, w1
         86:< 3:->  BitAnd(Check:Int32:@71, Int32:Kill:@83, Int32|UseAsOther|UseAsInt|ReallyWantsInt, Int32, Exits, bc#60)
           Int32 @70 = Below(@53, $-281474976710656(@15), DFG:@86)
           Void @71 = Check(@70:WarmAny, @53:ColdAny, @29:ColdAny, @29:ColdAny, @53:ColdAny, @69:ColdAny, DFG:@86, generator = 0x105799370, earlyClobbered = [], lateClobbered = [], usedRegisters = [%r0, %r1, %r2, %r4, %r5, %r19, %r20, %r21, %r22, %fp], ExitsSideways|Reads:Top)
               Patch &Branch64(3,SameAsRep)0, Below, %r0, %r22, %r0, %r20, %r20, %r0, %r1, @71
                      0x389cc9ae0:    cmp    x0, x22
                      0x389cc9ae4:    b.lo   0x389cc9dc0
           Int32 @72 = Trunc(@53, DFG:@86)
           Int32 @73 = BitAnd(@69, @72, DFG:@86)
               And32 %r1, %r0, %r1, @73
                      0x389cc9ae8:    and    w1, w1, w0
           16:<!0:->  PutStack(KnownInt32:@71, MustGen, loc27, machine:loc3, FlushedInt32, W:Stack(-28), bc#19)
           Int32 @72 = Trunc(@53, DFG:@86)
           Int64 @11 = SlotBase(stack0)
           Void @76 = Store(@72, @11, DFG:@16, offset = 32, ControlDependent|Writes:94...95)
               Move32 %r0, -64(%fp), @76
                      0x389cc9aec:    stur   w0, [fp, #-64]
           12:<!0:->  PutStack(Untyped:@86, MustGen, loc28, machine:loc4, FlushedJSValue, W:Stack(-29), bc#19)
           Int64 @77 = ZExt32(@73, DFG:@12)
           Int64 @78 = Add(@77, $-281474976710656(@15), DFG:@12)
               Add64 %r1, %r22, %r3, @78
                      0x389cc9af0:    add    x3, x1, x22
           Int64 @11 = SlotBase(stack0)
           Void @81 = Store(@78, @11, DFG:@12, offset = 24, ControlDependent|Writes:95...96)
               Move %r3, -72(%fp), @81
                      0x389cc9af4:    stur   x3, [fp, #-72]
           10:<!0:->  PutStack(KnownInt32:@46, MustGen, loc29, machine:loc5, FlushedInt32, W:Stack(-30), bc#19)
           Int32 @82 = Trunc(@24, DFG:@10)
           Int64 @11 = SlotBase(stack0)
           Void @85 = Store(@82, @11, DFG:@10, offset = 16, ControlDependent|Writes:96...97)
               Move32 %r21, -80(%fp), @85
                      0x389cc9af8:    stur   w21, [fp, #-80]
          129:<!10:->  GetByVal(KnownCell:Kill:@76, Int32:Kill:@86, Untyped:Kill:@117, JS|MustGen|UseAsOther, FinalOther, Contiguous+OriginalArray+OutOfBounds+AsIs, R:World, W:Heap, Exits, ClobbersExit, bc#19)  predicting FinalOther
           Int32 @89 = AboveEqual(@73, @67, DFG:@129)
           Void @90 = Branch(@89, DFG:@129, Terminal)
               Branch32 AboveOrEqual, %r1, %r2, @90
                      0x389cc9afc:    cmp    w1, w2
                      0x389cc9b00:    b.hs   0x389cc9bec
        ...
        ...

        * b3/air/AirDisassembler.cpp:
        (JSC::B3::Air::Disassembler::dump):
        * b3/air/AirDisassembler.h:
        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::lower):
        (JSC::FTL::DFG::LowerDFGToB3::lowInt32):
        (JSC::FTL::DFG::LowerDFGToB3::lowCell):
        (JSC::FTL::DFG::LowerDFGToB3::lowBoolean):
        (JSC::FTL::DFG::LowerDFGToB3::lowJSValue):

2017-03-01  Mark Lam  <mark.lam@apple.com>

        REGRESSION (r213202?): Assertion failed: (!"initialized()"), function operator().
        https://bugs.webkit.org/show_bug.cgi?id=169042

        Not reviewed.

        Rolling out r213229 and r213202.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/MachineStackMarker.cpp:
        (JSC::getCurrentPlatformThread):
        (JSC::MachineThreads::Thread::createForCurrentThread):
        (JSC::MachineThreads::machineThreadForCurrentThread):
        (JSC::MachineThreads::removeThread):
        (JSC::MachineThreads::Thread::suspend):
        (JSC::MachineThreads::tryCopyOtherThreadStacks):
        * heap/MachineStackMarker.h:
        * runtime/JSCellInlines.h:
        (JSC::JSCell::classInfo):
        * runtime/JSLock.cpp:
        (JSC::JSLock::JSLock):
        (JSC::JSLock::lock):
        (JSC::JSLock::unlock):
        (JSC::JSLock::currentThreadIsHoldingLock):
        * runtime/JSLock.h:
        (JSC::JSLock::ownerThread):
        (JSC::JSLock::currentThreadIsHoldingLock): Deleted.
        * runtime/PlatformThread.h: Removed.
        * runtime/VM.cpp:
        (JSC::VM::~VM):
        * runtime/VM.h:
        (JSC::VM::ownerThread):
        * runtime/Watchdog.cpp:
        (JSC::Watchdog::setTimeLimit):
        (JSC::Watchdog::shouldTerminate):
        (JSC::Watchdog::startTimer):
        (JSC::Watchdog::stopTimer):
        * tools/JSDollarVMPrototype.cpp:
        (JSC::JSDollarVMPrototype::currentThreadOwnsJSLock):
        * tools/VMInspector.cpp:

2017-03-01  Mark Lam  <mark.lam@apple.com>

        REGRESSION (r213202?): Assertion failed: (!"initialized()"), function operator()
        https://bugs.webkit.org/show_bug.cgi?id=169042

        Reviewed by Filip Pizlo.

        * runtime/JSLock.h:
        (JSC::JSLock::currentThreadIsHoldingLock):

2017-02-28  Brian Burg  <bburg@apple.com>

        REGRESSION(r211344): Remote Inspector: listingForAutomationTarget() is called off-main-thread, causing assertions
        https://bugs.webkit.org/show_bug.cgi?id=168695
        <rdar://problem/30643899>

        Reviewed by Joseph Pecoraro.

        The aforementioned commit added some new calls to update target listings. This causes RemoteInspector
        to update some listings underneath an incoming setup message on the XPC queue, which is not a safe place
        to gather listing information for RemoteAutomationTargets.

        Update the listing asynchronously since we don't need it immediately. Since this really only happens when
        the connection to the target is set up and shut down, we can trigger listings to be refreshed from
        the async block that's called on the target's queue inside RemoteConnectionToTarget::{setup,close}.

        * inspector/remote/RemoteInspector.h:
        Make updateListingForTarget(unsigned) usable from RemoteConnectionToTarget.

        * inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
        (Inspector::RemoteConnectionToTarget::setup):
        (Inspector::RemoteConnectionToTarget::close):
        Grab the target identifier while the RemoteControllableTarget pointer is still valid,
        and use it inside the block later after it may have been destructed already. If that happens,
        then updateTargetListing will bail out because the targetIdentifier cannot be found in the mapping.

        * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
        (Inspector::RemoteInspector::updateTargetListing):
        We need to make sure to request a listing push after the target is updated, so implicitly call
        pushListingsSoon() from here. That method doesn't require any particular queue or holding a lock.

        (Inspector::RemoteInspector::receivedSetupMessage):
        (Inspector::RemoteInspector::receivedDidCloseMessage):
        (Inspector::RemoteInspector::receivedConnectionDiedMessage):
        Remove calls to updateTargetListing() and pushListingsSoon(), as these happen implicitly
        and asynchronously on the target's queue when the connection to target is opened or closed.

2017-03-01  Tomas Popela  <tpopela@redhat.com>

        Leak under Options::setOptions
        https://bugs.webkit.org/show_bug.cgi?id=169029

        Reviewed by Michael Saboff.

        Don't leak the optionsStrCopy variable.

        * runtime/Options.cpp:
        (JSC::Options::setOptions):

2017-03-01  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Allow UnlinkedCodeBlock to dump its bytecode sequence
        https://bugs.webkit.org/show_bug.cgi?id=168968

        Reviewed by Saam Barati.

        This patch decouples dumping bytecode sequence from CodeBlock.
        This change allows UnlinkedCodeBlock to dump its bytecode sequence.
        It is useful because we now have complex phase between UnlinkedCodeBlock and CodeBlock,
        called Generatorification.

        We introduce BytecodeDumper<Block>. Both CodeBlock and UnlinkedCodeBlock can use
        this class to dump bytecode sequence.

        And this patch also adds Option::dumpBytecodesBeforeGeneratorification,
        which dumps unlinked bytecode sequence before generatorification if it is enabled.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/BytecodeDumper.cpp: Added.
        (JSC::getStructureID):
        (JSC::getSpecialPointer):
        (JSC::getPutByIdFlags):
        (JSC::getToThisStatus):
        (JSC::getPointer):
        (JSC::getStructureChain):
        (JSC::getStructure):
        (JSC::getCallLinkInfo):
        (JSC::getBasicBlockLocation):
        (JSC::BytecodeDumper<Block>::actualPointerFor):
        (JSC::BytecodeDumper<CodeBlock>::actualPointerFor):
        (JSC::beginDumpProfiling):
        (JSC::BytecodeDumper<Block>::dumpValueProfiling):
        (JSC::BytecodeDumper<CodeBlock>::dumpValueProfiling):
        (JSC::BytecodeDumper<Block>::dumpArrayProfiling):
        (JSC::BytecodeDumper<CodeBlock>::dumpArrayProfiling):
        (JSC::BytecodeDumper<Block>::dumpProfilesForBytecodeOffset):
        (JSC::dumpRareCaseProfile):
        (JSC::dumpArithProfile):
        (JSC::BytecodeDumper<CodeBlock>::dumpProfilesForBytecodeOffset):
        (JSC::BytecodeDumper<Block>::vm):
        (JSC::BytecodeDumper<Block>::identifier):
        (JSC::regexpToSourceString):
        (JSC::regexpName):
        (JSC::printLocationAndOp):
        (JSC::isConstantRegisterIndex):
        (JSC::debugHookName):
        (JSC::BytecodeDumper<Block>::registerName):
        (JSC::idName):
        (JSC::BytecodeDumper<Block>::constantName):
        (JSC::BytecodeDumper<Block>::printUnaryOp):
        (JSC::BytecodeDumper<Block>::printBinaryOp):
        (JSC::BytecodeDumper<Block>::printConditionalJump):
        (JSC::BytecodeDumper<Block>::printGetByIdOp):
        (JSC::dumpStructure):
        (JSC::dumpChain):
        (JSC::BytecodeDumper<Block>::printGetByIdCacheStatus):
        (JSC::BytecodeDumper<Block>::printPutByIdCacheStatus):
        (JSC::BytecodeDumper<Block>::dumpCallLinkStatus):
        (JSC::BytecodeDumper<CodeBlock>::dumpCallLinkStatus):
        (JSC::BytecodeDumper<Block>::printCallOp):
        (JSC::BytecodeDumper<Block>::printPutByIdOp):
        (JSC::BytecodeDumper<Block>::printLocationOpAndRegisterOperand):
        (JSC::BytecodeDumper<Block>::dumpBytecode):
        (JSC::BytecodeDumper<Block>::dumpIdentifiers):
        (JSC::BytecodeDumper<Block>::dumpConstants):
        (JSC::BytecodeDumper<Block>::dumpRegExps):
        (JSC::BytecodeDumper<Block>::dumpExceptionHandlers):
        (JSC::BytecodeDumper<Block>::dumpSwitchJumpTables):
        (JSC::BytecodeDumper<Block>::dumpStringSwitchJumpTables):
        (JSC::BytecodeDumper<Block>::dumpBlock):
        * bytecode/BytecodeDumper.h: Added.
        (JSC::BytecodeDumper::BytecodeDumper):
        (JSC::BytecodeDumper::block):
        (JSC::BytecodeDumper::instructionsBegin):
        * bytecode/BytecodeGeneratorification.cpp:
        (JSC::BytecodeGeneratorification::BytecodeGeneratorification):
        (JSC::performGeneratorification):
        * bytecode/BytecodeLivenessAnalysis.cpp:
        (JSC::BytecodeLivenessAnalysis::dumpResults):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::propagateTransitions):
        (JSC::CodeBlock::finalizeLLIntInlineCaches):
        (JSC::CodeBlock::hasOpDebugForLineAndColumn):
        (JSC::CodeBlock::usesOpcode):
        (JSC::CodeBlock::valueProfileForBytecodeOffset):
        (JSC::CodeBlock::arithProfileForPC):
        (JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
        (JSC::idName): Deleted.
        (JSC::CodeBlock::registerName): Deleted.
        (JSC::CodeBlock::constantName): Deleted.
        (JSC::regexpToSourceString): Deleted.
        (JSC::regexpName): Deleted.
        (JSC::debugHookName): Deleted.
        (JSC::CodeBlock::printUnaryOp): Deleted.
        (JSC::CodeBlock::printBinaryOp): Deleted.
        (JSC::CodeBlock::printConditionalJump): Deleted.
        (JSC::CodeBlock::printGetByIdOp): Deleted.
        (JSC::dumpStructure): Deleted.
        (JSC::dumpChain): Deleted.
        (JSC::CodeBlock::printGetByIdCacheStatus): Deleted.
        (JSC::CodeBlock::printPutByIdCacheStatus): Deleted.
        (JSC::CodeBlock::printCallOp): Deleted.
        (JSC::CodeBlock::printPutByIdOp): Deleted.
        (JSC::CodeBlock::dumpExceptionHandlers): Deleted.
        (JSC::CodeBlock::beginDumpProfiling): Deleted.
        (JSC::CodeBlock::dumpValueProfiling): Deleted.
        (JSC::CodeBlock::dumpArrayProfiling): Deleted.
        (JSC::CodeBlock::dumpRareCaseProfile): Deleted.
        (JSC::CodeBlock::dumpArithProfile): Deleted.
        (JSC::CodeBlock::printLocationAndOp): Deleted.
        (JSC::CodeBlock::printLocationOpAndRegisterOperand): Deleted.
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::constantRegisters):
        (JSC::CodeBlock::numberOfRegExps):
        (JSC::CodeBlock::bitVectors):
        (JSC::CodeBlock::bitVector):
        * bytecode/HandlerInfo.h:
        (JSC::HandlerInfoBase::typeName):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::dump):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::getConstant):
        * bytecode/UnlinkedInstructionStream.cpp:
        (JSC::UnlinkedInstructionStream::UnlinkedInstructionStream):
        * bytecode/UnlinkedInstructionStream.h:
        (JSC::UnlinkedInstructionStream::Reader::next):
        * runtime/Options.h:

2017-02-28  Mark Lam  <mark.lam@apple.com>

        Change JSLock to stash PlatformThread instead of std::thread::id.
        https://bugs.webkit.org/show_bug.cgi?id=168996

        Reviewed by Filip Pizlo.

        PlatformThread is more useful because it allows us to:
        1. find the MachineThreads::Thread which is associated with it.
        2. suspend / resume threads.
        3. send a signal to a thread.

        We can't do those with std::thread::id.  We will need one or more of these
        capabilities to implement non-polling VM traps later.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::Thread::createForCurrentThread):
        (JSC::MachineThreads::machineThreadForCurrentThread):
        (JSC::MachineThreads::removeThread):
        (JSC::MachineThreads::Thread::suspend):
        (JSC::MachineThreads::tryCopyOtherThreadStacks):
        (JSC::getCurrentPlatformThread): Deleted.
        * heap/MachineStackMarker.h:
        * runtime/JSCellInlines.h:
        (JSC::JSCell::classInfo):
        * runtime/JSLock.cpp:
        (JSC::JSLock::lock):
        (JSC::JSLock::unlock):
        (JSC::JSLock::currentThreadIsHoldingLock): Deleted.
        * runtime/JSLock.h:
        (JSC::JSLock::ownerThread):
        (JSC::JSLock::currentThreadIsHoldingLock):
        * runtime/PlatformThread.h: Added.
        (JSC::currentPlatformThread):
        * runtime/VM.cpp:
        (JSC::VM::~VM):
        * runtime/VM.h:
        (JSC::VM::ownerThread):
        * runtime/Watchdog.cpp:
        (JSC::Watchdog::setTimeLimit):
        (JSC::Watchdog::shouldTerminate):
        (JSC::Watchdog::startTimer):
        (JSC::Watchdog::stopTimer):
        * tools/JSDollarVMPrototype.cpp:
        (JSC::JSDollarVMPrototype::currentThreadOwnsJSLock):
        * tools/VMInspector.cpp:

2017-02-28  Mark Lam  <mark.lam@apple.com>

        Enable the SigillCrashAnalyzer by default for iOS.
        https://bugs.webkit.org/show_bug.cgi?id=168989

        Reviewed by Keith Miller.

        * runtime/Options.cpp:
        (JSC::overrideDefaults):

2017-02-28  Mark Lam  <mark.lam@apple.com>

        Remove setExclusiveThread() and peers from the JSLock.
        https://bugs.webkit.org/show_bug.cgi?id=168977

        Reviewed by Filip Pizlo.

        JSLock::setExclusiveThread() was only used by WebCore.  Benchmarking with
        Speedometer, we see that removal of exclusive thread status has no measurable
        impact on performance.  So, let's remove the code for handling exclusive thread
        status, and simplify the JSLock code.

        For the records, exclusive thread status does improve JSLock locking/unlocking
        time by up to 20%.  However, this difference is not measurable in the way WebCore
        uses the JSLock as confirmed by Speedometer.

        Also applied a minor optimization in JSLock::lock() to assume the initial lock
        entry case (as opposed to the re-entry case).  This appears to shows a small
        fractional improvement (about 5%) in JSLock cumulative locking and unlocking
        time in a micro-benchmark.

        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::MachineThreads):
        (JSC::MachineThreads::addCurrentThread):
        * heap/MachineStackMarker.h:
        * runtime/JSLock.cpp:
        (JSC::JSLock::JSLock):
        (JSC::JSLock::lock):
        (JSC::JSLock::unlock):
        (JSC::JSLock::currentThreadIsHoldingLock):
        (JSC::JSLock::dropAllLocks):
        (JSC::JSLock::grabAllLocks):
        (JSC::JSLock::setExclusiveThread): Deleted.
        * runtime/JSLock.h:
        (JSC::JSLock::ownerThread):
        (JSC::JSLock::hasExclusiveThread): Deleted.
        (JSC::JSLock::exclusiveThread): Deleted.
        * runtime/VM.h:
        (JSC::VM::hasExclusiveThread): Deleted.
        (JSC::VM::exclusiveThread): Deleted.
        (JSC::VM::setExclusiveThread): Deleted.

2017-02-28  Saam Barati  <sbarati@apple.com>

        Arm64 disassembler prints "ars" instead of "asr"
        https://bugs.webkit.org/show_bug.cgi?id=168923

        Rubber stamped by Michael Saboff.

        * disassembler/ARM64/A64DOpcode.cpp:
        (JSC::ARM64Disassembler::A64DOpcodeBitfield::format):

2017-02-28  Oleksandr Skachkov  <gskachkov@gmail.com>

        Use of arguments in arrow function is slow
        https://bugs.webkit.org/show_bug.cgi?id=168829

        Reviewed by Saam Barati.

        Current patch improves performance access to arguments within arrow functuion
        by preventing create arguments variable within arrow function, also allow to cache 
        arguments variable. Before arguments variable always have Dynamic resolve type, after 
        patch it can be ClosureVar, that increase performance of access to arguments variable
        in 9 times inside of the arrow function. 

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * runtime/JSScope.cpp:
        (JSC::abstractAccess):

2017-02-28  Michael Saboff  <msaboff@apple.com>

        Add ability to configure JSC options from a file
        https://bugs.webkit.org/show_bug.cgi?id=168914

        Reviewed by Filip Pizlo.

        Added the ability to set options and DataLog file location via a configuration file.
        The configuration file is specified with the --configFile option to JSC or the
        JSC_configFile environment variable.

        The file format allows for options conditionally dependent on various attributes.
        Currently those attributes are the process name, parent process name and build
        type (Release or Debug).  In this patch, the parent process type is not set.
        That will be set up in WebKit code with a follow up patch.

        Here is an example config file:

            logFile = "/tmp/jscLog.%pid.txt"

            jscOptions {
                dumpOptions = 2
            }

            build == "Debug" {
                jscOptions {
                    useConcurrentJIT = false
                    dumpDisassembly = true
                }
            }

            build == "Release" && processName == "jsc" {
                jscOptions {
                    asyncDisassembly = true
                }
            }

        Eliminated the prior options file code.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * jsc.cpp:
        (jscmain):
        * runtime/ConfigFile.cpp: Added.
        (JSC::ConfigFileScanner::ConfigFileScanner):
        (JSC::ConfigFileScanner::start):
        (JSC::ConfigFileScanner::lineNumber):
        (JSC::ConfigFileScanner::currentBuffer):
        (JSC::ConfigFileScanner::atFileEnd):
        (JSC::ConfigFileScanner::tryConsume):
        (JSC::ConfigFileScanner::tryConsumeString):
        (JSC::ConfigFileScanner::tryConsumeUpto):
        (JSC::ConfigFileScanner::fillBufferIfNeeded):
        (JSC::ConfigFileScanner::fillBuffer):
        (JSC::ConfigFile::ConfigFile):
        (JSC::ConfigFile::setProcessName):
        (JSC::ConfigFile::setParentProcessName):
        (JSC::ConfigFile::parse):
        * runtime/ConfigFile.h: Added.
        * runtime/Options.cpp:
        (JSC::Options::initialize):
        (JSC::Options::setOptions):
        * runtime/Options.h:

2017-02-27  Alex Christensen  <achristensen@webkit.org>

        Begin enabling WebRTC on 64-bit
        https://bugs.webkit.org/show_bug.cgi?id=168915

        Reviewed by Eric Carlson.

        * Configurations/FeatureDefines.xcconfig:

2017-02-27  Mark Lam  <mark.lam@apple.com>

        Introduce a VM Traps mechanism and refactor Watchdog to use it.
        https://bugs.webkit.org/show_bug.cgi?id=168842

        Reviewed by Filip Pizlo.

        Currently, the traps mechanism is only used for the JSC watchdog, and for
        asynchronous termination requests (which is currently only used for worker
        threads termination).

        This first cut of the traps mechanism still relies on polling from DFG and FTL
        code.  This is done to keep the patch as small as possible.  The work to do
        a non-polling version of the traps mechanism for DFG and FTL code is deferred to
        another patch.

        In this patch, worker threads still need to set the VM::m_needAsynchronousTerminationSupport
        flag to enable the traps polling in the DFG and FTL code.  When we have the
        non-polling version of the DFG and FTL traps mechanism, we can remove the use of
        the VM::m_needAsynchronousTerminationSupport flag.

        Note: this patch also separates asynchronous termination support from the JSC
        watchdog.  This separation allows us to significantly simplify the locking
        requirements in the watchdog code, and make it easier to reason about its
        correctness.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitLoopHint):
        (JSC::BytecodeGenerator::emitCheckTraps):
        (JSC::BytecodeGenerator::emitWatchdog): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        * 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::compileCheckTraps):
        * 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::compileCheckTraps):
        (JSC::FTL::DFG::LowerDFGToB3::compileCheckWatchdogTimer): Deleted.
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::executeProgram):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        (JSC::Interpreter::execute):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_check_traps):
        (JSC::JIT::emitSlow_op_check_traps):
        (JSC::JIT::emit_op_watchdog): Deleted.
        (JSC::JIT::emitSlow_op_watchdog): Deleted.
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/VM.cpp:
        (JSC::VM::~VM):
        (JSC::VM::ensureWatchdog):
        (JSC::VM::handleTraps):
        * runtime/VM.h:
        (JSC::VM::ownerThread):
        (JSC::VM::needTrapHandling):
        (JSC::VM::needTrapHandlingAddress):
        (JSC::VM::notifyNeedTermination):
        (JSC::VM::notifyNeedWatchdogCheck):
        (JSC::VM::needAsynchronousTerminationSupport):
        (JSC::VM::setNeedAsynchronousTerminationSupport):
        * runtime/VMInlines.h:
        (JSC::VM::shouldTriggerTermination): Deleted.
        * runtime/VMTraps.cpp: Added.
        (JSC::VMTraps::fireTrap):
        (JSC::VMTraps::takeTrap):
        * runtime/VMTraps.h: Added.
        (JSC::VMTraps::needTrapHandling):
        (JSC::VMTraps::needTrapHandlingAddress):
        (JSC::VMTraps::hasTrapForEvent):
        (JSC::VMTraps::setTrapForEvent):
        (JSC::VMTraps::clearTrapForEvent):
        * runtime/Watchdog.cpp:
        (JSC::Watchdog::Watchdog):
        (JSC::Watchdog::setTimeLimit):
        (JSC::Watchdog::shouldTerminate):
        (JSC::Watchdog::enteredVM):
        (JSC::Watchdog::exitedVM):
        (JSC::Watchdog::startTimer):
        (JSC::Watchdog::stopTimer):
        (JSC::Watchdog::willDestroyVM):
        (JSC::Watchdog::terminateSoon): Deleted.
        (JSC::Watchdog::shouldTerminateSlow): Deleted.
        * runtime/Watchdog.h:
        (JSC::Watchdog::shouldTerminate): Deleted.
        (JSC::Watchdog::timerDidFireAddress): Deleted.

2017-02-27  Commit Queue  <commit-queue@webkit.org>

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

        "It broke 32-bit jsc tests in debug builds" (Requested by
        saamyjoon on #webkit).

        Reverted changeset:

        "op_get_by_id_with_this should use inline caching"
        https://bugs.webkit.org/show_bug.cgi?id=162124
        http://trac.webkit.org/changeset/213019

2017-02-27  JF Bastien  <jfbastien@apple.com>

        WebAssembly: miscellaneous spec fixes part deux
        https://bugs.webkit.org/show_bug.cgi?id=168861

        Reviewed by Keith Miller.

        * wasm/WasmFunctionParser.h: add some FIXME

2017-02-27  Alex Christensen  <achristensen@webkit.org>

        [libwebrtc] Enable WebRTC in some Production Builds
        https://bugs.webkit.org/show_bug.cgi?id=168858

        * Configurations/FeatureDefines.xcconfig:

2017-02-26  Caio Lima  <ticaiolima@gmail.com>

        op_get_by_id_with_this should use inline caching
        https://bugs.webkit.org/show_bug.cgi?id=162124

        Reviewed by Saam Barati.

        This patch is enabling inline cache for op_get_by_id_with_this in all
        tiers. It means that operations using ```super.member``` are going to
        be able to be optimized by PIC. To enable it, we introduced a new
        member of StructureStubInfo.patch named thisGPR, created a new class
        to manage the IC named JITGetByIdWithThisGenerator and changed
        PolymorphicAccess.regenerate that uses StructureStubInfo.patch.thisGPR
        to decide the correct this value on inline caches.
        With inline cached enabled, ```super.member``` are ~4.5x faster,
        according microbenchmarks.

        * bytecode/AccessCase.cpp:
        (JSC::AccessCase::generateImpl):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::PolymorphicAccess::regenerate):
        * bytecode/PolymorphicAccess.h:
        * bytecode/StructureStubInfo.cpp:
        (JSC::StructureStubInfo::reset):
        * bytecode/StructureStubInfo.h:
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::link):
        * dfg/DFGJITCompiler.h:
        (JSC::DFG::JITCompiler::addGetByIdWithThis):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileIn):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetByIdWithThis):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetByIdWithThis):
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByIdWithThis):
        (JSC::FTL::DFG::LowerDFGToB3::compileIn):
        (JSC::FTL::DFG::LowerDFGToB3::getByIdWithThis):
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgumentsWithExecState):
        * jit/ICStats.h:
        * jit/JIT.cpp:
        (JSC::JIT::JIT):
        (JSC::JIT::privateCompileSlowCases):
        (JSC::JIT::link):
        * jit/JIT.h:
        * jit/JITInlineCacheGenerator.cpp:
        (JSC::JITByIdGenerator::JITByIdGenerator):
        (JSC::JITGetByIdWithThisGenerator::JITGetByIdWithThisGenerator):
        (JSC::JITGetByIdWithThisGenerator::generateFastPath):
        * jit/JITInlineCacheGenerator.h:
        (JSC::JITGetByIdWithThisGenerator::JITGetByIdWithThisGenerator):
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_get_by_id_with_this):
        (JSC::JIT::emitSlow_op_get_by_id_with_this):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_get_by_id_with_this):
        (JSC::JIT::emitSlow_op_get_by_id_with_this):
        * jit/Repatch.cpp:
        (JSC::appropriateOptimizingGetByIdFunction):
        (JSC::appropriateGenericGetByIdFunction):
        (JSC::tryCacheGetByID):
        * jit/Repatch.h:
        * jsc.cpp:
        (WTF::CustomGetter::getOwnPropertySlot):
        (WTF::CustomGetter::customGetterAcessor):

2017-02-24  JF Bastien  <jfbastien@apple.com>

        WebAssembly: miscellaneous spec fixes
        https://bugs.webkit.org/show_bug.cgi?id=168822

        Reviewed by Saam Barati.

        * wasm/WasmModuleParser.cpp: "unknown" sections are now called "custom" sections
        * wasm/WasmSections.h:
        (JSC::Wasm::validateOrder):
        (JSC::Wasm::makeString): fix ASSERT_UNREACHABLE bug in printing
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::constructJSWebAssemblyInstance): disallow i64 import
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::link): disallow i64 export
        (JSC::WebAssemblyModuleRecord::evaluate):

2017-02-24  Filip Pizlo  <fpizlo@apple.com>

        Move Arg::Type and Arg::Width out into the B3 namespace, since they are general concepts
        https://bugs.webkit.org/show_bug.cgi?id=168833

        Reviewed by Saam Barati.
        
        I want to use the Air::Arg::Type and Air::Arg::Width concepts in B3. We are already
        doing this a bit, and it's akward because of the namespacing. Throughout B3 we take the
        approach that if something is not specific to Air, then it should be in the B3
        namespace.
        
        This moves Air::Arg::Type to B3::Bank. This moves Air::Arg::Width to B3::Width.
        
        I renamed Arg::Type to Bank because there is already a B3::Type and because Arg::Type
        was never really a type. Its purpose was always to identify register banks, and we use
        this enum when the thing we care about is whether the value is most appropriate for
        GPRs or FPRs.
        
        I kept both as non-enum classes because I think that we've learned that terse compiler
        code is a good thing. I don't want to say Bank::GP when I can say GP. With Width, the
        argument is even stronger, since you cannot say Width::8 but you can say Width8.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3Bank.cpp: Added.
        (WTF::printInternal):
        * b3/B3Bank.h: Added.
        (JSC::B3::forEachBank):
        (JSC::B3::bankForType):
        * b3/B3CheckSpecial.cpp:
        (JSC::B3::CheckSpecial::forEachArg):
        * b3/B3LegalizeMemoryOffsets.cpp:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::run):
        (JSC::B3::Air::LowerToAir::tmp):
        (JSC::B3::Air::LowerToAir::scaleForShl):
        (JSC::B3::Air::LowerToAir::effectiveAddr):
        (JSC::B3::Air::LowerToAir::addr):
        (JSC::B3::Air::LowerToAir::createGenericCompare):
        (JSC::B3::Air::LowerToAir::createBranch):
        (JSC::B3::Air::LowerToAir::createCompare):
        (JSC::B3::Air::LowerToAir::createSelect):
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3MemoryValue.cpp:
        (JSC::B3::MemoryValue::accessWidth):
        * b3/B3MemoryValue.h:
        * b3/B3MoveConstants.cpp:
        * b3/B3PatchpointSpecial.cpp:
        (JSC::B3::PatchpointSpecial::forEachArg):
        * b3/B3StackmapSpecial.cpp:
        (JSC::B3::StackmapSpecial::forEachArgImpl):
        * b3/B3Value.h:
        * b3/B3Variable.h:
        (JSC::B3::Variable::width):
        (JSC::B3::Variable::bank):
        * b3/B3WasmAddressValue.h:
        * b3/B3Width.cpp: Added.
        (WTF::printInternal):
        * b3/B3Width.h: Added.
        (JSC::B3::pointerWidth):
        (JSC::B3::widthForType):
        (JSC::B3::conservativeWidth):
        (JSC::B3::minimumWidth):
        (JSC::B3::bytes):
        (JSC::B3::widthForBytes):
        * b3/air/AirAllocateRegistersByGraphColoring.cpp:
        * b3/air/AirAllocateStack.cpp:
        (JSC::B3::Air::allocateStack):
        * b3/air/AirArg.cpp:
        (JSC::B3::Air::Arg::canRepresent):
        (JSC::B3::Air::Arg::isCompatibleBank):
        (JSC::B3::Air::Arg::isCompatibleType): Deleted.
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::hasBank):
        (JSC::B3::Air::Arg::bank):
        (JSC::B3::Air::Arg::isBank):
        (JSC::B3::Air::Arg::forEachTmp):
        (JSC::B3::Air::Arg::forEachType): Deleted.
        (JSC::B3::Air::Arg::pointerWidth): Deleted.
        (JSC::B3::Air::Arg::typeForB3Type): Deleted.
        (JSC::B3::Air::Arg::widthForB3Type): Deleted.
        (JSC::B3::Air::Arg::conservativeWidth): Deleted.
        (JSC::B3::Air::Arg::minimumWidth): Deleted.
        (JSC::B3::Air::Arg::bytes): Deleted.
        (JSC::B3::Air::Arg::widthForBytes): Deleted.
        (JSC::B3::Air::Arg::hasType): Deleted.
        (JSC::B3::Air::Arg::type): Deleted.
        (JSC::B3::Air::Arg::isType): Deleted.
        * b3/air/AirArgInlines.h:
        (JSC::B3::Air::ArgThingHelper<Tmp>::forEach):
        (JSC::B3::Air::ArgThingHelper<Arg>::forEach):
        (JSC::B3::Air::ArgThingHelper<Reg>::forEach):
        (JSC::B3::Air::Arg::forEach):
        * b3/air/AirCCallSpecial.cpp:
        (JSC::B3::Air::CCallSpecial::forEachArg):
        * b3/air/AirCCallingConvention.cpp:
        * b3/air/AirCode.cpp:
        (JSC::B3::Air::Code::Code):
        (JSC::B3::Air::Code::setRegsInPriorityOrder):
        (JSC::B3::Air::Code::pinRegister):
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::regsInPriorityOrder):
        (JSC::B3::Air::Code::newTmp):
        (JSC::B3::Air::Code::numTmps):
        (JSC::B3::Air::Code::regsInPriorityOrderImpl):
        * b3/air/AirCustom.cpp:
        (JSC::B3::Air::PatchCustom::isValidForm):
        (JSC::B3::Air::ShuffleCustom::isValidForm):
        * b3/air/AirCustom.h:
        (JSC::B3::Air::PatchCustom::forEachArg):
        (JSC::B3::Air::CCallCustom::forEachArg):
        (JSC::B3::Air::ColdCCallCustom::forEachArg):
        (JSC::B3::Air::ShuffleCustom::forEachArg):
        (JSC::B3::Air::WasmBoundsCheckCustom::forEachArg):
        * b3/air/AirDumpAsJS.cpp:
        (JSC::B3::Air::dumpAsJS):
        * b3/air/AirEliminateDeadCode.cpp:
        (JSC::B3::Air::eliminateDeadCode):
        * b3/air/AirEmitShuffle.cpp:
        (JSC::B3::Air::emitShuffle):
        * b3/air/AirEmitShuffle.h:
        (JSC::B3::Air::ShufflePair::ShufflePair):
        (JSC::B3::Air::ShufflePair::width):
        * b3/air/AirFixObviousSpills.cpp:
        * b3/air/AirFixPartialRegisterStalls.cpp:
        (JSC::B3::Air::fixPartialRegisterStalls):
        * b3/air/AirInst.cpp:
        (JSC::B3::Air::Inst::hasArgEffects):
        * b3/air/AirInst.h:
        (JSC::B3::Air::Inst::forEachTmp):
        * b3/air/AirInstInlines.h:
        (JSC::B3::Air::Inst::forEach):
        (JSC::B3::Air::Inst::forEachDef):
        (JSC::B3::Air::Inst::forEachDefWithExtraClobberedRegs):
        * b3/air/AirLiveness.h:
        (JSC::B3::Air::TmpLivenessAdapter::numIndices):
        (JSC::B3::Air::TmpLivenessAdapter::acceptsBank):
        (JSC::B3::Air::TmpLivenessAdapter::valueToIndex):
        (JSC::B3::Air::TmpLivenessAdapter::indexToValue):
        (JSC::B3::Air::StackSlotLivenessAdapter::acceptsBank):
        (JSC::B3::Air::RegLivenessAdapter::acceptsBank):
        (JSC::B3::Air::AbstractLiveness::AbstractLiveness):
        (JSC::B3::Air::AbstractLiveness::LocalCalc::execute):
        (JSC::B3::Air::TmpLivenessAdapter::acceptsType): Deleted.
        (JSC::B3::Air::StackSlotLivenessAdapter::acceptsType): Deleted.
        (JSC::B3::Air::RegLivenessAdapter::acceptsType): Deleted.
        * b3/air/AirLogRegisterPressure.cpp:
        (JSC::B3::Air::logRegisterPressure):
        * b3/air/AirLowerAfterRegAlloc.cpp:
        (JSC::B3::Air::lowerAfterRegAlloc):
        * b3/air/AirLowerMacros.cpp:
        (JSC::B3::Air::lowerMacros):
        * b3/air/AirPadInterference.cpp:
        (JSC::B3::Air::padInterference):
        * b3/air/AirReportUsedRegisters.cpp:
        (JSC::B3::Air::reportUsedRegisters):
        * b3/air/AirSpillEverything.cpp:
        (JSC::B3::Air::spillEverything):
        * b3/air/AirTmpInlines.h:
        (JSC::B3::Air::AbsoluteTmpMapper<Arg::GP>::absoluteIndex): Deleted.
        (JSC::B3::Air::AbsoluteTmpMapper<Arg::GP>::lastMachineRegisterIndex): Deleted.
        (JSC::B3::Air::AbsoluteTmpMapper<Arg::GP>::tmpFromAbsoluteIndex): Deleted.
        (JSC::B3::Air::AbsoluteTmpMapper<Arg::FP>::absoluteIndex): Deleted.
        (JSC::B3::Air::AbsoluteTmpMapper<Arg::FP>::lastMachineRegisterIndex): Deleted.
        (JSC::B3::Air::AbsoluteTmpMapper<Arg::FP>::tmpFromAbsoluteIndex): Deleted.
        * b3/air/AirTmpWidth.cpp:
        (JSC::B3::Air::TmpWidth::recompute):
        * b3/air/AirTmpWidth.h:
        (JSC::B3::Air::TmpWidth::width):
        (JSC::B3::Air::TmpWidth::requiredWidth):
        (JSC::B3::Air::TmpWidth::defWidth):
        (JSC::B3::Air::TmpWidth::useWidth):
        (JSC::B3::Air::TmpWidth::Widths::Widths):
        * b3/air/AirUseCounts.h:
        (JSC::B3::Air::UseCounts::UseCounts):
        * b3/air/AirValidate.cpp:
        * b3/air/opcode_generator.rb:
        * b3/air/testair.cpp:
        (JSC::B3::Air::compile): Deleted.
        (JSC::B3::Air::invoke): Deleted.
        (JSC::B3::Air::compileAndRun): Deleted.
        (JSC::B3::Air::testSimple): Deleted.
        (JSC::B3::Air::loadConstantImpl): Deleted.
        (JSC::B3::Air::loadConstant): Deleted.
        (JSC::B3::Air::loadDoubleConstant): Deleted.
        (JSC::B3::Air::testShuffleSimpleSwap): Deleted.
        (JSC::B3::Air::testShuffleSimpleShift): Deleted.
        (JSC::B3::Air::testShuffleLongShift): Deleted.
        (JSC::B3::Air::testShuffleLongShiftBackwards): Deleted.
        (JSC::B3::Air::testShuffleSimpleRotate): Deleted.
        (JSC::B3::Air::testShuffleSimpleBroadcast): Deleted.
        (JSC::B3::Air::testShuffleBroadcastAllRegs): Deleted.
        (JSC::B3::Air::testShuffleTreeShift): Deleted.
        (JSC::B3::Air::testShuffleTreeShiftBackward): Deleted.
        (JSC::B3::Air::testShuffleTreeShiftOtherBackward): Deleted.
        (JSC::B3::Air::testShuffleMultipleShifts): Deleted.
        (JSC::B3::Air::testShuffleRotateWithFringe): Deleted.
        (JSC::B3::Air::testShuffleRotateWithFringeInWeirdOrder): Deleted.
        (JSC::B3::Air::testShuffleRotateWithLongFringe): Deleted.
        (JSC::B3::Air::testShuffleMultipleRotates): Deleted.
        (JSC::B3::Air::testShuffleShiftAndRotate): Deleted.
        (JSC::B3::Air::testShuffleShiftAllRegs): Deleted.
        (JSC::B3::Air::testShuffleRotateAllRegs): Deleted.
        (JSC::B3::Air::testShuffleSimpleSwap64): Deleted.
        (JSC::B3::Air::testShuffleSimpleShift64): Deleted.
        (JSC::B3::Air::testShuffleSwapMixedWidth): Deleted.
        (JSC::B3::Air::testShuffleShiftMixedWidth): Deleted.
        (JSC::B3::Air::testShuffleShiftMemory): Deleted.
        (JSC::B3::Air::testShuffleShiftMemoryLong): Deleted.
        (JSC::B3::Air::testShuffleShiftMemoryAllRegs): Deleted.
        (JSC::B3::Air::testShuffleShiftMemoryAllRegs64): Deleted.
        (JSC::B3::Air::combineHiLo): Deleted.
        (JSC::B3::Air::testShuffleShiftMemoryAllRegsMixedWidth): Deleted.
        (JSC::B3::Air::testShuffleRotateMemory): Deleted.
        (JSC::B3::Air::testShuffleRotateMemory64): Deleted.
        (JSC::B3::Air::testShuffleRotateMemoryMixedWidth): Deleted.
        (JSC::B3::Air::testShuffleRotateMemoryAllRegs64): Deleted.
        (JSC::B3::Air::testShuffleRotateMemoryAllRegsMixedWidth): Deleted.
        (JSC::B3::Air::testShuffleSwapDouble): Deleted.
        (JSC::B3::Air::testShuffleShiftDouble): Deleted.
        (JSC::B3::Air::testX86VMULSD): Deleted.
        (JSC::B3::Air::testX86VMULSDDestRex): Deleted.
        (JSC::B3::Air::testX86VMULSDOp1DestRex): Deleted.
        (JSC::B3::Air::testX86VMULSDOp2DestRex): Deleted.
        (JSC::B3::Air::testX86VMULSDOpsDestRex): Deleted.
        (JSC::B3::Air::testX86VMULSDAddr): Deleted.
        (JSC::B3::Air::testX86VMULSDAddrOpRexAddr): Deleted.
        (JSC::B3::Air::testX86VMULSDDestRexAddr): Deleted.
        (JSC::B3::Air::testX86VMULSDRegOpDestRexAddr): Deleted.
        (JSC::B3::Air::testX86VMULSDAddrOpDestRexAddr): Deleted.
        (JSC::B3::Air::testX86VMULSDBaseNeedsRex): Deleted.
        (JSC::B3::Air::testX86VMULSDIndexNeedsRex): Deleted.
        (JSC::B3::Air::testX86VMULSDBaseIndexNeedRex): Deleted.
        (JSC::B3::Air::run): Deleted.

2017-02-24  Keith Miller  <keith_miller@apple.com>

        We should be able to use std::tuples as keys in HashMap
        https://bugs.webkit.org/show_bug.cgi?id=168805

        Reviewed by Filip Pizlo.

        Convert the mess of std::pairs we used as the keys in PrototypeMap
        to a std::tuple. I also plan on using this for a HashMap in wasm.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/PrototypeMap.cpp:
        (JSC::PrototypeMap::createEmptyStructure):
        (JSC::PrototypeMap::clearEmptyObjectStructureForPrototype):
        * runtime/PrototypeMap.h:

2017-02-24  Saam Barati  <sbarati@apple.com>

        Unreviewed. Remove inaccurate copy-paste comment from r212939.

        * dfg/DFGOperations.cpp:

2017-02-23  Saam Barati  <sbarati@apple.com>

        Intrinsicify parseInt
        https://bugs.webkit.org/show_bug.cgi?id=168627

        Reviewed by Filip Pizlo.

        This patch makes parseInt an intrinsic in the DFG and FTL.
        We do our best to eliminate this node. If we speculate that
        the first operand to the operation is an int32, and that there
        isn't a second operand, we convert to the identity of the first
        operand. That's because parseInt(someInt) === someInt.
        
        If the first operand is proven to be an integer, and the second
        operand is the integer 0 or the integer 10, we can eliminate the
        node by making it an identity over its first operand. That's
        because parseInt(someInt, 0) === someInt and parseInt(someInt, 10) === someInt.
        
        If we are not able to constant fold the node away, we try to remove
        checks. The most common use case of parseInt is that its first operand
        is a proven string. The DFG might be able to remove type checks in this
        case. We also set up CSE rules for parseInt(someString, someIntRadix)
        because it's a "pure" operation (modulo resolving a rope).

        This looks to be a 4% Octane/Box2D progression.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * 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/DFGNode.h:
        (JSC::DFG::Node::hasHeapPrediction):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        (JSC::DFG::parseIntResult):
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileParseInt):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        (JSC::DFG::SpeculativeJIT::appendCallSetResult):
        * 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::compileParseInt):
        * jit/JITOperations.h:
        * parser/Lexer.cpp:
        * runtime/ErrorInstance.cpp:
        * runtime/Intrinsic.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::toStringView): Deleted.
        (JSC::isStrWhiteSpace): Deleted.
        (JSC::parseDigit): Deleted.
        (JSC::parseIntOverflow): Deleted.
        (JSC::parseInt): Deleted.
        * runtime/JSGlobalObjectFunctions.h:
        * runtime/ParseInt.h: Added.
        (JSC::parseDigit):
        (JSC::parseIntOverflow):
        (JSC::isStrWhiteSpace):
        (JSC::parseInt):
        (JSC::toStringView):
        * runtime/StringPrototype.cpp:

2017-02-23  JF Bastien  <jfbastien@apple.com>

        WebAssembly: support 0x1 version
        https://bugs.webkit.org/show_bug.cgi?id=168672

        Reviewed by Keith Miller.

        * wasm/wasm.json: update the version number, everything is based
        on its value

2017-02-23  Saam Barati  <sbarati@apple.com>

        Make Briggs fixpoint validation run only with validateGraphAtEachPhase
        https://bugs.webkit.org/show_bug.cgi?id=168795

        Rubber stamped by Keith Miller.

        The Briggs allocator was running intensive validation
        on each step of the fixpoint. Instead, it now will just
        do it when shouldValidateIRAtEachPhase() is true because
        doing this for all !ASSERT_DISABLED builds takes too long.

        * b3/air/AirAllocateRegistersByGraphColoring.cpp:

2017-02-23  Filip Pizlo  <fpizlo@apple.com>

        SpeculativeJIT::compilePutByValForIntTypedArray should only do the constant-folding optimization when the constant passes the type check
        https://bugs.webkit.org/show_bug.cgi?id=168787

        Reviewed by Michael Saboff and Mark Lam.

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

2017-02-23  Mark Lam  <mark.lam@apple.com>

        Ensure that the end of the last invalidation point does not extend beyond the end of the buffer.
        https://bugs.webkit.org/show_bug.cgi?id=168786

        Reviewed by Filip Pizlo.

        In practice, we will always have multiple instructions after invalidation points,
        and have enough room in the JIT buffer for the invalidation point to work with.
        However, as a precaution, we can guarantee that there's enough room by always
        emitting a label just before we link the buffer.  The label will emit nop padding
        if needed.

        * assembler/LinkBuffer.cpp:
        (JSC::LinkBuffer::linkCode):

2017-02-23  Keith Miller  <keith_miller@apple.com>

        Unreviewed, fix the cloop build. Needed a #if.

        * jit/ExecutableAllocator.cpp:

2017-02-22  Carlos Garcia Campos  <cgarcia@igalia.com>

        Better handle Thread and RunLoop initialization
        https://bugs.webkit.org/show_bug.cgi?id=167828

        Reviewed by Yusuke Suzuki.

        * runtime/InitializeThreading.cpp:
        (JSC::initializeThreading): Do not initialize double_conversion, that is already initialized by WTF, and GC
        threads that will be initialized by WTF main thread when needed.

2017-02-22  JF Bastien  <jfbastien@apple.com>

        WebAssembly: clear out insignificant i32 bits when calling JavaScript
        https://bugs.webkit.org/show_bug.cgi?id=166677

        Reviewed by Keith Miller.

        When WebAssembly calls JavaScript it needs to clear out the
        insignificant bits of int32 values:

          +------------------- tag
          |  +---------------- insignificant
          |  |   +------------ 32-bit integer value
          |  |   |
          |--|---|-------|
        0xffff0000ffffffff

        At least some JavaScript code assumes that these bits are all
        zero. In the wasm-to-wasm.js example we store a 64-bit value in an
        object with lo / hi fields, each containing 32-bit integers. We
        then load these back, and the baseline compiler fails its
        comparison because it first checks the value are the same type
        (yes, because the int32 tag is set in both), and then whether they
        have the same value (no, because comparing the two registers
        fails). We could argue that the baseline compiler is wrong for
        performing a 64-bit comparison, but it doesn't really matter
        because there's not much of a point in breaking that invariant for
        WebAssembly's sake.

        * wasm/WasmBinding.cpp:
        (JSC::Wasm::wasmToJs):

2017-02-22  Keith Miller  <keith_miller@apple.com>

        Remove the demand executable allocator
        https://bugs.webkit.org/show_bug.cgi?id=168754

        Reviewed by Saam Barati.

        We currently only use the demand executable allocator for non-iOS 32-bit platforms.
        Benchmark results on a MBP indicate there is no appreciable performance difference
        between a the fixed and demand allocators. In a future patch I will go back through
        this code and remove more of the abstractions.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * jit/ExecutableAllocator.cpp:
        (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator):
        (JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps):
        (JSC::FixedVMPoolExecutableAllocator::jitWriteThunkGenerator):
        (JSC::FixedVMPoolExecutableAllocator::genericWriteToJITRegion):
        (JSC::ExecutableAllocator::initializeAllocator):
        (JSC::ExecutableAllocator::ExecutableAllocator):
        (JSC::FixedVMPoolExecutableAllocator::~FixedVMPoolExecutableAllocator):
        (JSC::ExecutableAllocator::isValid):
        (JSC::ExecutableAllocator::underMemoryPressure):
        (JSC::ExecutableAllocator::memoryPressureMultiplier):
        (JSC::ExecutableAllocator::allocate):
        (JSC::ExecutableAllocator::isValidExecutableMemory):
        (JSC::ExecutableAllocator::getLock):
        (JSC::ExecutableAllocator::committedByteCount):
        (JSC::ExecutableAllocator::dumpProfile):
        (JSC::DemandExecutableAllocator::DemandExecutableAllocator): Deleted.
        (JSC::DemandExecutableAllocator::~DemandExecutableAllocator): Deleted.
        (JSC::DemandExecutableAllocator::bytesAllocatedByAllAllocators): Deleted.
        (JSC::DemandExecutableAllocator::bytesCommittedByAllocactors): Deleted.
        (JSC::DemandExecutableAllocator::dumpProfileFromAllAllocators): Deleted.
        (JSC::DemandExecutableAllocator::allocateNewSpace): Deleted.
        (JSC::DemandExecutableAllocator::notifyNeedPage): Deleted.
        (JSC::DemandExecutableAllocator::notifyPageIsFree): Deleted.
        (JSC::DemandExecutableAllocator::allocators): Deleted.
        (JSC::DemandExecutableAllocator::allocatorsMutex): Deleted.
        * jit/ExecutableAllocator.h:
        * jit/ExecutableAllocatorFixedVMPool.cpp: Removed.
        * jit/JITStubRoutine.h:
        (JSC::JITStubRoutine::canPerformRangeFilter):
        (JSC::JITStubRoutine::filteringStartAddress):
        (JSC::JITStubRoutine::filteringExtentSize):

2017-02-22  Saam Barati  <sbarati@apple.com>

        Add biased coloring to Briggs and IRC
        https://bugs.webkit.org/show_bug.cgi?id=168611

        Reviewed by Filip Pizlo.

        This patch implements biased coloring as proposed by Briggs. See section
        5.3.3 of his thesis for more information: http://www.cs.utexas.edu/users/mckinley/380C/lecs/briggs-thesis-1992.pdf

        The main idea of biased coloring is this:
        We try to coalesce a move between u and v, but the conservative heuristic
        fails. We don't want coalesce the move because we don't want to risk
        creating an uncolorable graph. However, if the conservative heuristic fails,
        it's not proof that the graph is uncolorable if the move were indeed coalesced.
        So, when we go to color the tmps, we'll remember that we really want the
        same register for u and v, and if legal during coloring, we will
        assign them to the same register.

        * b3/air/AirAllocateRegistersByGraphColoring.cpp:

2017-02-22  Yusuke Suzuki  <utatane.tea@gmail.com>

        JSModuleNamespace object should have IC
        https://bugs.webkit.org/show_bug.cgi?id=160590

        Reviewed by Saam Barati.

        This patch optimizes accesses to module namespace objects.

        1. Cache the resolutions for module namespace objects.

            When constructing the module namespace object, we already resolves all the exports.
            The module namespace object caches this result and leverage it in the later access in
            getOwnPropertySlot. This avoids resolving bindings through resolveExport.

        2. Introduce ModuleNamespaceLoad IC.

            This patch adds new IC for module namespace objects. The mechanism is simple, getOwnPropertySlot
            tells us about module namespace object resolution. The IC first checks whether the given object
            is an expected module namespace object. If this check succeeds, we load the value from the module
            environment.

        3. Introduce DFG/FTL optimization.

            After exploiting module namespace object accesses in (2), DFG can recognize this in ByteCodeParser.
            DFG will convert it to CheckCell with the namespace object and GetClosureVar from the cached environment.
            At that time, we have a chance to fold it to the constant.

        This optimization improves the performance of accessing to module namespace objects.

        Before
            $ time ../../WebKitBuild/module-ic-tot/Release/bin/jsc -m module-assert-access-namespace.js
            ../../WebKitBuild/module-ic-tot/Release/bin/jsc -m   0.43s user 0.03s system 101% cpu 0.451 total
            $ time ../../WebKitBuild/module-ic-tot/Release/bin/jsc -m module-assert-access-binding.js
            ../../WebKitBuild/module-ic-tot/Release/bin/jsc -m   0.08s user 0.02s system 103% cpu 0.104 total

        After
            $ time ../../WebKitBuild/module-ic/Release/bin/jsc -m module-assert-access-namespace.js
            ../../WebKitBuild/module-ic/Release/bin/jsc -m   0.11s user 0.01s system 106% cpu 0.109 total
            $ time ../../WebKitBuild/module-ic/Release/bin/jsc -m module-assert-access-binding.js
            ../../WebKitBuild/module-ic/Release/bin/jsc -m module-assert-access-binding.j  0.08s user 0.02s system 102% cpu 0.105 total

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/AccessCase.cpp:
        (JSC::AccessCase::create):
        (JSC::AccessCase::guardedByStructureCheck):
        (JSC::AccessCase::canReplace):
        (JSC::AccessCase::visitWeak):
        (JSC::AccessCase::generateWithGuard):
        (JSC::AccessCase::generateImpl):
        * bytecode/AccessCase.h:
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::GetByIdStatus):
        (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
        (JSC::GetByIdStatus::makesCalls):
        (JSC::GetByIdStatus::dump):
        * bytecode/GetByIdStatus.h:
        (JSC::GetByIdStatus::isModuleNamespace):
        (JSC::GetByIdStatus::takesSlowPath):
        (JSC::GetByIdStatus::moduleNamespaceObject):
        (JSC::GetByIdStatus::moduleEnvironment):
        (JSC::GetByIdStatus::scopeOffset):
        * bytecode/ModuleNamespaceAccessCase.cpp: Added.
        (JSC::ModuleNamespaceAccessCase::ModuleNamespaceAccessCase):
        (JSC::ModuleNamespaceAccessCase::create):
        (JSC::ModuleNamespaceAccessCase::~ModuleNamespaceAccessCase):
        (JSC::ModuleNamespaceAccessCase::clone):
        (JSC::ModuleNamespaceAccessCase::emit):
        * bytecode/ModuleNamespaceAccessCase.h: Added.
        (JSC::ModuleNamespaceAccessCase::moduleNamespaceObject):
        (JSC::ModuleNamespaceAccessCase::moduleEnvironment):
        (JSC::ModuleNamespaceAccessCase::scopeOffset):
        * bytecode/PolymorphicAccess.cpp:
        (WTF::printInternal):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleModuleNamespaceLoad):
        (JSC::DFG::ByteCodeParser::handleGetById):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::loadValue):
        * jit/Repatch.cpp:
        (JSC::tryCacheGetByID):
        * runtime/AbstractModuleRecord.cpp:
        (JSC::AbstractModuleRecord::getModuleNamespace):
        * runtime/JSModuleNamespaceObject.cpp:
        (JSC::JSModuleNamespaceObject::finishCreation):
        (JSC::JSModuleNamespaceObject::visitChildren):
        (JSC::getValue):
        (JSC::JSModuleNamespaceObject::getOwnPropertySlot):
        (JSC::JSModuleNamespaceObject::getOwnPropertyNames):
        * runtime/JSModuleNamespaceObject.h:
        (JSC::isJSModuleNamespaceObject):
        (JSC::JSModuleNamespaceObject::create): Deleted.
        (JSC::JSModuleNamespaceObject::createStructure): Deleted.
        (JSC::JSModuleNamespaceObject::moduleRecord): Deleted.
        * runtime/JSModuleRecord.h:
        (JSC::JSModuleRecord::moduleEnvironment): Deleted.
        * runtime/PropertySlot.h:
        (JSC::PropertySlot::PropertySlot):
        (JSC::PropertySlot::domJIT):
        (JSC::PropertySlot::moduleNamespaceSlot):
        (JSC::PropertySlot::setValueModuleNamespace):
        (JSC::PropertySlot::setCacheableCustom):

2017-02-22  Saam Barati  <sbarati@apple.com>

        Unreviewed. Rename AirGraphColoring.* files to AirAllocateRegistersByGraphColoring.* to be more consistent with the rest of the Air file names.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/air/AirAllocateRegistersByGraphColoring.cpp: Copied from Source/JavaScriptCore/b3/air/AirGraphColoring.cpp.
        * b3/air/AirAllocateRegistersByGraphColoring.h: Copied from Source/JavaScriptCore/b3/air/AirGraphColoring.h.
        * b3/air/AirGenerate.cpp:
        * b3/air/AirGraphColoring.cpp: Removed.
        * b3/air/AirGraphColoring.h: Removed.

2017-02-21  Youenn Fablet  <youenn@apple.com>

        [WebRTC][Mac] Activate libwebrtc
        https://bugs.webkit.org/show_bug.cgi?id=167293
        <rdar://problem/30401864>

        Reviewed by Alex Christensen.

        * Configurations/FeatureDefines.xcconfig:

2017-02-21  Saam Barati  <sbarati@apple.com>

        Add the Briggs optimistic allocator to run on ARM64
        https://bugs.webkit.org/show_bug.cgi?id=168454

        Reviewed by Filip Pizlo.

        This patch adds the Briggs allocator to Air:
        http://www.cs.utexas.edu/users/mckinley/380C/lecs/briggs-thesis-1992.pdf
        It uses it by default on ARM64. I was measuring an 8-10% speedup
        in the phase because of this. I also wasn't able to detect a slowdown 
        for generated code on ARM64. There are still a few things we can do
        to speed things up even further. Moving the interference graph into
        a BitVector was another 10-20% speedup. We should consider doing this
        in a follow up patch. This is especially important now, since making
        register allocation faster has a direct impact on startup time for
        Wasm modules.
        
        I abstracted away the common bits between Briggs and IRC, and moved
        them into a common super class. In a follow up to this patch, I plan
        on implementing biased coloring for both Briggs and IRC (this is
        described in Briggs's thesis). I was able to detect a 1% slowdown
        with Briggs on Octane for x86-64. This is because the register file
        for x86-64 is smaller than ARM64. When I implemented biased coloring,
        I was no longer able to detect this slowdown. I still think it's a
        sensible plan to run Briggs on ARM64 and IRC on x86-64.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::prepareForGeneration):
        * b3/air/AirGraphColoring.cpp: Copied from Source/JavaScriptCore/b3/air/AirIteratedRegisterCoalescing.cpp.
        (JSC::B3::Air::allocateRegistersByGraphColoring):
        (JSC::B3::Air::iteratedRegisterCoalescing): Deleted.
        * b3/air/AirGraphColoring.h: Copied from Source/JavaScriptCore/b3/air/AirIteratedRegisterCoalescing.h.
        * b3/air/AirIteratedRegisterCoalescing.cpp: Removed.
        * b3/air/AirIteratedRegisterCoalescing.h: Removed.
        * runtime/Options.h:

2017-02-21  Mark Lam  <mark.lam@apple.com>

        Add more missing exception checks detected by running marathon.js.
        https://bugs.webkit.org/show_bug.cgi?id=168697

        Reviewed by Saam Barati.

        * runtime/StringPrototype.cpp:
        (JSC::replaceUsingRegExpSearch):
        (JSC::replaceUsingStringSearch):

2017-02-21  JF Bastien  <jfbastien@apple.com>

        FullCodeOrigin for CodeBlock+CodeOrigin printing
        https://bugs.webkit.org/show_bug.cgi?id=168673

        Reviewed by Filip Pizlo.

        WebAssembly doesn't have a CodeBlock, so printing it isn't
        valid. This patch adds FullCodeOrigin to handle the
        CodeBlock+CodeOrigin printing pattern, and uses it through all the
        places I could find, including Repatch.cpp where it's relevant for
        WebAssembly.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::noticeIncomingCall):
        * bytecode/FullCodeOrigin.cpp: Added.
        (JSC::FullCodeOrigin::dump):
        (JSC::FullCodeOrigin::dumpInContext):
        * bytecode/FullCodeOrigin.h: Added.
        (JSC::FullCodeOrigin::FullCodeOrigin):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::PolymorphicAccess::regenerate):
        * jit/PolymorphicCallStubRoutine.cpp:
        (JSC::PolymorphicCallStubRoutine::PolymorphicCallStubRoutine):
        * jit/Repatch.cpp:
        (JSC::linkFor):
        (JSC::linkDirectFor):
        (JSC::linkVirtualFor):

2017-02-21  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix cloop. I managed to have my local patch for relanding be the one without the cloop
        fix. I keep forgetting about cloop!

        * heap/Heap.cpp:
        (JSC::Heap::stopThePeriphery):
        * runtime/JSLock.cpp:

2017-02-21  Mark Lam  <mark.lam@apple.com>

        Add missing exception checks detected by running marathon.js.
        https://bugs.webkit.org/show_bug.cgi?id=168687

        Reviewed by Saam Barati.

        When running the marathon.js test from https://bugs.webkit.org/show_bug.cgi?id=168580,
        we get some crashes due to missing exception checks.  This patch adds those
        missing exception checks.

        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::toPropertyKey):
        * runtime/JSObject.cpp:
        (JSC::JSObject::getPrimitiveNumber):

2017-02-20  Filip Pizlo  <fpizlo@apple.com>

        The collector thread should only start when the mutator doesn't have heap access
        https://bugs.webkit.org/show_bug.cgi?id=167737

        Reviewed by Keith Miller.
        
        This turns the collector thread's workflow into a state machine, so that the mutator thread can
        run it directly. This reduces the amount of synchronization we do with the collector thread, and
        means that most apps will never start the collector thread. The collector thread will still start
        when we need to finish collecting and we don't have heap access.
        
        In this new world, "stopping the world" means relinquishing control of collection to the mutator.
        This means tracking who is conducting collection. I use the GCConductor enum to say who is
        conducting. It's either GCConductor::Mutator or GCConductor::Collector. I use the term "conn" to
        refer to the concept of conducting (having the conn, relinquishing the conn, taking the conn).
        So, stopping the world means giving the mutator the conn. Releasing heap access means giving the
        collector the conn.
        
        This meant bringing back the conservative scan of the calling thread. It turns out that this
        scan was too slow to be called on each GC increment because apparently setjmp() now does system
        calls. So, I wrote our own callee save register saving for the GC. Then I had doubts about
        whether or not it was correct, so I also made it so that the GC only rarely asks for the register
        state. I think we still want to use my register saving code instead of setjmp because setjmp
        seems to save things we don't need, and that could make us overly conservative.
        
        It turns out that this new scheduling discipline makes the old space-time scheduler perform
        better than the new stochastic space-time scheduler on systems with fewer than 4 cores. This is
        because the mutator having the conn enables us to time the mutator<->collector context switches
        by polling. The OS is never involved. So, we can use super precise timing. This allows the old
        space-time schduler to shine like it hadn't before.
        
        The splay results imply that this is all a good thing. On 2-core systems, this reduces pause
        times by 40% and it increases throughput about 5%. On 1-core systems, this reduces pause times by
        half and reduces throughput by 8%. On 4-or-more-core systems, this doesn't seem to have much
        effect.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::visitChildren):
        * dfg/DFGWorklist.cpp:
        (JSC::DFG::Worklist::ThreadBody::ThreadBody):
        (JSC::DFG::Worklist::dump):
        (JSC::DFG::numberOfWorklists):
        (JSC::DFG::ensureWorklistForIndex):
        (JSC::DFG::existingWorklistForIndexOrNull):
        (JSC::DFG::existingWorklistForIndex):
        * dfg/DFGWorklist.h:
        (JSC::DFG::numberOfWorklists): Deleted.
        (JSC::DFG::ensureWorklistForIndex): Deleted.
        (JSC::DFG::existingWorklistForIndexOrNull): Deleted.
        (JSC::DFG::existingWorklistForIndex): Deleted.
        * heap/CollectingScope.h: Added.
        (JSC::CollectingScope::CollectingScope):
        (JSC::CollectingScope::~CollectingScope):
        * heap/CollectorPhase.cpp: Added.
        (JSC::worldShouldBeSuspended):
        (WTF::printInternal):
        * heap/CollectorPhase.h: Added.
        * heap/EdenGCActivityCallback.cpp:
        (JSC::EdenGCActivityCallback::lastGCLength):
        * heap/FullGCActivityCallback.cpp:
        (JSC::FullGCActivityCallback::doCollection):
        (JSC::FullGCActivityCallback::lastGCLength):
        * heap/GCConductor.cpp: Added.
        (JSC::gcConductorShortName):
        (WTF::printInternal):
        * heap/GCConductor.h: Added.
        * heap/GCFinalizationCallback.cpp: Added.
        (JSC::GCFinalizationCallback::GCFinalizationCallback):
        (JSC::GCFinalizationCallback::~GCFinalizationCallback):
        * heap/GCFinalizationCallback.h: Added.
        (JSC::GCFinalizationCallbackFuncAdaptor::GCFinalizationCallbackFuncAdaptor):
        (JSC::createGCFinalizationCallback):
        * heap/Heap.cpp:
        (JSC::Heap::Thread::Thread):
        (JSC::Heap::Heap):
        (JSC::Heap::lastChanceToFinalize):
        (JSC::Heap::gatherStackRoots):
        (JSC::Heap::updateObjectCounts):
        (JSC::Heap::sweepSynchronously):
        (JSC::Heap::collectAllGarbage):
        (JSC::Heap::collectAsync):
        (JSC::Heap::collectSync):
        (JSC::Heap::shouldCollectInCollectorThread):
        (JSC::Heap::collectInCollectorThread):
        (JSC::Heap::checkConn):
        (JSC::Heap::runNotRunningPhase):
        (JSC::Heap::runBeginPhase):
        (JSC::Heap::runFixpointPhase):
        (JSC::Heap::runConcurrentPhase):
        (JSC::Heap::runReloopPhase):
        (JSC::Heap::runEndPhase):
        (JSC::Heap::changePhase):
        (JSC::Heap::finishChangingPhase):
        (JSC::Heap::stopThePeriphery):
        (JSC::Heap::resumeThePeriphery):
        (JSC::Heap::stopTheMutator):
        (JSC::Heap::resumeTheMutator):
        (JSC::Heap::stopIfNecessarySlow):
        (JSC::Heap::collectInMutatorThread):
        (JSC::Heap::waitForCollector):
        (JSC::Heap::acquireAccessSlow):
        (JSC::Heap::releaseAccessSlow):
        (JSC::Heap::relinquishConn):
        (JSC::Heap::finishRelinquishingConn):
        (JSC::Heap::handleNeedFinalize):
        (JSC::Heap::notifyThreadStopping):
        (JSC::Heap::finalize):
        (JSC::Heap::addFinalizationCallback):
        (JSC::Heap::requestCollection):
        (JSC::Heap::waitForCollection):
        (JSC::Heap::updateAllocationLimits):
        (JSC::Heap::didFinishCollection):
        (JSC::Heap::collectIfNecessaryOrDefer):
        (JSC::Heap::notifyIsSafeToCollect):
        (JSC::Heap::preventCollection):
        (JSC::Heap::performIncrement):
        (JSC::Heap::markToFixpoint): Deleted.
        (JSC::Heap::shouldCollectInThread): Deleted.
        (JSC::Heap::collectInThread): Deleted.
        (JSC::Heap::stopTheWorld): Deleted.
        (JSC::Heap::resumeTheWorld): Deleted.
        * heap/Heap.h:
        (JSC::Heap::machineThreads):
        (JSC::Heap::lastFullGCLength):
        (JSC::Heap::lastEdenGCLength):
        (JSC::Heap::increaseLastFullGCLength):
        * heap/HeapInlines.h:
        (JSC::Heap::mutatorIsStopped): Deleted.
        * heap/HeapStatistics.cpp: Removed.
        * heap/HeapStatistics.h: Removed.
        * heap/HelpingGCScope.h: Removed.
        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::stopSweeping):
        (JSC::IncrementalSweeper::willFinishSweeping): Deleted.
        * heap/IncrementalSweeper.h:
        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::gatherFromCurrentThread):
        (JSC::MachineThreads::gatherConservativeRoots):
        (JSC::callWithCurrentThreadState):
        * heap/MachineStackMarker.h:
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::allocateSlowCaseImpl):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::Handle::sweep):
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::sweep):
        * heap/MutatorState.cpp:
        (WTF::printInternal):
        * heap/MutatorState.h:
        * heap/RegisterState.h: Added.
        * heap/RunningScope.h: Added.
        (JSC::RunningScope::RunningScope):
        (JSC::RunningScope::~RunningScope):
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::SlotVisitor):
        (JSC::SlotVisitor::drain):
        (JSC::SlotVisitor::drainFromShared):
        (JSC::SlotVisitor::drainInParallelPassively):
        (JSC::SlotVisitor::donateAll):
        (JSC::SlotVisitor::donate):
        * heap/SlotVisitor.h:
        (JSC::SlotVisitor::codeName):
        * heap/StochasticSpaceTimeMutatorScheduler.cpp:
        (JSC::StochasticSpaceTimeMutatorScheduler::beginCollection):
        (JSC::StochasticSpaceTimeMutatorScheduler::synchronousDrainingDidStall):
        (JSC::StochasticSpaceTimeMutatorScheduler::timeToStop):
        * heap/SweepingScope.h: Added.
        (JSC::SweepingScope::SweepingScope):
        (JSC::SweepingScope::~SweepingScope):
        * jit/JITWorklist.cpp:
        (JSC::JITWorklist::Thread::Thread):
        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionFlashHeapAccess):
        * runtime/InitializeThreading.cpp:
        (JSC::initializeThreading):
        * runtime/JSCellInlines.h:
        (JSC::JSCell::classInfo):
        * runtime/Options.cpp:
        (JSC::overrideDefaults):
        * runtime/Options.h:
        * runtime/TestRunnerUtils.cpp:
        (JSC::finalizeStatsAtEndOfTesting):

2017-02-21  Saam Barati  <sbarati@apple.com>

        Air should have a disassembly mode that dumps IR and assembly intermixed
        https://bugs.webkit.org/show_bug.cgi?id=168629

        Reviewed by Filip Pizlo.

        This will make dumping FTL disassembly dump Air intermixed
        with the assembly generated by each Air Inst. This is similar
        to how dumpDFGDisassembly dumps the generated assembly for each
        Node.
        
        Here is what the output will look like:
        
        Generated FTL JIT code for foo#CUaFiQ:[0x10b76c960->0x10b76c2d0->0x10b7b6da0, FTLFunctionCall, 40 (NeverInline)], instruction count = 40:
        BB#0: ; frequency = 1.000000
                0x469004e02e00: push %rbp
                0x469004e02e01: mov %rsp, %rbp
                0x469004e02e04: add $0xffffffffffffffd0, %rsp
            Move $0x10b76c960, %rax, $4487301472(@16)
                0x469004e02e08: mov $0x10b76c960, %rax
            Move %rax, 16(%rbp), @19
                0x469004e02e12: mov %rax, 0x10(%rbp)
            Patch &Patchpoint2, %rbp, %rax, @20
                0x469004e02e16: lea -0x50(%rbp), %rax
                0x469004e02e1a: mov $0x1084081e0, %r11
                0x469004e02e24: cmp %rax, (%r11)
                0x469004e02e27: ja 0x469004e02e9a
            Move 56(%rbp), %rdx, @23
                0x469004e02e2d: mov 0x38(%rbp), %rdx
            Move $0xffff000000000002, %rax, $-281474976710654(@15)
                0x469004e02e31: mov $0xffff000000000002, %rax
            Patch &BranchTest64(3,SameAsRep)1, NonZero, %rdx, %rax, %rdx, @26
                0x469004e02e3b: test %rdx, %rax
                0x469004e02e3e: jnz 0x469004e02f08
            Move 48(%rbp), %rax, @29
                0x469004e02e44: mov 0x30(%rbp), %rax
            Move %rax, %rcx, @31
                0x469004e02e48: mov %rax, %rcx
            Xor64 $6, %rcx, @31
                0x469004e02e4b: xor $0x6, %rcx
            Patch &BranchTest64(3,SameAsRep)1, NonZero, %rcx, $-2, %rax, @35
                0x469004e02e4f: test $0xfffffffffffffffe, %rcx
                0x469004e02e56: jnz 0x469004e02f12
            Patch &Branch32(3,SameAsRep)0, NotEqual, (%rdx), $266, %rdx, @45
                0x469004e02e5c: cmp $0x10a, (%rdx)
                0x469004e02e62: jnz 0x469004e02f1c
            BranchTest32 NonZero, %rax, $1, @49
                0x469004e02e68: test $0x1, %al
                0x469004e02e6a: jnz 0x469004e02e91
          Successors: #3, #1
        BB#1: ; frequency = 1.000000
          Predecessors: #0
            Move $0, %rcx, @65
                0x469004e02e70: xor %rcx, %rcx
            Jump @66
          Successors: #2
        BB#2: ; frequency = 1.000000
          Predecessors: #1, #3
            Move 24(%rdx), %rax, @58
                0x469004e02e73: mov 0x18(%rdx), %rax
            Patch &BranchAdd32(4,ForceLateUseUnlessRecoverable)3, Overflow, %rcx, %rax, %rcx, %rcx, %rax, @60
                0x469004e02e77: add %eax, %ecx
                0x469004e02e79: jo 0x469004e02f26
            Move $0xffff000000000000, %rax, $-281474976710656(@14)
                0x469004e02e7f: mov $0xffff000000000000, %rax
            Add64 %rcx, %rax, %rax, @62
                0x469004e02e89: add %rcx, %rax
            Ret64 %rax, @63
                0x469004e02e8c: mov %rbp, %rsp
                0x469004e02e8f: pop %rbp
                0x469004e02e90: ret 
        BB#3: ; frequency = 1.000000
          Predecessors: #0
            Move 16(%rdx), %rcx, @52
                0x469004e02e91: mov 0x10(%rdx), %rcx
            Jump @55
                0x469004e02e95: jmp 0x469004e02e73
          Successors: #2

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::setDisassembler):
        (JSC::B3::Air::Code::disassembler):
        * b3/air/AirDisassembler.cpp: Added.
        (JSC::B3::Air::Disassembler::startEntrypoint):
        (JSC::B3::Air::Disassembler::endEntrypoint):
        (JSC::B3::Air::Disassembler::startLatePath):
        (JSC::B3::Air::Disassembler::endLatePath):
        (JSC::B3::Air::Disassembler::startBlock):
        (JSC::B3::Air::Disassembler::addInst):
        (JSC::B3::Air::Disassembler::dump):
        * b3/air/AirDisassembler.h: Added.
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::generate):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):

2017-02-21  Ryan Haddad  <ryanhaddad@apple.com>

        Unreviewed, rolling out r212712.

        This change broke the CLoop build.

        Reverted changeset:

        "JSModuleNamespace object should have IC"
        https://bugs.webkit.org/show_bug.cgi?id=160590
        http://trac.webkit.org/changeset/212712

2017-02-21  Yusuke Suzuki  <utatane.tea@gmail.com>

        JSModuleNamespace object should have IC
        https://bugs.webkit.org/show_bug.cgi?id=160590

        Reviewed by Saam Barati.

        This patch optimizes accesses to module namespace objects.

        1. Cache the resolutions for module namespace objects.

            When constructing the module namespace object, we already resolves all the exports.
            The module namespace object caches this result and leverage it in the later access in
            getOwnPropertySlot. This avoids resolving bindings through resolveExport.

        2. Introduce ModuleNamespaceLoad IC.

            This patch adds new IC for module namespace objects. The mechanism is simple, getOwnPropertySlot
            tells us about module namespace object resolution. The IC first checks whether the given object
            is an expected module namespace object. If this check succeeds, we load the value from the module
            environment.

        3. Introduce DFG/FTL optimization.

            After exploiting module namespace object accesses in (2), DFG can recognize this in ByteCodeParser.
            DFG will convert it to CheckCell with the namespace object and GetClosureVar from the cached environment.
            At that time, we have a chance to fold it to the constant.

        This optimization improves the performance of accessing to module namespace objects.

        Before
            $ time ../../WebKitBuild/module-ic-tot/Release/bin/jsc -m module-assert-access-namespace.js
            ../../WebKitBuild/module-ic-tot/Release/bin/jsc -m   0.43s user 0.03s system 101% cpu 0.451 total
            $ time ../../WebKitBuild/module-ic-tot/Release/bin/jsc -m module-assert-access-binding.js
            ../../WebKitBuild/module-ic-tot/Release/bin/jsc -m   0.08s user 0.02s system 103% cpu 0.104 total

        After
            $ time ../../WebKitBuild/module-ic/Release/bin/jsc -m module-assert-access-namespace.js
            ../../WebKitBuild/module-ic/Release/bin/jsc -m   0.11s user 0.01s system 106% cpu 0.109 total
            $ time ../../WebKitBuild/module-ic/Release/bin/jsc -m module-assert-access-binding.js
            ../../WebKitBuild/module-ic/Release/bin/jsc -m module-assert-access-binding.j  0.08s user 0.02s system 102% cpu 0.105 total

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/AccessCase.cpp:
        (JSC::AccessCase::create):
        (JSC::AccessCase::guardedByStructureCheck):
        (JSC::AccessCase::canReplace):
        (JSC::AccessCase::visitWeak):
        (JSC::AccessCase::generateWithGuard):
        (JSC::AccessCase::generateImpl):
        * bytecode/AccessCase.h:
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::GetByIdStatus):
        (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
        (JSC::GetByIdStatus::makesCalls):
        (JSC::GetByIdStatus::dump):
        * bytecode/GetByIdStatus.h:
        (JSC::GetByIdStatus::isModuleNamespace):
        (JSC::GetByIdStatus::takesSlowPath):
        (JSC::GetByIdStatus::moduleNamespaceObject):
        (JSC::GetByIdStatus::moduleEnvironment):
        (JSC::GetByIdStatus::scopeOffset):
        * bytecode/ModuleNamespaceAccessCase.cpp: Added.
        (JSC::ModuleNamespaceAccessCase::ModuleNamespaceAccessCase):
        (JSC::ModuleNamespaceAccessCase::create):
        (JSC::ModuleNamespaceAccessCase::~ModuleNamespaceAccessCase):
        (JSC::ModuleNamespaceAccessCase::clone):
        (JSC::ModuleNamespaceAccessCase::emit):
        * bytecode/ModuleNamespaceAccessCase.h: Added.
        (JSC::ModuleNamespaceAccessCase::moduleNamespaceObject):
        (JSC::ModuleNamespaceAccessCase::moduleEnvironment):
        (JSC::ModuleNamespaceAccessCase::scopeOffset):
        * bytecode/PolymorphicAccess.cpp:
        (WTF::printInternal):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleModuleNamespaceLoad):
        (JSC::DFG::ByteCodeParser::handleGetById):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::loadValue):
        * jit/Repatch.cpp:
        (JSC::tryCacheGetByID):
        * runtime/AbstractModuleRecord.cpp:
        (JSC::AbstractModuleRecord::getModuleNamespace):
        * runtime/JSModuleNamespaceObject.cpp:
        (JSC::JSModuleNamespaceObject::finishCreation):
        (JSC::JSModuleNamespaceObject::visitChildren):
        (JSC::getValue):
        (JSC::JSModuleNamespaceObject::getOwnPropertySlot):
        (JSC::JSModuleNamespaceObject::getOwnPropertyNames):
        * runtime/JSModuleNamespaceObject.h:
        (JSC::isJSModuleNamespaceObject):
        (JSC::JSModuleNamespaceObject::create): Deleted.
        (JSC::JSModuleNamespaceObject::createStructure): Deleted.
        (JSC::JSModuleNamespaceObject::moduleRecord): Deleted.
        * runtime/JSModuleRecord.h:
        (JSC::JSModuleRecord::moduleEnvironment): Deleted.
        * runtime/PropertySlot.h:
        (JSC::PropertySlot::PropertySlot):
        (JSC::PropertySlot::domJIT):
        (JSC::PropertySlot::moduleNamespaceSlot):
        (JSC::PropertySlot::setValueModuleNamespace):
        (JSC::PropertySlot::setCacheableCustom):

2017-02-21  Yusuke Suzuki  <utatane.tea@gmail.com>

        ASSERTION FAILED: "!scope.exception()" with Object.isSealed/isFrozen and uninitialized module bindings
        https://bugs.webkit.org/show_bug.cgi?id=168605

        Reviewed by Saam Barati.

        We should check exception state after calling getOwnPropertyDescriptor() since it can throw errors.

        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorIsSealed):
        (JSC::objectConstructorIsFrozen):

2017-02-20  Mark Lam  <mark.lam@apple.com>

        [Re-landing] CachedCall should let GC know to keep its arguments alive.
        https://bugs.webkit.org/show_bug.cgi?id=168567
        <rdar://problem/30475767>

        Reviewed by Saam Barati.

        We fix this by having CachedCall use a MarkedArgumentBuffer to store its
        arguments instead of a Vector.

        Also declared CachedCall, MarkedArgumentBuffer, and ProtoCallFrame as
        WTF_FORBID_HEAP_ALLOCATION because they rely on being stack allocated for
        correctness.

        Update: the original patch has a bug in MarkedArgumentBuffer::expandCapacity()
        where it was copying and calling addMarkSet() on values in m_buffer beyond m_size
        (up to m_capacity).  As a result, depending on the pre-existing values in
        m_inlineBuffer, this may result in a computed Heap pointer that is wrong, and
        subsequently, manifest as a crash.  This is likely to be the cause of the PLT
        regression.

        I don't have a new test for this fix because the issue relies on sufficiently bad
        values randomly showing up in m_inlineBuffer when we do an ensureCapacity() which
        calls expandCapacity().

        * interpreter/CachedCall.h:
        (JSC::CachedCall::CachedCall):
        (JSC::CachedCall::call):
        (JSC::CachedCall::clearArguments):
        (JSC::CachedCall::appendArgument):
        (JSC::CachedCall::setArgument): Deleted.
        * interpreter/CallFrame.h:
        (JSC::ExecState::emptyList):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::prepareForRepeatCall):
        * interpreter/Interpreter.h:
        * interpreter/ProtoCallFrame.h:
        * runtime/ArgList.cpp:
        (JSC::MarkedArgumentBuffer::slowEnsureCapacity):
        (JSC::MarkedArgumentBuffer::expandCapacity):
        (JSC::MarkedArgumentBuffer::slowAppend):
        * runtime/ArgList.h:
        (JSC::MarkedArgumentBuffer::append):
        (JSC::MarkedArgumentBuffer::ensureCapacity):
        * runtime/StringPrototype.cpp:
        (JSC::replaceUsingRegExpSearch):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2017-02-20  Commit Queue  <commit-queue@webkit.org>

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

        "Appears to cause PLT regression" (Requested by mlam on
        #webkit).

        Reverted changeset:

        "CachedCall should let GC know to keep its arguments alive."
        https://bugs.webkit.org/show_bug.cgi?id=168567
        http://trac.webkit.org/changeset/212618

2017-02-19  Mark Lam  <mark.lam@apple.com>

        BytecodeGenerator should not iterate its m_controlFlowScopeStack using a pointer bump.
        https://bugs.webkit.org/show_bug.cgi?id=168585

        Reviewed by Yusuke Suzuki.

        This is because m_controlFlowScopeStack is a SegmentedVector, and entries for
        consecutive indices in the vector are not guaranteed to be consecutive in memory
        layout.  Instead, we should be using indexing instead.

        This issue was detected by the marathon.js test from
        https://bugs.webkit.org/show_bug.cgi?id=168580.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
        (JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):

2017-02-20  Manuel Rego Casasnovas  <rego@igalia.com>

        [css-grid] Remove compilation flag ENABLE_CSS_GRID_LAYOUT
        https://bugs.webkit.org/show_bug.cgi?id=167693

        Reviewed by Sergio Villar Senin.

        * Configurations/FeatureDefines.xcconfig:

2017-02-19  Commit Queue  <commit-queue@webkit.org>

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

        Broke CLoop builds when r212466 was rolled out in r212616
        (Requested by rniwa on #webkit).

        Reverted changeset:

        "Unreviewed, fix cloop build."
        http://trac.webkit.org/changeset/212472

2017-02-19  Mark Lam  <mark.lam@apple.com>

        functionTestWasmModuleFunctions() should use a MarkedArgumentBuffer for storing args instead of a Vector.
        https://bugs.webkit.org/show_bug.cgi?id=168574

        Reviewed by Filip Pizlo.

        * jsc.cpp:
        (callWasmFunction):
        (functionTestWasmModuleFunctions):
        * runtime/ArgList.h:

2017-02-19  Mark Lam  <mark.lam@apple.com>

        CachedCall should let GC know to keep its arguments alive.
        https://bugs.webkit.org/show_bug.cgi?id=168567
        <rdar://problem/30475767>

        Reviewed by Saam Barati.

        We fix this by having CachedCall use a MarkedArgumentBuffer to store its
        arguments instead of a Vector.

        Also declared CachedCall, MarkedArgumentBuffer, and ProtoCallFrame as
        WTF_FORBID_HEAP_ALLOCATION because they rely on being stack allocated for
        correctness.

        * interpreter/CachedCall.h:
        (JSC::CachedCall::CachedCall):
        (JSC::CachedCall::call):
        (JSC::CachedCall::clearArguments):
        (JSC::CachedCall::appendArgument):
        (JSC::CachedCall::setArgument): Deleted.
        * interpreter/CallFrame.h:
        (JSC::ExecState::emptyList):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::prepareForRepeatCall):
        * interpreter/Interpreter.h:
        * interpreter/ProtoCallFrame.h:
        * runtime/ArgList.cpp:
        (JSC::MarkedArgumentBuffer::expandCapacity):
        * runtime/ArgList.h:
        (JSC::MarkedArgumentBuffer::ensureCapacity):
        * runtime/StringPrototype.cpp:
        (JSC::replaceUsingRegExpSearch):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2017-02-19  Commit Queue  <commit-queue@webkit.org>

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

        causes crashes on AArch64 on linux, maybe it's causing crashes
        on iOS too (Requested by pizlo on #webkit).

        Reverted changeset:

        "The collector thread should only start when the mutator
        doesn't have heap access"
        https://bugs.webkit.org/show_bug.cgi?id=167737
        http://trac.webkit.org/changeset/212466

2017-02-17  Michael Saboff  <msaboff@apple.com>

        Improve ARM64 disassembler handling of pseudo ops, unsupported opcodes and zero reg
        https://bugs.webkit.org/show_bug.cgi?id=168527

        Reviewed by Filip Pizlo.

        Added support for data processing 1 source instructions like rbit, rev, clz and cls.
        Added support for the FP conditional select instruction, fcsel.  Consolidated the
        two classes for handling dmb instructions into one class.  Fixed the instruction
        selection mask in the integer conditional select class, A64DOpcodeConditionalSelect.
        Fixed the processing of extract instruction (extr) including the rotate right (ror)
        pseudo instruction.  Changed the printing of x31 and w31 to xzr and wzr as operands
        according to the spec.  Added support for common pseudo instructions.  This includes:
        - mvn x1, X2 in place of orn x1, xzr, x2
        - lsl x3, x4, #count in place of ubfiz x3, x4, #count, #count
        - smull x5, w6, w7 in place of smaddl x5, w6, w7, XZR
        - More understandable mov x8, #-304 in place of movn x8, #0x12f
        - Eliminated xzr from register index loads and stores, outputing
          ldr x10, [x11] instead of ldr x10, [x11, xzr]

        Changed the move wide instructions to use hex literals for movz and movk.
        This makes it much easier to decifer sequences of wide moves for large literals.
                Before                       After
          movz   x17, #26136           movz   x17, #0x6618
          movk   x17, #672, lsl #16    movk   x17, #0x2a0, lsl #16
          movk   x17, #1, lsl #32      movk   x17, #0x1, lsl #32

        Verified that all instructions currently generated by the JSC stress tests are
        disassembled.

        * disassembler/ARM64/A64DOpcode.cpp:
        (JSC::ARM64Disassembler::A64DOpcodeBitfield::format):
        (JSC::ARM64Disassembler::A64DOpcodeDataProcessing1Source::format):
        (JSC::ARM64Disassembler::A64DOpcodeDataProcessing2Source::format):
        (JSC::ARM64Disassembler::A64DOpcodeDataProcessing3Source::format):
        (JSC::ARM64Disassembler::A64DOpcodeExtract::format):
        (JSC::ARM64Disassembler::A64DOpcodeFloatingPointConditionalSelect::format):
        (JSC::ARM64Disassembler::A64DOpcodeFloatingPointIntegerConversions::format):
        (JSC::ARM64Disassembler::A64DOpcodeDmb::format):
        (JSC::ARM64Disassembler::A64DOpcodeLoadStoreImmediate::format):
        (JSC::ARM64Disassembler::A64DOpcodeLoadStoreRegisterOffset::format):
        (JSC::ARM64Disassembler::A64DOpcodeLoadStoreRegisterPair::format):
        (JSC::ARM64Disassembler::A64DOpcodeLoadStoreUnsignedImmediate::format):
        (JSC::ARM64Disassembler::A64DOpcodeLogicalShiftedRegister::format):
        (JSC::ARM64Disassembler::A64DOpcodeMoveWide::format):
        (JSC::ARM64Disassembler::A64DOpcodeDmbIsh::format): Deleted.
        (JSC::ARM64Disassembler::A64DOpcodeDmbIshSt::format): Deleted.
        * disassembler/ARM64/A64DOpcode.h:
        (JSC::ARM64Disassembler::A64DOpcode::appendSignedImmediate64):
        (JSC::ARM64Disassembler::A64DOpcode::appendUnsignedHexImmediate):
        (JSC::ARM64Disassembler::A64DOpcodeDataProcessing1Source::opName):
        (JSC::ARM64Disassembler::A64DOpcodeDataProcessing1Source::sBit):
        (JSC::ARM64Disassembler::A64DOpcodeDataProcessing1Source::opCode):
        (JSC::ARM64Disassembler::A64DOpcodeDataProcessing1Source::opCode2):
        (JSC::ARM64Disassembler::A64DOpcodeDataProcessing1Source::opNameIndex):
        (JSC::ARM64Disassembler::A64DOpcodeDataProcessing3Source::opName):
        (JSC::ARM64Disassembler::A64DOpcodeFloatingPointConditionalSelect::opName):
        (JSC::ARM64Disassembler::A64DOpcodeFloatingPointConditionalSelect::condition):
        (JSC::ARM64Disassembler::A64DOpcodeDmb::option):
        (JSC::ARM64Disassembler::A64DOpcodeDmb::crM):
        (JSC::ARM64Disassembler::A64DOpcodeLogicalShiftedRegister::isMov):
        (JSC::ARM64Disassembler::A64DOpcodeDmbIsh::opName): Deleted.
        (JSC::ARM64Disassembler::A64DOpcodeDmbIshSt::opName): Deleted.

2017-02-17  Zan Dobersek  <zdobersek@igalia.com>

        [GLib] GCActivityCallback::scheduleTimer() keeps pushing dispatch into the future
        https://bugs.webkit.org/show_bug.cgi?id=168363

        Reviewed by Carlos Garcia Campos.

        Mimic the USE(CF) implementation of GCActivityCallback and HeapTimer by
        scheduling the timer a decade into the future instead of completely
        cancelling it. That way new dispatch times for GCActivityCallback can be
        computed by simply deducting the difference in the new and previous
        delay from the GSource's current dispatch time. Previously we handled an
        extra 'paused' state (where m_delay was -1) and allowed for a delay of
        an infinite value to be valid, complicating the next dispatch time
        computation.

        HeapTimer gains the static s_decade variable. The dispatch function in
        heapTimerSourceFunctions only dispatches the callback, which now delays
        the GSource by a decade. HeapTimer::scheduleTimer() simply schedules the
        source to dispatch in the specified amount of time, and cancelTimer()
        'cancels' the source by setting the dispatch time to a decade.

        GCActivityCallback constructor initializes the delay to the s_decade
        value and immediately sets the ready time for GSource a decade into the
        future, avoiding the default -1 value as the ready time that would cause
        problems in scheduleTimer(). scheduleTimer() doesn't special-case the
        zero-delay value anymore, instead it just computes the difference
        between the old and the new delay and rolls back the GSource's ready
        time for that amount. cancelTimer() sets m_delay to the decade value and
        delays the GSource for that same amount.

        * heap/GCActivityCallback.cpp:
        (JSC::GCActivityCallback::GCActivityCallback):
        (JSC::GCActivityCallback::scheduleTimer):
        (JSC::GCActivityCallback::cancelTimer):
        * heap/GCActivityCallback.h:
        * heap/HeapTimer.cpp:
        (JSC::HeapTimer::HeapTimer):
        (JSC::HeapTimer::scheduleTimer):
        (JSC::HeapTimer::cancelTimer):
        * heap/HeapTimer.h:

2017-02-16  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Drop PassRefPtr from ArrayBuffer
        https://bugs.webkit.org/show_bug.cgi?id=168455

        Reviewed by Geoffrey Garen.

        This patch finally drops all the PassRefPtr in JSC.
        We changed PassRefPtr<ArrayBuffer> to RefPtr<ArrayBuffer>&&.
        Since ArrayBuffer may be nullptr if the array is neutered,
        we hold it as RefPtr<> instead of Ref<>.

        And we also drops 2 files, TypedArrayBase.h and IntegralTypedArrayBase.h.
        They are not used (and they are not referenced from the project file).

        * inspector/JavaScriptCallFrame.h:
        * jsc.cpp:
        (functionDollarAgentReceiveBroadcast):
        * runtime/ArrayBufferView.cpp:
        (JSC::ArrayBufferView::ArrayBufferView):
        * runtime/ArrayBufferView.h:
        (JSC::ArrayBufferView::possiblySharedBuffer):
        (JSC::ArrayBufferView::unsharedBuffer):
        (JSC::ArrayBufferView::verifySubRangeLength):
        (JSC::ArrayBufferView::clampOffsetAndNumElements):
        * runtime/ClassInfo.h:
        * runtime/DataView.cpp:
        (JSC::DataView::DataView):
        (JSC::DataView::create):
        * runtime/DataView.h:
        * runtime/GenericTypedArrayView.h:
        * runtime/GenericTypedArrayViewInlines.h:
        (JSC::GenericTypedArrayView<Adaptor>::GenericTypedArrayView):
        (JSC::GenericTypedArrayView<Adaptor>::create):
        (JSC::GenericTypedArrayView<Adaptor>::subarray):
        * runtime/IntegralTypedArrayBase.h: Removed.
        * runtime/JSArrayBuffer.cpp:
        (JSC::JSArrayBuffer::JSArrayBuffer):
        (JSC::JSArrayBuffer::create):
        * runtime/JSArrayBuffer.h:
        * runtime/JSArrayBufferPrototype.cpp:
        (JSC::arrayBufferProtoFuncSlice):
        * runtime/JSArrayBufferView.cpp:
        (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
        * runtime/JSArrayBufferView.h:
        * runtime/JSArrayBufferViewInlines.h:
        (JSC::JSArrayBufferView::possiblySharedImpl):
        (JSC::JSArrayBufferView::unsharedImpl):
        * runtime/JSCell.cpp:
        (JSC::JSCell::slowDownAndWasteMemory):
        (JSC::JSCell::getTypedArrayImpl):
        * runtime/JSCell.h:
        * runtime/JSDataView.cpp:
        (JSC::JSDataView::create):
        (JSC::JSDataView::possiblySharedTypedImpl):
        (JSC::JSDataView::unsharedTypedImpl):
        (JSC::JSDataView::getTypedArrayImpl):
        * runtime/JSDataView.h:
        * runtime/JSGenericTypedArrayView.h:
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::constructGenericTypedArrayViewWithArguments):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::create):
        (JSC::JSGenericTypedArrayView<Adaptor>::possiblySharedTypedImpl):
        (JSC::JSGenericTypedArrayView<Adaptor>::unsharedTypedImpl):
        (JSC::JSGenericTypedArrayView<Adaptor>::getTypedArrayImpl):
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
        * runtime/JSTypedArrays.cpp:
        (JSC::createUint8TypedArray):
        * runtime/TypedArrayBase.h: Removed.

2017-02-16  Keith Miller  <keith_miller@apple.com>

        ASSERTION FAILED: vm.heap.mutatorState() == MutatorState::Running || vm.apiLock().ownerThread() != std::this_thread::get_id()
        https://bugs.webkit.org/show_bug.cgi?id=168354

        Reviewed by Geoffrey Garen.

        Instead of adding a custom vmEntryGlobalObject for the debugger
        we can just have it use vmEntryScope instead.

        * debugger/Debugger.cpp:
        (JSC::Debugger::detach):
        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::vmEntryGlobalObjectForDebuggerDetach): Deleted.
        * interpreter/CallFrame.h:

2017-02-16  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix cloop build.

        * heap/Heap.cpp:
        (JSC::Heap::stopThePeriphery):
        * runtime/JSLock.cpp:

2017-02-10  Filip Pizlo  <fpizlo@apple.com>

        The collector thread should only start when the mutator doesn't have heap access
        https://bugs.webkit.org/show_bug.cgi?id=167737

        Reviewed by Keith Miller.
        
        This turns the collector thread's workflow into a state machine, so that the mutator thread can
        run it directly. This reduces the amount of synchronization we do with the collector thread, and
        means that most apps will never start the collector thread. The collector thread will still start
        when we need to finish collecting and we don't have heap access.
        
        In this new world, "stopping the world" means relinquishing control of collection to the mutator.
        This means tracking who is conducting collection. I use the GCConductor enum to say who is
        conducting. It's either GCConductor::Mutator or GCConductor::Collector. I use the term "conn" to
        refer to the concept of conducting (having the conn, relinquishing the conn, taking the conn).
        So, stopping the world means giving the mutator the conn. Releasing heap access means giving the
        collector the conn.
        
        This meant bringing back the conservative scan of the calling thread. It turns out that this
        scan was too slow to be called on each GC increment because apparently setjmp() now does system
        calls. So, I wrote our own callee save register saving for the GC. Then I had doubts about
        whether or not it was correct, so I also made it so that the GC only rarely asks for the register
        state. I think we still want to use my register saving code instead of setjmp because setjmp
        seems to save things we don't need, and that could make us overly conservative.
        
        It turns out that this new scheduling discipline makes the old space-time scheduler perform
        better than the new stochastic space-time scheduler on systems with fewer than 4 cores. This is
        because the mutator having the conn enables us to time the mutator<->collector context switches
        by polling. The OS is never involved. So, we can use super precise timing. This allows the old
        space-time schduler to shine like it hadn't before.
        
        The splay results imply that this is all a good thing. On 2-core systems, this reduces pause
        times by 40% and it increases throughput about 5%. On 1-core systems, this reduces pause times by
        half and reduces throughput by 8%. On 4-or-more-core systems, this doesn't seem to have much
        effect.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGWorklist.cpp:
        (JSC::DFG::Worklist::ThreadBody::ThreadBody):
        (JSC::DFG::Worklist::dump):
        (JSC::DFG::numberOfWorklists):
        (JSC::DFG::ensureWorklistForIndex):
        (JSC::DFG::existingWorklistForIndexOrNull):
        (JSC::DFG::existingWorklistForIndex):
        * dfg/DFGWorklist.h:
        (JSC::DFG::numberOfWorklists): Deleted.
        (JSC::DFG::ensureWorklistForIndex): Deleted.
        (JSC::DFG::existingWorklistForIndexOrNull): Deleted.
        (JSC::DFG::existingWorklistForIndex): Deleted.
        * heap/CollectingScope.h: Added.
        (JSC::CollectingScope::CollectingScope):
        (JSC::CollectingScope::~CollectingScope):
        * heap/CollectorPhase.cpp: Added.
        (JSC::worldShouldBeSuspended):
        (WTF::printInternal):
        * heap/CollectorPhase.h: Added.
        * heap/EdenGCActivityCallback.cpp:
        (JSC::EdenGCActivityCallback::lastGCLength):
        * heap/FullGCActivityCallback.cpp:
        (JSC::FullGCActivityCallback::doCollection):
        (JSC::FullGCActivityCallback::lastGCLength):
        * heap/GCConductor.cpp: Added.
        (JSC::gcConductorShortName):
        (WTF::printInternal):
        * heap/GCConductor.h: Added.
        * heap/Heap.cpp:
        (JSC::Heap::Thread::Thread):
        (JSC::Heap::Heap):
        (JSC::Heap::lastChanceToFinalize):
        (JSC::Heap::gatherStackRoots):
        (JSC::Heap::updateObjectCounts):
        (JSC::Heap::shouldCollectInCollectorThread):
        (JSC::Heap::collectInCollectorThread):
        (JSC::Heap::checkConn):
        (JSC::Heap::runCurrentPhase):
        (JSC::Heap::runNotRunningPhase):
        (JSC::Heap::runBeginPhase):
        (JSC::Heap::runFixpointPhase):
        (JSC::Heap::runConcurrentPhase):
        (JSC::Heap::runReloopPhase):
        (JSC::Heap::runEndPhase):
        (JSC::Heap::changePhase):
        (JSC::Heap::finishChangingPhase):
        (JSC::Heap::stopThePeriphery):
        (JSC::Heap::resumeThePeriphery):
        (JSC::Heap::stopTheMutator):
        (JSC::Heap::resumeTheMutator):
        (JSC::Heap::stopIfNecessarySlow):
        (JSC::Heap::collectInMutatorThread):
        (JSC::Heap::collectInMutatorThreadImpl):
        (JSC::Heap::waitForCollector):
        (JSC::Heap::acquireAccessSlow):
        (JSC::Heap::releaseAccessSlow):
        (JSC::Heap::relinquishConn):
        (JSC::Heap::finishRelinquishingConn):
        (JSC::Heap::handleNeedFinalize):
        (JSC::Heap::notifyThreadStopping):
        (JSC::Heap::finalize):
        (JSC::Heap::requestCollection):
        (JSC::Heap::waitForCollection):
        (JSC::Heap::updateAllocationLimits):
        (JSC::Heap::didFinishCollection):
        (JSC::Heap::collectIfNecessaryOrDefer):
        (JSC::Heap::preventCollection):
        (JSC::Heap::performIncrement):
        (JSC::Heap::markToFixpoint): Deleted.
        (JSC::Heap::shouldCollectInThread): Deleted.
        (JSC::Heap::collectInThread): Deleted.
        (JSC::Heap::stopTheWorld): Deleted.
        (JSC::Heap::resumeTheWorld): Deleted.
        * heap/Heap.h:
        (JSC::Heap::machineThreads):
        (JSC::Heap::lastFullGCLength):
        (JSC::Heap::lastEdenGCLength):
        (JSC::Heap::increaseLastFullGCLength):
        * heap/HeapInlines.h:
        (JSC::Heap::mutatorIsStopped): Deleted.
        * heap/HeapStatistics.cpp: Removed.
        * heap/HeapStatistics.h: Removed.
        * heap/HelpingGCScope.h: Removed.
        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::gatherFromCurrentThread):
        (JSC::MachineThreads::gatherConservativeRoots):
        * heap/MachineStackMarker.h:
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::Handle::sweep):
        * heap/MutatorState.cpp:
        (WTF::printInternal):
        * heap/MutatorState.h:
        * heap/RegisterState.h: Added.
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::drainFromShared):
        (JSC::SlotVisitor::drainInParallelPassively):
        (JSC::SlotVisitor::donateAll):
        * heap/StochasticSpaceTimeMutatorScheduler.cpp:
        (JSC::StochasticSpaceTimeMutatorScheduler::beginCollection):
        (JSC::StochasticSpaceTimeMutatorScheduler::synchronousDrainingDidStall):
        (JSC::StochasticSpaceTimeMutatorScheduler::timeToStop):
        * heap/SweepingScope.h: Added.
        (JSC::SweepingScope::SweepingScope):
        (JSC::SweepingScope::~SweepingScope):
        * jit/JITWorklist.cpp:
        (JSC::JITWorklist::Thread::Thread):
        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionFlashHeapAccess):
        * runtime/InitializeThreading.cpp:
        (JSC::initializeThreading):
        * runtime/JSCellInlines.h:
        (JSC::JSCell::classInfo):
        * runtime/Options.cpp:
        (JSC::overrideDefaults):
        * runtime/Options.h:
        * runtime/TestRunnerUtils.cpp:
        (JSC::finalizeStatsAtEndOfTesting):

2017-02-16  Anders Carlsson  <andersca@apple.com>

        Remove EFL from JavaScriptCore
        https://bugs.webkit.org/show_bug.cgi?id=168459

        Reviewed by Geoffrey Garen.

        * heap/GCActivityCallback.cpp:
        (JSC::GCActivityCallback::GCActivityCallback):
        (JSC::GCActivityCallback::cancelTimer):
        (JSC::GCActivityCallback::didAllocate):
        * heap/GCActivityCallback.h:
        * heap/HeapTimer.cpp:
        (JSC::HeapTimer::add): Deleted.
        (JSC::HeapTimer::stop): Deleted.
        (JSC::HeapTimer::timerEvent): Deleted.
        * heap/HeapTimer.h:
        * inspector/EventLoop.cpp:
        (Inspector::EventLoop::cycle):
        * jsc.cpp:
        (main):
        * tools/CodeProfiling.cpp:
        (JSC::CodeProfiling::begin):
        (JSC::CodeProfiling::end):

2017-02-15  Brian Burg  <bburg@apple.com>

        [Cocoa] Web Inspector: Inspector::fromProtocolString<T> should return std::optional<T>
        https://bugs.webkit.org/show_bug.cgi?id=168018
        <rdar://problem/30468779>

        Reviewed by Joseph Pecoraro.

        These methods parse untrusted string inputs, so they should return an optional instead
        of asserting or crashing when the input is not usable.

        Update various pieces of generated code to handle the error case gracefully.

        * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
        (ObjCBackendDispatcherImplementationGenerator._generate_conversions_for_command):
        (ObjCBackendDispatcherImplementationGenerator._generate_invocation_for_command):
        The local variable holding the ObjC-friendly converted value should take a std::optional
        when converting an enum from a string into an NS_ENUM value. If the enum command parameter
        is not optional, then send a response with a command failure message and return.

        The optional enum parameter case is not handled correctly, but no existing code requires it.

        * inspector/scripts/codegen/generate_objc_protocol_type_conversions_header.py:
        (ObjCProtocolTypeConversionsHeaderGenerator._generate_enum_from_protocol_string):
        Fix signature and remove default case ASSERT_NOT_REACHED.

        * inspector/scripts/codegen/generate_objc_protocol_type_conversions_implementation.py:
        (ObjCProtocolTypeConversionsImplementationGenerator._generate_type_factory_method_implementation):
        Since this code assumes all inputs to be valid and throws an exception otherwise, we
        try to convert the enum and throw an exception if it's nullopt. If it's valid, write to outValue.

        * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
        (ObjCProtocolTypesImplementationGenerator._generate_init_method_for_payload):
        The local variable holding the ObjC-friendly converted value should take a std::optional
        when converting an enum from a string into an NS_ENUM value. If the enum command parameter
        is not optional, then throw an exception if the value is nullopt. Otherwise, allow it to be empty.

        * inspector/scripts/codegen/objc_generator.py:
        (ObjCGenerator.protocol_to_objc_expression_for_member):
        Unconditionally unwrap the optional. This expression is only used inside the typechecked
        ObjC protocol objects. In this case we are guaranteed to have already initialized the enum with a valid
        value, but must store it as a string inside a wrapped InspectorObject. The getter needs to
        re-convert the stored string into an NS_ENUM value.

        * inspector/scripts/codegen/objc_generator_templates.py:
        Update type template for fromProtocolString<T>().

        * inspector/scripts/tests/all/expected/definitions-with-mac-platform.json-result:
        * inspector/scripts/tests/generic/expected/commands-with-async-attribute.json-result:
        * inspector/scripts/tests/generic/expected/commands-with-optional-call-return-parameters.json-result:
        * inspector/scripts/tests/generic/expected/definitions-with-mac-platform.json-result:
        * inspector/scripts/tests/generic/expected/domain-availability.json-result:
        * inspector/scripts/tests/generic/expected/domains-with-varying-command-sizes.json-result:
        * inspector/scripts/tests/generic/expected/enum-values.json-result:
        * inspector/scripts/tests/generic/expected/events-with-optional-parameters.json-result:
        * inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result:
        * inspector/scripts/tests/generic/expected/same-type-id-different-domain.json-result:
        * inspector/scripts/tests/generic/expected/shadowed-optional-type-setters.json-result:
        * inspector/scripts/tests/generic/expected/type-declaration-aliased-primitive-type.json-result:
        * inspector/scripts/tests/generic/expected/type-declaration-array-type.json-result:
        * inspector/scripts/tests/generic/expected/type-declaration-enum-type.json-result:
        * inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result:
        * inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:
        * inspector/scripts/tests/generic/expected/worker-supported-domains.json-result:
        * inspector/scripts/tests/ios/expected/definitions-with-mac-platform.json-result:
        * inspector/scripts/tests/mac/expected/definitions-with-mac-platform.json-result:
        Rebaseline tests.

2017-02-16  Keith Miller  <keith_miller@apple.com>

        ASSERTION FAILED: vm.heap.mutatorState() == MutatorState::Running || vm.apiLock().ownerThread() != std::this_thread::get_id()
        https://bugs.webkit.org/show_bug.cgi?id=168354

        Reviewed by Filip Pizlo.

        Add a new vmEntryGlobalObject method for the debugger so that
        the debugger does not crash in debug builds when trying to
        detach itself from a global object.

        * debugger/Debugger.cpp:
        (JSC::Debugger::detach):
        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::vmEntryGlobalObjectForDebuggerDetach):
        * interpreter/CallFrame.h:

2017-02-16  Keith Miller  <keith_miller@apple.com>

        Refactor AccessCase to be more like B3Value
        https://bugs.webkit.org/show_bug.cgi?id=168408

        Reviewed by Filip Pizlo.

        This patch makes AccessCase (and new subclasses) more like B3Value. In the new system each
        type has an associated AccessCase subclass. For instance any getter should use the
        GetterSetterAccessCase subclass. The new system is easier to follow since you no longer need
        to know exactly which members are used by which types. The subclass to AccessType mapping is:

        GetterSetterAccessCase:
            Getter
            CustomAccessorGetter
            CustomValueGetter
            Setter

        ProxyableAccessCase:
            Load
            Miss
            GetGetter

        IntrinsicGetterAccessCase:
            IntrinsicGetter

        AccessCase:
            Everything else

        It also has the additional advantage that it uses less memory for the cases where we would have needed
        rare data in the past but that case would only use a small bit of it.

        This patch also removes megamorphic loads and renames some TryGetById related enum values from Pure to Try.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/AccessCase.cpp: Added.
        (JSC::AccessCase::AccessCase):
        (JSC::AccessCase::create):
        (JSC::AccessCase::~AccessCase):
        (JSC::AccessCase::fromStructureStubInfo):
        (JSC::AccessCase::clone):
        (JSC::AccessCase::commit):
        (JSC::AccessCase::guardedByStructureCheck):
        (JSC::AccessCase::doesCalls):
        (JSC::AccessCase::couldStillSucceed):
        (JSC::AccessCase::canReplace):
        (JSC::AccessCase::dump):
        (JSC::AccessCase::visitWeak):
        (JSC::AccessCase::propagateTransitions):
        (JSC::AccessCase::generateWithGuard):
        (JSC::AccessCase::generate):
        (JSC::AccessCase::generateImpl):
        * bytecode/AccessCase.h: Added.
        (JSC::AccessCase::as):
        (JSC::AccessCase::create):
        (JSC::AccessCase::type):
        (JSC::AccessCase::state):
        (JSC::AccessCase::offset):
        (JSC::AccessCase::structure):
        (JSC::AccessCase::newStructure):
        (JSC::AccessCase::conditionSet):
        (JSC::AccessCase::alternateBase):
        (JSC::AccessCase::additionalSet):
        (JSC::AccessCase::viaProxy):
        (JSC::AccessCase::isGetter):
        (JSC::AccessCase::isAccessor):
        (JSC::AccessCase::dumpImpl):
        (JSC::AccessCase::resetState):
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
        * bytecode/GetterSetterAccessCase.cpp: Added.
        (JSC::GetterSetterAccessCase::GetterSetterAccessCase):
        (JSC::GetterSetterAccessCase::create):
        (JSC::GetterSetterAccessCase::~GetterSetterAccessCase):
        (JSC::GetterSetterAccessCase::clone):
        (JSC::GetterSetterAccessCase::alternateBase):
        (JSC::GetterSetterAccessCase::dumpImpl):
        (JSC::GetterSetterAccessCase::emitDOMJITGetter):
        * bytecode/GetterSetterAccessCase.h: Added.
        (JSC::GetterSetterAccessCase::callLinkInfo):
        (JSC::GetterSetterAccessCase::customSlotBase):
        (JSC::GetterSetterAccessCase::domJIT):
        * bytecode/IntrinsicGetterAccessCase.cpp: Added.
        (JSC::IntrinsicGetterAccessCase::IntrinsicGetterAccessCase):
        (JSC::IntrinsicGetterAccessCase::create):
        (JSC::IntrinsicGetterAccessCase::~IntrinsicGetterAccessCase):
        (JSC::IntrinsicGetterAccessCase::clone):
        * bytecode/IntrinsicGetterAccessCase.h: Added.
        (JSC::IntrinsicGetterAccessCase::intrinsicFunction):
        (JSC::IntrinsicGetterAccessCase::intrinsic):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::PolymorphicAccess::regenerate):
        (WTF::printInternal):
        (JSC::AccessCase::AccessCase): Deleted.
        (JSC::AccessCase::tryGet): Deleted.
        (JSC::AccessCase::get): Deleted.
        (JSC::AccessCase::megamorphicLoad): Deleted.
        (JSC::AccessCase::replace): Deleted.
        (JSC::AccessCase::transition): Deleted.
        (JSC::AccessCase::setter): Deleted.
        (JSC::AccessCase::in): Deleted.
        (JSC::AccessCase::getLength): Deleted.
        (JSC::AccessCase::getIntrinsic): Deleted.
        (JSC::AccessCase::~AccessCase): Deleted.
        (JSC::AccessCase::fromStructureStubInfo): Deleted.
        (JSC::AccessCase::clone): Deleted.
        (JSC::AccessCase::commit): Deleted.
        (JSC::AccessCase::guardedByStructureCheck): Deleted.
        (JSC::AccessCase::alternateBase): Deleted.
        (JSC::AccessCase::doesCalls): Deleted.
        (JSC::AccessCase::couldStillSucceed): Deleted.
        (JSC::AccessCase::canBeReplacedByMegamorphicLoad): Deleted.
        (JSC::AccessCase::canReplace): Deleted.
        (JSC::AccessCase::dump): Deleted.
        (JSC::AccessCase::visitWeak): Deleted.
        (JSC::AccessCase::propagateTransitions): Deleted.
        (JSC::AccessCase::generateWithGuard): Deleted.
        (JSC::AccessCase::generate): Deleted.
        (JSC::AccessCase::generateImpl): Deleted.
        (JSC::AccessCase::emitDOMJITGetter): Deleted.
        * bytecode/PolymorphicAccess.h:
        (JSC::AccessCase::type): Deleted.
        (JSC::AccessCase::state): Deleted.
        (JSC::AccessCase::offset): Deleted.
        (JSC::AccessCase::viaProxy): Deleted.
        (JSC::AccessCase::structure): Deleted.
        (JSC::AccessCase::newStructure): Deleted.
        (JSC::AccessCase::conditionSet): Deleted.
        (JSC::AccessCase::intrinsicFunction): Deleted.
        (JSC::AccessCase::intrinsic): Deleted.
        (JSC::AccessCase::domJIT): Deleted.
        (JSC::AccessCase::additionalSet): Deleted.
        (JSC::AccessCase::customSlotBase): Deleted.
        (JSC::AccessCase::isGetter): Deleted.
        (JSC::AccessCase::callLinkInfo): Deleted.
        (JSC::AccessCase::RareData::RareData): Deleted.
        * bytecode/ProxyableAccessCase.cpp: Added.
        (JSC::ProxyableAccessCase::ProxyableAccessCase):
        (JSC::ProxyableAccessCase::create):
        (JSC::ProxyableAccessCase::~ProxyableAccessCase):
        (JSC::ProxyableAccessCase::clone):
        (JSC::ProxyableAccessCase::dumpImpl):
        * bytecode/ProxyableAccessCase.h: Added.
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeForStubInfo):
        * bytecode/StructureStubInfo.cpp:
        (JSC::StructureStubInfo::reset):
        * bytecode/StructureStubInfo.h:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileTryGetById):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetById):
        * jit/IntrinsicEmitter.cpp:
        (JSC::IntrinsicGetterAccessCase::canEmitIntrinsicGetter):
        (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
        (JSC::AccessCase::canEmitIntrinsicGetter): Deleted.
        (JSC::AccessCase::emitIntrinsicGetter): Deleted.
        * jit/JITOperations.cpp:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_try_get_by_id):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_try_get_by_id):
        * jit/Repatch.cpp:
        (JSC::tryCacheGetByID):
        (JSC::tryCachePutByID):
        (JSC::tryRepatchIn):
        * jit/Repatch.h:
        * runtime/Options.h:

2017-02-16  Filip Pizlo  <fpizlo@apple.com>

        JSONParseTest needs to hold the lock when the VM is destroyed
        https://bugs.webkit.org/show_bug.cgi?id=168450

        Rubber stamped by Alex Christensen.

        * API/tests/JSONParseTest.cpp:
        (testJSONParse):

2017-02-16  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Drop PassRefPtr in inspector/
        https://bugs.webkit.org/show_bug.cgi?id=168420

        Reviewed by Alex Christensen.

        Drop PassRefPtr uses.
        And use Ref<Inspector::ScriptArguments> and Ref<ScriptCallStack> as much as possible.
        It drops some unnecessary null checks.

        * debugger/Debugger.cpp:
        (JSC::Debugger::hasBreakpoint):
        (JSC::Debugger::currentDebuggerCallFrame):
        * debugger/Debugger.h:
        * inspector/AsyncStackTrace.cpp:
        (Inspector::AsyncStackTrace::create):
        (Inspector::AsyncStackTrace::AsyncStackTrace):
        (Inspector::AsyncStackTrace::buildInspectorObject):
        (Inspector::AsyncStackTrace::truncate):
        * inspector/AsyncStackTrace.h:
        * inspector/ConsoleMessage.cpp:
        (Inspector::ConsoleMessage::ConsoleMessage):
        * inspector/ConsoleMessage.h:
        * inspector/InjectedScriptManager.cpp:
        (Inspector::InjectedScriptManager::InjectedScriptManager):
        (Inspector::InjectedScriptManager::injectedScriptHost):
        * inspector/InjectedScriptManager.h:
        * inspector/JSGlobalObjectConsoleClient.cpp:
        (Inspector::JSGlobalObjectConsoleClient::messageWithTypeAndLevel):
        (Inspector::JSGlobalObjectConsoleClient::count):
        (Inspector::JSGlobalObjectConsoleClient::timeEnd):
        (Inspector::JSGlobalObjectConsoleClient::timeStamp):
        (Inspector::JSGlobalObjectConsoleClient::warnUnimplemented):
        * inspector/JSGlobalObjectConsoleClient.h:
        ConsoleClient now takes Ref<ScriptArgument>&& instead of RefPtr<ScriptArgument>&&.

        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::appendAPIBacktrace):
        (Inspector::JSGlobalObjectInspectorController::reportAPIException):
        * inspector/JSGlobalObjectInspectorController.h:
        * inspector/JSJavaScriptCallFrame.cpp:
        (Inspector::JSJavaScriptCallFrame::JSJavaScriptCallFrame):
        (Inspector::toJS):
        * inspector/JSJavaScriptCallFrame.h:
        (Inspector::JSJavaScriptCallFrame::create):
        * inspector/JavaScriptCallFrame.cpp:
        (Inspector::JavaScriptCallFrame::JavaScriptCallFrame):
        (Inspector::JavaScriptCallFrame::caller):
        * inspector/JavaScriptCallFrame.h:
        (Inspector::JavaScriptCallFrame::create):
        * inspector/ScriptDebugServer.cpp:
        (Inspector::ScriptDebugServer::evaluateBreakpointAction):
        (Inspector::ScriptDebugServer::dispatchDidPause):
        (Inspector::ScriptDebugServer::exceptionOrCaughtValue):
        * inspector/agents/InspectorConsoleAgent.cpp:
        (Inspector::InspectorConsoleAgent::stopTiming):
        (Inspector::InspectorConsoleAgent::count):
        * inspector/agents/InspectorConsoleAgent.h:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::didScheduleAsyncCall):
        * runtime/ConsoleClient.cpp:
        (JSC::ConsoleClient::printConsoleMessageWithArguments):
        (JSC::ConsoleClient::internalMessageWithTypeAndLevel):
        (JSC::ConsoleClient::logWithLevel):
        (JSC::ConsoleClient::dir):
        (JSC::ConsoleClient::dirXML):
        (JSC::ConsoleClient::table):
        (JSC::ConsoleClient::trace):
        (JSC::ConsoleClient::assertion):
        (JSC::ConsoleClient::group):
        (JSC::ConsoleClient::groupCollapsed):
        (JSC::ConsoleClient::groupEnd):
        * runtime/ConsoleClient.h:
        * runtime/ConsoleObject.cpp:
        (JSC::consoleLogWithLevel):
        (JSC::consoleProtoFuncDir):
        (JSC::consoleProtoFuncDirXML):
        (JSC::consoleProtoFuncTable):
        (JSC::consoleProtoFuncTrace):
        (JSC::consoleProtoFuncAssert):
        (JSC::consoleProtoFuncCount):
        (JSC::consoleProtoFuncTimeStamp):
        (JSC::consoleProtoFuncGroup):
        (JSC::consoleProtoFuncGroupCollapsed):
        (JSC::consoleProtoFuncGroupEnd):

2017-02-15  Keith Miller  <keith_miller@apple.com>

        Weak should not use jsCast in its accessors
        https://bugs.webkit.org/show_bug.cgi?id=168406

        Reviewed by Filip Pizlo.

        This can cause assertion failures in WebCore where classes might remove themselves
        from a data structure in a weak reference, if that reference is still alive.

        * heap/WeakInlines.h:
        (JSC::>):
        (JSC::Weak<T>::operator):
        (JSC::Weak<T>::get):

2017-02-16  Yusuke Suzuki  <utatane.tea@gmail.com>

        Web Inspector: allow import() inside the inspector
        https://bugs.webkit.org/show_bug.cgi?id=167457

        Reviewed by Ryosuke Niwa.

        We relax import module hook to accept null SourceOrigin.
        Such a script can be evaluated from the inspector console.

        * jsc.cpp:
        (GlobalObject::moduleLoaderImportModule):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncImportModule):

2017-02-16  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Update module namespace object according to the latest ECMA262
        https://bugs.webkit.org/show_bug.cgi?id=168280

        Reviewed by Saam Barati.

        Reflect updates to the module namespace object.

        1. @@iterator property is dropped[1].
        2. @@toStringTag property becomes non-configurable[1].
        3. delete with Symbol should be delegated to the JSObject's one[2].

        [1]: https://tc39.github.io/ecma262/#sec-module-namespace-objects
        [2]: https://github.com/tc39/ecma262/pull/767

        * runtime/JSModuleNamespaceObject.cpp:
        (JSC::JSModuleNamespaceObject::finishCreation):
        (JSC::JSModuleNamespaceObject::deleteProperty):
        (JSC::moduleNamespaceObjectSymbolIterator): Deleted.

2017-02-16  Carlos Garcia Campos  <cgarcia@igalia.com>

        Unreviewed. Fix the build after r212424.

        Add missing file.

        * inspector/remote/RemoteInspector.cpp: Added.
        (Inspector::RemoteInspector::startDisabled):
        (Inspector::RemoteInspector::nextAvailableTargetIdentifier):
        (Inspector::RemoteInspector::registerTarget):
        (Inspector::RemoteInspector::unregisterTarget):
        (Inspector::RemoteInspector::updateTarget):
        (Inspector::RemoteInspector::updateClientCapabilities):
        (Inspector::RemoteInspector::setRemoteInspectorClient):
        (Inspector::RemoteInspector::setupFailed):
        (Inspector::RemoteInspector::setupCompleted):
        (Inspector::RemoteInspector::waitingForAutomaticInspection):
        (Inspector::RemoteInspector::clientCapabilitiesDidChange):
        (Inspector::RemoteInspector::stop):
        (Inspector::RemoteInspector::listingForTarget):
        (Inspector::RemoteInspector::updateHasActiveDebugSession):

2017-02-15  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Drop PassRefPtr in bytecompiler/
        https://bugs.webkit.org/show_bug.cgi?id=168374

        Reviewed by Sam Weinig.

        This patch drops PassRefPtr in bytecompiler directory.
        We carefully change this to Ref<>. And we use Ref<Label>
        as much as possible instead of using RefPtr<Label>.
        And use Label& instead of Label* as much as possible.

        Currently we do not apply this change for RefPtr<RegisterID>,
        to reduce the size of this patch.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
        (JSC::BytecodeGenerator::newLabelScope):
        (JSC::BytecodeGenerator::newLabel):
        (JSC::BytecodeGenerator::newEmittedLabel):
        Introduce a new helper function, which returns new label that is emitted right here.

        (JSC::BytecodeGenerator::emitLabel):
        (JSC::BytecodeGenerator::emitJump):
        (JSC::BytecodeGenerator::emitJumpIfTrue):
        (JSC::BytecodeGenerator::emitJumpIfFalse):
        (JSC::BytecodeGenerator::emitJumpIfNotFunctionCall):
        (JSC::BytecodeGenerator::emitJumpIfNotFunctionApply):
        Drop returning Ref<Label> since nobody uses it.

        (JSC::BytecodeGenerator::emitGetByVal):
        (JSC::BytecodeGenerator::emitExpectedFunctionSnippet):
        (JSC::BytecodeGenerator::emitCall):
        (JSC::BytecodeGenerator::emitReturn):
        (JSC::BytecodeGenerator::emitConstruct):
        (JSC::BytecodeGenerator::pushFinallyControlFlowScope):
        (JSC::BytecodeGenerator::breakTarget):
        (JSC::BytecodeGenerator::pushTry):
        (JSC::BytecodeGenerator::popTry):
        (JSC::prepareJumpTableForSwitch):
        (JSC::prepareJumpTableForStringSwitch):
        (JSC::BytecodeGenerator::endSwitch):
        (JSC::BytecodeGenerator::emitEnumeration):
        (JSC::BytecodeGenerator::emitIteratorNext):
        (JSC::BytecodeGenerator::emitIteratorNextWithValue):
        (JSC::BytecodeGenerator::emitIteratorClose):
        (JSC::BytecodeGenerator::pushIndexedForInScope):
        (JSC::BytecodeGenerator::pushStructureForInScope):
        (JSC::BytecodeGenerator::invalidateForInContextForLocal):
        (JSC::BytecodeGenerator::emitRequireObjectCoercible):
        (JSC::BytecodeGenerator::emitYieldPoint):
        (JSC::BytecodeGenerator::emitYield):
        (JSC::BytecodeGenerator::emitDelegateYield):
        (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
        (JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
        (JSC::BytecodeGenerator::emitFinallyCompletion):
        (JSC::BytecodeGenerator::emitJumpIf):
        * bytecompiler/BytecodeGenerator.h:
        FinallyJump, FinallyContext, TryData, TryContext and TryRange hold Ref<Label>
        instead of RefPtr<Label>. They are never nullptr.

        (JSC::FinallyJump::FinallyJump):
        (JSC::FinallyContext::FinallyContext):
        (JSC::FinallyContext::registerJump):
        (JSC::BytecodeGenerator::emitNodeInConditionContext):
        (JSC::BytecodeGenerator::emitNodeForLeftHandSide):
        * bytecompiler/Label.h:
        Make Label noncopyable.

        * bytecompiler/LabelScope.h:
        (JSC::LabelScope::LabelScope):
        (JSC::LabelScope::breakTarget):
        breakTarget always returns Label&. On the other hand, continueTarget may be nullptr.
        So it returns Label*.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::ExpressionNode::emitBytecodeInConditionContext):
        (JSC::ConstantNode::emitBytecodeInConditionContext):
        (JSC::FunctionCallValueNode::emitBytecode):
        (JSC::CallFunctionCallDotNode::emitBytecode):
        (JSC::ApplyFunctionCallDotNode::emitBytecode):
        (JSC::LogicalNotNode::emitBytecodeInConditionContext):
        (JSC::BinaryOpNode::emitBytecodeInConditionContext):
        (JSC::InstanceOfNode::emitBytecode):
        (JSC::LogicalOpNode::emitBytecode):
        (JSC::LogicalOpNode::emitBytecodeInConditionContext):
        (JSC::ConditionalNode::emitBytecode):
        (JSC::IfElseNode::emitBytecode):
        (JSC::DoWhileNode::emitBytecode):
        (JSC::WhileNode::emitBytecode):
        (JSC::ForNode::emitBytecode):
        (JSC::ForInNode::emitBytecode):
        (JSC::ContinueNode::trivialTarget):
        (JSC::ContinueNode::emitBytecode):
        (JSC::BreakNode::trivialTarget):
        (JSC::CaseBlockNode::emitBytecodeForBlock):
        (JSC::TryNode::emitBytecode):
        (JSC::FunctionNode::emitBytecode):
        (JSC::ClassExprNode::emitBytecode):
        (JSC::assignDefaultValueIfUndefined):
        (JSC::ArrayPatternNode::bindValue):
        Use Ref<Label> and Label&.

        * parser/Nodes.h:

2017-02-15  Alex Christensen  <achristensen@webkit.org>

        Unreviewed, rolling out r212394.

        Fixed iOS WebInspector

        Reverted changeset:

        "Unreviewed, rolling out r212169."
        https://bugs.webkit.org/show_bug.cgi?id=166681
        http://trac.webkit.org/changeset/212394

2017-02-15  Guillaume Emont  <guijemont@igalia.com>

        MIPS: add missing implementations of load8SignedExtendTo32()

        JSC: missing implementations of MacroAssemblerMIPS::load8SignedExtendTo32()
        https://bugs.webkit.org/show_bug.cgi?id=168350

        Reviewed by Yusuke Suzuki.

        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::load8SignedExtendTo32):
        Add missing implementations

2017-02-15  Alex Christensen  <achristensen@webkit.org>

        Unreviewed, rolling out r212169.

        Broke iOS WebInspector

        Reverted changeset:

        "WebInspector: refactor RemoteInspector to move cocoa specific
        code to their own files"
        https://bugs.webkit.org/show_bug.cgi?id=166681
        http://trac.webkit.org/changeset/212169

2017-02-15  Chris Dumez  <cdumez@apple.com>

        Expose Symbol.toPrimitive / valueOf on Location instances
        https://bugs.webkit.org/show_bug.cgi?id=168295

        Reviewed by Geoffrey Garen, Keith Miller and Mark Lam.

        Cache origin objectProtoValueOf function on JSGlobalObject.

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

2017-02-15  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Drop PassRefPtr
        https://bugs.webkit.org/show_bug.cgi?id=168320

        Reviewed by Saam Barati.

        * API/JSContextRef.cpp:
        (JSGlobalContextCreateInGroup):
        Use Ref<VM> from the factory function.

        * API/JSScriptRef.cpp:
        (OpaqueJSScript::create):
        Return Ref<> instead.

        * API/tests/JSONParseTest.cpp:
        (testJSONParse):
        Use Ref<VM>.

        * assembler/LinkBuffer.cpp:
        (JSC::LinkBuffer::finalizeCodeWithoutDisassembly):
        Use reference since we already perform null check.

        * assembler/MacroAssemblerCodeRef.h:
        (JSC::MacroAssemblerCodeRef::MacroAssemblerCodeRef):
        Take Ref<>&& instead of PassRefPtr<>.

        * bytecode/CallLinkInfo.h:
        (JSC::CallLinkInfo::setStub):
        (JSC::CallLinkInfo::setSlowStub):
        Take Ref<>&& instead of PassRefPtr<>.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        Take RefPtr<SourceProvider>. Currently, the SourceProvider would be nullptr.
        We will change it to Ref<SourceProvider> in https://bugs.webkit.org/show_bug.cgi?id=168325.

        (JSC::CodeBlock::finishCreation):
        Take Ref<TypeSet>&&.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::setJITCode):
        Take Ref<>&& instead.

        (JSC::CodeBlock::jitCode):
        Return RefPtr<> instead.

        * bytecode/EvalCodeBlock.h:
        (JSC::EvalCodeBlock::create):
        Take RefPtr<>&& instead since SourceProvider woule be nullptr.

        (JSC::EvalCodeBlock::EvalCodeBlock):
        * bytecode/FunctionCodeBlock.h:
        (JSC::FunctionCodeBlock::create):
        (JSC::FunctionCodeBlock::FunctionCodeBlock):
        Take RefPtr<>&& instead since SourceProvider woule be nullptr.

        * bytecode/GlobalCodeBlock.h:
        (JSC::GlobalCodeBlock::GlobalCodeBlock):
        Take RefPtr<>&& instead since SourceProvider woule be nullptr.

        * bytecode/ModuleProgramCodeBlock.h:
        (JSC::ModuleProgramCodeBlock::create):
        (JSC::ModuleProgramCodeBlock::ModuleProgramCodeBlock):
        Take RefPtr<>&& instead since SourceProvider woule be nullptr.

        * bytecode/ProgramCodeBlock.h:
        (JSC::ProgramCodeBlock::create):
        (JSC::ProgramCodeBlock::ProgramCodeBlock):
        Take RefPtr<>&& instead since SourceProvider woule be nullptr.

        * debugger/DebuggerParseData.cpp:
        (JSC::gatherDebuggerParseDataForSource):
        Ensure the provider is not nullptr. It is OK because we already
        touch `provider->xxx` values.

        * dfg/DFGBlockInsertionSet.cpp:
        (JSC::DFG::BlockInsertionSet::insert):
        Take Ref<>&& instead.

        * dfg/DFGBlockInsertionSet.h:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::inlineCall):
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::parseCodeBlock):
        Pass Ref<>&& to appendBlock.

        * dfg/DFGDriver.cpp:
        (JSC::DFG::compileImpl):
        (JSC::DFG::compile):
        Pass Ref<Plan>&&. And take Ref<>&& callback.

        * dfg/DFGDriver.h:
        * dfg/DFGGraph.h:
        appendBlock takes Ref<>&&.

        (JSC::DFG::Graph::appendBlock):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        * dfg/DFGJITCompiler.h:
        (JSC::DFG::JITCompiler::jitCode):
        * dfg/DFGJITFinalizer.cpp:
        (JSC::DFG::JITFinalizer::JITFinalizer):
        Take Ref<JITCode>&&.

        (JSC::DFG::JITFinalizer::finalize):
        (JSC::DFG::JITFinalizer::finalizeFunction):
        (JSC::DFG::JITFinalizer::finalizeCommon):
        Pass compilation reference since we already perform null check.

        * dfg/DFGJITFinalizer.h:
        * dfg/DFGWorklist.cpp:
        (JSC::DFG::Worklist::enqueue):
        Take Ref<Plan>&&.

        * dfg/DFGWorklist.h:
        * ftl/FTLJITFinalizer.cpp:
        (JSC::FTL::JITFinalizer::finalizeFunction):
        Dereference and pass jitCode & compilation references.

        * jit/GCAwareJITStubRoutine.cpp:
        (JSC::createJITStubRoutine):
        Return Ref<> instead.

        * jit/GCAwareJITStubRoutine.h:
        (JSC::createJITStubRoutine):
        * jit/JIT.cpp:
        (JSC::JIT::link):
        Pass compilation reference since we already perform null check.

        * jit/JITStubRoutine.h:
        (JSC::JITStubRoutine::asCodePtr):
        Take Ref<>&& instead. And this drops unnecessary null check.

        * jit/JITThunks.cpp:
        (JSC::JITThunks::hostFunctionStub):
        Pass Ref<> to NativeExecutable::create.

        * llint/LLIntEntrypoint.cpp:
        (JSC::LLInt::setFunctionEntrypoint):
        (JSC::LLInt::setEvalEntrypoint):
        (JSC::LLInt::setProgramEntrypoint):
        (JSC::LLInt::setModuleProgramEntrypoint):
        Use Ref<>&& instead.

        * parser/SourceCode.h:
        (JSC::SourceCode::SourceCode):
        (JSC::SourceCode::subExpression):
        Add constructors taking Ref<>&&.
        We still have constructors that take RefPtr<>&&.
        We will change it to Ref<SourceProvider>&& in https://bugs.webkit.org/show_bug.cgi?id=168325.

        * parser/UnlinkedSourceCode.h:
        (JSC::UnlinkedSourceCode::UnlinkedSourceCode):
        Add constructors taking Ref<>&&.
        We still have constructors that take RefPtr<>&&.
        We will change it to Ref<SourceProvider>&& in https://bugs.webkit.org/show_bug.cgi?id=168325.

        * profiler/ProfilerDatabase.cpp:
        (JSC::Profiler::Database::addCompilation):
        Take Ref<Compilation>&&.

        * profiler/ProfilerDatabase.h:
        Change data structures to hold Ref<> instead of RefPtr<>.

        * runtime/EvalExecutable.h:
        (JSC::EvalExecutable::generatedJITCode):
        Return Ref<> instead.

        * runtime/ExecutableBase.h:
        (JSC::ExecutableBase::generatedJITCodeForCall):
        (JSC::ExecutableBase::generatedJITCodeForConstruct):
        (JSC::ExecutableBase::generatedJITCodeFor):
        Return Ref<> instead.

        * runtime/Identifier.cpp:
        (JSC::Identifier::add):
        (JSC::Identifier::add8):
        * runtime/Identifier.h:
        (JSC::Identifier::add):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::setInputCursor):
        And take Ref<> in this method.

        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::inputCursor):
        Change m_inputCursor from RefPtr<> to Ref<>.

        * runtime/JSPropertyNameEnumerator.cpp:
        (JSC::JSPropertyNameEnumerator::create):
        (JSC::JSPropertyNameEnumerator::finishCreation):
        Take Ref<PropertyNameArray>&&.

        * runtime/JSPropertyNameEnumerator.h:
        (JSC::propertyNameEnumerator):
        * runtime/JSString.h:
        (JSC::JSString::JSString):
        Take Ref<StringImpl>&& since we do not allow nullptr in this constructor.

        (JSC::JSString::create):
        (JSC::JSString::createHasOtherOwner):
        Take Ref<StringImpl>&& in these factory functions. And drop unnecessary assertions.

        (JSC::jsSingleCharacterString):
        Use StringImpl::create() which returns Ref<>.

        (JSC::jsNontrivialString):
        Dereference impl() since we ensure that `s.length() > 1`.

        (JSC::jsString):
        Use releaseNonNull() since we ensure that `s.length() > 1`.

        (JSC::jsOwnedString):
        Use releaseNonNull() since we ensure that `s.length() > 1`.

        * runtime/ModuleProgramExecutable.h:
        * runtime/NativeExecutable.cpp:
        (JSC::NativeExecutable::create):
        (JSC::NativeExecutable::finishCreation):
        Take Ref<JITCode>&&.

        * runtime/NativeExecutable.h:
        * runtime/ProgramExecutable.h:
        Return Ref<JITCode>.

        * runtime/PropertyNameArray.h:
        (JSC::PropertyNameArray::releaseData):
        (JSC::PropertyNameArray::setData): Deleted.
        This is not used.

        * runtime/RegExpKey.h:
        (JSC::RegExpKey::RegExpKey):
        Take RefPtr<>&&.

        * runtime/SmallStrings.cpp:
        (JSC::SmallStringsStorage::rep):
        Return StringImpl& since m_reps is already initialized in the constructor.

        (JSC::SmallStrings::createEmptyString):
        Dereference StringImpl::empty().

        (JSC::SmallStrings::createSingleCharacterString):
        Use StringImpl&.

        (JSC::SmallStrings::singleCharacterStringRep):
        Return StringImpl&.

        (JSC::SmallStrings::initialize):
        Use AtomicStringImpl::add instead.

        * runtime/SmallStrings.h:
        * runtime/Structure.cpp:
        (JSC::Structure::toStructureShape):
        Return Ref<>.

        * runtime/Structure.h:
        * runtime/TypeLocationCache.cpp:
        (JSC::TypeLocationCache::getTypeLocation):
        Take RefPtr<TypeSet>&&.

        * runtime/TypeLocationCache.h:
        * runtime/TypeProfilerLog.cpp:
        Pass Ref<>&&.

        (JSC::TypeProfilerLog::processLogEntries):
        * runtime/TypeSet.cpp:
        (JSC::TypeSet::addTypeInformation):
        Take RefPtr<>&& since it can be nullptr.
        And clean up "not found" code.

        (JSC::TypeSet::allStructureRepresentations):
        Use range based iteration.

        (JSC::StructureShape::leastCommonAncestor):
        We found that this method accidentally takes `const Vector<>` instead of `const Vector<>&`.
        And internally, we just use raw pointers since these StructureShapes are owned by the m_proto trees which starts from the given Vector<>.

        (JSC::StructureShape::hasSamePrototypeChain):
        Take const reference instead. And use raw pointers internally.

        (JSC::StructureShape::merge):
        Take Ref<>&&.

        * runtime/TypeSet.h:
        (JSC::StructureShape::setProto):
        Take Ref<>&&.

        * runtime/VM.cpp:
        (JSC::VM::getHostFunction):
        Pass Ref<>&&.

        (JSC::VM::queueMicrotask):
        Take and pass Ref<>&&.

        * runtime/VM.h:
        (JSC::QueuedTask::QueuedTask):
        Take Ref<>&&.

        * tools/FunctionOverrides.cpp:
        (JSC::initializeOverrideInfo):
        We need this change due to Ref<>&& and RefPtr<>&& ambiguity of SourceCode constructors.
        Once SourceCode is fixed to only take Ref<>&&, this change is unnecessary.

2017-02-15  Csaba Osztrogonác  <ossy@webkit.org>

        [Mac][cmake] Unreviewed trivial buildfix after r212169.
        https://bugs.webkit.org/show_bug.cgi?id=166681

        * PlatformMac.cmake: Removed inspector/remote/RemoteInspectorXPCConnection.mm.

2017-02-14  Mark Lam  <mark.lam@apple.com>

        Add JSC_sweepSynchronously and fix JSC_useZombieMode options.
        https://bugs.webkit.org/show_bug.cgi?id=168257
        <rdar://problem/30451496>

        Reviewed by Filip Pizlo.

        JSC_useZombieMode now basically enables JSC_sweepSynchronously and
        JSC_scribbleFreeCells, which together does the job of zombifying dead objects
        immediately after a GC.

        * heap/Heap.cpp:
        (JSC::Heap::sweepSynchronously):
        (JSC::Heap::collectAllGarbage):
        (JSC::Heap::finalize):
        (JSC::Heap::didFinishCollection):
        (JSC::Zombify::visit): Deleted.
        (JSC::Zombify::operator()): Deleted.
        (JSC::Heap::zombifyDeadObjects): Deleted.
        * heap/Heap.h:
        (JSC::Heap::isZombified): Deleted.
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):
        * runtime/Options.h:

2017-02-13  Michael Saboff  <msaboff@apple.com>

        asyncDisassembly crashes on iOS
        https://bugs.webkit.org/show_bug.cgi?id=168259

        Reviewed by Filip Pizlo.

        Eliminated the dumping of  the disassembly for the JIT write thunk.
        Not only does it fix the crash, but given the nature of the JIT
        write thunk, we probably don't want to disassemble it anyway.
        
        * jit/ExecutableAllocatorFixedVMPool.cpp:
        (JSC::FixedVMPoolExecutableAllocator::jitWriteThunkGenerator):

2017-02-12  Ryosuke Niwa  <rniwa@webkit.org>

        C loop build fix attempt after r212207.

        * runtime/Lookup.h:

2017-02-11  Sam Weinig  <sam@webkit.org>

        Remove the remaining functions out of JSDOMBinding
        https://bugs.webkit.org/show_bug.cgi?id=168179

        Reviewed by Darin Adler.

        Move utility functions into more appropriate locations.
        - Move hasIteratorMethod to IteratorOperations.
        - Move nonCachingStaticFunctionGetter to Lookup

        * runtime/IteratorOperations.cpp:
        (JSC::hasIteratorMethod):
        * runtime/IteratorOperations.h:
        * runtime/Lookup.h:
        (JSC::nonCachingStaticFunctionGetter):

2017-02-11  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Implement (Shared)ArrayBuffer.prototype.byteLength
        https://bugs.webkit.org/show_bug.cgi?id=166476

        Reviewed by Saam Barati.

        `byteLength` becomes getter and is set in ArrayBuffer.prototype
        and SharedArrayBuffer.prototype. This patch implements the
        above getter in native function. We do not have any optimization
        path for that for now since ArrayBuffer.prototype.byteLength is
        not considered a hot function: while TypedArrays have [] accesses,
        ArrayBuffer does not have that. Thus byteLength getter is not so
        meaningful for a hot paths like iterations.

        * runtime/JSArrayBuffer.cpp:
        (JSC::JSArrayBuffer::getOwnPropertySlot): Deleted.
        (JSC::JSArrayBuffer::put): Deleted.
        (JSC::JSArrayBuffer::defineOwnProperty): Deleted.
        (JSC::JSArrayBuffer::deleteProperty): Deleted.
        (JSC::JSArrayBuffer::getOwnNonIndexPropertyNames): Deleted.
        * runtime/JSArrayBuffer.h:
        (JSC::JSArrayBuffer::impl): Deleted.
        * runtime/JSArrayBufferPrototype.cpp:
        (JSC::arrayBufferProtoGetterFuncByteLength):
        (JSC::sharedArrayBufferProtoGetterFuncByteLength):
        (JSC::JSArrayBufferPrototype::finishCreation):

2017-02-10  Saam Barati  <sbarati@apple.com>

        Object allocation sinking phase doesn't properly handle control flow when emitting a PutHint of a materialized object into a PromotedHeapLocation of a still sunken object
        https://bugs.webkit.org/show_bug.cgi?id=168140
        <rdar://problem/30205880>

        Reviewed by Filip Pizlo.

        This patch fixes a bug in allocation sinking phase where
        we don't properly handle control flow when materializing
        an object and also PutHinting that materialization into
        a still sunken object. We were performing the PutHint
        for the materialization at the point of materialization,
        however, we may have materialized along both edges
        of a control flow diamond, in which case, we need to
        also PutHint at the join point. Consider this program:
        
        ```
        bb#0:
        b: PhantomActivation()
        a: PhantomNewFunction()
        c: PutHint(@a, @b, ActivationLoc)
        Branch(#1, #2)
        
        bb#1:
        d: MaterializeActivation()
        e: PutHint(@a, @d, ActivationLoc)
        f: Upsilon(@d, ^p)
        Jump(#3)
        
        bb#2:
        g: MaterializeActivation()
        h: PutHint(@a, @g, ActivationLoc)
        i: Upsilon(@d, ^p)
        Jump(#3)
        
        bb#3:
        p: Phi()
        // What is PromotedHeapLocation(@a, ActivationLoc) here?
        // What would we do if we exited?
        ```
        Before this patch, we didn't perform a PutHint of the Phi.
        However, we need to, otherwise when exit, we won't know
        the value of PromotedHeapLocation(@a, ActivationLoc)
        
        The program we need then, for correctness, is this:
        ```
        bb#0:
        b: PhantomActivation()
        a: PhantomNewFunction()
        c: PutHint(@a, @b, ActivationLoc)
        Branch(#1, #2)
        
        bb#1:
        d: MaterializeActivation()
        e: PutHint(@a, @d, ActivationLoc)
        f: Upsilon(@d, ^p)
        Jump(#3)
        
        bb#2:
        g: MaterializeActivation()
        h: PutHint(@a, @g, ActivationLoc)
        i: Upsilon(@d, ^p)
        Jump(#3)
        
        bb#3:
        p: Phi()
        j: PutHint(@a, @p, ActivationLoc)
        ```
        
        This patch makes it so that we emit the necessary PutHint at node `j`.
        I've also added more validation to the OSRAvailabilityAnalysisPhase
        to catch this problem during validation.

        * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
        (JSC::DFG::OSRAvailabilityAnalysisPhase::run):
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationMaterializeObjectInOSR):

2017-02-10  Carlos Garcia Campos  <cgarcia@igalia.com>

        WebInspector: refactor RemoteInspector to move cocoa specific code to their own files
        https://bugs.webkit.org/show_bug.cgi?id=166681

        Reviewed by Michael Catanzaro.

        Move RemoteConnectionToTarget.mm and RemoteInspector.mm to a cocoa directory renamed with a Cocoa prefix,
        because those are now the cocoa implementation of RemoteConnectionToTarget and RemoteInspector. The
        cross-platform parts of RemoteInspector have been moced to a new RemoteInspector.cpp file. Also moved to cocoa
        directory RemoteInspectorXPCConnection.h and RemoteInspectorXPCConnection.mm keeping the same name. Other than
        that there aren't important code changes, only some cocoa specific types like NSString used in common headers,
        and some other platform ifdefs needed. This is in preparation for adding a remote inspector implementation for
        the GTK+ port.

        * API/JSRemoteInspector.cpp:
        (JSRemoteInspectorSetParentProcessInformation): Add PLATFORM(COCOA) to the ifdef.
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * PlatformMac.cmake:
        * inspector/remote/RemoteConnectionToTarget.h: Add platform ifdefs for cocoa specific parts and change
        sendMessageToTarget to receive a WTF String instead of an NSString.
        * inspector/remote/RemoteControllableTarget.h: Add platform ifdefs for CF specific parts.
        * inspector/remote/RemoteInspectionTarget.h:
        * inspector/remote/RemoteInspector.cpp: Added.
        (Inspector::RemoteInspector::startDisabled):
        (Inspector::RemoteInspector::nextAvailableTargetIdentifier):
        (Inspector::RemoteInspector::registerTarget):
        (Inspector::RemoteInspector::unregisterTarget):
        (Inspector::RemoteInspector::updateTarget):
        (Inspector::RemoteInspector::updateClientCapabilities):
        (Inspector::RemoteInspector::setRemoteInspectorClient):
        (Inspector::RemoteInspector::setupFailed):
        (Inspector::RemoteInspector::setupCompleted):
        (Inspector::RemoteInspector::waitingForAutomaticInspection):
        (Inspector::RemoteInspector::clientCapabilitiesDidChange):
        (Inspector::RemoteInspector::stop):
        (Inspector::RemoteInspector::listingForTarget):
        (Inspector::RemoteInspector::updateHasActiveDebugSession):
        * inspector/remote/RemoteInspector.h: Add platform ifdefs for cocoa specific parts. Also add TargetListing
        typedef to define platform specific types for the listings without more ifdefs.
        * inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm: Renamed from Source/JavaScriptCore/inspector/remote/RemoteConnectionToTarget.mm.
        (Inspector::RemoteTargetInitializeGlobalQueue):
        (Inspector::RemoteConnectionToTarget::setup):
        (Inspector::RemoteConnectionToTarget::close):
        (Inspector::RemoteConnectionToTarget::sendMessageToTarget):
        (Inspector::RemoteConnectionToTarget::setupRunLoop):
        * inspector/remote/cocoa/RemoteInspectorCocoa.mm: Renamed from Source/JavaScriptCore/inspector/remote/RemoteInspector.mm.
        (Inspector::canAccessWebInspectorMachPort):
        (Inspector::RemoteInspector::singleton):
        (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
        (Inspector::RemoteInspector::start):
        (Inspector::RemoteInspector::pushListingsSoon):
        (Inspector::RemoteInspector::receivedIndicateMessage):
        (Inspector::RemoteInspector::receivedProxyApplicationSetupMessage):
        * inspector/remote/cocoa/RemoteInspectorXPCConnection.h: Renamed from Source/JavaScriptCore/inspector/remote/RemoteInspectorXPCConnection.h.
        * inspector/remote/cocoa/RemoteInspectorXPCConnection.mm: Renamed from Source/JavaScriptCore/inspector/remote/RemoteInspectorXPCConnection.mm.
        (Inspector::RemoteInspectorXPCConnection::closeFromMessage):

2017-02-10  Brian Burg  <bburg@apple.com>

        [Cocoa] Web Inspector: payload initializers for ObjC protocol types handles special-cased property names incorrectly
        https://bugs.webkit.org/show_bug.cgi?id=168141

        Reviewed by Joseph Pecoraro.

        The generated code erroneously uses the ObjC variable name as the payload key,
        rather than the raw type member name. For example, 'identifier' would be used instead of 'id'.

        * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
        (ObjCProtocolTypesImplementationGenerator._generate_init_method_for_payload):

        * inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:
        Rebaseline an affected test.

2017-02-10  Mark Lam  <mark.lam@apple.com>

        StructureStubInfo::considerCaching() should write barrier its owner CodeBlock when buffering a new Structure.
        https://bugs.webkit.org/show_bug.cgi?id=168137
        <rdar://problem/28656664>

        Reviewed by Filip Pizlo.

        If we're adding a new structure to StructureStubInfo's bufferedStructures, we
        should write barrier the StubInfo's owner CodeBlock because that structure may be
        collected during the next GC.  Write barrier-ing the owner CodeBlock ensures that
        CodeBlock::finalizeBaselineJITInlineCaches() is called on it during the GC,
        which, in turn, gives the StructureStubInfo the opportunity to filter out the
        dead structure.

        * bytecode/StructureStubInfo.h:
        (JSC::StructureStubInfo::considerCaching):
        * jit/JITOperations.cpp:

2017-02-10  Brian Burg  <bburg@apple.com>

        [Cocoa] Web Inspector: generate an NS_ENUM containing platforms supported by the protocol code generator
        https://bugs.webkit.org/show_bug.cgi?id=168019
        <rdar://problem/28718990>

        Reviewed by Joseph Pecoraro.

        It's useful to have an symbolic value (not a string) for each of the supported platform values.
        Generate this once per protocol for the Objective-C bindings. Covered by existing tests.

        * inspector/scripts/codegen/generate_objc_header.py:
        (ObjCHeaderGenerator.generate_output):
        (ObjCHeaderGenerator._generate_enum_for_platforms):
        Create an NS_ENUM for Platform values in Platforms.

        * inspector/scripts/codegen/generate_objc_protocol_type_conversions_header.py:
        (ObjCProtocolTypeConversionsHeaderGenerator.generate_output):
        (ObjCProtocolTypeConversionsHeaderGenerator._generate_enum_conversion_for_platforms):
        Add type conversion/parsing methods for the newly added enum.

        * inspector/scripts/codegen/generator.py:
        (Generator.stylized_name_for_enum_value):
        (Generator.stylized_name_for_enum_value.replaceCallback):
        Support arbitrary special-cased substrings in enums, not just all-caps. Add 'IOS' and 'MacOS'.

        * inspector/scripts/codegen/models.py:
        (Platforms):
        Use lower-case string values for platform names, to avoid guesswork.

        (Platforms.__metaclass__):
        (Platforms.__metaclass__.__iter__):
        Make it possible to iterate over Platform instances of Platforms.

        * inspector/scripts/tests/all/expected/definitions-with-mac-platform.json-result:
        * inspector/scripts/tests/generic/expected/commands-with-async-attribute.json-result:
        * inspector/scripts/tests/generic/expected/commands-with-optional-call-return-parameters.json-result:
        * inspector/scripts/tests/generic/expected/definitions-with-mac-platform.json-result:
        * inspector/scripts/tests/generic/expected/domain-availability.json-result:
        * inspector/scripts/tests/generic/expected/domains-with-varying-command-sizes.json-result:
        * inspector/scripts/tests/generic/expected/enum-values.json-result:
        * inspector/scripts/tests/generic/expected/events-with-optional-parameters.json-result:
        * inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result:
        * inspector/scripts/tests/generic/expected/same-type-id-different-domain.json-result:
        * inspector/scripts/tests/generic/expected/shadowed-optional-type-setters.json-result:
        * inspector/scripts/tests/generic/expected/type-declaration-aliased-primitive-type.json-result:
        * inspector/scripts/tests/generic/expected/type-declaration-array-type.json-result:
        * inspector/scripts/tests/generic/expected/type-declaration-enum-type.json-result:
        * inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result:
        * inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:
        * inspector/scripts/tests/generic/expected/worker-supported-domains.json-result:
        * inspector/scripts/tests/ios/expected/definitions-with-mac-platform.json-result:
        * inspector/scripts/tests/mac/expected/definitions-with-mac-platform.json-result:
        Rebaseline results.

2017-02-09  Filip Pizlo  <fpizlo@apple.com>

        SharedArrayBuffer does not need to be in the transfer list
        https://bugs.webkit.org/show_bug.cgi?id=168079

        Reviewed by Geoffrey Garen and Keith Miller.
        
        Exposes a simple shareWith() API for when you know you want to share the contents of
        a shared buffer. Also a useful explicit operator bool.

        * runtime/ArrayBuffer.cpp:
        (JSC::ArrayBuffer::shareWith):
        * runtime/ArrayBuffer.h:
        (JSC::ArrayBufferContents::operator bool):

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

        B3::Procedure::deleteOrphans() should neutralize upsilons with dead phis.
        https://bugs.webkit.org/show_bug.cgi?id=167437
        <rdar://problem/30198083>

        Reviewed by Filip Pizlo.

        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::deleteOrphans):

2017-02-09  Saam Barati  <sbarati@apple.com>

        Sloppy mode: We don't properly hoist functions names "arguments" when we have a non-simple parameter list
        https://bugs.webkit.org/show_bug.cgi?id=167319
        <rdar://problem/30149432>

        Reviewed by Mark Lam.

        When hoisting a function inside sloppy mode, we were assuming all "var"s are inside
        what we call the "var" SymbolTableEntry. This was almost true, execpt for "arguments",
        which has sufficiently weird behavior. "arguments" can be visible to the default
        parameter expressions inside a function, therefore can't go inside the "var"
        SymbolTableEntry since the parameter SymbolTableEntry comes before the "var"
        SymbolTableEntry in the scope chain.  Therefore, if we hoist a function named
        "arguments", then we must also look for that variable inside the parameter scope
        stack entry.

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

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

        Fix max length check in ArrayPrototype.js' concatSlowPath().
        https://bugs.webkit.org/show_bug.cgi?id=167270
        <rdar://problem/30128133>

        Reviewed by Filip Pizlo.

        1. Fixed concatSlowPath() to ensure that the result array length does not exceed
           @MAX_ARRAY_INDEX.  The old code was checking against @MAX_SAFE_INTEGER in some
           cases, but this is overly permissive.

        2. Changed concatSlowPath() to throw a RangeError instead of a TypeError to be
           consistent with the C++ runtime functions in JSArray.cpp.

        3. Changed the RangeError message in concatSlowPath() and JSArray.cpp to "Length
           exceeded the maximum array length" when the error is that the result length
           exceeds MAX_ARRAY_INDEX.  We do this for 2 reasons:
           a. "Length exceeded the maximum array length" is more informative than
              "Invalid array length".
           b. We want to use the same string consistently for the same error.

           There are still 2 places in JSArray.cpp that still throws a RangeError with
           message "Invalid array length".  In those cases, the error is not necessarily
           due to the result length exceeding MAX_ARRAY_INDEX, but is due to attempting to
           set a length value that is not an integer that fits in MAX_ARRAY_INDEX e.g.
           an attempt to set a fractional length value.  Hence, "Invalid array length" is
           appropriate for those cases.

        4. Fixed JSArray::appendMemcpy() to handle overflows when computing the result
           array length.

        * builtins/ArrayPrototype.js:
        (concatSlowPath):
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * runtime/ArrayPrototype.cpp:
        (JSC::concatAppendOne):
        (JSC::arrayProtoPrivateFuncAppendMemcpy):
        * runtime/JSArray.cpp:
        (JSC::JSArray::appendMemcpy):
        (JSC::JSArray::push):

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

        Constructed object's global object should be the global object of the constructor.
        https://bugs.webkit.org/show_bug.cgi?id=167121
        <rdar://problem/30054759>

        Reviewed by Filip Pizlo and Geoffrey Garen.

        The realm (i.e. globalObject) of any object should be the same as the constructor
        that instantiated the object.  Changed PrototypeMap::createEmptyStructure() to
        be passed the correct globalObject to use instead of assuming it's the same one
        as the prototype object.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        * bytecode/InternalFunctionAllocationProfile.h:
        (JSC::InternalFunctionAllocationProfile::createAllocationStructureFromBase):
        * bytecode/ObjectAllocationProfile.h:
        (JSC::ObjectAllocationProfile::initialize):
        * runtime/FunctionRareData.cpp:
        (JSC::FunctionRareData::initializeObjectAllocationProfile):
        * runtime/FunctionRareData.h:
        (JSC::FunctionRareData::createInternalFunctionAllocationStructureFromBase):
        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::createSubclassStructure):
        * runtime/IteratorOperations.cpp:
        (JSC::createIteratorResultObjectStructure):
        * runtime/JSBoundFunction.cpp:
        (JSC::getBoundFunctionStructure):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::allocateAndInitializeRareData):
        (JSC::JSFunction::initializeRareData):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSProxy.cpp:
        (JSC::JSProxy::setTarget):
        * runtime/ObjectConstructor.h:
        (JSC::constructEmptyObject):
        * runtime/PrototypeMap.cpp:
        (JSC::PrototypeMap::createEmptyStructure):
        (JSC::PrototypeMap::emptyStructureForPrototypeFromBaseStructure):
        (JSC::PrototypeMap::emptyObjectStructureForPrototype):
        (JSC::PrototypeMap::clearEmptyObjectStructureForPrototype):
        * runtime/PrototypeMap.h:

2017-02-09  Keith Miller  <keith_miller@apple.com>

        We should not allow Function.caller to be used on native functions
        https://bugs.webkit.org/show_bug.cgi?id=165628

        Reviewed by Mark Lam.

        Also remove unneeded dynamic cast.

        * runtime/JSFunction.cpp:
        (JSC::RetrieveCallerFunctionFunctor::RetrieveCallerFunctionFunctor):
        (JSC::JSFunction::callerGetter):

2017-02-08  Keith Miller  <keith_miller@apple.com>

        [JSC] op_in should have ArrayProfile
        https://bugs.webkit.org/show_bug.cgi?id=164581

        Reviewed by Filip Pizlo.

        This patch adds an ArrayProfile to the op_in bytecode. In the
        DFG, if we see that we the key is an int32 we will convert the In
        DFG node to a HasIndexedProperty node instead.

        This patch also flips the two arguments of op_in and the In node
        to reflect the other property lookup bytecodes.

        * bytecode/BytecodeList.json:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::finishCreation):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitIn):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::emitIn): Deleted.
        * bytecompiler/NodesCodegen.cpp:
        (JSC::InNode::emitBytecode):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::convertToHasIndexedProperty):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasArrayMode):
        (JSC::DFG::Node::hasInternalMethodType):
        (JSC::DFG::Node::internalMethodType):
        (JSC::DFG::Node::setInternalMethodType):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileIn):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileIn):
        (JSC::FTL::DFG::LowerDFGToB3::compileHasIndexedProperty):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * llint/LowLevelInterpreter.asm:
        * parser/Nodes.h:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::opIn):

2017-02-08  Saam Barati  <sbarati@apple.com>

        Air IRC might spill a terminal that produces a value after the terminal
        https://bugs.webkit.org/show_bug.cgi?id=167919
        <rdar://problem/29754721>

        Reviewed by Filip Pizlo.

        IRC may spill a value-producing terminal (a patchpoint can be a value-producing terminal).
        It used to do this by placing the spill *after* the terminal. This produces an invalid
        graph because no instructions are allowed after the terminal.
        
        I fixed this bug by having a cleanup pass over the IR after IRC is done.
        The pass detects this problem, and fixes it by moving the spill into the
        successors. However, it is careful to detect when the edge to the
        successor is a critical edge. If the value-producing patchpoint is
        the only predecessor of the successor, it just moves the spill
        code to the beginning of the successor. Otherwise, it's a critical
        edge and it breaks it by adding a block that does the spilling then
        jumps to the successor.

        * b3/air/AirInsertionSet.cpp:
        * b3/air/AirInsertionSet.h:
        (JSC::B3::Air::InsertionSet::insertInsts):
        * b3/air/AirIteratedRegisterCoalescing.cpp:
        * b3/testb3.cpp:
        (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled):
        (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled2):
        (JSC::B3::run):

2017-02-07  Mark Lam  <mark.lam@apple.com>

        SigillCrashAnalyzer::analyze() should use a do-while loop instead of a lambda.
        https://bugs.webkit.org/show_bug.cgi?id=167950

        Reviewed by Michael Saboff.

        Lambdas aren't free (apparently, the compiler isn't able to detect that the
        lambda does not escape and can be inlined completely).  So, use a do-while loop
        instead since we don't really need a lambda here.

        * tools/SigillCrashAnalyzer.cpp:

2017-02-05  Mark Lam  <mark.lam@apple.com>

        The SigillCrashAnalyzer should play nicer with client code that may install its own SIGILL handler.
        https://bugs.webkit.org/show_bug.cgi?id=167858

        Reviewed by Michael Saboff.

        Here are the scenarios that may come up:

        1. Client code did not install a SIGILL handler.
           - In this case, once we're done analyzing the SIGILL, we can just restore the
             default handler and return to let the OS do the default action i.e. capture
             a core dump.

        2. Client code installed a SIGILL handler before JSC does.
           - In this case, we will see a non-null handler returned as the old signal
             handler when we install ours.
           - In our signal handler, after doing our crash analysis, we should invoke the
             client handler to let it do its work.
           - Our analyzer can also tell us if the SIGILL source is from JSC code in
             general (right now, this would just mean JIT code).
           - If the SIGILL source is not from JSC, we'll just let the client handler
             decided how to proceed.  We assume that the client handler will do the right
             thing (which is how the old behavior is before the SigillCrashAnalyzer was
             introduced).
           - If the SIGILL source is from JSC, then we know the SIGILL is an unrecoverable
             condition.  Hence, after we have given the client handler a chance to run,
             we should restore the default handler and let the OS capture a core dump.
             This intentionally overrides whatever signal settings the client handler may
             have set.

        3. Client code installed a SIGILL handler after JSC does.
           - In this case, we are dependent on the client handler to call our handler
             after it does its work.  This is compatible with the old behavior before
             SigillCrashAnalyzer was introduced.
           - In our signal handler, if we determine that the SIGILL source is from JSC
             code, then the SIGILL is not recoverable.  We should then restore the
             default handler and get a core dump.
           - If the SIGILL source is not from JSC, we check to see if there's a client
             handler installed after us.
           - If we detect a client handler installed after us, we defer judgement on what
             to do to the client handler.  Since the client handler did not uninstall
             itself, it must have considered itself to have recovered from the SIGILL.
             We'll trust the client handler and take no restore action of our own (which
             is compatible with old code behavior).
           - If we detect no client handler and we have no previous handler, then we
             should restore the default handler and get a core dump.

        * tools/SigillCrashAnalyzer.cpp:
        (JSC::handleCrash):
        (JSC::installCrashHandler):
        (JSC::SigillCrashAnalyzer::analyze): Deleted.

2017-02-07  Yusuke Suzuki  <utatane.tea@gmail.com>

        Unreviewed, manual roll out of r211777
        https://bugs.webkit.org/show_bug.cgi?id=167457

        * jsc.cpp:
        (GlobalObject::moduleLoaderImportModule):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncImportModule):

2017-02-07  Yusuke Suzuki  <utatane.tea@gmail.com>

        Web Inspector: allow import() inside the inspector
        https://bugs.webkit.org/show_bug.cgi?id=167457

        Reviewed by Ryosuke Niwa.

        We relax import module hook to accept null SourceOrigin.
        Such a script can be evaluated from the inspector console.

        * jsc.cpp:
        (GlobalObject::moduleLoaderImportModule):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncImportModule):

2017-02-06  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Do not use RunLoop when dispatching inspector GC event
        https://bugs.webkit.org/show_bug.cgi?id=167683
        <rdar://problem/30167791>

        Reviewed by Brian Burg.

        Move the RunLoop deferred implementation to WebCore. It is not needed
        for JSContext inspection, and in JSContext inspection we are not
        guarenteed a RunLoop to defer to.

        * inspector/agents/InspectorHeapAgent.h:
        * inspector/agents/InspectorHeapAgent.cpp:
        (Inspector::InspectorHeapAgent::InspectorHeapAgent):
        (Inspector::InspectorHeapAgent::~InspectorHeapAgent):
        (Inspector::InspectorHeapAgent::disable):
        (Inspector::InspectorHeapAgent::didGarbageCollect):
        (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask): Deleted.
        (Inspector::SendGarbageCollectionEventsTask::addGarbageCollection): Deleted.
        (Inspector::SendGarbageCollectionEventsTask::reset): Deleted.
        (Inspector::SendGarbageCollectionEventsTask::timerFired): Deleted.

        (Inspector::InspectorHeapAgent::dispatchGarbageCollectedEvent):
        Make a virtual method so that WebCore implementations of this agent can choose
        to dispatch this event asynchronously.

        * inspector/agents/InspectorScriptProfilerAgent.cpp:
        Remove unnecessary RunLoop include.

2017-02-06  Joseph Pecoraro  <pecoraro@apple.com>

        Static Analyzer: JSContext.mm: Incorrect decrement of the reference count of an object
        https://bugs.webkit.org/show_bug.cgi?id=167848

        Reviewed by Saam Barati.

        Source/JavaScriptCore/API/JSContext.mm:87:5: warning: Incorrect decrement of the reference count of an object that is not owned at this point by the caller
            [self.exceptionHandler release];
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        1 warning generated.

        * API/JSContext.mm:
        (-[JSContext dealloc]):
        Use the ivar in dealloc instead of going through the getter.

2017-02-05  Mark Lam  <mark.lam@apple.com>

        The VMInspector should use an RAII Locker.
        https://bugs.webkit.org/show_bug.cgi?id=167854

        Reviewed by Saam Barati.

        Previously, VMInspector::lock() was returning an expected LockToken, and there's
        no way to unlock it when we're done with it.  This was not a problem before
        because the VMInspector had only one client, the SigillCrashAnalyzer, that
        expected the process to crash due to a SIGILL shortly thereafter.

        However, the VMInspector is useful as a debugging tool that we can apply in other
        debugging tasks.  Fixing VMInspector::lock() to return an RAII locker will enable
        other use cases.  Plus it's just bad form to be able to lock something and never
        be able to unlock it.

        * tools/SigillCrashAnalyzer.cpp:
        (JSC::SigillCrashAnalyzer::analyze):
        * tools/VMInspector.cpp:
        * tools/VMInspector.h:

2017-02-04  Joseph Pecoraro  <pecoraro@apple.com>

        Static Analyzer: Value stored to 'recordedMachineThreads' during its initialization is never read
        https://bugs.webkit.org/show_bug.cgi?id=167845

        Reviewed by Saam Barati.

        Source/JavaScriptCore/heap/MachineStackMarker.cpp:151:14: warning: Value stored to 'recordedMachineThreads' during its initialization is never read
                auto recordedMachineThreads = m_set.take(machineThreads);
                     ^~~~~~~~~~~~~~~~~~~~~~   ~~~~~~~~~~~~~~~~~~~~~~~~~~

        * heap/MachineStackMarker.cpp:
        (JSC::ActiveMachineThreadsManager::remove):

2017-02-04  Joseph Pecoraro  <pecoraro@apple.com>

        Static Analyzer: Value stored to 'prev' is never read
        https://bugs.webkit.org/show_bug.cgi?id=167844

        Reviewed by Saam Barati.

        Source/JavaScriptCore/runtime/JSMapIterator.h:60:13: warning: Value stored to 'prev' is never read
                    prev = bucket;
                    ^      ~~~~~~
        Source/JavaScriptCore/runtime/JSSetIterator.h:60:13: warning: Value stored to 'prev' is never read
                    prev = bucket;
                    ^      ~~~~~~

        * runtime/JSMapIterator.h:
        (JSC::JSMapIterator::advanceIter):
        * runtime/JSSetIterator.h:
        (JSC::JSSetIterator::advanceIter):

2017-02-04  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Add operationToInt32SensibleSlow to optimize kraken pbkdf2 and sha256
        https://bugs.webkit.org/show_bug.cgi?id=167736

        Reviewed by Saam Barati.

        Add a new function operationToInt32SensibleSlow. This function is only
        called after x86 cvttss2si_rr is failed. This means that the
        given double number never in range of int32 truncatable numbers.

        As a result, exp in operationToInt32 always becomes >= 31. So
        we can change the condition from `exp < 32` to `exp == 31`.
        This makes missingOne constant. And it leads significantly good
        code generation.

        The original operationToInt32 code.

            170:   66 48 0f 7e c1          movq   %xmm0,%rcx
            175:   31 c0                   xor    %eax,%eax
            177:   66 48 0f 7e c6          movq   %xmm0,%rsi
            17c:   48 c1 f9 34             sar    $0x34,%rcx
            180:   81 e1 ff 07 00 00       and    $0x7ff,%ecx
            186:   8d 91 01 fc ff ff       lea    -0x3ff(%rcx),%edx
            18c:   83 fa 53                cmp    $0x53,%edx
            18f:   77 37                   ja     1c8 <_ZN3JSC16operationToInt32Ed+0x58>
            191:   83 fa 34                cmp    $0x34,%edx
            194:   7f 3a                   jg     1d0 <_ZN3JSC16operationToInt32Ed+0x60>
            196:   b9 34 00 00 00          mov    $0x34,%ecx
            19b:   66 48 0f 7e c7          movq   %xmm0,%rdi
            1a0:   29 d1                   sub    %edx,%ecx
            1a2:   48 d3 ff                sar    %cl,%rdi
            1a5:   83 fa 1f                cmp    $0x1f,%edx
            1a8:   89 f8                   mov    %edi,%eax
            1aa:   7f 12                   jg     1be <_ZN3JSC16operationToInt32Ed+0x4e>
            1ac:   89 d1                   mov    %edx,%ecx
            1ae:   b8 01 00 00 00          mov    $0x1,%eax
            1b3:   d3 e0                   shl    %cl,%eax
            1b5:   89 c2                   mov    %eax,%edx
            1b7:   8d 40 ff                lea    -0x1(%rax),%eax
            1ba:   21 f8                   and    %edi,%eax
            1bc:   01 d0                   add    %edx,%eax
            1be:   89 c2                   mov    %eax,%edx
            1c0:   f7 da                   neg    %edx
            1c2:   48 85 f6                test   %rsi,%rsi
            1c5:   0f 48 c2                cmovs  %edx,%eax
            1c8:   f3 c3                   repz retq
            1ca:   66 0f 1f 44 00 00       nopw   0x0(%rax,%rax,1)
            1d0:   66 48 0f 7e c0          movq   %xmm0,%rax
            1d5:   81 e9 33 04 00 00       sub    $0x433,%ecx
            1db:   48 d3 e0                shl    %cl,%rax
            1de:   eb de                   jmp    1be <_ZN3JSC16operationToInt32Ed+0x4e>

        The operationToInt32SensibleSlow code.

            1e0:   66 48 0f 7e c1          movq   %xmm0,%rcx
            1e5:   66 48 0f 7e c2          movq   %xmm0,%rdx
            1ea:   48 c1 f9 34             sar    $0x34,%rcx
            1ee:   81 e1 ff 07 00 00       and    $0x7ff,%ecx
            1f4:   8d b1 01 fc ff ff       lea    -0x3ff(%rcx),%esi
            1fa:   83 fe 34                cmp    $0x34,%esi
            1fd:   7e 21                   jle    220 <_ZN3JSC28operationToInt32SensibleSlowEd+0x40>
            1ff:   66 48 0f 7e c0          movq   %xmm0,%rax
            204:   81 e9 33 04 00 00       sub    $0x433,%ecx
            20a:   48 d3 e0                shl    %cl,%rax
            20d:   89 c1                   mov    %eax,%ecx
            20f:   f7 d9                   neg    %ecx
            211:   48 85 d2                test   %rdx,%rdx
            214:   0f 48 c1                cmovs  %ecx,%eax
            217:   c3                      retq
            218:   0f 1f 84 00 00 00 00    nopl   0x0(%rax,%rax,1)
            21f:   00
            220:   66 48 0f 7e c0          movq   %xmm0,%rax
            225:   b9 34 00 00 00          mov    $0x34,%ecx
            22a:   29 f1                   sub    %esi,%ecx
            22c:   48 d3 f8                sar    %cl,%rax
            22f:   89 c1                   mov    %eax,%ecx
            231:   81 c9 00 00 00 80       or     $0x80000000,%ecx
            237:   83 fe 1f                cmp    $0x1f,%esi
            23a:   0f 44 c1                cmove  %ecx,%eax
            23d:   89 c1                   mov    %eax,%ecx
            23f:   f7 d9                   neg    %ecx
            241:   48 85 d2                test   %rdx,%rdx
            244:   0f 48 c1                cmovs  %ecx,%eax
            247:   c3                      retq
            248:   0f 1f 84 00 00 00 00    nopl   0x0(%rax,%rax,1)
            24f:   00

        This improves kraken pbkdf2 by 10.8% and sha256 by 7.5%.

                                                       baseline                  patched

            stanford-crypto-pbkdf2                 153.195+-2.745      ^     138.204+-2.513         ^ definitely 1.1085x faster
            stanford-crypto-sha256-iterative        49.047+-1.038      ^      45.610+-1.235         ^ definitely 1.0754x faster

            <arithmetic>                           101.121+-1.379      ^      91.907+-1.500         ^ definitely 1.1003x faster

        * assembler/CPU.h:
        (JSC::hasSensibleDoubleToInt):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileValueToInt32):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::doubleToInt32):
        (JSC::FTL::DFG::LowerDFGToB3::sensibleDoubleToInt32):
        * ftl/FTLOutput.cpp:
        (JSC::FTL::Output::hasSensibleDoubleToInt): Deleted.
        * ftl/FTLOutput.h:
        * runtime/MathCommon.cpp:
        (JSC::operationToInt32SensibleSlow):
        * runtime/MathCommon.h:

2017-02-03  Joseph Pecoraro  <pecoraro@apple.com>

        Unreviewed rollout of r211486, r211629.

        Original change is not ideal and is causing issues.

        * inspector/agents/InspectorHeapAgent.cpp:
        (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):
        * runtime/InitializeThreading.cpp:
        (JSC::initializeThreading):

2017-02-03  JF Bastien  <jfbastien@apple.com>

        OSR entry: delay outer-loop compilation when at inner-loop
        https://bugs.webkit.org/show_bug.cgi?id=167149

        Reviewed by Filip Pizlo.

        r211224 and r211461 were reverted because they caused massive
        kraken/ai-astar regressions. This patch instead does the
        minimally-disruptive change to fix the original bug as described
        below, but omits extra tuning and refactoring which I had
        before. I'll commit tuning and refactoring separately, if this
        sticks. This patch is therefore very minimal, and layers carefully
        on top of the complex spaghetti-logic. The only change it makes is
        that it uses triggers to indicate to outer loops that they should
        compile, which fixes the immediate bug and seems roughly perf
        neutral (maybe a small gain on kraken sometimes, other times a
        small regression as would be expected from slightly compiling
        later). As opposed to r211461 this patch doesn't unconditionally
        unset the trigger because it prevents further DFG executions from
        entering. It therefore makes the trigger a tri-state enum class:
        don't trigger, compilation done, start compilation. Only "start
        compilation" gets reset to "don't trigger". "Compilation done"
        does not (unless there's a problem compiling, then it gets set
        back to "don't trigger").

        As of https://bugs.webkit.org/show_bug.cgi?id=155217 OSR
        compilation can be kicked off for an entry into an outer-loop,
        while executing an inner-loop. This is desirable because often the
        codegen from an inner-entry isn't as good as the codegen from an
        outer-entry, but execution from an inner-loop is often pretty hot
        and likely to kick off compilation. This approach provided nice
        speedups on Kraken because we'd select to enter to the outer-loop
        very reliably, which reduces variability (the inner-loop was
        selected roughly 1/5 times from my unscientific measurements).

        When compilation starts we take a snapshot of the JSValues at the
        current execution state using OSR's recovery mechanism. These
        values are passed to the compiler and are used as way to perform
        type profiling, and could be used to observe cell types as well as
        to perform predictions such as through constant propagation.

        It's therefore desired to enter from the outer-loop when we can,
        but we need to be executing from that location to capture the
        right JSValues, otherwise we're confusing the compiler and giving
        it inaccurate JSValues which can lead it to predict the wrong
        things, leading to suboptimal code or recompilation due to
        misprediction, or in super-corner-cases a crash.

        DFG tier-up was added here:
        https://bugs.webkit.org/show_bug.cgi?id=112838

        * dfg/DFGJITCode.h:
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::JITCompiler):
        * dfg/DFGOperations.cpp:
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.cpp:
        (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::ToFTLForOSREntryDeferredCompilationCallback):
        (JSC::DFG::Ref<ToFTLForOSREntryDeferredCompilationCallback>ToFTLForOSREntryDeferredCompilationCallback::create):
        (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
        (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidComplete):
        * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.h:

2017-02-03  Saam Barati  <sbarati@apple.com>

        When OSR entering to the baseline JIT from the LLInt for a ProgramCodeBlock we can skip compiling a lot of the program
        https://bugs.webkit.org/show_bug.cgi?id=167725
        <rdar://problem/30339082>

        Reviewed by Michael Saboff.

        We often want to baseline compile ProgramCode once we hit a loop in the LLInt.
        However, some programs execute a non-trivial amount of code before the loop.
        This code can never be executed again because ProgramCodeBlocks never run more
        than once. We're wasting time and memory by compiling code that is unreachable
        from the OSR entry destination. This patch fixes this by only compiling code
        that is reachable from the OSR entry destination.

        This is a speedup on Kraken/ai-astar for devices with limited CPUs (I've been
        testing on devices with 2 CPUs). On ai-astar, we were spending 50-100ms compiling
        a huge ProgramCodeBlock in the baseline JIT where the majority of the code
        would never execute. If this compilation was kicked off on the main thread,
        then we'd be stalled for a long time. If it were started on the baseline JITs
        background compilation thread, we'd still waste 50-100ms in that thread, causing
        all other baseline compilations to happen on the main thread.

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::executeProgram):
        * interpreter/Interpreter.h:
        * jit/JIT.cpp:
        (JSC::JIT::JIT):
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        (JSC::JIT::compile):
        * jit/JITWorklist.cpp:
        (JSC::JITWorklist::Plan::Plan):
        (JSC::JITWorklist::Plan::compileNow):
        (JSC::JITWorklist::compileLater):
        (JSC::JITWorklist::compileNow):
        * jit/JITWorklist.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::jitCompileAndSetHeuristics):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/Completion.cpp:
        (JSC::evaluate):

2017-02-03  Csaba Osztrogonác  <ossy@webkit.org>

        Unreviewed typo fix after r211630.

        * CMakeLists.txt:

2017-02-03  Carlos Garcia Campos  <cgarcia@igalia.com>

        [GTK] Add initial implementation of resource usage overlay
        https://bugs.webkit.org/show_bug.cgi?id=167731

        Reviewed by Michael Catanzaro.

        Also expose nextFireTime() for GTK+ port.

        * heap/GCActivityCallback.cpp:
        (JSC::GCActivityCallback::scheduleTimer):
        (JSC::GCActivityCallback::cancelTimer):
        * heap/GCActivityCallback.h:

2017-02-03  Csaba Osztrogonác  <ossy@webkit.org>

        [cmake] Unreviewed AArch64 buildfix after r211603.
        https://bugs.webkit.org/show_bug.cgi?id=167714

        * CMakeLists.txt:

2017-02-02  Andreas Kling  <akling@apple.com>

        [Mac] In-process memory pressure monitor for WebContent processes AKA websam
        <https://webkit.org/b/167491>
        <rdar://problem/30116072>

        Reviewed by Antti Koivisto.

        Remove the sloppy "max live heap size" mechanism from JSC in favor of the new
        WebCore-side memory footprint monitor.

        * heap/Heap.cpp:
        (JSC::Heap::updateAllocationLimits):
        (JSC::Heap::didExceedMaxLiveSize): Deleted.
        * heap/Heap.h:
        (JSC::Heap::setMaxLiveSize): Deleted.

2017-02-02  Mark Lam  <mark.lam@apple.com>

        Add a SIGILL crash analyzer to make debugging SIGILLs easier.
        https://bugs.webkit.org/show_bug.cgi?id=167714
        <rdar://problem/30318237>

        Not reviewed.

        Build fix for CLOOP build.

        * tools/VMInspector.cpp:

2017-02-02  Mark Lam  <mark.lam@apple.com>

        Add a SIGILL crash analyzer to make debugging SIGILLs easier.
        https://bugs.webkit.org/show_bug.cgi?id=167714
        <rdar://problem/30318237>

        Reviewed by Filip Pizlo.

        The current implementation is only for X86_64 and ARM64 on OS(DARWIN).  The
        analyzer is not enabled for all other ports.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * API/JSVirtualMachine.mm:
        * assembler/ARM64Assembler.h:
        (JSC::ARM64Assembler::illegalInstruction):
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::illegalInstruction):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::illegalInstruction):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::illegalInstruction):
        * heap/Heap.cpp:
        (JSC::Heap::forEachCodeBlockIgnoringJITPlansImpl):
        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::forEachCodeBlockIgnoringJITPlans):
        * runtime/Options.cpp:
        (JSC::Options::isAvailable):
        (JSC::recomputeDependentOptions):
        * runtime/Options.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::~VM):
        * runtime/VM.h:
        * tools/SigillCrashAnalyzer.cpp: Added.
        (JSC::SignalContext::SignalContext):
        (JSC::SignalContext::dump):
        (JSC::handleCrash):
        (JSC::initializeCrashHandler):
        (JSC::ensureSigillCrashAnalyzer):
        (JSC::SigillCrashAnalyzer::analyze):
        (JSC::SigillCrashAnalyzer::dumpCodeBlock):
        * tools/SigillCrashAnalyzer.h: Added.
        * tools/VMInspector.cpp: Added.
        (JSC::VMInspector::instance):
        (JSC::VMInspector::add):
        (JSC::VMInspector::remove):
        (JSC::ensureIsSafeToLock):
        * tools/VMInspector.h: Added.
        (JSC::VMInspector::iterate):

2017-02-02  Chris Dumez  <cdumez@apple.com>

        {}.toString.call(crossOriginWindow) should return "[object Object]"
        https://bugs.webkit.org/show_bug.cgi?id=167701
        <rdar://problem/30330797>

        Reviewed by Keith Miller.

        Have JSProxy forward toStringName calls to its target so Window
        can override it.

        * runtime/JSProxy.cpp:
        (JSC::JSProxy::toStringName):
        * runtime/JSProxy.h:

2017-02-02  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r211571 and r211582.
        https://bugs.webkit.org/show_bug.cgi?id=167751

        This change caused API test WebKit1.MemoryPressureHandler to
        fail with an assertion. (Requested by ryanhaddad on #webkit).

        Reverted changesets:

        "[Mac] In-process memory pressure monitor for WebContent
        processes."
        https://bugs.webkit.org/show_bug.cgi?id=167491
        http://trac.webkit.org/changeset/211571

        "Unreviewed attempt to fix the Windows build after r211571."
        http://trac.webkit.org/changeset/211582

2017-02-02  Andreas Kling  <akling@apple.com>

        [Mac] In-process memory pressure monitor for WebContent processes.
        <https://webkit.org/b/167491>
        <rdar://problem/30116072>

        Reviewed by Antti Koivisto.

        Remove the sloppy "max live heap size" mechanism from JSC in favor of the new
        WebCore-side memory footprint monitor.

        * heap/Heap.cpp:
        (JSC::Heap::updateAllocationLimits):
        (JSC::Heap::didExceedMaxLiveSize): Deleted.
        * heap/Heap.h:
        (JSC::Heap::setMaxLiveSize): Deleted.

2017-02-02  Joseph Pecoraro  <pecoraro@apple.com>

        Removed unused m_errorHandlingModeReentry from Interpreter
        https://bugs.webkit.org/show_bug.cgi?id=167726

        Reviewed by Yusuke Suzuki.

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

2017-02-01  Commit Queue  <commit-queue@webkit.org>

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

        Big regression on kraken (Requested by jfbastien on #webkit).

        Reverted changeset:

        "OSR entry: delay outer-loop compilation when at inner-loop"
        https://bugs.webkit.org/show_bug.cgi?id=167149
        http://trac.webkit.org/changeset/211461

2017-02-01  Keith Miller  <keith_miller@apple.com>

        Unreviewed, fix unintended change.

        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::StackFrame::displayName):

2017-02-01  Keith Miller  <keith_miller@apple.com>

        The sampling profile should have an option to sample from C frames.
        https://bugs.webkit.org/show_bug.cgi?id=167614

        Reviewed by Saam Barati.

        We should be able to use the sampling profiler, at least
        internally, to trace C calls.  This patch only modifies the JSC
        shell although it would be nice to add it to the Web Inspector in
        a future patch.

        * runtime/Options.h:
        * runtime/SamplingProfiler.cpp:
        (JSC::FrameWalker::FrameWalker):
        (JSC::FrameWalker::walk):
        (JSC::FrameWalker::recordJSFrame):
        (JSC::CFrameWalker::CFrameWalker):
        (JSC::CFrameWalker::walk):
        (JSC::CFrameWalker::isCFrame):
        (JSC::CFrameWalker::advanceToParentFrame):
        (JSC::CFrameWalker::frame):
        (JSC::SamplingProfiler::takeSample):
        (JSC::SamplingProfiler::processUnverifiedStackTraces):
        (JSC::SamplingProfiler::StackFrame::displayName):
        * runtime/SamplingProfiler.h:
        (JSC::SamplingProfiler::UnprocessedStackFrame::UnprocessedStackFrame):

2017-02-01  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Use guaranteed RunLoop instead of RunLoop::current for dispatching inspector GC event
        https://bugs.webkit.org/show_bug.cgi?id=167683
        <rdar://problem/30167791>

        Reviewed by Timothy Hatcher.

        * inspector/agents/InspectorHeapAgent.cpp:
        (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):
        Use RunLoop::main instead of RunLoop::current which may go away.

        * runtime/InitializeThreading.cpp:
        (JSC::initializeThreading):
        Ensure RunLoop::main is initialized when using JSC APIs.

2017-02-01  Yusuke Suzuki  <utatane.tea@gmail.com>

        ArityFixup should adjust SP first
        https://bugs.webkit.org/show_bug.cgi?id=167239

        Reviewed by Michael Saboff.

        Arity fixup extends the stack and copy/fill the stack with
        the values. At that time, we accidentally read/write stack
        space below the stack pointer. As a result, we touch the area
        of the stack space below the x64 red zone. These areas are unsafe.
        OS may corrupt this space when constructing a signal stack.
        The Linux kernel could not populate the pages for this space
        and causes segmentation fault. This patch changes the stack
        pointer before performing the arity fixup.

        * jit/ThunkGenerators.cpp:
        (JSC::arityFixupGenerator):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

2017-01-31  Filip Pizlo  <fpizlo@apple.com>

        Make verifyEdge a RELEASE_ASSERT
        <rdar://problem/30296879>

        Rubber stamped by Saam Barati.

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

2017-01-31  JF Bastien  <jfbastien@apple.com>

        OSR entry: delay outer-loop compilation when at inner-loop
        https://bugs.webkit.org/show_bug.cgi?id=167149

        Reviewed by Filip Pizlo.

        r211224 was reverted because it caused a massive kraken/ai-astar
        regression. This patch instead does the minimally-disruptive
        change to fix the original bug as described below, but omits extra
        tuning and refactoring which I had before. I'll commit tuning and
        refactoring separately, if this sticks. This patch is therefore
        very minimal, and layers carefully on top of the complex
        spaghetti-logic. The only change it makes is that it uses triggers
        to indicate to outer loops that they should compile, which fixes
        the immediate bug and seems roughly perf neutral (maybe a small
        gain on kraken sometimes, other times a small regression as would
        be expected from compiling later).

        As of https://bugs.webkit.org/show_bug.cgi?id=155217 OSR
        compilation can be kicked off for an entry into an outer-loop,
        while executing an inner-loop. This is desirable because often the
        codegen from an inner-entry isn't as good as the codegen from an
        outer-entry, but execution from an inner-loop is often pretty hot
        and likely to kick off compilation. This approach provided nice
        speedups on Kraken because we'd select to enter to the outer-loop
        very reliably, which reduces variability (the inner-loop was
        selected roughly 1/5 times from my unscientific measurements).

        When compilation starts we take a snapshot of the JSValues at the
        current execution state using OSR's recovery mechanism. These
        values are passed to the compiler and are used as way to perform
        type profiling, and could be used to observe cell types as well as
        to perform predictions such as through constant propagation.

        It's therefore desired to enter from the outer-loop when we can,
        but we need to be executing from that location to capture the
        right JSValues, otherwise we're confusing the compiler and giving
        it inaccurate JSValues which can lead it to predict the wrong
        things, leading to suboptimal code or recompilation due to
        misprediction, or in super-corner-cases a crash.

        These effects are pretty hard to measure: Fil points out that
        marsalis-osr-entry really needs mustHandleValues (the JSValues
        from the point of execution) because right now it just happens to
        correctly guess int32. I tried removing mustHandleValues entirely
        and saw no slowdowns, but our benchmarks probably aren't
        sufficient to reliably find issues, sometimes because we happen to
        have sufficient mitigations.

        DFG tier-up was added here:
        https://bugs.webkit.org/show_bug.cgi?id=112838

        * dfg/DFGOperations.cpp:

2017-01-31  Filip Pizlo  <fpizlo@apple.com>

        The mutator should be able to perform increments of GC work
        https://bugs.webkit.org/show_bug.cgi?id=167528

        Reviewed by Keith Miller and Geoffrey Garen.

        The cool thing about having a concurrent and parallel collector is that it's easy to also make
        it incremental, because the load balancer can also hand over work to anyone (including the
        mutator) and since the collector is running concurrently anyway, the mutator can usually rely
        on the balancer having some spare work.

        This change adds a classic work-based incremental mode to the GC. When you allocate K bytes,
        you have to do Options::gcIncrementScale() * K "bytes" of draining. This is ammortized so that
        it only happens in allocation slow paths.

        On computers that have a lot of CPUs, this mode is not profitable and we set gcIncrementScale
        to zero. On such computers, Riptide was already performing great because there was no way that
        one mutator thread could outpace many GC threads. But on computers with fewer CPUs, there were
        problems having to do with making the collector progress quickly enough so that the heap
        doesn't grow too much. The stochastic scheduler actually made things worse, because it relies
        a lot on the fact that the GC will simply be faster than the mutator anyway. The old scheduler
        claimed to address the problem of GC pace, but it used a time-based scheduler, which is not as
        precise at keeping pase as the new work-based incremental mode.

        In theory, the work-based mode guarantees a bound on how much the heap can grow during a
        collection just because each byte allocated means some number of bytes visited. We don't try
        to create such a theoretical bound. We're just trying to give the collector an unfair advantage
        in any race with the mutator.

        Turning on incremental mode, the stochastic scheduler, and passive draining in combination with
        each other is a huge splay-latency speed-up on my iPad. It's also a CDjs progression. It does
        regress splay-throughput, but I think that's fine (the regression is 11%, the progression is
        3x).

        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::~Heap):
        (JSC::Heap::markToFixpoint):
        (JSC::Heap::updateObjectCounts):
        (JSC::Heap::endMarking):
        (JSC::Heap::finalize):
        (JSC::Heap::didAllocate):
        (JSC::Heap::visitCount):
        (JSC::Heap::bytesVisited):
        (JSC::Heap::forEachSlotVisitor):
        (JSC::Heap::performIncrement):
        (JSC::Heap::threadVisitCount): Deleted.
        (JSC::Heap::threadBytesVisited): Deleted.
        * heap/Heap.h:
        * heap/MarkStack.cpp:
        (JSC::MarkStackArray::transferTo):
        * heap/MarkStack.h:
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::didStartMarking):
        (JSC::SlotVisitor::clearMarkStacks):
        (JSC::SlotVisitor::appendToMarkStack):
        (JSC::SlotVisitor::noteLiveAuxiliaryCell):
        (JSC::SlotVisitor::donateKnownParallel):
        (JSC::SlotVisitor::drain):
        (JSC::SlotVisitor::performIncrementOfDraining):
        (JSC::SlotVisitor::didReachTermination):
        (JSC::SlotVisitor::hasWork):
        (JSC::SlotVisitor::drainFromShared):
        (JSC::SlotVisitor::drainInParallelPassively):
        (JSC::SlotVisitor::donateAll):
        (JSC::SlotVisitor::correspondingGlobalStack):
        * heap/SlotVisitor.h:
        * heap/SlotVisitorInlines.h:
        (JSC::SlotVisitor::reportExtraMemoryVisited):
        (JSC::SlotVisitor::forEachMarkStack):
        * heap/SpaceTimeMutatorScheduler.cpp:
        (JSC::SpaceTimeMutatorScheduler::log):
        * heap/StochasticSpaceTimeMutatorScheduler.cpp:
        (JSC::StochasticSpaceTimeMutatorScheduler::log):
        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionHeapCapacity):
        * runtime/Options.cpp:
        (JSC::overrideDefaults):
        * runtime/Options.h:

2017-01-31  Tomas Popela  <tpopela@redhat.com>

        Compilation error in JSArrayBufferView.h
        https://bugs.webkit.org/show_bug.cgi?id=167642

        Reviewed by Alex Christensen.

        * runtime/JSArrayBufferView.h:
        (JSC::JSArrayBufferView::vector):

2017-01-30  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Do not reject WebAssembly.compile() with Exception
        https://bugs.webkit.org/show_bug.cgi?id=167585

        Reviewed by Mark Lam.

        We accidentally reject the promise with Exception instead of Exception::value()
        for the result of WebAssembly::compile().

        * wasm/JSWebAssembly.cpp:
        (JSC::webAssemblyCompileFunc):

2017-01-30  Joseph Pecoraro  <pecoraro@apple.com>

        Implement PerformanceObserver
        https://bugs.webkit.org/show_bug.cgi?id=167546
        <rdar://problem/30247959>

        Reviewed by Ryosuke Niwa.

        * runtime/CommonIdentifiers.h:

2017-01-30  Matt Baker  <mattbaker@apple.com>

        Web Inspector: Need some limit on Async Call Stacks for async loops (rAF loops)
        https://bugs.webkit.org/show_bug.cgi?id=165633
        <rdar://problem/29738502>

        Reviewed by Joseph Pecoraro.

        This patch limits the memory used by the Inspector backend to store async
        stack trace data.

        Asynchronous stack traces are stored as a disjoint set of parent pointer
        trees. Tree nodes represent asynchronous operations, and hold a copy of
        the stack trace at the time the operation was scheduled. Each tree can
        be regarded as a set of stack traces, stored as singly linked lists that
        share part of their structure (specifically their tails). Traces belonging
        to the same tree will at least share a common root. A stack trace begins
        at a leaf node and follows the chain of parent pointers to the root of
        of the tree. Leaf nodes always contain pending asynchronous calls.

        When an asynchronous operation is scheduled with requestAnimationFrame,
        setInterval, etc, a node is created containing the current call stack and
        some bookkeeping data for the operation. An unique identifier comprised
        of an operation type and callback identifier is mapped to the node. If
        scheduling the callback was itself the result of an asynchronous call,
        the node becomes a child of the node associated with that call, otherwise
        it becomes the root of a new tree.

        A node is either `pending`, `active`, `dispatched`, or `canceled`. Nodes
        start out as pending. After a callback for a pending node is dispatched
        the node is marked as such, unless it is a repeating callback such as
        setInterval, in which case it remains pending. Once a node is no longer
        pending it is removed, as long as it has no children. Since nodes are
        reference counted, it is a property of the stack trace tree that nodes
        that are no longer pending and have no children pointing to them will be
        automatically pruned from the tree.

        If an async operation is canceled (e.g. cancelTimeout), the associated
        node is marked as such. If the callback is not being dispatched at the
        time, and has no children, it is removed.

        Because async operations can be chained indefinitely, stack traces are
        limited to a maximum depth. The depth of a stack trace is equal to the
        sum of the depths of its nodes, with a node's depth equal to the number
        of frames in its associated call stack. For any stack trace,

            S = { s𝟶, s𝟷, …, s𝑘 }, with endpoints s𝟶, s𝑘
            depth(S) = depth(s𝟶) + depth(s𝟷) + … + depth(s𝑘)

        A stack trace is truncated when it exceeds the maximum depth. Truncation
        occurs on node boundaries, not call frames, consequently the maximum depth
        is more of a target than a guarantee:

            d = maximum stack trace depth
            for all S, depth(S) ≤ d + depth(s𝑘)

        Because nodes can belong to multiple stack traces, it may be necessary
        to clone the tail of a stack trace being truncated to prevent other traces
        from being effected.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * inspector/AsyncStackTrace.cpp: Added.
        (Inspector::AsyncStackTrace::create):
        (Inspector::AsyncStackTrace::AsyncStackTrace):
        (Inspector::AsyncStackTrace::~AsyncStackTrace):
        (Inspector::AsyncStackTrace::isPending):
        (Inspector::AsyncStackTrace::isLocked):
        (Inspector::AsyncStackTrace::willDispatchAsyncCall):
        (Inspector::AsyncStackTrace::didDispatchAsyncCall):
        (Inspector::AsyncStackTrace::didCancelAsyncCall):
        (Inspector::AsyncStackTrace::buildInspectorObject):
        (Inspector::AsyncStackTrace::truncate):
        (Inspector::AsyncStackTrace::remove):
        * inspector/AsyncStackTrace.h:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::didScheduleAsyncCall):
        (Inspector::InspectorDebuggerAgent::didCancelAsyncCall):
        (Inspector::InspectorDebuggerAgent::willDispatchAsyncCall):
        (Inspector::InspectorDebuggerAgent::didDispatchAsyncCall):
        (Inspector::InspectorDebuggerAgent::didPause):
        (Inspector::InspectorDebuggerAgent::clearAsyncStackTraceData):
        (Inspector::InspectorDebuggerAgent::buildAsyncStackTrace): Deleted.
        (Inspector::InspectorDebuggerAgent::refAsyncCallData): Deleted.
        (Inspector::InspectorDebuggerAgent::derefAsyncCallData): Deleted.
        * inspector/agents/InspectorDebuggerAgent.h:
        * inspector/protocol/Console.json:

2017-01-30  Ryan Haddad  <ryanhaddad@apple.com>

        Unreviewed, rolling out r211345.

        The LayoutTest for this change is failing an assertion.

        Reverted changeset:

        "Web Inspector: Need some limit on Async Call Stacks for async
        loops (rAF loops)"
        https://bugs.webkit.org/show_bug.cgi?id=165633
        http://trac.webkit.org/changeset/211345

2017-01-28  Matt Baker  <mattbaker@apple.com>

        Web Inspector: Need some limit on Async Call Stacks for async loops (rAF loops)
        https://bugs.webkit.org/show_bug.cgi?id=165633
        <rdar://problem/29738502>

        Reviewed by Joseph Pecoraro.

        This patch limits the memory used by the Inspector backend to store async
        stack trace data.

        Asynchronous stack traces are stored as a disjoint set of parent pointer
        trees. Tree nodes represent asynchronous operations, and hold a copy of
        the stack trace at the time the operation was scheduled. Each tree can
        be regarded as a set of stack traces, stored as singly linked lists that
        share part of their structure (specifically their tails). Traces belonging
        to the same tree will at least share a common root. A stack trace begins
        at a leaf node and follows the chain of parent pointers to the root of
        of the tree. Leaf nodes always contain pending asynchronous calls.

        When an asynchronous operation is scheduled with requestAnimationFrame,
        setInterval, etc, a node is created containing the current call stack and
        some bookkeeping data for the operation. An unique identifier comprised
        of an operation type and callback identifier is mapped to the node. If
        scheduling the callback was itself the result of an asynchronous call,
        the node becomes a child of the node associated with that call, otherwise
        it becomes the root of a new tree.

        A node is either `pending`, `active`, `dispatched`, or `canceled`. Nodes
        start out as pending. After a callback for a pending node is dispatched
        the node is marked as such, unless it is a repeating callback such as
        setInterval, in which case it remains pending. Once a node is no longer
        pending it is removed, as long as it has no children. Since nodes are
        reference counted, it is a property of the stack trace tree that nodes
        that are no longer pending and have no children pointing to them will be
        automatically pruned from the tree.

        If an async operation is canceled (e.g. cancelTimeout), the associated
        node is marked as such. If the callback is not being dispatched at the
        time, and has no children, it is removed.

        Because async operations can be chained indefinitely, stack traces are
        limited to a maximum depth. The depth of a stack trace is equal to the
        sum of the depths of its nodes, with a node's depth equal to the number
        of frames in its associated call stack. For any stack trace,

            S = { s𝟶, s𝟷, …, s𝑘 }, with endpoints s𝟶, s𝑘
            depth(S) = depth(s𝟶) + depth(s𝟷) + … + depth(s𝑘)

        A stack trace is truncated when it exceeds the maximum depth. Truncation
        occurs on node boundaries, not call frames, consequently the maximum depth
        is more of a target than a guarantee:

            d = maximum stack trace depth
            for all S, depth(S) ≤ d + depth(s𝑘)

        Because nodes can belong to multiple stack traces, it may be necessary
        to clone the tail of a stack trace being truncated to prevent other traces
        from being effected.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * inspector/AsyncStackTrace.cpp: Added.
        (Inspector::AsyncStackTrace::create):
        (Inspector::AsyncStackTrace::AsyncStackTrace):
        (Inspector::AsyncStackTrace::~AsyncStackTrace):
        (Inspector::AsyncStackTrace::isPending):
        (Inspector::AsyncStackTrace::isLocked):
        (Inspector::AsyncStackTrace::willDispatchAsyncCall):
        (Inspector::AsyncStackTrace::didDispatchAsyncCall):
        (Inspector::AsyncStackTrace::didCancelAsyncCall):
        (Inspector::AsyncStackTrace::buildInspectorObject):
        (Inspector::AsyncStackTrace::truncate):
        (Inspector::AsyncStackTrace::remove):
        * inspector/AsyncStackTrace.h:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::didScheduleAsyncCall):
        (Inspector::InspectorDebuggerAgent::didCancelAsyncCall):
        (Inspector::InspectorDebuggerAgent::willDispatchAsyncCall):
        (Inspector::InspectorDebuggerAgent::didDispatchAsyncCall):
        (Inspector::InspectorDebuggerAgent::didPause):
        (Inspector::InspectorDebuggerAgent::clearAsyncStackTraceData):
        (Inspector::InspectorDebuggerAgent::buildAsyncStackTrace): Deleted.
        (Inspector::InspectorDebuggerAgent::refAsyncCallData): Deleted.
        (Inspector::InspectorDebuggerAgent::derefAsyncCallData): Deleted.
        * inspector/agents/InspectorDebuggerAgent.h:
        * inspector/protocol/Console.json:

2017-01-28  Joseph Pecoraro  <pecoraro@apple.com>

        Remote Inspector: Listing should be updated when a target gains or loses a debugger session
        https://bugs.webkit.org/show_bug.cgi?id=167449

        Reviewed by Brian Burg.

        * inspector/remote/RemoteInspector.h:
        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::setupFailed):
        (Inspector::RemoteInspector::updateTargetListing):
        (Inspector::RemoteInspector::receivedSetupMessage):
        (Inspector::RemoteInspector::receivedDidCloseMessage):
        (Inspector::RemoteInspector::receivedConnectionDiedMessage):
        Whenever we add/remove a connection we should update the listing properties
        for that target that corresponded to that connection. In this way group
        updating active sessions, the target, and pushing listing together.

2017-01-27  Yusuke Suzuki  <utatane.tea@gmail.com>

        Lift template escape sequence restrictions in tagged templates
        https://bugs.webkit.org/show_bug.cgi?id=166871

        Reviewed by Saam Barati.

        This patch implements stage 3 Lifting Template Literal Restriction[1].
        Prior to this patch, template literal becomes syntax error if it contains
        invalid escape sequences. But it is too restricted; Template literal
        can have cooked and raw representations and only cooked representation
        can escape sequences. So even if invalid escape sequences are included,
        the raw representation can be valid.

        Lifting Template Literal Restriction relaxes the above restriction.
        When invalid escape sequence is included, if target template literals
        are used as tagged templates, we make the result of the template including
        the invalid escape sequence `undefined` instead of making it SyntaxError
        immediately. It allows us to accept the templates including invalid
        escape sequences in the raw representations in tagged templates.

        On the other hand, the raw representation is only used in tagged templates.
        So if invalid escape sequences are included in the usual template literals,
        we just make it SyntaxError as before.

        [1]: https://github.com/tc39/proposal-template-literal-revision

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitGetTemplateObject):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::TemplateStringNode::emitBytecode):
        (JSC::TemplateLiteralNode::emitBytecode):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createTemplateString):
        * parser/Lexer.cpp:
        (JSC::Lexer<CharacterType>::parseUnicodeEscape):
        (JSC::Lexer<T>::parseTemplateLiteral):
        (JSC::Lexer<T>::lex):
        (JSC::Lexer<T>::scanTemplateString):
        (JSC::Lexer<T>::scanTrailingTemplateString): Deleted.
        * parser/Lexer.h:
        * parser/NodeConstructors.h:
        (JSC::TemplateStringNode::TemplateStringNode):
        * parser/Nodes.h:
        (JSC::TemplateStringNode::cooked):
        (JSC::TemplateStringNode::raw):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseAssignmentElement):
        (JSC::Parser<LexerType>::parseTemplateString):
        (JSC::Parser<LexerType>::parseTemplateLiteral):
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        (JSC::Parser<LexerType>::parseMemberExpression):
        * parser/ParserTokens.h:
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createTemplateString):
        * runtime/TemplateRegistry.cpp:
        (JSC::TemplateRegistry::getTemplateObject):
        * runtime/TemplateRegistryKey.h:
        (JSC::TemplateRegistryKey::cookedStrings):
        (JSC::TemplateRegistryKey::create):
        (JSC::TemplateRegistryKey::TemplateRegistryKey):
        * runtime/TemplateRegistryKeyTable.cpp:
        (JSC::TemplateRegistryKeyTable::createKey):
        * runtime/TemplateRegistryKeyTable.h:

2017-01-27  Saam Barati  <sbarati@apple.com>

        Make the CLI for the sampling profiler better for inlined call site indices
        https://bugs.webkit.org/show_bug.cgi?id=167482

        Reviewed by Mark Lam.

        This patches changes the command line interface for the sampling
        profiler to also dump the machine frame that the semantic code
        origin is in if the semantic code origin is inlined. This helps
        when doing performance work because it's helpful to know the
        context that an inlined frame is in. Before, we used to just
        say it was in the baseline JIT if it didn't have its own optimized
        compile. Now, we can tell that its inlined into a DFG or FTL frame.

        * inspector/agents/InspectorScriptProfilerAgent.cpp:
        (Inspector::buildSamples):
        * runtime/Options.h:
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::processUnverifiedStackTraces):
        (JSC::SamplingProfiler::reportTopFunctions):
        (JSC::SamplingProfiler::reportTopBytecodes):
        * runtime/SamplingProfiler.h:
        (JSC::SamplingProfiler::StackFrame::CodeLocation::hasCodeBlockHash):
        (JSC::SamplingProfiler::StackFrame::CodeLocation::hasBytecodeIndex):
        (JSC::SamplingProfiler::StackFrame::CodeLocation::hasExpressionInfo):
        (JSC::SamplingProfiler::StackFrame::hasExpressionInfo):
        (JSC::SamplingProfiler::StackFrame::lineNumber):
        (JSC::SamplingProfiler::StackFrame::columnNumber):
        (JSC::SamplingProfiler::StackFrame::hasBytecodeIndex): Deleted.
        (JSC::SamplingProfiler::StackFrame::hasCodeBlockHash): Deleted.

2017-01-27  Yusuke Suzuki  <utatane.tea@gmail.com>

        Extend create_hash_table to specify Intrinsic
        https://bugs.webkit.org/show_bug.cgi?id=167505

        Reviewed by Sam Weinig.

        This patch extends create_hash_table to specify Intrinsic.
        We can set Intrinsic in the static property table definition
        in runtime/XXX.h.

        And drop the adhoc code for String.fromCharCode in create_hash_table.

        * create_hash_table:
        * runtime/StringConstructor.cpp:

2017-01-27  Filip Pizlo  <fpizlo@apple.com>

        scanExternalRememberedSet needs to mergeIfNecessary
        https://bugs.webkit.org/show_bug.cgi?id=167523

        Reviewed by Keith Miller.
        
        The protocol for opaque roots is that if you add to them outside of draining, then you need to call
        mergeIfNecessary.
        
        This means that every MarkingConstraint that adds opaque roots needs to mergeIfNecessary after.
        
        scanExternalRememberedSet transitively calls addOpaqueRoot, is called from a MarkingConstraint, and
        was missing a call to mergeIfNecessary. This fixes it.

        * API/JSVirtualMachine.mm:
        (scanExternalRememberedSet):

2017-01-27  Carlos Garcia Campos  <cgarcia@igalia.com>

        Unreviewed. Fix GTK+ debug build after r211247.

        * heap/GCAssertions.h:

2017-01-26  Keith Miller  <keith_miller@apple.com>

        classInfo should take a VM so it is not materialized from the object on each call
        https://bugs.webkit.org/show_bug.cgi?id=167424

        Rubber Stamped by Michael Saboff.

        Previously, classInfo() would get the VM from the target's
        MarkedBlock.  Most callers already have a VM on hand, so it is
        wasteful to compute the VM from the marked block every time. This
        patch refactors some of the most common callers of classInfo(),
        jsDynamicCast and inherits to take a VM as well.

        * API/JSCallbackConstructor.cpp:
        (JSC::JSCallbackConstructor::finishCreation):
        * API/JSCallbackFunction.cpp:
        (JSC::JSCallbackFunction::finishCreation):
        * API/JSCallbackObjectFunctions.h:
        (JSC::JSCallbackObject<Parent>::asCallbackObject):
        (JSC::JSCallbackObject<Parent>::finishCreation):
        * API/JSObjectRef.cpp:
        (JSObjectSetPrototype):
        (classInfoPrivate):
        (JSObjectGetPrivate):
        (JSObjectSetPrivate):
        (JSObjectGetPrivateProperty):
        (JSObjectSetPrivateProperty):
        (JSObjectDeletePrivateProperty):
        * API/JSTypedArray.cpp:
        (JSValueGetTypedArrayType):
        (JSObjectMakeTypedArrayWithArrayBuffer):
        (JSObjectMakeTypedArrayWithArrayBufferAndOffset):
        (JSObjectGetTypedArrayBytesPtr):
        (JSObjectGetTypedArrayLength):
        (JSObjectGetTypedArrayByteLength):
        (JSObjectGetTypedArrayByteOffset):
        (JSObjectGetTypedArrayBuffer):
        (JSObjectGetArrayBufferBytesPtr):
        (JSObjectGetArrayBufferByteLength):
        * API/JSValue.mm:
        (isDate):
        (isArray):
        (valueToObjectWithoutCopy):
        * API/JSValueRef.cpp:
        (JSValueIsArray):
        (JSValueIsDate):
        (JSValueIsObjectOfClass):
        * API/JSWeakObjectMapRefPrivate.cpp:
        * API/JSWrapperMap.mm:
        (tryUnwrapObjcObject):
        * API/ObjCCallbackFunction.h:
        * API/ObjCCallbackFunction.mm:
        (tryUnwrapConstructor):
        * bindings/ScriptFunctionCall.cpp:
        (Deprecated::ScriptFunctionCall::call):
        * bytecode/CallVariant.h:
        (JSC::CallVariant::internalFunction):
        (JSC::CallVariant::function):
        (JSC::CallVariant::isClosureCall):
        (JSC::CallVariant::executable):
        (JSC::CallVariant::functionExecutable):
        (JSC::CallVariant::nativeExecutable):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::setConstantRegisters):
        (JSC::CodeBlock::replacement):
        (JSC::CodeBlock::computeCapabilityLevel):
        (JSC::CodeBlock::nameForRegister):
        * bytecode/ObjectAllocationProfile.h:
        (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount):
        * bytecode/ObjectPropertyCondition.cpp:
        (JSC::ObjectPropertyCondition::attemptToMakeEquivalenceWithoutBarrier):
        * bytecode/ObjectPropertyCondition.h:
        (JSC::ObjectPropertyCondition::isValidValueForPresence):
        * bytecode/PropertyCondition.cpp:
        (JSC::PropertyCondition::isValidValueForAttributes):
        (JSC::PropertyCondition::isValidValueForPresence):
        (JSC::PropertyCondition::attemptToMakeEquivalenceWithoutBarrier):
        * bytecode/PropertyCondition.h:
        * bytecode/SpeculatedType.cpp:
        (JSC::speculationFromCell):
        * debugger/Debugger.cpp:
        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::functionName):
        (JSC::DebuggerCallFrame::scope):
        (JSC::DebuggerCallFrame::type):
        * debugger/DebuggerScope.cpp:
        (JSC::DebuggerScope::name):
        (JSC::DebuggerScope::location):
        * dfg/DFGAbstractInterpreter.h:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::AbstractInterpreter):
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::get):
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        (JSC::DFG::ByteCodeParser::planLoad):
        (JSC::DFG::ByteCodeParser::checkPresenceLike):
        (JSC::DFG::ByteCodeParser::load):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGDesiredWeakReferences.cpp:
        (JSC::DFG::DesiredWeakReferences::reallyAdd):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupMakeRope):
        * dfg/DFGFrozenValue.h:
        (JSC::DFG::FrozenValue::FrozenValue):
        (JSC::DFG::FrozenValue::dynamicCast):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        (JSC::DFG::Graph::tryGetConstantClosureVar):
        (JSC::DFG::Graph::tryGetFoldableView):
        (JSC::DFG::Graph::getRegExpPrototypeProperty):
        (JSC::DFG::Graph::isStringPrototypeMethodSane):
        (JSC::DFG::Graph::canOptimizeStringObjectAccess):
        * dfg/DFGLazyJSValue.cpp:
        (JSC::DFG::LazyJSValue::tryGetStringImpl):
        (JSC::DFG::LazyJSValue::tryGetString):
        * dfg/DFGLazyJSValue.h:
        * dfg/DFGNode.cpp:
        (JSC::DFG::Node::convertToPutStructureHint):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::dynamicCastConstant):
        (JSC::DFG::Node::castConstant):
        * dfg/DFGOperations.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileIn):
        (JSC::DFG::SpeculativeJIT::compileMaterializeNewObject):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileDirectCallOrConstruct):
        (JSC::FTL::DFG::LowerDFGToB3::compileIn):
        (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation):
        (JSC::FTL::DFG::LowerDFGToB3::compileStringReplace):
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationMaterializeObjectInOSR):
        * heap/CodeBlockSet.cpp:
        (JSC::CodeBlockSet::lastChanceToFinalize):
        (JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
        * heap/CodeBlockSet.h:
        * heap/GCAssertions.h:
        * heap/Heap.cpp:
        (JSC::Heap::lastChanceToFinalize):
        (JSC::Heap::protectedObjectTypeCounts):
        (JSC::Heap::objectTypeCounts):
        (JSC::Heap::deleteUnmarkedCompiledCode):
        * heap/HeapSnapshotBuilder.cpp:
        (JSC::HeapSnapshotBuilder::json):
        * heap/SlotVisitor.cpp:
        (JSC::validate):
        * inspector/InjectedScriptHost.h:
        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::reportAPIException):
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::finishCreation):
        (Inspector::JSInjectedScriptHost::isHTMLAllCollection):
        (Inspector::JSInjectedScriptHost::subtype):
        (Inspector::JSInjectedScriptHost::functionDetails):
        (Inspector::JSInjectedScriptHost::getInternalProperties):
        (Inspector::JSInjectedScriptHost::proxyTargetValue):
        (Inspector::JSInjectedScriptHost::weakMapSize):
        (Inspector::JSInjectedScriptHost::weakMapEntries):
        (Inspector::JSInjectedScriptHost::weakSetSize):
        (Inspector::JSInjectedScriptHost::weakSetEntries):
        (Inspector::JSInjectedScriptHost::iteratorEntries):
        * inspector/JSInjectedScriptHostPrototype.cpp:
        (Inspector::JSInjectedScriptHostPrototype::finishCreation):
        (Inspector::jsInjectedScriptHostPrototypeAttributeEvaluate):
        (Inspector::jsInjectedScriptHostPrototypeFunctionInternalConstructorName):
        (Inspector::jsInjectedScriptHostPrototypeFunctionIsHTMLAllCollection):
        (Inspector::jsInjectedScriptHostPrototypeFunctionProxyTargetValue):
        (Inspector::jsInjectedScriptHostPrototypeFunctionWeakMapSize):
        (Inspector::jsInjectedScriptHostPrototypeFunctionWeakMapEntries):
        (Inspector::jsInjectedScriptHostPrototypeFunctionWeakSetSize):
        (Inspector::jsInjectedScriptHostPrototypeFunctionWeakSetEntries):
        (Inspector::jsInjectedScriptHostPrototypeFunctionIteratorEntries):
        (Inspector::jsInjectedScriptHostPrototypeFunctionEvaluateWithScopeExtension):
        (Inspector::jsInjectedScriptHostPrototypeFunctionSubtype):
        (Inspector::jsInjectedScriptHostPrototypeFunctionFunctionDetails):
        (Inspector::jsInjectedScriptHostPrototypeFunctionGetInternalProperties):
        * inspector/JSJavaScriptCallFrame.cpp:
        (Inspector::JSJavaScriptCallFrame::finishCreation):
        (Inspector::toJSJavaScriptCallFrame): Deleted.
        * inspector/JSJavaScriptCallFrame.h:
        * inspector/JSJavaScriptCallFramePrototype.cpp:
        (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
        (Inspector::jsJavaScriptCallFramePrototypeFunctionEvaluateWithScopeExtension):
        (Inspector::jsJavaScriptCallFramePrototypeFunctionScopeDescriptions):
        (Inspector::jsJavaScriptCallFrameAttributeCaller):
        (Inspector::jsJavaScriptCallFrameAttributeSourceID):
        (Inspector::jsJavaScriptCallFrameAttributeLine):
        (Inspector::jsJavaScriptCallFrameAttributeColumn):
        (Inspector::jsJavaScriptCallFrameAttributeFunctionName):
        (Inspector::jsJavaScriptCallFrameAttributeScopeChain):
        (Inspector::jsJavaScriptCallFrameAttributeThisObject):
        (Inspector::jsJavaScriptCallFrameAttributeType):
        (Inspector::jsJavaScriptCallFrameIsTailDeleted):
        * inspector/ScriptArguments.cpp:
        (Inspector::ScriptArguments::getFirstArgumentAsString):
        * inspector/agents/InspectorHeapAgent.cpp:
        (Inspector::InspectorHeapAgent::getPreview):
        * interpreter/Interpreter.cpp:
        (JSC::notifyDebuggerOfUnwinding):
        (JSC::Interpreter::unwind):
        (JSC::Interpreter::notifyDebuggerOfExceptionToBeThrown):
        (JSC::Interpreter::execute):
        * interpreter/ShadowChicken.cpp:
        (JSC::ShadowChicken::update):
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::readFrame):
        (JSC::StackVisitor::readNonInlinedFrame):
        (JSC::StackVisitor::Frame::calleeSaveRegisters):
        * jit/JITCode.cpp:
        (JSC::JITCode::execute):
        * jit/JITOperations.cpp:
        (JSC::operationNewFunctionCommon):
        * jit/Repatch.cpp:
        (JSC::tryCacheGetByID):
        * jsc.cpp:
        (WTF::CustomGetter::customGetter):
        (WTF::RuntimeArray::finishCreation):
        (WTF::RuntimeArray::lengthGetter):
        (WTF::DOMJITGetter::customGetter):
        (WTF::DOMJITGetterComplex::DOMJITNodeDOMJIT::slowCall):
        (WTF::DOMJITGetterComplex::functionEnableException):
        (WTF::DOMJITGetterComplex::customGetter):
        (WTF::DOMJITFunctionObject::safeFunction):
        (functionDescribeArray):
        (functionCreateElement):
        (functionGetElement):
        (functionSetElementRoot):
        (functionGetHiddenValue):
        (functionSetHiddenValue):
        (functionSetImpureGetterDelegate):
        (functionNoFTL):
        (functionDollarEvalScript):
        (functionDollarAgentBroadcast):
        (functionTransferArrayBuffer):
        (functionFindTypeForExpression):
        (functionReturnTypeFor):
        (functionHasBasicBlockExecuted):
        (functionBasicBlockExecutionCount):
        (functionEnsureArrayStorage):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/AbstractModuleRecord.cpp:
        (JSC::AbstractModuleRecord::finishCreation):
        * runtime/ArrayBuffer.cpp:
        (JSC::ArrayBuffer::transferTo):
        * runtime/ArrayBuffer.h:
        * runtime/ArrayConstructor.cpp:
        (JSC::ArrayConstructor::finishCreation):
        (JSC::arrayConstructorPrivateFuncIsArraySlow):
        (JSC::arrayConstructorPrivateFuncIsArrayConstructor):
        * runtime/ArrayConstructor.h:
        (JSC::isArrayConstructor): Deleted.
        * runtime/ArrayIteratorPrototype.cpp:
        (JSC::ArrayIteratorPrototype::finishCreation):
        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation):
        * runtime/AsyncFunctionPrototype.cpp:
        (JSC::AsyncFunctionPrototype::finishCreation):
        * runtime/AtomicsObject.cpp:
        (JSC::AtomicsObject::finishCreation):
        (JSC::atomicsFuncWait):
        (JSC::atomicsFuncWake):
        * runtime/BooleanObject.cpp:
        (JSC::BooleanObject::finishCreation):
        * runtime/BooleanObject.h:
        (JSC::asBooleanObject):
        * runtime/BooleanPrototype.cpp:
        (JSC::BooleanPrototype::finishCreation):
        (JSC::booleanProtoFuncToString):
        (JSC::booleanProtoFuncValueOf):
        * runtime/ConsoleObject.cpp:
        (JSC::ConsoleObject::finishCreation):
        * runtime/DateConstructor.cpp:
        (JSC::constructDate):
        * runtime/DateInstance.cpp:
        (JSC::DateInstance::finishCreation):
        * runtime/DateInstance.h:
        (JSC::asDateInstance):
        * runtime/DatePrototype.cpp:
        (JSC::formateDateInstance):
        (JSC::DatePrototype::finishCreation):
        (JSC::dateProtoFuncToISOString):
        (JSC::dateProtoFuncToLocaleString):
        (JSC::dateProtoFuncToLocaleDateString):
        (JSC::dateProtoFuncToLocaleTimeString):
        (JSC::dateProtoFuncGetTime):
        (JSC::dateProtoFuncGetFullYear):
        (JSC::dateProtoFuncGetUTCFullYear):
        (JSC::dateProtoFuncGetMonth):
        (JSC::dateProtoFuncGetUTCMonth):
        (JSC::dateProtoFuncGetDate):
        (JSC::dateProtoFuncGetUTCDate):
        (JSC::dateProtoFuncGetDay):
        (JSC::dateProtoFuncGetUTCDay):
        (JSC::dateProtoFuncGetHours):
        (JSC::dateProtoFuncGetUTCHours):
        (JSC::dateProtoFuncGetMinutes):
        (JSC::dateProtoFuncGetUTCMinutes):
        (JSC::dateProtoFuncGetSeconds):
        (JSC::dateProtoFuncGetUTCSeconds):
        (JSC::dateProtoFuncGetMilliSeconds):
        (JSC::dateProtoFuncGetUTCMilliseconds):
        (JSC::dateProtoFuncGetTimezoneOffset):
        (JSC::dateProtoFuncSetTime):
        (JSC::setNewValueFromTimeArgs):
        (JSC::setNewValueFromDateArgs):
        (JSC::dateProtoFuncSetYear):
        (JSC::dateProtoFuncGetYear):
        * runtime/ErrorInstance.cpp:
        (JSC::ErrorInstance::finishCreation):
        * runtime/ErrorPrototype.cpp:
        (JSC::ErrorPrototype::finishCreation):
        * runtime/ExceptionHelpers.cpp:
        (JSC::isTerminatedExecutionException):
        * runtime/ExceptionHelpers.h:
        * runtime/ExecutableBase.cpp:
        (JSC::ExecutableBase::clearCode):
        (JSC::ExecutableBase::dump):
        (JSC::ExecutableBase::hashFor):
        * runtime/FunctionPrototype.cpp:
        (JSC::functionProtoFuncToString):
        * runtime/GeneratorFunctionPrototype.cpp:
        (JSC::GeneratorFunctionPrototype::finishCreation):
        * runtime/GeneratorPrototype.cpp:
        (JSC::GeneratorPrototype::finishCreation):
        * runtime/GetterSetter.h:
        * runtime/InspectorInstrumentationObject.cpp:
        (JSC::InspectorInstrumentationObject::finishCreation):
        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::finishCreation):
        (JSC::InternalFunction::createSubclassStructure):
        * runtime/InternalFunction.h:
        (JSC::asInternalFunction):
        * runtime/IntlCollator.cpp:
        (JSC::IntlCollator::finishCreation):
        * runtime/IntlCollatorPrototype.cpp:
        (JSC::IntlCollatorPrototypeGetterCompare):
        (JSC::IntlCollatorPrototypeFuncResolvedOptions):
        * runtime/IntlDateTimeFormat.cpp:
        (JSC::IntlDateTimeFormat::finishCreation):
        * runtime/IntlDateTimeFormatPrototype.cpp:
        (JSC::IntlDateTimeFormatPrototypeGetterFormat):
        (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
        * runtime/IntlNumberFormat.cpp:
        (JSC::IntlNumberFormat::finishCreation):
        * runtime/IntlNumberFormatPrototype.cpp:
        (JSC::IntlNumberFormatPrototypeGetterFormat):
        (JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
        * runtime/IntlObject.cpp:
        (JSC::IntlObject::finishCreation):
        * runtime/IntlObjectInlines.h:
        (JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor):
        * runtime/IteratorPrototype.cpp:
        (JSC::IteratorPrototype::finishCreation):
        * runtime/JSArray.h:
        (JSC::asArray):
        (JSC::isJSArray):
        * runtime/JSArrayBuffer.h:
        (JSC::toPossiblySharedArrayBuffer):
        (JSC::toUnsharedArrayBuffer):
        (JSC::JSArrayBuffer::toWrapped):
        * runtime/JSArrayBufferConstructor.cpp:
        (JSC::arrayBufferFuncIsView):
        * runtime/JSArrayBufferPrototype.cpp:
        (JSC::arrayBufferProtoFuncSlice):
        * runtime/JSArrayBufferView.h:
        * runtime/JSArrayBufferViewInlines.h:
        (JSC::JSArrayBufferView::toWrapped):
        * runtime/JSBoundFunction.cpp:
        (JSC::isBoundFunction):
        (JSC::getBoundFunctionStructure):
        (JSC::JSBoundFunction::finishCreation):
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::dumpForBacktrace):
        * runtime/JSCJSValue.h:
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::inherits):
        (JSC::JSValue::classInfoOrNull):
        * runtime/JSCallee.cpp:
        (JSC::JSCallee::finishCreation):
        * runtime/JSCell.cpp:
        (JSC::JSCell::dumpToStream):
        (JSC::JSCell::className):
        (JSC::JSCell::isAnyWasmCallee):
        * runtime/JSCell.h:
        (JSC::jsCast):
        (JSC::jsDynamicCast):
        * runtime/JSCellInlines.h:
        (JSC::JSCell::methodTable):
        (JSC::JSCell::inherits):
        (JSC::JSCell::classInfo):
        * runtime/JSCustomGetterSetterFunction.cpp:
        (JSC::JSCustomGetterSetterFunction::finishCreation):
        * runtime/JSDataViewPrototype.cpp:
        (JSC::getData):
        (JSC::setData):
        (JSC::dataViewProtoGetterBuffer):
        (JSC::dataViewProtoGetterByteLength):
        (JSC::dataViewProtoGetterByteOffset):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::finishCreation):
        (JSC::JSFunction::allocateAndInitializeRareData):
        (JSC::JSFunction::initializeRareData):
        (JSC::RetrieveArgumentsFunctor::RetrieveArgumentsFunctor):
        (JSC::RetrieveCallerFunctionFunctor::RetrieveCallerFunctionFunctor):
        (JSC::RetrieveCallerFunctionFunctor::operator()):
        (JSC::JSFunction::callerGetter):
        (JSC::JSFunction::getOwnNonIndexPropertyNames):
        (JSC::getCalculatedDisplayName):
        (JSC::JSFunction::reifyBoundNameIfNeeded):
        * runtime/JSGenericTypedArrayView.h:
        (JSC::toPossiblySharedNativeTypedView):
        (JSC::toUnsharedNativeTypedView):
        (JSC::JSGenericTypedArrayView<Adaptor>::toWrapped):
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::constructGenericTypedArrayViewWithArguments):
        (JSC::constructGenericTypedArrayView):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::set):
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::speciesConstruct):
        (JSC::genericTypedArrayViewProtoFuncSet):
        (JSC::genericTypedArrayViewProtoFuncSlice):
        (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
        * runtime/JSGenericTypedArrayViewPrototypeInlines.h:
        (JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
        * runtime/JSGlobalObject.cpp:
        (JSC::getTemplateObject):
        (JSC::enqueueJob):
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncProtoGetter):
        (JSC::globalFuncProtoSetter):
        * runtime/JSInternalPromiseDeferred.cpp:
        (JSC::JSInternalPromiseDeferred::create):
        * runtime/JSLexicalEnvironment.h:
        (JSC::asActivation):
        * runtime/JSModuleLoader.cpp:
        (JSC::JSModuleLoader::finishCreation):
        (JSC::JSModuleLoader::evaluate):
        (JSC::JSModuleLoader::getModuleNamespaceObject):
        * runtime/JSModuleNamespaceObject.cpp:
        (JSC::JSModuleNamespaceObject::finishCreation):
        (JSC::moduleNamespaceObjectSymbolIterator):
        * runtime/JSModuleRecord.cpp:
        (JSC::JSModuleRecord::finishCreation):
        * runtime/JSNativeStdFunction.cpp:
        (JSC::JSNativeStdFunction::finishCreation):
        * runtime/JSONObject.cpp:
        (JSC::JSONObject::finishCreation):
        (JSC::unwrapBoxedPrimitive):
        (JSC::Stringifier::Stringifier):
        (JSC::Walker::walk):
        * runtime/JSObject.cpp:
        (JSC::JSObject::className):
        (JSC::JSObject::toStringName):
        (JSC::JSObject::calculatedClassName):
        (JSC::JSObject::putInlineSlow):
        (JSC::JSObject::ensureInt32Slow):
        (JSC::JSObject::ensureDoubleSlow):
        (JSC::JSObject::ensureContiguousSlow):
        (JSC::JSObject::ensureArrayStorageSlow):
        (JSC::JSObject::deleteProperty):
        (JSC::JSObject::getOwnStaticPropertySlot):
        (JSC::JSObject::findPropertyHashEntry):
        (JSC::JSObject::getOwnNonIndexPropertyNames):
        (JSC::JSObject::reifyAllStaticProperties):
        (JSC::JSObject::getOwnPropertyDescriptor):
        * runtime/JSObject.h:
        (JSC::JSObject::finishCreation):
        (JSC::JSNonFinalObject::finishCreation):
        (JSC::JSFinalObject::finishCreation):
        * runtime/JSPromiseDeferred.cpp:
        (JSC::JSPromiseDeferred::create):
        * runtime/JSPropertyNameIterator.cpp:
        (JSC::JSPropertyNameIterator::finishCreation):
        (JSC::propertyNameIteratorFuncNext):
        * runtime/JSScope.cpp:
        (JSC::JSScope::symbolTable):
        * runtime/JSScope.h:
        * runtime/JSString.cpp:
        (JSC::JSString::dumpToStream):
        * runtime/JSStringIterator.cpp:
        (JSC::JSStringIterator::finishCreation):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::typedArrayViewPrivateFuncIsTypedArrayView):
        (JSC::typedArrayViewPrivateFuncLength):
        (JSC::typedArrayViewPrivateFuncGetOriginalConstructor):
        (JSC::typedArrayViewProtoGetterFuncToStringTag):
        (JSC::JSTypedArrayViewPrototype::finishCreation):
        * runtime/LazyClassStructure.cpp:
        (JSC::LazyClassStructure::Initializer::setConstructor):
        * runtime/Lookup.h:
        (JSC::putEntry):
        * runtime/MapConstructor.cpp:
        (JSC::MapConstructor::finishCreation):
        * runtime/MapIteratorPrototype.cpp:
        (JSC::MapIteratorPrototype::finishCreation):
        (JSC::MapIteratorPrototypeFuncNext):
        * runtime/MapPrototype.cpp:
        (JSC::MapPrototype::finishCreation):
        (JSC::mapProtoFuncValues):
        (JSC::mapProtoFuncEntries):
        (JSC::mapProtoFuncKeys):
        (JSC::privateFuncMapIterator):
        (JSC::privateFuncMapIteratorNext):
        * runtime/MathObject.cpp:
        (JSC::MathObject::finishCreation):
        * runtime/ModuleLoaderPrototype.cpp:
        (JSC::moduleLoaderPrototypeParseModule):
        (JSC::moduleLoaderPrototypeRequestedModules):
        (JSC::moduleLoaderPrototypeModuleDeclarationInstantiation):
        (JSC::moduleLoaderPrototypeResolve):
        (JSC::moduleLoaderPrototypeFetch):
        (JSC::moduleLoaderPrototypeInstantiate):
        (JSC::moduleLoaderPrototypeGetModuleNamespaceObject):
        (JSC::moduleLoaderPrototypeEvaluate):
        * runtime/NativeErrorConstructor.cpp:
        (JSC::NativeErrorConstructor::finishCreation):
        * runtime/NumberConstructor.cpp:
        (JSC::NumberConstructor::finishCreation):
        * runtime/NumberObject.cpp:
        (JSC::NumberObject::finishCreation):
        * runtime/NumberPrototype.cpp:
        (JSC::NumberPrototype::finishCreation):
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructor::finishCreation):
        * runtime/ObjectPrototype.cpp:
        (JSC::ObjectPrototype::finishCreation):
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::toStringName):
        (JSC::ProxyObject::finishCreation):
        * runtime/ReflectObject.cpp:
        (JSC::ReflectObject::finishCreation):
        (JSC::reflectObjectConstruct):
        * runtime/RegExpConstructor.cpp:
        (JSC::RegExpConstructor::finishCreation):
        (JSC::setRegExpConstructorInput):
        (JSC::setRegExpConstructorMultiline):
        (JSC::constructRegExp):
        * runtime/RegExpConstructor.h:
        (JSC::asRegExpConstructor):
        (JSC::isRegExp):
        * runtime/RegExpObject.cpp:
        (JSC::RegExpObject::finishCreation):
        * runtime/RegExpObject.h:
        (JSC::asRegExpObject):
        * runtime/RegExpPrototype.cpp:
        (JSC::RegExpPrototype::finishCreation):
        (JSC::regExpProtoFuncTestFast):
        (JSC::regExpProtoFuncExec):
        (JSC::regExpProtoFuncMatchFast):
        (JSC::regExpProtoFuncCompile):
        (JSC::regExpProtoGetterGlobal):
        (JSC::regExpProtoGetterIgnoreCase):
        (JSC::regExpProtoGetterMultiline):
        (JSC::regExpProtoGetterSticky):
        (JSC::regExpProtoGetterUnicode):
        (JSC::regExpProtoGetterSource):
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::processUnverifiedStackTraces):
        * runtime/ScriptExecutable.cpp:
        (JSC::ScriptExecutable::newCodeBlockFor):
        (JSC::ScriptExecutable::newReplacementCodeBlockFor):
        * runtime/SetConstructor.cpp:
        (JSC::SetConstructor::finishCreation):
        * runtime/SetIteratorPrototype.cpp:
        (JSC::SetIteratorPrototype::finishCreation):
        (JSC::SetIteratorPrototypeFuncNext):
        * runtime/SetPrototype.cpp:
        (JSC::SetPrototype::finishCreation):
        (JSC::setProtoFuncValues):
        (JSC::setProtoFuncEntries):
        (JSC::privateFuncSetIterator):
        (JSC::privateFuncSetIteratorNext):
        * runtime/StackFrame.cpp:
        (JSC::StackFrame::sourceURL):
        (JSC::StackFrame::functionName):
        * runtime/StringIteratorPrototype.cpp:
        (JSC::StringIteratorPrototype::finishCreation):
        * runtime/StringObject.cpp:
        (JSC::StringObject::finishCreation):
        * runtime/StringObject.h:
        (JSC::asStringObject):
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        (JSC::replace):
        (JSC::stringProtoFuncReplaceUsingRegExp):
        (JSC::stringProtoFuncToString):
        * runtime/StructureRareData.cpp:
        (JSC::StructureRareData::setObjectToStringValue):
        * runtime/Symbol.cpp:
        (JSC::Symbol::finishCreation):
        * runtime/SymbolConstructor.cpp:
        (JSC::SymbolConstructor::finishCreation):
        * runtime/SymbolObject.cpp:
        (JSC::SymbolObject::finishCreation):
        * runtime/SymbolPrototype.cpp:
        (JSC::SymbolPrototype::finishCreation):
        (JSC::symbolProtoFuncToString):
        (JSC::symbolProtoFuncValueOf):
        * runtime/TestRunnerUtils.cpp:
        (JSC::getExecutableForFunction):
        * runtime/ThrowScope.cpp:
        (JSC::ThrowScope::throwException):
        * runtime/VM.cpp:
        (JSC::VM::throwException):
        * runtime/WeakMapConstructor.cpp:
        (JSC::WeakMapConstructor::finishCreation):
        * runtime/WeakMapPrototype.cpp:
        (JSC::WeakMapPrototype::finishCreation):
        (JSC::getWeakMapData):
        * runtime/WeakSetConstructor.cpp:
        (JSC::WeakSetConstructor::finishCreation):
        * runtime/WeakSetPrototype.cpp:
        (JSC::WeakSetPrototype::finishCreation):
        (JSC::getWeakMapData):
        * tools/JSDollarVMPrototype.cpp:
        (JSC::codeBlockFromArg):
        * wasm/JSWebAssembly.cpp:
        (JSC::JSWebAssembly::finishCreation):
        * wasm/js/JSWebAssemblyHelpers.h:
        (JSC::getWasmBufferFromValue):
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::finishCreation):
        * wasm/js/JSWebAssemblyMemory.cpp:
        (JSC::JSWebAssemblyMemory::grow):
        (JSC::JSWebAssemblyMemory::finishCreation):
        (JSC::JSWebAssemblyMemory::destroy):
        (JSC::JSWebAssemblyMemory::~JSWebAssemblyMemory): Deleted.
        * wasm/js/JSWebAssemblyMemory.h:
        * wasm/js/JSWebAssemblyModule.cpp:
        (JSC::JSWebAssemblyModule::finishCreation):
        * wasm/js/JSWebAssemblyTable.cpp:
        (JSC::JSWebAssemblyTable::finishCreation):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction):
        (JSC::WebAssemblyFunction::finishCreation):
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::constructJSWebAssemblyInstance):
        * wasm/js/WebAssemblyMemoryPrototype.cpp:
        (JSC::getMemory):
        * wasm/js/WebAssemblyModulePrototype.cpp:
        (JSC::webAssemblyModuleProtoCustomSections):
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::finishCreation):
        * wasm/js/WebAssemblyTablePrototype.cpp:
        (JSC::getTable):
        (JSC::webAssemblyTableProtoFuncSet):

2017-01-26  Mark Lam  <mark.lam@apple.com>

        Fix missing exception check in genericTypedArrayViewProtoFuncSet().
        https://bugs.webkit.org/show_bug.cgi?id=166812
        <rdar://problem/29916672>

        Reviewed by Saam Barati.

        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewProtoFuncSet):

2017-01-26  Commit Queue  <commit-queue@webkit.org>

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

        "It was a Kraken performance regression" (Requested by
        saamyjoon on #webkit).

        Reverted changeset:

        "OSR entry: delay outer-loop compilation when at inner-loop"
        https://bugs.webkit.org/show_bug.cgi?id=167149
        http://trac.webkit.org/changeset/211224

2017-01-26  Saam Barati  <sbarati@apple.com>

        Harden how the compiler references GC objects
        https://bugs.webkit.org/show_bug.cgi?id=167277
        <rdar://problem/30179506>

        Reviewed by Filip Pizlo.

        Since r210971, the DFG/FTL will flash safepoints before
        each phase. This means that there are more opportunities for
        a GC to happen while the compiler is running. Because of this,
        the compiler must keep track of all the heap pointers that are part
        of the Graph data structure. To accomplish this, I've designed
        a new type called RegisteredStructure that can only be constructed
        after the Graph becomes aware of its underlying Structure*. I
        designed this new type to have the type system in C++ help us catch
        errors where we're not informing the graph/plan of a heap pointer.
        I've made it a compile error to create an OpInfo with a pointer
        T* where T inherits from HeapCell. This encourages an OpInfo
        to be created with either a FrozenValue* or a RegisteredStructure.
        I've added similar compile time assertions for TrustedImmPtr in DFG::SpeculativeJIT
        and FTL::Output::constIntPtr. These static asserts don't save us from all bad
        programs because there are ways to write code that's incorrect that compiles,
        but the new types do help us ensure that the most obvious way of writing the
        code is correct.
        
        The reason this patch is so big is that I've strung RegisteredStructure and
        RegisteredStructureSet through the entire DFG/FTL.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::determineLiveness):
        * bytecode/StructureSet.cpp:
        (JSC::StructureSet::filter): Deleted.
        (JSC::StructureSet::filterArrayModes): Deleted.
        (JSC::StructureSet::speculationFromStructures): Deleted.
        (JSC::StructureSet::arrayModesFromStructures): Deleted.
        (JSC::StructureSet::validateReferences): Deleted.
        * bytecode/StructureSet.h:
        * dfg/DFGAbstractInterpreter.h:
        (JSC::DFG::AbstractInterpreter::filter):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::booleanResult):
        (JSC::DFG::isToThisAnIdentity):
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::observeTransition):
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::filter):
        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::set):
        (JSC::DFG::AbstractValue::setType):
        (JSC::DFG::AbstractValue::mergeOSREntryValue):
        (JSC::DFG::AbstractValue::filter):
        (JSC::DFG::AbstractValue::changeStructure):
        (JSC::DFG::AbstractValue::contains):
        * dfg/DFGAbstractValue.h:
        (JSC::DFG::AbstractValue::observeTransition):
        (JSC::DFG::AbstractValue::TransitionObserver::TransitionObserver):
        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::alreadyChecked):
        * dfg/DFGArrayifySlowPathGenerator.h:
        (JSC::DFG::ArrayifySlowPathGenerator::ArrayifySlowPathGenerator):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        (JSC::DFG::ByteCodeParser::load):
        (JSC::DFG::ByteCodeParser::handleGetById):
        (JSC::DFG::ByteCodeParser::handlePutById):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
        (JSC::DFG::CallArrayAllocatorSlowPathGenerator::CallArrayAllocatorSlowPathGenerator):
        (JSC::DFG::CallArrayAllocatorWithVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableSizeSlowPathGenerator):
        * dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h:
        (JSC::DFG::CallCreateDirectArgumentsSlowPathGenerator::CallCreateDirectArgumentsSlowPathGenerator):
        * dfg/DFGCommonData.cpp:
        (JSC::DFG::CommonData::notifyCompilingStructureTransition):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        (JSC::DFG::ConstantFoldingPhase::emitGetByOffset):
        (JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
        (JSC::DFG::ConstantFoldingPhase::addBaseCheck):
        (JSC::DFG::ConstantFoldingPhase::addStructureTransitionCheck):
        * dfg/DFGDesiredWeakReferences.cpp:
        (JSC::DFG::DesiredWeakReferences::reallyAdd):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::checkArray):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::Graph):
        (JSC::DFG::Graph::dump):
        (JSC::DFG::Graph::tryGetConstantProperty):
        (JSC::DFG::Graph::inferredValueForProperty):
        (JSC::DFG::Graph::visitChildren):
        (JSC::DFG::Graph::freeze):
        (JSC::DFG::Graph::registerStructure):
        (JSC::DFG::Graph::assertIsRegistered):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::registerStructure):
        (JSC::DFG::Graph::addStructureSet):
        * dfg/DFGJITCompiler.h:
        (JSC::DFG::JITCompiler::branchWeakStructure):
        * dfg/DFGMultiGetByOffsetData.cpp:
        (JSC::DFG::MultiGetByOffsetCase::dumpInContext):
        * dfg/DFGMultiGetByOffsetData.h:
        (JSC::DFG::MultiGetByOffsetCase::MultiGetByOffsetCase):
        (JSC::DFG::MultiGetByOffsetCase::set):
        * dfg/DFGNode.cpp:
        (JSC::DFG::Node::convertToPutStructureHint):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToCheckStructure):
        (JSC::DFG::Node::structureSet):
        (JSC::DFG::Node::structure):
        (JSC::DFG::Node::OpInfoWrapper::OpInfoWrapper):
        (JSC::DFG::Node::OpInfoWrapper::operator=):
        (JSC::DFG::Node::OpInfoWrapper::asRegisteredStructure):
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        * dfg/DFGOpInfo.h:
        (JSC::DFG::OpInfo::OpInfo):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        (JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
        * dfg/DFGRegisteredStructure.h: Added.
        (JSC::DFG::RegisteredStructure::get):
        (JSC::DFG::RegisteredStructure::operator->):
        (JSC::DFG::RegisteredStructure::operator==):
        (JSC::DFG::RegisteredStructure::operator!=):
        (JSC::DFG::RegisteredStructure::operator bool):
        (JSC::DFG::RegisteredStructure::RegisteredStructure):
        (JSC::DFG::RegisteredStructure::createPrivate):
        * dfg/DFGRegisteredStructureSet.cpp: Added.
        (JSC::DFG::RegisteredStructureSet::filter):
        (JSC::DFG::RegisteredStructureSet::filterArrayModes):
        (JSC::DFG::RegisteredStructureSet::speculationFromStructures):
        (JSC::DFG::RegisteredStructureSet::arrayModesFromStructures):
        (JSC::DFG::RegisteredStructureSet::validateReferences):
        * dfg/DFGRegisteredStructureSet.h: Added.
        (JSC::DFG::RegisteredStructureSet::RegisteredStructureSet):
        (JSC::DFG::RegisteredStructureSet::onlyStructure):
        (JSC::DFG::RegisteredStructureSet::toStructureSet):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
        (JSC::DFG::SpeculativeJIT::emitGetCallee):
        (JSC::DFG::SpeculativeJIT::silentFill):
        (JSC::DFG::SpeculativeJIT::checkArray):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
        (JSC::DFG::SpeculativeJIT::compileFromCharCode):
        (JSC::DFG::SpeculativeJIT::compileDoubleRep):
        (JSC::DFG::compileClampDoubleToByte):
        (JSC::DFG::SpeculativeJIT::compileMakeRope):
        (JSC::DFG::SpeculativeJIT::compileArithRounding):
        (JSC::DFG::SpeculativeJIT::compileNewFunctionCommon):
        (JSC::DFG::SpeculativeJIT::compileNewFunction):
        (JSC::DFG::SpeculativeJIT::compileCreateActivation):
        (JSC::DFG::SpeculativeJIT::compileCreateDirectArguments):
        (JSC::DFG::SpeculativeJIT::compileCreateScopedArguments):
        (JSC::DFG::SpeculativeJIT::compileCreateClonedArguments):
        (JSC::DFG::SpeculativeJIT::compileSpread):
        (JSC::DFG::SpeculativeJIT::compileArraySlice):
        (JSC::DFG::SpeculativeJIT::compileTypeOf):
        (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
        (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
        (JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOnCell):
        (JSC::DFG::SpeculativeJIT::compileNewTypedArray):
        (JSC::DFG::SpeculativeJIT::speculateStringOrStringObject):
        (JSC::DFG::SpeculativeJIT::compileMaterializeNewObject):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::TrustedImmPtr::TrustedImmPtr):
        (JSC::DFG::SpeculativeJIT::TrustedImmPtr::weakPointer):
        (JSC::DFG::SpeculativeJIT::TrustedImmPtr::operator MacroAssembler::TrustedImmPtr):
        (JSC::DFG::SpeculativeJIT::TrustedImmPtr::asIntptr):
        (JSC::DFG::SpeculativeJIT::callOperation):
        (JSC::DFG::SpeculativeJIT::emitAllocateDestructibleObject):
        (JSC::DFG::SpeculativeJIT::speculateStringObjectForStructure):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNullOrUndefined):
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
        (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
        (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNullOrUndefined):
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
        (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        * dfg/DFGStructureAbstractValue.cpp:
        (JSC::DFG::StructureAbstractValue::assertIsRegistered):
        (JSC::DFG::StructureAbstractValue::clobber):
        (JSC::DFG::StructureAbstractValue::observeTransition):
        (JSC::DFG::StructureAbstractValue::observeTransitions):
        (JSC::DFG::StructureAbstractValue::add):
        (JSC::DFG::StructureAbstractValue::merge):
        (JSC::DFG::StructureAbstractValue::mergeNotTop):
        (JSC::DFG::StructureAbstractValue::filter):
        (JSC::DFG::StructureAbstractValue::filterSlow):
        (JSC::DFG::StructureAbstractValue::filterClassInfoSlow):
        (JSC::DFG::StructureAbstractValue::contains):
        (JSC::DFG::StructureAbstractValue::isSubsetOf):
        (JSC::DFG::StructureAbstractValue::isSupersetOf):
        (JSC::DFG::StructureAbstractValue::overlaps):
        (JSC::DFG::StructureAbstractValue::isSubClassOf):
        (JSC::DFG::StructureAbstractValue::dumpInContext):
        * dfg/DFGStructureAbstractValue.h:
        (JSC::DFG::StructureAbstractValue::StructureAbstractValue):
        (JSC::DFG::StructureAbstractValue::operator=):
        (JSC::DFG::StructureAbstractValue::set):
        (JSC::DFG::StructureAbstractValue::toStructureSet):
        (JSC::DFG::StructureAbstractValue::at):
        (JSC::DFG::StructureAbstractValue::operator[]):
        (JSC::DFG::StructureAbstractValue::onlyStructure):
        * dfg/DFGStructureRegistrationPhase.cpp:
        (JSC::DFG::StructureRegistrationPhase::StructureRegistrationPhase): Deleted.
        (JSC::DFG::StructureRegistrationPhase::run): Deleted.
        (JSC::DFG::StructureRegistrationPhase::registerStructures): Deleted.
        (JSC::DFG::StructureRegistrationPhase::registerStructure): Deleted.
        (JSC::DFG::StructureRegistrationPhase::assertAreRegistered): Deleted.
        (JSC::DFG::StructureRegistrationPhase::assertIsRegistered): Deleted.
        (JSC::DFG::performStructureRegistration): Deleted.
        * dfg/DFGStructureRegistrationPhase.h:
        * dfg/DFGTransition.cpp:
        (JSC::DFG::Transition::dumpInContext):
        * dfg/DFGTransition.h:
        (JSC::DFG::Transition::Transition):
        * dfg/DFGTypeCheckHoistingPhase.cpp:
        (JSC::DFG::TypeCheckHoistingPhase::noticeStructureCheck):
        (JSC::DFG::TypeCheckHoistingPhase::noticeStructureCheckAccountingForArrayMode):
        * dfg/DFGValidate.cpp:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::lower):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor):
        (JSC::FTL::DFG::LowerDFGToB3::compileCheckStructure):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutStructure):
        (JSC::FTL::DFG::LowerDFGToB3::compileArraySlice):
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateActivation):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateDirectArguments):
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateRest):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArray):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayBuffer):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
        (JSC::FTL::DFG::LowerDFGToB3::compileAllocatePropertyStorage):
        (JSC::FTL::DFG::LowerDFGToB3::compileReallocatePropertyStorage):
        (JSC::FTL::DFG::LowerDFGToB3::compileMultiGetByOffset):
        (JSC::FTL::DFG::LowerDFGToB3::compileMultiPutByOffset):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucket):
        (JSC::FTL::DFG::LowerDFGToB3::compileOverridesHasInstance):
        (JSC::FTL::DFG::LowerDFGToB3::compileCheckStructureImmediate):
        (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
        (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp):
        (JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenTail):
        (JSC::FTL::DFG::LowerDFGToB3::checkStructure):
        (JSC::FTL::DFG::LowerDFGToB3::checkInferredType):
        (JSC::FTL::DFG::LowerDFGToB3::allocateObject):
        (JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedObject):
        (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
        (JSC::FTL::DFG::LowerDFGToB3::allocateUninitializedContiguousJSArray):
        (JSC::FTL::DFG::LowerDFGToB3::boolify):
        (JSC::FTL::DFG::LowerDFGToB3::equalNullOrUndefined):
        (JSC::FTL::DFG::LowerDFGToB3::lowCell):
        (JSC::FTL::DFG::LowerDFGToB3::speculateStringObjectForStructureID):
        (JSC::FTL::DFG::LowerDFGToB3::weakPointer):
        (JSC::FTL::DFG::LowerDFGToB3::frozenPointer):
        (JSC::FTL::DFG::LowerDFGToB3::weakStructureID):
        (JSC::FTL::DFG::LowerDFGToB3::weakStructure):
        (JSC::FTL::DFG::LowerDFGToB3::crash):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::weakPointer):
        (JSC::FTL::Output::constIntPtr):

2017-01-26  JF Bastien  <jfbastien@apple.com>

        OSR entry: delay outer-loop compilation when at inner-loop
        https://bugs.webkit.org/show_bug.cgi?id=167149

        Reviewed by Filip Pizlo.

        As of https://bugs.webkit.org/show_bug.cgi?id=155217 OSR
        compilation can be kicked off for an entry into an outer-loop,
        while executing an inner-loop. This is desirable because often the
        codegen from an inner-entry isn't as good as the codegen from an
        outer-entry, but execution from an inner-loop is often pretty hot
        and likely to kick off compilation. This approach provided nice
        speedups on Kraken because we'd select to enter to the outer-loop
        very reliably, which reduces variability (the inner-loop was
        selected roughly 1/5 times from my unscientific measurements).

        When compilation starts we take a snapshot of the JSValues at the
        current execution state using OSR's recovery mechanism. These
        values are passed to the compiler and are used as way to perform
        type profiling, and could be used to observe cell types as well as
        to perform predictions such as through constant propagation.

        It's therefore desired to enter from the outer-loop when we can,
        but we need to be executing from that location to capture the
        right JSValues, otherwise we're confusing the compiler and giving
        it inaccurate JSValues which can lead it to predict the wrong
        things, leading to suboptimal code or recompilation due to
        misprediction, or in super-corner-cases a crash.

        These effects are pretty hard to measure: Fil points out that
        marsalis-osr-entry really needs mustHandleValues (the JSValues
        from the point of execution) because right now it just happens to
        correctly guess int32. I tried removing mustHandleValues entirely
        and saw no slowdowns, but our benchmarks probably aren't
        sufficient to reliably find issues, sometimes because we happen to
        have sufficient mitigations.

        DFG tier-up was added here:
        https://bugs.webkit.org/show_bug.cgi?id=112838

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGJITCode.h:
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::JITCompiler):
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):
        * dfg/DFGOSREntry.h:
        (JSC::DFG::prepareOSREntry):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGTierUpEntryTrigger.h: Copied from Source/JavaScriptCore/ftl/FTLOSREntry.h.
        * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.cpp:
        (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::ToFTLForOSREntryDeferredCompilationCallback):
        (JSC::DFG::Ref<ToFTLForOSREntryDeferredCompilationCallback>ToFTLForOSREntryDeferredCompilationCallback::create):
        (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
        (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidComplete):
        * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.h:
        * ftl/FTLOSREntry.cpp:
        (JSC::FTL::prepareOSREntry):
        * ftl/FTLOSREntry.h:
        * jit/JITOperations.cpp:

2017-01-25  Saam Barati  <sbarati@apple.com>

        WebAssembly JS API: coerce return values from imports
        https://bugs.webkit.org/show_bug.cgi?id=165480
        <rdar://problem/29760318>

        Reviewed by Yusuke Suzuki.

        This patch does proper coercion for all possible
        JSValue return types from an imported function.
        
        It also adds the spec-compliant code to throw an exception
        when calling an import that has an i64 parameter or return
        value.

        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::emitJumpIfException):
        * jit/AssemblyHelpers.h:
        * wasm/WasmB3IRGenerator.cpp:
        * wasm/WasmBinding.cpp:
        (JSC::Wasm::wasmToJs):

2017-01-25  Filip Pizlo  <fpizlo@apple.com>

        jsc.cpp should have the $.agent stuff for testing SAB
        https://bugs.webkit.org/show_bug.cgi?id=167431

        Reviewed by Saam Barati.
        
        This adds some stuff that the SAB branch of test262 needs. None of this is exposed except for our
        own tests and the SAB branch of test262. We now pass all of the Atomics tests in the SAB branch
        of test262.
        
        * jsc.cpp:
        (Message::releaseContents):
        (Message::index):
        (GlobalObject::finishCreation):
        (GlobalObject::addFunction):
        (Message::Message):
        (Message::~Message):
        (Worker::Worker):
        (Worker::~Worker):
        (Worker::send):
        (Worker::receive):
        (Worker::current):
        (Worker::currentWorker):
        (Workers::Workers):
        (Workers::~Workers):
        (Workers::broadcast):
        (Workers::report):
        (Workers::tryGetReport):
        (Workers::getReport):
        (Workers::singleton):
        (functionDollarCreateRealm):
        (functionDollarDetachArrayBuffer):
        (functionDollarEvalScript):
        (functionDollarAgentStart):
        (functionDollarAgentReceiveBroadcast):
        (functionDollarAgentReport):
        (functionDollarAgentSleep):
        (functionDollarAgentBroadcast):
        (functionDollarAgentGetReport):
        (functionWaitForReport):
        (checkException):
        (runWithScripts):
        (runJSC):
        (jscmain):
        * runtime/JSArrayBuffer.h:

2017-01-25  Filip Pizlo  <fpizlo@apple.com>

        ARM/ARM64 stress/atomics-store-return.js fails
        <rdar://problem/30192652>

        Reviewed by Michael Saboff.
        
        The problem was relying on double->int casts for anything. We need to use toInt32().

        * runtime/AtomicsObject.cpp:
        (JSC::atomicsFuncCompareExchange):
        (JSC::atomicsFuncExchange):
        (JSC::atomicsFuncStore):

2017-01-25  Ryosuke Niwa  <rniwa@webkit.org>

        collectMatchingElementsInFlatTree should not find elements inside an user agent shadow tree
        https://bugs.webkit.org/show_bug.cgi?id=167409

        Reviewed by Antti Koivisto.

        Added matchingElementInFlatTree as a common identifier since it's required in the bindings code.

        * runtime/CommonIdentifiers.h:

2017-01-24  Joseph Pecoraro  <pecoraro@apple.com>

        Fold USER_TIMING into WEB_TIMING and make it a RuntimeEnabledFeature
        https://bugs.webkit.org/show_bug.cgi?id=167394

        Reviewed by Ryosuke Niwa.

        * Configurations/FeatureDefines.xcconfig:
        * runtime/CommonIdentifiers.h:

2017-01-24  Filip Pizlo  <fpizlo@apple.com>

        Atomics.store should return the int-converted value according to toInteger
        https://bugs.webkit.org/show_bug.cgi?id=167399

        Reviewed by Saam Barati.
        
        I keep getting this wrong, but I think I've finally done it right. What we want is for
        Atomics.store to return the value it was passed after toInteger, which doesn't clip the value to
        any kind of range. It does get truncated to double.
        
        This changes the code to pass those "integers" as doubles. It doesn't matter that this is slow,
        since all of these code paths are slow due to their need to check everything. We'll take care of
        that by making them intrinsic later.

        * runtime/AtomicsObject.cpp:
        (JSC::atomicsFuncAdd):
        (JSC::atomicsFuncAnd):
        (JSC::atomicsFuncCompareExchange):
        (JSC::atomicsFuncExchange):
        (JSC::atomicsFuncLoad):
        (JSC::atomicsFuncOr):
        (JSC::atomicsFuncStore):
        (JSC::atomicsFuncSub):
        (JSC::atomicsFuncXor):

2017-01-24  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Optimize Number#toString with Int52
        https://bugs.webkit.org/show_bug.cgi?id=167303

        Reviewed by Sam Weinig.

        In kraken crypto-sha256-iterative, we frequently call Number.prototype.toString with
        Int52. In that case, toString handles it in the generic double path. But we should
        have a fast path for this since it can be represented in int64_t.

        The stanford-crypto-sha256-iterative shows 1.6% performance improvement (on Linux machine hanayamata).

            Collected 100 samples per benchmark/VM, with 100 VM invocations per benchmark. Emitted a call to gc() between
            sample measurements. Used 1 benchmark iteration per VM invocation for warm-up. Used the jsc-specific preciseTime()
            function to get microsecond-level timing. Reporting benchmark execution times with 95% confidence intervals in
            milliseconds.

                                                       baseline                  patched

            stanford-crypto-sha256-iterative        32.853+-0.075      ^      32.325+-0.055         ^ definitely 1.0163x faster

        * runtime/JSCJSValue.h:
        * runtime/NumberPrototype.cpp:
        (JSC::int52ToStringWithRadix):
        (JSC::toStringWithRadix):

2017-01-24  Michael Saboff  <msaboff@apple.com>

        InferredTypeTable entry manipulation is not TOCTOU race safe
        https://bugs.webkit.org/show_bug.cgi?id=167344

        Reviewed by Filip Pizlo.

        Made the accesses to table values safe from Time of Check,
        Time of Use races with local temporary values.

        Fixed point that we set an entry in the table to access the
        current table entry instead of using the local entry.  In that case,
        we reload the now changed entry.

        * runtime/InferredTypeTable.cpp:
        (JSC::InferredTypeTable::visitChildren):
        (JSC::InferredTypeTable::get):
        (JSC::InferredTypeTable::willStoreValue):
        (JSC::InferredTypeTable::makeTop):

2017-01-24  Filip Pizlo  <fpizlo@apple.com>

        Atomics.store should return the int-converted value, not the value that it stored
        https://bugs.webkit.org/show_bug.cgi?id=167395

        Reviewed by Saam Barati.
        
        Previously the code was based around passing a lambda that operated over the native type of the
        operation (so for example int8_t if we were doing things to Int8Arrays). But to support this
        behavior of store, we need it to be able to control how it converts its result to JSValue and it
        needs to see its argument as an int32_t. It turns out that it's easy for all of the functions in
        AtomicsObject.cpp to also adopt this protocol since the conversion to JSValue is just jsNumber()
        from the native type in those cases, and the conversion from int32_t is done for free in
        std::atomic.

        * runtime/AtomicsObject.cpp:
        (JSC::atomicsFuncAdd):
        (JSC::atomicsFuncAnd):
        (JSC::atomicsFuncCompareExchange):
        (JSC::atomicsFuncExchange):
        (JSC::atomicsFuncLoad):
        (JSC::atomicsFuncOr):
        (JSC::atomicsFuncStore):
        (JSC::atomicsFuncSub):
        (JSC::atomicsFuncXor):

2017-01-24  Filip Pizlo  <fpizlo@apple.com>

        -0 is a valid array index and AtomicsObject should know this
        https://bugs.webkit.org/show_bug.cgi?id=167386

        Reviewed by Mark Lam.

        * runtime/AtomicsObject.cpp: The bug title really says it all.

2017-01-24  Commit Queue  <commit-queue@webkit.org>

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

        introduces a subtle bug in InferredTypeTable, huge
        Octane/deltablue regression (Requested by pizlo on #webkit).

        Reverted changeset:

        "InferredTypeTable entry manipulation is not TOCTOU race safe"
        https://bugs.webkit.org/show_bug.cgi?id=167344
        http://trac.webkit.org/changeset/211091

2017-01-24  Filip Pizlo  <fpizlo@apple.com>

        Enable the stochastic space-time scheduler on the larger multicores
        https://bugs.webkit.org/show_bug.cgi?id=167382
        <rdar://problem/30173375>

        Rubber stamped by Saam Barati
        
        This looks like a 1.3% JetStream speed-up thanks to a 28% splay-latency improvement. This new
        scheduler seems to prevent all of the same pathologies as the old one prevented. But instead of
        periodically suspending the mutator, this new one will only suspend after an iteration of the
        constraint fixpoint. The length of that suspension length is random with the distribution being
        governed by mutatorUtilization. Once resumed, the mutator gets to run unimpeded until draining
        stalls.
        
        I'm enabling it on platforms as I benchmark those platforms. It's possible that we will want to
        use a different scheduler on different platforms.

        * runtime/Options.cpp:
        (JSC::overrideDefaults):

2017-01-24  Michael Saboff  <msaboff@apple.com>

        JSArray::tryCreateUninitialized should be called JSArray::tryCreateForInitializationPrivate
        https://bugs.webkit.org/show_bug.cgi?id=167334

        Rubber-stamped by Filip Pizlo.

        * dfg/DFGOperations.cpp:
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationMaterializeObjectInOSR):
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncSplice):
        (JSC::arrayProtoPrivateFuncConcatMemcpy):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/JSArray.cpp:
        (JSC::JSArray::tryCreateForInitializationPrivate):
        (JSC::JSArray::fastSlice):
        (JSC::JSArray::tryCreateUninitialized): Deleted.
        * runtime/JSArray.h:
        (JSC::JSArray::tryCreateForInitializationPrivate):
        (JSC::constructArray):
        (JSC::constructArrayNegativeIndexed):
        (JSC::JSArray::tryCreateUninitialized): Deleted.
        * runtime/RegExpMatchesArray.cpp:
        (JSC::createEmptyRegExpMatchesArray):
        * runtime/RegExpMatchesArray.h:
        (JSC::createRegExpMatchesArray):

2017-01-23  Michael Saboff  <msaboff@apple.com>

        InferredTypeTable entry manipulation is not TOCTOU race safe
        https://bugs.webkit.org/show_bug.cgi?id=167344

        Reviewed by Filip Pizlo.

        Made the accesses to table values safe from Time of Check,
        Time of Use races with local temporary values.

        * runtime/InferredTypeTable.cpp:
        (JSC::InferredTypeTable::visitChildren):
        (JSC::InferredTypeTable::get):
        (JSC::InferredTypeTable::willStoreValue):
        (JSC::InferredTypeTable::makeTop):

2017-01-23  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Provide a way to trigger a Garbage Collection
        https://bugs.webkit.org/show_bug.cgi?id=167345
        <rdar://problem/30102853>

        Reviewed by Timothy Hatcher.

        * inspector/protocol/Console.json:
        * inspector/protocol/Debugger.json:
        * inspector/protocol/Heap.json:
        * inspector/protocol/Runtime.json:
        These domains are supported by Worker backends. Label them.

        * inspector/scripts/codegen/generate_js_backend_commands.py:
        (JSBackendCommandsGenerator.generate_domain):
        * inspector/scripts/codegen/models.py:
        (Protocol.parse_domain):
        (Domain.__init__):
        (Domains):
        Parse "workerSupported" and include a line in BackendCommands.js
        that calls to InspectorBackend.workerSupportedDomain().

        * inspector/scripts/tests/generic/domain-availability.json: Added.
        * inspector/scripts/tests/generic/expected/domain-availability.json-result: Added.
        * inspector/scripts/tests/generic/expected/worker-supported-domains.json-result: Added.
        * inspector/scripts/tests/generic/worker-supported-domains.json: Added.
        Tests for domain "workerSupported" and "availability" properties.

2017-01-23  Saam Barati  <sbarati@apple.com>

        https://bugs.webkit.org/show_bug.cgi?id=167247
        JSC: operationSpreadGeneric uses the wrong global object for the builtin function and slow_path_spread consults the wrong global object to prove if the iterator protocol is unobservable
        <rdar://problem/30121809>

        Reviewed by Filip Pizlo.

        There were two bugs in the different tiers with respect to how
        spread handled global objects.
        
        The first was in the LLInt/baseline inside slow_path_spread:
        
        We consulted the lexical global object instead of the thing we're
        spreading's global object to determine if the array iterator protocol
        is unobservable. This is wrong if the incoming array is from a different
        global object. We must consult the incoming array's global object
        to determine if it can be spread using the fast path.
        
        The second was in operationSpreadGeneric in the DFG/FTL:
        
        We were always using the incoming array's global object, even
        when going down the slow path. This is wrong because we were
        fetching the builtin iteration function helper from the incoming
        array's global object, which meant that if the iterator function
        were to throw an exception, it could leak objects from a different
        global object. We should be executing the iterator function with
        the lexical global object.

        * dfg/DFGOperations.cpp:
        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionGlobalObjectForObject):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/JSArray.h:
        * runtime/JSArrayInlines.h:
        (JSC::JSArray::isIteratorProtocolFastAndNonObservable):

2017-01-22  Filip Pizlo  <fpizlo@apple.com>

        Land the stochastic space-time scheduler disabled
        https://bugs.webkit.org/show_bug.cgi?id=167249

        Reviewed by Saam Barati.
        
        The space-time scheduler is pretty weird. It uses a periodic scheduler where the next period is
        simply determined by an integer multiple of time since when the scheduler last snapped phase. It
        snaps phase after constraint solving. Both the snapping of the phase after constraint solving and
        the periodicity appear to be necessary for good performance. For example, if the space-time
        scheduler decided that it was in the resume part of the phase just by virtue of having just
        resumed, then it would be empirically worse than our scheduler which asks "what time is it?" to
        decide whether it should be suspended or resumed even if it just suspended or resumed. I've spent
        a lot of time wondering why these two features are essential, and I think I found a reason.
        
        What's happening is that sometimes the GC has an overrun and its increment takes longer than it
        should have. The current scheduler forgives overruns when constraint solving, which seems to
        make sense because it cannot control whether constraint solving runs with the mutator resumed or
        suspended. It has to be suspended currently. Snapping phase after constraint solving accomplishes
        this. What's more surprising is how important it is to manage deadline misses during draining.
        The relevant kind of deadline miss is when doing mutator-suspended draining to catch up to the
        retreating wavefront. Deadline misses while doing this can happen systematically in some
        workloads, like JetStream/hash-map and some test in Speedometer. It's because they have some
        ginormous object and it takes like ~3ms+-1.5ms just to scan it. The space-time scheduler's use
        of time to decide what to do saves the day here: after the deadline miss, the scheduler will
        initially realize that it missed its deadline to resume the mutator. But as soon as it does this
        it asks: "based on current time since phase snap, what should I do?". In the case of a deadline
        miss, this question is essentially a weighted coin flip because of the high noise in the amount
        of time that it takes to do things in the GC. If you overrun, you will probably overrun by
        multiple milliseconds, which is enough that where you land in the space-time scheduler's timeline
        is random. The likelihood that you land in the "resume mutator" part of the timeline has a
        probability that is roughly the same as what the space-time scheduler calls mutator utilization.
        This is a super weird property. I did not intend for it to have this property, but it appears to
        be the most important property of this scheduler.
        
        Based on this, it seems that the fact that the space-time scheduler could suspend the mutator
        before draining runs out of work doesn't accomplish anything. As soon as you resume the
        mutator, you have a retreating wavefront to worry about. But if the collector is happily scanning
        things then it's almost certain that the collector will outpace the mutator. Also, anything that
        the mutator asks us to revisit is deferred anyway.
        
        In the past I've tried to replace the scheduler in one patch and this turned out to be annoying
        because even a poorly conceived scheduler should be iterated on. This patch lands a new scheduler
        called the StochasticSpaceTime scheduler. It replaces two of the known-good features of the old
        scheduler: (1) it forgives constraint pauses and (2) after deadline overrun its choice is random,
        weighted by the mutator utilization target. Unlike the old scheduler, this one will only suspend
        the mutator when the draining terminates, but it may pause for any amount of time after an
        iteration of constraint solving. It computes the targetPause by measuring constraint solving time
        and multiplying by the pauseScale (0.3 by default). If smaller then minimumPause (0.3ms by
        default), then it uses minimumPause instead. The stochastic scheduler will then definitely do at
        least targetPause worth of suspended draining after the constraint solving iteration, and then
        it will decide whether or not to do another one at random. The probability that it will choose to
        resume is exactly mutatorUtilization, which is computed exactly as before. Therefore, the
        probability of resumption starts at 0.7 and goes down as memory usage rises. Conversely, the
        probability that we will stay suspended starts at 0.3 and goes up from there.
        
        This new scheduler looks like it might be a 25% improvement on splay-latency. It also looks like
        a small progression on hash-map. Hash-map is a great test of one of the worst cases of retreating
        wavefront, since it is repeatedly storing to a ginormous array. This array is sure to take a
        while to scan, and to complete, the GC must be smart enough to visit any new objects it finds
        while scanning the array immediately after scanning that array. This new scheduler means that
        after scanning the array, the probability that you will scan whatever you found in it starts at
        0.3 and rises as the program allocates. It's sure to be 0.3, and not 0.3^k, because after the
        wavefront stops advancing, the only object on the mark stack after a constraint iteration will be
        that array. Since there is sure to be a 0.3ms or longer pause, the GC will be sure to start
        visiting this object. The GC can then complete if it just allows enough time after this to scan
        whatever new objects it finds. If scanning the array overruns the deadline (and it almost
        certainly will) then the probability that the GC keeps the mutator suspended is simply
        1 - mutatorUtilization.
        
        This scheduler is disabled by default. You can enable it with
        --useStochasticMutatorScheduler=true.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::markToFixpoint):
        * heap/Heap.h:
        * heap/MarkingConstraintSet.cpp:
        (JSC::MarkingConstraintSet::didStartMarking):
        (JSC::MarkingConstraintSet::executeConvergenceImpl):
        (JSC::MarkingConstraintSet::resetStats): Deleted.
        (JSC::MarkingConstraintSet::executeBootstrap): Deleted.
        * heap/MarkingConstraintSet.h:
        * heap/MutatorScheduler.cpp:
        (JSC::MutatorScheduler::didReachTermination):
        (JSC::MutatorScheduler::synchronousDrainingDidStall):
        * heap/MutatorScheduler.h:
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::didReachTermination):
        (JSC::SlotVisitor::drainFromShared):
        * heap/StochasticSpaceTimeMutatorScheduler.cpp: Added.
        (JSC::StochasticSpaceTimeMutatorScheduler::Snapshot::Snapshot):
        (JSC::StochasticSpaceTimeMutatorScheduler::Snapshot::now):
        (JSC::StochasticSpaceTimeMutatorScheduler::Snapshot::bytesAllocatedThisCycle):
        (JSC::StochasticSpaceTimeMutatorScheduler::StochasticSpaceTimeMutatorScheduler):
        (JSC::StochasticSpaceTimeMutatorScheduler::~StochasticSpaceTimeMutatorScheduler):
        (JSC::StochasticSpaceTimeMutatorScheduler::state):
        (JSC::StochasticSpaceTimeMutatorScheduler::beginCollection):
        (JSC::StochasticSpaceTimeMutatorScheduler::didStop):
        (JSC::StochasticSpaceTimeMutatorScheduler::willResume):
        (JSC::StochasticSpaceTimeMutatorScheduler::didReachTermination):
        (JSC::StochasticSpaceTimeMutatorScheduler::didExecuteConstraints):
        (JSC::StochasticSpaceTimeMutatorScheduler::synchronousDrainingDidStall):
        (JSC::StochasticSpaceTimeMutatorScheduler::timeToStop):
        (JSC::StochasticSpaceTimeMutatorScheduler::timeToResume):
        (JSC::StochasticSpaceTimeMutatorScheduler::log):
        (JSC::StochasticSpaceTimeMutatorScheduler::endCollection):
        (JSC::StochasticSpaceTimeMutatorScheduler::setResumeTime):
        (JSC::StochasticSpaceTimeMutatorScheduler::bytesAllocatedThisCycleImpl):
        (JSC::StochasticSpaceTimeMutatorScheduler::bytesSinceBeginningOfCycle):
        (JSC::StochasticSpaceTimeMutatorScheduler::maxHeadroom):
        (JSC::StochasticSpaceTimeMutatorScheduler::headroomFullness):
        (JSC::StochasticSpaceTimeMutatorScheduler::mutatorUtilization):
        * heap/StochasticSpaceTimeMutatorScheduler.h: Added.
        * runtime/Options.cpp:
        (JSC::overrideDefaults):
        * runtime/Options.h:

2017-01-23  Mark Lam  <mark.lam@apple.com>

        Added a comment to clarify an assertion.

        Rubber-stamped by Filip Pizlo.

        * runtime/JSCellInlines.h:
        (JSC::JSCell::classInfo):

2017-01-23  Filip Pizlo  <fpizlo@apple.com>

        SharedArrayBuffer plus WebGL should not equal CRASH
        https://bugs.webkit.org/show_bug.cgi?id=167329

        Reviewed by Saam Barati.
        
        DOM unwrapping methods should return null rather than crashing. The code expects an
        unshared buffer, so we should return null when it's shared. The caller can then decide
        if they like null or not.

        * runtime/JSArrayBufferViewInlines.h:
        (JSC::JSArrayBufferView::toWrapped):

2017-01-23  Mark Lam  <mark.lam@apple.com>

        ObjCCallbackFunction::destroy() should not use jsCast().
        https://bugs.webkit.org/show_bug.cgi?id=167322

        Reviewed by Filip Pizlo.

        Since r210829, it is no longer correct for object destructors to use jsCast().
        Fixed ObjCCallbackFunction::destroy() to use a static_cast instead.

        * API/ObjCCallbackFunction.mm:
        (JSC::ObjCCallbackFunction::destroy):

2017-01-23  Michael Saboff  <msaboff@apple.com>

        IntlObject uses JSArray::tryCreateUninitialized in an unsafe way
        https://bugs.webkit.org/show_bug.cgi?id=167288

        Reviewed by Filip Pizlo.

        Refactored the following "create" methods into a "tryCreate" method and a
        "create" wrapper: JSArray::create(), Butterfly::create() and
        createArrayButterfly().

        Changed IntlObject.cpp to use JSArray::tryCreate() as it is simpler to use
        by not requiring the caller to be GC savey.  The performance benefits of
        tryCreateUninitialized() are not needed by the IntlObject c++ code.

        Did not add a new test as the bug caused LayoutTests/js/intl.html to fail
        reliably with the JSC option values scribbleFreeCells=true,
        collectContinuously=true and JSC_useGenerationalGC=false.

        * runtime/Butterfly.h:
        * runtime/ButterflyInlines.h:
        (JSC::Butterfly::tryCreate): Added.
        (JSC::Butterfly::create):
        * runtime/IntlObject.cpp:
        (JSC::canonicalizeLocaleList):
        (JSC::lookupSupportedLocales):
        (JSC::intlObjectFuncGetCanonicalLocales):
        * runtime/JSArray.h:
        (JSC::createContiguousArrayButterfly): Deleted.
        (JSC::tryCreateArrayButterfly): Added.
        (JSC::createArrayButterfly):
        (JSC::JSArray::tryCreate): Added.
        (JSC::JSArray::create):

2017-01-23  Joseph Pecoraro  <pecoraro@apple.com>

        JavaScriptCore has a weak external symbol in it
        https://bugs.webkit.org/show_bug.cgi?id=167282

        Reviewed by Yusuke Suzuki.

        * debugger/Debugger.cpp:
        (JSC::Debugger::ProfilingClient::~ProfilingClient):
        * debugger/Debugger.h:
        Avoid possible weak external symbol.

2017-01-21  Chris Dumez  <cdumez@apple.com>

        JavaScript for-of does not work on a lot of collection types (e.g. HTMLCollection)
        https://bugs.webkit.org/show_bug.cgi?id=167091

        Reviewed by Darin Adler.

        Update Array methods to throw a TypeError when (this === null || this === undefined)
        instead of when (this == null). This is because (this == null) returns true for types
        that masquerades as undefined (such as document.all) and this prevented use of the
        Array API on such types. The specification only stays to use ToObject(), which throws
        when the input is undefined or null.

        The corresponding specification is at:
        - https://www.ecma-international.org/ecma-262/7.0/index.html#sec-array.prototype.values
        - https://www.ecma-international.org/ecma-262/7.0/index.html#sec-toobject

        * builtins/ArrayPrototype.js:
        (values):
        (keys):
        (entries):
        (reduce):
        (reduceRight):
        (every):
        (forEach):
        (filter):
        (map):
        (some):
        (fill):
        (find):
        (findIndex):
        (includes):
        (sort):
        (concatSlowPath):
        (copyWithin):

2017-01-21  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] export JSC::importModule API for WebCore dynamic import
        https://bugs.webkit.org/show_bug.cgi?id=167099

        Reviewed by Darin Adler.

        We newly expose JSC::importModule API. This can be used later
        from WebCore to implement WebCore side dynamic import.
        And JSC shell also uses this API.

        And this patch also cleans up module loader a bit:
        Dropping requestInstantiateAll.

        * builtins/BuiltinNames.h:
        * builtins/ModuleLoaderPrototype.js:
        (requestLink):
        (requestImportModule):
        (requestInstantiateAll): Deleted.
        (importModule): Deleted.
        * jsc.cpp:
        (GlobalObject::moduleLoaderImportModule):
        * runtime/Completion.cpp:
        (JSC::importModule):
        * runtime/Completion.h:
        * runtime/JSModuleLoader.cpp:
        (JSC::JSModuleLoader::requestImportModule):
        * runtime/JSModuleLoader.h:
        * runtime/ModuleLoaderPrototype.cpp:

2017-01-21  Yusuke Suzuki  <utatane.tea@gmail.com>

        dynamic import is ambiguous with import declaration at module code
        https://bugs.webkit.org/show_bug.cgi?id=167098

        Reviewed by Darin Adler.

        This patch fixes two syntax issues related to dynamic import.

        1. Fix member expression parsing with dynamic import results

        We should not return import expression immediately after parsing
        it in parseMemberExpression. This prohibits us to parse the following
        code,

            import("...").then(function () {
            });

        2. dynamic import with import declaration under the module context

        Before this patch, we always attempt to parse IMPORT as import declaration
        under the module context. It means that import call in the top level
        expression statement fails to be parsed since the parser attempts to parse
        it as import declaration.

            import("...")  // module top level statement.

        In this patch, we check the condition `[lookahead != (]` before starting
        parsing import declaration. This allows us to put import call in the module
        top level statement.

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

2017-01-20  Joseph Pecoraro  <pecoraro@apple.com>

        Remove outdated ENABLE(CSP_NEXT) build flag
        https://bugs.webkit.org/show_bug.cgi?id=167252

        Reviewed by Brent Fulgham.

        * Configurations/FeatureDefines.xcconfig:

2017-01-20  Saam Barati  <sbarati@apple.com>

        We should flash a safepoint before each DFG/FTL phase
        https://bugs.webkit.org/show_bug.cgi?id=167234

        Reviewed by Filip Pizlo.

        The recent GC changes caused us to regress Kraken because of a
        longstanding issue that happened to be hit with higher frequency because
        of a change in timing between when a particular GC was happening and 
        when a particular FTL compilation was happening. The regression is caused
        by the GC was waiting for a large function to make it through the DFG portion
        of an FTL compilation. This was taking 20ms-30ms and started happened during a
        particular test with much higher frequency.
        
        This means that anytime the GC waits for this compilation, the test ran at least
        ~20ms slower because the GC waits for the compiler threads the mutator is stopped.
        
        It's good that we have such an easily reproducible case of this performance
        issue because it will effect many real JS programs, especially ones with
        large functions that get hot.
        
        The most straight forward solution to fix this is to flash a safepoint before
        each phase, allowing the GC to suspend the compiler if needed. In my testing,
        this progresses Kraken in the browser, and doesn't regress anything else. This
        solution also makes the most sense. I did some analysis on the compilation time
        of this function that took ~20-30ms to pass through the DFG phases, and
        the phase times were mostly evenly distributed. Some took longer than others,
        but no phase was longer than 3ms. Most were in the 0.25ms to 1.5ms range.

        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGSafepoint.cpp:
        (JSC::DFG::Safepoint::begin):
        * runtime/Options.h:

2017-01-20  Skachkov Oleksandr  <gskachkov@gmail.com>

        Super property access in base class constructor doesn't work
        https://bugs.webkit.org/show_bug.cgi?id=166665

        Reviewed by Ryosuke Niwa.

        Allow to use super inside of the constructor for classes 
        without parent class.
        Parser checks if super used within the constructor and 
        add this information to function metedata, and later it is used
        during byte code generation.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::ClassExprNode::emitBytecode):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFunctionBody):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        * parser/Parser.h:
        (JSC::Scope::usesEval):
        (JSC::Scope::fillParametersForSourceProviderCache):
        (JSC::Scope::restoreFromSourceProviderCache):
        (JSC::Parser::adjustSuperBindingForBaseConstructor):
        * parser/SourceProviderCacheItem.h:
        (JSC::SourceProviderCacheItem::SourceProviderCacheItem):

2017-01-19  Chris Dumez  <cdumez@apple.com>

        iterable<> should be enabled on WK1
        https://bugs.webkit.org/show_bug.cgi?id=167221
        <rdar://problem/30108531>

        Reviewed by Youenn Fablet.

        * runtime/CommonIdentifiers.h:

2017-01-19  Filip Pizlo  <fpizlo@apple.com>

        Structure::pin() needs to be called while holding a lock
        https://bugs.webkit.org/show_bug.cgi?id=167220

        Reviewed by Saam Barati.

        Imagine this race: the mutator calls pin() and the collector calls visitChildren(),
        on the same Structure at the same time. In trunk pin() does not require a lock to be
        held and it doesn't grab any locks. Meanwhile visitChildren() grabs the lock, checks
        if the structure is pinned, and if not, it removes it by overwriting with zero. Now
        imagine how this plays out when pin() runs. Since pin() grabs no locks, it is
        irrelevant that visitChildren() grabs any locks. So, visitChildren() might check if
        the table is pinned before pin() pins it, and then clear the table after it was
        already pinned.

        The problem here is that pin() should be holding a lock. We could either make pin()
        grab that lock by itself, or what this patch does is makes the caller grab the lock.
        This is great because it means that sometimes we don't have to introduce any new
        locking.

        This fixes a materializePropertyTable() checkOffsetConsistency() crash that happens
        very rarely, but I was able to get it to reproduce with run-webkit-tests and
        aggressive GC settings.

        * runtime/ConcurrentJSLock.h:
        * runtime/Structure.cpp:
        (JSC::Structure::materializePropertyTable):
        (JSC::Structure::changePrototypeTransition):
        (JSC::Structure::attributeChangeTransition):
        (JSC::Structure::toDictionaryTransition):
        (JSC::Structure::nonPropertyTransition):
        (JSC::Structure::pin):
        (JSC::Structure::pinForCaching):
        (JSC::Structure::add):
        * runtime/Structure.h:
        * runtime/StructureInlines.h:
        (JSC::Structure::checkOffsetConsistency):
        (JSC::Structure::add):
        (JSC::Structure::addPropertyWithoutTransition):

2017-01-19  Filip Pizlo  <fpizlo@apple.com>

        The mutator needs to fire a barrier after memmoving stuff around in an object that the GC scans
        https://bugs.webkit.org/show_bug.cgi?id=167208

        Reviewed by Saam Barati.
        
        It used to be that if you moved a value from one place to another in the same object
        then there is no need for a barrier because the generational GC would have no need to
        know that some old object still continues to refer to the same other old object.

        But the concurrent GC might scan that object as the mutator moves pointers around in
        it. If the ordering is right, this could mean that the collector never sees some of
        those pointers. This can be fixed by adding a barrier.

        This fixes the most obvious cases I found. There may be more and I'll continue to
        audit. Most of the other memmove users seem to already use some kind of synchronization
        to prevent this. For example, this can also be fixed by just holding the cell lock
        around the memmove since we're dealing with indexing storage and the GC reads that
        under the cell lock.

        * runtime/JSArray.cpp:
        (JSC::JSArray::shiftCountWithAnyIndexingType):
        (JSC::JSArray::unshiftCountWithAnyIndexingType):

2017-01-19  Myles C. Maxfield  <mmaxfield@apple.com>

        [Cocoa] Variation fonts are erroneously disabled on iOS
        https://bugs.webkit.org/show_bug.cgi?id=167172

        Reviewed by Simon Fraser.

        OpenSource builders don't seem to understand sdk=embedded*.

        * Configurations/FeatureDefines.xcconfig:

2017-01-19  Skachkov Oleksandr  <gskachkov@gmail.com>

        "this" missing after await in async arrow function
        https://bugs.webkit.org/show_bug.cgi?id=166919

        Reviewed by NOBODY Saam Barati.

        This patch fixed issue in async arrow function. Issue appears because in arrow
        function _this_ is loaded from arrow function virtual scope. 
        Async arrow function can be suspended and when resuming should be used _this_ from 
        virtual scope, to allow this we load _this_ from virtual scope before store it to 
        generator.generatorThis property 

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

2017-01-18  Yusuke Suzuki  <utatane.tea@gmail.com>

        [B3] B3 strength reduction could encounter Value without owner in PureCSE
        https://bugs.webkit.org/show_bug.cgi?id=167161

        Reviewed by Filip Pizlo.

        PureCSE relies on the fact that all the stored Values have owner member.
        This assumption is broken when you execute specializeSelect in B3ReduceStrength phase.
        It clears owner of Values which are in between Select and Check to clone them to then/else
        blocks. If these cleared Values are already stored in PureCSE map, this map poses a Value
        with nullptr owner in PureCSE.

        This patch changes PureCSE to ignore stored Values tha have nullptr owner. This even means
        that a client of PureCSE could deliberately null the owner if they wanted to signal the
        Value should be ignored.

        While PureCSE ignores chance for optimization if Value's owner is nullptr, in the current
        strength reduction algorithm, this does not hurt optimization because CSE will be eventually
        applied since the strength reduction phase want to reach fixed point. But even without
        this iterations, our result itself is valid since PureCSE is allowed to be conservative.

        * b3/B3PureCSE.cpp:
        (JSC::B3::PureCSE::findMatch):
        (JSC::B3::PureCSE::process):
        * b3/testb3.cpp:
        (JSC::B3::testCheckSelectAndCSE):
        (JSC::B3::run):

2017-01-18  Filip Pizlo  <fpizlo@apple.com>

        JSSegmentedVariableObject and its subclasses should have a sane destruction story
        https://bugs.webkit.org/show_bug.cgi?id=167193

        Reviewed by Saam Barati.
        
        Prior to this change, JSSegmentedVariableObjects' subclasses install finalizers that call
        destroy. They did this in random ways, which sometimes resulted in
        JSSegmentedVariableObject::~JSSegmentedVariableObject executing more than once (which worked
        because of the way that ~SegmentedVector is written). Maybe this works now, but it's a disaster
        waiting to happen.

        Fortunately we can now just give those things their own Subspace and teach it its own protocol of
        destruction. This change introduces JSSegmentedVariableObjectSubspace and stashes a m_classInfo
        in JSSegmentedVariableObject. Now, subclasses of JSSegmentedVariableObject are destructible in
        much the same way as JSDestructibleObject without having to be subclasses of
        JSDestructibleObject.

        * API/JSCallbackObject.cpp:
        (JSC::JSCallbackObject<JSGlobalObject>::create):
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * jsc.cpp:
        (GlobalObject::create):
        * runtime/JSGlobalLexicalEnvironment.h:
        (JSC::JSGlobalLexicalEnvironment::create):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::create):
        (JSC::JSGlobalObject::finishCreation):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::create): Deleted.
        (JSC::JSGlobalObject::finishCreation): Deleted.
        * runtime/JSSegmentedVariableObject.cpp:
        (JSC::JSSegmentedVariableObject::destroy):
        (JSC::JSSegmentedVariableObject::JSSegmentedVariableObject):
        (JSC::JSSegmentedVariableObject::~JSSegmentedVariableObject):
        (JSC::JSSegmentedVariableObject::finishCreation):
        * runtime/JSSegmentedVariableObject.h:
        (JSC::JSSegmentedVariableObject::subspaceFor):
        (JSC::JSSegmentedVariableObject::classInfo):
        (JSC::JSSegmentedVariableObject::JSSegmentedVariableObject): Deleted.
        (JSC::JSSegmentedVariableObject::finishCreation): Deleted.
        * runtime/JSSegmentedVariableObjectSubspace.cpp: Added.
        (JSC::JSSegmentedVariableObjectSubspace::JSSegmentedVariableObjectSubspace):
        (JSC::JSSegmentedVariableObjectSubspace::~JSSegmentedVariableObjectSubspace):
        (JSC::JSSegmentedVariableObjectSubspace::finishSweep):
        (JSC::JSSegmentedVariableObjectSubspace::destroy):
        * runtime/JSSegmentedVariableObjectSubspace.h: Added.
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        * testRegExp.cpp:
        (GlobalObject::create):

2017-01-18  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: console.table only works for the first 5 properties
        https://bugs.webkit.org/show_bug.cgi?id=167175

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.prototype.wrapTable):
        (InjectedScript.RemoteObject.createObjectPreviewForValue):
        (InjectedScript.RemoteObject.prototype._appendPropertyPreviews):
        Pass through secondLevelKeys. Though the keys are themselves ignored, the
        existence is a signal that we should send more than the first 5 properties.

2017-01-18  Antti Koivisto  <antti@apple.com>

        Only delete source provider caches on full collection
        https://bugs.webkit.org/show_bug.cgi?id=167173

        Reviewed by Andreas Kling.

        They are currently often wiped and recreated during page loading due to eden collections.

        It is not clear that tying the lifetime of these caches to gc makes sense at all but this
        should at least help some.

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

2017-01-18  Filip Pizlo  <fpizlo@apple.com>

        JSObjectSetPrivate should not use jsCast<>
        rdar://problem/30069096

        Reviewed by Keith Miller.

        * API/JSObjectRef.cpp:
        (JSObjectSetPrivate):

2017-01-18  Brian Burg  <bburg@apple.com>

        Web Inspector: remove an unnecessary include in generated Objective-C Inspector protocol code
        https://bugs.webkit.org/show_bug.cgi?id=167156

        Rubber-stamped by Geoffrey Garen.

        * inspector/scripts/codegen/objc_generator_templates.py:
        This include of config.h doesn't make sense when using the code generator
        outside of JavaScriptCore/WebKit. It is not necessary either, so remove it.

        * inspector/scripts/tests/all/expected/definitions-with-mac-platform.json-result:
        * inspector/scripts/tests/generic/expected/commands-with-async-attribute.json-result:
        * inspector/scripts/tests/generic/expected/commands-with-optional-call-return-parameters.json-result:
        * inspector/scripts/tests/generic/expected/definitions-with-mac-platform.json-result:
        * inspector/scripts/tests/generic/expected/domains-with-varying-command-sizes.json-result:
        * inspector/scripts/tests/generic/expected/enum-values.json-result:
        * inspector/scripts/tests/generic/expected/events-with-optional-parameters.json-result:
        * inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result:
        * inspector/scripts/tests/generic/expected/same-type-id-different-domain.json-result:
        * inspector/scripts/tests/generic/expected/shadowed-optional-type-setters.json-result:
        * inspector/scripts/tests/generic/expected/type-declaration-aliased-primitive-type.json-result:
        * inspector/scripts/tests/generic/expected/type-declaration-array-type.json-result:
        * inspector/scripts/tests/generic/expected/type-declaration-enum-type.json-result:
        * inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result:
        * inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:
        * inspector/scripts/tests/ios/expected/definitions-with-mac-platform.json-result:
        * inspector/scripts/tests/mac/expected/definitions-with-mac-platform.json-result:
        Rebaseline test results.

2017-01-18  Csaba Osztrogonác  <ossy@webkit.org>

        Fix the JSCOnly build after r210844
        https://bugs.webkit.org/show_bug.cgi?id=167155

        Unreviewed buildfix.

        * heap/EdenGCActivityCallback.cpp:

2017-01-16  Filip Pizlo  <fpizlo@apple.com>

        Make opaque root scanning truly constraint-based
        https://bugs.webkit.org/show_bug.cgi?id=165760

        Reviewed by Geoffrey Garen.

        We have bugs when visitChildren() changes its mind about what opaque root to add, since
        we don't have barriers on opaque roots. This supposedly once worked for generational GC,
        and I started adding more barriers to support concurrent GC. But I think that the real
        bug here is that we want the JSObject->OpaqueRoot to be evaluated as a constraint that
        participates in the fixpoint. I like to think of this as an *output* constraint, because it
        is concerned with outgoing edges in the heap from the object that registered the constraint.
        An *input* constraint is like what Weak<> does when deciding whether the thing it points to
        should be live.

        Whether or not an object has output constraints depends on its type. So, we want the GC to
        have a feature where we rapidly call some function on all marked objects of some type.
        
        It's easy to rapidly scan all marked objects in a MarkedBlock. So, we want to allocate all
        objects that have output constraints in their own MarkedBlocks and we want to track the set
        of MarkedBlocks with output constraints.
        
        This patch makes it easy to have clients of JSC's internal C++ APIs create a Subspace - like
        what we used to call MarkedSpace::Subspace but now it's in the JSC namespace - which is
        a collection of objects that you can easily scan during GC from a MarkingConstraint. It's
        now possible for internal C++ API clients to register their own MarkingConstraints. The DOM
        now uses this to create two Subspaces (more on why two below) and it calls
        JSCell::visitOutputConstraints() on all of the marked objects in those subspaces using a new
        MarkingConstraint. That MarkingConstraint uses a new style of volatility, called
        SeldomGreyed, which is like GreyedByExecution except it is opportunistically not executed
        as roots in the hopes that their sole execution will be the snapshot-at-the-end. I also
        converted the CodeBlock rescan constraint to SeldomGreyed, since that's also an output
        constraint.
        
        This patch also uses Subspace for something pretty obvious: knowing how to call the
        destructor. Subspaces can specialize the sweep for their way of invoking destructors. We
        have the following subspaces:
        
        - auxiliary
        - cell
        - destructibleCell - for JSCell subclasses that have destructors and StructureIsImmortal
        - stringSpace - inlines ~JSString into the sweep, making string allocation 7% faster
        - destructibleObjectSpace - for JSDestructibleObject subclasses
        
        And WebCore adds:
        
        - outputConstraint - for JSDOMObjects that have a visitAdditionalChildren
        - globalObjectOutputConstraint - for JSDOMGlobalObjects that have a visitAdditionalChildren,
          since JSDOMGlobalObjects are not JSDestructibleObjects
        
        The Subspace for a type is selected by saying JSC::subspaceFor<Type>(vm). This calls
        Type::subspaceFor<Type>(vm). This allows cell classes to override subspaceFor<> and it
        allows any subspaceFor<> implementation to query static flags in the type. This is how
        JSCell::subspaceFor<> can select either cellSpace or destructibleCellSpace.
        
        This patch is mostly about:
        
        - Moving MarkedSpace::Subspace out of MarkedSpace and making it a nice class with a nice
          API. Almost all of its functionality is just taken out of MarkedSpace.
        - Converting users of the old API for allocating objects and getting MarkedAllocators, like
          heap.allocatorForObjectWithoutDestructor() and its friends. That would now say
          vm.cellSpace.allocatorFor().
        
        Altogether, this means that we only have a small regression on Dromaeo. The regression is
        due to the fact that we scan output constraints. Before the Subspace optimizations (see
        r209766, which was rolled out in r209812), this regression on Dromaeo/jslib was 2x but after
        the optimizations in this patch it's only 1.12x. Note that Dromaeo/jslib creats gigabytes of
        DOM nodes. Compared to web pages, this is a very extreme synthetic microbenchmark. Still, we
        like optimizing these because we don't want to presume what web pages will look like.
        
        The use of Subspaces to specialize destructors happened not because it's super necessary but
        because I wanted to introduce a single unified way of communicating to the GC how to treat
        different types. Any Subspace feature that allowed us to collect some types together would
        have to be mindful of the destructorness of objects. I could have turned this into a
        liability where each Subspace has two subsubspaces - one for destructor objects and one for
        non-destructor objects, which would have allowed me to keep the old sweep specialization
        code. Just days prior, mlam wanted to do something that was hard because of that old sweep
        specializer, so I decided to take the opportunity to fix the sweep specializer while also
        making Subspace be the one true way of teaching the GC about types. To validate that this
        actually does things, I added a JSStringSubspace and a test that shows that this is a 7%
        string allocation progression.
        
        In bug 167066, I'm getting rid of the rest of the code in JSC that would special-case for
        JSDestructibleObject vs StructureIsImmortal by using the GC's DestructionMode. After that,
        Subspace will be only mechanism by which JSC uses the GC to encode types.
        
        Prior to this change, having multiple MarkedSpace::Subspaces would have been expensive
        because they create a bunch of MarkedAllocators upfront. We now have the ability to create
        MarkedAllocators lazily. We create them on the first allocation from that size class or when
        a JIT asks for the MarkedAllocator. The concurrent JITs can ask for MarkedAllocators because
        their creation is under a lock.
        
        On my machine, this might be a 1.1% JetStream speed-up with 87% confidence and it might be
        a 0.4% PLT3 slow-down with 92% confidence. Note that 0.4% on PLT3 is the level of systematic
        error on PLT3 on my computer: I've seen definite 0.4% speed-ups and slow-downs that were not
        confirmed by any bot. Let's see what the bots say.
        
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/ObjectAllocationProfile.h:
        (JSC::ObjectAllocationProfile::initialize):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generateImpl):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
        (JSC::DFG::SpeculativeJIT::compileMakeRope):
        (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
        (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
        (JSC::DFG::SpeculativeJIT::compileNewTypedArray):
        (JSC::DFG::SpeculativeJIT::emitAllocateButterfly):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
        (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
        (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
        (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorageWithSizeImpl):
        (JSC::FTL::DFG::LowerDFGToB3::allocateObject):
        (JSC::FTL::DFG::LowerDFGToB3::allocatorForSize):
        (JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedObject):
        (JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedCell):
        (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
        * heap/AllocatorAttributes.h:
        (JSC::AllocatorAttributes::AllocatorAttributes):
        * heap/ConstraintVolatility.h: Added.
        (WTF::printInternal):
        * heap/GCActivityCallback.cpp:
        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::lastChanceToFinalize):
        (JSC::Heap::markToFixpoint):
        (JSC::Heap::updateObjectCounts):
        (JSC::Heap::collectAllGarbage):
        (JSC::Heap::collectInThread):
        (JSC::Heap::stopTheWorld):
        (JSC::Heap::updateAllocationLimits):
        (JSC::Heap::bytesVisited):
        (JSC::Heap::addCoreConstraints):
        (JSC::Heap::addMarkingConstraint):
        (JSC::Heap::notifyIsSafeToCollect):
        (JSC::Heap::preventCollection):
        (JSC::Heap::allowCollection):
        (JSC::Heap::setMutatorShouldBeFenced):
        (JSC::Heap::buildConstraintSet): Deleted.
        (JSC::Heap::writeBarrierOpaqueRootSlow): Deleted.
        (JSC::Heap::addMutatorShouldBeFencedCache): Deleted.
        * heap/Heap.h:
        (JSC::Heap::mutatorExecutionVersion):
        (JSC::Heap::numOpaqueRoots):
        (JSC::Heap::vm): Deleted.
        (JSC::Heap::subspaceForObjectWithoutDestructor): Deleted.
        (JSC::Heap::subspaceForObjectDestructor): Deleted.
        (JSC::Heap::subspaceForAuxiliaryData): Deleted.
        (JSC::Heap::allocatorForObjectWithoutDestructor): Deleted.
        (JSC::Heap::allocatorForObjectWithDestructor): Deleted.
        (JSC::Heap::allocatorForAuxiliaryData): Deleted.
        * heap/HeapInlines.h:
        (JSC::Heap::vm):
        (JSC::Heap::allocateWithDestructor): Deleted.
        (JSC::Heap::allocateWithoutDestructor): Deleted.
        (JSC::Heap::allocateObjectOfType): Deleted.
        (JSC::Heap::subspaceForObjectOfType): Deleted.
        (JSC::Heap::allocatorForObjectOfType): Deleted.
        (JSC::Heap::allocateAuxiliary): Deleted.
        (JSC::Heap::tryAllocateAuxiliary): Deleted.
        (JSC::Heap::tryReallocateAuxiliary): Deleted.
        (JSC::Heap::ascribeOwner): Deleted.
        (JSC::Heap::writeBarrierOpaqueRoot): Deleted.
        * heap/LargeAllocation.cpp:
        (JSC::LargeAllocation::tryCreate):
        (JSC::LargeAllocation::LargeAllocation):
        (JSC::LargeAllocation::~LargeAllocation):
        (JSC::LargeAllocation::sweep):
        * heap/LargeAllocation.h:
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::MarkedAllocator):
        (JSC::MarkedAllocator::tryAllocateWithoutCollecting):
        (JSC::MarkedAllocator::tryAllocateIn):
        (JSC::MarkedAllocator::allocateSlowCaseImpl):
        (JSC::MarkedAllocator::tryAllocateBlock):
        (JSC::MarkedAllocator::shrink):
        (JSC::MarkedAllocator::markedSpace):
        * heap/MarkedAllocator.h:
        (JSC::MarkedAllocator::nextAllocatorInSubspace):
        (JSC::MarkedAllocator::setNextAllocatorInSubspace):
        (JSC::MarkedAllocator::subspace):
        (JSC::MarkedAllocator::tryAllocate): Deleted.
        (JSC::MarkedAllocator::allocate): Deleted.
        (JSC::MarkedAllocator::forEachBlock): Deleted.
        * heap/MarkedAllocatorInlines.h: Added.
        (JSC::MarkedAllocator::tryAllocate):
        (JSC::MarkedAllocator::allocate):
        (JSC::MarkedAllocator::forEachBlock):
        (JSC::MarkedAllocator::forEachNotEmptyBlock):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::Handle::subspace):
        (JSC::MarkedBlock::Handle::sweep):
        (JSC::MarkedBlock::Handle::specializedSweep): Deleted.
        (JSC::MarkedBlock::Handle::sweepHelperSelectScribbleMode): Deleted.
        (JSC::MarkedBlock::Handle::sweepHelperSelectEmptyMode): Deleted.
        (JSC::MarkedBlock::Handle::sweepHelperSelectHasNewlyAllocated): Deleted.
        (JSC::MarkedBlock::Handle::sweepHelperSelectSweepMode): Deleted.
        (JSC::MarkedBlock::Handle::sweepHelperSelectMarksMode): Deleted.
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::Handle::visitWeakSet):
        * heap/MarkedBlockInlines.h:
        (JSC::MarkedBlock::Handle::isNewlyAllocatedStale):
        (JSC::MarkedBlock::Handle::hasAnyNewlyAllocated):
        (JSC::MarkedBlock::heap):
        (JSC::MarkedBlock::space):
        (JSC::MarkedBlock::Handle::space):
        (JSC::MarkedBlock::Handle::specializedSweep):
        (JSC::MarkedBlock::Handle::finishSweepKnowingSubspace):
        (JSC::MarkedBlock::Handle::sweepDestructionMode):
        (JSC::MarkedBlock::Handle::emptyMode):
        (JSC::MarkedBlock::Handle::scribbleMode):
        (JSC::MarkedBlock::Handle::newlyAllocatedMode):
        (JSC::MarkedBlock::Handle::marksMode):
        (JSC::MarkedBlock::Handle::forEachMarkedCell):
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::initializeSizeClassForStepSize):
        (JSC::MarkedSpace::MarkedSpace):
        (JSC::MarkedSpace::lastChanceToFinalize):
        (JSC::MarkedSpace::addMarkedAllocator):
        (JSC::MarkedSpace::allocate): Deleted.
        (JSC::MarkedSpace::tryAllocate): Deleted.
        (JSC::MarkedSpace::allocateLarge): Deleted.
        (JSC::MarkedSpace::tryAllocateLarge): Deleted.
        * heap/MarkedSpace.h:
        (JSC::MarkedSpace::heap):
        (JSC::MarkedSpace::allocatorLock):
        (JSC::MarkedSpace::subspaceForObjectsWithDestructor): Deleted.
        (JSC::MarkedSpace::subspaceForObjectsWithoutDestructor): Deleted.
        (JSC::MarkedSpace::subspaceForAuxiliaryData): Deleted.
        (JSC::MarkedSpace::allocatorFor): Deleted.
        (JSC::MarkedSpace::destructorAllocatorFor): Deleted.
        (JSC::MarkedSpace::auxiliaryAllocatorFor): Deleted.
        (JSC::MarkedSpace::allocateWithoutDestructor): Deleted.
        (JSC::MarkedSpace::allocateWithDestructor): Deleted.
        (JSC::MarkedSpace::allocateAuxiliary): Deleted.
        (JSC::MarkedSpace::tryAllocateAuxiliary): Deleted.
        (JSC::MarkedSpace::forEachSubspace): Deleted.
        * heap/MarkingConstraint.cpp:
        (JSC::MarkingConstraint::MarkingConstraint):
        * heap/MarkingConstraint.h:
        (JSC::MarkingConstraint::volatility):
        * heap/MarkingConstraintSet.cpp:
        (JSC::MarkingConstraintSet::resetStats):
        (JSC::MarkingConstraintSet::add):
        (JSC::MarkingConstraintSet::executeConvergenceImpl):
        * heap/MarkingConstraintSet.h:
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::visitChildren):
        (JSC::SlotVisitor::visitAsConstraint):
        (JSC::SlotVisitor::drain):
        (JSC::SlotVisitor::addOpaqueRoot):
        (JSC::SlotVisitor::mergeIfNecessary):
        (JSC::SlotVisitor::mergeOpaqueRootsIfNecessary): Deleted.
        * heap/SlotVisitor.h:
        (JSC::SlotVisitor::setIgnoreNewOpaqueRoots):
        * heap/SlotVisitorInlines.h:
        (JSC::SlotVisitor::reportExtraMemoryVisited):
        (JSC::SlotVisitor::reportExternalMemoryVisited):
        * heap/Subspace.cpp: Added.
        (JSC::Subspace::Subspace):
        (JSC::Subspace::~Subspace):
        (JSC::Subspace::finishSweep):
        (JSC::Subspace::destroy):
        (JSC::Subspace::allocate):
        (JSC::Subspace::tryAllocate):
        (JSC::Subspace::allocatorForSlow):
        (JSC::Subspace::allocateSlow):
        (JSC::Subspace::tryAllocateSlow):
        * heap/Subspace.h: Added.
        (JSC::Subspace::tryAllocatorFor):
        (JSC::Subspace::allocatorFor):
        * heap/SubspaceInlines.h: Added.
        (JSC::Subspace::forEachMarkedBlock):
        (JSC::Subspace::forEachNotEmptyMarkedBlock):
        (JSC::Subspace::forEachLargeAllocation):
        (JSC::Subspace::forEachMarkedCell):
        * heap/WeakBlock.cpp:
        (JSC::WeakBlock::specializedVisit):
        * heap/WeakBlock.h:
        * heap/WeakSet.h:
        (JSC::WeakSet::visit):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitAllocateJSObjectWithKnownSize):
        (JSC::AssemblyHelpers::emitAllocateVariableSized):
        (JSC::AssemblyHelpers::emitAllocateVariableSizedCell):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_new_object):
        * jsc.cpp:
        * runtime/ButterflyInlines.h:
        (JSC::Butterfly::createUninitialized):
        (JSC::Butterfly::growArrayRight):
        * runtime/ClassInfo.h:
        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::createEmpty):
        * runtime/DirectArguments.cpp:
        (JSC::DirectArguments::overrideThings):
        * runtime/GenericArgumentsInlines.h:
        (JSC::GenericArguments<Type>::initModifiedArgumentsDescriptor):
        * runtime/HashMapImpl.h:
        (JSC::HashMapBuffer::create):
        * runtime/JSArray.cpp:
        (JSC::JSArray::tryCreateUninitialized):
        (JSC::JSArray::unshiftCountSlowCase):
        * runtime/JSArrayBufferView.cpp:
        (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
        * runtime/JSCell.h:
        (JSC::subspaceFor):
        * runtime/JSCellInlines.h:
        (JSC::JSCell::visitOutputConstraints):
        (JSC::JSCell::subspaceFor):
        (JSC::allocateCell):
        * runtime/JSDestructibleObject.h:
        (JSC::JSDestructibleObject::subspaceFor):
        * runtime/JSDestructibleObjectSubspace.cpp: Added.
        (JSC::JSDestructibleObjectSubspace::JSDestructibleObjectSubspace):
        (JSC::JSDestructibleObjectSubspace::~JSDestructibleObjectSubspace):
        (JSC::JSDestructibleObjectSubspace::finishSweep):
        (JSC::JSDestructibleObjectSubspace::destroy):
        * runtime/JSDestructibleObjectSubspace.h: Added.
        * runtime/JSObject.h:
        (JSC::JSObject::JSObject):
        * runtime/JSObjectInlines.h:
        * runtime/JSSegmentedVariableObject.h:
        * runtime/JSString.h:
        (JSC::JSString::subspaceFor):
        * runtime/JSStringSubspace.cpp: Added.
        (JSC::JSStringSubspace::JSStringSubspace):
        (JSC::JSStringSubspace::~JSStringSubspace):
        (JSC::JSStringSubspace::finishSweep):
        (JSC::JSStringSubspace::destroy):
        * runtime/JSStringSubspace.h: Added.
        * runtime/RegExpMatchesArray.h:
        (JSC::tryCreateUninitializedRegExpMatchesArray):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2017-01-17  Michael Saboff  <msaboff@apple.com>

        Nested parenthesized regular expressions with non-zero minimum counts appear to hang and use lots of memory
        https://bugs.webkit.org/show_bug.cgi?id=167125

        Reviewed by Filip Pizlo.

        Changed Yarr to handle nested parenthesized subexpressions where the minimum count is
        not 0 directly in the Yarr interpreter.  Previously we'd factor an expression like
        (a|b)+ into (a|b)(a|b)* with special handling for captures.  This factoring was done
        using a deep copy that doubled the size of the resulting expresion for each nested 
        parenthesized subexpression.  Now the Yarr interpreter can directly process a regexp
        like (a|b){2,42}.  

        The parser will allow one level of nested, non-zero minimum, counted parenthesis using
        the old copy method.  After one level, it will generate parenthesis terms with a non-zero
        minimum.   Such an expression wasn't handled by the Yarr JIT before the change, so this
        change isn't a performance regression.

        Added a minimum count to the YarrPattern and ByteTerm classes, and then factored that
        minimum into the interpreter.  A non-zero minimum is only handled by the Yarr interpreter.
        If the Yarr JIT see such a term, it punts back to the interpreter.

        * yarr/YarrInterpreter.cpp:
        (JSC::Yarr::Interpreter::backtrackPatternCharacter):
        (JSC::Yarr::Interpreter::backtrackPatternCasedCharacter):
        (JSC::Yarr::Interpreter::matchCharacterClass):
        (JSC::Yarr::Interpreter::backtrackCharacterClass):
        (JSC::Yarr::Interpreter::matchBackReference):
        (JSC::Yarr::Interpreter::backtrackBackReference):
        (JSC::Yarr::Interpreter::matchParenthesesOnceBegin):
        (JSC::Yarr::Interpreter::matchParenthesesOnceEnd):
        (JSC::Yarr::Interpreter::backtrackParenthesesOnceBegin):
        (JSC::Yarr::Interpreter::backtrackParenthesesOnceEnd):
        (JSC::Yarr::Interpreter::matchParenthesesTerminalBegin):
        (JSC::Yarr::Interpreter::backtrackParenthesesTerminalBegin):
        (JSC::Yarr::Interpreter::matchParentheticalAssertionBegin):
        (JSC::Yarr::Interpreter::matchParentheticalAssertionEnd):
        (JSC::Yarr::Interpreter::backtrackParentheticalAssertionBegin):
        (JSC::Yarr::Interpreter::backtrackParentheticalAssertionEnd):
        (JSC::Yarr::Interpreter::matchParentheses):
        (JSC::Yarr::Interpreter::backtrackParentheses):
        (JSC::Yarr::Interpreter::matchDisjunction):
        (JSC::Yarr::ByteCompiler::atomPatternCharacter):
        (JSC::Yarr::ByteCompiler::atomCharacterClass):
        (JSC::Yarr::ByteCompiler::atomBackReference):
        (JSC::Yarr::ByteCompiler::atomParentheticalAssertionEnd):
        (JSC::Yarr::ByteCompiler::atomParenthesesSubpatternEnd):
        (JSC::Yarr::ByteCompiler::atomParenthesesOnceEnd):
        (JSC::Yarr::ByteCompiler::atomParenthesesTerminalEnd):
        (JSC::Yarr::ByteCompiler::emitDisjunction):
        * yarr/YarrInterpreter.h:
        (JSC::Yarr::ByteTerm::ByteTerm):
        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::generatePatternCharacterOnce):
        (JSC::Yarr::YarrGenerator::generatePatternCharacterFixed):
        (JSC::Yarr::YarrGenerator::generatePatternCharacterGreedy):
        (JSC::Yarr::YarrGenerator::backtrackPatternCharacterNonGreedy):
        (JSC::Yarr::YarrGenerator::generateCharacterClassFixed):
        (JSC::Yarr::YarrGenerator::generateCharacterClassGreedy):
        (JSC::Yarr::YarrGenerator::backtrackCharacterClassNonGreedy):
        (JSC::Yarr::YarrGenerator::generateTerm):
        (JSC::Yarr::YarrGenerator::backtrackTerm):
        (JSC::Yarr::YarrGenerator::generate):
        (JSC::Yarr::YarrGenerator::backtrack):
        (JSC::Yarr::YarrGenerator::opCompileParenthesesSubpattern):
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::YarrPatternConstructor::copyTerm):
        (JSC::Yarr::YarrPatternConstructor::quantifyAtom):
        (JSC::Yarr::YarrPatternConstructor::checkForTerminalParentheses):
        (JSC::Yarr::YarrPattern::YarrPattern):
        * yarr/YarrPattern.h:
        (JSC::Yarr::PatternTerm::PatternTerm):
        (JSC::Yarr::PatternTerm::quantify):
        (JSC::Yarr::YarrPattern::reset):

2017-01-17  Joseph Pecoraro  <pecoraro@apple.com>

        ENABLE(USER_TIMING) Not Defined for Apple Windows or OS X Ports
        https://bugs.webkit.org/show_bug.cgi?id=116551
        <rdar://problem/13949830>

        Reviewed by Alex Christensen.

        * Configurations/FeatureDefines.xcconfig:

2017-01-16  Filip Pizlo  <fpizlo@apple.com>

        JSCell::classInfo() shouldn't have a bunch of mitigations for being called during destruction
        https://bugs.webkit.org/show_bug.cgi?id=167066

        Reviewed by Keith Miller and Michael Saboff.
        
        This reduces the size of JSCell::classInfo() by half and removes some checks that
        this function previously had to do in case it was called from destructors.
        
        I changed all of the destructors so that they don't call JSCell::classInfo() and I
        added an assertion to JSCell::classInfo() to catch cases where someone called it
        from a destructor accidentally.
        
        This means that we only have one place in destruction that needs to know the class:
        the sweeper's call to the destructor.
        
        One of the trickiest outcomes of this is the need to support inherits() tests in
        JSObjectGetPrivate(), when it is called from the destructor callback on the object
        being destructed. JSObjectGetPrivate() is undefined behavior anyway if you use it
        on any dead-but-not-destructed object other than the one being destructed right
        now. The purpose of the inherits() tests is to distinguish between different kinds
        of CallbackObjects, which may have different kinds of base classes. I think that
        this was always subtly wrong - for example, if the object being destructed is a
        JSGlobalObject then it's not a DestructibleObject, is not in a destructor block,
        but does not have an immortal Structure - so classInfo() is not valid. This fixes
        the issue by having ~JSCallbackObject know its classInfo. It now stashes its
        classInfo in VM so that JSObjectGetPrivate can use that classInfo if it detects
        that it's being used on a currently-destructing object.
        
        That was the only really weird part of this patch. The rest is mostly removing
        illegal uses of jsCast<> in destructors. There were a few other genuine uses of
        classInfo() but they were in code that already knew how to get its classInfo()
        using other means:
        
        - You can still say structure()->classInfo(), and I use this form in code that
          knows that its StructureIsImmortal.
        
        - You can use this->classInfo() if it's overridden, like in subclasses of
          JSDestructibleObject.
        
        Rolling this back in because I think I fixed the crashes.

        * API/JSAPIWrapperObject.mm:
        (JSAPIWrapperObjectHandleOwner::finalize):
        * API/JSCallbackObject.h:
        * API/JSCallbackObjectFunctions.h:
        (JSC::JSCallbackObject<Parent>::~JSCallbackObject):
        (JSC::JSCallbackObject<Parent>::init):
        * API/JSObjectRef.cpp:
        (classInfoPrivate):
        (JSObjectGetPrivate):
        (JSObjectSetPrivate):
        * bytecode/EvalCodeBlock.cpp:
        (JSC::EvalCodeBlock::destroy):
        * bytecode/FunctionCodeBlock.cpp:
        (JSC::FunctionCodeBlock::destroy):
        * bytecode/ModuleProgramCodeBlock.cpp:
        (JSC::ModuleProgramCodeBlock::destroy):
        * bytecode/ProgramCodeBlock.cpp:
        (JSC::ProgramCodeBlock::destroy):
        * bytecode/UnlinkedEvalCodeBlock.cpp:
        (JSC::UnlinkedEvalCodeBlock::destroy):
        * bytecode/UnlinkedFunctionCodeBlock.cpp:
        (JSC::UnlinkedFunctionCodeBlock::destroy):
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::destroy):
        * bytecode/UnlinkedModuleProgramCodeBlock.cpp:
        (JSC::UnlinkedModuleProgramCodeBlock::destroy):
        * bytecode/UnlinkedProgramCodeBlock.cpp:
        (JSC::UnlinkedProgramCodeBlock::destroy):
        * heap/CodeBlockSet.cpp:
        (JSC::CodeBlockSet::lastChanceToFinalize):
        (JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::allocateSlowCaseImpl):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::Handle::sweep):
        * jit/JITThunks.cpp:
        (JSC::JITThunks::finalize):
        * runtime/AbstractModuleRecord.cpp:
        (JSC::AbstractModuleRecord::destroy):
        * runtime/ExecutableBase.cpp:
        (JSC::ExecutableBase::clearCode):
        * runtime/JSCellInlines.h:
        (JSC::JSCell::classInfo):
        (JSC::JSCell::callDestructor):
        * runtime/JSLock.h:
        (JSC::JSLock::ownerThread):
        * runtime/JSModuleNamespaceObject.cpp:
        (JSC::JSModuleNamespaceObject::destroy):
        * runtime/JSModuleRecord.cpp:
        (JSC::JSModuleRecord::destroy):
        * runtime/JSPropertyNameEnumerator.cpp:
        (JSC::JSPropertyNameEnumerator::destroy):
        * runtime/JSSegmentedVariableObject.h:
        * runtime/SymbolTable.cpp:
        (JSC::SymbolTable::destroy):
        * runtime/VM.h:
        * wasm/js/JSWebAssemblyCallee.cpp:
        (JSC::JSWebAssemblyCallee::destroy):
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::destroy):
        * wasm/js/WebAssemblyToJSCallee.cpp:
        (JSC::WebAssemblyToJSCallee::WebAssemblyToJSCallee):
        (JSC::WebAssemblyToJSCallee::destroy):

2017-01-17  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, roll out http://trac.webkit.org/changeset/210821
        It was causing crashes.

        * API/JSAPIWrapperObject.mm:
        (JSAPIWrapperObjectHandleOwner::finalize):
        * API/JSCallbackObject.h:
        * API/JSCallbackObjectFunctions.h:
        (JSC::JSCallbackObject<Parent>::~JSCallbackObject):
        (JSC::JSCallbackObject<Parent>::init):
        * API/JSObjectRef.cpp:
        (JSObjectGetPrivate):
        (JSObjectSetPrivate):
        (classInfoPrivate): Deleted.
        * bytecode/EvalCodeBlock.cpp:
        (JSC::EvalCodeBlock::destroy):
        * bytecode/FunctionCodeBlock.cpp:
        (JSC::FunctionCodeBlock::destroy):
        * bytecode/ModuleProgramCodeBlock.cpp:
        (JSC::ModuleProgramCodeBlock::destroy):
        * bytecode/ProgramCodeBlock.cpp:
        (JSC::ProgramCodeBlock::destroy):
        * bytecode/UnlinkedEvalCodeBlock.cpp:
        (JSC::UnlinkedEvalCodeBlock::destroy):
        * bytecode/UnlinkedFunctionCodeBlock.cpp:
        (JSC::UnlinkedFunctionCodeBlock::destroy):
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::destroy):
        * bytecode/UnlinkedModuleProgramCodeBlock.cpp:
        (JSC::UnlinkedModuleProgramCodeBlock::destroy):
        * bytecode/UnlinkedProgramCodeBlock.cpp:
        (JSC::UnlinkedProgramCodeBlock::destroy):
        * heap/CodeBlockSet.cpp:
        (JSC::CodeBlockSet::lastChanceToFinalize):
        (JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::allocateSlowCaseImpl):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::Handle::sweep):
        * jit/JITThunks.cpp:
        (JSC::JITThunks::finalize):
        * runtime/AbstractModuleRecord.cpp:
        (JSC::AbstractModuleRecord::destroy):
        * runtime/ExecutableBase.cpp:
        (JSC::ExecutableBase::clearCode):
        * runtime/JSCellInlines.h:
        (JSC::JSCell::classInfo):
        (JSC::JSCell::callDestructor):
        * runtime/JSLock.h:
        (JSC::JSLock::exclusiveThread):
        (JSC::JSLock::ownerThread): Deleted.
        * runtime/JSModuleNamespaceObject.cpp:
        (JSC::JSModuleNamespaceObject::destroy):
        * runtime/JSModuleRecord.cpp:
        (JSC::JSModuleRecord::destroy):
        * runtime/JSPropertyNameEnumerator.cpp:
        (JSC::JSPropertyNameEnumerator::destroy):
        * runtime/JSSegmentedVariableObject.h:
        * runtime/SymbolTable.cpp:
        (JSC::SymbolTable::destroy):
        * runtime/VM.h:
        * wasm/js/JSWebAssemblyCallee.cpp:
        (JSC::JSWebAssemblyCallee::destroy):
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::destroy):
        * wasm/js/WebAssemblyToJSCallee.cpp:
        (JSC::WebAssemblyToJSCallee::WebAssemblyToJSCallee):
        (JSC::WebAssemblyToJSCallee::destroy):

2017-01-16  Filip Pizlo  <fpizlo@apple.com>

        JSCell::classInfo() shouldn't have a bunch of mitigations for being called during destruction
        https://bugs.webkit.org/show_bug.cgi?id=167066

        Reviewed by Keith Miller and Michael Saboff.
        
        This reduces the size of JSCell::classInfo() by half and removes some checks that
        this function previously had to do in case it was called from destructors.
        
        I changed all of the destructors so that they don't call JSCell::classInfo() and I
        added an assertion to JSCell::classInfo() to catch cases where someone called it
        from a destructor accidentally.
        
        This means that we only have one place in destruction that needs to know the class:
        the sweeper's call to the destructor.
        
        One of the trickiest outcomes of this is the need to support inherits() tests in
        JSObjectGetPrivate(), when it is called from the destructor callback on the object
        being destructed. JSObjectGetPrivate() is undefined behavior anyway if you use it
        on any dead-but-not-destructed object other than the one being destructed right
        now. The purpose of the inherits() tests is to distinguish between different kinds
        of CallbackObjects, which may have different kinds of base classes. I think that
        this was always subtly wrong - for example, if the object being destructed is a
        JSGlobalObject then it's not a DestructibleObject, is not in a destructor block,
        but does not have an immortal Structure - so classInfo() is not valid. This fixes
        the issue by having ~JSCallbackObject know its classInfo. It now stashes its
        classInfo in VM so that JSObjectGetPrivate can use that classInfo if it detects
        that it's being used on a currently-destructing object.
        
        That was the only really weird part of this patch. The rest is mostly removing
        illegal uses of jsCast<> in destructors. There were a few other genuine uses of
        classInfo() but they were in code that already knew how to get its classInfo()
        using other means:
        
        - You can still say structure()->classInfo(), and I use this form in code that
          knows that its StructureIsImmortal.
        
        - You can use this->classInfo() if it's overridden, like in subclasses of
          JSDestructibleObject.

        * API/JSAPIWrapperObject.mm:
        (JSAPIWrapperObjectHandleOwner::finalize):
        * API/JSCallbackObject.h:
        * API/JSCallbackObjectFunctions.h:
        (JSC::JSCallbackObject<Parent>::~JSCallbackObject):
        (JSC::JSCallbackObject<Parent>::init):
        * API/JSObjectRef.cpp:
        (classInfoPrivate):
        (JSObjectGetPrivate):
        (JSObjectSetPrivate):
        * bytecode/EvalCodeBlock.cpp:
        (JSC::EvalCodeBlock::destroy):
        * bytecode/FunctionCodeBlock.cpp:
        (JSC::FunctionCodeBlock::destroy):
        * bytecode/ModuleProgramCodeBlock.cpp:
        (JSC::ModuleProgramCodeBlock::destroy):
        * bytecode/ProgramCodeBlock.cpp:
        (JSC::ProgramCodeBlock::destroy):
        * bytecode/UnlinkedEvalCodeBlock.cpp:
        (JSC::UnlinkedEvalCodeBlock::destroy):
        * bytecode/UnlinkedFunctionCodeBlock.cpp:
        (JSC::UnlinkedFunctionCodeBlock::destroy):
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::destroy):
        * bytecode/UnlinkedModuleProgramCodeBlock.cpp:
        (JSC::UnlinkedModuleProgramCodeBlock::destroy):
        * bytecode/UnlinkedProgramCodeBlock.cpp:
        (JSC::UnlinkedProgramCodeBlock::destroy):
        * heap/CodeBlockSet.cpp:
        (JSC::CodeBlockSet::lastChanceToFinalize):
        (JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::allocateSlowCaseImpl):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::Handle::sweep):
        * jit/JITThunks.cpp:
        (JSC::JITThunks::finalize):
        * runtime/AbstractModuleRecord.cpp:
        (JSC::AbstractModuleRecord::destroy):
        * runtime/ExecutableBase.cpp:
        (JSC::ExecutableBase::clearCode):
        * runtime/JSCellInlines.h:
        (JSC::JSCell::classInfo):
        (JSC::JSCell::callDestructor):
        * runtime/JSLock.h:
        (JSC::JSLock::ownerThread):
        * runtime/JSModuleNamespaceObject.cpp:
        (JSC::JSModuleNamespaceObject::destroy):
        * runtime/JSModuleRecord.cpp:
        (JSC::JSModuleRecord::destroy):
        * runtime/JSPropertyNameEnumerator.cpp:
        (JSC::JSPropertyNameEnumerator::destroy):
        * runtime/JSSegmentedVariableObject.h:
        * runtime/SymbolTable.cpp:
        (JSC::SymbolTable::destroy):
        * runtime/VM.h:
        * wasm/js/JSWebAssemblyCallee.cpp:
        (JSC::JSWebAssemblyCallee::destroy):
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::destroy):
        * wasm/js/WebAssemblyToJSCallee.cpp:
        (JSC::WebAssemblyToJSCallee::WebAssemblyToJSCallee):
        (JSC::WebAssemblyToJSCallee::destroy):

2017-01-16  Joseph Pecoraro  <pecoraro@apple.com>

        Remove the REQUEST_ANIMATION_FRAME flag
        https://bugs.webkit.org/show_bug.cgi?id=156980
        <rdar://problem/25906849>

        Reviewed by Simon Fraser.

        * Configurations/FeatureDefines.xcconfig:

2017-01-14  Yusuke Suzuki  <utatane.tea@gmail.com>

        WebAssembly: Suppress warnings & errors in GCC
        https://bugs.webkit.org/show_bug.cgi?id=167049

        Reviewed by Sam Weinig.

        * wasm/WasmFunctionParser.h:
        Add missing { } after the switch. Ideally, it is not necessary.
        But in GCC, it is required. Since this function is fairly large,
        I think the code generated by this does not cause performance
        regression.

        * wasm/WasmPageCount.h:
        UINT_MAX is defined in limits.h.

        * wasm/generateWasmValidateInlinesHeader.py:
        On the other hand, we use this suppress pragma here to solve the
        same problem in wasm/WasmFunctionParser.h. Since the load function
        is fairly small, the additional `return { };` may generate some
        suboptimal code. See bug 150794 for more detail.

2017-01-14  Yusuke Suzuki  <utatane.tea@gmail.com>

        Reserve capacity for StringBuilder in unescape
        https://bugs.webkit.org/show_bug.cgi?id=167008

        Reviewed by Sam Weinig.

        `unescape` function is frequently called in Kraken sha256-iterative.
        This patch just reserves the capacity for the StringBuilder.

        Currently, we select the length of the string for the reserved capacity.
        It improves the performance 2.73%.

            Benchmark report for Kraken on sakura-trick.

            VMs tested:
            "baseline" at /home/yusukesuzuki/dev/WebKit/WebKitBuild/untot/Release/bin/jsc
            "patched" at /home/yusukesuzuki/dev/WebKit/WebKitBuild/un/Release/bin/jsc

            Collected 100 samples per benchmark/VM, with 100 VM invocations per benchmark. Emitted a call to gc() between
            sample measurements. Used 1 benchmark iteration per VM invocation for warm-up. Used the jsc-specific preciseTime()
            function to get microsecond-level timing. Reporting benchmark execution times with 95% confidence intervals in
            milliseconds.

                                                       baseline                  patched

            stanford-crypto-sha256-iterative        51.609+-0.672             50.237+-0.860           might be 1.0273x faster

            <arithmetic>                            51.609+-0.672             50.237+-0.860           might be 1.0273x faster

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

2017-01-13  Joseph Pecoraro  <pecoraro@apple.com>

        Remove ENABLE(DETAILS_ELEMENT) guards
        https://bugs.webkit.org/show_bug.cgi?id=167042

        Reviewed by Alex Christensen.

        * Configurations/FeatureDefines.xcconfig:

2017-01-11  Darin Adler  <darin@apple.com>

        Remove PassRefPtr from more of "platform"
        https://bugs.webkit.org/show_bug.cgi?id=166809

        Reviewed by Sam Weinig.

        * inspector/JSInjectedScriptHost.h:
        (Inspector::JSInjectedScriptHost::impl): Simplified code since we don't need a
        const_cast here any more.
        * runtime/PrivateName.h:
        (JSC::PrivateName::uid): Ditto.

2017-01-13  Ryan Haddad  <ryanhaddad@apple.com>

        Unreviewed, rolling out r210735.

        This change introduced LayoutTest and JSC test flakiness.

        Reverted changeset:

        "Reserve capacity for StringBuilder in unescape"
        https://bugs.webkit.org/show_bug.cgi?id=167008
        http://trac.webkit.org/changeset/210735

2017-01-13  Saam Barati  <sbarati@apple.com>

        Initialize the ArraySpecies watchpoint as Clear and transition to IsWatched once slice is called for the first time
        https://bugs.webkit.org/show_bug.cgi?id=167017
        <rdar://problem/30019309>

        Reviewed by Keith Miller and Filip Pizlo.

        This patch is to reverse the JSBench regression from r210695.
        
        The new state diagram for the array species watchpoint is as
        follows:
        
        1. On GlobalObject construction, it starts life out as ClearWatchpoint.
        2. When slice is called for the first time, we observe the state
        of the world, and either transition it to IsWatched if we were able
        to set up the object property conditions, or to IsInvalidated if we
        were not.
        3. The DFG compiler will now only lower slice as an intrinsic if
        it observed the speciesWatchpoint.state() as IsWatched.
        4. The IsWatched => IsInvalidated transition happens only when
        one of the object property condition watchpoints fire.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * runtime/ArrayPrototype.cpp:
        (JSC::speciesWatchpointIsValid):
        (JSC::speciesConstructArray):
        (JSC::arrayProtoPrivateFuncConcatMemcpy):
        (JSC::ArrayPrototype::tryInitializeSpeciesWatchpoint):
        (JSC::ArrayPrototype::initializeSpeciesWatchpoint): Deleted.
        * runtime/ArrayPrototype.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::JSGlobalObject):
        (JSC::JSGlobalObject::init):

2017-01-13  Yusuke Suzuki  <utatane.tea@gmail.com>

        Reserve capacity for StringBuilder in unescape
        https://bugs.webkit.org/show_bug.cgi?id=167008

        Reviewed by Sam Weinig.

        `unescape` function is frequently called in Kraken sha256-iterative.
        This patch just reserves the capacity for the StringBuilder.

        Currently, we select the length of the string for the reserved capacity.
        It improves the performance 2.73%.

            Benchmark report for Kraken on sakura-trick.

            VMs tested:
            "baseline" at /home/yusukesuzuki/dev/WebKit/WebKitBuild/untot/Release/bin/jsc
            "patched" at /home/yusukesuzuki/dev/WebKit/WebKitBuild/un/Release/bin/jsc

            Collected 100 samples per benchmark/VM, with 100 VM invocations per benchmark. Emitted a call to gc() between
            sample measurements. Used 1 benchmark iteration per VM invocation for warm-up. Used the jsc-specific preciseTime()
            function to get microsecond-level timing. Reporting benchmark execution times with 95% confidence intervals in
            milliseconds.

                                                       baseline                  patched

            stanford-crypto-sha256-iterative        51.609+-0.672             50.237+-0.860           might be 1.0273x faster

            <arithmetic>                            51.609+-0.672             50.237+-0.860           might be 1.0273x faster

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

2017-01-12  Saam Barati  <sbarati@apple.com>

        Add a slice intrinsic to the DFG/FTL
        https://bugs.webkit.org/show_bug.cgi?id=166707
        <rdar://problem/29913445>

        Reviewed by Filip Pizlo.

        The gist of this patch is to inline Array.prototype.slice
        into the DFG/FTL. The implementation in the DFG-backend
        and FTLLowerDFGToB3 is just a straight forward implementation
        of what the C function is doing. The more interesting bits
        of this patch are setting up the proper watchpoints and conditions
        in the executing code to prove that its safe to skip all of the
        observable JS actions that Array.prototype.slice normally does.
        
        We perform the following proofs:
        1. Array.prototype.constructor has not changed (via a watchpoint).
        2. That Array.prototype.constructor[Symbol.species] has not changed (via a watchpoint).
        3. The global object is not having a bad time.
        4. The array that is being sliced has an original array structure.
        5. Array.prototype/Object.prototype have not transitioned.
        
        Conditions 1, 2, and 3 are strictly required.
        
        4 is ensuring a couple things:
        1. That a "constructor" property hasn't been added to the array
        we're slicing since we're supposed to perform a Get(array, "constructor").
        2. That we're not slicing an instance of a subclass of Array.
        
        We could relax 4.1 in the future if we find other ways to test if
        the incoming array hasn't changed the "constructor" property. We
        would probably use TryGetById to do this.
        
        I'm seeing a 5% speedup on crypto-pbkdf2 and often a 1% speedup on
        the total benchmark (the results are sometimes noisy).

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
        (JSC::DFG::CallArrayAllocatorWithVariableStructureVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableStructureVariableSizeSlowPathGenerator):
        * 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::compileArraySlice):
        (JSC::DFG::SpeculativeJIT::emitAllocateButterfly):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::emitInitializeButterfly):
        (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::emitInitializeButterfly):
        (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileArraySlice):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize):
        (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
        (JSC::FTL::DFG::LowerDFGToB3::initializeArrayElements):
        (JSC::FTL::DFG::LowerDFGToB3::storeStructure):
        (JSC::FTL::DFG::LowerDFGToB3::allocateCell):
        (JSC::FTL::DFG::LowerDFGToB3::allocateObject):
        (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
        (JSC::FTL::DFG::LowerDFGToB3::allocateUninitializedContiguousJSArray):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::emitLoadStructure):
        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation):
        (JSC::speciesWatchpointIsValid):
        (JSC::speciesConstructArray):
        (JSC::arrayProtoFuncSlice):
        (JSC::arrayProtoPrivateFuncConcatMemcpy):
        (JSC::ArrayPrototype::initializeSpeciesWatchpoint):
        (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::handleFire):
        (JSC::speciesWatchpointsValid): Deleted.
        (JSC::ArrayPrototype::attemptToInitializeSpeciesWatchpoint): Deleted.
        * runtime/ArrayPrototype.h:
        (JSC::ArrayPrototype::speciesWatchpointStatus): Deleted.
        (): Deleted.
        * runtime/Intrinsic.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::JSGlobalObject):
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::arraySpeciesWatchpoint):
        * runtime/Structure.h:

2017-01-12  Saam Barati  <sbarati@apple.com>

        Concurrent GC has a bug where we would detect a race but fail to rescan the object
        https://bugs.webkit.org/show_bug.cgi?id=166960
        <rdar://problem/29983526>

        Reviewed by Filip Pizlo and Mark Lam.

        We have code like this in JSC:
        
        ```
        Butterfly* butterfly = allocateMoreOutOfLineStorage(vm, oldOutOfLineCapacity, newOutOfLineCapacity);
        nukeStructureAndSetButterfly(vm, structureID, butterfly);
        structure->setLastOffset(newLastOffset);
        WTF::storeStoreFence();
        setStructureIDDirectly(structureID);
        ```
        
        Note that the collector could detect a race here, which sometimes
        incorrectly caused us to not visit the object again.
        
        Mutator Thread: M, Collector Thread: C, assuming sequential consistency via
        proper barriers:
        
        M: allocate new butterfly
        M: Set nuked structure ID
        M: Set butterfly (this does a barrier)
        C: Start scanning O
        C: load structure ID
        C: See it's nuked and bail, (we used to rely on a write barrier to rescan).
        
        We sometimes never rescanned here because we were calling
        setStructureIDDirectly which doesn't do a write barrier.
        (Note, the places that do this but call setStructure were
        OK because setStructure will perform a write barrier.)
        
        (This same issue also existed in places where the collector thread
        detected races for Structure::m_offset, but places that changed
        Structure::m_offset didn't perform a write barrier on the object
        after changing its Structure's m_offset.)
        
        To prevent such code from requiring every call site to perform
        a write barrier on the object, I've changed the collector code
        to keep a stack of cells to be revisited due to races. This stack
        is then consulted when we do marking. Because such races are rare,
        we have a single stack on Heap that is guarded by a lock.

        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::~Heap):
        (JSC::Heap::markToFixpoint):
        (JSC::Heap::endMarking):
        (JSC::Heap::buildConstraintSet):
        (JSC::Heap::addToRaceMarkStack):
        * heap/Heap.h:
        (JSC::Heap::collectorSlotVisitor):
        (JSC::Heap::mutatorMarkStack): Deleted.
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::didRace):
        * heap/SlotVisitor.h:
        (JSC::SlotVisitor::didRace):
        (JSC::SlotVisitor::didNotRace): Deleted.
        * heap/SlotVisitorInlines.h:
        (JSC::SlotVisitor::didNotRace): Deleted.
        * runtime/JSObject.cpp:
        (JSC::JSObject::visitButterfly):
        (JSC::JSObject::visitButterflyImpl):
        * runtime/JSObjectInlines.h:
        (JSC::JSObject::prepareToPutDirectWithoutTransition):
        * runtime/Structure.cpp:
        (JSC::Structure::flattenDictionaryStructure):

2017-01-12  Chris Dumez  <cdumez@apple.com>

        Add KEYBOARD_KEY_ATTRIBUTE / KEYBOARD_CODE_ATTRIBUTE to FeatureDefines.xcconfig
        https://bugs.webkit.org/show_bug.cgi?id=166995

        Reviewed by Jer Noble.

        Add KEYBOARD_KEY_ATTRIBUTE / KEYBOARD_CODE_ATTRIBUTE to FeatureDefines.xcconfig
        as some people are having trouble building without it.

        * Configurations/FeatureDefines.xcconfig:

2017-01-12  Yusuke Suzuki  <utatane.tea@gmail.com>

        Implement InlineClassicScript
        https://bugs.webkit.org/show_bug.cgi?id=166925

        Reviewed by Ryosuke Niwa.

        Add ScriptFetcher field for SourceOrigin.

        * runtime/SourceOrigin.h:
        (JSC::SourceOrigin::SourceOrigin):
        (JSC::SourceOrigin::fetcher):

2017-01-11  Andreas Kling  <akling@apple.com>

        Crash when WebCore's GC heap grows way too large.
        <https://webkit.org/b/166875>
        <rdar://problem/27896585>

        Reviewed by Mark Lam.

        Add a simple API to JSC::Heap that allows setting a hard limit on the amount
        of live bytes. If this is exceeded, we crash with a recognizable signature.
        By default there is no limit.

        * heap/Heap.cpp:
        (JSC::Heap::didExceedMaxLiveSize):
        (JSC::Heap::updateAllocationLimits):
        * heap/Heap.h:
        (JSC::Heap::setMaxLiveSize):

2017-01-11  Yusuke Suzuki  <utatane.tea@gmail.com>

        Decouple module loading initiator from ScriptElement
        https://bugs.webkit.org/show_bug.cgi?id=166888

        Reviewed by Saam Barati and Ryosuke Niwa.

        Add ScriptFetcher and JSScriptFetcher.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/ModuleLoaderPrototype.js:
        (requestFetch):
        (requestInstantiate):
        (requestSatisfy):
        (requestInstantiateAll):
        (requestLink):
        (moduleEvaluation):
        (loadAndEvaluateModule):
        (importModule):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LowLevelInterpreter.asm:
        * runtime/Completion.cpp:
        (JSC::loadAndEvaluateModule):
        (JSC::loadModule):
        (JSC::linkAndEvaluateModule):
        * runtime/Completion.h:
        * runtime/JSModuleLoader.cpp:
        (JSC::JSModuleLoader::loadAndEvaluateModule):
        (JSC::JSModuleLoader::loadModule):
        (JSC::JSModuleLoader::linkAndEvaluateModule):
        (JSC::JSModuleLoader::resolve):
        (JSC::JSModuleLoader::fetch):
        (JSC::JSModuleLoader::instantiate):
        (JSC::JSModuleLoader::evaluate):
        * runtime/JSModuleLoader.h:
        * runtime/JSScriptFetcher.cpp: Copied from Source/WebCore/dom/LoadableScript.cpp.
        (JSC::JSScriptFetcher::destroy):
        * runtime/JSScriptFetcher.h: Added.
        (JSC::JSScriptFetcher::createStructure):
        (JSC::JSScriptFetcher::create):
        (JSC::JSScriptFetcher::fetcher):
        (JSC::JSScriptFetcher::JSScriptFetcher):
        * runtime/JSType.h:
        * runtime/ScriptFetcher.h: Copied from Source/WebCore/dom/LoadableScript.cpp.
        (JSC::ScriptFetcher::~ScriptFetcher):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2017-01-10  Yusuke Suzuki  <utatane.tea@gmail.com>

        Implement JSSourceCode to propagate SourceCode in module pipeline
        https://bugs.webkit.org/show_bug.cgi?id=166861

        Reviewed by Saam Barati.

        Instead of propagating source code string, we propagate JSSourceCode
        cell in the module pipeline. This allows us to attach a metadata
        to the propagated source code string. In particular, it propagates
        SourceOrigin through the module pipeline.

        And it also fixes JSC shell to use Module source type for module source code.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/ModuleLoaderPrototype.js:
        (fulfillFetch):
        (requestFetch):
        * jsc.cpp:
        (GlobalObject::moduleLoaderFetch):
        (runWithScripts):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LowLevelInterpreter.asm:
        * runtime/Completion.cpp:
        (JSC::loadAndEvaluateModule):
        (JSC::loadModule):
        * runtime/JSModuleLoader.cpp:
        (JSC::JSModuleLoader::provide):
        * runtime/JSModuleLoader.h:
        * runtime/JSSourceCode.cpp: Added.
        (JSC::JSSourceCode::destroy):
        * runtime/JSSourceCode.h: Added.
        (JSC::JSSourceCode::createStructure):
        (JSC::JSSourceCode::create):
        (JSC::JSSourceCode::sourceCode):
        (JSC::JSSourceCode::JSSourceCode):
        * runtime/JSType.h:
        * runtime/ModuleLoaderPrototype.cpp:
        (JSC::moduleLoaderPrototypeParseModule):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2017-01-10  Commit Queue  <commit-queue@webkit.org>

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

        "breaks web compatability" (Requested by keith_miller on
        #webkit).

        Reverted changeset:

        "Add support for global"
        https://bugs.webkit.org/show_bug.cgi?id=165171
        http://trac.webkit.org/changeset/210052

2017-01-10  Sam Weinig  <sam@webkit.org>

        [WebIDL] Remove most of the custom bindings for the WebGL code
        https://bugs.webkit.org/show_bug.cgi?id=166834

        Reviewed by Alex Christensen.

        * runtime/ArrayPrototype.h:
        * runtime/ObjectPrototype.h:
        Export the ClassInfo so it can be used from WebCore.

2017-01-09  Filip Pizlo  <fpizlo@apple.com>

        Streamline the GC barrier slowpath
        https://bugs.webkit.org/show_bug.cgi?id=166878

        Reviewed by Geoffrey Garen and Saam Barati.
        
        This implements two optimizations to the barrier:
        
        - Removes the write barrier buffer. This was just overhead.
        
        - Teaches the slow path how to white an object that was black but unmarked, ensuring that
          we don't take slow path for this object again.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileStoreBarrier):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::emitStoreBarrier):
        * heap/CellState.h:
        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::markToFixpoint):
        (JSC::Heap::addToRememberedSet):
        (JSC::Heap::stopTheWorld):
        (JSC::Heap::writeBarrierSlowPath):
        (JSC::Heap::buildConstraintSet):
        (JSC::Heap::flushWriteBarrierBuffer): Deleted.
        * heap/Heap.h:
        (JSC::Heap::writeBarrierBuffer): Deleted.
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::appendJSCellOrAuxiliary):
        (JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
        (JSC::SlotVisitor::appendToMarkStack):
        (JSC::SlotVisitor::visitChildren):
        * heap/WriteBarrierBuffer.cpp: Removed.
        * heap/WriteBarrierBuffer.h: Removed.
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * runtime/JSCellInlines.h:
        (JSC::JSCell::JSCell):
        * runtime/StructureIDBlob.h:
        (JSC::StructureIDBlob::StructureIDBlob):

2017-01-10  Mark Lam  <mark.lam@apple.com>

        Property setters should not be called for bound arguments list entries.
        https://bugs.webkit.org/show_bug.cgi?id=165631

        Reviewed by Filip Pizlo.

        * builtins/FunctionPrototype.js:
        (bind):
        - use @putByValDirect to set the bound arguments so that we don't consult the
          prototype chain for setters.

        * runtime/IntlDateTimeFormatPrototype.cpp:
        (JSC::IntlDateTimeFormatPrototypeGetterFormat):
        * runtime/IntlNumberFormatPrototype.cpp:
        (JSC::IntlNumberFormatPrototypeGetterFormat):
        - no need to create a bound arguments array because these bound functions binds
          no arguments according to the spec.

2017-01-10  Skachkov Oleksandr  <gskachkov@gmail.com>

        Calling async arrow function which is in a class's member function will cause error
        https://bugs.webkit.org/show_bug.cgi?id=166879

        Reviewed by Saam Barati.

        Current patch fixed loading 'super' in async arrow function. Errored appear becuase 
        super was loaded always nevertherless if it used in async arrow function or not, but bytecompiler
        put to arrow function context only if it used within arrow function. So to fix this issue we need to 
        check if super was used in arrow function. 

        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::FunctionNode::emitBytecode):

2017-01-10  Commit Queue  <commit-queue@webkit.org>

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

        This change introduced JSC test failures (Requested by
        ryanhaddad on #webkit).

        Reverted changeset:

        "Implement JSSourceCode to propagate SourceCode in module
        pipeline"
        https://bugs.webkit.org/show_bug.cgi?id=166861
        http://trac.webkit.org/changeset/210537

2017-01-10  Commit Queue  <commit-queue@webkit.org>

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

        too crude for non-WebCore clients (Requested by kling on
        #webkit).

        Reverted changeset:

        "Crash when GC heap grows way too large."
        https://bugs.webkit.org/show_bug.cgi?id=166875
        http://trac.webkit.org/changeset/210540

2017-01-09  Filip Pizlo  <fpizlo@apple.com>

        JSArray has some object scanning races
        https://bugs.webkit.org/show_bug.cgi?id=166874

        Reviewed by Mark Lam.
        
        This fixes two separate bugs, both of which I detected by running
        array-splice-contiguous.js in extreme anger:
        
        1) Some of the paths of shifting and unshifting were not grabbing the internal cell
           lock. This was causing the array storage scan to crash, even though it was well
           synchronized (the scan does hold the lock). The fix is just to hold the lock anywhere
           that memmoves the innards of the butterfly.
        
        2) Out of line property scanning was synchronized using double collect snapshot. Array
           storage scanning was synchronized using locks. But what if array storage
           transformations messed up the out of line properties? It turns out that we actually
           need to hoist the array storage scanner's locking up into the double collect
           snapshot.
        
        I don't know how to write a test that does any better of a job of catching this than
        array-splice-contiguous.js.

        * heap/DeferGC.h: Make DisallowGC usable even if NDEBUG.
        * runtime/JSArray.cpp:
        (JSC::JSArray::unshiftCountSlowCase):
        (JSC::JSArray::shiftCountWithArrayStorage):
        (JSC::JSArray::unshiftCountWithArrayStorage):
        * runtime/JSObject.cpp:
        (JSC::JSObject::visitButterflyImpl):

2017-01-10  Andreas Kling  <akling@apple.com>

        Crash when GC heap grows way too large.
        <https://webkit.org/b/166875>
        <rdar://problem/27896585>

        Reviewed by Mark Lam.

        Hard cap the JavaScript heap at 4GB of live objects (determined post-GC.)
        If we go past this limit, crash with a recognizable signature.

        * heap/Heap.cpp:
        (JSC::Heap::didExceedHeapSizeLimit):
        (JSC::Heap::updateAllocationLimits):

2017-01-09  Yusuke Suzuki  <utatane.tea@gmail.com>

        Implement JSSourceCode to propagate SourceCode in module pipeline
        https://bugs.webkit.org/show_bug.cgi?id=166861

        Reviewed by Saam Barati.

        Instead of propagating source code string, we propagate JSSourceCode
        cell in the module pipeline. This allows us to attach a metadata
        to the propagated source code string. In particular, it propagates
        SourceOrigin through the module pipeline.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/ModuleLoaderPrototype.js:
        (fulfillFetch):
        (requestFetch):
        * jsc.cpp:
        (GlobalObject::moduleLoaderFetch):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LowLevelInterpreter.asm:
        * runtime/Completion.cpp:
        (JSC::loadAndEvaluateModule):
        (JSC::loadModule):
        * runtime/JSModuleLoader.cpp:
        (JSC::JSModuleLoader::provide):
        * runtime/JSModuleLoader.h:
        * runtime/JSSourceCode.cpp: Added.
        (JSC::JSSourceCode::destroy):
        * runtime/JSSourceCode.h: Added.
        (JSC::JSSourceCode::createStructure):
        (JSC::JSSourceCode::create):
        (JSC::JSSourceCode::sourceCode):
        (JSC::JSSourceCode::JSSourceCode):
        * runtime/JSType.h:
        * runtime/ModuleLoaderPrototype.cpp:
        (JSC::moduleLoaderPrototypeParseModule):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2017-01-09  Yusuke Suzuki  <utatane.tea@gmail.com>

        REGRESSION (r210522): ASSERTION FAILED: divot.offset >= divotStart.offset seen with stress/import-basic.js and stress/import-from-eval.js
        https://bugs.webkit.org/show_bug.cgi?id=166873

        Reviewed by Saam Barati.

        The divot should be the end of `import` token.

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

2017-01-09  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix cloop.

        * dfg/DFGPlanInlines.h:

2017-01-09  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Prototype dynamic-import
        https://bugs.webkit.org/show_bug.cgi?id=165724

        Reviewed by Saam Barati.

        In this patch, we implement stage3 dynamic-import proposal[1].
        This patch adds a new special operator `import`. And by using it, we can import
        the module dynamically from modules and scripts. Before this feature, the module
        is always imported statically and before executing the modules, importing the modules
        needs to be done. And especially, the module can only be imported from the module.
        So the classic script cannot import and use the modules. This dynamic-import relaxes
        the above restrictions.

        The typical dynamic-import form is the following.

            import("...").then(function (namespace) { ... });

        You can pass any AssignmentExpression for the import operator. So you can determine
        the importing modules dynamically.

            import(value).then(function (namespace) { ... });

        And previously the module import declaration is only allowed in the top level statements.
        But this import operator is just an expression. So you can use it in the function.
        And you can use it conditionally.

            async function go(cond)
            {
                if (cond)
                    return import("...");
                return undefined;
            }
            await go(true);

        Currently, this patch just implements this feature only for the JSC shell.
        JSC module loader requires a new hook, `importModule`. And the JSC shell implements
        this hook. So, for now, this dynamic-import is not available in the browser side.
        If you write this `import` call, it always returns the rejected promise.

        import is implemented like a special operator similar to `super`.
        This is because import is context-sensitive. If you call the `import`, the module
        key resolution is done based on the caller's running context.

        For example, if you are running the script which filename is "./ok/hello.js", the module
        key for the call`import("./resource/syntax.js")` becomes `"./ok/resource/syntax.js"`.
        But if you write the completely same import form in the script "./error/hello.js", the
        key becomes "./error/resource/syntax.js". So exposing this feature as the `import`
        function is misleading: this function becomes caller's context-sensitive. That's why
        dynamic-import is specified as a special operator.

        To resolve the module key, we need the caller's context information like the filename of
        the caller. This is provided by the SourceOrigin implemented in r210149.
        In the JSC shell implementation, this SourceOrigin holds the filename of the caller. So
        based on this implementation, the module loader resolve the module key.
        In the near future, we will extend this SourceOrigin to hold more information needed for
        the browser-side import implementation.

        [1]: https://tc39.github.io/proposal-dynamic-import/

        * builtins/ModuleLoaderPrototype.js:
        (importModule):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitGetTemplateObject):
        (JSC::BytecodeGenerator::emitGetGlobalPrivate):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ImportNode::emitBytecode):
        * jsc.cpp:
        (absolutePath):
        (GlobalObject::moduleLoaderImportModule):
        (functionRun):
        (functionLoad):
        (functionCheckSyntax):
        (runWithScripts):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createImportExpr):
        * parser/NodeConstructors.h:
        (JSC::ImportNode::ImportNode):
        * parser/Nodes.h:
        (JSC::ExpressionNode::isImportNode):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseMemberExpression):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createImportExpr):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObject.h:
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncImportModule):
        * runtime/JSGlobalObjectFunctions.h:
        * runtime/JSModuleLoader.cpp:
        (JSC::JSModuleLoader::importModule):
        (JSC::JSModuleLoader::getModuleNamespaceObject):
        * runtime/JSModuleLoader.h:
        * runtime/ModuleLoaderPrototype.cpp:
        (JSC::moduleLoaderPrototypeGetModuleNamespaceObject):

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

        Make the collector's fixpoint smart about scheduling work
        https://bugs.webkit.org/show_bug.cgi?id=165910

        Reviewed by Keith Miller.
        
        Prior to this change, every time the GC would run any constraints in markToFixpoint, it
        would run all of the constraints. It would always run them in the same order. That means
        that so long as any one constraint was generating new work, we'd pay the price of all
        constraints. This is usually OK because most constraints are cheap but it artificially
        inflates the cost of slow constraints - especially ones that are expensive but usually
        generate no new work.
        
        This patch redoes how the GC runs constraints by applying ideas from data flow analysis.
        The GC now builds a MarkingConstraintSet when it boots up, and this contains all of the
        constraints as well as some meta-data about them. Now, markToFixpoint just calls into
        MarkingConstraintSet to execute constraints. Because constraint execution and scheduling
        need to be aware of each other, I rewrote markToFixpoint in such a way that it's more
        obvious how the GC goes between constraint solving, marking with stopped mutator, and
        marking with resumed mutator. This also changes the scheduler API in such a way that a
        synchronous stop-the-world collection no longer needs to do fake stop/resume - instead we
        just swap the space-time scheduler for the stop-the-world scheduler.
        
        This is a big streamlining of the GC. This is a speed-up in GC-heavy tests because we
        now execute most constraints exactly twice regardless of how many total fixpoint
        iterations we do. Now, when we run out of marking work, the constraint solver will just
        run the constraint that is most likely to generate new visiting work, and if it does
        generate work, then the GC now goes back to marking. Before, it would run *all*
        constraints and then go back to marking. The constraint solver is armed with three
        information signals that it uses to sort the constraints in order of descending likelihood
        to generate new marking work. Then it runs them in that order until it there is new
        marking work. The signals are:
        
        1) Whether the constraint is greyed by marking or execution. We call this the volatility
           of the constraint. For example, weak reference constraints have GreyedByMarking as
           their volatility because they are most likely to have something to say after we've done
           some marking. On the other hand, conservative roots have GreyedByExecution as their
           volatility because they will give new information anytime we let the mutator run. The
           constraint solver will only run GreyedByExecution constraints as roots and after the
           GreyedByMarking constraints go silent. This ensures that we don't try to scan
           conservative roots every time we need to re-run weak references and vice-versa.
           
           Another way to look at it is that the constraint solver tries to predict if the
           wavefront is advancing or retreating. The wavefront is almost certainly advancing so
           long as the mark stacks are non-empty or so long as at least one of the GreyedByMarking
           constraints is still producing work. Otherwise the wavefront is almost certainly
           retreating. It's most profitable to run GreyedByMarking constraints when the wavefront
           is advancing, and most profitable to run GreyedByExecution constraints when the
           wavefront is retreating.
           
           We use the predicted wavefront direction and the volatility of constraints as a
           first-order signal of constraint profitability.
        
        2) How much visiting work was created the last time the constraint ran. The solver
           remembers the lastVisitCount, and uses it to predict how much work the constraint will
           generate next time. In practice this means we will keep re-running the one interesting
           constraint until it shuts up.
        
        3) Optional work predictors for some constraints. The constraint that shuffles the mutator
           mark stack into the main SlotVisitor's mutator mark stack always knows exactly how much
           work it will create.
           
           The sum of (2) and (3) are used as a second-order signal of constraint profitability.
        
        The constraint solver will always run all of the GreyedByExecution constraints at GC
        start, since these double as the GC's roots. The constraint solver will always run all of
        the GreyedByMarking constraints the first time that marking stalls. Other than that, the
        solver will keep running constraints, sorted according to their likelihood to create work,
        until either work is created or we run out of constraints to run. GC termination happens
        when we run out of constraints to run.
        
        This new infrastructure means that we have a much better chance of dealing with worst-case
        DOM pathologies. If we can intelligently factor different evil DOM things into different
        constraints with the right work predictions then this could reduce the cost of those DOM
        things by a factor of N where N is the number of fixpoint iterations the GC typically
        does. N is usually around 5-6 even for simple heaps.
        
        My perf measurements say:
        
        PLT3: 0.02% faster with 5.3% confidence.
        JetStream: 0.15% faster with 17% confidence.
        Speedometer: 0.58% faster with 82% confidence.
        
        Here are the details from JetStream:
        
        splay: 1.02173x faster with 0.996841 confidence
        splay-latency: 1.0617x faster with 0.987462 confidence
        towers.c: 1.01852x faster with 0.92128 confidence
        crypto-md5: 1.06058x faster with 0.482363 confidence
        score: 1.00152x faster with 0.16892 confidence
        
        I think that Speedometer is legitimately benefiting from this change based on looking at
        --logGC=true output. We are now spending less time reexecuting expensive constraints. I
        think that JetStream/splay is also benefiting, because although the constraints it sees
        are cheap, it spends 30% of its time in GC so even small improvements matter.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::markCodeBlocks): Deleted.
        (JSC::DFG::Plan::rememberCodeBlocks): Deleted.
        * dfg/DFGPlan.h:
        * dfg/DFGPlanInlines.h: Added.
        (JSC::DFG::Plan::iterateCodeBlocksForGC):
        * dfg/DFGWorklist.cpp:
        (JSC::DFG::Worklist::markCodeBlocks): Deleted.
        (JSC::DFG::Worklist::rememberCodeBlocks): Deleted.
        (JSC::DFG::rememberCodeBlocks): Deleted.
        * dfg/DFGWorklist.h:
        * dfg/DFGWorklistInlines.h: Added.
        (JSC::DFG::iterateCodeBlocksForGC):
        (JSC::DFG::Worklist::iterateCodeBlocksForGC):
        * heap/CodeBlockSet.cpp:
        (JSC::CodeBlockSet::writeBarrierCurrentlyExecuting): Deleted.
        * heap/CodeBlockSet.h:
        (JSC::CodeBlockSet::iterate): Deleted.
        * heap/CodeBlockSetInlines.h:
        (JSC::CodeBlockSet::iterate):
        (JSC::CodeBlockSet::iterateCurrentlyExecuting):
        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::iterateExecutingAndCompilingCodeBlocks):
        (JSC::Heap::iterateExecutingAndCompilingCodeBlocksWithoutHoldingLocks):
        (JSC::Heap::assertSharedMarkStacksEmpty):
        (JSC::Heap::markToFixpoint):
        (JSC::Heap::endMarking):
        (JSC::Heap::collectInThread):
        (JSC::Heap::stopIfNecessarySlow):
        (JSC::Heap::acquireAccessSlow):
        (JSC::Heap::collectIfNecessaryOrDefer):
        (JSC::Heap::buildConstraintSet):
        (JSC::Heap::notifyIsSafeToCollect):
        (JSC::Heap::ResumeTheWorldScope::ResumeTheWorldScope): Deleted.
        (JSC::Heap::ResumeTheWorldScope::~ResumeTheWorldScope): Deleted.
        (JSC::Heap::harvestWeakReferences): Deleted.
        (JSC::Heap::visitConservativeRoots): Deleted.
        (JSC::Heap::visitCompilerWorklistWeakReferences): Deleted.
        * heap/Heap.h:
        * heap/MarkingConstraint.cpp: Added.
        (JSC::MarkingConstraint::MarkingConstraint):
        (JSC::MarkingConstraint::~MarkingConstraint):
        (JSC::MarkingConstraint::resetStats):
        (JSC::MarkingConstraint::execute):
        * heap/MarkingConstraint.h: Added.
        (JSC::MarkingConstraint::index):
        (JSC::MarkingConstraint::abbreviatedName):
        (JSC::MarkingConstraint::name):
        (JSC::MarkingConstraint::lastVisitCount):
        (JSC::MarkingConstraint::quickWorkEstimate):
        (JSC::MarkingConstraint::workEstimate):
        (JSC::MarkingConstraint::volatility):
        * heap/MarkingConstraintSet.cpp: Added.
        (JSC::MarkingConstraintSet::ExecutionContext::ExecutionContext):
        (JSC::MarkingConstraintSet::ExecutionContext::didVisitSomething):
        (JSC::MarkingConstraintSet::ExecutionContext::shouldTimeOut):
        (JSC::MarkingConstraintSet::ExecutionContext::drain):
        (JSC::MarkingConstraintSet::ExecutionContext::didExecute):
        (JSC::MarkingConstraintSet::ExecutionContext::execute):
        (JSC::MarkingConstraintSet::MarkingConstraintSet):
        (JSC::MarkingConstraintSet::~MarkingConstraintSet):
        (JSC::MarkingConstraintSet::resetStats):
        (JSC::MarkingConstraintSet::add):
        (JSC::MarkingConstraintSet::executeBootstrap):
        (JSC::MarkingConstraintSet::executeConvergence):
        (JSC::MarkingConstraintSet::isWavefrontAdvancing):
        (JSC::MarkingConstraintSet::executeConvergenceImpl):
        (JSC::MarkingConstraintSet::executeAll):
        * heap/MarkingConstraintSet.h: Added.
        (JSC::MarkingConstraintSet::isWavefrontRetreating):
        * heap/MutatorScheduler.cpp: Added.
        (JSC::MutatorScheduler::MutatorScheduler):
        (JSC::MutatorScheduler::~MutatorScheduler):
        (JSC::MutatorScheduler::didStop):
        (JSC::MutatorScheduler::willResume):
        (JSC::MutatorScheduler::didExecuteConstraints):
        (JSC::MutatorScheduler::log):
        (JSC::MutatorScheduler::shouldStop):
        (JSC::MutatorScheduler::shouldResume):
        * heap/MutatorScheduler.h: Added.
        * heap/OpaqueRootSet.h:
        (JSC::OpaqueRootSet::add):
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::visitAsConstraint):
        (JSC::SlotVisitor::drain):
        (JSC::SlotVisitor::didReachTermination):
        (JSC::SlotVisitor::hasWork):
        (JSC::SlotVisitor::drainFromShared):
        (JSC::SlotVisitor::drainInParallelPassively):
        (JSC::SlotVisitor::addOpaqueRoot):
        * heap/SlotVisitor.h:
        (JSC::SlotVisitor::addToVisitCount):
        * heap/SpaceTimeMutatorScheduler.cpp: Copied from Source/JavaScriptCore/heap/SpaceTimeScheduler.cpp.
        (JSC::SpaceTimeMutatorScheduler::Snapshot::Snapshot):
        (JSC::SpaceTimeMutatorScheduler::Snapshot::now):
        (JSC::SpaceTimeMutatorScheduler::Snapshot::bytesAllocatedThisCycle):
        (JSC::SpaceTimeMutatorScheduler::SpaceTimeMutatorScheduler):
        (JSC::SpaceTimeMutatorScheduler::~SpaceTimeMutatorScheduler):
        (JSC::SpaceTimeMutatorScheduler::state):
        (JSC::SpaceTimeMutatorScheduler::beginCollection):
        (JSC::SpaceTimeMutatorScheduler::didStop):
        (JSC::SpaceTimeMutatorScheduler::willResume):
        (JSC::SpaceTimeMutatorScheduler::didExecuteConstraints):
        (JSC::SpaceTimeMutatorScheduler::timeToStop):
        (JSC::SpaceTimeMutatorScheduler::timeToResume):
        (JSC::SpaceTimeMutatorScheduler::log):
        (JSC::SpaceTimeMutatorScheduler::endCollection):
        (JSC::SpaceTimeMutatorScheduler::bytesAllocatedThisCycleImpl):
        (JSC::SpaceTimeMutatorScheduler::bytesSinceBeginningOfCycle):
        (JSC::SpaceTimeMutatorScheduler::maxHeadroom):
        (JSC::SpaceTimeMutatorScheduler::headroomFullness):
        (JSC::SpaceTimeMutatorScheduler::mutatorUtilization):
        (JSC::SpaceTimeMutatorScheduler::collectorUtilization):
        (JSC::SpaceTimeMutatorScheduler::elapsedInPeriod):
        (JSC::SpaceTimeMutatorScheduler::phase):
        (JSC::SpaceTimeMutatorScheduler::shouldBeResumed):
        (JSC::SpaceTimeScheduler::Decision::targetMutatorUtilization): Deleted.
        (JSC::SpaceTimeScheduler::Decision::targetCollectorUtilization): Deleted.
        (JSC::SpaceTimeScheduler::Decision::elapsedInPeriod): Deleted.
        (JSC::SpaceTimeScheduler::Decision::phase): Deleted.
        (JSC::SpaceTimeScheduler::Decision::shouldBeResumed): Deleted.
        (JSC::SpaceTimeScheduler::Decision::timeToResume): Deleted.
        (JSC::SpaceTimeScheduler::Decision::timeToStop): Deleted.
        (JSC::SpaceTimeScheduler::SpaceTimeScheduler): Deleted.
        (JSC::SpaceTimeScheduler::snapPhase): Deleted.
        (JSC::SpaceTimeScheduler::currentDecision): Deleted.
        * heap/SpaceTimeMutatorScheduler.h: Copied from Source/JavaScriptCore/heap/SpaceTimeScheduler.h.
        (JSC::SpaceTimeScheduler::Decision::operator bool): Deleted.
        * heap/SpaceTimeScheduler.cpp: Removed.
        * heap/SpaceTimeScheduler.h: Removed.
        * heap/SynchronousStopTheWorldMutatorScheduler.cpp: Added.
        (JSC::SynchronousStopTheWorldMutatorScheduler::SynchronousStopTheWorldMutatorScheduler):
        (JSC::SynchronousStopTheWorldMutatorScheduler::~SynchronousStopTheWorldMutatorScheduler):
        (JSC::SynchronousStopTheWorldMutatorScheduler::state):
        (JSC::SynchronousStopTheWorldMutatorScheduler::beginCollection):
        (JSC::SynchronousStopTheWorldMutatorScheduler::timeToStop):
        (JSC::SynchronousStopTheWorldMutatorScheduler::timeToResume):
        (JSC::SynchronousStopTheWorldMutatorScheduler::endCollection):
        * heap/SynchronousStopTheWorldMutatorScheduler.h: Added.
        * heap/VisitingTimeout.h: Added.
        (JSC::VisitingTimeout::VisitingTimeout):
        (JSC::VisitingTimeout::visitCount):
        (JSC::VisitingTimeout::didVisitSomething):
        (JSC::VisitingTimeout::shouldTimeOut):
        * runtime/Options.h:

2017-01-09  Commit Queue  <commit-queue@webkit.org>

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

        "4% JSBench regression" (Requested by keith_mi_ on #webkit).

        Reverted changeset:

        "Add a slice intrinsic to the DFG/FTL"
        https://bugs.webkit.org/show_bug.cgi?id=166707
        http://trac.webkit.org/changeset/210476

2017-01-08  Andreas Kling  <akling@apple.com>

        Inject MarkedSpace size classes for a few more high-volume objects.
        <https://webkit.org/b/166815>

        Reviewed by Darin Adler.

        Add the following classes to the list of manually injected size classes:

            - JSString
            - JSFunction
            - PropertyTable
            - Structure

        Only Structure actually ends up with a new size class, the others already
        can't get any tighter due to the current MarkedBlock::atomSize being 16.
        I've put them in anyway to ensure that we have optimally carved-out cells
        for them in the future, should they grow.

        With this change, Structures get allocated in 128-byte cells instead of
        160-byte cells, giving us 25% more Structures per MarkedBlock.

        * heap/MarkedSpace.cpp:

2017-01-06  Saam Barati  <sbarati@apple.com>

        Add a slice intrinsic to the DFG/FTL
        https://bugs.webkit.org/show_bug.cgi?id=166707

        Reviewed by Filip Pizlo.

        The gist of this patch is to inline Array.prototype.slice
        into the DFG/FTL. The implementation in the DFG-backend
        and FTLLowerDFGToB3 is just a straight forward implementation
        of what the C function is doing. The more interesting bits
        of this patch are setting up the proper watchpoints and conditions
        in the executing code to prove that its safe to skip all of the
        observable JS actions that Array.prototype.slice normally does.
        
        We perform the following proofs:
        1. Array.prototype.constructor has not changed (via a watchpoint).
        2. That Array.prototype.constructor[Symbol.species] has not changed (via a watchpoint).
        3. The global object is not having a bad time.
        3. The array that is being sliced has an original array structure.
        5. Array.prototype/Object.prototype have not transitioned.
        
        Conditions 1, 2, and 3 are strictly required.
        
        4 is ensuring a couple things:
        1. That a "constructor" property hasn't been added to the array
        we're slicing since we're supposed to perform a Get(array, "constructor").
        2. That we're not slicing an instance of a subclass of Array.
        
        We could relax 4.1 in the future if we find other ways to test if
        the incoming array hasn't changed the "constructor" property.
        
        I'm seeing a 5% speedup on crypto-pbkdf2 and often a 1% speedup on
        the total benchmark (the results are sometimes noisy).

        * bytecode/ExitKind.cpp:
        (JSC::exitKindToString):
        * bytecode/ExitKind.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/DFGNode.h:
        (JSC::DFG::Node::hasHeapPrediction):
        (JSC::DFG::Node::hasArrayMode):
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArraySlice):
        * 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::compileArraySlice):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::emitLoadStructure):
        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation):
        (JSC::speciesWatchpointIsValid):
        (JSC::speciesConstructArray):
        (JSC::arrayProtoFuncSlice):
        (JSC::arrayProtoPrivateFuncConcatMemcpy):
        (JSC::ArrayPrototype::initializeSpeciesWatchpoint):
        (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::handleFire):
        (JSC::speciesWatchpointsValid): Deleted.
        (JSC::ArrayPrototype::attemptToInitializeSpeciesWatchpoint): Deleted.
        * runtime/ArrayPrototype.h:
        (JSC::ArrayPrototype::speciesWatchpointStatus): Deleted.
        (): Deleted.
        * runtime/Intrinsic.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::JSGlobalObject):
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::arraySpeciesWatchpoint):

2017-01-06  Mark Lam  <mark.lam@apple.com>

        The ObjC API's JSVirtualMachine's map tables need to be guarded by a lock.
        https://bugs.webkit.org/show_bug.cgi?id=166778
        <rdar://problem/29761198>

        Reviewed by Filip Pizlo.

        Now that we have a concurrent GC, access to JSVirtualMachine's
        m_externalObjectGraph and m_externalRememberedSet need to be guarded by a lock
        since both the GC marker thread and the mutator thread may access them at the
        same time.

        * API/JSVirtualMachine.mm:
        (-[JSVirtualMachine addExternalRememberedObject:]):
        (-[JSVirtualMachine addManagedReference:withOwner:]):
        (-[JSVirtualMachine removeManagedReference:withOwner:]):
        (-[JSVirtualMachine externalDataMutex]):
        (scanExternalObjectGraph):
        (scanExternalRememberedSet):

        * API/JSVirtualMachineInternal.h:
        - Deleted externalObjectGraph method.  There's no need to expose this.

2017-01-06  Michael Saboff  <msaboff@apple.com>

        @putByValDirect in Array.of and Array.from overwrites non-writable/configurable properties
        https://bugs.webkit.org/show_bug.cgi?id=153486

        Reviewed by Saam Barati.

        Moved read only check in putDirect() to all paths.

        * runtime/SparseArrayValueMap.cpp:
        (JSC::SparseArrayValueMap::putDirect):

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

        DeferGC::~DeferGC should be super cheap
        https://bugs.webkit.org/show_bug.cgi?id=166626

        Reviewed by Saam Barati.
        
        Right now, ~DeferGC requires running the collector's full collectIfNecessaryOrDefer()
        hook, which is super big. Normally, that hook would only be called from GC slow paths,
        so it ought to be possible to add complex logic to it. It benefits the GC algorithm to
        make that code smart, not necessarily fast.

        The right thing for it to do is to have ~DeferGC check a boolean to see if
        collectIfNecessaryOrDefer() had previously deferred anything, and only call it if that
        is true. That's what this patch does.
        
        Unfortunately, this means that we lose the collectAccordingToDeferGCProbability mode,
        which we used for two tests. Since I could only see two tests that used this mode, I
        felt that it was better to enhance the GC than to keep the tests. I filed bug 166627 to
        bring back something like that mode.
        
        Although this patch does make some paths faster, its real goal is to ensure that bug
        165963 can add more logic to collectIfNecessaryOrDefer() without introducing a big
        regression. Until then, I wouldn't be surprised if this patch was a progression, but I'm
        not betting on it.

        * heap/Heap.cpp:
        (JSC::Heap::collectIfNecessaryOrDefer):
        (JSC::Heap::decrementDeferralDepthAndGCIfNeededSlow):
        (JSC::Heap::canCollect): Deleted.
        (JSC::Heap::shouldCollectHeuristic): Deleted.
        (JSC::Heap::shouldCollect): Deleted.
        (JSC::Heap::collectAccordingToDeferGCProbability): Deleted.
        (JSC::Heap::decrementDeferralDepthAndGCIfNeeded): Deleted.
        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::incrementDeferralDepth):
        (JSC::Heap::decrementDeferralDepth):
        (JSC::Heap::decrementDeferralDepthAndGCIfNeeded):
        (JSC::Heap::mayNeedToStop):
        (JSC::Heap::stopIfNecessary):
        * runtime/Options.h:

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

        AutomaticThread timeout shutdown leaves a small window where notify() would think that the thread is still running
        https://bugs.webkit.org/show_bug.cgi?id=166742

        Reviewed by Geoffrey Garen.
        
        Update to new AutomaticThread API.

        * dfg/DFGWorklist.cpp:

2017-01-05  Per Arne Vollan  <pvollan@apple.com>

        [Win] Compile error.
        https://bugs.webkit.org/show_bug.cgi?id=166726

        Reviewed by Alex Christensen.

        Add include folder.

        * CMakeLists.txt:

2016-12-21  Brian Burg  <bburg@apple.com>

        Web Inspector: teach the protocol generator about platform-specific types, events, and commands
        https://bugs.webkit.org/show_bug.cgi?id=166003
        <rdar://problem/28718990>

        Reviewed by Joseph Pecoraro.

        This patch implements parser, model, and generator-side changes to account for
        platform-specific types, events, and commands. The 'platform' property is parsed
        for top-level definitions and assumed to be the 'generic' platform if none is specified.

        Since the generator's platform setting acts to filter definitions with an incompatible platform,
        all generators must be modified to consult a list of filtered types/commands/events for
        a domain instead of directly accessing Domain.{type_declarations, commands, events}. To prevent
        accidental misuse, hide those fields behind accessors (e.g., `all_type_declarations()`) so that they
        are still accessible if truly necessary, but not used by default and caused an error if not migrated.

        * inspector/scripts/codegen/generate_cpp_alternate_backend_dispatcher_header.py:
        (CppAlternateBackendDispatcherHeaderGenerator._generate_handler_declarations_for_domain):
        * inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py:
        (CppBackendDispatcherHeaderGenerator.domains_to_generate):
        (CppBackendDispatcherHeaderGenerator._generate_handler_declarations_for_domain):
        (CppBackendDispatcherHeaderGenerator._generate_dispatcher_declarations_for_domain):
        * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
        (CppBackendDispatcherImplementationGenerator.domains_to_generate):
        (CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementations_for_domain):
        (CppBackendDispatcherImplementationGenerator._generate_small_dispatcher_switch_implementation_for_domain):
        (CppBackendDispatcherImplementationGenerator._generate_large_dispatcher_switch_implementation_for_domain):
        * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_header.py:
        (CppFrontendDispatcherHeaderGenerator.domains_to_generate):
        (CppFrontendDispatcherHeaderGenerator._generate_dispatcher_declarations_for_domain):
        * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
        (CppFrontendDispatcherImplementationGenerator.domains_to_generate):
        (CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementations_for_domain):
        * inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
        (CppProtocolTypesHeaderGenerator._generate_forward_declarations):
        (_generate_typedefs_for_domain):
        (_generate_builders_for_domain):
        (_generate_forward_declarations_for_binding_traits):
        (_generate_declarations_for_enum_conversion_methods):
        * inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py:
        (CppProtocolTypesImplementationGenerator._generate_enum_conversion_methods_for_domain):
        (CppProtocolTypesImplementationGenerator._generate_open_field_names):
        (CppProtocolTypesImplementationGenerator._generate_builders_for_domain):
        * inspector/scripts/codegen/generate_js_backend_commands.py:
        (JSBackendCommandsGenerator.should_generate_domain):
        (JSBackendCommandsGenerator.domains_to_generate):
        (JSBackendCommandsGenerator.generate_domain):
        (JSBackendCommandsGenerator.domains_to_generate.should_generate_domain): Deleted.
        * inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py:
        (ObjCBackendDispatcherHeaderGenerator.domains_to_generate):
        (ObjCBackendDispatcherHeaderGenerator._generate_objc_forward_declarations):
        (ObjCBackendDispatcherHeaderGenerator._generate_objc_handler_declarations_for_domain):
        * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
        (ObjCBackendDispatcherImplementationGenerator):
        (ObjCBackendDispatcherImplementationGenerator.domains_to_generate):
        (ObjCBackendDispatcherImplementationGenerator._generate_handler_implementation_for_domain):
        (ObjCConfigurationImplementationGenerator): Deleted.
        (ObjCConfigurationImplementationGenerator.__init__): Deleted.
        (ObjCConfigurationImplementationGenerator.output_filename): Deleted.
        (ObjCConfigurationImplementationGenerator.domains_to_generate): Deleted.
        (ObjCConfigurationImplementationGenerator.generate_output): Deleted.
        (ObjCConfigurationImplementationGenerator._generate_handler_implementation_for_domain): Deleted.
        (ObjCConfigurationImplementationGenerator._generate_handler_implementation_for_command): Deleted.
        (ObjCConfigurationImplementationGenerator._generate_success_block_for_command): Deleted.
        (ObjCConfigurationImplementationGenerator._generate_success_block_for_command.and): Deleted.
        (ObjCConfigurationImplementationGenerator._generate_conversions_for_command): Deleted.
        (ObjCConfigurationImplementationGenerator._generate_conversions_for_command.in_param_expression): Deleted.
        (ObjCConfigurationImplementationGenerator._generate_invocation_for_command): Deleted.
        * inspector/scripts/codegen/generate_objc_configuration_header.py:
        (ObjCConfigurationHeaderGenerator.generate_output):
        (ObjCConfigurationHeaderGenerator._generate_properties_for_domain):
        * inspector/scripts/codegen/generate_objc_configuration_implementation.py:
        (ObjCConfigurationImplementationGenerator):
        (ObjCConfigurationImplementationGenerator.generate_output):
        (ObjCConfigurationImplementationGenerator._generate_configuration_implementation_for_domains):
        (ObjCConfigurationImplementationGenerator._generate_ivars):
        (ObjCConfigurationImplementationGenerator._generate_dealloc):
        (ObjCBackendDispatcherImplementationGenerator): Deleted.
        (ObjCBackendDispatcherImplementationGenerator.__init__): Deleted.
        (ObjCBackendDispatcherImplementationGenerator.output_filename): Deleted.
        (ObjCBackendDispatcherImplementationGenerator.generate_output): Deleted.
        (ObjCBackendDispatcherImplementationGenerator._generate_configuration_implementation_for_domains): Deleted.
        (ObjCBackendDispatcherImplementationGenerator._generate_ivars): Deleted.
        (ObjCBackendDispatcherImplementationGenerator._generate_dealloc): Deleted.
        (ObjCBackendDispatcherImplementationGenerator._generate_handler_setter_for_domain): Deleted.
        (ObjCBackendDispatcherImplementationGenerator._generate_event_dispatcher_getter_for_domain): Deleted.
        (ObjCBackendDispatcherImplementationGenerator._variable_name_prefix_for_domain): Deleted.
        * inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
        (ObjCFrontendDispatcherImplementationGenerator.domains_to_generate):
        (ObjCFrontendDispatcherImplementationGenerator._generate_event_dispatcher_implementations):
        * inspector/scripts/codegen/generate_objc_header.py:
        (ObjCHeaderGenerator.generate_output):
        (ObjCHeaderGenerator._generate_forward_declarations):
        (ObjCHeaderGenerator._generate_enums):
        (ObjCHeaderGenerator._generate_types):
        (ObjCHeaderGenerator._generate_command_protocols):
        (ObjCHeaderGenerator._generate_event_interfaces):
        * inspector/scripts/codegen/generate_objc_internal_header.py:
        (ObjCInternalHeaderGenerator.generate_output):
        (ObjCInternalHeaderGenerator._generate_event_dispatcher_private_interfaces):
        * inspector/scripts/codegen/generate_objc_protocol_type_conversions_header.py:
        (ObjCProtocolTypeConversionsHeaderGenerator.domains_to_generate):
        (ObjCProtocolTypeConversionsHeaderGenerator._generate_enum_conversion_functions):
        * inspector/scripts/codegen/generate_objc_protocol_type_conversions_implementation.py:
        (ObjCProtocolTypeConversionsImplementationGenerator.domains_to_generate):
        (ObjCProtocolTypeConversionsImplementationGenerator._generate_type_factory_category_interface):
        (ObjCProtocolTypeConversionsImplementationGenerator._generate_type_factory_category_implementation):
        * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
        (ObjCProtocolTypesImplementationGenerator.domains_to_generate):
        (ObjCProtocolTypesImplementationGenerator.generate_type_implementations):

        * inspector/scripts/codegen/generator.py:
        (Generator.can_generate_platform):
        (Generator):
        (Generator.type_declarations_for_domain):
        (Generator.commands_for_domain):
        (Generator.events_for_domain):
        These are the core methods for computing whether a definition can be used given a target platform.

        (Generator.calculate_types_requiring_shape_assertions):
        (Generator._traverse_and_assign_enum_values):
        * inspector/scripts/codegen/models.py:
        (Protocol.parse_type_declaration):
        (Protocol.parse_command):
        (Protocol.parse_event):
        (Protocol.resolve_types):

        (Domain.__init__):
        (Domain):
        (Domain.all_type_declarations):
        (Domain.all_commands):
        (Domain.all_events):
        Hide fields behind these accessors so it's really obvious when we are ignoring platform filtering.

        (Domain.resolve_type_references):
        (TypeDeclaration.__init__):
        (Command.__init__):
        (Event.__init__):
        * inspector/scripts/codegen/objc_generator.py:
        (ObjCGenerator.should_generate_types_for_domain):
        (ObjCGenerator):
        (ObjCGenerator.should_generate_commands_for_domain):
        (ObjCGenerator.should_generate_events_for_domain):
        (ObjCGenerator.should_generate_domain_types_filter): Deleted.
        (ObjCGenerator.should_generate_domain_types_filter.should_generate_domain_types): Deleted.
        (ObjCGenerator.should_generate_domain_command_handler_filter): Deleted.
        (ObjCGenerator.should_generate_domain_command_handler_filter.should_generate_domain_command_handler): Deleted.
        (ObjCGenerator.should_generate_domain_event_dispatcher_filter): Deleted.
        (ObjCGenerator.should_generate_domain_event_dispatcher_filter.should_generate_domain_event_dispatcher): Deleted.
        Clean up some messy code that essentially did the same definition filtering as we must do for platforms.
        This will be enhanced in a future patch so that platform filtering will take priority over the target framework.

        The results above need rebaselining because the class names for two generators were swapped by accident.
        Fixing the names causes the order of generated files to change, and this generates ugly diffs because every
        generated file includes the same copyright block at the top.

        * inspector/scripts/tests/generic/expected/commands-with-async-attribute.json-result:
        * inspector/scripts/tests/generic/expected/commands-with-optional-call-return-parameters.json-result:
        * inspector/scripts/tests/generic/expected/domains-with-varying-command-sizes.json-result:
        * inspector/scripts/tests/generic/expected/enum-values.json-result:
        * inspector/scripts/tests/generic/expected/events-with-optional-parameters.json-result:
        * inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result:
        * inspector/scripts/tests/generic/expected/same-type-id-different-domain.json-result:
        * inspector/scripts/tests/generic/expected/shadowed-optional-type-setters.json-result:
        * inspector/scripts/tests/generic/expected/type-declaration-aliased-primitive-type.json-result:
        * inspector/scripts/tests/generic/expected/type-declaration-array-type.json-result:
        * inspector/scripts/tests/generic/expected/type-declaration-enum-type.json-result:
        * inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result:
        * inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:

        * inspector/scripts/tests/generic/expected/fail-on-command-with-invalid-platform.json-error: Added.
        * inspector/scripts/tests/generic/expected/fail-on-type-with-invalid-platform.json-error: Added.
        * inspector/scripts/tests/generic/fail-on-command-with-invalid-platform.json: Added.
        * inspector/scripts/tests/generic/fail-on-type-with-invalid-platform.json: Added.

        Add error test cases for invalid platforms in commands, types, and events.

        * inspector/scripts/tests/generic/definitions-with-mac-platform.json: Added.
        * inspector/scripts/tests/generic/expected/definitions-with-mac-platform.json-result: Added.
        * inspector/scripts/tests/all/definitions-with-mac-platform.json: Added.
        * inspector/scripts/tests/all/expected/definitions-with-mac-platform.json-result: Added.
        * inspector/scripts/tests/ios/definitions-with-mac-platform.json: Added.
        * inspector/scripts/tests/ios/expected/definitions-with-mac-platform.json-result: Added.
        * inspector/scripts/tests/mac/definitions-with-mac-platform.json: Added.
        * inspector/scripts/tests/mac/expected/definitions-with-mac-platform.json-result: Added.

        Add a basic 4-way test that generates code for each platform from the same specification.
        With 'macos' platform for each definition, only 'all' and 'mac' generate anything interesting.

2017-01-03  Brian Burg  <bburg@apple.com>

        Web Inspector: teach the protocol generator about platform-specific types, events, and commands
        https://bugs.webkit.org/show_bug.cgi?id=166003
        <rdar://problem/28718990>

        Reviewed by Joseph Pecoraro.

        This patch implements parser, model, and generator-side changes to account for
        platform-specific types, events, and commands. The 'platform' property is parsed
        for top-level definitions and assumed to be the 'generic' platform if none is specified.

        Since the generator's platform setting acts to filter definitions with an incompatible platform,
        all generators must be modified to consult a list of filtered types/commands/events for
        a domain instead of directly accessing Domain.{type_declarations, commands, events}. To prevent
        accidental misuse, hide those fields behind accessors (e.g., `all_type_declarations()`) so that they
        are still accessible if truly necessary, but not used by default and caused an error if not migrated.

        * inspector/scripts/codegen/generate_cpp_alternate_backend_dispatcher_header.py:
        (CppAlternateBackendDispatcherHeaderGenerator._generate_handler_declarations_for_domain):
        * inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py:
        (CppBackendDispatcherHeaderGenerator.domains_to_generate):
        (CppBackendDispatcherHeaderGenerator._generate_handler_declarations_for_domain):
        (CppBackendDispatcherHeaderGenerator._generate_dispatcher_declarations_for_domain):
        * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
        (CppBackendDispatcherImplementationGenerator.domains_to_generate):
        (CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementations_for_domain):
        (CppBackendDispatcherImplementationGenerator._generate_small_dispatcher_switch_implementation_for_domain):
        (CppBackendDispatcherImplementationGenerator._generate_large_dispatcher_switch_implementation_for_domain):
        * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_header.py:
        (CppFrontendDispatcherHeaderGenerator.domains_to_generate):
        (CppFrontendDispatcherHeaderGenerator._generate_dispatcher_declarations_for_domain):
        * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
        (CppFrontendDispatcherImplementationGenerator.domains_to_generate):
        (CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementations_for_domain):
        * inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
        (CppProtocolTypesHeaderGenerator._generate_forward_declarations):
        (_generate_typedefs_for_domain):
        (_generate_builders_for_domain):
        (_generate_forward_declarations_for_binding_traits):
        (_generate_declarations_for_enum_conversion_methods):
        * inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py:
        (CppProtocolTypesImplementationGenerator._generate_enum_conversion_methods_for_domain):
        (CppProtocolTypesImplementationGenerator._generate_open_field_names):
        (CppProtocolTypesImplementationGenerator._generate_builders_for_domain):
        * inspector/scripts/codegen/generate_js_backend_commands.py:
        (JSBackendCommandsGenerator.should_generate_domain):
        (JSBackendCommandsGenerator.domains_to_generate):
        (JSBackendCommandsGenerator.generate_domain):
        (JSBackendCommandsGenerator.domains_to_generate.should_generate_domain): Deleted.
        * inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py:
        (ObjCBackendDispatcherHeaderGenerator.domains_to_generate):
        (ObjCBackendDispatcherHeaderGenerator._generate_objc_forward_declarations):
        (ObjCBackendDispatcherHeaderGenerator._generate_objc_handler_declarations_for_domain):
        * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
        (ObjCBackendDispatcherImplementationGenerator):
        (ObjCBackendDispatcherImplementationGenerator.domains_to_generate):
        (ObjCBackendDispatcherImplementationGenerator._generate_handler_implementation_for_domain):
        (ObjCConfigurationImplementationGenerator): Deleted.
        (ObjCConfigurationImplementationGenerator.__init__): Deleted.
        (ObjCConfigurationImplementationGenerator.output_filename): Deleted.
        (ObjCConfigurationImplementationGenerator.domains_to_generate): Deleted.
        (ObjCConfigurationImplementationGenerator.generate_output): Deleted.
        (ObjCConfigurationImplementationGenerator._generate_handler_implementation_for_domain): Deleted.
        (ObjCConfigurationImplementationGenerator._generate_handler_implementation_for_command): Deleted.
        (ObjCConfigurationImplementationGenerator._generate_success_block_for_command): Deleted.
        (ObjCConfigurationImplementationGenerator._generate_success_block_for_command.and): Deleted.
        (ObjCConfigurationImplementationGenerator._generate_conversions_for_command): Deleted.
        (ObjCConfigurationImplementationGenerator._generate_conversions_for_command.in_param_expression): Deleted.
        (ObjCConfigurationImplementationGenerator._generate_invocation_for_command): Deleted.
        * inspector/scripts/codegen/generate_objc_configuration_header.py:
        (ObjCConfigurationHeaderGenerator.generate_output):
        (ObjCConfigurationHeaderGenerator._generate_properties_for_domain):
        * inspector/scripts/codegen/generate_objc_configuration_implementation.py:
        (ObjCConfigurationImplementationGenerator):
        (ObjCConfigurationImplementationGenerator.generate_output):
        (ObjCConfigurationImplementationGenerator._generate_configuration_implementation_for_domains):
        (ObjCConfigurationImplementationGenerator._generate_ivars):
        (ObjCConfigurationImplementationGenerator._generate_dealloc):
        (ObjCBackendDispatcherImplementationGenerator): Deleted.
        (ObjCBackendDispatcherImplementationGenerator.__init__): Deleted.
        (ObjCBackendDispatcherImplementationGenerator.output_filename): Deleted.
        (ObjCBackendDispatcherImplementationGenerator.generate_output): Deleted.
        (ObjCBackendDispatcherImplementationGenerator._generate_configuration_implementation_for_domains): Deleted.
        (ObjCBackendDispatcherImplementationGenerator._generate_ivars): Deleted.
        (ObjCBackendDispatcherImplementationGenerator._generate_dealloc): Deleted.
        (ObjCBackendDispatcherImplementationGenerator._generate_handler_setter_for_domain): Deleted.
        (ObjCBackendDispatcherImplementationGenerator._generate_event_dispatcher_getter_for_domain): Deleted.
        (ObjCBackendDispatcherImplementationGenerator._variable_name_prefix_for_domain): Deleted.
        * inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
        (ObjCFrontendDispatcherImplementationGenerator.domains_to_generate):
        (ObjCFrontendDispatcherImplementationGenerator._generate_event_dispatcher_implementations):
        * inspector/scripts/codegen/generate_objc_header.py:
        (ObjCHeaderGenerator.generate_output):
        (ObjCHeaderGenerator._generate_forward_declarations):
        (ObjCHeaderGenerator._generate_enums):
        (ObjCHeaderGenerator._generate_types):
        (ObjCHeaderGenerator._generate_command_protocols):
        (ObjCHeaderGenerator._generate_event_interfaces):
        * inspector/scripts/codegen/generate_objc_internal_header.py:
        (ObjCInternalHeaderGenerator.generate_output):
        (ObjCInternalHeaderGenerator._generate_event_dispatcher_private_interfaces):
        * inspector/scripts/codegen/generate_objc_protocol_type_conversions_header.py:
        (ObjCProtocolTypeConversionsHeaderGenerator.domains_to_generate):
        (ObjCProtocolTypeConversionsHeaderGenerator._generate_enum_conversion_functions):
        * inspector/scripts/codegen/generate_objc_protocol_type_conversions_implementation.py:
        (ObjCProtocolTypeConversionsImplementationGenerator.domains_to_generate):
        (ObjCProtocolTypeConversionsImplementationGenerator._generate_type_factory_category_interface):
        (ObjCProtocolTypeConversionsImplementationGenerator._generate_type_factory_category_implementation):
        * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
        (ObjCProtocolTypesImplementationGenerator.domains_to_generate):
        (ObjCProtocolTypesImplementationGenerator.generate_type_implementations):

        * inspector/scripts/codegen/generator.py:
        (Generator.can_generate_platform):
        (Generator):
        (Generator.type_declarations_for_domain):
        (Generator.commands_for_domain):
        (Generator.events_for_domain):
        These are the core methods for computing whether a definition can be used given a target platform.

        (Generator.calculate_types_requiring_shape_assertions):
        (Generator._traverse_and_assign_enum_values):
        * inspector/scripts/codegen/models.py:
        (Protocol.parse_type_declaration):
        (Protocol.parse_command):
        (Protocol.parse_event):
        (Protocol.resolve_types):

        (Domain.__init__):
        (Domain):
        (Domain.all_type_declarations):
        (Domain.all_commands):
        (Domain.all_events):
        Hide fields behind these accessors so it's really obvious when we are ignoring platform filtering.

        (Domain.resolve_type_references):
        (TypeDeclaration.__init__):
        (Command.__init__):
        (Event.__init__):
        * inspector/scripts/codegen/objc_generator.py:
        (ObjCGenerator.should_generate_types_for_domain):
        (ObjCGenerator):
        (ObjCGenerator.should_generate_commands_for_domain):
        (ObjCGenerator.should_generate_events_for_domain):
        (ObjCGenerator.should_generate_domain_types_filter): Deleted.
        (ObjCGenerator.should_generate_domain_types_filter.should_generate_domain_types): Deleted.
        (ObjCGenerator.should_generate_domain_command_handler_filter): Deleted.
        (ObjCGenerator.should_generate_domain_command_handler_filter.should_generate_domain_command_handler): Deleted.
        (ObjCGenerator.should_generate_domain_event_dispatcher_filter): Deleted.
        (ObjCGenerator.should_generate_domain_event_dispatcher_filter.should_generate_domain_event_dispatcher): Deleted.
        Clean up some messy code that essentially did the same definition filtering as we must do for platforms.
        This will be enhanced in a future patch so that platform filtering will take priority over the target framework.

        The following results need rebaselining because the class names for two generators were swapped by accident.
        Fixing the names causes the order of generated files to change, and this generates ugly diffs because every
        generated file includes the same copyright block at the top.

        * inspector/scripts/tests/generic/expected/commands-with-async-attribute.json-result:
        * inspector/scripts/tests/generic/expected/commands-with-optional-call-return-parameters.json-result:
        * inspector/scripts/tests/generic/expected/domains-with-varying-command-sizes.json-result:
        * inspector/scripts/tests/generic/expected/enum-values.json-result:
        * inspector/scripts/tests/generic/expected/events-with-optional-parameters.json-result:
        * inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result:
        * inspector/scripts/tests/generic/expected/same-type-id-different-domain.json-result:
        * inspector/scripts/tests/generic/expected/shadowed-optional-type-setters.json-result:
        * inspector/scripts/tests/generic/expected/type-declaration-aliased-primitive-type.json-result:
        * inspector/scripts/tests/generic/expected/type-declaration-array-type.json-result:
        * inspector/scripts/tests/generic/expected/type-declaration-enum-type.json-result:
        * inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result:
        * inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:

2017-01-03  Brian Burg  <bburg@apple.com>

        Web Inspector: teach the protocol generator about platform-specific types, events, and commands
        https://bugs.webkit.org/show_bug.cgi?id=166003
        <rdar://problem/28718990>

        Reviewed by Joseph Pecoraro.

        Make it possible to test inspector protocol generator output for different platforms.

        Move existing tests to the generic/ subdirectory, as they are to be generated
        without any specific platform. Later, platform-specific generator behavior will be
        tested by cloning the same test to multiple platform directories.

        * inspector/scripts/tests{/ => /generic/}commands-with-async-attribute.json
        * inspector/scripts/tests{/ => /generic/}commands-with-optional-call-return-parameters.json
        * inspector/scripts/tests{/ => /generic/}domains-with-varying-command-sizes.json
        * inspector/scripts/tests{/ => /generic/}enum-values.json
        * inspector/scripts/tests{/ => /generic/}events-with-optional-parameters.json
        * inspector/scripts/tests{/ => /generic/}expected/commands-with-async-attribute.json-result
        * inspector/scripts/tests{/ => /generic/}expected/commands-with-optional-call-return-parameters.json-result
        * inspector/scripts/tests{/ => /generic/}expected/domains-with-varying-command-sizes.json-result
        * inspector/scripts/tests{/ => /generic/}expected/enum-values.json-result
        * inspector/scripts/tests{/ => /generic/}expected/events-with-optional-parameters.json-result
        * inspector/scripts/tests{/ => /generic/}expected/fail-on-domain-availability.json-error
        * inspector/scripts/tests{/ => /generic/}expected/fail-on-duplicate-command-call-parameter-names.json-error
        * inspector/scripts/tests{/ => /generic/}expected/fail-on-duplicate-command-return-parameter-names.json-error
        * inspector/scripts/tests{/ => /generic/}expected/fail-on-duplicate-event-parameter-names.json-error
        * inspector/scripts/tests{/ => /generic/}expected/fail-on-duplicate-type-declarations.json-error
        * inspector/scripts/tests{/ => /generic/}expected/fail-on-duplicate-type-member-names.json-error
        * inspector/scripts/tests{/ => /generic/}expected/fail-on-enum-with-no-values.json-error
        * inspector/scripts/tests{/ => /generic/}expected/fail-on-number-typed-optional-parameter-flag.json-error
        * inspector/scripts/tests{/ => /generic/}expected/fail-on-number-typed-optional-type-member.json-error
        * inspector/scripts/tests{/ => /generic/}expected/fail-on-string-typed-optional-parameter-flag.json-error
        * inspector/scripts/tests{/ => /generic/}expected/fail-on-string-typed-optional-type-member.json-error
        * inspector/scripts/tests{/ => /generic/}expected/fail-on-type-declaration-using-type-reference.json-error
        * inspector/scripts/tests{/ => /generic/}expected/fail-on-type-reference-as-primitive-type.json-error
        * inspector/scripts/tests{/ => /generic/}expected/fail-on-type-with-lowercase-name.json-error
        * inspector/scripts/tests{/ => /generic/}expected/fail-on-unknown-type-reference-in-type-declaration.json-error
        * inspector/scripts/tests{/ => /generic/}expected/fail-on-unknown-type-reference-in-type-member.json-error
        * inspector/scripts/tests{/ => /generic/}expected/generate-domains-with-feature-guards.json-result
        * inspector/scripts/tests{/ => /generic/}expected/same-type-id-different-domain.json-result
        * inspector/scripts/tests{/ => /generic/}expected/shadowed-optional-type-setters.json-result
        * inspector/scripts/tests{/ => /generic/}expected/type-declaration-aliased-primitive-type.json-result
        * inspector/scripts/tests{/ => /generic/}expected/type-declaration-array-type.json-result
        * inspector/scripts/tests{/ => /generic/}expected/type-declaration-enum-type.json-result
        * inspector/scripts/tests{/ => /generic/}expected/type-declaration-object-type.json-result
        * inspector/scripts/tests{/ => /generic/}expected/type-requiring-runtime-casts.json-result
        * inspector/scripts/tests{/ => /generic/}fail-on-domain-availability.json
        * inspector/scripts/tests{/ => /generic/}fail-on-duplicate-command-call-parameter-names.json
        * inspector/scripts/tests{/ => /generic/}fail-on-duplicate-command-return-parameter-names.json
        * inspector/scripts/tests{/ => /generic/}fail-on-duplicate-event-parameter-names.json
        * inspector/scripts/tests{/ => /generic/}fail-on-duplicate-type-declarations.json
        * inspector/scripts/tests{/ => /generic/}fail-on-duplicate-type-member-names.json
        * inspector/scripts/tests{/ => /generic/}fail-on-enum-with-no-values.json
        * inspector/scripts/tests{/ => /generic/}fail-on-number-typed-optional-parameter-flag.json
        * inspector/scripts/tests{/ => /generic/}fail-on-number-typed-optional-type-member.json
        * inspector/scripts/tests{/ => /generic/}fail-on-string-typed-optional-parameter-flag.json
        * inspector/scripts/tests{/ => /generic/}fail-on-string-typed-optional-type-member.json
        * inspector/scripts/tests{/ => /generic/}fail-on-type-declaration-using-type-reference.json
        * inspector/scripts/tests{/ => /generic/}fail-on-type-reference-as-primitive-type.json
        * inspector/scripts/tests{/ => /generic/}fail-on-type-with-lowercase-name.json
        * inspector/scripts/tests{/ => /generic/}fail-on-unknown-type-reference-in-type-declaration.json
        * inspector/scripts/tests{/ => /generic/}fail-on-unknown-type-reference-in-type-member.json
        * inspector/scripts/tests{/ => /generic/}generate-domains-with-feature-guards.json
        * inspector/scripts/tests{/ => /generic/}same-type-id-different-domain.json
        * inspector/scripts/tests{/ => /generic/}shadowed-optional-type-setters.json
        * inspector/scripts/tests{/ => /generic/}type-declaration-aliased-primitive-type.json
        * inspector/scripts/tests{/ => /generic/}type-declaration-array-type.json
        * inspector/scripts/tests{/ => /generic/}type-declaration-enum-type.json
        * inspector/scripts/tests{/ => /generic/}type-declaration-object-type.json
        * inspector/scripts/tests{/ => /generic/}type-requiring-runtime-casts.json

2017-01-03  Brian Burg  <bburg@apple.com>

        Web Inspector: teach the protocol generator about platform-specific types, events, and commands
        https://bugs.webkit.org/show_bug.cgi?id=166003
        <rdar://problem/28718990>

        Reviewed by Joseph Pecoraro.

        Add a --platform argument to generate-inspector-protocol-bindings.py and propagate
        the specified platform to each generator. This will be used in the next few patches
        to exclude types, events, and commands that are unsupported by the backend platform.

        Covert all subclasses of Generator to pass along their positional arguments so that we
        can easily change base class arguments without editing all generator constructors.

        * inspector/scripts/codegen/cpp_generator.py:
        (CppGenerator.__init__):
        * inspector/scripts/codegen/generate_cpp_alternate_backend_dispatcher_header.py:
        (CppAlternateBackendDispatcherHeaderGenerator.__init__):
        * inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py:
        (CppBackendDispatcherHeaderGenerator.__init__):
        * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
        (CppBackendDispatcherImplementationGenerator.__init__):
        * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_header.py:
        (CppFrontendDispatcherHeaderGenerator.__init__):
        * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
        (CppFrontendDispatcherImplementationGenerator.__init__):
        * inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
        (CppProtocolTypesHeaderGenerator.__init__):
        * inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py:
        (CppProtocolTypesImplementationGenerator.__init__):
        * inspector/scripts/codegen/generate_js_backend_commands.py:
        (JSBackendCommandsGenerator.__init__):
        * inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py:
        (ObjCBackendDispatcherHeaderGenerator.__init__):
        * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
        (ObjCConfigurationImplementationGenerator.__init__):
        * inspector/scripts/codegen/generate_objc_configuration_header.py:
        (ObjCConfigurationHeaderGenerator.__init__):
        * inspector/scripts/codegen/generate_objc_configuration_implementation.py:
        (ObjCBackendDispatcherImplementationGenerator.__init__):
        * inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
        (ObjCFrontendDispatcherImplementationGenerator.__init__):
        * inspector/scripts/codegen/generate_objc_header.py:
        (ObjCHeaderGenerator.__init__):
        * inspector/scripts/codegen/generate_objc_internal_header.py:
        (ObjCInternalHeaderGenerator.__init__):
        * inspector/scripts/codegen/generate_objc_protocol_type_conversions_header.py:
        (ObjCProtocolTypeConversionsHeaderGenerator.__init__):
        * inspector/scripts/codegen/generate_objc_protocol_type_conversions_implementation.py:
        (ObjCProtocolTypeConversionsImplementationGenerator.__init__):
        * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
        (ObjCProtocolTypesImplementationGenerator.__init__):
        Pass along *args instead of single positional arguments.

        * inspector/scripts/codegen/generator.py:
        (Generator.__init__):
        Save the target platform and add a getter.

        * inspector/scripts/codegen/models.py:
        (Platform):
        (Platform.__init__):
        (Platform.fromString):
        (Platforms):
        Define the allowed Platform instances (iOS, macOS, and Any).

        * inspector/scripts/codegen/objc_generator.py:
        (ObjCGenerator.and.__init__):
        * inspector/scripts/generate-inspector-protocol-bindings.py:
        (generate_from_specification):
        Pass along *args instead of single positional arguments.

2017-01-04  JF Bastien  <jfbastien@apple.com>

        WebAssembly JS API: add Module.sections
        https://bugs.webkit.org/show_bug.cgi?id=165159
        <rdar://problem/29760326>

        Reviewed by Mark Lam.

        As described in: https://github.com/WebAssembly/design/blob/master/JS.md#webassemblymodulecustomsections

        This was added for Emscripten, and is likely to be used soon.

        * wasm/WasmFormat.h: custom sections are just name + bytes
        * wasm/WasmModuleParser.cpp: parse them, instead of skipping over
        * wasm/WasmModuleParser.h:
        * wasm/js/WebAssemblyModulePrototype.cpp: construct the Array of
        ArrayBuffer as described in the spec
        (JSC::webAssemblyModuleProtoCustomSections):

2017-01-04  Saam Barati  <sbarati@apple.com>

        We don't properly handle exceptions inside the nativeCallTrampoline macro in the LLInt
        https://bugs.webkit.org/show_bug.cgi?id=163720

        Reviewed by Mark Lam.

        In the LLInt, we were incorrectly doing the exception check after the call.
        Before the exception check, we were unwinding to our caller's
        frame under the assumption that our caller was always a JS frame.
        This is incorrect, however, because our caller might be a C frame.
        One way that it can be a C frame is when C calls to JS, and JS tail
        calls to native. This patch fixes this bug by doing unwinding from
        the native callee's frame instead of its callers.

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

2017-01-03  JF Bastien  <jfbastien@apple.com>

        REGRESSION (r210244): Release JSC Stress test failure: wasm.yaml/wasm/js-api/wasm-to-wasm.js.default-wasm
        https://bugs.webkit.org/show_bug.cgi?id=166669
        <rdar://problem/29856455>

        Reviewed by Saam Barati.

        Bug #165282 added wasm -> wasm calls, but caused crashes in
        release builds because the pinned registers are also callee-saved
        and were being clobbered. B3 didn't see itself clobbering them
        when no memory was used, and therefore omitted a restore.

        This was causing the C++ code in callWebAssemblyFunction to crash
        because $r12 was 0, and it expected it to have its value prior to
        the call.

        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::createJSToWasmWrapper):

2017-01-03  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Address failures under LayoutTests/inspector/debugger/stepping
        https://bugs.webkit.org/show_bug.cgi?id=166300

        Reviewed by Brian Burg.

        * debugger/Debugger.cpp:
        (JSC::Debugger::continueProgram):
        When continuing, clear states that would have had us pause again.

        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::didBecomeIdle):
        When resuming after becoming idle, be sure to clear Debugger state.

2017-01-03  JF Bastien  <jfbastien@apple.com>

        WebAssembly JS API: check and test in-call / out-call values
        https://bugs.webkit.org/show_bug.cgi?id=164876
        <rdar://problem/29844107>

        Reviewed by Saam Barati.

        * wasm/WasmBinding.cpp:
        (JSC::Wasm::wasmToJs): fix the wasm -> JS call coercions for f32 /
        f64 which the assotiated tests inadvertently tripped on: the
        previous code wasn't correctly performing JSValue boxing for
        "double" values. This change is slightly involved because it
        requires two scratch registers to materialize the
        `DoubleEncodeOffset` value. This change therefore reorganizes the
        code to first generate traps, then handle all integers (freeing
        all GPRs), and then all the floating-point values.
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction): Implement the defined semantics
        for mismatched arities when JS calls wasm:
        https://github.com/WebAssembly/design/blob/master/JS.md#exported-function-exotic-objects
          - i32 is 0, f32 / f64 are NaN.
          - wasm functions which return "void" are "undefined" in JS.

2017-01-03  Per Arne Vollan  <pvollan@apple.com>

        [Win] jsc.exe sometimes never exits.
        https://bugs.webkit.org/show_bug.cgi?id=158073

        Reviewed by Darin Adler.

        On Windows the thread specific destructor is also called when the main thread is exiting.
        This may lead to the main thread waiting forever for the machine thread lock when exiting,
        if the sampling profiler thread was terminated by the system while holding the machine
        thread lock.

        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::removeThread):

2017-01-02  Julien Brianceau  <jbriance@cisco.com>

        Remove sh4 specific code from JavaScriptCore
        https://bugs.webkit.org/show_bug.cgi?id=166640

        Reviewed by Filip Pizlo.

        sh4-specific code does not compile for a while (r189884 at least).
        As nobody seems to have interest in this architecture anymore, let's
        remove this dead code and thus ease the burden for JSC maintainers.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::Jump::Jump):
        (JSC::AbstractMacroAssembler::Jump::link):
        * assembler/MacroAssembler.h:
        * assembler/MacroAssemblerSH4.h: Removed.
        * assembler/MaxFrameExtentForSlowPathCall.h:
        * assembler/SH4Assembler.h: Removed.
        * bytecode/DOMJITAccessCasePatchpointParams.cpp:
        (JSC::SlowPathCallGeneratorWithArguments::generateImpl):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::debugCall):
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgumentsWithExecState):
        (JSC::CCallHelpers::prepareForTailCallSlow):
        * jit/CallFrameShuffler.cpp:
        (JSC::CallFrameShuffler::prepareForTailCall):
        * jit/ExecutableAllocator.h:
        * jit/FPRInfo.h:
        * jit/GPRInfo.h:
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::privateCompileCTINativeCall):
        * jit/JITOperations.cpp:
        * jit/RegisterSet.cpp:
        (JSC::RegisterSet::llintBaselineCalleeSaveRegisters):
        (JSC::RegisterSet::dfgCalleeSaveRegisters):
        * jit/ThunkGenerators.cpp:
        (JSC::nativeForGenerator):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LLIntOfflineAsmConfig.h:
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * offlineasm/backends.rb:
        * offlineasm/instructions.rb:
        * offlineasm/sh4.rb: Removed.
        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::generateEnter):
        (JSC::Yarr::YarrGenerator::generateReturn):

2017-01-02  JF Bastien  <jfbastien@apple.com>

        WebAssembly: handle and optimize wasm export → wasm import calls
        https://bugs.webkit.org/show_bug.cgi?id=165282

        Reviewed by Saam Barati.

          - Add a new JSType for WebAssemblyFunction, and use it when creating its
            structure. This will is used to quickly detect from wasm whether the import
            call is to another wasm module, or whether it's to JS.
          - Generate two stubs from the import stub generator: one for wasm->JS and one
            for wasm -> wasm. This is done at Module time. Which is called will only be
            known at Instance time, once we've received the import object. We want to
            avoid codegen at Instance time, so having both around is great.
          - Restore the WebAssembly global state (VM top Instance, and pinned registers)
            after call / call_indirect, and in the JS->wasm entry stub.
          - Pinned registers are now a global thing, not per-Memory, because the wasm ->
            wasm stubs are generated at Module time where we don't really have enough
            information to do the right thing (doing so would generate too much code).

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/JSType.h: add WebAssemblyFunctionType as a JSType
        * wasm/WasmB3IRGenerator.cpp: significantly rework how calls which
        could be external work, and how we save / restore global state:
        VM's top Instance, and pinned registers
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        (JSC::Wasm::getMemoryBaseAndSize):
        (JSC::Wasm::restoreWebAssemblyGlobalState):
        (JSC::Wasm::createJSToWasmWrapper):
        (JSC::Wasm::parseAndCompile):
        * wasm/WasmB3IRGenerator.h:
        * wasm/WasmBinding.cpp:
        (JSC::Wasm::materializeImportJSCell):
        (JSC::Wasm::wasmToJS):
        (JSC::Wasm::wasmToWasm): the main goal of this patch was adding this function
        (JSC::Wasm::exitStubGenerator):
        * wasm/WasmBinding.h:
        * wasm/WasmFormat.h: Get rid of much of the function index space:
        we already have all of its information elsewhere, and as-is it
        provides no extra efficiency.
        (JSC::Wasm::ModuleInformation::functionIndexSpaceSize):
        (JSC::Wasm::ModuleInformation::isImportedFunctionFromFunctionIndexSpace):
        (JSC::Wasm::ModuleInformation::signatureIndexFromFunctionIndexSpace):
        * wasm/WasmFunctionParser.h:
        (JSC::Wasm::FunctionParser<Context>::FunctionParser):
        * wasm/WasmMemory.cpp: Add some logging.
        (JSC::Wasm::Memory::dump): this was nice when debugging
        (JSC::Wasm::Memory::makeString):
        (JSC::Wasm::Memory::Memory):
        (JSC::Wasm::Memory::~Memory):
        (JSC::Wasm::Memory::grow):
        * wasm/WasmMemory.h: don't use extra indirection, it wasn't
        needed. Reorder some of the fields which are looked up at runtime
        so they're more cache-friendly.
        (JSC::Wasm::Memory::Memory):
        (JSC::Wasm::Memory::mode):
        (JSC::Wasm::Memory::offsetOfSize):
        * wasm/WasmMemoryInformation.cpp: Pinned registers are now a
        global thing for all of JSC, not a per-Memory thing
        anymore. wasm->wasm calls are more complex otherwise: they have to
        figure out how to bridge between the caller and callee's
        special-snowflake pinning.
        (JSC::Wasm::PinnedRegisterInfo::get):
        (JSC::Wasm::PinnedRegisterInfo::PinnedRegisterInfo):
        (JSC::Wasm::MemoryInformation::MemoryInformation):
        * wasm/WasmMemoryInformation.h:
        * wasm/WasmModuleParser.cpp:
        * wasm/WasmModuleParser.h:
        * wasm/WasmPageCount.cpp: Copied from Source/JavaScriptCore/wasm/WasmBinding.h.
        (JSC::Wasm::PageCount::dump): nice for debugging
        * wasm/WasmPageCount.h:
        * wasm/WasmPlan.cpp:
        (JSC::Wasm::Plan::parseAndValidateModule):
        (JSC::Wasm::Plan::run):
        * wasm/WasmPlan.h:
        (JSC::Wasm::Plan::takeWasmExitStubs):
        * wasm/WasmSignature.cpp:
        (JSC::Wasm::Signature::toString):
        (JSC::Wasm::Signature::dump):
        * wasm/WasmSignature.h:
        * wasm/WasmValidate.cpp:
        (JSC::Wasm::validateFunction):
        * wasm/WasmValidate.h:
        * wasm/js/JSWebAssemblyInstance.h:
        (JSC::JSWebAssemblyInstance::offsetOfTable):
        (JSC::JSWebAssemblyInstance::offsetOfImportFunctions):
        (JSC::JSWebAssemblyInstance::offsetOfImportFunction):
        * wasm/js/JSWebAssemblyMemory.cpp:
        (JSC::JSWebAssemblyMemory::create):
        (JSC::JSWebAssemblyMemory::JSWebAssemblyMemory):
        (JSC::JSWebAssemblyMemory::buffer):
        (JSC::JSWebAssemblyMemory::grow):
        * wasm/js/JSWebAssemblyMemory.h:
        (JSC::JSWebAssemblyMemory::memory):
        (JSC::JSWebAssemblyMemory::offsetOfMemory):
        (JSC::JSWebAssemblyMemory::offsetOfSize):
        * wasm/js/JSWebAssemblyModule.cpp:
        (JSC::JSWebAssemblyModule::create):
        (JSC::JSWebAssemblyModule::JSWebAssemblyModule):
        * wasm/js/JSWebAssemblyModule.h:
        (JSC::JSWebAssemblyModule::signatureIndexFromFunctionIndexSpace):
        (JSC::JSWebAssemblyModule::functionImportCount):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction):
        (JSC::WebAssemblyFunction::create):
        (JSC::WebAssemblyFunction::createStructure):
        (JSC::WebAssemblyFunction::WebAssemblyFunction):
        (JSC::WebAssemblyFunction::finishCreation):
        * wasm/js/WebAssemblyFunction.h:
        (JSC::WebAssemblyFunction::wasmEntrypoint):
        (JSC::WebAssemblyFunction::offsetOfInstance):
        (JSC::WebAssemblyFunction::offsetOfWasmEntryPointCode):
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::constructJSWebAssemblyInstance): always start with a dummy
        memory, so wasm->wasm calls don't need to null-check
        * wasm/js/WebAssemblyMemoryConstructor.cpp:
        (JSC::constructJSWebAssemblyMemory):
        * wasm/js/WebAssemblyModuleConstructor.cpp:
        (JSC::WebAssemblyModuleConstructor::createModule):
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::link):
        (JSC::WebAssemblyModuleRecord::evaluate):
        * wasm/js/WebAssemblyModuleRecord.h:

2017-01-02  Saam Barati  <sbarati@apple.com>

        WebAssembly: Some loads don't take into account the offset
        https://bugs.webkit.org/show_bug.cgi?id=166616
        <rdar://problem/29841541>

        Reviewed by Keith Miller.

        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::emitLoadOp):

2017-01-01  Jeff Miller  <jeffm@apple.com>

        Update user-visible copyright strings to include 2017
        https://bugs.webkit.org/show_bug.cgi?id=166278

        Reviewed by Dan Bernstein.

        * Info.plist:

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

        WebAssembly: Don't allow duplicate export names
        https://bugs.webkit.org/show_bug.cgi?id=166490
        <rdar://problem/29815000>

        Reviewed by Keith Miller.

        * wasm/WasmModuleParser.cpp:

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

        Unreviewed. Fix jsc.cpp build error.

        * jsc.cpp:
        (functionTestWasmModuleFunctions):

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

        WebAssembly: Implement grow_memory and current_memory
        https://bugs.webkit.org/show_bug.cgi?id=166448
        <rdar://problem/29803676>

        Reviewed by Keith Miller.

        This patch implements grow_memory, current_memory, and WebAssembly.prototype.grow.
        See relevant spec texts here:
        
        https://github.com/WebAssembly/design/blob/master/Semantics.md#linear-memory-accesses
        https://github.com/WebAssembly/design/blob/master/JS.md#webassemblymemoryprototypegrow
        
        I also fix a couple miscellaneous bugs:
        
        1. Data section now understands full init_exprs. 
        2. parseVarUint1 no longer has a bug where we allow values larger than 1 if
        their bottom 8 bits are zero.
        
        Since the JS API can now grow memory, we need to make calling an import
        and call_indirect refresh the base memory register and the size registers.

        * jsc.cpp:
        (functionTestWasmModuleFunctions):
        * runtime/Options.h:
        * runtime/VM.h:
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        (JSC::Wasm::reloadPinnedRegisters):
        (JSC::Wasm::B3IRGenerator::emitReloadPinnedRegisters):
        (JSC::Wasm::createJSToWasmWrapper):
        (JSC::Wasm::parseAndCompile):
        * wasm/WasmFormat.cpp:
        (JSC::Wasm::Segment::create):
        * wasm/WasmFormat.h:
        (JSC::Wasm::I32InitExpr::I32InitExpr):
        (JSC::Wasm::I32InitExpr::globalImport):
        (JSC::Wasm::I32InitExpr::constValue):
        (JSC::Wasm::I32InitExpr::isConst):
        (JSC::Wasm::I32InitExpr::isGlobalImport):
        (JSC::Wasm::I32InitExpr::globalImportIndex):
        (JSC::Wasm::Segment::byte):
        (JSC::Wasm::ModuleInformation::importFunctionCount):
        (JSC::Wasm::ModuleInformation::hasMemory):
        * wasm/WasmFunctionParser.h:
        * wasm/WasmMemory.cpp:
        (JSC::Wasm::Memory::Memory):
        (JSC::Wasm::Memory::grow):
        * wasm/WasmMemory.h:
        (JSC::Wasm::Memory::size):
        (JSC::Wasm::Memory::sizeInPages):
        (JSC::Wasm::Memory::offsetOfMemory):
        (JSC::Wasm::Memory::isValid): Deleted.
        (JSC::Wasm::Memory::grow): Deleted.
        * wasm/WasmModuleParser.cpp:
        (JSC::Wasm::makeI32InitExpr):
        * wasm/WasmModuleParser.h:
        * wasm/WasmPageCount.h:
        (JSC::Wasm::PageCount::bytes):
        (JSC::Wasm::PageCount::pageCount):
        (JSC::Wasm::PageCount::fromBytes):
        (JSC::Wasm::PageCount::operator+):
        * wasm/WasmParser.h:
        (JSC::Wasm::Parser<SuccessType>::parseVarUInt1):
        * wasm/WasmValidate.cpp:
        * wasm/js/JSWebAssemblyInstance.h:
        (JSC::JSWebAssemblyInstance::offsetOfMemory):
        * wasm/js/JSWebAssemblyMemory.cpp:
        (JSC::JSWebAssemblyMemory::~JSWebAssemblyMemory):
        (JSC::JSWebAssemblyMemory::grow):
        * wasm/js/JSWebAssemblyMemory.h:
        (JSC::JSWebAssemblyMemory::offsetOfMemory):
        * wasm/js/JSWebAssemblyModule.h:
        (JSC::JSWebAssemblyModule::functionImportCount):
        (JSC::JSWebAssemblyModule::jsEntrypointCalleeFromFunctionIndexSpace):
        (JSC::JSWebAssemblyModule::wasmEntrypointCalleeFromFunctionIndexSpace):
        (JSC::JSWebAssemblyModule::importCount): Deleted.
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction):
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::constructJSWebAssemblyInstance):
        * wasm/js/WebAssemblyMemoryConstructor.cpp:
        (JSC::constructJSWebAssemblyMemory):
        * wasm/js/WebAssemblyMemoryPrototype.cpp:
        (JSC::getMemory):
        (JSC::webAssemblyMemoryProtoFuncBuffer):
        (JSC::webAssemblyMemoryProtoFuncGrow):
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::link):
        (JSC::dataSegmentFail):
        (JSC::WebAssemblyModuleRecord::evaluate):
        * wasm/wasm.json:

2016-12-26  Yusuke Suzuki  <utatane.tea@gmail.com>

        Use variadic templates in JSC Parser to clean up
        https://bugs.webkit.org/show_bug.cgi?id=166482

        Reviewed by Saam Barati.

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

2016-12-25  Yusuke Suzuki  <utatane.tea@gmail.com>

        Propagate the source origin as much as possible
        https://bugs.webkit.org/show_bug.cgi?id=166348

        Reviewed by Darin Adler.

        This patch introduces CallFrame::callerSourceOrigin, SourceOrigin class
        and SourceProvider::m_sourceOrigin. CallFrame::callerSourceOrigin returns
        an appropriate SourceOrigin if possible. If we cannot find the appropriate
        one, we just return null SourceOrigin.

        This paves the way for implementing the module dynamic-import[1].
        When the import operator is evaluated, it will resolve the module
        specifier with this propagated source origin of the caller function.

        To support import operator inside the dynamic code generation
        functions (like `eval`, `new Function`, indirect call to `eval`),
        we need to propagate the caller's source origin to the generated
        source code.

        We do not use sourceURL for that purpose. This is because we
        would like to keep sourceURL for `eval` / `new Function` null.
        This sourceURL will be used for the stack dump for errors with line/column
        numbers. Dumping the caller's sourceURL with line/column numbers are
        meaningless. So we would like to keep it null while we would like
        to propagate SourceOrigin for dynamic imports.

        [1]: https://github.com/tc39/proposal-dynamic-import

        * API/JSBase.cpp:
        (JSEvaluateScript):
        (JSCheckScriptSyntax):
        * API/JSObjectRef.cpp:
        (JSObjectMakeFunction):
        * API/JSScriptRef.cpp:
        (OpaqueJSScript::create):
        (OpaqueJSScript::vm):
        (OpaqueJSScript::OpaqueJSScript):
        (parseScript):
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Scripts/builtins/builtins_templates.py:
        * Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.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/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::BuiltinExecutables):
        (JSC::BuiltinExecutables::createDefaultConstructor):
        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::evaluateWithScopeExtension):
        * inspector/InjectedScriptManager.cpp:
        (Inspector::InjectedScriptManager::createInjectedScript):
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::parse):
        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::callerSourceOrigin):
        * interpreter/CallFrame.h:
        * interpreter/Interpreter.cpp:
        (JSC::eval):
        * jsc.cpp:
        (jscSource):
        (GlobalObject::finishCreation):
        (extractDirectoryName):
        (currentWorkingDirectory):
        (GlobalObject::moduleLoaderResolve):
        (functionRunString):
        (functionLoadString):
        (functionCallerSourceOrigin):
        (functionCreateBuiltin):
        (functionCheckModuleSyntax):
        (runInteractive):
        * parser/SourceCode.h:
        (JSC::makeSource):
        * parser/SourceProvider.cpp:
        (JSC::SourceProvider::SourceProvider):
        * parser/SourceProvider.h:
        (JSC::SourceProvider::sourceOrigin):
        (JSC::StringSourceProvider::create):
        (JSC::StringSourceProvider::StringSourceProvider):
        (JSC::WebAssemblySourceProvider::create):
        (JSC::WebAssemblySourceProvider::WebAssemblySourceProvider):
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunction):
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * runtime/FunctionConstructor.h:
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncEval):
        * runtime/ModuleLoaderPrototype.cpp:
        (JSC::moduleLoaderPrototypeParseModule):
        * runtime/ScriptExecutable.h:
        (JSC::ScriptExecutable::sourceOrigin):
        * runtime/SourceOrigin.h: Added.
        (JSC::SourceOrigin::SourceOrigin):
        (JSC::SourceOrigin::string):
        (JSC::SourceOrigin::isNull):
        * tools/FunctionOverrides.cpp:
        (JSC::initializeOverrideInfo):

2016-12-24  Caio Lima  <ticaiolima@gmail.com>

        [test262] Fixing mapped arguments object property test case
        https://bugs.webkit.org/show_bug.cgi?id=159398

        Reviewed by Saam Barati.

        This patch changes GenericArguments' override mechanism to
        implement corret behavior on ECMAScript test262 suite test cases of
        mapped arguments object with non-configurable and non-writable
        property. Also it is ensuring that arguments[i]
        cannot be deleted when argument "i" is {configurable: false}.
        
        The previous implementation is against to the specification for 2 reasons:

        1. Every argument in arguments object are {writable: true} by default
           (http://www.ecma-international.org/ecma-262/7.0/index.html#sec-createunmappedargumentsobject).
           It means that we have to stop mapping a defined property index
           if the new property descriptor contains writable (i.e writable is
           present) and its value is false (also check
           https://tc39.github.io/ecma262/#sec-arguments-exotic-objects-defineownproperty-p-desc).
           Previous implementation considers {writable: false} if writable is
           not present.

        2. When a property is overriden, "delete" operation is always returning true. However
           delete operations should follow the specification.

        We created an auxilary boolean array named m_modifiedArgumentsDescriptor
        to store which arguments[i] descriptor was changed from its default
        property descriptor. This modification was necessary because m_overrides
        was responsible to keep this information at the same time
        of keeping information about arguments mapping. The problem of this apporach was
        that we needed to call overridesArgument(i) as soon as the ith argument's property
        descriptor was changed and it stops the argument's mapping as sideffect, producing
        wrong behavior.
        To keep tracking arguments mapping status, we renamed DirectArguments::m_overrides to
        DirectArguments::m_mappedArguments and now we it is responsible to manage if an
        argument[i] is mapped or not.
        With these 2 structures, now it is possible to an argument[i] have its property 
        descriptor modified and don't stop the mapping as soon as it happens. One example
        of that wrong behavior can be found on arguments-bizarre-behaviour-disable-enumerability
        test case, that now is fixed by this new mechanism.

        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generateWithGuard):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnDirectArguments):
        (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
        (JSC::DFG::SpeculativeJIT::compileCreateDirectArguments):
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileGetArrayLength):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateDirectArguments):
        * jit/JITOperations.cpp:
        (JSC::canAccessArgumentIndexQuickly):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitDirectArgumentsGetByVal):
        * runtime/DirectArguments.cpp:
        (JSC::DirectArguments::estimatedSize):
        (JSC::DirectArguments::visitChildren):
        (JSC::DirectArguments::overrideThings):
        (JSC::DirectArguments::overrideThingsIfNecessary):
        (JSC::DirectArguments::unmapArgument):
        (JSC::DirectArguments::copyToArguments):
        (JSC::DirectArguments::overridesSize):
        (JSC::DirectArguments::overrideArgument): Deleted.
        * runtime/DirectArguments.h:
        (JSC::DirectArguments::length):
        (JSC::DirectArguments::isMappedArgument):
        (JSC::DirectArguments::isMappedArgumentInDFG):
        (JSC::DirectArguments::getIndexQuickly):
        (JSC::DirectArguments::setIndexQuickly):
        (JSC::DirectArguments::overrodeThings):
        (JSC::DirectArguments::initModifiedArgumentsDescriptorIfNecessary):
        (JSC::DirectArguments::setModifiedArgumentDescriptor):
        (JSC::DirectArguments::isModifiedArgumentDescriptor):
        (JSC::DirectArguments::offsetOfMappedArguments):
        (JSC::DirectArguments::offsetOfModifiedArgumentsDescriptor):
        (JSC::DirectArguments::canAccessIndexQuickly): Deleted.
        (JSC::DirectArguments::canAccessArgumentIndexQuicklyInDFG): Deleted.
        (JSC::DirectArguments::offsetOfOverrides): Deleted.
        * runtime/GenericArguments.h:
        * runtime/GenericArgumentsInlines.h:
        (JSC::GenericArguments<Type>::visitChildren):
        (JSC::GenericArguments<Type>::getOwnPropertySlot):
        (JSC::GenericArguments<Type>::getOwnPropertySlotByIndex):
        (JSC::GenericArguments<Type>::getOwnPropertyNames):
        (JSC::GenericArguments<Type>::put):
        (JSC::GenericArguments<Type>::putByIndex):
        (JSC::GenericArguments<Type>::deleteProperty):
        (JSC::GenericArguments<Type>::deletePropertyByIndex):
        (JSC::GenericArguments<Type>::defineOwnProperty):
        (JSC::GenericArguments<Type>::initModifiedArgumentsDescriptor):
        (JSC::GenericArguments<Type>::initModifiedArgumentsDescriptorIfNecessary):
        (JSC::GenericArguments<Type>::setModifiedArgumentDescriptor):
        (JSC::GenericArguments<Type>::isModifiedArgumentDescriptor):
        (JSC::GenericArguments<Type>::copyToArguments):
        * runtime/ScopedArguments.cpp:
        (JSC::ScopedArguments::visitChildren):
        (JSC::ScopedArguments::unmapArgument):
        (JSC::ScopedArguments::overrideArgument): Deleted.
        * runtime/ScopedArguments.h:
        (JSC::ScopedArguments::isMappedArgument):
        (JSC::ScopedArguments::isMappedArgumentInDFG):
        (JSC::ScopedArguments::getIndexQuickly):
        (JSC::ScopedArguments::setIndexQuickly):
        (JSC::ScopedArguments::initModifiedArgumentsDescriptorIfNecessary):
        (JSC::ScopedArguments::setModifiedArgumentDescriptor):
        (JSC::ScopedArguments::isModifiedArgumentDescriptor):
        (JSC::ScopedArguments::canAccessIndexQuickly): Deleted.
        (JSC::ScopedArguments::canAccessArgumentIndexQuicklyInDFG): Deleted.

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

        Using Option::breakOnThrow() shouldn't crash while printing a null CodeBlock.
        https://bugs.webkit.org/show_bug.cgi?id=166466

        Reviewed by Keith Miller.

        * runtime/VM.cpp:
        (JSC::VM::throwException):

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

        Enhance LLInt tracing to dump the codeBlock signature instead of just a pointer where appropriate.
        https://bugs.webkit.org/show_bug.cgi?id=166465

        Reviewed by Keith Miller.

        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (JSC::LLInt::traceFunctionPrologue):

2016-12-23  Keith Miller  <keith_miller@apple.com>

        WebAssembly: trap on bad division.
        https://bugs.webkit.org/show_bug.cgi?id=164786

        Reviewed by Mark Lam.

        This patch adds traps for division / modulo by zero and for
        division by int_min / -1.

        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::emitChecksForModOrDiv):
        * wasm/WasmExceptionType.h:
        * wasm/WasmPlan.cpp:
        (JSC::Wasm::Plan::run):
        * wasm/wasm.json:

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

        Fix broken LLINT_SLOW_PATH_TRACING build.
        https://bugs.webkit.org/show_bug.cgi?id=166463

        Reviewed by Keith Miller.

        * llint/LLIntExceptions.cpp:
        (JSC::LLInt::returnToThrow):
        (JSC::LLInt::callToThrow):
        * runtime/CommonSlowPathsExceptions.cpp:
        (JSC::CommonSlowPaths::interpreterThrowInCaller):

2016-12-22  Keith Miller  <keith_miller@apple.com>

        WebAssembly: Make spec-tests/f32.wast.js and spec-tests/f64.wast.js pass
        https://bugs.webkit.org/show_bug.cgi?id=166447

        Reviewed by Saam Barati.

        We needed to treat -0.0 < 0.0 for floating point min/max. For min,
        the algorithm works because if a == b then a and b are not NaNs so
        either they are the same or they are some zero. When we or a and b
        either we get the same number back or we get -0.0. Similarly for
        max we use an and and the sign bit gets dropped if one is 0.0 and
        the other is -0.0, otherwise, we get the same number back.

        * wasm/wasm.json:

2016-12-22  Saam Barati  <sbarati@apple.com>

        WebAssembly: Make calling Wasm functions that returns or takes an i64 as a parameter an early exception
        https://bugs.webkit.org/show_bug.cgi?id=166437
        <rdar://problem/29793949>

        Reviewed by Keith Miller.

        This patch makes it so that we throw an exception before we do
        anything else if we call a wasm function that either takes an
        i64 as an argument or returns an i64.

        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction):
        (JSC::WebAssemblyFunction::WebAssemblyFunction):
        (JSC::WebAssemblyFunction::call): Deleted.
        * wasm/js/WebAssemblyFunction.h:
        (JSC::WebAssemblyFunction::signatureIndex):
        (JSC::WebAssemblyFunction::jsEntrypoint):

2016-12-22  Keith Miller  <keith_miller@apple.com>

        Add BitOr for floating points to B3
        https://bugs.webkit.org/show_bug.cgi?id=166446

        Reviewed by Saam Barati.

        This patch does some slight refactoring to the ARM assembler,
        which groups all the vector floating point instructions together.

        * assembler/ARM64Assembler.h:
        (JSC::ARM64Assembler::vand):
        (JSC::ARM64Assembler::vorr):
        (JSC::ARM64Assembler::vectorDataProcessingLogical):
        (JSC::ARM64Assembler::vectorDataProcessing2Source): Deleted.
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::orDouble):
        (JSC::MacroAssemblerARM64::orFloat):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::orDouble):
        (JSC::MacroAssemblerX86Common::orFloat):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::orps_rr):
        * b3/B3ConstDoubleValue.cpp:
        (JSC::B3::ConstDoubleValue::bitOrConstant):
        (JSC::B3::ConstDoubleValue::bitXorConstant):
        * b3/B3ConstDoubleValue.h:
        * b3/B3ConstFloatValue.cpp:
        (JSC::B3::ConstFloatValue::bitOrConstant):
        (JSC::B3::ConstFloatValue::bitXorConstant):
        * b3/B3ConstFloatValue.h:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3Validate.cpp:
        * b3/air/AirInstInlines.h:
        (JSC::B3::Air::Inst::shouldTryAliasingDef):
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::bitOrDouble):
        (JSC::B3::testBitOrArgDouble):
        (JSC::B3::testBitOrArgsDouble):
        (JSC::B3::testBitOrArgImmDouble):
        (JSC::B3::testBitOrImmsDouble):
        (JSC::B3::bitOrFloat):
        (JSC::B3::testBitOrArgFloat):
        (JSC::B3::testBitOrArgsFloat):
        (JSC::B3::testBitOrArgImmFloat):
        (JSC::B3::testBitOrImmsFloat):
        (JSC::B3::testBitOrArgsFloatWithUselessDoubleConversion):
        (JSC::B3::run):

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

        BytecodeGenerator::m_finallyDepth should be unsigned.
        https://bugs.webkit.org/show_bug.cgi?id=166438

        Reviewed by Saam Barati.

        Also removed FinallyContext::m_finallyDepth because it is not used.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::pushFinallyControlFlowScope):
        (JSC::BytecodeGenerator::labelScopeDepth):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::FinallyContext::FinallyContext):
        (JSC::FinallyContext::finallyLabel):
        (JSC::FinallyContext::depth): Deleted.

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

        De-duplicate finally blocks.
        https://bugs.webkit.org/show_bug.cgi?id=160168

        Reviewed by Saam Barati.

        JS execution can arrive at a finally block when there are abrupt completions from
        its try or catch block.  The abrupt completion types include Break,
        Continue, Return, and Throw.  The non-abrupt completion type is called Normal
        (i.e. the case of a try block falling through to the finally block).

        Previously, we enable each of these paths for abrupt completion (except for Throw)
        to run the finally block code by duplicating the finally block code at each of
        the sites that trigger those completions.  This patch fixes the implementation so
        that each of these abrupt completions will set a completionTypeRegister (plus a
        completionValueRegister for CompletionType::Return) and then jump to the
        relevant finally blocks, and continue to thread through subsequent outer finally
        blocks until execution reaches the outermost finally block that the completion
        type dictates.  We no longer duplicate the finally block code.

        The implementation details:
        1. We allocate a pair of registers (completionTypeRegister and completionValueRegister)
           just before entering the outermost try-catch-finally scope.

           On allocating the registers, we initialize the completionTypeRegister to
           CompletionType::Normal, and set the completionValueRegister to the empty
           JSValue.

        2. The completionTypeRegister will hold a CompletionType value.  This is how we
           encode the CompletionType value to be set:

           a. For Normal, Return, and Throw completion types: 
              - The completionTypeRegister is set to CompletionType::Normal,
                CompletionType::Return, and CompletionType::Throw respectively.

           b. For Break and Continue completion types:
              - The completionTypeRegister is set to a unique jumpID where the jumpID is
                computed as:

                jumpID = CompletionType::NumberOfTypes + bytecodeOffset

                The bytecodeOffset used here is the bytecodeOffset of the break or continue
                statement that triggered this completion.

        3. Each finally block will have 2 entries:
           a. the catch entry.
           b. the normal entry.

           The catch entry is recorded in the codeBlock's exception handler table,
           and can only be jumped to by the VM's exception handling mechanism.

           The normal entry is recorded in a FinallyContext (at bytecode generation time
           only) and is jumped to when we want enter the finally block due any of the
           other CompletionTypes.

        4. How each completion type works?

           CompletionType::Normal
           ======================
           We normally encounter this when falling through from a try or catch block to
           the finally block.  
          
           For the try block case, since completionTypeRegister is set to Normal by default,
           there's nothing more that needs to be done.

           For the catch block case, since we entered the catch block with an exception,
           completionTypeRegister may be set to Throw.  We'll need to set it to Normal
           before jumping to the finally block's normal entry.

           CompletionType::Break
           =====================
           When we emit bytecode for the BreakNode, we check if we have any FinallyContexts
           that we need to service before jumping to the breakTarget.  If we don't, then
           emit op_jump to the breakTarget as usual.  Otherwise:

           a. we'll register a jumpID and the breakTarget with the FinallyContext for the
              outermost finally block that we're supposed to run through.
           b. we'll also increment the numberOfBreaksOrContinues count in each FinallyContext
              from the innermost to the one for that outermost finally block.
           c. emit bytecode to set the completionTypeRegister to the jumpID.
           d. emit bytecode to jump to the normal entry of the innermost finally block.

           Each finally block will take care of cascading to the next outer finally block
           as needed (see (5) below).

           CompletionType::Continue
           ========================
           Since continues and breaks work the same way (i.e. with a jump), we handle this
           exactly the same way as CompletionType::Break, except that we use the
           continueTarget instead of the breakTarget.

           CompletionType::Return
           ======================
           When we emit bytecode for the ReturnNode, we check if we have any FinallyContexts
           at all on the m_controlFlowScopeStack.  If we don't, then emit op_ret as usual.
           Otherwise:

           a. emit bytecode to set the completionTypeRegister to CompletionType::Return.
           b. emit bytecode to move the return value into the completionValueRegister.
           c. emit bytecode to jump to the normal entry of the innermost finally block.

           Each finally block will take care of cascading to the next outer finally block
           as needed (see (5) below).

           CompletionType::Throw
           ======================
           At the catch entry a finally block, we:
           1. emit an op_catch that stores the caught Exception object in the
              completionValueRegister.
           2. emit bytecode to set the completionTypeRegister to CompletionType::Throw.
           3. Fall through or jump to the finally block's normal entry.

        5. What happens in each finally block?
           ==================================
           For details on the finally block's catch entry, see "CompletionType::Throw" in
           (4) above.

           The finally block's normal entry will:
           1. restore the scope of the finally block.
           2. save the completionTypeRegister in a savedCompletionTypeRegister.
           3. proceed to execute the body of the finally block.

           At the end of the finally block, we will emit bytecode check the
           savedCompletionTypeRegister for each completion type see emitFinallyCompletion())
           in the following order:
          
           a. Check for CompletionType::Normal
              ================================
              If savedCompletionTypeRegister is CompletionType::Normal, jump to the
              designated normalCompletion label.  We only need this check this finally
              block also needs to check for Break, Continue, or Return.  If not, the
              completion type check for CompletionType::Throw below will make this check
              redundant.

           b. Check for CompletionType::Break and Continue
              ============================================
              If the FinallyContext for this block has registered FinallyJumps, we'll
              check the jumpIDs against the savedCompletionTypeRegister.  If the jumpID
              matches, jump to the corresponding jumpTarget.

              If no jumpIDs match but the FinallyContext's numberOfBreaksOrContinues is
              greater than the number of registered FinallyJumps, then this means that
              we have a Break or Continue that needs to be handled by an outer finally
              block.  In that case, jump to the next outer finally block's normal entry.
             
           c. Check for CompletionType::Return
              ================================
              If this finally block is not the outermost and the savedCompletionTypeRegister
              is set to CompletionType::Return, then jump to the next outer finally
              block's normal entry.

              Otherwise, if this finally block is the outermost and the savedCompletionTypeRegister
              is set to CompletionType::Return, then execute op_ret and return the value
              in the completionValueRegister.

           d. CompletionType::Throw
              =====================
              If savedCompletionTypeRegister is CompletionType::Throw, then just re-throw the
              Exception object in the completionValueRegister.

           Detail 1: that we check the savedCompletionTypeRegister (and not the
           completionTypeRegister).  This is because the finally block may itself contain
           a try-finally, and this inner try-finally may have trashed the completionTypeRegister.
           Here's an example:

               try {
                   return "r1"; // Sets completionTypeRegister to CompletionType::Return;
               } finally {
                   // completionTypeRegister is CompletionType::Return here.

                   try {
                       ... // do stuff.
                   } finally {
                       ... // do more stuff.
                   }

                   // completionTypeRegister may be anything here depending on what
                   // was executed in the inner try-finally block above.

                   // Hence, finally completion here must be based on a saved copy of the
                   // completionTypeRegister when we entered this finally block.
               }

           Detail 2: the finally completion for CompletionType::Throw must always explicitly
           check if the savedCompletionTypeRegister is CompletionType::Throw before throwing.
           We cannot imply that it is so from the Throw case being last.  Here's why:

               // completionTypeRegister is CompletionType::Normal here.
               try {
                   return "r1"; // Sets completionTypeRegister to CompletionType::Return;
               } finally {
                   // completionTypeRegister is CompletionType::Return here.

                   try {
                       ... // do stuff.  No abrupt completions.
                   } finally {
                       // completionTypeRegister is CompletionType::Return here (from the outer try-finally).
                       // savedCompletionTypeRegister is set to completionTypeRegister (i.e. CompletionType::Return) here.

                       ... // do more stuff.  No abrupt completions.

                       // Unless there's an abrupt completion since entering the outer
                       // finally block, the savedCompletionTypeRegister will remain set
                       // to CompletionType::Return.  If we don't explicitly check if the
                       // savedCompletionTypeRegister is CompletionType::Throw before
                       // throwing here, we'll end up erroneously throwing "r1".
                   }

                   ...
               }

        6. restoreScopeRegister()
       
           Since the needed scope objects are always stored in a local, we can restore
           the scope register by simply moving from that local instead of going through
           op_get_parent_scope.

        7. m_controlFlowScopeStack needs to be a SegmentedVector instead of a Vector.
           This makes it easier to keep a pointer to the FinallyContext on that stack,
           and not have to worry about the vector being realloc'ed due to resizing. 

        Performance appears to be neutral both on ES6SampleBench (run via cli) and the
        JSC benchmarks.

        Relevant spec references:
        https://tc39.github.io/ecma262/#sec-completion-record-specification-type
        https://tc39.github.io/ecma262/#sec-try-statement-runtime-semantics-evaluation

        * bytecode/HandlerInfo.h:
        (JSC::HandlerInfoBase::typeName):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitReturn):
        (JSC::BytecodeGenerator::pushFinallyControlFlowScope):
        (JSC::BytecodeGenerator::popFinallyControlFlowScope):
        (JSC::BytecodeGenerator::allocateAndEmitScope):
        (JSC::BytecodeGenerator::pushTry):
        (JSC::BytecodeGenerator::popTry):
        (JSC::BytecodeGenerator::emitCatch):
        (JSC::BytecodeGenerator::restoreScopeRegister):
        (JSC::BytecodeGenerator::labelScopeDepthToLexicalScopeIndex):
        (JSC::BytecodeGenerator::labelScopeDepth):
        (JSC::BytecodeGenerator::pushLocalControlFlowScope):
        (JSC::BytecodeGenerator::popLocalControlFlowScope):
        (JSC::BytecodeGenerator::emitEnumeration):
        (JSC::BytecodeGenerator::emitIsNumber):
        (JSC::BytecodeGenerator::emitYield):
        (JSC::BytecodeGenerator::emitDelegateYield):
        (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
        (JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
        (JSC::BytecodeGenerator::emitFinallyCompletion):
        (JSC::BytecodeGenerator::allocateCompletionRecordRegisters):
        (JSC::BytecodeGenerator::releaseCompletionRecordRegisters):
        (JSC::BytecodeGenerator::emitJumpIf):
        (JSC::BytecodeGenerator::pushIteratorCloseControlFlowScope): Deleted.
        (JSC::BytecodeGenerator::popIteratorCloseControlFlowScope): Deleted.
        (JSC::BytecodeGenerator::emitComplexPopScopes): Deleted.
        (JSC::BytecodeGenerator::emitPopScopes): Deleted.
        (JSC::BytecodeGenerator::popTryAndEmitCatch): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        (JSC::bytecodeOffsetToJumpID):
        (JSC::FinallyJump::FinallyJump):
        (JSC::FinallyContext::FinallyContext):
        (JSC::FinallyContext::outerContext):
        (JSC::FinallyContext::finallyLabel):
        (JSC::FinallyContext::depth):
        (JSC::FinallyContext::numberOfBreaksOrContinues):
        (JSC::FinallyContext::incNumberOfBreaksOrContinues):
        (JSC::FinallyContext::handlesReturns):
        (JSC::FinallyContext::setHandlesReturns):
        (JSC::FinallyContext::registerJump):
        (JSC::FinallyContext::numberOfJumps):
        (JSC::FinallyContext::jumps):
        (JSC::ControlFlowScope::ControlFlowScope):
        (JSC::ControlFlowScope::isLabelScope):
        (JSC::ControlFlowScope::isFinallyScope):
        (JSC::BytecodeGenerator::currentLexicalScopeIndex):
        (JSC::BytecodeGenerator::CompletionRecordScope::CompletionRecordScope):
        (JSC::BytecodeGenerator::CompletionRecordScope::~CompletionRecordScope):
        (JSC::BytecodeGenerator::completionTypeRegister):
        (JSC::BytecodeGenerator::completionValueRegister):
        (JSC::BytecodeGenerator::emitSetCompletionType):
        (JSC::BytecodeGenerator::emitSetCompletionValue):
        (JSC::BytecodeGenerator::isInFinallyBlock): Deleted.
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ContinueNode::emitBytecode):
        (JSC::BreakNode::emitBytecode):
        (JSC::ReturnNode::emitBytecode):
        (JSC::TryNode::emitBytecode):

2016-12-22  Saam Barati  <sbarati@apple.com>

        WebAssembly: Make the spec-tests/address.wast.js test pass
        https://bugs.webkit.org/show_bug.cgi?id=166429
        <rdar://problem/29793220>

        Reviewed by Keith Miller.

        Right now, provably out of bound loads/stores (given a load/store's constant
        offset) are not a validation error. However, we were failing to catch uint32_t
        overflows in release builds (we did have a debug assertion). To fix this,
        I now detect when uint32_t addition will overflow, and instead of emitting
        a normal load/store, I emit code that throws an out of bounds memory exception.

        * wasm/WasmB3IRGenerator.cpp:

2016-12-22  Keith Miller  <keith_miller@apple.com>

        WebAssembly: The validator should not allow unused stack entries at the end of a block
        https://bugs.webkit.org/show_bug.cgi?id=166411

        Reviewed by Saam Barati.

        This patch also cleans up some of the verbose mode logging.

        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::dumpExpressionStack):
        (JSC::Wasm::B3IRGenerator::dump):
        * wasm/WasmFunctionParser.h:
        * wasm/WasmValidate.cpp:
        (JSC::Wasm::dumpExpressionStack):
        (JSC::Wasm::Validate::dump):

2016-12-22  Saam Barati  <sbarati@apple.com>

        WebAssembly: Make the spec-tests/start.wast.js test pass
        https://bugs.webkit.org/show_bug.cgi?id=166416
        <rdar://problem/29784532>

        Reviewed by Yusuke Suzuki.

        To make the test run, I had to fix two bugs:
        
        1. We weren't properly finding the start function. There was code
        that would try to find the start function from the list of *exported*
        functions. This is wrong; the start function is an index into the
        function index space, which is the space for *imports* and *local*
        functions. So the code was just wrong in this respect, and I've
        fixed it do the right thing. We weren't sure if this was originally
        allowed or not in the spec, but it has been decided that it is allowed
        and the spec-tests test for it: https://github.com/WebAssembly/design/issues/896
        
        2. We were emitting a breakpoint for Unreachable. Instead of crashing,
        this opcode needs to throw an exception when executing.

        * wasm/WasmB3IRGenerator.cpp:
        * wasm/WasmExceptionType.h:
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::link):
        (JSC::WebAssemblyModuleRecord::evaluate):
        * wasm/js/WebAssemblyModuleRecord.h:

2016-12-21  Keith Miller  <keith_miller@apple.com>

        WebAssembly: Fix decode floating point constants in unreachable code
        https://bugs.webkit.org/show_bug.cgi?id=166400

        Reviewed by Saam Barati.

        We decoded these as variable length but they should be fixed length.

        * wasm/WasmFunctionParser.h:

2016-12-21  Keith Miller  <keith_miller@apple.com>

        WebAssembly: Allow br, br_if, and br_table to act as a return
        https://bugs.webkit.org/show_bug.cgi?id=166393

        Reviewed by Saam Barati.

        This patch allows br, br_if, and br_table to treat branching to
        the size of the control stack to act as a return. This change was
        made by adding a new block type to the wasm function parser,
        TopLevel. Adding this new block eliminates a lot of the special
        case code we had in the parser previously. The only special case
        we need is when the end opcode is parsed from the top level.  The
        B3 IR generator needs to automatically emit a return at that
        point.

        Also, this patch adds the function number to validation errors
        in the function parser. The current error message is not helpful
        otherwise.

        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::ControlData::dump):
        (JSC::Wasm::B3IRGenerator::addTopLevel):
        * wasm/WasmFunctionParser.h:
        * wasm/WasmPlan.cpp:
        (JSC::Wasm::Plan::parseAndValidateModule):
        (JSC::Wasm::Plan::run):
        * wasm/WasmValidate.cpp:
        (JSC::Wasm::Validate::ControlData::dump):
        (JSC::Wasm::Validate::Validate):
        (JSC::Wasm::Validate::addTopLevel):
        (JSC::Wasm::validateFunction):

2016-12-21  JF Bastien  <jfbastien@apple.com>

        WebAssembly JS API: cleanup & pass VM around to {Compile/Runtime}Error
        https://bugs.webkit.org/show_bug.cgi?id=166295
        <rdar://problem/29762017>

        Reviewed by Mark Lam.

        Rename the create* functions, and pass VM around, as suggested for
        LinkError in #165805.

        At the same time, use the default source appender when
        constructing these error types, which gives a nice map back to the
        original source as part of the error message. This is clearer when
        using the current frame, so add that as well.

        * jit/ThunkGenerators.cpp:
        (JSC::throwExceptionFromWasmThunkGenerator):
        * wasm/js/JSWebAssemblyCompileError.cpp:
        (JSC::JSWebAssemblyCompileError::create):
        (JSC::createJSWebAssemblyCompileError):
        (JSC::createWebAssemblyCompileError): Deleted.
        * wasm/js/JSWebAssemblyCompileError.h:
        (JSC::JSWebAssemblyCompileError::create):
        * wasm/js/JSWebAssemblyRuntimeError.cpp:
        (JSC::JSWebAssemblyRuntimeError::create):
        * wasm/js/JSWebAssemblyRuntimeError.h:
        (JSC::JSWebAssemblyRuntimeError::create):
        * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
        (JSC::constructJSWebAssemblyCompileError):
        * wasm/js/WebAssemblyModuleConstructor.cpp:
        (JSC::WebAssemblyModuleConstructor::createModule):
        * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
        (JSC::constructJSWebAssemblyRuntimeError):

2016-12-21  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Fix modules document in features.json
        https://bugs.webkit.org/show_bug.cgi?id=166313

        Reviewed by Saam Barati.

        * features.json:

2016-12-20  Taras Tsugrii  <ttsugrii@fb.com>

        Fix undefined behavior caused by macro expansion producing 'defined'
        https://bugs.webkit.org/show_bug.cgi?id=166047

        Reviewed by Darin Adler.

        * API/JSBase.h:

2016-12-20  Keith Miller  <keith_miller@apple.com>

        Add support for global
        https://bugs.webkit.org/show_bug.cgi?id=165171

        Reviewed by Filip Pizlo.

        This patch adds spport for the global property on the global object.
        The global property spec is in stage three and is quite simple.
        For reference: http://tc39.github.io/proposal-global/

        * runtime/JSGlobalObject.cpp:

2016-12-20  Saam Barati  <sbarati@apple.com>

        WebAssembly: We should compile wasm functions in parallel
        https://bugs.webkit.org/show_bug.cgi?id=165993

        Reviewed by Keith Miller.

        This patch adds a very simple parallel compiler for Wasm code.
        This patch speeds up compiling the Unity headless benchmark by
        slightly more than 4x on my MBP. To make this safe, I perform
        all linking on the main thread. I also had to change some code
        inside Wasmb3IRGenerator to be thread safe.

        * b3/air/AirCustom.h:
        (JSC::B3::Air::WasmBoundsCheckCustom::generate):
        * b3/air/AirGenerationContext.h:
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        (JSC::Wasm::B3IRGenerator::emitExceptionCheck):
        (JSC::Wasm::createJSToWasmWrapper):
        (JSC::Wasm::parseAndCompile):
        * wasm/WasmB3IRGenerator.h:
        * wasm/WasmCallingConvention.h:
        (JSC::Wasm::CallingConvention::setupFrameInPrologue):
        * wasm/WasmPlan.cpp:
        (JSC::Wasm::Plan::parseAndValidateModule):
        (JSC::Wasm::Plan::run):
        * wasm/WasmPlan.h:

2016-12-20  Brent Fulgham  <bfulgham@apple.com>

        Address some style problems found by static analysis
        https://bugs.webkit.org/show_bug.cgi?id=165975

        Reviewed by Alex Christensen.

        Correct the const-correctness of functions that are implemented using stricter
        const declarations.

        * inspector/agents/InspectorDebuggerAgent.h:
        * inspector/agents/InspectorHeapAgent.cpp:
        * inspector/agents/InspectorHeapAgent.h:
        * inspector/agents/InspectorRuntimeAgent.h:
        * inspector/agents/InspectorScriptProfilerAgent.cpp:
        * inspector/agents/InspectorScriptProfilerAgent.h:
        * inspector/scripts/codegen/cpp_generator.py:
        (cpp_type_for_unchecked_formal_in_parameter): Update to match const declarations of
        implementation files.
        * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
        Rebaselined results for "const Ptr* const" syntax.

2016-12-20  JF Bastien  <jfbastien@apple.com>

        WebAssembly: construct 32-bit encodedJSValue properly
        https://bugs.webkit.org/show_bug.cgi?id=166199

        Reviewed by Mark Lam.

        Constructing an encodedJSValue using `{ }` yields the wrong value
        on 32-bit platforms. WebAssembly doesn't currently target 32-bit
        platforms, but we may as well get it right.

        * wasm/JSWebAssembly.cpp:
        (JSC::webAssemblyCompileFunc):
        (JSC::webAssemblyValidateFunc):
        * wasm/js/JSWebAssemblyHelpers.h:
        (JSC::toNonWrappingUint32):
        * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
        (JSC::constructJSWebAssemblyCompileError):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction):
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::constructJSWebAssemblyInstance):
        * wasm/js/WebAssemblyMemoryConstructor.cpp:
        (JSC::constructJSWebAssemblyMemory):
        * wasm/js/WebAssemblyModuleConstructor.cpp:
        (JSC::constructJSWebAssemblyModule):
        * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
        (JSC::constructJSWebAssemblyRuntimeError):
        * wasm/js/WebAssemblyTableConstructor.cpp:
        (JSC::constructJSWebAssemblyTable):
        * wasm/js/WebAssemblyTablePrototype.cpp:
        (JSC::webAssemblyTableProtoFuncLength):
        (JSC::webAssemblyTableProtoFuncGrow):
        (JSC::webAssemblyTableProtoFuncGet):
        (JSC::webAssemblyTableProtoFuncSet):

2016-12-20  Dean Jackson  <dino@apple.com>

        Remove INDIE_UI
        https://bugs.webkit.org/show_bug.cgi?id=165881
        <rdar://problem/29672532>

        Reviewed by Simon Fraser.

        The Indie UI work has been discontinued.

        * Configurations/FeatureDefines.xcconfig:

2016-12-20  JF Bastien  <jfbastien@apple.com>

        WebAssembly API: implement WebAssembly.LinkError
        https://bugs.webkit.org/show_bug.cgi?id=165805
        <rdar://problem/29747874>

        Reviewed by Mark Lam.

        As described here: https://github.com/WebAssembly/design/pull/901
        Some TypeError and RangeError are now converted to WebAssembly.LinkError.

        * CMakeLists.txt: add files
        * DerivedSources.make: add autoget .lut.h files
        * JavaScriptCore.xcodeproj/project.pbxproj: add files
        * builtins/BuiltinNames.h: new name LinkError
        * runtime/JSGlobalObject.h: auto-register LinkError using existing macro magic
        * wasm/JSWebAssembly.h: make the new includes available
        * wasm/js/JSWebAssemblyLinkError.cpp: Copied from Source/JavaScriptCore/wasm/JSWebAssemblyCompileError.cpp.
        (JSC::JSWebAssemblyLinkError::create):
        (JSC::JSWebAssemblyLinkError::JSWebAssemblyLinkError):
        (JSC::createWebAssemblyLinkError):
        * wasm/js/JSWebAssemblyLinkError.h: Copied from Source/JavaScriptCore/wasm/JSWebAssemblyCompileError.h.
        (JSC::JSWebAssemblyLinkError::create):
        * wasm/js/WebAssemblyInstanceConstructor.cpp: update as per spec change
        (JSC::constructJSWebAssemblyInstance):
        * wasm/js/WebAssemblyLinkErrorConstructor.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyCompileErrorConstructor.cpp.
        (JSC::constructJSWebAssemblyLinkError):
        (JSC::callJSWebAssemblyLinkError):
        (JSC::WebAssemblyLinkErrorConstructor::create):
        (JSC::WebAssemblyLinkErrorConstructor::createStructure):
        (JSC::WebAssemblyLinkErrorConstructor::finishCreation):
        (JSC::WebAssemblyLinkErrorConstructor::WebAssemblyLinkErrorConstructor):
        (JSC::WebAssemblyLinkErrorConstructor::getConstructData):
        (JSC::WebAssemblyLinkErrorConstructor::getCallData):
        * wasm/js/WebAssemblyLinkErrorConstructor.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyCompileErrorConstructor.h.
        * wasm/js/WebAssemblyLinkErrorPrototype.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyCompileErrorPrototypr.cpp.
        (JSC::WebAssemblyLinkErrorPrototype::create):
        (JSC::WebAssemblyLinkErrorPrototype::createStructure):
        (JSC::WebAssemblyLinkErrorPrototype::finishCreation):
        (JSC::WebAssemblyLinkErrorPrototype::WebAssemblyLinkErrorPrototype):
        * wasm/js/WebAssemblyLinkErrorPrototype.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyCompileErrorPrototypr.h.
        * wasm/js/WebAssemblyModuleRecord.cpp: update as per spec change
        (JSC::dataSegmentFail):
        (JSC::WebAssemblyModuleRecord::evaluate):

2016-12-20  JF Bastien  <jfbastien@apple.com>

        WebAssembly: unique function signatures
        https://bugs.webkit.org/show_bug.cgi?id=165957
        <rdar://problem/29735737>

        Reviewed by Saam Barati.

        Signatures in a Module's Type section can be duplicated, we
        therefore need to unique them so that call_indirect only needs to
        do a single integer compare to check that a callee's Signature is
        the same as the Signature declared at the call site. Without
        uniquing we'd either trap when duplicate Signatures are used, or
        we'd need to do multiple comparisons. This patch makes that narrow
        usecase function correctly.

        There's further complication when calling from wasm to
        wasm, in which case the Signatures must also match. Such
        cross-instance calls will be improved in bug #165282, but this
        patch sets the groundwork for it:

        - Signatures are now owned by SignatureInformation which lives on
          VM, and is shared by all Modules.
        - When parsing a Module, a Signature is created for every Type
          entry, and then uniqued by SignatureInformation's adopt
          method. Duplicate Signatures are dropped and the previous
          SignatureIndex is returned, new Signatures are adopted and a new
          SignatureIndex is created.
        - The SignatureIndex values are monotonic. 0 is used to represent
          invalid indices, which trap. This can only occur through Table.
        - SignatureInformation is used while generating code to map a
          SignatureIndex back to the Signature* when return / argument
          information is needed. This is a simple lookup into a Vector. It
          isn't used at runtime.
        - These Signatures live forever on VM because the bookkeeping
          likely isn't worth it. We may want to empty things out if all
          Modules die, this is tracked in bug #166037.
        - We can further improve things by bit-packing SignatureIndex with
          Code*, which is tracked by bug #165511.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/VM.h: wasm signatures are uniqued here, but aren't accessed frequently (only during parsing) so indirection is fine
        * wasm/WasmB3IRGenerator.cpp: use SignatureIndex instead of Signature* when appropriate, and when still using Signature* do so with its new API
        (JSC::Wasm::createJSToWasmWrapper):
        (JSC::Wasm::parseAndCompile):
        * wasm/WasmBinding.cpp:
        (JSC::Wasm::importStubGenerator): use SignatureIndex
        * wasm/WasmBinding.h:
        * wasm/WasmCallingConvention.h:
        (JSC::Wasm::CallingConvention::loadArguments):
        * wasm/WasmFormat.cpp: drive-by move of alloc/free functions to the implementation file, allows the .h file to drop an FastMalloc.h
        (JSC::Wasm::Segment::create):
        (JSC::Wasm::Segment::destroy):
        (JSC::Wasm::Segment::createPtr):
        * wasm/WasmFormat.h: move Signature to its own file
        (JSC::Wasm::CallableFunction::CallableFunction):
        * wasm/WasmFunctionParser.h:
        (JSC::Wasm::FunctionParser<Context>::FunctionParser):
        * wasm/WasmModuleParser.cpp:
        * wasm/WasmModuleParser.h:
        (JSC::Wasm::ModuleParser::ModuleParser):
        * wasm/WasmParser.h:
        (JSC::Wasm::Parser<SuccessType>::Parser):
        * wasm/WasmPlan.cpp:
        (JSC::Wasm::Plan::parseAndValidateModule):
        (JSC::Wasm::Plan::run):
        * wasm/WasmSignature.cpp: Added.
        (JSC::Wasm::Signature::dump):
        (JSC::Wasm::Signature::hash):
        (JSC::Wasm::Signature::create):
        (JSC::Wasm::Signature::createInvalid):
        (JSC::Wasm::Signature::destroy):
        (JSC::Wasm::SignatureInformation::~SignatureInformation):
        (JSC::Wasm::SignatureInformation::adopt):
        (JSC::Wasm::SignatureInformation::get):
        * wasm/WasmSignature.h: Added.
        (JSC::Wasm::Signature::Signature):
        (JSC::Wasm::Signature::storage):
        (JSC::Wasm::Signature::allocatedSize):
        (JSC::Wasm::Signature::returnType):
        (JSC::Wasm::Signature::returnCount):
        (JSC::Wasm::Signature::argumentCount):
        (JSC::Wasm::Signature::argument):
        (JSC::Wasm::Signature::operator==):
        (JSC::Wasm::SignatureHash::empty):
        (JSC::Wasm::SignatureHash::deleted):
        (JSC::Wasm::SignatureHash::SignatureHash):
        (JSC::Wasm::SignatureHash::operator==):
        (JSC::Wasm::SignatureHash::equal):
        (JSC::Wasm::SignatureHash::hash):
        (JSC::Wasm::SignatureHash::isHashTableDeletedValue):
        * wasm/WasmValidate.cpp:
        (JSC::Wasm::validateFunction):
        * wasm/WasmValidate.h:
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::create):
        * wasm/js/JSWebAssemblyModule.h:
        (JSC::JSWebAssemblyModule::signatureForFunctionIndexSpace):
        * wasm/js/JSWebAssemblyTable.cpp:
        (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
        (JSC::JSWebAssemblyTable::clearFunction):
        (JSC::JSWebAssemblyTable::setFunction):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction):
        (JSC::WebAssemblyFunction::call):
        (JSC::WebAssemblyFunction::create):
        (JSC::WebAssemblyFunction::WebAssemblyFunction):
        (JSC::WebAssemblyFunction::finishCreation):
        * wasm/js/WebAssemblyFunction.h:
        (JSC::WebAssemblyFunction::signatureIndex):
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::link):
        (JSC::WebAssemblyModuleRecord::evaluate):

2016-12-20  Konstantin Tokarev  <annulen@yandex.ru>

        Modernize for loops in JSC
        https://bugs.webkit.org/show_bug.cgi?id=166060

        Reviewed by Yusuke Suzuki.

        * API/JSCallbackObject.h:
        (JSC::JSCallbackObjectData::JSPrivatePropertyMap::visitChildren):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::propagateTransitions):
        (JSC::CodeBlock::stronglyVisitStrongReferences):
        (JSC::CodeBlock::stronglyVisitWeakReferences):
        (JSC::CodeBlock::jettison):
        (JSC::CodeBlock::getArrayProfile):
        (JSC::CodeBlock::tallyFrequentExitSites):
        (JSC::CodeBlock::nameForRegister):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ObjectPatternNode::bindValue):
        * debugger/Debugger.cpp:
        (JSC::Debugger::applyBreakpoints):
        * dfg/DFGCPSRethreadingPhase.cpp:
        (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
        * dfg/DFGClobberSet.cpp:
        (JSC::DFG::ClobberSet::setOf):
        * dfg/DFGDesiredIdentifiers.cpp:
        (JSC::DFG::DesiredIdentifiers::reallyAdd):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::visitChildren):
        * dfg/DFGIntegerCheckCombiningPhase.cpp:
        (JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
        * dfg/DFGIntegerRangeOptimizationPhase.cpp:
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::link):
        * dfg/DFGLICMPhase.cpp:
        (JSC::DFG::LICMPhase::run):
        * dfg/DFGMaximalFlushInsertionPhase.cpp:
        (JSC::DFG::MaximalFlushInsertionPhase::treatRootBlock):
        * dfg/DFGPutStackSinkingPhase.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
        (JSC::DFG::SpeculativeJIT::linkBranches):
        * dfg/DFGStructureRegistrationPhase.cpp:
        (JSC::DFG::StructureRegistrationPhase::run):
        * dfg/DFGTypeCheckHoistingPhase.cpp:
        (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
        (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
        * dfg/DFGValidate.cpp:
        * dfg/DFGVirtualRegisterAllocationPhase.cpp:
        (JSC::DFG::VirtualRegisterAllocationPhase::run):
        * heap/HeapVerifier.cpp:
        (JSC::trimDeadObjectsFromList):
        (JSC::HeapVerifier::trimDeadObjects):
        * heap/LiveObjectList.cpp:
        (JSC::LiveObjectList::findObject):
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::isPagedOut):
        * inspector/ScriptCallStack.cpp:
        (Inspector::ScriptCallStack::firstNonNativeCallFrame):
        * jit/JIT.cpp:
        (JSC::JIT::link):
        * parser/VariableEnvironment.cpp:
        (JSC::VariableEnvironment::markAllVariablesAsCaptured):
        (JSC::VariableEnvironment::hasCapturedVariables):
        * runtime/FunctionHasExecutedCache.cpp:
        (JSC::FunctionHasExecutedCache::hasExecutedAtOffset):
        (JSC::FunctionHasExecutedCache::getFunctionRanges):
        * runtime/JSPropertyNameEnumerator.cpp:
        (JSC::JSPropertyNameEnumerator::visitChildren):
        * runtime/TypeProfiler.cpp:
        (JSC::TypeProfiler::findLocation):
        * runtime/TypeSet.cpp:
        (JSC::TypeSet::addTypeInformation):
        (JSC::TypeSet::dumpTypes):
        * runtime/VM.cpp:
        (JSC::VM::gatherConservativeRoots):
        * runtime/WeakMapData.cpp:
        (JSC::WeakMapData::DeadKeyCleaner::visitWeakReferences):
        (JSC::WeakMapData::DeadKeyCleaner::finalizeUnconditionally):
        * tools/ProfileTreeNode.h:
        (JSC::ProfileTreeNode::dumpInternal):
        * yarr/YarrInterpreter.cpp:
        (JSC::Yarr::ByteCompiler::emitDisjunction):

2016-12-20  Konstantin Tokarev  <annulen@yandex.ru>

        __cpuid() requires <intrin.h> to be included
        https://bugs.webkit.org/show_bug.cgi?id=166051

        Reviewed by Yusuke Suzuki.

        * assembler/MacroAssemblerX86Common.h:

2016-12-19  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Enable ES6 Modules
        https://bugs.webkit.org/show_bug.cgi?id=165849

        Reviewed by Geoffrey Garen.

        * features.json:

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

        Rolling out r209974 and r209952. They break some websites in mysterious ways. Step 2: Rollout r209952.
        https://bugs.webkit.org/show_bug.cgi?id=166049

        Not reviewed.

        * bytecode/HandlerInfo.h:
        (JSC::HandlerInfoBase::typeName):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitReturn):
        (JSC::BytecodeGenerator::pushFinallyControlFlowScope):
        (JSC::BytecodeGenerator::pushIteratorCloseControlFlowScope):
        (JSC::BytecodeGenerator::popFinallyControlFlowScope):
        (JSC::BytecodeGenerator::popIteratorCloseControlFlowScope):
        (JSC::BytecodeGenerator::emitComplexPopScopes):
        (JSC::BytecodeGenerator::emitPopScopes):
        (JSC::BytecodeGenerator::pushTry):
        (JSC::BytecodeGenerator::popTryAndEmitCatch):
        (JSC::BytecodeGenerator::labelScopeDepth):
        (JSC::BytecodeGenerator::pushLocalControlFlowScope):
        (JSC::BytecodeGenerator::popLocalControlFlowScope):
        (JSC::BytecodeGenerator::emitEnumeration):
        (JSC::BytecodeGenerator::emitYield):
        (JSC::BytecodeGenerator::emitDelegateYield):
        (JSC::BytecodeGenerator::popTry): Deleted.
        (JSC::BytecodeGenerator::emitCatch): Deleted.
        (JSC::BytecodeGenerator::restoreScopeRegister): Deleted.
        (JSC::BytecodeGenerator::labelScopeDepthToLexicalScopeIndex): Deleted.
        (JSC::BytecodeGenerator::emitIsNumber): Deleted.
        (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded): Deleted.
        (JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded): Deleted.
        (JSC::BytecodeGenerator::emitFinallyCompletion): Deleted.
        (JSC::BytecodeGenerator::allocateFinallyRegisters): Deleted.
        (JSC::BytecodeGenerator::releaseFinallyRegisters): Deleted.
        (JSC::BytecodeGenerator::emitCompareFinallyActionAndJumpIf): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::isInFinallyBlock):
        (JSC::FinallyJump::FinallyJump): Deleted.
        (JSC::FinallyContext::FinallyContext): Deleted.
        (JSC::FinallyContext::outerContext): Deleted.
        (JSC::FinallyContext::finallyLabel): Deleted.
        (JSC::FinallyContext::depth): Deleted.
        (JSC::FinallyContext::numberOfBreaksOrContinues): Deleted.
        (JSC::FinallyContext::incNumberOfBreaksOrContinues): Deleted.
        (JSC::FinallyContext::handlesReturns): Deleted.
        (JSC::FinallyContext::setHandlesReturns): Deleted.
        (JSC::FinallyContext::registerJump): Deleted.
        (JSC::FinallyContext::numberOfJumps): Deleted.
        (JSC::FinallyContext::jumps): Deleted.
        (JSC::ControlFlowScope::ControlFlowScope): Deleted.
        (JSC::ControlFlowScope::isLabelScope): Deleted.
        (JSC::ControlFlowScope::isFinallyScope): Deleted.
        (JSC::BytecodeGenerator::currentLexicalScopeIndex): Deleted.
        (JSC::BytecodeGenerator::FinallyRegistersScope::FinallyRegistersScope): Deleted.
        (JSC::BytecodeGenerator::FinallyRegistersScope::~FinallyRegistersScope): Deleted.
        (JSC::BytecodeGenerator::finallyActionRegister): Deleted.
        (JSC::BytecodeGenerator::finallyReturnValueRegister): Deleted.
        (JSC::BytecodeGenerator::emitSetFinallyActionToNormalCompletion): Deleted.
        (JSC::BytecodeGenerator::emitSetFinallyActionToReturnCompletion): Deleted.
        (JSC::BytecodeGenerator::emitSetFinallyActionToJumpID): Deleted.
        (JSC::BytecodeGenerator::emitSetFinallyReturnValueRegister): Deleted.
        (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNormalCompletion): Deleted.
        (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotJump): Deleted.
        (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsReturnCompletion): Deleted.
        (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotReturnCompletion): Deleted.
        (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotThrowCompletion): Deleted.
        (JSC::BytecodeGenerator::emitJumpIfCompletionTypeIsThrow): Deleted.
        (JSC::BytecodeGenerator::bytecodeOffsetToJumpID): Deleted.
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ContinueNode::emitBytecode):
        (JSC::BreakNode::emitBytecode):
        (JSC::ReturnNode::emitBytecode):
        (JSC::TryNode::emitBytecode):

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

        Rolling out r209974 and r209952. They break some websites in mysterious ways. Step 1: Rollout r209974.
        https://bugs.webkit.org/show_bug.cgi?id=166049

        Not reviewed.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitEnumeration):
        (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
        (JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
        (JSC::BytecodeGenerator::emitFinallyCompletion):
        (JSC::BytecodeGenerator::allocateFinallyRegisters):
        (JSC::BytecodeGenerator::releaseFinallyRegisters):
        (JSC::BytecodeGenerator::emitCompareFinallyActionAndJumpIf):
        (JSC::BytecodeGenerator::allocateCompletionRecordRegisters): Deleted.
        (JSC::BytecodeGenerator::releaseCompletionRecordRegisters): Deleted.
        (JSC::BytecodeGenerator::emitJumpIfCompletionType): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        (JSC::FinallyJump::FinallyJump):
        (JSC::FinallyContext::registerJump):
        (JSC::BytecodeGenerator::FinallyRegistersScope::FinallyRegistersScope):
        (JSC::BytecodeGenerator::FinallyRegistersScope::~FinallyRegistersScope):
        (JSC::BytecodeGenerator::finallyActionRegister):
        (JSC::BytecodeGenerator::finallyReturnValueRegister):
        (JSC::BytecodeGenerator::emitSetFinallyActionToNormalCompletion):
        (JSC::BytecodeGenerator::emitSetFinallyActionToReturnCompletion):
        (JSC::BytecodeGenerator::emitSetFinallyActionToJumpID):
        (JSC::BytecodeGenerator::emitSetFinallyReturnValueRegister):
        (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNormalCompletion):
        (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotJump):
        (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsReturnCompletion):
        (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotReturnCompletion):
        (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotThrowCompletion):
        (JSC::BytecodeGenerator::emitJumpIfCompletionTypeIsThrow):
        (JSC::BytecodeGenerator::bytecodeOffsetToJumpID):
        (JSC::bytecodeOffsetToJumpID): Deleted.
        (JSC::BytecodeGenerator::CompletionRecordScope::CompletionRecordScope): Deleted.
        (JSC::BytecodeGenerator::CompletionRecordScope::~CompletionRecordScope): Deleted.
        (JSC::BytecodeGenerator::completionTypeRegister): Deleted.
        (JSC::BytecodeGenerator::completionValueRegister): Deleted.
        (JSC::BytecodeGenerator::emitSetCompletionType): Deleted.
        (JSC::BytecodeGenerator::emitSetCompletionValue): Deleted.
        * bytecompiler/NodesCodegen.cpp:
        (JSC::TryNode::emitBytecode):

2016-12-19  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Assertion seen in InspectorDebuggerAgent::refAsyncCallData with Inspector open
        https://bugs.webkit.org/show_bug.cgi?id=166034
        <rdar://problem/29554366>

        Reviewed by Brian Burg.

        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::refAsyncCallData):
        Remove assertion. This assert can happen if the currently executing callback
        was just explicitly cancelled by script. Existing code already handles if
        no async data was found for the given identifier.

2016-12-18  Saam Barati  <sbarati@apple.com>

        WebAssembly: Implement the WebAssembly.compile and WebAssembly.validate
        https://bugs.webkit.org/show_bug.cgi?id=165936

        Reviewed by Mark Lam.

        The APIs are documented here:
        - https://github.com/WebAssembly/design/blob/master/JS.md#webassemblycompile
        - https://github.com/WebAssembly/design/blob/master/JS.md#webassemblyvalidate

        * wasm/JSWebAssembly.cpp:
        (JSC::webAssemblyCompileFunc):
        (JSC::webAssemblyValidateFunc):
        (JSC::JSWebAssembly::finishCreation):
        * wasm/WasmPlan.cpp:
        (JSC::Wasm::Plan::parseAndValidateModule):
        (JSC::Wasm::Plan::run):
        * wasm/WasmPlan.h:
        * wasm/js/JSWebAssemblyHelpers.h:
        (JSC::getWasmBufferFromValue):
        * wasm/js/WebAssemblyModuleConstructor.cpp:
        (JSC::constructJSWebAssemblyModule):
        (JSC::callJSWebAssemblyModule):
        (JSC::WebAssemblyModuleConstructor::createModule):
        * wasm/js/WebAssemblyModuleConstructor.h:

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

        Rename finallyActionRegister to completionTypeRegister and only store int JSValues in it.
        https://bugs.webkit.org/show_bug.cgi?id=165979

        Reviewed by Saam Barati.

        This patch makes it so that we only store int JSValues in the finallyActionRegister
        thereby making type prediction on this register more successful for JITs.  In so
        doing, we are able to get some additional benefits:

        1. Renamed the following:
           FinallyRegistersScope => CompletionRecordScope
           finallyActionRegister => completionTypeRegister
           finallyReturnValueRegister => completionValueRegister

           These new names are more in line with the ES spec, which describes these
           values as the completion record and its type and value properties.
           https://tc39.github.io/ecma262/#sec-completion-record-specification-type

        2. We now think of the Break and Continue jumpIDs as encodings of CompletionType
           (in our implementation of completion type).  As a result, we only need one of
           each of the emitter methods for getting, setting, and compare-and-jump on the
           completion type.  The code using these methods also reads much clearer now.  

        3. Finally blocks' op_catch should now always pop the caught Exception object into
           the completionValueRegister instead of the completionTypeRegister (formerly
           finallyActionRegister). 

        Also removed the restoreScopeRegister() call in the IteratorClose catch block
        because that is an implementation specific synthesized catch block, and we
        can guarantee that it never needs to resolve any symbols from the scope.  Hence,
        there is no need to restore the scope register.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitEnumeration):
        (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
        (JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
        (JSC::BytecodeGenerator::emitFinallyCompletion):
        (JSC::BytecodeGenerator::allocateCompletionRecordRegisters):
        (JSC::BytecodeGenerator::releaseCompletionRecordRegisters):
        (JSC::BytecodeGenerator::emitJumpIfCompletionType):
        (JSC::BytecodeGenerator::allocateFinallyRegisters): Deleted.
        (JSC::BytecodeGenerator::releaseFinallyRegisters): Deleted.
        (JSC::BytecodeGenerator::emitCompareFinallyActionAndJumpIf): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        (JSC::bytecodeOffsetToJumpID):
        (JSC::FinallyJump::FinallyJump):
        (JSC::FinallyContext::registerJump):
        (JSC::BytecodeGenerator::CompletionRecordScope::CompletionRecordScope):
        (JSC::BytecodeGenerator::CompletionRecordScope::~CompletionRecordScope):
        (JSC::BytecodeGenerator::completionTypeRegister):
        (JSC::BytecodeGenerator::completionValueRegister):
        (JSC::BytecodeGenerator::emitSetCompletionType):
        (JSC::BytecodeGenerator::emitSetCompletionValue):
        (JSC::BytecodeGenerator::FinallyRegistersScope::FinallyRegistersScope): Deleted.
        (JSC::BytecodeGenerator::FinallyRegistersScope::~FinallyRegistersScope): Deleted.
        (JSC::BytecodeGenerator::finallyActionRegister): Deleted.
        (JSC::BytecodeGenerator::finallyReturnValueRegister): Deleted.
        (JSC::BytecodeGenerator::emitSetFinallyActionToNormalCompletion): Deleted.
        (JSC::BytecodeGenerator::emitSetFinallyActionToReturnCompletion): Deleted.
        (JSC::BytecodeGenerator::emitSetFinallyActionToJumpID): Deleted.
        (JSC::BytecodeGenerator::emitSetFinallyReturnValueRegister): Deleted.
        (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNormalCompletion): Deleted.
        (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotJump): Deleted.
        (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsReturnCompletion): Deleted.
        (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotReturnCompletion): Deleted.
        (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotThrowCompletion): Deleted.
        (JSC::BytecodeGenerator::emitJumpIfCompletionTypeIsThrow): Deleted.
        (JSC::BytecodeGenerator::bytecodeOffsetToJumpID): Deleted.
        * bytecompiler/NodesCodegen.cpp:
        (JSC::TryNode::emitBytecode):

2016-12-17  Saam Barati  <sbarati@apple.com>

        WebAssembly: WasmB3IRGenerator uses WarmAny as a ValueRep but expects the incoming value to be a register
        https://bugs.webkit.org/show_bug.cgi?id=165989

        Reviewed by Mark Lam.

        The input should be constrained to a register to match what
        the patchpoint code expects.

        * wasm/WasmB3IRGenerator.cpp:

2016-12-17  Saam Barati  <sbarati@apple.com>

        WebAssembly: Change a RELEASE_ASSERT_NOT_REACHED to a jit.breakpoint() for now to allow us to run some wasm benchmarks
        https://bugs.webkit.org/show_bug.cgi?id=165990

        Reviewed by Mark Lam.

        * wasm/WasmBinding.cpp:
        (JSC::Wasm::importStubGenerator):

2016-12-16  Joseph Pecoraro  <pecoraro@apple.com>

        JSContext Inspector: Avoid some possible exceptions inspecting a JSContext
        https://bugs.webkit.org/show_bug.cgi?id=165986
        <rdar://problem/29551379>

        Reviewed by Matt Baker.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.prototype.processProperties):
        Prefer String.prototype.endsWith now that it is available.

        (InjectedScript.prototype._describe):
        Prefer Function.prototype.toString for converting functions to String.
        Previously we were doing String(f) which would to Symbol.toPrimitive
        conversion which seems unnecessary here.

2016-12-16  Michael Catanzaro  <mcatanzaro@igalia.com>

        Unreviewed, fix GCC 6 build failure after r209952

        Return false, not nullptr, in function returning bool.

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

2016-12-16  Saam Barati  <sbarati@apple.com>

        WebAssembly: We still have some incorrect parsing productions inside unreachable code
        https://bugs.webkit.org/show_bug.cgi?id=165981

        Reviewed by Keith Miller.

        This hardens our parsing for CallIndirect and Loop/Block/If to be exactly like their reachable variant.
        
        It also fixes a more nefarious bug in which we were decoding an extra varuint32
        for Br/BrIf inside unreachable code.

        * wasm/WasmFunctionParser.h:

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

        CellState should have members with accurate names
        https://bugs.webkit.org/show_bug.cgi?id=165969

        Reviewed by Mark Lam.
        
        This once again renames the members in CellState. I wanted to convey the following
        pieces of information in the names:
        
        - What does the state mean for Generational GC?
        - What does the state mean for Concurrent GC?
        - Does the state guarantee what it means, or is there some contingency?
        
        The names I came up with are:
        
        PossiblyOldOrBlack: An object in this state may be old, or may be black, depending on
            other things. If the mark bit is set then the object is either black or being
            blackened as we speak. It's going to survive the GC, so it will be old, but may be
            new now. In between GCs, objects in this state are definitely old. If the mark bit
            is not set, then the object is actually old and white.
        
        DefinitelyNewAndWhite: The object was just allocated so it is white (not marked) and
            new.
        
        DefinitelyGrey: The object is definitely grey - it will be rescanned in the future. It
            may be new or old depending on other things.

        * heap/CellState.h:
        * heap/Heap.cpp:
        (JSC::Heap::addToRememberedSet):
        (JSC::Heap::writeBarrierSlowPath):
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::appendJSCellOrAuxiliary):
        (JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
        (JSC::SlotVisitor::appendToMarkStack):
        (JSC::SlotVisitor::visitChildren):
        * runtime/JSCellInlines.h:
        (JSC::JSCell::JSCell):
        * runtime/StructureIDBlob.h:
        (JSC::StructureIDBlob::StructureIDBlob):

2016-12-16  Saam Barati  <sbarati@apple.com>

        B3::DoubleToFloatReduction will accidentally convince itself it converted a Phi from Double to Float and then convert uses of that Phi into a use of FloatToDouble(@Phi)
        https://bugs.webkit.org/show_bug.cgi?id=165946

        Reviewed by Keith Miller.

        This was happening because the phase will convert some Phi nodes
        from Double to Float. However, one place that did this conversion
        forgot to first check if the Phi was already a Float. If it's already
        a Float, a later part of the phase will be buggy if the phase claims that it has
        converted it from Double->Float. The reason is that at the end of the
        phase, we'll look for all uses of former Double Phi nodes and make them
        be a use of ConvertFloatToDouble on the Phi, instead of a use of the Phi itself.
        This is clearly wrong if the Phi were Float to begin with (and
        therefore, the uses were Float uses to begin with).

        * b3/B3ReduceDoubleToFloat.cpp:
        * b3/testb3.cpp:
        (JSC::B3::testReduceFloatToDoubleValidates):
        (JSC::B3::run):

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

        De-duplicate finally blocks.
        https://bugs.webkit.org/show_bug.cgi?id=160168

        Reviewed by Keith Miller.

        JS execution can arrive at a finally block when there are abrupt completions from
        its try or catch block.  The abrupt completion types include Break,
        Continue, Return, and Throw.  The non-abrupt completion type is called Normal
        (i.e. the case of a try block falling through to the finally block).

        Previously, we enable each of these paths for abrupt completion (except for Throw)
        to run the finally block code by duplicating the finally block code at each of
        the sites that trigger those completions.  This patch fixes the implementation so
        that each of these abrupt completions will set a finallyActionRegister (plus a
        finallyReturnValueRegister for CompletionType::Return) and then jump to the
        relevant finally blocks, and continue to thread through subsequent outer finally
        blocks until execution reaches the outermost finally block that the completion
        type dictates.  We no longer duplicate the finally block code.

        The implementation details:
        1. We allocate a pair of finallyActionRegister and finallyReturnValueRegister
           just before entering the outermost try-catch-finally scope.

           On allocating the registers, we set them to the empty JSValue.  This serves
           to set the completion type to CompletionType::Normal (see (2) below).

        2. The finallyActionRegister serves 2 purpose:
           a. indicates the CompletionType that triggered entry into the finally block.

              This is how we encode the completion type in the finallyActionRegister:
              1. CompletionType::Normal
                 - finallyActionRegister is set to the empty JSValue.
              2. CompletionType::Break
                 - finallyActionRegister is set to the int jumpID for the site of the break statement.
              3. CompletionType::Continue
                 - finallyActionRegister is set to the int jumpID for the site of the continue statement.
              4. CompletionType::Return
                 - finallyActionRegister is set to CompletionType::Return as an int JSValue.
                 - finallyReturnValueRegister is set to the value to be returned. 
              5. CompletionType::Throw
                 - finallyActionRegister is set to the exception object that was caught by the finally block.

              Hence, if the finallyActionRegister can either be:
              1. empty i.e. we're handling CompletionType::Normal.
              2. an int JSValue i.e. we're handling CompletionType::Break, Continue, or Return.
              3. an object i.e. we're handling CompletionType::Throw.

           b. stores the exception caught in the finally block if we're handing
              CompletionType::Throw.

        3. Each finally block will have 2 entries:
           a. the entry via throw.
           b. the normal entry.

           The entry via throw is recorded in the codeBlock's exception table, and can
           only be jumped to by the VM's exception handling mechanism.

           The normal entry is recorded in a FinallyContext (at bytecode generation time
           only) and is jumped to when we want enter the finally block due any of the
           other CompletionTypes.

        4. CompletionType::Normal
           ======================
           We encounter this when falling through from a try or catch block to the finally block.  
           
           For the try block case, since finallyActionRegister is set to Normal by default,
           there's nothing more that needs to be done.

           For the catch block case, since we entered the catch block with an exception,
           finallyActionRegister may be set to Throw.  We'll need to set it to Normal
           before jumping to the finally block's normal entry.

           CompletionType::Break
           =====================
           When we emit bytecode for the BreakNode, we check if we have any FinallyContexts
           that we need to service before jumping to the breakTarget.  If we do, then:
           a. we'll register a jumpID along with the breakTarget with the outermost FinallyContext.
           b. we'll also increment the numberOfBreaksOrContinues count in each FinallyContext
              from the innermost to the outermost.
           c. instead of emitting bytecode to jump to the breakTarget, we:
              1. emit bytecode to set finallyActionRegister to the jumpID.
              b. emit bytecode to jump to the normal entry of the innermost finally block.

           Each finally block will take care of cascading to the next outer finally block
           as needed (see (5) below).

           CompletionType::Continue
           ========================
           Since continues and breaks work the same way (i.e. with a jump), we handle this
           exactly the same way as CompletionType::Break, except that we use the
           continueTarget instead of the breakTarget.

           CompletionType::Return
           ======================
           When we emit bytecode for the ReturnNode, we check if we have any FinallyContexts
           at all on the m_controlFlowScopeStack.

           If so, then instead of emitting op_ret, we:
              1. emit bytecode to set finallyActionRegister to the CompletionType::Return.
              1. emit bytecode to move the return value into finallyReturnValueRegister.
              2. emit bytecode to jump to the normal entry of the innermost finally block.

           Each finally block will take care of cascading to the next outer finally block
           as needed (see (5) below).

           CompletionType::Throw
           ======================
           The op_catch of a finally block will always store the caught exception object
           in the finallyActionRegister.  This means we're handling CompletionType::Throw
           (see (2) above).

        5. What happens in each finally block?
           ==================================
           Only the finally block's entry via throw will have an op_catch that catches the
           pending exception (and stores it in the finallyActionRegister).  This throw
           entry then falls through to the normal entry.

           The finally block's normal entry will restore the scope of the finally block
           and proceed to execute its code.

           At the end of the finally block (see emitFinallyCompletion()), the finally
           block will check the finallyActionRegister for each completion type in the
           following order:
           
           a. CompletionType::Normal: jump to the code after the finally block as
              designated by a normalCompletion label.

           b. CompletionType::Break and Continue:
              If the FinallyContext for this block has registered FinallyJumps, we'll
              check for the jumpIDs against the finallyActionRegister.  If the jumpID
              matches, jump to the corresponding jumpTarget.

              If no jumpIDs match but the FinallyContext's numberOfBreaksOrContinues is
              greater than the number of registered FinallyJumps, then this means that
              we have a Break or Continue that needs to be handled by an outer finally
              block.  In that case, jump to the outer finally block's normal entry.
              
           c. CompletionType::Return:
              If this finally block is not the outermost and finallyActionRegister contains
              CompletionType::Return, then jump to the outer finally block's normal entry.

              Otherwise, if this finally block is the outermost and finallyActionRegister
              contains CompletionType::Return, then execute op_ret and return the value
              in finallyReturnValueRegister.

           d. CompletionType::Throw:
              If we're not handling any of the above cases, then just throw the
              finallyActionRegister which contains the exception to re-throw.

        6. restoreScopeRegister()
        
           Since the needed scope objects are always stored in a local, we can restore
           the scope register by simply moving from that local instead of going through
           op_get_parent_scope.

        7. m_controlFlowScopeStack needs to be a SegmentedVector instead of a Vector.
           This makes it easier to keep a pointer to the FinallyContext on that stack,
           and not have to worry about the vector being realloc'ed due to resizing. 

        Performance appears to be neutral both on ES6SampleBench (run via cli) and the
        JSC benchmarks.

        Relevant spec references:
        https://tc39.github.io/ecma262/#sec-completion-record-specification-type
        https://tc39.github.io/ecma262/#sec-try-statement-runtime-semantics-evaluation

        * bytecode/HandlerInfo.h:
        (JSC::HandlerInfoBase::typeName):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitReturn):
        (JSC::BytecodeGenerator::pushFinallyControlFlowScope):
        (JSC::BytecodeGenerator::popFinallyControlFlowScope):
        (JSC::BytecodeGenerator::allocateAndEmitScope):
        (JSC::BytecodeGenerator::pushTry):
        (JSC::BytecodeGenerator::popTry):
        (JSC::BytecodeGenerator::emitCatch):
        (JSC::BytecodeGenerator::restoreScopeRegister):
        (JSC::BytecodeGenerator::labelScopeDepthToLexicalScopeIndex):
        (JSC::BytecodeGenerator::labelScopeDepth):
        (JSC::BytecodeGenerator::pushLocalControlFlowScope):
        (JSC::BytecodeGenerator::popLocalControlFlowScope):
        (JSC::BytecodeGenerator::emitEnumeration):
        (JSC::BytecodeGenerator::emitIsNumber):
        (JSC::BytecodeGenerator::emitYield):
        (JSC::BytecodeGenerator::emitDelegateYield):
        (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
        (JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
        (JSC::BytecodeGenerator::emitFinallyCompletion):
        (JSC::BytecodeGenerator::allocateFinallyRegisters):
        (JSC::BytecodeGenerator::releaseFinallyRegisters):
        (JSC::BytecodeGenerator::emitCompareFinallyActionAndJumpIf):
        (JSC::BytecodeGenerator::pushIteratorCloseControlFlowScope): Deleted.
        (JSC::BytecodeGenerator::popIteratorCloseControlFlowScope): Deleted.
        (JSC::BytecodeGenerator::emitComplexPopScopes): Deleted.
        (JSC::BytecodeGenerator::emitPopScopes): Deleted.
        (JSC::BytecodeGenerator::popTryAndEmitCatch): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        (JSC::FinallyJump::FinallyJump):
        (JSC::FinallyContext::FinallyContext):
        (JSC::FinallyContext::outerContext):
        (JSC::FinallyContext::finallyLabel):
        (JSC::FinallyContext::depth):
        (JSC::FinallyContext::numberOfBreaksOrContinues):
        (JSC::FinallyContext::incNumberOfBreaksOrContinues):
        (JSC::FinallyContext::handlesReturns):
        (JSC::FinallyContext::setHandlesReturns):
        (JSC::FinallyContext::registerJump):
        (JSC::FinallyContext::numberOfJumps):
        (JSC::FinallyContext::jumps):
        (JSC::ControlFlowScope::ControlFlowScope):
        (JSC::ControlFlowScope::isLabelScope):
        (JSC::ControlFlowScope::isFinallyScope):
        (JSC::BytecodeGenerator::currentLexicalScopeIndex):
        (JSC::BytecodeGenerator::FinallyRegistersScope::FinallyRegistersScope):
        (JSC::BytecodeGenerator::FinallyRegistersScope::~FinallyRegistersScope):
        (JSC::BytecodeGenerator::finallyActionRegister):
        (JSC::BytecodeGenerator::finallyReturnValueRegister):
        (JSC::BytecodeGenerator::emitSetFinallyActionToNormalCompletion):
        (JSC::BytecodeGenerator::emitSetFinallyActionToReturnCompletion):
        (JSC::BytecodeGenerator::emitSetFinallyActionToJumpID):
        (JSC::BytecodeGenerator::emitSetFinallyReturnValueRegister):
        (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNormalCompletion):
        (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotJump):
        (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsReturnCompletion):
        (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotReturnCompletion):
        (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotThrowCompletion):
        (JSC::BytecodeGenerator::emitJumpIfCompletionTypeIsThrow):
        (JSC::BytecodeGenerator::bytecodeOffsetToJumpID):
        (JSC::BytecodeGenerator::isInFinallyBlock): Deleted.
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ContinueNode::emitBytecode):
        (JSC::BreakNode::emitBytecode):
        (JSC::ReturnNode::emitBytecode):
        (JSC::TryNode::emitBytecode):

2016-12-16  Keith Miller  <keith_miller@apple.com>

        Add missing cases to parseUnreachableExpression and cleanup FunctionParser
        https://bugs.webkit.org/show_bug.cgi?id=165966

        Reviewed by Saam Barati.

        This patch adds a number of missing cases to the Wasm FunctionParser's unreachable
        code decoder. It also, removes unneeded OpType namespaces where they were not
        needed and has the unary / binary macros cover all the cases rather than
        just the simple cases.

        * wasm/WasmFunctionParser.h:

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

        Add predecessor info to dumps from JSC_dumpBytecodeLivenessResults=true.
        https://bugs.webkit.org/show_bug.cgi?id=165958

        Reviewed by Saam Barati.

        Also:
        1. refactored the code to use a common lambda function to dump FastBitVectors.
        2. list successors by their block index instead of pointers.

        * bytecode/BytecodeLivenessAnalysis.cpp:
        (JSC::BytecodeLivenessAnalysis::dumpResults):

2016-12-16  Saam Barati  <sbarati@apple.com>

        WebAssembly: WasmB3IRGenerator should throw exceptions instead of crash
        https://bugs.webkit.org/show_bug.cgi?id=165834

        Reviewed by Keith Miller.

        This patch generalizes how we throw exceptions in the Wasm::B3IRGenerator.
        There are still places where we need to throw exceptions and we don't, but
        this patch removes most of those places inside the IR generator. There are
        still a few places we need to throw exceptions inside the IR generator, like
        div/mod by 0. Those will be done in a separate patch. Also, there are
        still some stubs we need to throw exceptions from; those will also be
        done in a separate patch.

        All exceptions thrown from Wasm share a common stub. The ABI for the stub
        is to move the Wasm::ExceptionType into argGPR1 and jump to the stub.
        The stub will then throw an exception with an error message tailored
        to the particular Wasm::ExceptionType failure.

        This patch also refactors B3::Compilation. Before, B3::Compilation(VM, Procedure)
        constructor would compile a B3 function. This patch makes B3::Compilation a simple 
        tuple that keeps the necessary bits of B3 function alive in order to be runnable.
        There is a new function that actually does the compilation for you. It is:
        Compilation B3::compile(VM&, Procedure&)
        The reason for this change is that I'm now using B3::Compilation(CodeRef, OpaqueByproducts)
        constructor in Wasm code. It is weird to have a class both have a
        constructor that instantiates the tuple, and another that performs the
        compilation and then instantiates the tuple. It's more straight
        forward if Compilation's job wasn't to actually do the compilation
        but just to hold the necessary bits to keep a compiled B3 alive.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3Compilation.cpp:
        (JSC::B3::Compilation::Compilation):
        * b3/B3Compilation.h:
        * b3/B3Compile.cpp: Added.
        (JSC::B3::compile):
        * b3/B3Compile.h: Added.
        * b3/testb3.cpp:
        (JSC::B3::compile):
        * jit/ThunkGenerators.cpp:
        (JSC::throwExceptionFromWasmThunkGenerator):
        * jit/ThunkGenerators.h:
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        (JSC::Wasm::B3IRGenerator::emitExceptionCheck):
        (JSC::Wasm::createJSToWasmWrapper):
        (JSC::Wasm::parseAndCompile):
        * wasm/WasmExceptionType.h: Added.
        (JSC::Wasm::errorMessageForExceptionType):

2016-12-16  Keith Miller  <keith_miller@apple.com>

        i64.eqz should use an Int64 zero
        https://bugs.webkit.org/show_bug.cgi?id=165942

        Reviewed by Mark Lam.

        This patch fixes i64.eqz, which was using an Int32 zero
        for the comparison previously. This patch also, adds
        printing opcodes names in verbose mode.

        * wasm/WasmFunctionParser.h:
        * wasm/generateWasmOpsHeader.py:
        * wasm/wasm.json:

2016-12-15  Darin Adler  <darin@apple.com>

        Use asString instead of toWTFString, toString, or getString when we already checked isString
        https://bugs.webkit.org/show_bug.cgi?id=165895

        Reviewed by Yusuke Suzuki.

        Once we have called isString, we should always use asString and value rather than using
        functions that have to deal with non-JSString objects. This leads to slightly fewer branches,
        slightly less reference count churn, since the string is stored right inside the JSString,
        and obviates the need for exception handling.

        * bindings/ScriptValue.cpp:
        (Inspector::jsToInspectorValue): Use asString/value instead of getString.
        * dfg/DFGOperations.cpp:
        (JSC::DFG::operationMapHash): Call jsMapHash with its new arguments.
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension): Use asString/value instead
        of toWTFString.
        * inspector/JSJavaScriptCallFrame.cpp:
        (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension): Ditto.
        * inspector/agents/InspectorHeapAgent.cpp:
        (Inspector::InspectorHeapAgent::getPreview): Use asString/tryGetValue, instead of the
        peculiar getString(nullptr) that was here before.
        * jsc.cpp:
        (functionGetGetterSetter): Use asString/toIdentifier instead of the much less efficient
        toWTFString/Identifier::fromString.
        (functionIsRope): Use asString instead of jsCast<JSString*>; same thing, but we should
        prefer the asString function, since it exists.
        (functionFindTypeForExpression): Use asString/value instead of getString.
        (functionHasBasicBlockExecuted): Ditto.
        (functionBasicBlockExecutionCount): Ditto.
        (functionCreateBuiltin): Use asString/value instead of toWTFString and removed
        unneeded RETURN_IF_EXCEPTION.
        (valueWithTypeOfWasmValue): Use asString instead of jsCast<String*>.
        (box): Ditto.
        * runtime/DateConstructor.cpp:
        (JSC::constructDate): Use asString/values instead of getString.
        * runtime/ExceptionHelpers.cpp:
        (JSC::errorDescriptionForValue): Tweaked formatting.

        * runtime/HashMapImpl.h:
        (JSC::jsMapHash): Changed this function to use asString/value.

        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::dumpInContextAssumingStructure): Use asString instead of
        jsCast<JSString*>.
        (JSC::JSValue::dumpForBacktrace): Ditto.
        * runtime/JSCJSValueInlines.h:
        (JSC::toPreferredPrimitiveType): Ditto.

        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncEval): Use asString/value instead of toWTFString.

        * runtime/JSString.cpp:
        (JSC::JSString::destroy): Streamlined by removing local variable.
        (JSC::JSString::estimatedSize): Use asString instead of jsCast<JSString*>.
        (JSC::JSString::visitChildren): Ditto.
        (JSC::JSString::toThis): Ditto.
        * runtime/JSString.h:
        (JSC::JSValue::toString): Ditto.
        (JSC::JSValue::toStringOrNull): Ditto.
        * runtime/NumberPrototype.cpp:
        (JSC::numberProtoFuncValueOf): Ditto.
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncToString): Ditto.
        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncRepeatCharacter): Ditto.
        (JSC::stringProtoFuncSubstr): Ditto.
        (JSC::builtinStringSubstrInternal): Simplified assertion by removing local variable.

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

        Fix validation of non-void if blocks with no else
        https://bugs.webkit.org/show_bug.cgi?id=165938

        Reviewed by Saam Barati.

        We should not have been allowing non-void if-blocks that don't
        have an else. Since this causes a value to be placed on the
        stack that only appears under some control flow and not another.

        * wasm/WasmValidate.cpp:

2016-12-15  Filip Pizlo  <fpizlo@apple.com>

        Get rid of HeapRootVisitor and make SlotVisitor less painful to use
        https://bugs.webkit.org/show_bug.cgi?id=165911

        Reviewed by Geoffrey Garen.
        
        Previously we had two ways of adding a raw pointer to the GC's mark stack:
        
        - SlotVisitor::appendUnbarrieredXYZ() methods
        - HeapRootVisitor::visit() methods
        
        HeapRootVisitor existed only to prevent you from calling its non-WriteBarrier<> methods
        unless you had permission. But SlotVisitor would let you do it anyway, because that was
        a lot more practical.
        
        I think that we should just have one way to do it. This removes HeapRootVisitor. It
        also renames appendUnbarrieredXYZ to appendUnbarriered, and it removes the use of extra
        indirection (so you now pass const WriteBarrier<>& instead of WriteBarrier<>*).

        * API/JSCallbackObject.h:
        (JSC::JSCallbackObjectData::JSPrivatePropertyMap::visitChildren):
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Scripts/builtins/builtins_templates.py:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::visitWeakly):
        (JSC::CodeBlock::visitChildren):
        (JSC::CodeBlock::propagateTransitions):
        (JSC::CodeBlock::determineLiveness):
        (JSC::CodeBlock::visitOSRExitTargets):
        (JSC::CodeBlock::stronglyVisitStrongReferences):
        (JSC::CodeBlock::stronglyVisitWeakReferences):
        * bytecode/DirectEvalCodeCache.cpp:
        (JSC::DirectEvalCodeCache::visitAggregate):
        * bytecode/InternalFunctionAllocationProfile.h:
        (JSC::InternalFunctionAllocationProfile::visitAggregate):
        * bytecode/ObjectAllocationProfile.h:
        (JSC::ObjectAllocationProfile::visitAggregate):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::propagateTransitions):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::visitChildren):
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::visitChildren):
        * debugger/DebuggerScope.cpp:
        (JSC::DebuggerScope::visitChildren):
        * dfg/DFGDesiredTransitions.cpp:
        (JSC::DFG::DesiredTransition::visitChildren):
        * dfg/DFGDesiredWeakReferences.cpp:
        (JSC::DFG::DesiredWeakReferences::visitChildren):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::visitChildren):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::markCodeBlocks):
        (JSC::DFG::Plan::checkLivenessAndVisitChildren):
        * heap/HandleSet.cpp:
        (JSC::HandleSet::visitStrongHandles):
        * heap/HandleSet.h:
        * heap/HandleStack.cpp:
        (JSC::HandleStack::visit):
        * heap/HandleStack.h:
        * heap/Heap.cpp:
        (JSC::Heap::markToFixpoint):
        * heap/Heap.h:
        * heap/HeapRootVisitor.h: Removed.
        * heap/LargeAllocation.cpp:
        (JSC::LargeAllocation::visitWeakSet):
        * heap/LargeAllocation.h:
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::Handle::visitWeakSet):
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::visitWeakSets):
        * heap/MarkedSpace.h:
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::appendUnbarriered):
        * heap/SlotVisitor.h:
        * heap/SlotVisitorInlines.h:
        (JSC::SlotVisitor::appendUnbarriered):
        (JSC::SlotVisitor::append):
        (JSC::SlotVisitor::appendHidden):
        (JSC::SlotVisitor::appendValues):
        (JSC::SlotVisitor::appendValuesHidden):
        (JSC::SlotVisitor::appendUnbarrieredPointer): Deleted.
        (JSC::SlotVisitor::appendUnbarrieredReadOnlyPointer): Deleted.
        (JSC::SlotVisitor::appendUnbarrieredValue): Deleted.
        (JSC::SlotVisitor::appendUnbarrieredReadOnlyValue): Deleted.
        (JSC::SlotVisitor::appendUnbarrieredWeak): Deleted.
        * heap/WeakBlock.cpp:
        (JSC::WeakBlock::specializedVisit):
        (JSC::WeakBlock::visit):
        * heap/WeakBlock.h:
        * heap/WeakSet.h:
        (JSC::WeakSet::visit):
        * interpreter/ShadowChicken.cpp:
        (JSC::ShadowChicken::visitChildren):
        * jit/GCAwareJITStubRoutine.cpp:
        (JSC::MarkingGCAwareJITStubRoutine::markRequiredObjectsInternal):
        * jit/PolymorphicCallStubRoutine.cpp:
        (JSC::PolymorphicCallStubRoutine::markRequiredObjectsInternal):
        * jsc.cpp:
        (WTF::Element::visitChildren):
        (WTF::ImpureGetter::visitChildren):
        (WTF::SimpleObject::visitChildren):
        * runtime/AbstractModuleRecord.cpp:
        (JSC::AbstractModuleRecord::visitChildren):
        * runtime/ArgList.cpp:
        (JSC::MarkedArgumentBuffer::markLists):
        * runtime/ArgList.h:
        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::visitChildren):
        * runtime/DirectArguments.cpp:
        (JSC::DirectArguments::visitChildren):
        * runtime/EvalExecutable.cpp:
        (JSC::EvalExecutable::visitChildren):
        * runtime/Exception.cpp:
        (JSC::Exception::visitChildren):
        * runtime/FunctionExecutable.cpp:
        (JSC::FunctionExecutable::visitChildren):
        * runtime/FunctionRareData.cpp:
        (JSC::FunctionRareData::visitChildren):
        * runtime/GetterSetter.cpp:
        (JSC::GetterSetter::visitChildren):
        * runtime/HashMapImpl.cpp:
        (JSC::HashMapBucket<Data>::visitChildren):
        (JSC::HashMapImpl<HashMapBucket>::visitChildren):
        * runtime/InferredTypeTable.cpp:
        (JSC::InferredTypeTable::visitChildren):
        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::visitChildren):
        * runtime/IntlCollator.cpp:
        (JSC::IntlCollator::visitChildren):
        * runtime/IntlCollatorConstructor.cpp:
        (JSC::IntlCollatorConstructor::visitChildren):
        * runtime/IntlDateTimeFormat.cpp:
        (JSC::IntlDateTimeFormat::visitChildren):
        * runtime/IntlDateTimeFormatConstructor.cpp:
        (JSC::IntlDateTimeFormatConstructor::visitChildren):
        * runtime/IntlNumberFormat.cpp:
        (JSC::IntlNumberFormat::visitChildren):
        * runtime/IntlNumberFormatConstructor.cpp:
        (JSC::IntlNumberFormatConstructor::visitChildren):
        * runtime/JSBoundFunction.cpp:
        (JSC::JSBoundFunction::visitChildren):
        * runtime/JSCallee.cpp:
        (JSC::JSCallee::visitChildren):
        * runtime/JSCellInlines.h:
        (JSC::JSCell::visitChildren):
        * runtime/JSCustomGetterSetterFunction.cpp:
        (JSC::JSCustomGetterSetterFunction::visitChildren):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::visitChildren):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSMapIterator.cpp:
        (JSC::JSMapIterator::visitChildren):
        * runtime/JSModuleEnvironment.cpp:
        (JSC::JSModuleEnvironment::visitChildren):
        * runtime/JSModuleNamespaceObject.cpp:
        (JSC::JSModuleNamespaceObject::visitChildren):
        * runtime/JSModuleRecord.cpp:
        (JSC::JSModuleRecord::visitChildren):
        * runtime/JSNativeStdFunction.cpp:
        (JSC::JSNativeStdFunction::visitChildren):
        * runtime/JSObject.cpp:
        (JSC::JSObject::visitButterflyImpl):
        * runtime/JSPromiseDeferred.cpp:
        (JSC::JSPromiseDeferred::visitChildren):
        * runtime/JSPropertyNameEnumerator.cpp:
        (JSC::JSPropertyNameEnumerator::visitChildren):
        * runtime/JSPropertyNameIterator.cpp:
        (JSC::JSPropertyNameIterator::visitChildren):
        * runtime/JSProxy.cpp:
        (JSC::JSProxy::visitChildren):
        * runtime/JSScope.cpp:
        (JSC::JSScope::visitChildren):
        * runtime/JSSegmentedVariableObject.cpp:
        (JSC::JSSegmentedVariableObject::visitChildren):
        * runtime/JSSetIterator.cpp:
        (JSC::JSSetIterator::visitChildren):
        * runtime/JSString.cpp:
        (JSC::JSRopeString::visitFibers):
        * runtime/JSSymbolTableObject.cpp:
        (JSC::JSSymbolTableObject::visitChildren):
        * runtime/JSWeakMap.cpp:
        (JSC::JSWeakMap::visitChildren):
        * runtime/JSWeakSet.cpp:
        (JSC::JSWeakSet::visitChildren):
        * runtime/JSWithScope.cpp:
        (JSC::JSWithScope::visitChildren):
        * runtime/JSWrapperObject.cpp:
        (JSC::JSWrapperObject::visitChildren):
        * runtime/LazyClassStructure.cpp:
        (JSC::LazyClassStructure::visit):
        * runtime/LazyPropertyInlines.h:
        (JSC::ElementType>::visit):
        * runtime/MapBase.cpp:
        (JSC::MapBase<HashMapBucketType>::visitChildren):
        * runtime/ModuleProgramExecutable.cpp:
        (JSC::ModuleProgramExecutable::visitChildren):
        * runtime/NativeErrorConstructor.cpp:
        (JSC::NativeErrorConstructor::visitChildren):
        * runtime/ProgramExecutable.cpp:
        (JSC::ProgramExecutable::visitChildren):
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::visitChildren):
        * runtime/ProxyRevoke.cpp:
        (JSC::ProxyRevoke::visitChildren):
        * runtime/RegExpCachedResult.cpp:
        (JSC::RegExpCachedResult::visitChildren):
        * runtime/RegExpObject.cpp:
        (JSC::RegExpObject::visitChildren):
        * runtime/RegExpPrototype.cpp:
        (JSC::RegExpPrototype::visitChildren):
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::visit):
        * runtime/ScopedArguments.cpp:
        (JSC::ScopedArguments::visitChildren):
        * runtime/SmallStrings.cpp:
        (JSC::SmallStrings::visitStrongReferences):
        * runtime/SparseArrayValueMap.cpp:
        (JSC::SparseArrayValueMap::visitChildren):
        * runtime/Structure.cpp:
        (JSC::Structure::visitChildren):
        (JSC::Structure::markIfCheap):
        * runtime/StructureChain.cpp:
        (JSC::StructureChain::visitChildren):
        * runtime/StructureRareData.cpp:
        (JSC::StructureRareData::visitChildren):
        * runtime/SymbolTable.cpp:
        (JSC::SymbolTable::visitChildren):
        * runtime/TypeProfilerLog.cpp:
        (JSC::TypeProfilerLog::visit):
        * runtime/WeakMapData.cpp:
        (JSC::WeakMapData::DeadKeyCleaner::visitWeakReferences):
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::visitChildren):
        * wasm/js/JSWebAssemblyMemory.cpp:
        (JSC::JSWebAssemblyMemory::visitChildren):
        * wasm/js/JSWebAssemblyModule.cpp:
        (JSC::JSWebAssemblyModule::visitChildren):
        * wasm/js/JSWebAssemblyTable.cpp:
        (JSC::JSWebAssemblyTable::visitChildren):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::WebAssemblyFunction::visitChildren):
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::visitChildren):

2016-12-15  Myles C. Maxfield  <mmaxfield@apple.com>

        Sort Xcode project files
        https://bugs.webkit.org/show_bug.cgi?id=165937

        Reviewed by Simon Fraser.

        * JavaScriptCore.xcodeproj/project.pbxproj:

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

        Wasm should not create empty unlinked callsites
        https://bugs.webkit.org/show_bug.cgi?id=165933

        Reviewed by Mark Lam.

        Wasm would create holes in the unlinked callsite vector if B3 was able to
        eliminate the callsite.

        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::addCall):

2016-12-15  JF Bastien  <jfbastien@apple.com>

        WebAssembly: improve compilation error messages
        https://bugs.webkit.org/show_bug.cgi?id=163919

        Reviewed by Saam Barati.

        The error handling messages were underwhelming because most
        locations merely returned `false` on failure. This patch uses
        std::expected to denote that failure isn't expected. Doing this
        makes it almost impossible to mess up the code: either a function
        returns a result (or a partial result for internal helpers) or an
        error. We're not synchronizing the error string with the m_failed
        bool anymore, and the caller will abort if they try to get a
        result but the outcome was an error.

        This also shortens the code significantly using macros, while also
        judiciously preventing inlining of error handling code and biasing
        towards success using UNLIKELY. This means that the generated code
        should be more efficient (no string formatting on success, and
        regalloc can avoid these unlikely paths).

        The patch adds a few missing checks as well, especially related to
        count limits and memory allocation failure.

        As a follow-up I'd like to improve WTF::makeString further, so it
        does coercions to string and understands ADL as I did in this
        patch.

        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::fail):
        (JSC::Wasm::parseAndCompile):
        * wasm/WasmB3IRGenerator.h:
        * wasm/WasmFormat.h:
        (JSC::Wasm::isValidExternalKind):
        (JSC::Wasm::makeString):
        * wasm/WasmFunctionParser.h:
        * wasm/WasmModuleParser.cpp:
        * wasm/WasmModuleParser.h:
        * wasm/WasmParser.h:
        (JSC::Wasm::FailureHelper::makeString):
        (JSC::Wasm::Parser::fail):
        (JSC::Wasm::Parser<SuccessType>::Parser):
        (JSC::Wasm::Parser<SuccessType>::consumeCharacter):
        (JSC::Wasm::Parser<SuccessType>::consumeString):
        (JSC::Wasm::Parser<SuccessType>::consumeUTF8String):
        (JSC::Wasm::Parser<SuccessType>::parseVarUInt32):
        (JSC::Wasm::Parser<SuccessType>::parseVarUInt64):
        (JSC::Wasm::Parser<SuccessType>::parseVarInt32):
        (JSC::Wasm::Parser<SuccessType>::parseVarInt64):
        (JSC::Wasm::Parser<SuccessType>::parseUInt32):
        (JSC::Wasm::Parser<SuccessType>::parseUInt64):
        (JSC::Wasm::Parser<SuccessType>::parseUInt8):
        (JSC::Wasm::Parser<SuccessType>::parseInt7):
        (JSC::Wasm::Parser<SuccessType>::parseUInt7):
        (JSC::Wasm::Parser<SuccessType>::parseVarUInt1):
        (JSC::Wasm::Parser<SuccessType>::parseResultType):
        (JSC::Wasm::Parser<SuccessType>::parseValueType):
        (JSC::Wasm::Parser<SuccessType>::parseExternalKind):
        * wasm/WasmPlan.cpp:
        (JSC::Wasm::Plan::run):
        * wasm/WasmSections.h:
        (JSC::Wasm::isValidSection):
        (JSC::Wasm::validateOrder):
        (JSC::Wasm::makeString):
        * wasm/WasmValidate.cpp:
        (JSC::Wasm::Validate::fail):
        (JSC::Wasm::Validate::addUnreachable):
        (JSC::Wasm::validateFunction):
        * wasm/WasmValidate.h:
        * wasm/generateWasmB3IRGeneratorInlinesHeader.py:
        * wasm/generateWasmOpsHeader.py:
        * wasm/generateWasmValidateInlinesHeader.py:
        (loadMacro):
        (storeMacro):
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::constructJSWebAssemblyInstance):
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::link):

2016-12-15  JF Bastien  <jfbastien@apple.com>

        WebAssembly API: improve data section errors, initialize after Element
        https://bugs.webkit.org/show_bug.cgi?id=165733

        Reviewed by Keith Miller.

        * wasm/WasmModuleParser.cpp:
        (JSC::Wasm::ModuleParser::parseData): Data section without Memory section or import is a validation error
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::dataSegmentFail):
        (JSC::WebAssemblyModuleRecord::evaluate): tighten checks (though the spec isn't fully baked), and move after Element initialization

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

        Turn on WebAssembly by default
        https://bugs.webkit.org/show_bug.cgi?id=165918

        Reviewed by Saam Barati.

        * runtime/Options.h:

2016-12-15  Konstantin Tokarev  <annulen@yandex.ru>

        Added missing override and final specifiers
        https://bugs.webkit.org/show_bug.cgi?id=165903

        Reviewed by Darin Adler.

        * bytecompiler/BytecodeGenerator.h:
        * jsc.cpp:
        * parser/Nodes.h:

2016-12-15  Chris Dumez  <cdumez@apple.com>

        Harden JSObject::getOwnPropertyDescriptor()
        https://bugs.webkit.org/show_bug.cgi?id=165908

        Reviewed by Geoffrey Garen.

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

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

        Fix 64-bit shift family Wasm opcodes
        https://bugs.webkit.org/show_bug.cgi?id=165902

        Reviewed by Geoffrey Garen.

        The Int64 versions of the shift family B3 opcodes take an Int32
        for the shift value. Wasm, however, takes an i64, so we need to
        Trunc the shift value. Also, this fixes a bug where shr_u mapped
        to signed shift and shr_s mapped to the unsigned shift.

        * wasm/wasm.json:

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

        Wasm should decode constants correctly
        https://bugs.webkit.org/show_bug.cgi?id=165886

        Reviewed by Saam Barati.

        This patch fixes how we decode the constant part of i32, i64, f32,
        and f64.const opcodes.

        * wasm/WasmFunctionParser.h:
        (JSC::Wasm::FunctionParser<Context>::parseExpression):
        * wasm/wasm.json:

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

        WebAssembly: Add various low hanging fruit that will allow us to run the LLVM torture tests in Wasm
        https://bugs.webkit.org/show_bug.cgi?id=165883

        Reviewed by Keith Miller.

        This patch implements some low hanging fruit:
        - Exporting Table
        - Exporting Memory
        - Load16 with zero extension to both 32 and 64 bit values.
        - Fixes Unreachable to emit code that will prevent B3 from having a validation error.

        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::addUnreachable):
        (JSC::Wasm::sizeOfLoadOp):
        (JSC::Wasm::B3IRGenerator::emitLoadOp):
        * wasm/WasmFunctionParser.h:
        (JSC::Wasm::FunctionParser<Context>::parseExpression):
        * wasm/WasmModuleParser.cpp:
        (JSC::Wasm::ModuleParser::parseExport):
        * wasm/WasmValidate.cpp:
        (JSC::Wasm::Validate::addUnreachable):
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::constructJSWebAssemblyInstance):
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::finishCreation):
        (JSC::WebAssemblyModuleRecord::link):

2016-12-14  Yusuke Suzuki  <utatane.tea@gmail.com>

        Update ModuleLoader code by using the latest builtin primitives
        https://bugs.webkit.org/show_bug.cgi?id=165851

        Reviewed by Sam Weinig.

        Update the module loader code,

        1. Use @globalPrivate for the utilities, instead of setting them as the member of ModuleLoader.
        2. Use @putByValDirect instead of @push. @push is user-observable since it uses Set() operation
           and it can be observed by defining indexed setters in Array.prototype.

        * builtins/ModuleLoaderPrototype.js:
        (ensureRegistered):
        (fulfillFetch):
        (commitInstantiated):
        (requestFetch):
        (requestSatisfy):
        (setStateToMax): Deleted.
        (newRegistryEntry): Deleted.
        * runtime/ModuleLoaderPrototype.cpp:

2016-12-14  Michael Saboff  <msaboff@apple.com>

        The stress GC bot crashes in JavaScriptCore beneath ShadowChicken::update and Inspector::jsToInspectorValue
        https://bugs.webkit.org/show_bug.cgi?id=165871

        Reviewed by Mark Lam.

        This fixes two issues with the VM watch dog timer firing in a worker.

        The first issue has to do with bytecode ordering.  Prior to this change, the first few opcodes
        generated when the watch dog is enabled are:
                op_enter
                op_watchdog
                op_get_scope
        When the watchdog fires, the function will get an exception at op_watchdog.  In processing that exception,
        we'll try to update the ShadowChicken shadow stack.  That update assumes that if there is a scope 
        VirtualRegister allocated, then the slot contains a valid JSScope.  With the current bytecode ordering,
        this is not true at op_watchdog as op_enter will put JSUndefined in the scope slot.  It isn't until the
        op_get_scope gets processed that we'll have a valid scope in the slot.  The fix for this issue is to 
        ensure that op_get_scope happens before the op_watchdog.

        The second issue is that ScriptFunctionCall::call() will not tell its caller that a terminated
        execution exception happened.  Instead call() returns an empty JSValue.  InjectedScript::wrapCallFrames()
        wasn't checking for an empty JSValue, but was passing it to another function.  Added a short circuit
        return when call returns an empty JSValue.

        Added <https://bugs.webkit.org/show_bug.cgi?id=165875> to fix other callers of ScriptFunctionCall::call()
        to check for an empty JSValue return value.
        Also tracked with <rdar://problem/29671015>.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitEnter):
        * inspector/InjectedScript.cpp:
        (Inspector::InjectedScript::wrapCallFrames):

2016-12-14  Filip Pizlo  <fpizlo@apple.com>

        DirectTailCall implementation needs to tell the shuffler what to put into the ArgumentCount explicitly
        https://bugs.webkit.org/show_bug.cgi?id=165882

        Reviewed by Mark Lam.
        
        The CallFrameShuffler was assuming that the ArgumentCount that it should store into the
        callee frame is simply the size of the args vector.
        
        That's not true for DirectTailCall, which will pad the args vector with undefined if we
        are optimizing an arity mismatch. We need to pass the ArgumentCount explicitly in this
        case.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileDirectCallOrConstruct):
        (JSC::FTL::DFG::LowerDFGToB3::compileTailCall):
        * jit/CallFrameShuffleData.h:
        * jit/CallFrameShuffler.cpp:
        (JSC::CallFrameShuffler::CallFrameShuffler):
        (JSC::CallFrameShuffler::prepareAny):
        * jit/CallFrameShuffler.h:
        (JSC::CallFrameShuffler::snapshot):
        * jit/JITCall.cpp:
        (JSC::JIT::compileOpCall):

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

        WebAssembly JS API: implement Global
        https://bugs.webkit.org/show_bug.cgi?id=164133

        Reviewed by Saam Barati.

        This patch adds support for globals. It handles imports, exports
        and internal globals. In the MVP only internal globals are allowed
        to be mutable. This means we can store a C-array of 64-bit slots
        off the instance holding them. When globals are exported to JS
        they are done so as numbers. This means that i64 globals cannot be
        imported or exported.

        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        (JSC::Wasm::B3IRGenerator::getGlobal):
        (JSC::Wasm::B3IRGenerator::setGlobal):
        (JSC::Wasm::B3IRGenerator::addCallIndirect):
        (JSC::Wasm::parseAndCompile):
        * wasm/WasmFormat.h:
        * wasm/WasmFunctionParser.h:
        (JSC::Wasm::FunctionParser<Context>::parseExpression):
        * wasm/WasmModuleParser.cpp:
        (JSC::Wasm::ModuleParser::parseImport):
        (JSC::Wasm::ModuleParser::parseGlobal):
        (JSC::Wasm::ModuleParser::parseExport):
        (JSC::Wasm::ModuleParser::parseElement):
        (JSC::Wasm::ModuleParser::parseInitExpr):
        (JSC::Wasm::ModuleParser::parseGlobalType):
        (JSC::Wasm::ModuleParser::parseData):
        * wasm/WasmModuleParser.h:
        * wasm/WasmParser.h:
        (JSC::Wasm::Parser::parseVarInt32):
        (JSC::Wasm::Parser::parseVarInt64):
        (JSC::Wasm::Parser::parseUInt64):
        * wasm/WasmValidate.cpp:
        (JSC::Wasm::Validate::hasMemory):
        (JSC::Wasm::Validate::Validate):
        (JSC::Wasm::Validate::getGlobal):
        (JSC::Wasm::Validate::setGlobal):
        (JSC::Wasm::validateFunction):
        * wasm/generateWasmOpsHeader.py:
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::create):
        (JSC::JSWebAssemblyInstance::finishCreation):
        (JSC::JSWebAssemblyInstance::visitChildren):
        * wasm/js/JSWebAssemblyInstance.h:
        (JSC::JSWebAssemblyInstance::loadI32Global):
        (JSC::JSWebAssemblyInstance::loadI64Global):
        (JSC::JSWebAssemblyInstance::loadF32Global):
        (JSC::JSWebAssemblyInstance::loadF64Global):
        (JSC::JSWebAssemblyInstance::setGlobal):
        (JSC::JSWebAssemblyInstance::offsetOfGlobals):
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::constructJSWebAssemblyInstance):
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::finishCreation):
        (JSC::WebAssemblyModuleRecord::link):

2016-12-14  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, re-enable concurrent GC on ARM64 now that the most likely culprit of the memory
        regressions is fixed. Lets see what the bots think!

        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):

2016-12-14  Filip Pizlo  <fpizlo@apple.com>

        Devices with fewer cores should use a more aggressive GC schedule by default
        https://bugs.webkit.org/show_bug.cgi?id=165859

        Reviewed by Mark Lam.

        * heap/Heap.cpp:
        (JSC::Heap::markToFixpoint): Log when we have an unexpected delay in wake-up.
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::drainInParallelPassively): Don't drain passively if there aren't many cores.
        * runtime/Options.cpp:
        (JSC::overrideDefaults): Change the heuristics if we have fewer cores.
        (JSC::Options::initialize):
        * runtime/Options.h:

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

        BytecodeBasicBlock::computeImpl() should not keep iterating blocks if all jump targets have already been found.
        https://bugs.webkit.org/show_bug.cgi?id=165820

        Reviewed by Saam Barati.

        Currently, if an opcode is a branch type opcode, BytecodeBasicBlock::computeImpl()
        will iterate over all basic blocks looking for the block containing the jump
        target, and it will continue to do this even when all the jump targets have been
        found.  This is wasted work, and all the more so given that most branch type
        opcodes only have a single jump target.

        * bytecode/BytecodeBasicBlock.cpp:
        (JSC::BytecodeBasicBlock::computeImpl):

2016-12-14  Gavin Barraclough  <barraclough@apple.com>

        MarkedBlock::marksConveyLivenessDuringMarking should take into account collection scope
        https://bugs.webkit.org/show_bug.cgi?id=165741

        Unreviewed, re-landing this with fix (revert erroneous change to Options).

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/CellContainer.cpp: Added.
        (JSC::CellContainer::isNewlyAllocated):
        * heap/CellContainer.h:
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::addBlock):
        (JSC::MarkedAllocator::removeBlock):
        (JSC::MarkedAllocator::dumpBits):
        * heap/MarkedAllocator.h:
        (JSC::MarkedAllocator::forEachBitVector):
        (JSC::MarkedAllocator::forEachBitVectorWithName):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::tryCreate):
        (JSC::MarkedBlock::Handle::~Handle):
        (JSC::MarkedBlock::MarkedBlock):
        (JSC::MarkedBlock::Handle::specializedSweep):
        (JSC::MarkedBlock::Handle::sweepHelperSelectMarksMode):
        (JSC::MarkedBlock::Handle::stopAllocating):
        (JSC::MarkedBlock::Handle::resumeAllocating):
        (JSC::MarkedBlock::aboutToMarkSlow):
        (JSC::MarkedBlock::Handle::didConsumeFreeList):
        (JSC::MarkedBlock::Handle::dumpState):
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::markingVersion):
        (JSC::MarkedBlock::isMarkedRaw):
        (JSC::MarkedBlock::isMarked):
        * heap/MarkedBlockInlines.h:
        (JSC::MarkedBlock::marksConveyLivenessDuringMarking):
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::appendJSCellOrAuxiliary):
        * runtime/StructureIDTable.h:
        (JSC::StructureIDTable::size):
        (JSC::StructureIDTable::get):

2016-12-14  Chris Dumez  <cdumez@apple.com>

        Unreviewed, rolling out r209766.

        Regressed Dromaeo JSLib by ~50%

        Reverted changeset:

        "Make opaque root scanning truly constraint-based"
        https://bugs.webkit.org/show_bug.cgi?id=165760
        http://trac.webkit.org/changeset/209766

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

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

        rolled out the wrong revision (Requested by pizlo on #webkit).

        Reverted changeset:

        "MarkedBlock::marksConveyLivenessDuringMarking should take
        into account collection scope"
        https://bugs.webkit.org/show_bug.cgi?id=165741
        http://trac.webkit.org/changeset/209795

2016-12-14  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, disable concurrent GC on ARM while we investigate a memory use regression.

        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):

2016-12-13  Yusuke Suzuki  <utatane.tea@gmail.com>

        Use JSValue::toWTFString instead of calling toString(exec) and value(exec)
        https://bugs.webkit.org/show_bug.cgi?id=165795

        Reviewed by Saam Barati.

        In old days, we frequently use the idiom like, `value.toString(exec)->value(exec)` to
        get WTFString from the given JSValue. But now, we have better function, `toWTFString`.
        `toWTFString` does not create intermediate JSString objects, then reduce unnecessary
        allocations.

        This patch mechanically replaces `value.toString(exec)->value(exec)` with `toWTFString(exec)`.

        * API/JSValueRef.cpp:
        (JSValueToStringCopy):
        * bindings/ScriptValue.cpp:
        (Deprecated::ScriptValue::toString):
        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::reportAPIException):
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
        * inspector/JSJavaScriptCallFrame.cpp:
        (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension):
        * inspector/ScriptCallStackFactory.cpp:
        (Inspector::extractSourceInformationFromException):
        * runtime/ConsoleObject.cpp:
        (JSC::valueToStringWithUndefinedOrNullCheck):
        (JSC::valueOrDefaultLabelString):
        * runtime/DateConstructor.cpp:
        (JSC::dateParse):
        * runtime/DatePrototype.cpp:
        (JSC::formatLocaleDate):
        * runtime/ErrorInstance.cpp:
        (JSC::ErrorInstance::sanitizedToString):
        * runtime/ErrorPrototype.cpp:
        (JSC::errorProtoFuncToString):
        * runtime/InspectorInstrumentationObject.cpp:
        (JSC::inspectorInstrumentationObjectLog):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncEval):
        * runtime/JSModuleLoader.cpp:
        (JSC::JSModuleLoader::fetch):
        * runtime/ModuleLoaderPrototype.cpp:
        (JSC::moduleLoaderPrototypeParseModule):
        * runtime/RegExpConstructor.cpp:
        (JSC::regExpCreate):
        * runtime/RegExpPrototype.cpp:
        (JSC::regExpProtoFuncCompile):
        (JSC::regExpProtoFuncToString):
        * runtime/StringPrototype.cpp:
        (JSC::replaceUsingRegExpSearch):
        (JSC::replaceUsingStringSearch):
        (JSC::stringProtoFuncSlice):
        (JSC::stringProtoFuncSplitFast):
        (JSC::stringProtoFuncSubstr):
        (JSC::stringProtoFuncLocaleCompare):
        (JSC::stringProtoFuncBig):
        (JSC::stringProtoFuncSmall):
        (JSC::stringProtoFuncBlink):
        (JSC::stringProtoFuncBold):
        (JSC::stringProtoFuncFixed):
        (JSC::stringProtoFuncItalics):
        (JSC::stringProtoFuncStrike):
        (JSC::stringProtoFuncSub):
        (JSC::stringProtoFuncSup):
        (JSC::stringProtoFuncFontcolor):
        (JSC::stringProtoFuncFontsize):
        (JSC::stringProtoFuncAnchor):
        (JSC::stringProtoFuncLink):
        (JSC::trimString):
        (JSC::stringProtoFuncStartsWith):
        (JSC::stringProtoFuncEndsWith):
        (JSC::stringProtoFuncIncludes):
        (JSC::builtinStringIncludesInternal):
        (JSC::stringProtoFuncNormalize):
        * tools/JSDollarVMPrototype.cpp:
        (JSC::functionPrint):
        * wasm/js/JSWebAssemblyCompileError.h:
        (JSC::JSWebAssemblyCompileError::create):
        * wasm/js/JSWebAssemblyRuntimeError.h:
        (JSC::JSWebAssemblyRuntimeError::create):

2016-12-14  Gavin Barraclough  <barraclough@apple.com>

        MarkedBlock::marksConveyLivenessDuringMarking should take into account collection scope
        https://bugs.webkit.org/show_bug.cgi?id=165741

        Unreviewed rollout due to performance regression.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/CellContainer.cpp: Removed.
        * heap/CellContainer.h:
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::addBlock):
        (JSC::MarkedAllocator::removeBlock):
        (JSC::MarkedAllocator::dumpBits):
        * heap/MarkedAllocator.h:
        (JSC::MarkedAllocator::forEachBitVector):
        (JSC::MarkedAllocator::forEachBitVectorWithName):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::tryCreate):
        (JSC::MarkedBlock::Handle::~Handle):
        (JSC::MarkedBlock::MarkedBlock):
        (JSC::MarkedBlock::Handle::specializedSweep):
        (JSC::MarkedBlock::Handle::sweepHelperSelectMarksMode):
        (JSC::MarkedBlock::Handle::stopAllocating):
        (JSC::MarkedBlock::Handle::resumeAllocating):
        (JSC::MarkedBlock::aboutToMarkSlow):
        (JSC::MarkedBlock::Handle::didConsumeFreeList):
        (JSC::MarkedBlock::Handle::dumpState): Deleted.
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::isMarked):
        (JSC::MarkedBlock::markingVersion): Deleted.
        (JSC::MarkedBlock::isMarkedRaw): Deleted.
        * heap/MarkedBlockInlines.h:
        (JSC::MarkedBlock::marksConveyLivenessDuringMarking):
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::appendJSCellOrAuxiliary):
        * runtime/Options.h:
        * runtime/StructureIDTable.h:
        (JSC::StructureIDTable::get):
        (JSC::StructureIDTable::size): Deleted.

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

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

        Cause build failures (Requested by yusukesuzuki on #webkit).

        Reverted changeset:

        "Use JSValue::toWTFString instead of calling toString(exec)
        and value(exec)"
        https://bugs.webkit.org/show_bug.cgi?id=165795
        http://trac.webkit.org/changeset/209792

2016-12-13  Yusuke Suzuki  <utatane.tea@gmail.com>

        Use JSValue::toWTFString instead of calling toString(exec) and value(exec)
        https://bugs.webkit.org/show_bug.cgi?id=165795

        Reviewed by Saam Barati.

        In old days, we frequently use the idiom like, `value.toString(exec)->value(exec)` to
        get WTFString from the given JSValue. But now, we have better function, `toWTFString`.
        `toWTFString` does not create intermediate JSString objects, then reduce unnecessary
        allocations.

        This patch mechanically replaces `value.toString(exec)->value(exec)` with `toWTFString(exec)`.

        * API/JSValueRef.cpp:
        (JSValueToStringCopy):
        * bindings/ScriptValue.cpp:
        (Deprecated::ScriptValue::toString):
        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::reportAPIException):
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
        * inspector/JSJavaScriptCallFrame.cpp:
        (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension):
        * inspector/ScriptCallStackFactory.cpp:
        (Inspector::extractSourceInformationFromException):
        * runtime/ConsoleObject.cpp:
        (JSC::valueToStringWithUndefinedOrNullCheck):
        (JSC::valueOrDefaultLabelString):
        * runtime/DateConstructor.cpp:
        (JSC::dateParse):
        * runtime/DatePrototype.cpp:
        (JSC::formatLocaleDate):
        * runtime/ErrorInstance.cpp:
        (JSC::ErrorInstance::sanitizedToString):
        * runtime/ErrorPrototype.cpp:
        (JSC::errorProtoFuncToString):
        * runtime/InspectorInstrumentationObject.cpp:
        (JSC::inspectorInstrumentationObjectLog):
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::toWTFStringSlowCase):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncEval):
        * runtime/JSModuleLoader.cpp:
        (JSC::JSModuleLoader::fetch):
        * runtime/ModuleLoaderPrototype.cpp:
        (JSC::moduleLoaderPrototypeParseModule):
        * runtime/RegExpConstructor.cpp:
        (JSC::regExpCreate):
        * runtime/RegExpPrototype.cpp:
        (JSC::regExpProtoFuncCompile):
        (JSC::regExpProtoFuncToString):
        * runtime/StringPrototype.cpp:
        (JSC::replaceUsingRegExpSearch):
        (JSC::replaceUsingStringSearch):
        (JSC::stringProtoFuncSlice):
        (JSC::stringProtoFuncSplitFast):
        (JSC::stringProtoFuncSubstr):
        (JSC::stringProtoFuncLocaleCompare):
        (JSC::stringProtoFuncBig):
        (JSC::stringProtoFuncSmall):
        (JSC::stringProtoFuncBlink):
        (JSC::stringProtoFuncBold):
        (JSC::stringProtoFuncFixed):
        (JSC::stringProtoFuncItalics):
        (JSC::stringProtoFuncStrike):
        (JSC::stringProtoFuncSub):
        (JSC::stringProtoFuncSup):
        (JSC::stringProtoFuncFontcolor):
        (JSC::stringProtoFuncFontsize):
        (JSC::stringProtoFuncAnchor):
        (JSC::stringProtoFuncLink):
        (JSC::trimString):
        (JSC::stringProtoFuncStartsWith):
        (JSC::stringProtoFuncEndsWith):
        (JSC::stringProtoFuncIncludes):
        (JSC::builtinStringIncludesInternal):
        (JSC::stringProtoFuncNormalize):
        * tools/JSDollarVMPrototype.cpp:
        (JSC::functionPrint):
        * wasm/js/JSWebAssemblyCompileError.h:
        (JSC::JSWebAssemblyCompileError::create):
        * wasm/js/JSWebAssemblyRuntimeError.h:
        (JSC::JSWebAssemblyRuntimeError::create):

2016-12-13  Saam Barati  <sbarati@apple.com>

        WebAssembly: implement the elements section
        https://bugs.webkit.org/show_bug.cgi?id=165715

        Reviewed by Keith Miller.

        This is a straight forward implementation of the Element
        section in the Wasm spec:
        https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md#element-section
        
        There are a few ambiguities I encountered when implementing this, so I've
        filed bugs against the Wasm design repo, and corresponding bugzilla bugs
        for us to address after they've been discussed by the various Wasm folks:
        - https://bugs.webkit.org/show_bug.cgi?id=165827
        - https://bugs.webkit.org/show_bug.cgi?id=165826
        - https://bugs.webkit.org/show_bug.cgi?id=165825

        * wasm/WasmFormat.h:
        * wasm/WasmModuleParser.cpp:
        (JSC::Wasm::ModuleParser::parseElement):
        (JSC::Wasm::ModuleParser::parseInitExpr):
        (JSC::Wasm::ModuleParser::parseData):
        * wasm/WasmModuleParser.h:
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::evaluate):

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

        Unreviewed, rolling out r209544.

        Looks like r209489 did not cause the performance regression
        after all

        Reverted changeset:

        "Unreviewed, rolling out r209489."
        https://bugs.webkit.org/show_bug.cgi?id=165550
        http://trac.webkit.org/changeset/209544

2016-12-13  Saam Barati  <sbarati@apple.com>

        WebAssembly: implement the table section and table import
        https://bugs.webkit.org/show_bug.cgi?id=165716

        Reviewed by Keith Miller.

        This patch implements the Table space for wasm:
        https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md#table-section

        It only implements defining and importing a table. The bulk
        of this patch is implementing the various wasm Table prototype
        methods and the underlying Table object:
        https://github.com/WebAssembly/design/blob/master/JS.md#webassemblytable-constructor

        This patch also fixes a bug in our implementation with call_indirect.
        We initially implemented call_indirect as a way to call functions that
        are imported or defined in the module. This was the wrong
        interpretation of the spec. Instead, call_indirect can only index into
        the table index space.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        (JSC::Wasm::B3IRGenerator::addCallIndirect):
        (JSC::Wasm::parseAndCompile):
        * wasm/WasmFormat.h:
        (JSC::Wasm::TableInformation::TableInformation):
        (JSC::Wasm::TableInformation::operator bool):
        (JSC::Wasm::TableInformation::isImport):
        (JSC::Wasm::TableInformation::initial):
        (JSC::Wasm::TableInformation::maximum):
        (JSC::Wasm::CallableFunction::CallableFunction):
        * wasm/WasmFunctionParser.h:
        (JSC::Wasm::FunctionParser<Context>::parseExpression):
        * wasm/WasmModuleParser.cpp:
        (JSC::Wasm::ModuleParser::parseImport):
        (JSC::Wasm::ModuleParser::parseResizableLimits):
        (JSC::Wasm::ModuleParser::parseTableHelper):
        (JSC::Wasm::ModuleParser::parseTable):
        (JSC::Wasm::ModuleParser::parseMemoryHelper):
        (JSC::Wasm::ModuleParser::parseExport):
        * wasm/WasmModuleParser.h:
        * wasm/js/JSWebAssemblyHelpers.h: Added.
        (JSC::toNonWrappingUint32):
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::visitChildren):
        * wasm/js/JSWebAssemblyInstance.h:
        (JSC::JSWebAssemblyInstance::table):
        (JSC::JSWebAssemblyInstance::setTable):
        (JSC::JSWebAssemblyInstance::offsetOfTable):
        * wasm/js/JSWebAssemblyTable.cpp:
        (JSC::JSWebAssemblyTable::create):
        (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
        (JSC::JSWebAssemblyTable::visitChildren):
        (JSC::JSWebAssemblyTable::grow):
        (JSC::JSWebAssemblyTable::clearFunction):
        (JSC::JSWebAssemblyTable::setFunction):
        * wasm/js/JSWebAssemblyTable.h:
        (JSC::JSWebAssemblyTable::maximum):
        (JSC::JSWebAssemblyTable::size):
        (JSC::JSWebAssemblyTable::getFunction):
        (JSC::JSWebAssemblyTable::offsetOfSize):
        (JSC::JSWebAssemblyTable::offsetOfFunctions):
        (JSC::JSWebAssemblyTable::isValidSize):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::WebAssemblyFunction::call):
        (JSC::WebAssemblyFunction::create):
        (JSC::WebAssemblyFunction::visitChildren):
        (JSC::WebAssemblyFunction::finishCreation):
        * wasm/js/WebAssemblyFunction.h:
        (JSC::WebAssemblyFunction::signature):
        (JSC::WebAssemblyFunction::wasmEntrypoint):
        (JSC::WebAssemblyFunction::webAssemblyCallee): Deleted.
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::constructJSWebAssemblyInstance):
        * wasm/js/WebAssemblyMemoryConstructor.cpp:
        (JSC::constructJSWebAssemblyMemory):
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::finishCreation):
        (JSC::WebAssemblyModuleRecord::link):
        * wasm/js/WebAssemblyTableConstructor.cpp:
        (JSC::constructJSWebAssemblyTable):
        * wasm/js/WebAssemblyTablePrototype.cpp:
        (JSC::getTable):
        (JSC::webAssemblyTableProtoFuncLength):
        (JSC::webAssemblyTableProtoFuncGrow):
        (JSC::webAssemblyTableProtoFuncGet):
        (JSC::webAssemblyTableProtoFuncSet):
        (JSC::WebAssemblyTablePrototype::create):
        (JSC::WebAssemblyTablePrototype::finishCreation):
        * wasm/js/WebAssemblyTablePrototype.h:

2016-12-13  Filip Pizlo  <fpizlo@apple.com>

        Add null checks to opaque root APIs.

        Rubber stamped by Saam Barati. 

        If we got a crash report about null in the opaque root HashSet, we would probably not
        celebrate how great it is that we found out about a new race - instead we would probably
        be annoyed that null wasn't just silently ignored.

        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::addOpaqueRoot):
        (JSC::SlotVisitor::containsOpaqueRoot):
        (JSC::SlotVisitor::containsOpaqueRootTriState):

2016-12-13  Filip Pizlo  <fpizlo@apple.com>

        Make opaque root scanning truly constraint-based
        https://bugs.webkit.org/show_bug.cgi?id=165760

        Reviewed by Saam Barati.
        
        We have bugs when visitChildren() changes its mind about what opaque root to add, since
        we don't have barriers on opaque roots. This supposedly once worked for generational GC,
        and I started adding more barriers to support concurrent GC. But I think that the real
        bug here is that we want the JSObject->OpaqueRoot to be evaluated as a constraint that
        participates in the fixpoint. A constraint is different from the normal visiting in that
        the GC will not wait for a barrier to rescan the object.
        
        So, it's now possible for any visitChildren() method to become a constraint by calling
        slotVisitor.rescanAsConstraint(). Because opaque roots are constraints, addOpaqueRoot()
        does rescanAsConstraint() for you.
        
        The constraint set is simply a HashSet<JSCell*> that accumulates with every
        rescanAsConstraint() call and is only cleared at the start of full GC. This trivially
        resolves most classes of GC bugs that would have arisen from opaque roots being changed
        in a way that the GC did not anticipate.
        
        Looks like this is perf-neutral.
        
        * heap/Heap.cpp:
        (JSC::Heap::markToFixpoint):
        (JSC::Heap::setMutatorShouldBeFenced):
        (JSC::Heap::writeBarrierOpaqueRootSlow): Deleted.
        (JSC::Heap::addMutatorShouldBeFencedCache): Deleted.
        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::writeBarrierOpaqueRoot): Deleted.
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::visitWeakSets):
        * heap/MarkedSpace.h:
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::visitChildren):
        (JSC::SlotVisitor::visitSubsequently):
        (JSC::SlotVisitor::drain):
        (JSC::SlotVisitor::addOpaqueRoot):
        (JSC::SlotVisitor::rescanAsConstraint):
        (JSC::SlotVisitor::mergeIfNecessary):
        (JSC::SlotVisitor::mergeOpaqueRootsAndConstraints):
        (JSC::SlotVisitor::mergeOpaqueRootsIfNecessary): Deleted.
        * heap/SlotVisitor.h:
        * heap/SlotVisitorInlines.h:
        (JSC::SlotVisitor::reportExtraMemoryVisited):
        (JSC::SlotVisitor::reportExternalMemoryVisited):
        (JSC::SlotVisitor::didNotRace):
        * heap/WeakBlock.cpp:
        (JSC::WeakBlock::specializedVisit):
        (JSC::WeakBlock::visit):
        * heap/WeakBlock.h:
        * heap/WeakSet.h:
        (JSC::WeakSet::visit):

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

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

        "Broke ARMv7 builds" (Requested by msaboff on #webkit).

        Reverted changeset:

        "REGRESSION(r209653): speedometer crashes making virtual slow
        path tailcalls"
        https://bugs.webkit.org/show_bug.cgi?id=165748
        http://trac.webkit.org/changeset/209725

2016-12-13  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, revert the collectorPermittedIdleRatio back to 0 because of 100MB
        regression on membuster. Also, it didn't seem to help perf.

        * runtime/Options.h:

2016-12-13  JF Bastien  <jfbastien@apple.com>

        [WTF] Turn tryMakeString(), makeString() into variadic templates
        https://bugs.webkit.org/show_bug.cgi?id=147142

        Reviewed by Mark Lam.

        * runtime/JSStringBuilder.h:
        (JSC::jsMakeNontrivialString): remove WTF:: prefix, it isn't needed anymore
        * runtime/Lookup.cpp:
        (JSC::reifyStaticAccessor): remove WTF:: prefix, it isn't needed anymore
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncToString): remove WTF:: prefix, it isn't needed anymore

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

        Rename BytecodeGenerator's ControlFlowContext to ControlFlowScope.
        https://bugs.webkit.org/show_bug.cgi?id=165777

        Reviewed by Keith Miller.

        The existing code sometimes refer to ControlFlowContext (and associated references)
        as context, and sometimes as scope.  Let's be consistent and always call it a scope.

        Also renamed push/popScopedControlFlowContext() to push/popLocalControlFlowScope()
        because these are only used when we inc/dec the m_localScopeDepth.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::initializeVarLexicalEnvironment):
        (JSC::BytecodeGenerator::pushLexicalScopeInternal):
        (JSC::BytecodeGenerator::popLexicalScopeInternal):
        (JSC::BytecodeGenerator::emitPushWithScope):
        (JSC::BytecodeGenerator::emitPopWithScope):
        (JSC::BytecodeGenerator::pushFinallyControlFlowScope):
        (JSC::BytecodeGenerator::pushIteratorCloseControlFlowScope):
        (JSC::BytecodeGenerator::popFinallyControlFlowScope):
        (JSC::BytecodeGenerator::popIteratorCloseControlFlowScope):
        (JSC::BytecodeGenerator::emitComplexPopScopes):
        (JSC::BytecodeGenerator::emitPopScopes):
        (JSC::BytecodeGenerator::pushLocalControlFlowScope):
        (JSC::BytecodeGenerator::popLocalControlFlowScope):
        (JSC::BytecodeGenerator::emitEnumeration):
        (JSC::BytecodeGenerator::pushFinallyContext): Deleted.
        (JSC::BytecodeGenerator::pushIteratorCloseContext): Deleted.
        (JSC::BytecodeGenerator::popFinallyContext): Deleted.
        (JSC::BytecodeGenerator::popIteratorCloseContext): Deleted.
        (JSC::BytecodeGenerator::pushScopedControlFlowContext): Deleted.
        (JSC::BytecodeGenerator::popScopedControlFlowContext): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::TryNode::emitBytecode):

2016-12-12  Filip Pizlo  <fpizlo@apple.com>

        GC scheduler should avoid consecutive pauses
        https://bugs.webkit.org/show_bug.cgi?id=165758

        Reviewed by Michael Saboff.
        
        This factors out the scheduler from lambdas in Heap::markToFixpoint to an actual class.
        It's called the SpaceTimeScheduler because it is a linear controller that ties the
        amount of time you spend on things to the amount of space you are using.
        
        This patch uses this refactoring to fix a bug where the GC would pause even though we
        still had time during a mutator timeslice. This is a 15% improvement on
        JetStream/splay-latency. Seems neutral on everything else. However, it's not at all
        clear if this is the right policy or not since retreating wavefront can sometimes be so
        sensitive to scheduling decisions. For this reason, there is a tunable option that lets
        you decide how long the GC will sit idle before the start of its timeslice.
        
        So, we can revert this policy change in this patch without reverting the patch.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/Heap.cpp:
        (JSC::Heap::markToFixpoint):
        * heap/Heap.h:
        * heap/SpaceTimeScheduler.cpp: Added.
        (JSC::SpaceTimeScheduler::Decision::targetMutatorUtilization):
        (JSC::SpaceTimeScheduler::Decision::targetCollectorUtilization):
        (JSC::SpaceTimeScheduler::Decision::elapsedInPeriod):
        (JSC::SpaceTimeScheduler::Decision::phase):
        (JSC::SpaceTimeScheduler::Decision::shouldBeResumed):
        (JSC::SpaceTimeScheduler::Decision::timeToResume):
        (JSC::SpaceTimeScheduler::Decision::timeToStop):
        (JSC::SpaceTimeScheduler::SpaceTimeScheduler):
        (JSC::SpaceTimeScheduler::snapPhase):
        (JSC::SpaceTimeScheduler::currentDecision):
        * heap/SpaceTimeScheduler.h: Added.
        (JSC::SpaceTimeScheduler::Decision::Decision):
        (JSC::SpaceTimeScheduler::Decision::operator bool):
        * runtime/Options.h:

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

        REGRESSION(r209653): speedometer crashes making virtual slow path tailcalls
        https://bugs.webkit.org/show_bug.cgi?id=165748

        Reviewed by Filip Pizlo.

        The virtual slow path for tailcalls always passes arguments on the stack.
        The fix here is to link to the stack argument entrypoint instead of a register
        argument entrypoint.

        While fixing this bug, I found that we weren't clearing the code origin when
        shuffling the call frame for a register argument tailcall.

        Also rolling back in r209653, r209654, r209663, and r209673.

        * jit/CallFrameShuffler.cpp:
        (JSC::CallFrameShuffler::prepareAny):
        * jit/ThunkGenerators.cpp:
        (JSC::virtualThunkFor):

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

        Rename BytecodeGenerator's m_symbolTableStack to m_lexicalScopeStack.
        https://bugs.webkit.org/show_bug.cgi?id=165768

        Reviewed by Saam Barati.

        The lexical scope in "m_lexicalScopeStack" here refers to a pair of { } in the
        source code that bounds the scope of variables.

        There are 4 places in the code where we call m_symbolTableStack.append() to
        append a new stack entry.  In only 3 of the 4 cases, a symbol table is provided
        in the new stack entry.  In all 4 cases, a scope register is provided in the new
        stack entry.

        Also, 3 of the 4 functions that appends an entry to this stack are named:
        1. initializeVarLexicalEnvironment()
        2. pushLexicalScopeInternal()
        3. emitPushWithScope()

        The 4th function is the BytecodeGenerator constructor where it pushes the scope
        for a module environment.

        Based on these details, m_lexicalScopeStack is a better name for this stack than
        m_symbolTableStack.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
        (JSC::BytecodeGenerator::initializeVarLexicalEnvironment):
        (JSC::BytecodeGenerator::pushLexicalScopeInternal):
        (JSC::BytecodeGenerator::initializeBlockScopedFunctions):
        (JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary):
        (JSC::BytecodeGenerator::popLexicalScopeInternal):
        (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
        (JSC::BytecodeGenerator::variable):
        (JSC::BytecodeGenerator::resolveType):
        (JSC::BytecodeGenerator::emitResolveScope):
        (JSC::BytecodeGenerator::emitPushWithScope):
        (JSC::BytecodeGenerator::emitPopWithScope):
        (JSC::BytecodeGenerator::pushFinallyContext):
        (JSC::BytecodeGenerator::pushIteratorCloseContext):
        (JSC::BytecodeGenerator::emitComplexPopScopes):
        (JSC::BytecodeGenerator::popTryAndEmitCatch):
        (JSC::BytecodeGenerator::emitPushFunctionNameScope):
        * bytecompiler/BytecodeGenerator.h:

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

        Unreviewed. Try to fix the cloop build.

        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::calleeSaveRegisters):
        * interpreter/StackVisitor.h:

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

        FTL: Dumping disassembly requires that code origin is set when making polymorphic tail calls.
        https://bugs.webkit.org/show_bug.cgi?id=165747

        Reviewed by Filip Pizlo.

        Setting the code origin needs to be done for both the fast and slow path as we might need
        it when linking a polymorphic or virtual call stub.

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

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

        Unreviewed. Try to fix the linux build.

        * runtime/StackFrame.h:

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

        We should be able to throw exceptions from Wasm code and when Wasm frames are on the stack
        https://bugs.webkit.org/show_bug.cgi?id=165429

        Reviewed by Keith Miller.

        This patch teaches the stack walking runtime about wasm.
        To do this, I taught StackVisitor that a callee is not
        always an object.

        To be able to unwind callee save registers properly, I've given
        JSWebAssemblyCallee a list of RegisterAtOffsetList for the callee
        saves that B3 saved in the prologue. Also, because we have two
        B3Compilations per wasm function, one for wasm entrypoint, and
        one for the JS entrypoint, I needed to create a callee for each
        because they each might spill callee save registers.

        I also fixed a bug inside the Wasm::Memory constructor where we
        were trying to mmap the same number of bytes even after the first
        mmap failed. We should start by trying to mmap the maximum bytes,
        and if that fails, fall back to the specified initial bytes. However,
        the code was just mmapping the maximum twice. I've fixed that and
        also added a RELEASE_ASSERT_NOT_REACHED() for when the second mmap
        fails along with a FIXME to throw an OOM error.

        There was a second bug I fixed where JSModuleRecord was calling
        visitWeak on its CallLinkInfos inside ::visitChldren(). It needs
        to do this after marking. I changed JSModuleRecord to do what
        CodeBlock does and call visitWeak on its CallLinkInfos inside
        an UnconditionalFinalizer.

        * API/JSContextRef.cpp:
        (BacktraceFunctor::operator()):
        * inspector/ScriptCallStackFactory.cpp:
        (Inspector::createScriptCallStackFromException):
        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::vmEntryGlobalObject):
        * interpreter/CallFrame.h:
        (JSC::ExecState::callee):
        * interpreter/Interpreter.cpp:
        (JSC::GetStackTraceFunctor::operator()):
        (JSC::UnwindFunctor::operator()):
        (JSC::UnwindFunctor::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
        * interpreter/Interpreter.h:
        * interpreter/ShadowChicken.cpp:
        (JSC::ShadowChicken::update):
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::StackVisitor):
        (JSC::StackVisitor::readFrame):
        (JSC::StackVisitor::readNonInlinedFrame):
        (JSC::StackVisitor::readInlinedFrame):
        (JSC::StackVisitor::Frame::isWasmFrame):
        (JSC::StackVisitor::Frame::codeType):
        (JSC::StackVisitor::Frame::calleeSaveRegisters):
        (JSC::StackVisitor::Frame::functionName):
        (JSC::StackVisitor::Frame::sourceURL):
        (JSC::StackVisitor::Frame::toString):
        (JSC::StackVisitor::Frame::hasLineAndColumnInfo):
        (JSC::StackVisitor::Frame::setToEnd):
        * interpreter/StackVisitor.h:
        (JSC::StackVisitor::Frame::callee):
        (JSC::StackVisitor::Frame::isNativeFrame):
        (JSC::StackVisitor::Frame::isJSFrame): Deleted.
        * jsc.cpp:
        (callWasmFunction):
        (functionTestWasmModuleFunctions):
        * runtime/Error.cpp:
        (JSC::addErrorInfoAndGetBytecodeOffset):
        * runtime/JSCell.cpp:
        (JSC::JSCell::isAnyWasmCallee):
        * runtime/JSCell.h:
        * runtime/JSFunction.cpp:
        (JSC::RetrieveArgumentsFunctor::operator()):
        (JSC::RetrieveCallerFunctionFunctor::operator()):
        * runtime/StackFrame.cpp:
        (JSC::StackFrame::sourceID):
        (JSC::StackFrame::sourceURL):
        (JSC::StackFrame::functionName):
        (JSC::StackFrame::computeLineAndColumn):
        (JSC::StackFrame::toString):
        * runtime/StackFrame.h:
        (JSC::StackFrame::StackFrame):
        (JSC::StackFrame::hasLineAndColumnInfo):
        (JSC::StackFrame::hasBytecodeOffset):
        (JSC::StackFrame::bytecodeOffset):
        (JSC::StackFrame::isNative): Deleted.
        * runtime/VM.h:
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        (JSC::Wasm::createJSToWasmWrapper):
        (JSC::Wasm::parseAndCompile):
        * wasm/WasmCallingConvention.h:
        (JSC::Wasm::CallingConvention::setupFrameInPrologue):
        * wasm/WasmFormat.h:
        * wasm/WasmMemory.cpp:
        (JSC::Wasm::Memory::Memory):
        * wasm/WasmMemory.h:
        (JSC::Wasm::Memory::isValid):
        * wasm/WasmPlan.cpp:
        (JSC::Wasm::Plan::run):
        (JSC::Wasm::Plan::initializeCallees):
        * wasm/WasmPlan.h:
        (JSC::Wasm::Plan::jsToWasmEntryPointForFunction): Deleted.
        * wasm/js/JSWebAssemblyCallee.cpp:
        (JSC::JSWebAssemblyCallee::finishCreation):
        * wasm/js/JSWebAssemblyCallee.h:
        (JSC::JSWebAssemblyCallee::create):
        (JSC::JSWebAssemblyCallee::entrypoint):
        (JSC::JSWebAssemblyCallee::calleeSaveRegisters):
        (JSC::JSWebAssemblyCallee::jsToWasmEntryPoint): Deleted.
        * wasm/js/JSWebAssemblyModule.cpp:
        (JSC::JSWebAssemblyModule::JSWebAssemblyModule):
        (JSC::JSWebAssemblyModule::visitChildren):
        (JSC::JSWebAssemblyModule::UnconditionalFinalizer::finalizeUnconditionally):
        * wasm/js/JSWebAssemblyModule.h:
        (JSC::JSWebAssemblyModule::jsEntrypointCalleeFromFunctionIndexSpace):
        (JSC::JSWebAssemblyModule::wasmEntrypointCalleeFromFunctionIndexSpace):
        (JSC::JSWebAssemblyModule::setJSEntrypointCallee):
        (JSC::JSWebAssemblyModule::setWasmEntrypointCallee):
        (JSC::JSWebAssemblyModule::allocationSize):
        (JSC::JSWebAssemblyModule::calleeFromFunctionIndexSpace): Deleted.
        * wasm/js/JSWebAssemblyRuntimeError.h:
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::WebAssemblyFunction::call):
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::constructJSWebAssemblyInstance):
        * wasm/js/WebAssemblyMemoryConstructor.cpp:
        (JSC::constructJSWebAssemblyMemory):
        * wasm/js/WebAssemblyModuleConstructor.cpp:
        (JSC::constructJSWebAssemblyModule):
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::link):

2016-12-11  Filip Pizlo  <fpizlo@apple.com>

        Re-enable concurrent GC.

        Rubber stampted by Saam Barati.
        
        This change actually landed in r209692 by accident.

        * runtime/Options.h:

2016-12-10  Filip Pizlo  <fpizlo@apple.com>

        MarkedBlock::marksConveyLivenessDuringMarking should take into account collection scope
        https://bugs.webkit.org/show_bug.cgi?id=165741

        Reviewed by Saam Barati.
        
        MarkedBlock::marksConveyLivenessDuringMarking thought that the off-by-one marking
        version indicated liveness during any collection when it's just during full collection.
        One of its users - MarkedBlock::sweep - knew this and had a special case, but the other
        one - MarkedBlock::isLive - didn't. So, I moved the special case into
        marksConveyLivenessDuringMarking.
        
        Also, this cleans up some remaining bitvector races.
        
        To find this bug, I significantly strengthened our assertions.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/CellContainer.cpp: Added.
        (JSC::CellContainer::isNewlyAllocated):
        * heap/CellContainer.h:
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::addBlock):
        (JSC::MarkedAllocator::removeBlock):
        (JSC::MarkedAllocator::dumpBits):
        * heap/MarkedAllocator.h:
        (JSC::MarkedAllocator::forEachBitVector):
        (JSC::MarkedAllocator::forEachBitVectorWithName):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::tryCreate):
        (JSC::MarkedBlock::Handle::~Handle):
        (JSC::MarkedBlock::MarkedBlock):
        (JSC::MarkedBlock::Handle::specializedSweep):
        (JSC::MarkedBlock::Handle::sweepHelperSelectMarksMode):
        (JSC::MarkedBlock::Handle::stopAllocating):
        (JSC::MarkedBlock::Handle::resumeAllocating):
        (JSC::MarkedBlock::aboutToMarkSlow):
        (JSC::MarkedBlock::Handle::didConsumeFreeList):
        (JSC::MarkedBlock::Handle::dumpState):
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::markingVersion):
        (JSC::MarkedBlock::isMarkedRaw):
        (JSC::MarkedBlock::isMarked):
        * heap/MarkedBlockInlines.h:
        (JSC::MarkedBlock::marksConveyLivenessDuringMarking):
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::appendJSCellOrAuxiliary):
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):
        * runtime/StructureIDTable.h:
        (JSC::StructureIDTable::size):
        (JSC::StructureIDTable::get):

2016-12-10  Filip Pizlo  <fpizlo@apple.com>

        The DOM should have an advancing wavefront opaque root barrier
        https://bugs.webkit.org/show_bug.cgi?id=165712

        Reviewed by Yusuke Suzuki.
        
        This exposes the ability to fire an advancing wavefront barrier on opaque roots. It also
        gives clients the ability to maintain their own cache of whether that barrier needs to
        be enabled.
        
        The DOM uses this to enable a very cheap barrier on the DOM. This is neutral on
        Speedometer and fixes another concurrent GC crash.

        * heap/Heap.cpp:
        (JSC::Heap::beginMarking):
        (JSC::Heap::endMarking):
        (JSC::Heap::writeBarrierOpaqueRootSlow):
        (JSC::Heap::addMutatorShouldBeFencedCache):
        (JSC::Heap::setMutatorShouldBeFenced):
        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::writeBarrierOpaqueRoot):

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

        Unreviewed, rolling out r209653, r209654, r209663, and
        r209673.
        https://bugs.webkit.org/show_bug.cgi?id=165739

        speedometer crashes (Requested by pizlo on #webkit).

        Reverted changesets:

        "JSVALUE64: Pass arguments in platform argument registers when
        making JavaScript calls"
        https://bugs.webkit.org/show_bug.cgi?id=160355
        http://trac.webkit.org/changeset/209653

        "Unreviewed build fix for 32 bit builds."
        http://trac.webkit.org/changeset/209654

        "Unreviewed build fix for the CLOOP after r209653"
        http://trac.webkit.org/changeset/209663

        "REGRESSION(r209653) Crash in CallFrameShuffler::snapshot()"
        https://bugs.webkit.org/show_bug.cgi?id=165728
        http://trac.webkit.org/changeset/209673

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

        REGRESSION(r209653) Crash in CallFrameShuffler::snapshot()
        https://bugs.webkit.org/show_bug.cgi?id=165728

        Reviewed by Filip Pizlo.

        It can be the case that a JSValueReg's CachedRecovery is the source for mutliple
        GPRs. We only store the CachedRecovery in one slot of m_newRegisters to simplify
        the recovery process. This is also done for the case where the recovery source
        and destination are the same GPR.

        In light of this change, snapshot needs to be taught that one CacheRecovery is
        the source for multiple registers.  This is done by using a two step process.
        First find all the argument CachedRecovery's and create a vector mapping all of
        the target GPRs and the source recovery.  Then use that vector to get the
        recovery for each register.

        * jit/CallFrameShuffler.h:
        (JSC::CallFrameShuffler::snapshot):

2016-12-10  Keith Miller  <keith_miller@apple.com>

        Fix indirect_call if the result type is used.
        https://bugs.webkit.org/show_bug.cgi?id=165727

        Reviewed by Michael Saboff.

        The patchpoint for indirect_call assumed that the callee would be
        in params[0]. This is not the case, however, if the callee returns
        a value.

        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::addCallIndirect):

2016-12-10  Konstantin Tokarev  <annulen@yandex.ru>

        [cmake] Include WTF, JSC, and WebCore headers automatically to targers using them
        https://bugs.webkit.org/show_bug.cgi?id=165686

        Reviewed by Michael Catanzaro.

        This change reduces duplication of include path lists between modules,
        and reduces future need for fixes like r209605 (broken build because of
        WebCore header suddenly becoming used in WebKit2).

        * CMakeLists.txt:
        * PlatformEfl.cmake:
        * PlatformGTK.cmake:
        * PlatformJSCOnly.cmake:
        * PlatformMac.cmake:

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

        Unreviewed build fix for the CLOOP after r209653

        * jit/GPRInfo.h:
        Provided a definition for NUMBER_OF_JS_FUNCTION_ARGUMENT_REGISTERS when the JIT is disabled.
        * jit/JITEntryPoints.h:
        Removed #if ENABLE(JIT) protection around contents.

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

        [JSC] Module namespace object behaves like immutable prototype exotic object
        https://bugs.webkit.org/show_bug.cgi?id=165598

        Reviewed by Mark Lam.

        In the latest ECMA262 draft, the module namespace object behaves like immutable prototype exotic object.
        https://tc39.github.io/ecma262/#sec-module-namespace-exotic-objects-setprototypeof-v

        * runtime/JSModuleNamespaceObject.h:

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

        REGRESSION(r208791): Assertion in testb3
        https://bugs.webkit.org/show_bug.cgi?id=165651

        Reviewed by Saam Barati.

        Accidentally we always use edx/rdx for the result of UDiv/UMod.
        But it is incorrect. We should use eax/rax for the result of UDiv.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lowerX86UDiv):

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

        Unreviewed build fix for 32 bit builds.

        * dfg/DFGMinifiedNode.h:
        (JSC::DFG::MinifiedNode::argumentIndex): Added a static_cast<unsigned>().

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

        JSVALUE64: Pass arguments in platform argument registers when making JavaScript calls
        https://bugs.webkit.org/show_bug.cgi?id=160355

        Reviewed by Filip Pizlo.

        This patch implements passing JavaScript function arguments in registers for 64 bit platforms.

        The implemented convention follows the ABI conventions for the associated platform.
        The first two arguments are the callee and argument count, the rest of the argument registers
        contain "this" and following argument until all platform argument registers are exhausted.
        Arguments beyond what fit in registers are placed on the stack in the same location as
        before this patch.

        For X86-64 non-Windows platforms, there are 6 argument registers specified in the related ABI.
        ARM64 has had argument registers.  This allows for 4 or 6 parameter values to be placed in
        registers on these respective platforms.  This patch doesn't implement passing arguments in
        registers for 32 bit platform, since most platforms have at most 4 argument registers
        specified and 32 bit platforms use two 32 bit registers/memory locations to store one JSValue.

        The call frame on the stack in unchanged in format and the arguments that are passed in
        registers use the corresponding call frame location as a spill location. Arguments can
        also be passed on the stack. The LLInt, baseline JIT'ed code as well as the initial entry
        from C++ code base arguments on the stack. DFG s and FTL generated code pass arguments
        via registers. All callees can accept arguments either in registers or on the stack.
        The callee is responsible for moving argument to its preferred location.

        The multiple entry points to JavaSCript code is now handled via the JITEntryPoints class and
        related code.  That class now has entries for StackArgsArityCheckNotRequired,
        StackArgsMustCheckArity and for platforms that support registers arguments,
        RegisterArgsArityCheckNotRequired, RegisterArgsMustCheckArity as well as and additional
        RegisterArgsPossibleExtraArgs entry point when extra registers argument are passed.
        This last case is needed to spill those extra arguments to the corresponding call frame
        slots.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3ArgumentRegValue.h:
        * b3/B3Validate.cpp:
        * bytecode/CallLinkInfo.cpp:
        (JSC::CallLinkInfo::CallLinkInfo):
        * bytecode/CallLinkInfo.h:
        (JSC::CallLinkInfo::setUpCall):
        (JSC::CallLinkInfo::argumentsLocation):
        (JSC::CallLinkInfo::argumentsInRegisters):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generateImpl):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCPSRethreadingPhase.cpp:
        (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
        (JSC::DFG::CPSRethreadingPhase::specialCaseArguments):
        (JSC::DFG::CPSRethreadingPhase::computeIsFlushed):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGCommon.h:
        * dfg/DFGDCEPhase.cpp:
        (JSC::DFG::DCEPhase::run):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compileImpl):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGGenerationInfo.h:
        (JSC::DFG::GenerationInfo::initArgumentRegisterValue):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::needsFlushedThis):
        (JSC::DFG::Graph::addImmediateShouldSpeculateInt32):
        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::InPlaceAbstractState::initialize):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::link):
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        (JSC::DFG::JITCompiler::compileEntry): Deleted.
        * dfg/DFGJITCompiler.h:
        (JSC::DFG::JITCompiler::addJSDirectCall):
        (JSC::DFG::JITCompiler::JSDirectCallRecord::JSDirectCallRecord):
        (JSC::DFG::JITCompiler::JSDirectCallRecord::hasSlowCall):
        * dfg/DFGJITFinalizer.cpp:
        (JSC::DFG::JITFinalizer::JITFinalizer):
        (JSC::DFG::JITFinalizer::finalize):
        (JSC::DFG::JITFinalizer::finalizeFunction):
        * dfg/DFGJITFinalizer.h:
        * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
        (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlock):
        * dfg/DFGMaximalFlushInsertionPhase.cpp:
        (JSC::DFG::MaximalFlushInsertionPhase::treatRegularBlock):
        (JSC::DFG::MaximalFlushInsertionPhase::treatRootBlock):
        * dfg/DFGMayExit.cpp:
        * dfg/DFGMinifiedNode.cpp:
        (JSC::DFG::MinifiedNode::fromNode):
        * dfg/DFGMinifiedNode.h:
        (JSC::DFG::belongsInMinifiedGraph):
        * dfg/DFGNode.cpp:
        (JSC::DFG::Node::hasVariableAccessData):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::accessesStack):
        (JSC::DFG::Node::setVariableAccessData):
        (JSC::DFG::Node::hasArgumentRegisterIndex):
        (JSC::DFG::Node::argumentRegisterIndex):
        * dfg/DFGNodeType.h:
        * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
        (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
        * dfg/DFGOSREntrypointCreationPhase.cpp:
        (JSC::DFG::OSREntrypointCreationPhase::run):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGPreciseLocalClobberize.h:
        (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
        * dfg/DFGPredictionInjectionPhase.cpp:
        (JSC::DFG::PredictionInjectionPhase::run):
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGPutStackSinkingPhase.cpp:
        * dfg/DFGRegisterBank.h:
        (JSC::DFG::RegisterBank::iterator::unlock):
        (JSC::DFG::RegisterBank::unlockAtIndex):
        * dfg/DFGSSAConversionPhase.cpp:
        (JSC::DFG::SSAConversionPhase::run):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::SpeculativeJIT):
        (JSC::DFG::SpeculativeJIT::clearGenerationInfo):
        (JSC::DFG::dumpRegisterInfo):
        (JSC::DFG::SpeculativeJIT::dump):
        (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
        (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
        (JSC::DFG::SpeculativeJIT::setupArgumentRegistersForEntry):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::allocate):
        (JSC::DFG::SpeculativeJIT::spill):
        (JSC::DFG::SpeculativeJIT::generationInfoFromVirtualRegister):
        (JSC::DFG::JSValueOperand::JSValueOperand):
        (JSC::DFG::JSValueOperand::gprUseSpecific):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::fillJSValue):
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        * dfg/DFGThunks.cpp:
        (JSC::DFG::osrEntryThunkGenerator):
        * dfg/DFGVariableEventStream.cpp:
        (JSC::DFG::VariableEventStream::reconstruct):
        * dfg/DFGVirtualRegisterAllocationPhase.cpp:
        (JSC::DFG::VirtualRegisterAllocationPhase::allocateRegister):
        (JSC::DFG::VirtualRegisterAllocationPhase::run):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLJITCode.cpp:
        (JSC::FTL::JITCode::~JITCode):
        (JSC::FTL::JITCode::initializeEntrypointThunk):
        (JSC::FTL::JITCode::setEntryFor):
        (JSC::FTL::JITCode::addressForCall):
        (JSC::FTL::JITCode::executableAddressAtOffset):
        (JSC::FTL::JITCode::initializeAddressForCall): Deleted.
        (JSC::FTL::JITCode::initializeArityCheckEntrypoint): Deleted.
        * ftl/FTLJITCode.h:
        * ftl/FTLJITFinalizer.cpp:
        (JSC::FTL::JITFinalizer::finalizeFunction):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::lower):
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetArgumentRegister):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct):
        (JSC::FTL::DFG::LowerDFGToB3::compileDirectCallOrConstruct):
        (JSC::FTL::DFG::LowerDFGToB3::compileTailCall):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallEval):
        * ftl/FTLOSREntry.cpp:
        (JSC::FTL::prepareOSREntry):
        * ftl/FTLOutput.cpp:
        (JSC::FTL::Output::argumentRegister):
        (JSC::FTL::Output::argumentRegisterInt32):
        * ftl/FTLOutput.h:
        * interpreter/ShadowChicken.cpp:
        (JSC::ShadowChicken::update):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::emitDumbVirtualCall):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::spillArgumentRegistersToFrameBeforePrologue):
        (JSC::AssemblyHelpers::spillArgumentRegistersToFrame):
        (JSC::AssemblyHelpers::fillArgumentRegistersFromFrameBeforePrologue):
        (JSC::AssemblyHelpers::emitPutArgumentToCallFrameBeforePrologue):
        (JSC::AssemblyHelpers::emitPutArgumentToCallFrame):
        (JSC::AssemblyHelpers::emitGetFromCallFrameHeaderBeforePrologue):
        (JSC::AssemblyHelpers::emitGetFromCallFrameArgumentBeforePrologue):
        (JSC::AssemblyHelpers::emitGetPayloadFromCallFrameHeaderBeforePrologue):
        (JSC::AssemblyHelpers::incrementCounter):
        * jit/CachedRecovery.cpp:
        (JSC::CachedRecovery::addTargetJSValueRegs):
        * jit/CachedRecovery.h:
        (JSC::CachedRecovery::gprTargets):
        (JSC::CachedRecovery::setWantedFPR):
        (JSC::CachedRecovery::wantedJSValueRegs):
        (JSC::CachedRecovery::setWantedJSValueRegs): Deleted.
        * jit/CallFrameShuffleData.h:
        * jit/CallFrameShuffler.cpp:
        (JSC::CallFrameShuffler::CallFrameShuffler):
        (JSC::CallFrameShuffler::dump):
        (JSC::CallFrameShuffler::tryWrites):
        (JSC::CallFrameShuffler::prepareAny):
        * jit/CallFrameShuffler.h:
        (JSC::CallFrameShuffler::snapshot):
        (JSC::CallFrameShuffler::addNew):
        (JSC::CallFrameShuffler::initDangerFrontier):
        (JSC::CallFrameShuffler::updateDangerFrontier):
        (JSC::CallFrameShuffler::findDangerFrontierFrom):
        * jit/CallFrameShuffler64.cpp:
        (JSC::CallFrameShuffler::emitDisplace):
        * jit/GPRInfo.h:
        (JSC::JSValueRegs::operator==):
        (JSC::JSValueRegs::operator!=):
        (JSC::GPRInfo::toArgumentIndex):
        (JSC::argumentRegisterFor):
        (JSC::argumentRegisterForCallee):
        (JSC::argumentRegisterForArgumentCount):
        (JSC::argumentRegisterIndexForJSFunctionArgument):
        (JSC::jsFunctionArgumentForArgumentRegister):
        (JSC::argumentRegisterForFunctionArgument):
        (JSC::numberOfRegisterArgumentsFor):
        * jit/JIT.cpp:
        (JSC::JIT::compileWithoutLinking):
        (JSC::JIT::link):
        (JSC::JIT::compileCTINativeCall): Deleted.
        * jit/JIT.h:
        (JSC::JIT::compileNativeCallEntryPoints):
        * jit/JITCall.cpp:
        (JSC::JIT::compileSetupVarargsFrame):
        (JSC::JIT::compileCallEval):
        (JSC::JIT::compileCallEvalSlowCase):
        (JSC::JIT::compileOpCall):
        (JSC::JIT::compileOpCallSlowCase):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::compileCallEvalSlowCase):
        (JSC::JIT::compileOpCall):
        (JSC::JIT::compileOpCallSlowCase):
        * jit/JITCode.cpp:
        (JSC::JITCode::execute):
        (JSC::DirectJITCode::DirectJITCode):
        (JSC::DirectJITCode::initializeEntryPoints):
        (JSC::DirectJITCode::addressForCall):
        (JSC::NativeJITCode::addressForCall):
        (JSC::DirectJITCode::initializeCodeRef): Deleted.
        * jit/JITCode.h:
        (JSC::JITCode::executableAddress): Deleted.
        * jit/JITEntryPoints.h: Added.
        (JSC::JITEntryPoints::JITEntryPoints):
        (JSC::JITEntryPoints::entryFor):
        (JSC::JITEntryPoints::setEntryFor):
        (JSC::JITEntryPoints::offsetOfEntryFor):
        (JSC::JITEntryPoints::registerEntryTypeForArgumentCount):
        (JSC::JITEntryPoints::registerEntryTypeForArgumentType):
        (JSC::JITEntryPoints::clearEntries):
        (JSC::JITEntryPoints::operator=):
        (JSC::JITEntryPointsWithRef::JITEntryPointsWithRef):
        (JSC::JITEntryPointsWithRef::codeRef):
        (JSC::argumentsLocationFor):
        (JSC::registerEntryPointTypeFor):
        (JSC::entryPointTypeFor):
        (JSC::thunkEntryPointTypeFor):
        (JSC::JITJSCallThunkEntryPointsWithRef::JITJSCallThunkEntryPointsWithRef):
        (JSC::JITJSCallThunkEntryPointsWithRef::entryFor):
        (JSC::JITJSCallThunkEntryPointsWithRef::setEntryFor):
        (JSC::JITJSCallThunkEntryPointsWithRef::offsetOfEntryFor):
        (JSC::JITJSCallThunkEntryPointsWithRef::clearEntries):
        (JSC::JITJSCallThunkEntryPointsWithRef::codeRef):
        (JSC::JITJSCallThunkEntryPointsWithRef::operator=):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::privateCompileJITEntryNativeCall):
        (JSC::JIT::privateCompileCTINativeCall): Deleted.
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::privateCompileJITEntryNativeCall):
        (JSC::JIT::privateCompileCTINativeCall): Deleted.
        * jit/JITOperations.cpp:
        * jit/JITThunks.cpp:
        (JSC::JITThunks::jitEntryNativeCall):
        (JSC::JITThunks::jitEntryNativeConstruct):
        (JSC::JITThunks::jitEntryStub):
        (JSC::JITThunks::jitCallThunkEntryStub):
        (JSC::JITThunks::hostFunctionStub):
        (JSC::JITThunks::ctiNativeCall): Deleted.
        (JSC::JITThunks::ctiNativeConstruct): Deleted.
        * jit/JITThunks.h:
        * jit/JSInterfaceJIT.h:
        (JSC::JSInterfaceJIT::emitJumpIfNotInt32):
        (JSC::JSInterfaceJIT::emitLoadInt32):
        * jit/RegisterSet.cpp:
        (JSC::RegisterSet::argumentRegisters):
        * jit/RegisterSet.h:
        * jit/Repatch.cpp:
        (JSC::linkSlowFor):
        (JSC::revertCall):
        (JSC::unlinkFor):
        (JSC::linkVirtualFor):
        (JSC::linkPolymorphicCall):
        * jit/SpecializedThunkJIT.h:
        (JSC::SpecializedThunkJIT::SpecializedThunkJIT):
        (JSC::SpecializedThunkJIT::checkJSStringArgument):
        (JSC::SpecializedThunkJIT::linkFailureHere):
        (JSC::SpecializedThunkJIT::finalize):
        * jit/ThunkGenerator.h:
        * jit/ThunkGenerators.cpp:
        (JSC::createRegisterArgumentsSpillEntry):
        (JSC::slowPathFor):
        (JSC::linkCallThunkGenerator):
        (JSC::linkDirectCallThunkGenerator):
        (JSC::linkPolymorphicCallThunkGenerator):
        (JSC::virtualThunkFor):
        (JSC::nativeForGenerator):
        (JSC::nativeCallGenerator):
        (JSC::nativeTailCallGenerator):
        (JSC::nativeTailCallWithoutSavedTagsGenerator):
        (JSC::nativeConstructGenerator):
        (JSC::stringCharLoadRegCall):
        (JSC::charCodeAtThunkGenerator):
        (JSC::charAtThunkGenerator):
        (JSC::fromCharCodeThunkGenerator):
        (JSC::clz32ThunkGenerator):
        (JSC::sqrtThunkGenerator):
        (JSC::floorThunkGenerator):
        (JSC::ceilThunkGenerator):
        (JSC::truncThunkGenerator):
        (JSC::roundThunkGenerator):
        (JSC::expThunkGenerator):
        (JSC::logThunkGenerator):
        (JSC::absThunkGenerator):
        (JSC::imulThunkGenerator):
        (JSC::randomThunkGenerator):
        (JSC::boundThisNoArgsFunctionCallGenerator):
        * jit/ThunkGenerators.h:
        * jsc.cpp:
        (jscmain):
        * llint/LLIntEntrypoint.cpp:
        (JSC::LLInt::setFunctionEntrypoint):
        (JSC::LLInt::setEvalEntrypoint):
        (JSC::LLInt::setProgramEntrypoint):
        (JSC::LLInt::setModuleProgramEntrypoint):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::entryOSR):
        (JSC::LLInt::setUpCall):
        * llint/LLIntThunks.cpp:
        (JSC::LLInt::generateThunkWithJumpTo):
        (JSC::LLInt::functionForRegisterCallEntryThunkGenerator):
        (JSC::LLInt::functionForStackCallEntryThunkGenerator):
        (JSC::LLInt::functionForRegisterConstructEntryThunkGenerator):
        (JSC::LLInt::functionForStackConstructEntryThunkGenerator):
        (JSC::LLInt::functionForRegisterCallArityCheckThunkGenerator):
        (JSC::LLInt::functionForStackCallArityCheckThunkGenerator):
        (JSC::LLInt::functionForRegisterConstructArityCheckThunkGenerator):
        (JSC::LLInt::functionForStackConstructArityCheckThunkGenerator):
        (JSC::LLInt::functionForCallEntryThunkGenerator): Deleted.
        (JSC::LLInt::functionForConstructEntryThunkGenerator): Deleted.
        (JSC::LLInt::functionForCallArityCheckThunkGenerator): Deleted.
        (JSC::LLInt::functionForConstructArityCheckThunkGenerator): Deleted.
        * llint/LLIntThunks.h:
        * runtime/ArityCheckMode.h:
        * runtime/ExecutableBase.cpp:
        (JSC::ExecutableBase::clearCode):
        * runtime/ExecutableBase.h:
        (JSC::ExecutableBase::entrypointFor):
        (JSC::ExecutableBase::offsetOfEntryFor):
        (JSC::ExecutableBase::offsetOfJITCodeWithArityCheckFor): Deleted.
        * runtime/JSBoundFunction.cpp:
        (JSC::boundThisNoArgsFunctionCall):
        * runtime/NativeExecutable.cpp:
        (JSC::NativeExecutable::finishCreation):
        * runtime/ScriptExecutable.cpp:
        (JSC::ScriptExecutable::installCode):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::thunkGeneratorForIntrinsic):
        (JSC::VM::clearCounters):
        (JSC::VM::dumpCounters):
        * runtime/VM.h:
        (JSC::VM::getJITEntryStub):
        (JSC::VM::getJITCallThunkEntryStub):
        (JSC::VM::addressOfCounter):
        (JSC::VM::counterFor):
        * wasm/WasmBinding.cpp:
        (JSC::Wasm::importStubGenerator):

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

        Wasm should support call_indirect
        https://bugs.webkit.org/show_bug.cgi?id=165718

        Reviewed by Filip Pizlo.

        This patch adds support for call_indirect. The basic framework for
        an indirect call is that the module holds a buffer containing a
        stub for each function in the index space. Whenever a function
        needs to do an indirect call it gets a index into that table. In
        order to ensure call_indirect is calling a valid function the
        functionIndexSpace also needs a pointer to a canonicalized
        signature. When making an indirect call, we first check the index
        is in range, then check the signature matches the value we were given.

        This patch also differentiates between FunctionIndexSpaces and
        ImmutableFunctionIndexSpaces. Since we don't know the size of the
        FunctionIndexSpace when we start parsing we need to be able to
        resize the IndexSpace. However, once we have finished parsing all
        the sections we want to prevent an relocation of the function
        index space pointer.

        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        (JSC::Wasm::B3IRGenerator::addCall):
        (JSC::Wasm::B3IRGenerator::addCallIndirect):
        (JSC::Wasm::createJSToWasmWrapper):
        (JSC::Wasm::parseAndCompile):
        * wasm/WasmB3IRGenerator.h:
        * wasm/WasmCallingConvention.h:
        (JSC::Wasm::CallingConvention::setupCall):
        * wasm/WasmFormat.h:
        * wasm/WasmFunctionParser.h:
        (JSC::Wasm::FunctionParser::setErrorMessage):
        (JSC::Wasm::FunctionParser<Context>::FunctionParser):
        (JSC::Wasm::FunctionParser<Context>::parseExpression):
        * wasm/WasmPlan.cpp:
        (JSC::Wasm::Plan::run):
        * wasm/WasmPlan.h:
        (JSC::Wasm::Plan::takeFunctionIndexSpace):
        * wasm/WasmValidate.cpp:
        (JSC::Wasm::Validate::addCallIndirect):
        (JSC::Wasm::validateFunction):
        * wasm/WasmValidate.h:
        * wasm/js/JSWebAssemblyModule.cpp:
        (JSC::JSWebAssemblyModule::create):
        (JSC::JSWebAssemblyModule::JSWebAssemblyModule):
        * wasm/js/JSWebAssemblyModule.h:
        (JSC::JSWebAssemblyModule::signatureForFunctionIndexSpace):
        (JSC::JSWebAssemblyModule::offsetOfFunctionIndexSpace):

2016-12-09  JF Bastien  <jfbastien@apple.com>

        WebAssembly: implement data section
        https://bugs.webkit.org/show_bug.cgi?id=165696

        Reviewed by Keith Miller.

        As specified in https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md#data-section
        Note that some of the interesting corner cases are ill-defined by the spec: https://github.com/WebAssembly/design/issues/897

        * wasm/WasmFormat.h: segments are what represent sections of memory to initialize (similar to ELF's non-zero intializer data / rodata)
        (JSC::Wasm::Segment::make):
        (JSC::Wasm::Segment::destroy):
        (JSC::Wasm::Segment::byte):
        (JSC::Wasm::Segment::makePtr):
        * wasm/WasmModuleParser.cpp: parse the data section, and prevent a few overflows if a user passes in UINT_MAX (the loops would overflow)
        (JSC::Wasm::ModuleParser::parseType):
        (JSC::Wasm::ModuleParser::parseImport):
        (JSC::Wasm::ModuleParser::parseFunction):
        (JSC::Wasm::ModuleParser::parseExport):
        (JSC::Wasm::ModuleParser::parseCode):
        (JSC::Wasm::ModuleParser::parseData):
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::evaluate): the only sensible time to initialize the data section is after linking, but before calling start, I test for this but the spec isn't clear it's correct yet

2016-12-09  Karim H  <karim@karhm.com>

        It is okay to turn undefined into null because we are producing values for a
        JSON representation (InspectorValue) and JSON has a `null` value and no
        `undefined` value.
        https://bugs.webkit.org/show_bug.cgi?id=165506

        Reviewed by Darin Adler.

        * bindings/ScriptValue.cpp:
        (Inspector::jsToInspectorValue):

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

        REGRESSION (r209554-209571): stress/poly-setter-combo crashing
        https://bugs.webkit.org/show_bug.cgi?id=165669

        Reviewed by Geoffrey Garen.
        
        We now rely on objects being zero-filled in a bunch of places, not just concurrent GC.
        So, we need 32-bit to do it too.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_new_object):

2016-12-09  Eric Carlson  <eric.carlson@apple.com>

        Annotate MediaStream and WebRTC idl with EnabledAtRuntime flag
        https://bugs.webkit.org/show_bug.cgi?id=165251

        Reviewed by Dean Jackson.

        Based on a patch by Dr Alex Gouaillard <agouaillard@gmail.com>

        * runtime/CommonIdentifiers.h: Add WebRTC and MediaStream identifiers.

2016-12-09  JF Bastien  <jfbastien@apple.com>

        WebAssembly JS API: implement start function
        https://bugs.webkit.org/show_bug.cgi?id=165150

        Reviewed by Saam Barati.

        * wasm/WasmFormat.h: pass the start function around
        * wasm/WasmModuleParser.cpp:
        (JSC::Wasm::ModuleParser::parseTable): mark unreachable code
        (JSC::Wasm::ModuleParser::parseGlobal): mark unreachable code
        (JSC::Wasm::ModuleParser::parseStart): mark unreachable code
        (JSC::Wasm::ModuleParser::parseElement): mark unreachable code
        (JSC::Wasm::ModuleParser::parseData): mark unreachable code
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction): NFC: call the new function below
        (JSC::WebAssemblyFunction::call): separate this out so that the start function can use it
        * wasm/js/WebAssemblyFunction.h:
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::visitChildren): visit the start function
        (JSC::WebAssemblyModuleRecord::link): handle start function
        (JSC::WebAssemblyModuleRecord::evaluate): call the start function, if present
        * wasm/js/WebAssemblyModuleRecord.h:

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

        GC might be forced to look at a nuked object due to ordering of AllocatePropertyStorage, MaterializeNewObject, and PutStructure
        https://bugs.webkit.org/show_bug.cgi?id=165672

        Reviewed by Geoffrey Garen.
        
        We need to make sure that the shady stuff in a property put happens after the
        PutByOffset, since the PutByOffset is the place where we materialize. More generally, we
        should strive to not have any fenceposts between Nodes where a GC would be illegal.
        
        This gets us most of the way there by separating NukeStructureAndSetButterfly from
        [Re]AllocatePropertyStorage. A transitioning put will now look something like:
        
            GetButterfly
            ReallocatePropertyStorage
            PutByOffset
            NukeStructureAndSetButterfly
            PutStructure
        
        Previously the structure would get nuked by ReallocatePropertyStorage, so if we placed
        an object materialization just after it (before the PutByOffset) then any GC that
        completed at that safepoint would encounter an unresolved visit race due to seeing a
        nuked structure. We cannot have nuked structures at safepoints, and this change makes
        sure that we don't - at least until someone tries to sink to the PutStructure. We will
        eventually have to create a combined SetStructureAndButterfly node, but we don't need it
        yet.
        
        This also fixes a goof where the DFG's AllocatePropertyStorage was nulling the structure
        instead of nuking it. This could easily have caused many crashes in GC.
        
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handlePutById):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGClobbersExitState.cpp:
        (JSC::DFG::clobbersExitState):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGMayExit.cpp:
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
        (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
        (JSC::DFG::SpeculativeJIT::compileNukeStructureAndSetButterfly):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStoreBarrierInsertionPhase.cpp:
        * dfg/DFGTypeCheckHoistingPhase.cpp:
        (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileNukeStructureAndSetButterfly):
        (JSC::FTL::DFG::LowerDFGToB3::storageForTransition):
        (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorage):
        (JSC::FTL::DFG::LowerDFGToB3::reallocatePropertyStorage):
        (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorageWithSizeImpl):
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):
        * runtime/Options.h: Fix a bug - make it possible to turn on concurrent GC optionally again.

2016-12-09  Chris Dumez  <cdumez@apple.com>

        Inline JSCell::toObject()
        https://bugs.webkit.org/show_bug.cgi?id=165679

        Reviewed by Geoffrey Garen.

        Inline JSCell::toObject() as it shows on Speedometer profiles.

        * runtime/JSCell.cpp:
        (JSC::JSCell::toObjectSlow):
        (JSC::JSCell::toObject): Deleted.
        * runtime/JSCell.h:
        * runtime/JSCellInlines.h:
        (JSC::JSCell::toObject):

2016-12-09  Geoffrey Garen  <ggaren@apple.com>

        Deploy OrdinalNumber in JSC::SourceCode
        https://bugs.webkit.org/show_bug.cgi?id=165687

        Reviewed by Michael Saboff.

        We have a lot of confusion between 1-based and 0-based counting in line
        and column numbers. Let's use OrdinalNumber to clear up the confusion.

        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        (JSC::UnlinkedFunctionExecutable::link):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::emitExpressionInfo):
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::functionDetails):
        * parser/Lexer.cpp:
        (JSC::Lexer<T>::setCode):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::Parser):
        * parser/Parser.h:
        (JSC::Parser<LexerType>::parse):
        * parser/SourceCode.h:
        (JSC::SourceCode::SourceCode):
        (JSC::SourceCode::firstLine):
        (JSC::SourceCode::startColumn):
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getUnlinkedGlobalCodeBlock):
        * runtime/ScriptExecutable.h:
        (JSC::ScriptExecutable::firstLine):
        (JSC::ScriptExecutable::startColumn):
        * tools/CodeProfile.h:
        (JSC::CodeProfile::CodeProfile):

2016-12-09  Saam Barati  <sbarati@apple.com>

        WebAssembly JS API: implement importing and defining Memory
        https://bugs.webkit.org/show_bug.cgi?id=164134

        Reviewed by Keith Miller.

        This patch implements the WebAssembly.Memory object. It refactors
        the code to now associate a Memory with the instance instead of
        the Module.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * jsc.cpp:
        (functionTestWasmModuleFunctions):
        * runtime/VM.h:
        * shell/CMakeLists.txt:
        * testWasm.cpp: Removed.
        This has bitrotted. I'm removing it.

        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        (JSC::Wasm::sizeOfLoadOp):
        (JSC::Wasm::createJSToWasmWrapper):
        (JSC::Wasm::parseAndCompile):
        * wasm/WasmB3IRGenerator.h:
        * wasm/WasmFormat.cpp:
        (JSC::Wasm::ModuleInformation::~ModuleInformation): Deleted.
        * wasm/WasmFormat.h:
        * wasm/WasmMemory.cpp:
        (JSC::Wasm::Memory::Memory):
        * wasm/WasmMemory.h:
        (JSC::Wasm::Memory::size):
        (JSC::Wasm::Memory::initial):
        (JSC::Wasm::Memory::maximum):
        (JSC::Wasm::Memory::pinnedRegisters): Deleted.
        * wasm/WasmMemoryInformation.cpp: Added.
        (JSC::Wasm::MemoryInformation::MemoryInformation):
        * wasm/WasmMemoryInformation.h: Added.
        (JSC::Wasm::MemoryInformation::MemoryInformation):
        (JSC::Wasm::MemoryInformation::pinnedRegisters):
        (JSC::Wasm::MemoryInformation::initial):
        (JSC::Wasm::MemoryInformation::maximum):
        (JSC::Wasm::MemoryInformation::isImport):
        (JSC::Wasm::MemoryInformation::operator bool):
        * wasm/WasmModuleParser.cpp:
        (JSC::Wasm::ModuleParser::parseImport):
        (JSC::Wasm::ModuleParser::parseMemoryHelper):
        (JSC::Wasm::ModuleParser::parseMemory):
        (JSC::Wasm::ModuleParser::parseExport):
        * wasm/WasmModuleParser.h:
        * wasm/WasmPageCount.h: Added. Implement a new way of describing Wasm
        pages and then asking for how many bytes a quantity of pages is. This
        class also makes it clear when we're talking about bytes or pages.

        (JSC::Wasm::PageCount::PageCount):
        (JSC::Wasm::PageCount::bytes):
        (JSC::Wasm::PageCount::isValid):
        (JSC::Wasm::PageCount::max):
        (JSC::Wasm::PageCount::operator bool):
        (JSC::Wasm::PageCount::operator<):
        (JSC::Wasm::PageCount::operator>):
        (JSC::Wasm::PageCount::operator>=):
        * wasm/WasmPlan.cpp:
        (JSC::Wasm::Plan::run):
        * wasm/WasmPlan.h:
        (JSC::Wasm::Plan::memory): Deleted.
        * wasm/WasmValidate.cpp:
        (JSC::Wasm::Validate::hasMemory):
        (JSC::Wasm::Validate::Validate):
        (JSC::Wasm::validateFunction):
        * wasm/WasmValidate.h:
        * wasm/generateWasmValidateInlinesHeader.py:
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::visitChildren):
        * wasm/js/JSWebAssemblyInstance.h:
        (JSC::JSWebAssemblyInstance::memory):
        (JSC::JSWebAssemblyInstance::setMemory):
        (JSC::JSWebAssemblyInstance::offsetOfImportFunctions):
        (JSC::JSWebAssemblyInstance::allocationSize):
        * wasm/js/JSWebAssemblyMemory.cpp:
        (JSC::JSWebAssemblyMemory::create):
        (JSC::JSWebAssemblyMemory::JSWebAssemblyMemory):
        (JSC::JSWebAssemblyMemory::buffer):
        (JSC::JSWebAssemblyMemory::visitChildren):
        * wasm/js/JSWebAssemblyMemory.h:
        (JSC::JSWebAssemblyMemory::memory):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction):
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        Handle importing and creating of memory according
        to the spec. This also does the needed validation
        of making sure the memory defined in the module
        is compatible with the imported memory.

        (JSC::constructJSWebAssemblyInstance):
        * wasm/js/WebAssemblyMemoryConstructor.cpp:
        (JSC::constructJSWebAssemblyMemory):
        (JSC::callJSWebAssemblyMemory):
        * wasm/js/WebAssemblyMemoryPrototype.cpp:
        (JSC::webAssemblyMemoryProtoFuncBuffer):
        (JSC::WebAssemblyMemoryPrototype::create):
        (JSC::WebAssemblyMemoryPrototype::finishCreation):
        * wasm/js/WebAssemblyMemoryPrototype.h:
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::finishCreation):
        (JSC::WebAssemblyModuleRecord::link):

2016-12-09  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Some resources fetched via Fetch API do not have data
        https://bugs.webkit.org/show_bug.cgi?id=165230
        <rdar://problem/29449220>

        Reviewed by Alex Christensen.

        * inspector/protocol/Page.json:
        Add new Fetch Page.ResourceType.

2016-12-09  Geoffrey Garen  <ggaren@apple.com>

        TextPosition and OrdinalNumber should be more like idiomatic numbers
        https://bugs.webkit.org/show_bug.cgi?id=165678

        Reviewed by Filip Pizlo.

        Adopt default constructor.

        * API/JSBase.cpp:
        (JSEvaluateScript):
        (JSCheckScriptSyntax):
        * API/JSObjectRef.cpp:
        (JSObjectMakeFunction):
        * API/JSScriptRef.cpp:
        (OpaqueJSScript::OpaqueJSScript):
        * jsc.cpp:
        (functionCheckModuleSyntax):
        * parser/SourceCode.h:
        (JSC::makeSource):
        * parser/SourceProvider.h:
        (JSC::StringSourceProvider::create):
        (JSC::WebAssemblySourceProvider::WebAssemblySourceProvider):
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunction):
        * runtime/ModuleLoaderPrototype.cpp:
        (JSC::moduleLoaderPrototypeParseModule):

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

        Unreviewed, disable concurrent GC for real.

        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):

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

        Unreviewed, disable concurrent GC while crashes get investigated.

        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):

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

        JSSegmentedVariableObject should keep its state private

        Rubber stamped by Michael Saboff.
        
        Its state fields were protected for no reason. They really should be private because
        you have to know to obey a particular concurrency protocol when accessing them.

        * runtime/JSSegmentedVariableObject.h:

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

        Unreviewed ARM buildfix after 209570.

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

2016-12-08  JF Bastien  <jfbastien@apple.com>

        WebAssembly: JSC::link* shouldn't need a CodeBlock
        https://bugs.webkit.org/show_bug.cgi?id=165591

        Reviewed by Keith Miller.

        Allow linking without a CodeBlock, which WebAssembly's wasm -> JS stubs does. This needs to work for polymorphic and virtual calls. This patch adds corresponding tests for this.

        * assembler/LinkBuffer.cpp:
        (JSC::shouldDumpDisassemblyFor): don't look at the tier option if there isn't a CodeBlock, only look at the global one. This is a WebAssembly function, so the tier information is irrelevant.
        * jit/Repatch.cpp:
        (JSC::isWebAssemblyToJSCallee): this is used in the link* functions below
        (JSC::linkFor):
        (JSC::linkVirtualFor):
        (JSC::linkPolymorphicCall):
        * runtime/Options.h: add an option to change the maximum number of polymorphic calls in stubs from wasm to JS, which will come in handy when we try to tune performance or try merging some of the WebAssembly stubs
        * wasm/WasmBinding.cpp:
        (JSC::Wasm::importStubGenerator): remove the breakpoint since the code now works
        * wasm/js/WebAssemblyToJSCallee.h:

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

        MultiPutByOffset should get a barrier if it transitions
        https://bugs.webkit.org/show_bug.cgi?id=165646

        Reviewed by Keith Miller.
        
        Previously, if we knew that we were storing a non-cell but we needed to transition, we
        would fail to add the barrier but the FTL's lowering expected the barrier to be there.
        
        Strictly, we need to "consider" the barrier on MultiPutByOffset if the value is
        possibly a cell or if the MultiPutByOffset may transition. Then "considering" the
        barrier implies checking if the base is possibly old.
        
        But because the barrier is so cheap anyway, this patch implements something safer: we
        just consider the barrier on MultiPutByOffset unconditionally, which opts it out of any
        barrier optimizations other than those based on the predicted state of the base. Those
        optimizations are already sound - for example they use doesGC() to detect safepoints
        and that function correctly predicts when MultiPutByOffset could GC.
        
        Because the barrier optimizations are only a very small speed-up, I think it's great to
        fix bugs by weakening the optimizer without cleverness.

        * dfg/DFGFixupPhase.cpp:
        * dfg/DFGStoreBarrierInsertionPhase.cpp:
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::assertValidCell):

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

        Enable concurrent GC on ARM64
        https://bugs.webkit.org/show_bug.cgi?id=165643

        Reviewed by Saam Barati.

        It looks stable enough to enable.

        * assembler/CPU.h:
        (JSC::useGCFences): Deleted.
        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generateImpl):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
        (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
        (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorage):
        (JSC::FTL::DFG::LowerDFGToB3::reallocatePropertyStorage):
        (JSC::FTL::DFG::LowerDFGToB3::allocateObject):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::mutatorFence):
        (JSC::AssemblyHelpers::storeButterfly):
        (JSC::AssemblyHelpers::nukeStructureAndStoreButterfly):
        (JSC::AssemblyHelpers::emitInitializeInlineStorage):
        (JSC::AssemblyHelpers::emitInitializeOutOfLineStorage):
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):

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

        Disable collectContinuously if not useConcurrentGC

        Rubber stamped by Geoffrey Garen.

        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):

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

        Unreviewed, fix cloop build.

        * runtime/JSObject.h:

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

        Concurrent GC should be stable enough to land enabled on X86_64
        https://bugs.webkit.org/show_bug.cgi?id=164990

        Reviewed by Geoffrey Garen.
        
        This fixes a ton of performance and correctness bugs revealed by getting the concurrent GC to
        be stable enough to land enabled.
        
        I had to redo the JSObject::visitChildren concurrency protocol again. This time I think it's
        even more correct than ever!
        
        This is an enormous win on JetStream/splay-latency and Octane/SplayLatency. It looks to be
        mostly neutral on everything else, though Speedometer is showing statistically weak signs of a
        slight regression.

        * API/JSAPIWrapperObject.mm: Added locking.
        (JSC::JSAPIWrapperObject::visitChildren):
        * API/JSCallbackObject.h: Added locking.
        (JSC::JSCallbackObjectData::visitChildren):
        (JSC::JSCallbackObjectData::JSPrivatePropertyMap::setPrivateProperty):
        (JSC::JSCallbackObjectData::JSPrivatePropertyMap::deletePrivateProperty):
        (JSC::JSCallbackObjectData::JSPrivatePropertyMap::visitChildren):
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::UnconditionalFinalizer::finalizeUnconditionally): This had a TOCTOU race on shouldJettisonDueToOldAge.
        (JSC::EvalCodeCache::visitAggregate): Moved to EvalCodeCache.cpp.
        * bytecode/DirectEvalCodeCache.cpp: Added. Outlined some functions and made them use locks.
        (JSC::DirectEvalCodeCache::setSlow):
        (JSC::DirectEvalCodeCache::clear):
        (JSC::DirectEvalCodeCache::visitAggregate):
        * bytecode/DirectEvalCodeCache.h:
        (JSC::DirectEvalCodeCache::set):
        (JSC::DirectEvalCodeCache::clear): Deleted.
        * bytecode/UnlinkedCodeBlock.cpp: Added locking.
        (JSC::UnlinkedCodeBlock::visitChildren):
        (JSC::UnlinkedCodeBlock::setInstructions):
        (JSC::UnlinkedCodeBlock::shrinkToFit):
        * bytecode/UnlinkedCodeBlock.h: Added locking.
        (JSC::UnlinkedCodeBlock::addRegExp):
        (JSC::UnlinkedCodeBlock::addConstant):
        (JSC::UnlinkedCodeBlock::addFunctionDecl):
        (JSC::UnlinkedCodeBlock::addFunctionExpr):
        (JSC::UnlinkedCodeBlock::createRareDataIfNecessary):
        (JSC::UnlinkedCodeBlock::shrinkToFit): Deleted.
        * debugger/Debugger.cpp: Use the right delete API.
        (JSC::Debugger::recompileAllJSFunctions):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): Fix a pre-existing bug in ToFunction constant folding.
        * dfg/DFGClobberize.h: Add support for nuking.
        (JSC::DFG::clobberize):
        * dfg/DFGClobbersExitState.cpp: Add support for nuking.
        (JSC::DFG::clobbersExitState):
        * dfg/DFGFixupPhase.cpp: Add support for nuking.
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::indexForChecks):
        (JSC::DFG::FixupPhase::originForCheck):
        (JSC::DFG::FixupPhase::speculateForBarrier):
        (JSC::DFG::FixupPhase::insertCheck):
        (JSC::DFG::FixupPhase::fixupChecksInBlock):
        * dfg/DFGSpeculativeJIT.cpp: Add support for nuking.
        (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
        (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
        * ftl/FTLLowerDFGToB3.cpp: Add support for nuking.
        (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorage):
        (JSC::FTL::DFG::LowerDFGToB3::reallocatePropertyStorage):
        (JSC::FTL::DFG::LowerDFGToB3::mutatorFence):
        (JSC::FTL::DFG::LowerDFGToB3::nukeStructureAndSetButterfly):
        (JSC::FTL::DFG::LowerDFGToB3::setButterfly): Deleted.
        * heap/CodeBlockSet.cpp: We need to be more careful about the CodeBlockSet workflow during GC, since we will allocate CodeBlocks in eden while collecting.
        (JSC::CodeBlockSet::clearMarksForFullCollection):
        (JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
        * heap/Heap.cpp: Added code to measure max pauses. Added a better collectContinuously mode.
        (JSC::Heap::lastChanceToFinalize): Stop the collectContinuously thread.
        (JSC::Heap::harvestWeakReferences): Inline SlotVisitor::harvestWeakReferences.
        (JSC::Heap::finalizeUnconditionalFinalizers): Inline SlotVisitor::finalizeUnconditionalReferences.
        (JSC::Heap::markToFixpoint): We need to do some MarkedSpace stuff before every conservative scan, rather than just at the start of marking, so we now call prepareForConservativeScan() before each conservative scan. Also call a less-parallel version of drainInParallel when the mutator is running.
        (JSC::Heap::collectInThread): Inline Heap::prepareForAllocation().
        (JSC::Heap::stopIfNecessarySlow): We need to be more careful about ensuring that we run finalization before and after stopping. Also, we should sanitize stack when stopping the world.
        (JSC::Heap::acquireAccessSlow): Add some optional debug prints.
        (JSC::Heap::handleNeedFinalize): Assert that we are running this when the world is not stopped.
        (JSC::Heap::finalize): Remove the old collectContinuously code.
        (JSC::Heap::requestCollection): We don't need to sanitize stack here anymore.
        (JSC::Heap::notifyIsSafeToCollect): Start the collectContinuously thread. It will request collection 1 KHz.
        (JSC::Heap::prepareForAllocation): Deleted.
        (JSC::Heap::preventCollection): Prevent any new concurrent GCs from being initiated.
        (JSC::Heap::allowCollection):
        (JSC::Heap::forEachSlotVisitor): Allows us to safely iterate slot visitors.
        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::writeBarrier): If the 'to' cell is not NewWhite then it could be AnthraciteOrBlack. During a full collection, objects may be AnthraciteOrBlack from a previous GC. Turns out, we don't benefit from this optimization so we can just kill it.
        * heap/HeapSnapshotBuilder.cpp:
        (JSC::HeapSnapshotBuilder::buildSnapshot): This needs to use PreventCollectionScope to ensure snapshot soundness.
        * heap/ListableHandler.h:
        (JSC::ListableHandler::isOnList): Useful helper.
        * heap/LockDuringMarking.h:
        (JSC::lockDuringMarking): It's a locker that only locks while we're marking.
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::addBlock): Hold the bitvector lock while resizing.
        * heap/MarkedBlock.cpp: Hold the bitvector lock while accessing the bitvectors while the mutator is running.
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::prepareForConservativeScan): We used to do this in prepareForMarking, but we need to do it before each conservative scan not just before marking.
        (JSC::MarkedSpace::prepareForMarking): Remove the logic moved to prepareForConservativeScan.
        * heap/MarkedSpace.h:
        * heap/PreventCollectionScope.h: Added.
        * heap/SlotVisitor.cpp: Refactored drainFromShared so that we can write a similar function called drainInParallelPassively.
        (JSC::SlotVisitor::updateMutatorIsStopped): Update whether we can use "fast" scanning.
        (JSC::SlotVisitor::mutatorIsStoppedIsUpToDate):
        (JSC::SlotVisitor::didReachTermination):
        (JSC::SlotVisitor::hasWork):
        (JSC::SlotVisitor::drain): This now uses the rightToRun lock to allow the main GC thread to safepoint the workers.
        (JSC::SlotVisitor::drainFromShared):
        (JSC::SlotVisitor::drainInParallelPassively): This runs marking with one fewer threads than normal. It's useful for when we have resumed the mutator, since then the mutator has a better chance of getting on a core.
        (JSC::SlotVisitor::addWeakReferenceHarvester):
        (JSC::SlotVisitor::addUnconditionalFinalizer):
        (JSC::SlotVisitor::harvestWeakReferences): Deleted.
        (JSC::SlotVisitor::finalizeUnconditionalFinalizers): Deleted.
        * heap/SlotVisitor.h:
        * heap/SlotVisitorInlines.h: Outline stuff.
        (JSC::SlotVisitor::addWeakReferenceHarvester): Deleted.
        (JSC::SlotVisitor::addUnconditionalFinalizer): Deleted.
        * runtime/InferredType.cpp: This needed thread safety.
        (JSC::InferredType::visitChildren): This needs to keep its structure finalizer alive until it runs.
        (JSC::InferredType::set):
        (JSC::InferredType::InferredStructureFinalizer::finalizeUnconditionally):
        * runtime/InferredType.h:
        * runtime/InferredValue.cpp: This needed thread safety.
        (JSC::InferredValue::visitChildren):
        (JSC::InferredValue::ValueCleanup::finalizeUnconditionally):
        * runtime/JSArray.cpp:
        (JSC::JSArray::unshiftCountSlowCase): Update to use new butterfly API.
        (JSC::JSArray::unshiftCountWithArrayStorage): Update to use new butterfly API.
        * runtime/JSArrayBufferView.cpp:
        (JSC::JSArrayBufferView::visitChildren): Thread safety.
        * runtime/JSCell.h:
        (JSC::JSCell::setStructureIDDirectly): This is used for nuking the structure.
        (JSC::JSCell::InternalLocker::InternalLocker): Deleted. The cell is now the lock.
        (JSC::JSCell::InternalLocker::~InternalLocker): Deleted. The cell is now the lock.
        * runtime/JSCellInlines.h:
        (JSC::JSCell::structure): Clean this up.
        (JSC::JSCell::lock): The cell is now the lock.
        (JSC::JSCell::tryLock):
        (JSC::JSCell::unlock):
        (JSC::JSCell::isLocked):
        (JSC::JSCell::lockInternalLock): Deleted.
        (JSC::JSCell::unlockInternalLock): Deleted.
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::visitChildren): Thread safety.
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren): Thread safety.
        (JSC::JSGenericTypedArrayView<Adaptor>::slowDownAndWasteMemory): Thread safety.
        * runtime/JSObject.cpp:
        (JSC::JSObject::markAuxiliaryAndVisitOutOfLineProperties): Factor out this "easy" step of butterfly visiting.
        (JSC::JSObject::visitButterfly): Make this achieve 100% precision about structure-butterfly relationships. This relies on the mutator "nuking" the structure prior to "locked" structure-butterfly transitions.
        (JSC::JSObject::visitChildren): Use the new, nicer API.
        (JSC::JSFinalObject::visitChildren): Use the new, nicer API.
        (JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists): Use the new butterfly API.
        (JSC::JSObject::createInitialUndecided): Use the new butterfly API.
        (JSC::JSObject::createInitialInt32): Use the new butterfly API.
        (JSC::JSObject::createInitialDouble): Use the new butterfly API.
        (JSC::JSObject::createInitialContiguous): Use the new butterfly API.
        (JSC::JSObject::createArrayStorage): Use the new butterfly API.
        (JSC::JSObject::convertUndecidedToContiguous): Use the new butterfly API.
        (JSC::JSObject::convertUndecidedToArrayStorage): Use the new butterfly API.
        (JSC::JSObject::convertInt32ToArrayStorage): Use the new butterfly API.
        (JSC::JSObject::convertDoubleToContiguous): Use the new butterfly API.
        (JSC::JSObject::convertDoubleToArrayStorage): Use the new butterfly API.
        (JSC::JSObject::convertContiguousToArrayStorage): Use the new butterfly API.
        (JSC::JSObject::increaseVectorLength): Use the new butterfly API.
        (JSC::JSObject::shiftButterflyAfterFlattening): Use the new butterfly API.
        * runtime/JSObject.h:
        (JSC::JSObject::setButterfly): This now does all of the fences. Only use this when you are not also transitioning the structure or the structure's lastOffset.
        (JSC::JSObject::nukeStructureAndSetButterfly): Use this when doing locked structure-butterfly transitions.
        * runtime/JSObjectInlines.h:
        (JSC::JSObject::putDirectWithoutTransition): Use the newly factored out API.
        (JSC::JSObject::prepareToPutDirectWithoutTransition): Factor this out!
        (JSC::JSObject::putDirectInternal): Use the newly factored out API.
        * runtime/JSPropertyNameEnumerator.cpp:
        (JSC::JSPropertyNameEnumerator::finishCreation): Locks!
        (JSC::JSPropertyNameEnumerator::visitChildren): Locks!
        * runtime/JSSegmentedVariableObject.cpp:
        (JSC::JSSegmentedVariableObject::visitChildren): Locks!
        * runtime/JSString.cpp:
        (JSC::JSString::visitChildren): Thread safety.
        * runtime/ModuleProgramExecutable.cpp:
        (JSC::ModuleProgramExecutable::visitChildren): Thread safety.
        * runtime/Options.cpp: For now we disable concurrent GC on not-X86_64.
        (JSC::recomputeDependentOptions):
        * runtime/Options.h: Change the default max GC parallelism to 8. I don't know why it was still 7.
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::stackTracesAsJSON): This needs to defer GC before grabbing its lock.
        * runtime/SparseArrayValueMap.cpp: This needed thread safety.
        (JSC::SparseArrayValueMap::add):
        (JSC::SparseArrayValueMap::remove):
        (JSC::SparseArrayValueMap::visitChildren):
        * runtime/SparseArrayValueMap.h:
        * runtime/Structure.cpp: This had a race between addNewPropertyTransition and visitChildren.
        (JSC::Structure::Structure):
        (JSC::Structure::materializePropertyTable):
        (JSC::Structure::addNewPropertyTransition):
        (JSC::Structure::flattenDictionaryStructure):
        (JSC::Structure::add): Help out with nuking support - the m_offset needs to play along.
        (JSC::Structure::visitChildren):
        * runtime/Structure.h: Make some useful things public - like the notion of a lastOffset.
        * runtime/StructureChain.cpp:
        (JSC::StructureChain::visitChildren): Thread safety!
        * runtime/StructureChain.h: Thread safety!
        * runtime/StructureIDTable.cpp:
        (JSC::StructureIDTable::allocateID): Ensure that we don't get nuked IDs.
        * runtime/StructureIDTable.h: Add the notion of a nuked ID! It's a bit that the runtime never sees except during specific shady actions like locked structure-butterfly transitions. "Nuking" tells the GC to steer clear and rescan once we fire the barrier.
        (JSC::nukedStructureIDBit):
        (JSC::nuke):
        (JSC::isNuked):
        (JSC::decontaminate):
        * runtime/StructureInlines.h:
        (JSC::Structure::hasIndexingHeader): Better API.
        (JSC::Structure::add):
        * runtime/VM.cpp: Better GC interaction.
        (JSC::VM::ensureWatchdog):
        (JSC::VM::deleteAllLinkedCode):
        (JSC::VM::deleteAllCode):
        * runtime/VM.h:
        (JSC::VM::getStructure): Why wasn't this always an API!
        * runtime/WebAssemblyExecutable.cpp:
        (JSC::WebAssemblyExecutable::visitChildren): Thread safety.

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

        Enable SharedArrayBuffer, remove the flag
        https://bugs.webkit.org/show_bug.cgi?id=165614

        Rubber stamped by Geoffrey Garen.

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

2016-12-08  JF Bastien  <jfbastien@apple.com>

        WebAssembly JS API: wire up Instance imports
        https://bugs.webkit.org/show_bug.cgi?id=165118

        Reviewed by Saam Barati.

        Change a bunch of the WebAssembly object model, and pipe the
        necessary changes to be able to call JS imports from
        WebAssembly. This will make it easier to call_indirect, and
        unblock many other missing features.

        As a follow-up I need to teach JSC::linkFor to live without a
        CodeBlock: wasm doesn't have one and the IC patching is sad. We'll
        switch on the callee (or its type?) and then use that as the owner
        (because the callee is alive if the instance is alive, ditto
        module, and module owns the CallLinkInfo).

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * interpreter/CallFrame.h:
        (JSC::ExecState::callee): give access to the callee as a JSCell
        * jit/RegisterSet.cpp: dead code from previous WebAssembly implementation
        * jsc.cpp:
        (callWasmFunction):
        (functionTestWasmModuleFunctions):
        * runtime/JSCellInlines.h:
        (JSC::ExecState::vm): check callee instead of jsCallee: wasm only has a JSCell and not a JSObject
        * runtime/VM.cpp:
        (JSC::VM::VM): store the "top" WebAssembly.Instance on entry to WebAssembly (and restore the previous one on exit)
        * runtime/VM.h:
        * testWasm.cpp:
        (runWasmTests):
        * wasm/JSWebAssembly.h:
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::B3IRGenerator): pass unlinked calls around to shorten their lifetime: they're ony needed until the Plan is done
        (JSC::Wasm::B3IRGenerator::addCall):
        (JSC::Wasm::createJSToWasmWrapper):
        (JSC::Wasm::parseAndCompile): also pass in the function index space, so that imports can be signature-checked along with internal functions
        * wasm/WasmB3IRGenerator.h:
        * wasm/WasmBinding.cpp: Added.
        (JSC::Wasm::importStubGenerator): stubs from wasm to JS
        * wasm/WasmBinding.h: Copied from Source/JavaScriptCore/wasm/WasmValidate.h.
        * wasm/WasmCallingConvention.h:
        (JSC::Wasm::CallingConvention::setupFrameInPrologue):
        * wasm/WasmFormat.h: fix the object model
        (JSC::Wasm::CallableFunction::CallableFunction):
        * wasm/WasmFunctionParser.h: simplify some of the failure condition checks
        (JSC::Wasm::FunctionParser<Context>::FunctionParser): need function index space, not just internal functions
        (JSC::Wasm::FunctionParser<Context>::parseExpression):
        * wasm/WasmModuleParser.cpp: early-create some of the structures which will be needed later
        (JSC::Wasm::ModuleParser::parseImport):
        (JSC::Wasm::ModuleParser::parseFunction):
        (JSC::Wasm::ModuleParser::parseMemory):
        (JSC::Wasm::ModuleParser::parseExport):
        (JSC::Wasm::ModuleParser::parseCode):
        * wasm/WasmModuleParser.h:
        (JSC::Wasm::ModuleParser::functionIndexSpace):
        (JSC::Wasm::ModuleParser::functionLocations):
        * wasm/WasmParser.h:
        (JSC::Wasm::Parser::consumeUTF8String):
        * wasm/WasmPlan.cpp: pass around the wasm objects at the right time, reducing their lifetime and making it easier to pass them around when needed
        (JSC::Wasm::Plan::run):
        (JSC::Wasm::Plan::initializeCallees):
        * wasm/WasmPlan.h:
        (JSC::Wasm::Plan::exports):
        (JSC::Wasm::Plan::internalFunctionCount):
        (JSC::Wasm::Plan::jsToWasmEntryPointForFunction):
        (JSC::Wasm::Plan::takeModuleInformation):
        (JSC::Wasm::Plan::takeCallLinkInfos):
        (JSC::Wasm::Plan::takeWasmToJSStubs):
        (JSC::Wasm::Plan::takeFunctionIndexSpace):
        * wasm/WasmValidate.cpp: check function index space instead of only internal functions
        (JSC::Wasm::Validate::addCall):
        (JSC::Wasm::validateFunction):
        * wasm/WasmValidate.h:
        * wasm/js/JSWebAssemblyCallee.cpp:
        (JSC::JSWebAssemblyCallee::finishCreation):
        * wasm/js/JSWebAssemblyCallee.h:
        (JSC::JSWebAssemblyCallee::create):
        (JSC::JSWebAssemblyCallee::jsToWasmEntryPoint):
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::create):
        (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
        (JSC::JSWebAssemblyInstance::visitChildren):
        * wasm/js/JSWebAssemblyInstance.h: hold the import functions off the end of the Instance
        (JSC::JSWebAssemblyInstance::importFunction):
        (JSC::JSWebAssemblyInstance::importFunctions):
        (JSC::JSWebAssemblyInstance::setImportFunction):
        (JSC::JSWebAssemblyInstance::offsetOfImportFunctions):
        (JSC::JSWebAssemblyInstance::offsetOfImportFunction):
        (JSC::JSWebAssemblyInstance::allocationSize):
        * wasm/js/JSWebAssemblyModule.cpp:
        (JSC::JSWebAssemblyModule::create):
        (JSC::JSWebAssemblyModule::JSWebAssemblyModule):
        (JSC::JSWebAssemblyModule::visitChildren):
        * wasm/js/JSWebAssemblyModule.h: hold the link call info, the import function stubs, and the function index space
        (JSC::JSWebAssemblyModule::signatureForFunctionIndexSpace):
        (JSC::JSWebAssemblyModule::importCount):
        (JSC::JSWebAssemblyModule::calleeFromFunctionIndexSpace):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction): set top Instance on VM
        * wasm/js/WebAssemblyFunction.h:
        (JSC::WebAssemblyFunction::instance):
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::constructJSWebAssemblyInstance): handle function imports
        * wasm/js/WebAssemblyModuleConstructor.cpp:
        (JSC::constructJSWebAssemblyModule): generate the stubs for import functions
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::link):
        * wasm/js/WebAssemblyToJSCallee.cpp: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyCallee.cpp.
        (JSC::WebAssemblyToJSCallee::create): dummy JSCell singleton which lives on the VM, and is put as the callee in the import stub's frame to identified it when unwinding
        (JSC::WebAssemblyToJSCallee::createStructure):
        (JSC::WebAssemblyToJSCallee::WebAssemblyToJSCallee):
        (JSC::WebAssemblyToJSCallee::finishCreation):
        (JSC::WebAssemblyToJSCallee::destroy):
        * wasm/js/WebAssemblyToJSCallee.h: Copied from Source/JavaScriptCore/wasm/WasmB3IRGenerator.h.

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

        Enable JSC restricted options by default in the jsc shell.
        https://bugs.webkit.org/show_bug.cgi?id=165615

        Reviewed by Keith Miller.

        The jsc shell is only used for debugging and development testing.  We should
        allow it to use restricted options like JSC_useDollarVM even for release builds.

        * jsc.cpp:
        (jscmain):
        * runtime/Options.cpp:
        (JSC::Options::enableRestrictedOptions):
        (JSC::Options::isAvailable):
        (JSC::allowRestrictedOptions): Deleted.
        * runtime/Options.h:

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

        Unreviewed, rolling out r209489.

        Likely caused large regressions on JetStream, Sunspider and
        Speedometer

        Reverted changeset:

        "Add system trace points for JavaScript VM entry/exit"
        https://bugs.webkit.org/show_bug.cgi?id=165550
        http://trac.webkit.org/changeset/209489

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

        Move LEB tests to API tests
        https://bugs.webkit.org/show_bug.cgi?id=165586

        Reviewed by Saam Barati.

        Delete old stuff.

        * testWasm.cpp:
        (printUsageStatement):
        (CommandLine::parseArguments):
        (main):
        (runLEBTests): Deleted.

2016-12-07  JF Bastien  <jfbastien@apple.com>

        Cleanup WebAssembly's RETURN_IF_EXCEPTION
        https://bugs.webkit.org/show_bug.cgi?id=165595

        Reviewed by Filip Pizlo.

        * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
        (JSC::constructJSWebAssemblyCompileError):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction):
        * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
        (JSC::constructJSWebAssemblyRuntimeError):

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

        Renamed SourceCode members to match their accessor names
        https://bugs.webkit.org/show_bug.cgi?id=165573

        Reviewed by Keith Miller.

        startChar => startOffset
        endChar => endOffset

        * parser/UnlinkedSourceCode.h:
        (JSC::UnlinkedSourceCode::UnlinkedSourceCode):
        (JSC::UnlinkedSourceCode::view):
        (JSC::UnlinkedSourceCode::startOffset):
        (JSC::UnlinkedSourceCode::endOffset):
        (JSC::UnlinkedSourceCode::length):

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

        Add more missing trivial wasm ops.
        https://bugs.webkit.org/show_bug.cgi?id=165564

        Reviewed by Geoffrey Garen.

        This patch adds the nop, drop, and tee_local opcodes.
        It also fixes an issue where we were not generating
        the proper enums for the grow_memory and current_memory
        opcodes.

        * wasm/WasmFunctionParser.h:
        (JSC::Wasm::FunctionParser<Context>::parseExpression):
        * wasm/generateWasmOpsHeader.py:

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

        Renamed source => parentSource
        https://bugs.webkit.org/show_bug.cgi?id=165570

        Reviewed by Keith Miller.

        For less confuse.

        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):

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

        [JSC] Drop translate phase in module loader
        https://bugs.webkit.org/show_bug.cgi?id=164861

        Reviewed by Saam Barati.

        Originally, this "translate" phase was introduced to the module loader.
        However, recent rework discussion[1] starts dropping this phase.
        And this "translate" phase is meaningless in the browser side module loader
        since this phase originally mimics the node.js's translation hook (like,
        transpiling CoffeeScript source to JavaScript).

        This "translate" phase is not necessary for the exposed HTML5
        <script type="module"> tag right now. Once the module loader pipeline is
        redefined and specified, we need to update the current loader anyway.
        So dropping "translate" phase right now is OK.

        This a bit simplifies the current module loader pipeline.

        [1]: https://github.com/whatwg/loader/issues/147

        * builtins/ModuleLoaderPrototype.js:
        (newRegistryEntry):
        (fulfillFetch):
        (requestFetch):
        (requestInstantiate):
        (provide):
        (fulfillTranslate): Deleted.
        (requestTranslate): Deleted.
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        * jsc.cpp:
        * runtime/JSGlobalObject.cpp:
        * runtime/JSGlobalObject.h:
        * runtime/JSModuleLoader.cpp:
        (JSC::JSModuleLoader::translate): Deleted.
        * runtime/JSModuleLoader.h:
        * runtime/ModuleLoaderPrototype.cpp:
        (JSC::moduleLoaderPrototypeInstantiate):
        (JSC::moduleLoaderPrototypeTranslate): Deleted.

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

        Web Inspector: Add ability to distinguish if a Script was parsed as a module
        https://bugs.webkit.org/show_bug.cgi?id=164900
        <rdar://problem/29323817>

        Reviewed by Timothy Hatcher.

        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::didParseSource):
        * inspector/protocol/Debugger.json:
        Add an optional event parameter to distinguish if a script was a module or not.

2016-12-07  Simon Fraser  <simon.fraser@apple.com>

        Add system trace points for JavaScript VM entry/exit
        https://bugs.webkit.org/show_bug.cgi?id=165550

        Reviewed by Tim Horton.

        Add trace points for entry/exit into/out of the JS VM.

        * runtime/VMEntryScope.cpp:
        (JSC::VMEntryScope::VMEntryScope):
        (JSC::VMEntryScope::~VMEntryScope):

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

        Add support for truncation operators
        https://bugs.webkit.org/show_bug.cgi?id=165519

        Reviewed by Geoffrey Garen.

        This patch adds initial support for truncation operators. The current patch
        does range based out of bounds checking, in the future we should use system
        register flags on ARM and other tricks on X86 improve the performance of
        these opcodes.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::branchTruncateDoubleToInt32):
        (JSC::MacroAssemblerARM64::truncateDoubleToInt64):
        (JSC::MacroAssemblerARM64::truncateDoubleToUint64):
        (JSC::MacroAssemblerARM64::truncateFloatToInt32):
        (JSC::MacroAssemblerARM64::truncateFloatToUint32):
        (JSC::MacroAssemblerARM64::truncateFloatToInt64):
        (JSC::MacroAssemblerARM64::truncateFloatToUint64):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::truncateFloatToInt32):
        (JSC::MacroAssemblerX86Common::truncateDoubleToUint32): Deleted.
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::truncateDoubleToUint32):
        (JSC::MacroAssemblerX86_64::truncateDoubleToInt64):
        (JSC::MacroAssemblerX86_64::truncateDoubleToUint64):
        (JSC::MacroAssemblerX86_64::truncateFloatToUint32):
        (JSC::MacroAssemblerX86_64::truncateFloatToInt64):
        (JSC::MacroAssemblerX86_64::truncateFloatToUint64):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::cvttss2si_rr):
        (JSC::X86Assembler::cvttss2siq_rr):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::addOp<OpType::I32TruncSF64>):
        (JSC::Wasm::B3IRGenerator::addOp<OpType::I32TruncSF32>):
        (JSC::Wasm::B3IRGenerator::addOp<OpType::I32TruncUF64>):
        (JSC::Wasm::B3IRGenerator::addOp<OpType::I32TruncUF32>):
        (JSC::Wasm::B3IRGenerator::addOp<OpType::I64TruncSF64>):
        (JSC::Wasm::B3IRGenerator::addOp<OpType::I64TruncUF64>):
        (JSC::Wasm::B3IRGenerator::addOp<OpType::I64TruncSF32>):
        (JSC::Wasm::B3IRGenerator::addOp<OpType::I64TruncUF32>):
        * wasm/WasmFunctionParser.h:
        (JSC::Wasm::FunctionParser<Context>::parseExpression):

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

        Web Inspector: Remove unused and mostly untested Page domain commands and events
        https://bugs.webkit.org/show_bug.cgi?id=165507

        Reviewed by Brian Burg.

        Remove unused and unsupported commands and events.

          - Page.setDocumentContent
          - Page.getScriptExecutionStatus
          - Page.setScriptExecutionDisabled
          - Page.handleJavaScriptDialog
          - Page.javascriptDialogOpening
          - Page.javascriptDialogClosed
          - Page.scriptsEnabled

        * inspector/protocol/Page.json:

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

        [JSC] Merge PromiseReactions
        https://bugs.webkit.org/show_bug.cgi?id=165526

        Reviewed by Sam Weinig.

        Our promise implementation has two arrays per Promise; promiseFulfillReactions and promiseRejectReactions.
        And everytime we call `promise.then`, we create two promise reactions for fullfill and reject.
        However, these two reactions and the arrays for reactions can be merged into one array and one reaction.
        It reduces the unnecessary object allocations.

        No behavior change.

        * builtins/BuiltinNames.h:
        * builtins/PromiseOperations.js:
        (globalPrivate.newPromiseReaction):
        (globalPrivate.triggerPromiseReactions):
        (globalPrivate.rejectPromise):
        (globalPrivate.fulfillPromise):
        (globalPrivate.promiseReactionJob):
        (globalPrivate.initializePromise):
        * builtins/PromisePrototype.js:
        (then):
        * runtime/JSPromise.cpp:
        (JSC::JSPromise::finishCreation):

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

        GetByID IC is wrongly unwrapping the global proxy this value for getter/setters.
        https://bugs.webkit.org/show_bug.cgi?id=165401

        Reviewed by Saam Barati.

        When the this value for a property access is the JS global and that property
        access is via a GetterSetter, the underlying getter / setter functions would
        expect the this value they receive to be the JSProxy instance instead of the
        JSGlobalObject.  This is consistent with how the LLINT and runtime code behaves.
        The IC code should behave the same way.

        Also added some ASSERTs to document invariants in the code, and help detect
        bugs sooner if the code gets changed in a way that breaks those invariants in
        the future.

        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generateImpl):

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

        DumpRenderTree ASSERT in JSC::ExecutableBase::isHostFunction seen on bots
        https://bugs.webkit.org/show_bug.cgi?id=165497
        <rdar://problem/29538973>

        Reviewed by Saam Barati.

        * inspector/agents/InspectorScriptProfilerAgent.cpp:
        (Inspector::InspectorScriptProfilerAgent::trackingComplete):
        Defer collection when extracting and processing the samples to avoid
        any objects held by the samples from getting collected while processing.
        This is because while processing we call into functions that can
        allocate and we must prevent those functions from syncing with the
        GC thread which may collect other sample data yet to be processed.

2016-12-06  Alexey Proskuryakov  <ap@apple.com>

        Correct SDKROOT values in xcconfig files
        https://bugs.webkit.org/show_bug.cgi?id=165487
        rdar://problem/29539209

        Reviewed by Dan Bernstein.

        Fix suggested by Dan Bernstein.

        * Configurations/DebugRelease.xcconfig:

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

        Remove old Wasm object model
        https://bugs.webkit.org/show_bug.cgi?id=165481

        Reviewed by Keith Miller and Mark Lam.

        It's confusing to see code that consults both the old
        Wasm object model alongside the new one. The old object
        model is not a thing, and it's not being used. Let's
        remove it now to prevent further confusion.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finalizeLLIntInlineCaches):
        (JSC::CodeBlock::replacement):
        (JSC::CodeBlock::computeCapabilityLevel):
        (JSC::CodeBlock::updateAllPredictions):
        * bytecode/CodeBlock.h:
        * bytecode/WebAssemblyCodeBlock.cpp: Removed.
        * bytecode/WebAssemblyCodeBlock.h: Removed.
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::isSupportedForInlining):
        * interpreter/Interpreter.cpp:
        (JSC::GetStackTraceFunctor::operator()):
        (JSC::UnwindFunctor::operator()):
        (JSC::isWebAssemblyExecutable): Deleted.
        * jit/JITOperations.cpp:
        * jit/Repatch.cpp:
        (JSC::linkPolymorphicCall):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::setUpCall):
        * runtime/ExecutableBase.cpp:
        (JSC::ExecutableBase::clearCode):
        * runtime/ExecutableBase.h:
        (JSC::ExecutableBase::isWebAssemblyExecutable): Deleted.
        * runtime/JSFunction.cpp:
        * runtime/JSFunction.h:
        * runtime/JSFunctionInlines.h:
        (JSC::JSFunction::isBuiltinFunction):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        * runtime/WebAssemblyExecutable.cpp: Removed.
        * runtime/WebAssemblyExecutable.h: Removed.

2016-12-06  JF Bastien  <jfbastien@apple.com>

        PureNaN: fix typo
        https://bugs.webkit.org/show_bug.cgi?id=165493

        Reviewed by Mark Lam.

        * runtime/PureNaN.h:

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

        Introduce the concept of Immutable Prototype Exotic Objects to comply with the spec.
        https://bugs.webkit.org/show_bug.cgi?id=165227
        <rdar://problem/29442665>

        Reviewed by Saam Barati.

        * runtime/JSObject.cpp:
        (JSC::JSObject::setPrototypeWithCycleCheck):
        - This is where we check for immutable prototype exotic objects and refuse to set
          the prototype if needed.
          See https://tc39.github.io/ecma262/#sec-immutable-prototype-exotic-objects.

        * runtime/JSTypeInfo.h:
        (JSC::TypeInfo::isImmutablePrototypeExoticObject):
        * runtime/Structure.h:
        - Add flag for declaring immutable prototype exotic objects.

        * runtime/ObjectPrototype.h:
        - Declare that Object.prototype is an immutable prototype exotic object.
          See https://tc39.github.io/ecma262/#sec-properties-of-the-object-prototype-object.

        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorSetPrototypeOf):
        - Use better error messages.

2016-12-04  Darin Adler  <darin@apple.com>

        Use ASCIICType more, and improve it a little bit
        https://bugs.webkit.org/show_bug.cgi?id=165360

        Reviewed by Sam Weinig.

        * inspector/InspectorValues.cpp:
        (Inspector::readHexDigits): Use isASCIIHexDigit.
        (Inspector::hextoInt): Deleted.
        (decodeString): Use toASCIIHexValue.

        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::parseDigit): Use isASCIIDigit, isASCIIUpper, and isASCIILower.

        * runtime/StringPrototype.cpp:
        (JSC::substituteBackreferencesSlow): Use isASCIIDigit.

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

        Add storeFence support for ARMv7
        https://bugs.webkit.org/show_bug.cgi?id=164733

        Reviewed by Saam Barati.

        * assembler/ARMAssembler.h:
        (JSC::ARMAssembler::dmbISHST): Added.
        * assembler/ARMv7Assembler.h: Typo fixed, DMB has only T1 encoding.
        (JSC::ARMv7Assembler::dmbSY):
        (JSC::ARMv7Assembler::dmbISHST): Added.
        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::storeFence):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::storeFence):

2016-12-05  Matt Baker  <mattbaker@apple.com>

        Web Inspector: remove ASSERT from InspectorDebuggerAgent::derefAsyncCallData
        https://bugs.webkit.org/show_bug.cgi?id=165413
        <rdar://problem/29517587>

        Reviewed by Brian Burg.

        DOMTimer::removeById can call into InspectorInstrumentation with an
        invalid identifier, so don't assert that async call data exists.

        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::derefAsyncCallData):

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

        Fixed a bug in my last patch.

        Unreviewed.

        * bytecode/UnlinkedFunctionExecutable.h: Restore the conversion to
        one-based counting.

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

        Moved start and end column linking into helper functions
        https://bugs.webkit.org/show_bug.cgi?id=165422

        Reviewed by Sam Weinig.

        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::link):
        * bytecode/UnlinkedFunctionExecutable.h:

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

        Fix JSC files so that we can build a release build with NDEBUG #undef'ed.
        https://bugs.webkit.org/show_bug.cgi?id=165409

        Reviewed by Keith Miller.

        This allows us to run a release build with DEBUG ASSERTs enabled.

        * bytecode/BytecodeLivenessAnalysis.cpp:
        * bytecode/UnlinkedEvalCodeBlock.cpp:
        * bytecode/UnlinkedFunctionCodeBlock.cpp:
        * bytecode/UnlinkedModuleProgramCodeBlock.cpp:
        * bytecode/UnlinkedProgramCodeBlock.cpp:
        * runtime/EvalExecutable.cpp:

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

        Renamed source => parentSource
        https://bugs.webkit.org/show_bug.cgi?id=165419

        Reviewed by Saam Barati.

        This should help clarify that a FunctionExecutable holds the source
        code to its *parent* scope, and not its own SourceCode.

        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createExecutable):
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        (JSC::UnlinkedFunctionExecutable::link):
        * bytecode/UnlinkedFunctionExecutable.h:

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

        ScriptExecutable should not contain a copy of firstLine and startColumn
        https://bugs.webkit.org/show_bug.cgi?id=165415

        Reviewed by Keith Miller.

        We already have this data in SourceCode.

        It's super confusing to have two copies of this data, where one is
        allowed to mutate. In reality, your line and column number never change.

        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::link):
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getUnlinkedGlobalCodeBlock):
        * runtime/CodeCache.h:
        (JSC::generateUnlinkedCodeBlock):
        * runtime/FunctionExecutable.cpp:
        (JSC::FunctionExecutable::FunctionExecutable):
        * runtime/FunctionExecutable.h:
        * runtime/ScriptExecutable.cpp:
        (JSC::ScriptExecutable::ScriptExecutable):
        (JSC::ScriptExecutable::newCodeBlockFor):
        * runtime/ScriptExecutable.h:
        (JSC::ScriptExecutable::firstLine):
        (JSC::ScriptExecutable::startColumn):
        (JSC::ScriptExecutable::recordParse):

2016-12-05  Caitlin Potter  <caitp@igalia.com>

        [JSC] report unexpected token when "async" is followed by identifier 
        https://bugs.webkit.org/show_bug.cgi?id=165091

        Reviewed by Mark Lam.

        Report a SyntaxError, in order to report correct error in contexts
        an async ArrowFunction cannot occur. Also corrects errors in comment
        describing JSTokenType bitfield, which was added in r209293.

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

2016-12-05  Keith Miller  <keith_miller@apple.com>

        Add Wasm i64 to i32 conversion.
        https://bugs.webkit.org/show_bug.cgi?id=165378

        Reviewed by Filip Pizlo.

        It turns out the wrap operation is just B3's Trunc.

        * wasm/wasm.json:

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

        REGRESSION(r208985): SafariForWebKitDevelopment Symbol Not Found looking for method with WTF::Optional
        https://bugs.webkit.org/show_bug.cgi?id=165351

        Reviewed by Yusuke Suzuki.

        Some versions of Safari expect:

            Inspector::BackendDispatcher::reportProtocolError(WTF::Optional<long>, Inspector::BackendDispatcher::CommonErrorCode, WTF::String const&)
        
        Which we had updated to use std::optional. Expose a version with the original
        Symbol for these Safaris. This stub will just call through to the new version.

        * inspector/InspectorBackendDispatcher.cpp:
        (Inspector::BackendDispatcher::reportProtocolError):
        * inspector/InspectorBackendDispatcher.h:

2016-12-05  Konstantin Tokarev  <annulen@yandex.ru>

        Add __STDC_FORMAT_MACROS before inttypes.h is included
        https://bugs.webkit.org/show_bug.cgi?id=165374

        We need formatting macros like PRIu64 to be available in all places where
        inttypes.h header is used. All these usages get inttypes.h definitions
        via wtf/Assertions.h header, except SQLiteFileSystem.cpp where formatting
        macros are not used anymore since r185129.

        This patch fixes multiple build errors with MinGW and reduces number of
        independent __STDC_FORMAT_MACROS uses in the code base.

        Reviewed by Darin Adler.

        * disassembler/ARM64/A64DOpcode.cpp: Removed __STDC_FORMAT_MACROS
        because it is obtained via Assertions.h now
        * disassembler/ARM64Disassembler.cpp: Ditto.

2016-12-04  Keith Miller  <keith_miller@apple.com>

        Add support for Wasm ctz and popcnt
        https://bugs.webkit.org/show_bug.cgi?id=165369

        Reviewed by Saam Barati.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::countTrailingZeros32):
        (JSC::MacroAssemblerARM64::countTrailingZeros64):
        * assembler/MacroAssemblerX86Common.cpp:
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::countTrailingZeros32):
        (JSC::MacroAssemblerX86Common::supportsBMI1):
        (JSC::MacroAssemblerX86Common::ctzAfterBsf):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::countTrailingZeros64):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::tzcnt_rr):
        (JSC::X86Assembler::tzcntq_rr):
        (JSC::X86Assembler::bsf_rr):
        (JSC::X86Assembler::bsfq_rr):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::addOp<OpType::I32Ctz>):
        (JSC::Wasm::B3IRGenerator::addOp<OpType::I64Ctz>):
        (JSC::Wasm::B3IRGenerator::addOp<OpType::I32Popcnt>):
        (JSC::Wasm::B3IRGenerator::addOp<OpType::I64Popcnt>):
        * wasm/WasmFunctionParser.h:
        (JSC::Wasm::FunctionParser<Context>::parseExpression):

2016-12-04  Saam Barati  <sbarati@apple.com>

        We should have a Wasm callee
        https://bugs.webkit.org/show_bug.cgi?id=165163

        Reviewed by Keith Miller.

        This patch adds JSWebAssemblyCallee and stores it into the
        callee slot in the call frame as part of the prologue of a
        wasm function. This is the first step in implementing
        unwinding from/through wasm frames. We will use the callee
        to identify that a machine frame belongs to wasm code.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * jsc.cpp:
        (callWasmFunction):
        (functionTestWasmModuleFunctions):
        * llint/LowLevelInterpreter64.asm:
        * runtime/JSGlobalObject.cpp:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        * wasm/JSWebAssembly.h:
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        (JSC::Wasm::parseAndCompile):
        * wasm/WasmCallingConvention.h:
        (JSC::Wasm::CallingConvention::setupFrameInPrologue):
        * wasm/WasmFormat.h:
        * wasm/WasmPlan.cpp:
        (JSC::Wasm::Plan::initializeCallees):
        * wasm/WasmPlan.h:
        (JSC::Wasm::Plan::compiledFunction):
        (JSC::Wasm::Plan::getCompiledFunctions): Deleted.
        * wasm/js/JSWebAssemblyCallee.cpp: Added.
        (JSC::JSWebAssemblyCallee::JSWebAssemblyCallee):
        (JSC::JSWebAssemblyCallee::finishCreation):
        (JSC::JSWebAssemblyCallee::destroy):
        * wasm/js/JSWebAssemblyCallee.h: Added.
        (JSC::JSWebAssemblyCallee::create):
        (JSC::JSWebAssemblyCallee::createStructure):
        (JSC::JSWebAssemblyCallee::jsEntryPoint):
        * wasm/js/JSWebAssemblyModule.cpp:
        (JSC::JSWebAssemblyModule::create):
        (JSC::JSWebAssemblyModule::JSWebAssemblyModule):
        (JSC::JSWebAssemblyModule::visitChildren):
        * wasm/js/JSWebAssemblyModule.h:
        (JSC::JSWebAssemblyModule::moduleInformation):
        (JSC::JSWebAssemblyModule::callee):
        (JSC::JSWebAssemblyModule::callees):
        (JSC::JSWebAssemblyModule::offsetOfCallees):
        (JSC::JSWebAssemblyModule::allocationSize):
        (JSC::JSWebAssemblyModule::compiledFunctions): Deleted.
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction):
        (JSC::WebAssemblyFunction::create):
        (JSC::WebAssemblyFunction::visitChildren):
        (JSC::WebAssemblyFunction::finishCreation):
        * wasm/js/WebAssemblyFunction.h:
        (JSC::WebAssemblyFunction::webAssemblyCallee):
        (JSC::WebAssemblyFunction::instance):
        (JSC::WebAssemblyFunction::signature):
        (JSC::CallableWebAssemblyFunction::CallableWebAssemblyFunction): Deleted.
        (JSC::WebAssemblyFunction::webAssemblyFunctionCell): Deleted.
        * wasm/js/WebAssemblyFunctionCell.cpp:
        (JSC::WebAssemblyFunctionCell::create): Deleted.
        (JSC::WebAssemblyFunctionCell::WebAssemblyFunctionCell): Deleted.
        (JSC::WebAssemblyFunctionCell::destroy): Deleted.
        (JSC::WebAssemblyFunctionCell::createStructure): Deleted.
        * wasm/js/WebAssemblyFunctionCell.h:
        (JSC::WebAssemblyFunctionCell::function): Deleted.
        * wasm/js/WebAssemblyModuleConstructor.cpp:
        (JSC::constructJSWebAssemblyModule):
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::link):

2016-12-04  Matt Baker  <mattbaker@apple.com>

        Web Inspector: Assertion Failures breakpoint should respect global Breakpoints enabled setting
        https://bugs.webkit.org/show_bug.cgi?id=165277
        <rdar://problem/29467098>

        Reviewed by Mark Lam.

        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::handleConsoleAssert):
        Check that breakpoints are active before pausing.

2016-12-03  Yusuke Suzuki  <utatane.tea@gmail.com>

        Refactor SymbolImpl layout
        https://bugs.webkit.org/show_bug.cgi?id=165247

        Reviewed by Darin Adler.

        Use SymbolImpl::{create, createNullSymbol} instead.

        * runtime/PrivateName.h:
        (JSC::PrivateName::PrivateName):

2016-12-03  JF Bastien  <jfbastien@apple.com>

        WebAssembly: update binary format to 0xD version
        https://bugs.webkit.org/show_bug.cgi?id=165345

        Reviewed by Keith Miller.

        As described in the following PR: https://github.com/WebAssembly/design/pull/836
        Originally committed in r209175, reverted in r209242, and fixed in r209284.

        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        (JSC::Wasm::B3IRGenerator::zeroForType):
        (JSC::Wasm::B3IRGenerator::addConstant):
        (JSC::Wasm::createJSWrapper):
        * wasm/WasmCallingConvention.h:
        (JSC::Wasm::CallingConvention::marshallArgument):
        * wasm/WasmFormat.cpp:
        (JSC::Wasm::toString): Deleted.
        * wasm/WasmFormat.h:
        (JSC::Wasm::isValueType):
        (JSC::Wasm::toB3Type): Deleted.
        * wasm/WasmFunctionParser.h:
        (JSC::Wasm::FunctionParser<Context>::parseExpression):
        * wasm/WasmModuleParser.cpp:
        (JSC::Wasm::ModuleParser::parse):
        (JSC::Wasm::ModuleParser::parseType):
        * wasm/WasmModuleParser.h:
        * wasm/WasmParser.h:
        (JSC::Wasm::Parser::parseResultType):
        * wasm/generateWasm.py:
        (Wasm.__init__):
        * wasm/generateWasmOpsHeader.py:
        (cppMacro):
        (typeMacroizer):
        (opcodeMacroizer):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction):
        * wasm/wasm.json:

2016-12-02  Keith Miller  <keith_miller@apple.com>

        Add Wasm copysign
        https://bugs.webkit.org/show_bug.cgi?id=165355

        Reviewed by Filip Pizlo.

        This patch also makes two other important changes:

        1) allows for i64 constants in the B3 generator language.
        2) Fixes a bug with F64ConvertUI64 where the operation returned a Float instead
           of a Double in B3.

        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::addOp<F64ConvertUI64>):
        * wasm/generateWasmB3IRGeneratorInlinesHeader.py:
        (CodeGenerator.generateOpcode):
        (generateConstCode):
        (generateI32ConstCode): Deleted.
        * wasm/wasm.json:

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

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

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

        Reverted changeset:

        "Add Wasm copysign"
        https://bugs.webkit.org/show_bug.cgi?id=165355
        http://trac.webkit.org/changeset/209298

2016-12-02  Keith Miller  <keith_miller@apple.com>

        Add Wasm copysign
        https://bugs.webkit.org/show_bug.cgi?id=165355

        Reviewed by Filip Pizlo.

        This patch also makes two other important changes:

        1) allows for i64 constants in the B3 generator language.
        2) Fixes a bug with F64ConvertUI64 where the operation returned a Float instead
           of a Double in B3.

        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::addOp<F64ConvertUI64>):
        * wasm/generateWasmB3IRGeneratorInlinesHeader.py:
        (CodeGenerator.generateOpcode):
        (generateConstCode):
        (generateI32ConstCode): Deleted.
        * wasm/wasm.json:

2016-12-02  Keith Miller  <keith_miller@apple.com>

        Unreviewed, fix git having a breakdown over trying to reland a rollout.

2016-12-02  Keith Miller  <keith_miller@apple.com>

        Add Wasm floating point nearest and trunc
        https://bugs.webkit.org/show_bug.cgi?id=165339

        Reviewed by Saam Barati.

        This patch also allows any wasm primitive type to be passed as a
        string.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::nearestIntDouble):
        (JSC::MacroAssemblerARM64::nearestIntFloat):
        (JSC::MacroAssemblerARM64::truncDouble):
        (JSC::MacroAssemblerARM64::truncFloat):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::nearestIntDouble):
        (JSC::MacroAssemblerX86Common::nearestIntFloat):
        * jsc.cpp:
        (box):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::addOp<F64ConvertUI64>):
        (JSC::Wasm::B3IRGenerator::addOp<OpType::F32ConvertUI64>):
        (JSC::Wasm::B3IRGenerator::addOp<OpType::F64Nearest>):
        (JSC::Wasm::B3IRGenerator::addOp<OpType::F32Nearest>):
        (JSC::Wasm::B3IRGenerator::addOp<OpType::F64Trunc>):
        (JSC::Wasm::B3IRGenerator::addOp<OpType::F32Trunc>):
        * wasm/WasmFunctionParser.h:
        (JSC::Wasm::FunctionParser<Context>::parseExpression):

2016-12-02  Caitlin Potter  <caitp@igalia.com>

[JSC] add additional bit to JSTokenType bitfield
        https://bugs.webkit.org/show_bug.cgi?id=165091

        Reviewed by Geoffrey Garen.

        Avoid overflow which causes keyword tokens to be treated as unary
        tokens now that "async" is tokenized as a keyword, by granting an
        additional 64 bits to be occupied by token IDs.

        * parser/ParserTokens.h:

2016-12-02  Andy Estes  <aestes@apple.com>

        [Cocoa] Adopt the PRODUCT_BUNDLE_IDENTIFIER build setting
        https://bugs.webkit.org/show_bug.cgi?id=164492

        Reviewed by Dan Bernstein.

        * Configurations/JavaScriptCore.xcconfig: Set PRODUCT_BUNDLE_IDENTIFIER to
        com.apple.$(PRODUCT_NAME:rfc1034identifier).
        * Info.plist: Changed CFBundleIdentifier's value from com.apple.${PRODUCT_NAME} to
        ${PRODUCT_BUNDLE_IDENTIFIER}.

2016-12-02  JF Bastien  <jfbastien@apple.com>

        WebAssembly: mark WasmOps.h as private
        https://bugs.webkit.org/show_bug.cgi?id=165335

        Reviewed by Mark Lam.

        * JavaScriptCore.xcodeproj/project.pbxproj: WasmOps.h will be used by non-JSC and should therefore be private

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

        Unreviewed, rolling out r209275 and r209276.
        https://bugs.webkit.org/show_bug.cgi?id=165348

        "broke the arm build" (Requested by keith_miller on #webkit).

        Reverted changesets:

        "Add Wasm floating point nearest and trunc"
        https://bugs.webkit.org/show_bug.cgi?id=165339
        http://trac.webkit.org/changeset/209275

        "Unreviewed, forgot to change instruction after renaming."
        http://trac.webkit.org/changeset/209276

2016-12-02  Keith Miller  <keith_miller@apple.com>

        Unreviewed, forgot to change instruction after renaming.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::nearestIntDouble):
        (JSC::MacroAssemblerARM64::nearestIntFloat):

2016-12-02  Keith Miller  <keith_miller@apple.com>

        Add Wasm floating point nearest and trunc
        https://bugs.webkit.org/show_bug.cgi?id=165339

        Reviewed by Filip Pizlo.

        This patch also allows any wasm primitive type to be passed as a
        string.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::nearestIntDouble):
        (JSC::MacroAssemblerARM64::nearestIntFloat):
        (JSC::MacroAssemblerARM64::truncDouble):
        (JSC::MacroAssemblerARM64::truncFloat):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::nearestIntDouble):
        (JSC::MacroAssemblerX86Common::nearestIntFloat):
        * jsc.cpp:
        (box):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::addOp<F64ConvertUI64>):
        (JSC::Wasm::B3IRGenerator::addOp<OpType::F32ConvertUI64>):
        (JSC::Wasm::B3IRGenerator::addOp<OpType::F64Nearest>):
        (JSC::Wasm::B3IRGenerator::addOp<OpType::F32Nearest>):
        (JSC::Wasm::B3IRGenerator::addOp<OpType::F64Trunc>):
        (JSC::Wasm::B3IRGenerator::addOp<OpType::F32Trunc>):
        * wasm/WasmFunctionParser.h:
        (JSC::Wasm::FunctionParser<Context>::parseExpression):

2016-12-02  JF Bastien  <jfbastien@apple.com>

        WebAssembly: revert patch causing odd breakage
        https://bugs.webkit.org/show_bug.cgi?id=165308

        Unreviewed.

        Bug #164724 seems to cause build issues which I haven't tracked down yet. WasmOps.h can't be found:
        ./Source/JavaScriptCore/wasm/WasmFormat.h:34:10: fatal error: 'WasmOps.h' file not found

        It's weird since the file is auto-generated and has been for a while. #164724 merely includes it in WasmFormat.h.

        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        (JSC::Wasm::B3IRGenerator::zeroForType):
        (JSC::Wasm::B3IRGenerator::addConstant):
        (JSC::Wasm::createJSWrapper):
        * wasm/WasmCallingConvention.h:
        (JSC::Wasm::CallingConvention::marshallArgument):
        * wasm/WasmFormat.cpp:
        (JSC::Wasm::toString):
        * wasm/WasmFormat.h:
        (JSC::Wasm::toB3Type):
        * wasm/WasmFunctionParser.h:
        (JSC::Wasm::FunctionParser<Context>::parseExpression):
        * wasm/WasmModuleParser.cpp:
        (JSC::Wasm::ModuleParser::parse):
        (JSC::Wasm::ModuleParser::parseType):
        * wasm/WasmModuleParser.h:
        * wasm/WasmParser.h:
        (JSC::Wasm::Parser::parseResultType):
        * wasm/generateWasm.py:
        (Wasm.__init__):
        * wasm/generateWasmOpsHeader.py:
        (cppMacro):
        (opcodeMacroizer):
        (typeMacroizer): Deleted.
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction):
        * wasm/wasm.json:

2016-12-01  Brian Burg  <bburg@apple.com>

        Remote Inspector: fix weird typo in generated ObjC protocol type initializer implementations
        https://bugs.webkit.org/show_bug.cgi?id=165295
        <rdar://problem/29427778>

        Reviewed by Joseph Pecoraro.

        Remove a stray semicolon appended after custom initializer signatures.
        This is a syntax error when building with less lenient compiler warnings.

        * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
        (ObjCProtocolTypesImplementationGenerator._generate_init_method_for_required_members):
        * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
        * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
        * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
        * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
        * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
        * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
        * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:

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

        Rename CallFrame::callee() to CallFrame::jsCallee()
        https://bugs.webkit.org/show_bug.cgi?id=165293

        Reviewed by Keith Miller.

        Wasm will soon have its own Callee that doesn't derive
        from JSObject, but derives from JSCell. I want to introduce
        a new function like:
        ```
        CalleeBase* CallFrame::callee()
        ```
        
        once we have a Wasm callee. It only makes sense to name that
        function callee() and rename the current one turn to:
        ```
        JSObject* CallFrame::jsCallee()
        ```

        * API/APICallbackFunction.h:
        (JSC::APICallbackFunction::call):
        (JSC::APICallbackFunction::construct):
        * API/JSCallbackObjectFunctions.h:
        (JSC::JSCallbackObject<Parent>::construct):
        (JSC::JSCallbackObject<Parent>::call):
        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::scope):
        (JSC::DebuggerCallFrame::type):
        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::friendlyFunctionName):
        * interpreter/CallFrame.h:
        (JSC::ExecState::jsCallee):
        (JSC::ExecState::callee): Deleted.
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::dumpRegisters):
        (JSC::notifyDebuggerOfUnwinding):
        * interpreter/ShadowChicken.cpp:
        (JSC::ShadowChicken::update):
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::readNonInlinedFrame):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::traceFunctionPrologue):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/ArrayConstructor.cpp:
        (JSC::constructArrayWithSizeQuirk):
        * runtime/AsyncFunctionConstructor.cpp:
        (JSC::callAsyncFunctionConstructor):
        (JSC::constructAsyncFunctionConstructor):
        * runtime/BooleanConstructor.cpp:
        (JSC::constructWithBooleanConstructor):
        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::createWithInlineFrame):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::arityCheckFor):
        * runtime/DateConstructor.cpp:
        (JSC::constructWithDateConstructor):
        * runtime/DirectArguments.cpp:
        (JSC::DirectArguments::createByCopying):
        * runtime/Error.h:
        (JSC::StrictModeTypeErrorFunction::constructThrowTypeError):
        (JSC::StrictModeTypeErrorFunction::callThrowTypeError):
        * runtime/ErrorConstructor.cpp:
        (JSC::Interpreter::constructWithErrorConstructor):
        (JSC::Interpreter::callErrorConstructor):
        * runtime/FunctionConstructor.cpp:
        (JSC::constructWithFunctionConstructor):
        (JSC::callFunctionConstructor):
        * runtime/GeneratorFunctionConstructor.cpp:
        (JSC::callGeneratorFunctionConstructor):
        (JSC::constructGeneratorFunctionConstructor):
        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::createSubclassStructure):
        * runtime/IntlCollator.cpp:
        (JSC::IntlCollator::initializeCollator):
        * runtime/IntlCollatorConstructor.cpp:
        (JSC::constructIntlCollator):
        (JSC::callIntlCollator):
        (JSC::IntlCollatorConstructorFuncSupportedLocalesOf):
        * runtime/IntlDateTimeFormat.cpp:
        (JSC::IntlDateTimeFormat::initializeDateTimeFormat):
        * runtime/IntlDateTimeFormatConstructor.cpp:
        (JSC::constructIntlDateTimeFormat):
        (JSC::callIntlDateTimeFormat):
        (JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf):
        * runtime/IntlNumberFormat.cpp:
        (JSC::IntlNumberFormat::initializeNumberFormat):
        * runtime/IntlNumberFormatConstructor.cpp:
        (JSC::constructIntlNumberFormat):
        (JSC::callIntlNumberFormat):
        (JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf):
        * runtime/IntlObject.cpp:
        (JSC::canonicalizeLocaleList):
        (JSC::defaultLocale):
        (JSC::lookupSupportedLocales):
        (JSC::intlObjectFuncGetCanonicalLocales):
        * runtime/JSArrayBufferConstructor.cpp:
        (JSC::constructArrayBuffer):
        * runtime/JSArrayBufferPrototype.cpp:
        (JSC::arrayBufferProtoFuncSlice):
        * runtime/JSBoundFunction.cpp:
        (JSC::boundThisNoArgsFunctionCall):
        (JSC::boundFunctionCall):
        (JSC::boundThisNoArgsFunctionConstruct):
        (JSC::boundFunctionConstruct):
        * runtime/JSCellInlines.h:
        (JSC::ExecState::vm):
        * runtime/JSCustomGetterSetterFunction.cpp:
        (JSC::JSCustomGetterSetterFunction::customGetterSetterFunctionCall):
        * runtime/JSFunction.cpp:
        (JSC::callHostFunctionAsConstructor):
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::constructGenericTypedArrayView):
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewProtoFuncSlice):
        (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncEval):
        * runtime/JSInternalPromiseConstructor.cpp:
        (JSC::constructPromise):
        * runtime/JSMapIterator.cpp:
        (JSC::JSMapIterator::createPair):
        (JSC::JSMapIterator::clone):
        * runtime/JSNativeStdFunction.cpp:
        (JSC::runStdFunction):
        * runtime/JSPromiseConstructor.cpp:
        (JSC::constructPromise):
        * runtime/JSPropertyNameIterator.cpp:
        (JSC::JSPropertyNameIterator::clone):
        * runtime/JSScope.h:
        (JSC::ExecState::lexicalGlobalObject):
        * runtime/JSSetIterator.cpp:
        (JSC::JSSetIterator::createPair):
        (JSC::JSSetIterator::clone):
        * runtime/JSStringIterator.cpp:
        (JSC::JSStringIterator::clone):
        * runtime/MapConstructor.cpp:
        (JSC::constructMap):
        * runtime/MapPrototype.cpp:
        (JSC::mapProtoFuncValues):
        (JSC::mapProtoFuncEntries):
        (JSC::mapProtoFuncKeys):
        (JSC::privateFuncMapIterator):
        * runtime/NativeErrorConstructor.cpp:
        (JSC::Interpreter::constructWithNativeErrorConstructor):
        (JSC::Interpreter::callNativeErrorConstructor):
        * runtime/ObjectConstructor.cpp:
        (JSC::constructObject):
        * runtime/ProxyObject.cpp:
        (JSC::performProxyCall):
        (JSC::performProxyConstruct):
        * runtime/ProxyRevoke.cpp:
        (JSC::performProxyRevoke):
        * runtime/RegExpConstructor.cpp:
        (JSC::constructWithRegExpConstructor):
        (JSC::callRegExpConstructor):
        * runtime/ScopedArguments.cpp:
        (JSC::ScopedArguments::createByCopying):
        * runtime/SetConstructor.cpp:
        (JSC::constructSet):
        * runtime/SetPrototype.cpp:
        (JSC::setProtoFuncValues):
        (JSC::setProtoFuncEntries):
        (JSC::privateFuncSetIterator):
        * runtime/StringConstructor.cpp:
        (JSC::constructWithStringConstructor):
        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncIterator):
        * runtime/WeakMapConstructor.cpp:
        (JSC::constructWeakMap):
        * runtime/WeakSetConstructor.cpp:
        (JSC::constructWeakSet):
        * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
        (JSC::constructJSWebAssemblyCompileError):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction):
        * wasm/js/WebAssemblyModuleConstructor.cpp:
        (JSC::constructJSWebAssemblyModule):
        * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
        (JSC::constructJSWebAssemblyRuntimeError):

2016-12-01  Brian Burg  <bburg@apple.com>

        Web Inspector: generated code should use a framework-style import for *ProtocolArrayConversions.h
        https://bugs.webkit.org/show_bug.cgi?id=165281
        <rdar://problem/29427778>

        Reviewed by Joseph Pecoraro.

        * inspector/scripts/codegen/generate_objc_protocol_type_conversions_header.py:
        (ObjCProtocolTypeConversionsHeaderGenerator.generate_output):
        * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
        * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
        * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
        * inspector/scripts/tests/expected/enum-values.json-result:
        * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
        * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
        * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
        * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
        * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
        * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:

2016-12-01  Geoffrey Garen  <ggaren@apple.com>

        SourceCodeKey should use unlinked source code
        https://bugs.webkit.org/show_bug.cgi?id=165286

        Reviewed by Saam Barati.

        This patch splits out UnlinkedSourceCode from SourceCode, and deploys
        UnlinkedSourceCode in SourceCodeKey.

        It's misleading to store SourceCode in SourceCodeKey because SourceCode
        has an absolute location whereas unlinked cached code has no location.

        I plan to deploy UnlinkedSourceCode in more places, to indicate code
        that has no absolute location.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * parser/SourceCode.cpp:
        (JSC::UnlinkedSourceCode::toUTF8):
        (JSC::SourceCode::toUTF8): Deleted.
        * parser/SourceCode.h:
        (JSC::SourceCode::SourceCode):
        (JSC::SourceCode::startColumn):
        (JSC::SourceCode::isHashTableDeletedValue): Deleted.
        (JSC::SourceCode::hash): Deleted.
        (JSC::SourceCode::view): Deleted.
        (JSC::SourceCode::providerID): Deleted.
        (JSC::SourceCode::isNull): Deleted.
        (JSC::SourceCode::provider): Deleted.
        (JSC::SourceCode::startOffset): Deleted.
        (JSC::SourceCode::endOffset): Deleted.
        (JSC::SourceCode::length): Deleted. Move a bunch of stuff in to a new
        base class, UnlinkedSourceCode.

        * parser/SourceCodeKey.h:
        (JSC::SourceCodeKey::SourceCodeKey): Use UnlinkedSourceCode since code
        in the cache has no location.

        * parser/UnlinkedSourceCode.h: Copied from Source/JavaScriptCore/parser/SourceCode.h.
        (JSC::UnlinkedSourceCode::UnlinkedSourceCode):
        (JSC::UnlinkedSourceCode::provider):
        (JSC::SourceCode::SourceCode): Deleted.
        (JSC::SourceCode::isHashTableDeletedValue): Deleted.
        (JSC::SourceCode::hash): Deleted.
        (JSC::SourceCode::view): Deleted.
        (JSC::SourceCode::providerID): Deleted.
        (JSC::SourceCode::isNull): Deleted.
        (JSC::SourceCode::provider): Deleted.
        (JSC::SourceCode::firstLine): Deleted.
        (JSC::SourceCode::startColumn): Deleted.
        (JSC::SourceCode::startOffset): Deleted.
        (JSC::SourceCode::endOffset): Deleted.
        (JSC::SourceCode::length): Deleted.
        (JSC::makeSource): Deleted.
        (JSC::SourceCode::subExpression): Deleted.

        * runtime/CodeCache.h: Use UnlinkedSourceCode in the cache.

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

        Add wasm int to floating point opcodes
        https://bugs.webkit.org/show_bug.cgi?id=165252

        Reviewed by Geoffrey Garen.

        This patch adds support for the Wasm integral type => floating point
        type conversion opcodes. Most of these were already supported by B3
        however there was no support for uint64 to float/double. Unfortunately,
        AFAIK x86_64 does not have a single instruction that performs this
        conversion. Since there is a signed conversion instruction on x86 we
        use that for all uint64s that don't have the top bit set. If they do have
        the top bit set we need to divide by 2 (rounding up) then convert the number
        with the signed conversion then double the result.

        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::convertUInt64ToDouble):
        (JSC::MacroAssemblerX86_64::convertUInt64ToFloat):
        * jsc.cpp:
        (valueWithTypeOfWasmValue):
        (box):
        (functionTestWasmModuleFunctions):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::addOp<F64ConvertUI64>):
        (JSC::Wasm::B3IRGenerator::addOp<OpType::F32ConvertUI64>):
        * wasm/WasmFunctionParser.h:
        (JSC::Wasm::FunctionParser<Context>::parseExpression):
        * wasm/wasm.json:

2016-12-01  Geoffrey Garen  <ggaren@apple.com>

        Renamed EvalCodeCache => DirectEvalCodeCache
        https://bugs.webkit.org/show_bug.cgi?id=165271

        Reviewed by Saam Barati.

        We only use this cache for DirectEval, not IndirectEval.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        (JSC::DirectEvalCodeCache::visitAggregate):
        (JSC::CodeBlock::stronglyVisitStrongReferences):
        (JSC::EvalCodeCache::visitAggregate): Deleted.
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::directEvalCodeCache):
        (JSC::CodeBlock::evalCodeCache): Deleted.
        * bytecode/DirectEvalCodeCache.h: Copied from Source/JavaScriptCore/bytecode/EvalCodeCache.h.
        (JSC::EvalCodeCache::CacheKey::CacheKey): Deleted.
        (JSC::EvalCodeCache::CacheKey::hash): Deleted.
        (JSC::EvalCodeCache::CacheKey::isEmptyValue): Deleted.
        (JSC::EvalCodeCache::CacheKey::operator==): Deleted.
        (JSC::EvalCodeCache::CacheKey::isHashTableDeletedValue): Deleted.
        (JSC::EvalCodeCache::CacheKey::Hash::hash): Deleted.
        (JSC::EvalCodeCache::CacheKey::Hash::equal): Deleted.
        (JSC::EvalCodeCache::tryGet): Deleted.
        (JSC::EvalCodeCache::set): Deleted.
        (JSC::EvalCodeCache::isEmpty): Deleted.
        (JSC::EvalCodeCache::clear): Deleted.
        * bytecode/EvalCodeCache.h: Removed.
        * interpreter/Interpreter.cpp:
        (JSC::eval):
        * runtime/DirectEvalExecutable.cpp:
        (JSC::DirectEvalExecutable::create):

2016-12-01  Geoffrey Garen  <ggaren@apple.com>

        Removed some unnecessary indirection in code generation
        https://bugs.webkit.org/show_bug.cgi?id=165264

        Reviewed by Keith Miller.

        There's no need to route through JSGlobalObject when producing code --
        it just made the code harder to read.

        This patch moves functions from JSGlobalObject to their singleton
        call sites.

        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getUnlinkedEvalCodeBlock):
        (JSC::CodeCache::getUnlinkedGlobalEvalCodeBlock): Deleted.
        * runtime/CodeCache.h:
        * runtime/DirectEvalExecutable.cpp:
        (JSC::DirectEvalExecutable::create):
        * runtime/IndirectEvalExecutable.cpp:
        (JSC::IndirectEvalExecutable::create):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::createProgramCodeBlock): Deleted.
        (JSC::JSGlobalObject::createLocalEvalCodeBlock): Deleted.
        (JSC::JSGlobalObject::createGlobalEvalCodeBlock): Deleted.
        (JSC::JSGlobalObject::createModuleProgramCodeBlock): Deleted.
        * runtime/JSGlobalObject.h:
        * runtime/ModuleProgramExecutable.cpp:
        (JSC::ModuleProgramExecutable::create):
        * runtime/ProgramExecutable.cpp:
        (JSC::ProgramExecutable::initializeGlobalProperties):
        * runtime/ProgramExecutable.h:

2016-11-30  Darin Adler  <darin@apple.com>

        Roll out StringBuilder changes from the previous patch.
        They were a slowdown on a Kraken JSON test.

        * runtime/JSONObject.cpp:
        Roll out changes from below.

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

        [JSC] Specifying same module entry point multiple times cause TypeError
        https://bugs.webkit.org/show_bug.cgi?id=164858

        Reviewed by Saam Barati.

        Allow importing the same module multiple times. Previously, when specifying the same
        module in the <script type="module" src="here">, it throws TypeError.

        * builtins/ModuleLoaderPrototype.js:
        (requestFetch):
        (requestTranslate):
        (requestInstantiate):
        (requestSatisfy):

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

        WebAssembly JS API: export a module namespace object instead of a module environment
        https://bugs.webkit.org/show_bug.cgi?id=165121

        Reviewed by Saam Barati.

        This patch setup AbstractModuleRecord further for WebAssemblyModuleRecord.
        For exported entries in a wasm instance, we set up exported entries for
        AbstractModuleRecord. This allows us to export WASM exported functions in
        the module handling code.

        Since the exported entries in the abstract module record are correctly
        instantiated, the module namespace object for WASM module also starts
        working correctly. So we start exposing the module namespace object
        as `instance.exports` instead of the module environment object.

        And we move SourceCode, lexicalVariables, and declaredVariables fields to
        JSModuleRecord since they are related to JS source code (in the spec words,
        they are related to the source text module record).

        * runtime/AbstractModuleRecord.cpp:
        (JSC::AbstractModuleRecord::AbstractModuleRecord):
        * runtime/AbstractModuleRecord.h:
        (JSC::AbstractModuleRecord::sourceCode): Deleted.
        (JSC::AbstractModuleRecord::declaredVariables): Deleted.
        (JSC::AbstractModuleRecord::lexicalVariables): Deleted.
        * runtime/JSModuleRecord.cpp:
        (JSC::JSModuleRecord::JSModuleRecord):
        * runtime/JSModuleRecord.h:
        (JSC::JSModuleRecord::sourceCode):
        (JSC::JSModuleRecord::declaredVariables):
        (JSC::JSModuleRecord::lexicalVariables):
        * wasm/WasmFormat.cpp:
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::finishCreation):
        * wasm/js/WebAssemblyFunction.cpp:
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::constructJSWebAssemblyInstance):
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::create):
        (JSC::WebAssemblyModuleRecord::WebAssemblyModuleRecord):
        (JSC::WebAssemblyModuleRecord::finishCreation):
        WebAssemblyModuleRecord::link should perform linking things.
        So allocating exported entries should be done here.
        (JSC::WebAssemblyModuleRecord::link):
        * wasm/js/WebAssemblyModuleRecord.h:

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

        TypeInfo::OutOfLineTypeFlags should be 16 bits in size.
        https://bugs.webkit.org/show_bug.cgi?id=165224

        Reviewed by Saam Barati.

        There's no reason for OutOfLineTypeFlags to be constraint to 8 bits since the
        space is available to us.  Making OutOfLineTypeFlags 16 bits brings TypeInfo up
        to 32 bits in size from the current 24 bits.

        * runtime/JSTypeInfo.h:
        (JSC::TypeInfo::TypeInfo):

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

        REGRESSION: inspector/sampling-profiler/* LayoutTests are flaky timeouts
        https://bugs.webkit.org/show_bug.cgi?id=164388
        <rdar://problem/29101555>

        Reviewed by Saam Barati.

        There was a possibility of a deadlock between the main thread and the GC thread
        with the SamplingProfiler lock when Inspector is processing samples to send to
        the frontend. The Inspector (main thread) was holding the SamplingProfiler lock
        while processing samples, which runs JavaScript that could trigger a GC, and
        GC then tries to acquire the SamplingProfiler lock to process unprocessed samples.

        A simple solution here is to tighten the bounds of when Inspector holds the
        SamplingProfiler lock. It only needs the lock when extracting samples from
        the SamplingProfiler. It doesn't need to hold the lock for processing those
        samples, which is what can run script and cause a GC.

        * inspector/agents/InspectorScriptProfilerAgent.cpp:
        (Inspector::InspectorScriptProfilerAgent::trackingComplete):
        Tighten bounds of this lock to only where it is needed.

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

        Proxy is not allowed in the global prototype chain.
        https://bugs.webkit.org/show_bug.cgi?id=165205

        Reviewed by Geoffrey Garen.

        * runtime/ProgramExecutable.cpp:
        (JSC::ProgramExecutable::initializeGlobalProperties):
        - We'll now throw a TypeError if we detect a Proxy in the global prototype chain.

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

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

        "It regressed Octane/Raytrace and JetStream" (Requested by
        saamyjoon on #webkit).

        Reverted changeset:

        "We should support CreateThis in the FTL"
        https://bugs.webkit.org/show_bug.cgi?id=164904
        http://trac.webkit.org/changeset/209112

2016-11-30  Darin Adler  <darin@apple.com>

        Streamline and speed up tokenizer and segmented string classes
        https://bugs.webkit.org/show_bug.cgi?id=165003

        Reviewed by Sam Weinig.

        * runtime/JSONObject.cpp:
        (JSC::Stringifier::appendStringifiedValue): Use viewWithUnderlyingString when calling
        StringBuilder::appendQuotedJSONString, since it now takes a StringView and there is
        no benefit in creating a String for that function if one doesn't already exist.

2016-11-29  JF Bastien  <jfbastien@apple.com>

        WebAssembly JS API: improve Instance
        https://bugs.webkit.org/show_bug.cgi?id=164757

        Reviewed by Keith Miller.

        An Instance's `exports` property wasn't populated with exports.

        According to the spec [0], `exports` should present itself as a WebAssembly
        Module Record. In order to do this we need to split JSModuleRecord into
        AbstractModuleRecord (without the `link` and `evaluate` functions), and
        JSModuleRecord (which implements link and evaluate). We can then have a separate
        WebAssemblyModuleRecord which shares most of the implementation.

        `exports` then maps function names to WebAssemblyFunction and
        WebAssemblyFunctionCell, which call into the B3-generated WebAssembly code.

        A follow-up patch will do imports.

        A few things of note:

         - Use Identifier instead of String. They get uniqued, we need them for the JSModuleNamespaceObject. This is safe because JSWebAssemblyModule creation is on the main thread.
         - JSWebAssemblyInstance needs to refer to the JSWebAssemblyModule used to create it, because the module owns the code, identifiers, etc. The world would be very sad if it got GC'd.
         - Instance.exports shouldn't use putWithoutTransition because it affects all Structures, whereas here each instance needs its own exports.
         - Expose the compiled functions, and pipe them to the InstanceConstructor. Start moving things around to split JSModuleRecord out into JS and WebAssembly parts.

          [0]: https://github.com/WebAssembly/design/blob/master/JS.md#webassemblyinstance-constructor

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/AbstractModuleRecord.cpp: Copied from Source/JavaScriptCore/runtime/JSModuleRecord.cpp, which I split in two
        (JSC::AbstractModuleRecord::AbstractModuleRecord):
        (JSC::AbstractModuleRecord::destroy):
        (JSC::AbstractModuleRecord::finishCreation):
        (JSC::AbstractModuleRecord::visitChildren):
        (JSC::AbstractModuleRecord::appendRequestedModule):
        (JSC::AbstractModuleRecord::addStarExportEntry):
        (JSC::AbstractModuleRecord::addImportEntry):
        (JSC::AbstractModuleRecord::addExportEntry):
        (JSC::identifierToJSValue):
        (JSC::AbstractModuleRecord::hostResolveImportedModule):
        (JSC::AbstractModuleRecord::ResolveQuery::ResolveQuery):
        (JSC::AbstractModuleRecord::ResolveQuery::isEmptyValue):
        (JSC::AbstractModuleRecord::ResolveQuery::isDeletedValue):
        (JSC::AbstractModuleRecord::ResolveQuery::Hash::hash):
        (JSC::AbstractModuleRecord::ResolveQuery::Hash::equal):
        (JSC::AbstractModuleRecord::cacheResolution):
        (JSC::getExportedNames):
        (JSC::AbstractModuleRecord::getModuleNamespace):
        (JSC::printableName):
        (JSC::AbstractModuleRecord::dump):
        * runtime/AbstractModuleRecord.h: Copied from Source/JavaScriptCore/runtime/JSModuleRecord.h.
        (JSC::AbstractModuleRecord::ImportEntry::isNamespace):
        (JSC::AbstractModuleRecord::sourceCode):
        (JSC::AbstractModuleRecord::moduleKey):
        (JSC::AbstractModuleRecord::requestedModules):
        (JSC::AbstractModuleRecord::exportEntries):
        (JSC::AbstractModuleRecord::importEntries):
        (JSC::AbstractModuleRecord::starExportEntries):
        (JSC::AbstractModuleRecord::declaredVariables):
        (JSC::AbstractModuleRecord::lexicalVariables):
        (JSC::AbstractModuleRecord::moduleEnvironment):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::webAssemblyModuleRecordStructure):
        (JSC::JSGlobalObject::webAssemblyFunctionStructure):
        * runtime/JSModuleEnvironment.cpp:
        (JSC::JSModuleEnvironment::create):
        (JSC::JSModuleEnvironment::finishCreation):
        (JSC::JSModuleEnvironment::getOwnPropertySlot):
        (JSC::JSModuleEnvironment::getOwnNonIndexPropertyNames):
        (JSC::JSModuleEnvironment::put):
        (JSC::JSModuleEnvironment::deleteProperty):
        * runtime/JSModuleEnvironment.h:
        (JSC::JSModuleEnvironment::create):
        (JSC::JSModuleEnvironment::offsetOfModuleRecord):
        (JSC::JSModuleEnvironment::allocationSize):
        (JSC::JSModuleEnvironment::moduleRecord):
        (JSC::JSModuleEnvironment::moduleRecordSlot):
        * runtime/JSModuleNamespaceObject.cpp:
        (JSC::JSModuleNamespaceObject::finishCreation):
        (JSC::JSModuleNamespaceObject::getOwnPropertySlot):
        * runtime/JSModuleNamespaceObject.h:
        (JSC::JSModuleNamespaceObject::create):
        (JSC::JSModuleNamespaceObject::moduleRecord):
        * runtime/JSModuleRecord.cpp:
        (JSC::JSModuleRecord::createStructure):
        (JSC::JSModuleRecord::create):
        (JSC::JSModuleRecord::JSModuleRecord):
        (JSC::JSModuleRecord::destroy):
        (JSC::JSModuleRecord::finishCreation):
        (JSC::JSModuleRecord::visitChildren):
        (JSC::JSModuleRecord::instantiateDeclarations):
        * runtime/JSModuleRecord.h:
        * runtime/JSScope.cpp:
        (JSC::abstractAccess):
        (JSC::JSScope::collectClosureVariablesUnderTDZ):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        * wasm/JSWebAssembly.h:
        * wasm/WasmFormat.h: use Identifier instead of String
        * wasm/WasmModuleParser.cpp:
        (JSC::Wasm::ModuleParser::parse):
        (JSC::Wasm::ModuleParser::parseType):
        (JSC::Wasm::ModuleParser::parseImport): fix off-by-one
        (JSC::Wasm::ModuleParser::parseFunction):
        (JSC::Wasm::ModuleParser::parseExport):
        * wasm/WasmModuleParser.h:
        (JSC::Wasm::ModuleParser::ModuleParser):
        * wasm/WasmPlan.cpp:
        (JSC::Wasm::Plan::run):
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::create):
        (JSC::JSWebAssemblyInstance::finishCreation):
        (JSC::JSWebAssemblyInstance::visitChildren):
        * wasm/js/JSWebAssemblyInstance.h:
        (JSC::JSWebAssemblyInstance::module):
        * wasm/js/JSWebAssemblyModule.cpp:
        (JSC::JSWebAssemblyModule::create):
        (JSC::JSWebAssemblyModule::finishCreation):
        (JSC::JSWebAssemblyModule::visitChildren):
        * wasm/js/JSWebAssemblyModule.h:
        (JSC::JSWebAssemblyModule::moduleInformation):
        (JSC::JSWebAssemblyModule::compiledFunctions):
        (JSC::JSWebAssemblyModule::exportSymbolTable):
        * wasm/js/WebAssemblyFunction.cpp: Added.
        (JSC::callWebAssemblyFunction):
        (JSC::WebAssemblyFunction::create):
        (JSC::WebAssemblyFunction::createStructure):
        (JSC::WebAssemblyFunction::WebAssemblyFunction):
        (JSC::WebAssemblyFunction::visitChildren):
        (JSC::WebAssemblyFunction::finishCreation):
        * wasm/js/WebAssemblyFunction.h: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyModule.h.
        (JSC::CallableWebAssemblyFunction::CallableWebAssemblyFunction):
        (JSC::WebAssemblyFunction::webAssemblyFunctionCell):
        * wasm/js/WebAssemblyFunctionCell.cpp: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyInstance.h.
        (JSC::WebAssemblyFunctionCell::create):
        (JSC::WebAssemblyFunctionCell::WebAssemblyFunctionCell):
        (JSC::WebAssemblyFunctionCell::destroy):
        (JSC::WebAssemblyFunctionCell::createStructure):
        * wasm/js/WebAssemblyFunctionCell.h: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyInstance.h.
        (JSC::WebAssemblyFunctionCell::function):
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::constructJSWebAssemblyInstance):
        * wasm/js/WebAssemblyModuleConstructor.cpp:
        (JSC::constructJSWebAssemblyModule):
        * wasm/js/WebAssemblyModuleRecord.cpp: Added.
        (JSC::WebAssemblyModuleRecord::createStructure):
        (JSC::WebAssemblyModuleRecord::create):
        (JSC::WebAssemblyModuleRecord::WebAssemblyModuleRecord):
        (JSC::WebAssemblyModuleRecord::destroy):
        (JSC::WebAssemblyModuleRecord::finishCreation):
        (JSC::WebAssemblyModuleRecord::visitChildren):
        (JSC::WebAssemblyModuleRecord::link):
        (JSC::WebAssemblyModuleRecord::evaluate):
        * wasm/js/WebAssemblyModuleRecord.h: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyModule.h.

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

        We should be able optimize the pattern where we spread a function's rest parameter to another call
        https://bugs.webkit.org/show_bug.cgi?id=163865

        Reviewed by Filip Pizlo.

        This patch optimizes the following patterns to prevent both the allocation
        of the rest parameter, and the execution of the iterator protocol:
        
        ```
        function foo(...args) {
            let arr = [...args];
        }
        
        and
        
        function foo(...args) {
            bar(...args);
        }
        ```
        
        To do this, I've extended the arguments elimination phase to reason
        about Spread and NewArrayWithSpread. I've added two new nodes, PhantomSpread
        and PhantomNewArrayWithSpread. PhantomSpread is only allowed over rest
        parameters that don't escape. If the rest parameter *does* escape, we can't
        convert the spread into a phantom because it would not be sound w.r.t JS
        semantics because we would be reading from the call frame even though
        the rest array may have changed.
        
        Note that NewArrayWithSpread also understands what to do when one of its
        arguments is PhantomSpread(@PhantomCreateRest) even if it itself is escaped.
        
        PhantomNewArrayWithSpread is only allowed over a series of
        PhantomSpread(@PhantomCreateRest) nodes. Like with PhantomSpread, PhantomNewArrayWithSpread
        is only allowed if none of its arguments that are being spread are escaped
        and if it itself is not escaped.
        
        Because there is a dependency between a node being a candidate and
        the escaped state of the node's children, I've extended the notion
        of escaping a node inside the arguments elimination phase. Now, when
        any node is escaped, we must consider all other candidates that are may
        now no longer be valid.
        
        For example:
        
        ```
        function foo(...args) {
            escape(args);
            bar(...args);
        }
        ```
        
        In the above program, we don't know if the function call to escape()
        modifies args, therefore, the spread can not become phantom because
        the execution of the spread may not be as simple as reading the
        arguments from the call frame.
        
        Unfortunately, the arguments elimination phase does not consider control
        flow when doing its escape analysis. It would be good to integrate this
        phase with the object allocation sinking phase. To see why, consider
        an example where we don't eliminate the spread and allocation of the rest
        parameter even though we could:
        
        ```
        function foo(rareCondition, ...args) {
            bar(...args);
            if (rareCondition)
                baz(args);
        }
        ```
        
        There are only a few users of the PhantomSpread and PhantomNewArrayWithSpread
        nodes. PhantomSpread is only used by PhantomNewArrayWithSpread and NewArrayWithSpread.
        PhantomNewArrayWithSpread is only used by ForwardVarargs and the various
        *Call*ForwardVarargs nodes. The users of these phantoms know how to produce
        what the phantom node would have produced. For example, NewArrayWithSpread
        knows how to produce the values that would have been produced by PhantomSpread(@PhantomCreateRest)
        by directly reading from the call frame.
        
        This patch is a 6% speedup on my MBP on ES6SampleBench.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::tryAppendLea):
        * b3/B3ValueRep.h:
        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createDefaultConstructor):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGForAllKills.h:
        (JSC::DFG::forAllKillsInBlock):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasConstant):
        (JSC::DFG::Node::constant):
        (JSC::DFG::Node::bitVector):
        (JSC::DFG::Node::isPhantomAllocation):
        * dfg/DFGNodeType.h:
        * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
        (JSC::DFG::OSRAvailabilityAnalysisPhase::run):
        (JSC::DFG::LocalOSRAvailabilityCalculator::LocalOSRAvailabilityCalculator):
        (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
        * dfg/DFGOSRAvailabilityAnalysisPhase.h:
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        * dfg/DFGPreciseLocalClobberize.h:
        (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGPromotedHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGPromotedHeapLocation.h:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGValidate.cpp:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::LowerDFGToB3):
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread):
        (JSC::FTL::DFG::LowerDFGToB3::compileSpread):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
        (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs):
        (JSC::FTL::DFG::LowerDFGToB3::getSpreadLengthFromInlineCallFrame):
        (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargsWithSpread):
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationPopulateObjectInOSR):
        (JSC::FTL::operationMaterializeObjectInOSR):
        * jit/SetupVarargsFrame.cpp:
        (JSC::emitSetupVarargsFrameFastCase):
        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionMaxArguments):
        * runtime/JSFixedArray.h:
        (JSC::JSFixedArray::createFromArray):

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

        Unreviewed, rolling out r209058 and r209074.
        https://bugs.webkit.org/show_bug.cgi?id=165188

        These changes caused API test StringBuilderTest.Equal to crash
        and/or fail. (Requested by ryanhaddad on #webkit).

        Reverted changesets:

        "Streamline and speed up tokenizer and segmented string
        classes"
        https://bugs.webkit.org/show_bug.cgi?id=165003
        http://trac.webkit.org/changeset/209058

        "REGRESSION (r209058): API test StringBuilderTest.Equal
        crashing"
        https://bugs.webkit.org/show_bug.cgi?id=165142
        http://trac.webkit.org/changeset/209074

2016-11-29  Caitlin Potter  <caitp@igalia.com>

        [JSC] always wrap AwaitExpression operand in a new Promise
        https://bugs.webkit.org/show_bug.cgi?id=165181

        Reviewed by Yusuke Suzuki.

        Ensure operand of AwaitExpression is wrapped in a new Promise by
        explicitly creating a new Promise Capability and invoking its
        resolve callback. This avoids the specified short-circuit for
        Promise.resolve().

        * builtins/AsyncFunctionPrototype.js:
        (globalPrivate.asyncFunctionResume):

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

        We should support CreateThis in the FTL
        https://bugs.webkit.org/show_bug.cgi?id=164904

        Reviewed by Geoffrey Garen.

        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
        (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateThis):
        (JSC::FTL::DFG::LowerDFGToB3::storeStructure):
        (JSC::FTL::DFG::LowerDFGToB3::allocateCell):
        (JSC::FTL::DFG::LowerDFGToB3::allocateObject):
        (JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedObject):
        (JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedCell):
        * runtime/Structure.h:

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

        Fix exception scope verification failures in runtime/RegExp* files.
        https://bugs.webkit.org/show_bug.cgi?id=165054

        Reviewed by Saam Barati.

        Also replaced returning JSValue() with returning { }.

        * runtime/RegExpConstructor.cpp:
        (JSC::toFlags):
        (JSC::regExpCreate):
        (JSC::constructRegExp):
        * runtime/RegExpObject.cpp:
        (JSC::RegExpObject::defineOwnProperty):
        (JSC::collectMatches):
        (JSC::RegExpObject::matchGlobal):
        * runtime/RegExpObjectInlines.h:
        (JSC::getRegExpObjectLastIndexAsUnsigned):
        (JSC::RegExpObject::execInline):
        (JSC::RegExpObject::matchInline):
        * runtime/RegExpPrototype.cpp:
        (JSC::regExpProtoFuncCompile):
        (JSC::flagsString):
        (JSC::regExpProtoFuncToString):
        (JSC::regExpProtoFuncSplitFast):

2016-11-29  Andy Estes  <aestes@apple.com>

        [Cocoa] Enable two clang warnings recommended by Xcode
        https://bugs.webkit.org/show_bug.cgi?id=164498

        Reviewed by Mark Lam.

        * Configurations/Base.xcconfig: Enabled CLANG_WARN_INFINITE_RECURSION and CLANG_WARN_SUSPICIOUS_MOVE.

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

        Add simple way to implement Wasm ops that require more than one B3 opcode
        https://bugs.webkit.org/show_bug.cgi?id=165129

        Reviewed by Geoffrey Garen.

        This patch adds a simple way to show the B3IRGenerator opcode script how
        to generate code for Wasm opcodes that do not have a one to one mapping.
        The syntax is pretty simple right now. There are only three things one
        can use as of this patch (although more things might be added in the future)
        1) Wasm opcode arguments: These are referred to as @<argument_number>. For example,
           I32.sub would map to Sub(@0, @1).
        2) 32-bit int constants: These are reffered to as i32(<value>). For example, i32.inc
           would map to Add(@0, i32(1))
        3) B3 opcodes: These are referred to as the B3 opcode name followed by the B3Value's constructor
           arguments. A value may take the result of another value as an argument. For example, you can do
           Div(Mul(@0, Add(@0, i32(1))), i32(2)) if there was a b3 opcode that computed the sum from 1 to n.

        These scripts are used to implement Wasm's eqz and floating point max/min opcodes. This patch
        also adds missing support for the Wasm Neg opcodes.

        * jsc.cpp:
        (box):
        (functionTestWasmModuleFunctions):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::toB3Op): Deleted.
        * wasm/WasmFunctionParser.h:
        (JSC::Wasm::FunctionParser<Context>::parseBody):
        * wasm/WasmModuleParser.cpp:
        (JSC::Wasm::ModuleParser::parseType):
        * wasm/WasmParser.h:
        (JSC::Wasm::Parser::parseUInt8):
        (JSC::Wasm::Parser::parseValueType):
        * wasm/generateWasmB3IRGeneratorInlinesHeader.py:
        (Source):
        (Source.__init__):
        (read):
        (lex):
        (CodeGenerator):
        (CodeGenerator.__init__):
        (CodeGenerator.advance):
        (CodeGenerator.token):
        (CodeGenerator.parseError):
        (CodeGenerator.consume):
        (CodeGenerator.generateParameters):
        (CodeGenerator.generateOpcode):
        (CodeGenerator.generate):
        (temp):
        (generateB3OpCode):
        (generateI32ConstCode):
        (generateB3Code):
        (generateSimpleCode):
        * wasm/wasm.json:

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

        Fix exception scope verification failures in ProxyConstructor.cpp and ProxyObject.cpp.
        https://bugs.webkit.org/show_bug.cgi?id=165053

        Reviewed by Saam Barati.

        Also replaced returning JSValue() with returning { }.

        * runtime/ProxyConstructor.cpp:
        (JSC::constructProxyObject):
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::structureForTarget):
        (JSC::performProxyGet):
        (JSC::ProxyObject::performInternalMethodGetOwnProperty):
        (JSC::ProxyObject::performHasProperty):
        (JSC::ProxyObject::getOwnPropertySlotCommon):
        (JSC::ProxyObject::performPut):
        (JSC::ProxyObject::putByIndexCommon):
        (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):

2016-11-28  Matt Baker  <mattbaker@apple.com>

        Web Inspector: Debugger should have an option for showing asynchronous call stacks
        https://bugs.webkit.org/show_bug.cgi?id=163230
        <rdar://problem/28698683>

        Reviewed by Joseph Pecoraro.

        * inspector/ScriptCallFrame.cpp:
        (Inspector::ScriptCallFrame::isNative):
        Encapsulate check for native code source URL.

        * inspector/ScriptCallFrame.h:
        * inspector/ScriptCallStack.cpp:
        (Inspector::ScriptCallStack::firstNonNativeCallFrame):
        (Inspector::ScriptCallStack::buildInspectorArray):
        * inspector/ScriptCallStack.h:
        Replace use of Console::StackTrace with Array<Console::CallFrame>.

        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::disable):
        (Inspector::InspectorDebuggerAgent::setAsyncStackTraceDepth):
        Set number of async frames to store (including boundary frames).
        A value of zero disables recording of async call stacks.

        (Inspector::InspectorDebuggerAgent::buildAsyncStackTrace):
        Helper function for building a linked list StackTraces.
        (Inspector::InspectorDebuggerAgent::didScheduleAsyncCall):
        Store a call stack for the script that scheduled the async call.
        If the call repeats (e.g. setInterval), the starting reference count is
        set to 1. This ensures that dereffing after dispatch won't clear the stack.
        If another async call is currently being dispatched, increment the
        AsyncCallData reference count for that call.

        (Inspector::InspectorDebuggerAgent::didCancelAsyncCall):
        Decrement the reference count for the canceled call.

        (Inspector::InspectorDebuggerAgent::willDispatchAsyncCall):
        Set the identifier for the async callback currently being dispatched,
        so that if the debugger pauses during dispatch a stack trace can be
        associated with the pause location. If an async call is already being
        dispatched, which could be the case when a script schedules an async
        call in a nested runloop, do nothing.

        (Inspector::InspectorDebuggerAgent::didDispatchAsyncCall):
        Decrement the reference count for the canceled call.
        (Inspector::InspectorDebuggerAgent::didPause):
        If a stored stack trace exists for this location, convert to a protocol
        object and send to the frontend.

        (Inspector::InspectorDebuggerAgent::didClearGlobalObject):
        (Inspector::InspectorDebuggerAgent::clearAsyncStackTraceData):
        (Inspector::InspectorDebuggerAgent::refAsyncCallData):
        Increment AsyncCallData reference count.
        (Inspector::InspectorDebuggerAgent::derefAsyncCallData):
        Decrement AsyncCallData reference count. If zero, deref its parent
        (if it exists) and remove the AsyncCallData entry.

        * inspector/agents/InspectorDebuggerAgent.h:

        * inspector/protocol/Console.json:
        * inspector/protocol/Network.json:
        Replace use of Console.StackTrace with array of Console.CallFrame.

        * inspector/protocol/Debugger.json:
        New protocol command and event data.

2016-11-28  Darin Adler  <darin@apple.com>

        Streamline and speed up tokenizer and segmented string classes
        https://bugs.webkit.org/show_bug.cgi?id=165003

        Reviewed by Sam Weinig.

        * runtime/JSONObject.cpp:
        (JSC::Stringifier::appendStringifiedValue): Use viewWithUnderlyingString when calling
        StringBuilder::appendQuotedJSONString, since it now takes a StringView and there is
        no benefit in creating a String for that function if one doesn't already exist.

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

        Fix exception scope verification failures in runtime/Intl* files.
        https://bugs.webkit.org/show_bug.cgi?id=165014

        Reviewed by Saam Barati.

        * runtime/IntlCollatorConstructor.cpp:
        (JSC::constructIntlCollator):
        (JSC::IntlCollatorConstructorFuncSupportedLocalesOf):
        * runtime/IntlCollatorPrototype.cpp:
        (JSC::IntlCollatorPrototypeFuncResolvedOptions):
        * runtime/IntlDateTimeFormatConstructor.cpp:
        (JSC::constructIntlDateTimeFormat):
        (JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf):
        * runtime/IntlDateTimeFormatPrototype.cpp:
        (JSC::IntlDateTimeFormatFuncFormatDateTime):
        (JSC::IntlDateTimeFormatPrototypeGetterFormat):
        (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
        * runtime/IntlNumberFormatConstructor.cpp:
        (JSC::constructIntlNumberFormat):
        (JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf):
        * runtime/IntlNumberFormatPrototype.cpp:
        (JSC::IntlNumberFormatFuncFormatNumber):
        (JSC::IntlNumberFormatPrototypeGetterFormat):
        (JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
        * runtime/IntlObject.cpp:
        (JSC::lookupSupportedLocales):
        * runtime/IntlObjectInlines.h:
        (JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor):

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

        Fix exception scope verification failures in IteratorOperations.h.
        https://bugs.webkit.org/show_bug.cgi?id=165015

        Reviewed by Saam Barati.

        * runtime/IteratorOperations.h:
        (JSC::forEachInIterable):

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

        Fix exception scope verification failures in JSArray* files.
        https://bugs.webkit.org/show_bug.cgi?id=165016

        Reviewed by Saam Barati.

        * runtime/JSArray.cpp:
        (JSC::JSArray::defineOwnProperty):
        (JSC::JSArray::put):
        (JSC::JSArray::setLength):
        (JSC::JSArray::pop):
        (JSC::JSArray::push):
        (JSC::JSArray::unshiftCountWithAnyIndexingType):
        * runtime/JSArrayBuffer.cpp:
        (JSC::JSArrayBuffer::put):
        (JSC::JSArrayBuffer::defineOwnProperty):
        * runtime/JSArrayInlines.h:
        (JSC::getLength):
        (JSC::toLength):

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

        Fix exception scope verification failures in JSDataView.cpp.
        https://bugs.webkit.org/show_bug.cgi?id=165020

        Reviewed by Saam Barati.

        * runtime/JSDataView.cpp:
        (JSC::JSDataView::put):

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

        Fix exception scope verification failures in JSFunction.cpp.
        https://bugs.webkit.org/show_bug.cgi?id=165021

        Reviewed by Saam Barati.

        * runtime/JSFunction.cpp:
        (JSC::JSFunction::put):
        (JSC::JSFunction::defineOwnProperty):

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

        Fix exception scope verification failures in runtime/JSGenericTypedArrayView* files.
        https://bugs.webkit.org/show_bug.cgi?id=165022

        Reviewed by Saam Barati.

        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::constructGenericTypedArrayViewFromIterator):
        (JSC::constructGenericTypedArrayViewWithArguments):
        (JSC::constructGenericTypedArrayView):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::set):
        (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::speciesConstruct):
        (JSC::genericTypedArrayViewProtoFuncSet):
        (JSC::genericTypedArrayViewProtoFuncJoin):
        (JSC::genericTypedArrayViewProtoFuncSlice):
        (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):

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

        Fix exception scope verification failures in runtime/Operations.cpp/h.
        https://bugs.webkit.org/show_bug.cgi?id=165046

        Reviewed by Saam Barati.

        Also switched to using returning { } instead of JSValue().

        * runtime/Operations.cpp:
        (JSC::jsAddSlowCase):
        (JSC::jsIsObjectTypeOrNull):
        * runtime/Operations.h:
        (JSC::jsStringFromRegisterArray):
        (JSC::jsStringFromArguments):
        (JSC::jsLess):
        (JSC::jsLessEq):

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

        Fix exception scope verification failures in JSScope.cpp.
        https://bugs.webkit.org/show_bug.cgi?id=165047

        Reviewed by Saam Barati.

        * runtime/JSScope.cpp:
        (JSC::JSScope::resolve):

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

        Fix exception scope verification failures in JSTypedArrayViewPrototype.cpp.
        https://bugs.webkit.org/show_bug.cgi?id=165049

        Reviewed by Saam Barati.

        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::typedArrayViewPrivateFuncSort):
        (JSC::typedArrayViewProtoFuncSet):
        (JSC::typedArrayViewProtoFuncCopyWithin):
        (JSC::typedArrayViewProtoFuncIncludes):
        (JSC::typedArrayViewProtoFuncLastIndexOf):
        (JSC::typedArrayViewProtoFuncIndexOf):
        (JSC::typedArrayViewProtoFuncJoin):
        (JSC::typedArrayViewProtoGetterFuncBuffer):
        (JSC::typedArrayViewProtoGetterFuncLength):
        (JSC::typedArrayViewProtoGetterFuncByteLength):
        (JSC::typedArrayViewProtoGetterFuncByteOffset):
        (JSC::typedArrayViewProtoFuncReverse):
        (JSC::typedArrayViewPrivateFuncSubarrayCreate):
        (JSC::typedArrayViewProtoFuncSlice):

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

        Fix exception scope verification failures in runtime/Map* files.
        https://bugs.webkit.org/show_bug.cgi?id=165050

        Reviewed by Saam Barati.

        * runtime/MapConstructor.cpp:
        (JSC::constructMap):
        * runtime/MapIteratorPrototype.cpp:
        (JSC::MapIteratorPrototypeFuncNext):
        * runtime/MapPrototype.cpp:
        (JSC::privateFuncMapIteratorNext):

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

        Fix exception scope verification failures in more miscellaneous files.
        https://bugs.webkit.org/show_bug.cgi?id=165102

        Reviewed by Saam Barati.

        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::constructJSWebAssemblyInstance):

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

        Fix exception scope verification failures in runtime/Weak* files.
        https://bugs.webkit.org/show_bug.cgi?id=165096

        Reviewed by Geoffrey Garen.

        * runtime/WeakMapConstructor.cpp:
        (JSC::constructWeakMap):
        * runtime/WeakMapPrototype.cpp:
        (JSC::protoFuncWeakMapSet):
        * runtime/WeakSetConstructor.cpp:
        (JSC::constructWeakSet):
        * runtime/WeakSetPrototype.cpp:
        (JSC::protoFuncWeakSetAdd):

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

        Fix exception scope verification failures in runtime/String* files.
        https://bugs.webkit.org/show_bug.cgi?id=165067

        Reviewed by Saam Barati.

        * runtime/StringConstructor.cpp:
        (JSC::stringFromCodePoint):
        (JSC::constructWithStringConstructor):
        * runtime/StringObject.cpp:
        (JSC::StringObject::put):
        (JSC::StringObject::putByIndex):
        (JSC::StringObject::defineOwnProperty):
        * runtime/StringPrototype.cpp:
        (JSC::jsSpliceSubstrings):
        (JSC::jsSpliceSubstringsWithSeparators):
        (JSC::replaceUsingRegExpSearch):
        (JSC::replaceUsingStringSearch):
        (JSC::repeatCharacter):
        (JSC::replace):
        (JSC::stringProtoFuncReplaceUsingStringSearch):
        (JSC::stringProtoFuncCharAt):
        (JSC::stringProtoFuncCodePointAt):
        (JSC::stringProtoFuncConcat):
        (JSC::stringProtoFuncIndexOf):
        (JSC::stringProtoFuncLastIndexOf):
        (JSC::splitStringByOneCharacterImpl):
        (JSC::stringProtoFuncSplitFast):
        (JSC::stringProtoFuncSubstring):
        (JSC::stringProtoFuncToLowerCase):
        (JSC::stringProtoFuncToUpperCase):
        (JSC::toLocaleCase):
        (JSC::trimString):
        (JSC::stringProtoFuncIncludes):
        (JSC::builtinStringIncludesInternal):
        (JSC::stringProtoFuncIterator):
        (JSC::normalize):
        (JSC::stringProtoFuncNormalize):

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

        Fix exception scope verification failures in ObjectConstructor.cpp and ObjectPrototype.cpp.
        https://bugs.webkit.org/show_bug.cgi?id=165051

        Reviewed by Saam Barati.

        Also,
        1. Replaced returning JSValue() with returning { }.
        2. Replaced uses of exec->propertyNames() with vm.propertyNames.

        * runtime/ObjectConstructor.cpp:
        (JSC::constructObject):
        (JSC::objectConstructorGetPrototypeOf):
        (JSC::objectConstructorGetOwnPropertyDescriptor):
        (JSC::objectConstructorGetOwnPropertyDescriptors):
        (JSC::objectConstructorGetOwnPropertyNames):
        (JSC::objectConstructorGetOwnPropertySymbols):
        (JSC::objectConstructorKeys):
        (JSC::ownEnumerablePropertyKeys):
        (JSC::toPropertyDescriptor):
        (JSC::defineProperties):
        (JSC::objectConstructorDefineProperties):
        (JSC::objectConstructorCreate):
        (JSC::setIntegrityLevel):
        (JSC::objectConstructorSeal):
        (JSC::objectConstructorPreventExtensions):
        (JSC::objectConstructorIsSealed):
        (JSC::objectConstructorIsFrozen):
        (JSC::ownPropertyKeys):
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncValueOf):
        (JSC::objectProtoFuncHasOwnProperty):
        (JSC::objectProtoFuncIsPrototypeOf):
        (JSC::objectProtoFuncDefineGetter):
        (JSC::objectProtoFuncDefineSetter):
        (JSC::objectProtoFuncLookupGetter):
        (JSC::objectProtoFuncLookupSetter):
        (JSC::objectProtoFuncToLocaleString):
        (JSC::objectProtoFuncToString):

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

        Fix exception scope verification failures in miscellaneous files.
        https://bugs.webkit.org/show_bug.cgi?id=165055

        Reviewed by Saam Barati.

        * runtime/MathObject.cpp:
        (JSC::mathProtoFuncIMul):
        * runtime/ModuleLoaderPrototype.cpp:
        (JSC::moduleLoaderPrototypeParseModule):
        (JSC::moduleLoaderPrototypeRequestedModules):
        * runtime/NativeErrorConstructor.cpp:
        (JSC::Interpreter::constructWithNativeErrorConstructor):
        * runtime/NumberConstructor.cpp:
        (JSC::constructWithNumberConstructor):
        * runtime/SetConstructor.cpp:
        (JSC::constructSet):
        * runtime/SetIteratorPrototype.cpp:
        (JSC::SetIteratorPrototypeFuncNext):
        * runtime/SparseArrayValueMap.cpp:
        (JSC::SparseArrayValueMap::putEntry):
        (JSC::SparseArrayEntry::put):
        * runtime/TemplateRegistry.cpp:
        (JSC::TemplateRegistry::getTemplateObject):

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

        Fix exception scope verification failures in ReflectObject.cpp.
        https://bugs.webkit.org/show_bug.cgi?id=165066

        Reviewed by Saam Barati.

        * runtime/ReflectObject.cpp:
        (JSC::reflectObjectConstruct):
        (JSC::reflectObjectDefineProperty):
        (JSC::reflectObjectEnumerate):
        (JSC::reflectObjectGet):
        (JSC::reflectObjectGetOwnPropertyDescriptor):
        (JSC::reflectObjectGetPrototypeOf):
        (JSC::reflectObjectOwnKeys):
        (JSC::reflectObjectSet):

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

        Fix exception scope verification failures in ArrayConstructor.cpp and ArrayPrototype.cpp.
        https://bugs.webkit.org/show_bug.cgi?id=164972

        Reviewed by Geoffrey Garen.

        * runtime/ArrayConstructor.cpp:
        (JSC::constructArrayWithSizeQuirk):
        * runtime/ArrayPrototype.cpp:
        (JSC::getProperty):
        (JSC::putLength):
        (JSC::speciesWatchpointsValid):
        (JSC::speciesConstructArray):
        (JSC::shift):
        (JSC::unshift):
        (JSC::arrayProtoFuncToString):
        (JSC::arrayProtoFuncToLocaleString):
        (JSC::slowJoin):
        (JSC::fastJoin):
        (JSC::arrayProtoFuncJoin):
        (JSC::arrayProtoFuncPop):
        (JSC::arrayProtoFuncPush):
        (JSC::arrayProtoFuncReverse):
        (JSC::arrayProtoFuncShift):
        (JSC::arrayProtoFuncSlice):
        (JSC::arrayProtoFuncSplice):
        (JSC::arrayProtoFuncUnShift):
        (JSC::arrayProtoFuncIndexOf):
        (JSC::arrayProtoFuncLastIndexOf):
        (JSC::concatAppendOne):
        (JSC::arrayProtoPrivateFuncConcatMemcpy):
        (JSC::ArrayPrototype::attemptToInitializeSpeciesWatchpoint):

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

        Fix exception scope verification failures in LLIntSlowPaths.cpp.
        https://bugs.webkit.org/show_bug.cgi?id=164969

        Reviewed by Geoffrey Garen.

        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::getByVal):
        (JSC::LLInt::setUpCall):
        (JSC::LLInt::varargsSetup):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):

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

        [WTF] Import std::optional reference implementation as WTF::Optional
        https://bugs.webkit.org/show_bug.cgi?id=164199

        Reviewed by Saam Barati and Sam Weinig.

        Previous WTF::Optional::operator= is not compatible to std::optional::operator=.
        std::optional::emplace has the same semantics to the previous one.
        So we change the code to use it.

        * 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-AnotherGuardedInternalBuiltin-Separate.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:
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::commuteCompareToZeroIntoTest):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::commuteCompareToZeroIntoTest):
        * b3/B3CheckSpecial.cpp:
        (JSC::B3::CheckSpecial::forEachArg):
        (JSC::B3::CheckSpecial::shouldTryAliasingDef):
        * b3/B3CheckSpecial.h:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::scaleForShl):
        (JSC::B3::Air::LowerToAir::effectiveAddr):
        (JSC::B3::Air::LowerToAir::tryAppendLea):
        * b3/B3Opcode.cpp:
        (JSC::B3::invertedCompare):
        * b3/B3Opcode.h:
        * b3/B3PatchpointSpecial.cpp:
        (JSC::B3::PatchpointSpecial::forEachArg):
        * b3/B3StackmapSpecial.cpp:
        (JSC::B3::StackmapSpecial::forEachArgImpl):
        * b3/B3StackmapSpecial.h:
        * b3/B3Value.cpp:
        (JSC::B3::Value::invertedCompare):
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::isValidScale):
        (JSC::B3::Air::Arg::isValidAddrForm):
        (JSC::B3::Air::Arg::isValidIndexForm):
        (JSC::B3::Air::Arg::isValidForm):
        * b3/air/AirCustom.h:
        (JSC::B3::Air::PatchCustom::shouldTryAliasingDef):
        * b3/air/AirFixObviousSpills.cpp:
        * b3/air/AirInst.h:
        * b3/air/AirInstInlines.h:
        (JSC::B3::Air::Inst::shouldTryAliasingDef):
        * b3/air/AirIteratedRegisterCoalescing.cpp:
        * b3/air/AirSpecial.cpp:
        (JSC::B3::Air::Special::shouldTryAliasingDef):
        * b3/air/AirSpecial.h:
        * bytecode/BytecodeGeneratorification.cpp:
        (JSC::BytecodeGeneratorification::storageForGeneratorLocal):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::findPC):
        (JSC::CodeBlock::bytecodeOffsetFromCallSiteIndex):
        * bytecode/CodeBlock.h:
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::link):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::PropertyListNode::emitPutConstantProperty):
        (JSC::ObjectPatternNode::bindValue):
        * debugger/Debugger.cpp:
        (JSC::Debugger::resolveBreakpoint):
        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::currentPosition):
        * debugger/DebuggerParseData.cpp:
        (JSC::DebuggerPausePositions::breakpointLocationForLineColumn):
        * debugger/DebuggerParseData.h:
        * debugger/ScriptProfilingScope.h:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeDoubleUnaryOpEffects):
        * dfg/DFGJITCode.cpp:
        (JSC::DFG::JITCode::findPC):
        * dfg/DFGJITCode.h:
        * dfg/DFGOperations.cpp:
        (JSC::DFG::operationPutByValInternal):
        * dfg/DFGSlowPathGenerator.h:
        (JSC::DFG::SlowPathGenerator::generate):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::runSlowPathGenerators):
        (JSC::DFG::SpeculativeJIT::emitUntypedBitOp):
        (JSC::DFG::SpeculativeJIT::emitUntypedRightShiftBitOp):
        (JSC::DFG::SpeculativeJIT::compileMathIC):
        (JSC::DFG::SpeculativeJIT::compileArithDiv):
        (JSC::DFG::SpeculativeJIT::compileCallDOMGetter):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compileLogicalNot):
        (JSC::DFG::SpeculativeJIT::emitBranch):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        * ftl/FTLJITCode.cpp:
        (JSC::FTL::JITCode::findPC):
        * ftl/FTLJITCode.h:
        * heap/Heap.cpp:
        (JSC::Heap::collectAsync):
        (JSC::Heap::collectSync):
        (JSC::Heap::collectInThread):
        (JSC::Heap::requestCollection):
        (JSC::Heap::willStartCollection):
        (JSC::Heap::didFinishCollection):
        (JSC::Heap::shouldDoFullCollection):
        * heap/Heap.h:
        (JSC::Heap::collectionScope):
        * heap/HeapSnapshot.cpp:
        (JSC::HeapSnapshot::nodeForCell):
        (JSC::HeapSnapshot::nodeForObjectIdentifier):
        * heap/HeapSnapshot.h:
        * inspector/InspectorBackendDispatcher.cpp:
        (Inspector::BackendDispatcher::dispatch):
        (Inspector::BackendDispatcher::sendPendingErrors):
        (Inspector::BackendDispatcher::reportProtocolError):
        * inspector/InspectorBackendDispatcher.h:
        * inspector/agents/InspectorHeapAgent.cpp:
        (Inspector::InspectorHeapAgent::nodeForHeapObjectIdentifier):
        (Inspector::InspectorHeapAgent::getPreview):
        (Inspector::InspectorHeapAgent::getRemoteObject):
        * inspector/agents/InspectorHeapAgent.h:
        * inspector/remote/RemoteConnectionToTarget.h:
        * inspector/remote/RemoteConnectionToTarget.mm:
        (Inspector::RemoteConnectionToTarget::targetIdentifier):
        (Inspector::RemoteConnectionToTarget::setup):
        * inspector/remote/RemoteInspector.h:
        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::updateClientCapabilities):
        * inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
        (_generate_declarations_for_enum_conversion_methods):
        (_generate_declarations_for_enum_conversion_methods.return_type_with_export_macro):
        * inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py:
        (CppProtocolTypesImplementationGenerator._generate_enum_conversion_methods_for_domain.generate_conversion_method_body):
        * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
        * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
        * inspector/scripts/tests/expected/enum-values.json-result:
        * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
        * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
        * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
        * jit/JITCode.h:
        (JSC::JITCode::findPC):
        * jit/JITDivGenerator.cpp:
        (JSC::JITDivGenerator::generateFastPath):
        * jit/JITOperations.cpp:
        * jit/PCToCodeOriginMap.cpp:
        (JSC::PCToCodeOriginMap::findPC):
        * jit/PCToCodeOriginMap.h:
        * jsc.cpp:
        (WTF::RuntimeArray::getOwnPropertySlot):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * parser/ModuleAnalyzer.cpp:
        (JSC::ModuleAnalyzer::exportVariable):
        * runtime/ConcurrentJSLock.h:
        (JSC::ConcurrentJSLocker::ConcurrentJSLocker):
        * runtime/DefinePropertyAttributes.h:
        (JSC::DefinePropertyAttributes::writable):
        (JSC::DefinePropertyAttributes::configurable):
        (JSC::DefinePropertyAttributes::enumerable):
        * runtime/GenericArgumentsInlines.h:
        (JSC::GenericArguments<Type>::getOwnPropertySlot):
        (JSC::GenericArguments<Type>::put):
        (JSC::GenericArguments<Type>::deleteProperty):
        (JSC::GenericArguments<Type>::defineOwnProperty):
        * runtime/HasOwnPropertyCache.h:
        (JSC::HasOwnPropertyCache::get):
        * runtime/HashMapImpl.h:
        (JSC::concurrentJSMapHash):
        * runtime/Identifier.h:
        (JSC::parseIndex):
        * runtime/JSArray.cpp:
        (JSC::JSArray::defineOwnProperty):
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::toNumberFromPrimitive):
        (JSC::JSValue::putToPrimitive):
        * runtime/JSCJSValue.h:
        * runtime/JSGenericTypedArrayView.h:
        (JSC::JSGenericTypedArrayView::toAdaptorNativeFromValueWithoutCoercion):
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::constructGenericTypedArrayViewWithArguments):
        (JSC::constructGenericTypedArrayView):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
        (JSC::JSGenericTypedArrayView<Adaptor>::put):
        * runtime/JSModuleRecord.cpp:
        * runtime/JSModuleRecord.h:
        * runtime/JSObject.cpp:
        (JSC::JSObject::putDirectAccessor):
        (JSC::JSObject::deleteProperty):
        (JSC::JSObject::putDirectMayBeIndex):
        (JSC::JSObject::defineOwnProperty):
        * runtime/JSObject.h:
        (JSC::JSObject::getOwnPropertySlot):
        (JSC::JSObject::getPropertySlot):
        (JSC::JSObject::putOwnDataPropertyMayBeIndex):
        * runtime/JSObjectInlines.h:
        (JSC::JSObject::putInline):
        * runtime/JSString.cpp:
        (JSC::JSString::getStringPropertyDescriptor):
        * runtime/JSString.h:
        (JSC::JSString::getStringPropertySlot):
        * runtime/LiteralParser.cpp:
        (JSC::LiteralParser<CharType>::parse):
        * runtime/MathCommon.h:
        (JSC::safeReciprocalForDivByConst):
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncHasOwnProperty):
        * runtime/PropertyDescriptor.h:
        (JSC::toPropertyDescriptor):
        * runtime/PropertyName.h:
        (JSC::parseIndex):
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::processUnverifiedStackTraces):
        * runtime/StringObject.cpp:
        (JSC::StringObject::put):
        (JSC::isStringOwnProperty):
        (JSC::StringObject::deleteProperty):
        * runtime/ToNativeFromValue.h:
        (JSC::toNativeFromValueWithoutCoercion):
        * runtime/TypedArrayAdaptors.h:
        (JSC::IntegralTypedArrayAdaptor::toNativeFromInt32WithoutCoercion):
        (JSC::IntegralTypedArrayAdaptor::toNativeFromUint32WithoutCoercion):
        (JSC::IntegralTypedArrayAdaptor::toNativeFromDoubleWithoutCoercion):
        (JSC::FloatTypedArrayAdaptor::toNativeFromInt32WithoutCoercion):
        (JSC::FloatTypedArrayAdaptor::toNativeFromDoubleWithoutCoercion):
        (JSC::Uint8ClampedAdaptor::toNativeFromInt32WithoutCoercion):
        (JSC::Uint8ClampedAdaptor::toNativeFromDoubleWithoutCoercion):

2016-11-26  Sam Weinig  <sam@webkit.org>

        Convert IntersectionObserver over to using RuntimeEnabledFeatures so it can be properly excluded from script
        https://bugs.webkit.org/show_b