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

        Arity fixup during inlining should do a 2 phase commit so it properly recovers the frame in case of exit
        https://bugs.webkit.org/show_bug.cgi?id=176981

        Reviewed by Yusuke Suzuki.

        This patch makes inline arity fixup happen in two phases:
        1. We get all the values we need and MovHint them to the expected locals.
        2. We SetLocal them inside the callee's CodeOrigin. This way, if we exit, the callee's
           frame is already set up. If any SetLocal exits, we have a valid exit state.
           This is required because if we didn't do this in two phases, we may exit in
           the middle of arity fixup from the caller's CodeOrigin. This is unsound because if
           we did the SetLocals in the caller's frame, the memcpy may clobber needed parts
           of the frame right before exiting. For example, consider if we need to pad two args:
           [arg3][arg2][arg1][arg0]
           [fix ][fix ][arg3][arg2][arg1][arg0]
           We memcpy starting from arg0 in the direction of arg3. If we were to exit at a type check
           for arg3's SetLocal in the caller's CodeOrigin, we'd exit with a frame like so:
           [arg3][arg2][arg1][arg2][arg1][arg0]
           And the caller would then just end up thinking its argument are:
           [arg3][arg2][arg1][arg2]
           which is incorrect.
       
       
        This patch also fixes a couple of bugs in IdentitiyWithProfile:
        1. The bytecode generator for this bytecode intrinsic was written incorrectly.
           It needed to store the result of evaluating its argument in a temporary that
           it creates. Otherwise, it might try to simply overwrite a constant
           or a register that it didn't own.
        2. We weren't eliminating this node in CSE inside the DFG.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_idWithProfile):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::inlineCall):
        * dfg/DFGCSEPhase.cpp:

2017-09-15  JF Bastien  <jfbastien@apple.com>

        WTF: use Forward.h when appropriate instead of Vector.h
        https://bugs.webkit.org/show_bug.cgi?id=176984

        Reviewed by Saam Barati.

        There's no need to include Vector.h when Forward.h will suffice. All we need is to move the template default parameters from Vector, and then the forward declaration can be used in so many new places: if a header only takes Vector by reference, rvalue reference, pointer, returns any of these, or has them as members then the header doesn't need to see the definition because the declaration will suffice.

        * bytecode/HandlerInfo.h:
        * heap/GCIncomingRefCounted.h:
        * heap/GCSegmentedArray.h:
        * wasm/js/JSWebAssemblyModule.h:

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

        We should have a way of preventing a caller from making a tail call and we should use it for ProxyObject instead of using build flags
        https://bugs.webkit.org/show_bug.cgi?id=176863

        Reviewed by Keith Miller.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/ProxyObject.cpp:
        (JSC::performProxyGet):
        (JSC::ProxyObject::performInternalMethodGetOwnProperty):
        (JSC::ProxyObject::performHasProperty):
        (JSC::ProxyObject::getOwnPropertySlotCommon):
        (JSC::ProxyObject::performPut):
        (JSC::performProxyCall):
        (JSC::performProxyConstruct):
        (JSC::ProxyObject::performDelete):
        (JSC::ProxyObject::performPreventExtensions):
        (JSC::ProxyObject::performIsExtensible):
        (JSC::ProxyObject::performDefineOwnProperty):
        (JSC::ProxyObject::performGetOwnPropertyNames):
        (JSC::ProxyObject::performSetPrototype):
        (JSC::ProxyObject::performGetPrototype):

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

        Make dumping the graph print when both when exitOK and !exitOK
        https://bugs.webkit.org/show_bug.cgi?id=176954

        Reviewed by Keith Miller.

        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):

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

        It should be valid to exit before each set when doing arity fixup when inlining
        https://bugs.webkit.org/show_bug.cgi?id=176948

        Reviewed by Keith Miller.

        This patch makes it so that we can exit before each SetLocal when doing arity
        fixup during inlining. This is OK because if we exit at any of these SetLocals,
        we will simply exit to the beginning of the call instruction.
        
        Not doing this led to a bug where FixupPhase would insert a ValueRep of
        a node before the actual node. This is obviously invalid IR. I've added
        a new validation rule to catch this malformed IR.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::inliningCost):
        (JSC::DFG::ByteCodeParser::inlineCall):
        * dfg/DFGValidate.cpp:
        * runtime/Options.h:

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

        AddressSanitizer: stack-buffer-underflow in JSC::Probe::Page::Page
        https://bugs.webkit.org/show_bug.cgi?id=176874
        <rdar://problem/34436415>

        Reviewed by Saam Barati.

        1. Make Probe::Stack play nice with ASan by:

           a. using a local memcpy implementation that suppresses ASan on ASan builds.
              We don't want to use std:memcpy() which validates stack memory because
              we are intentionally copying stack memory beyond the current frame.

           b. changing Stack::s_chunkSize to equal sizeof(uintptr_t) on ASan builds.
              This ensures that Page::flushWrites() only writes stack memory that was
              modified by a probe.  The probes should only modify stack memory that
              belongs to JSC stack data structures.  We don't want to inadvertently
              modify adjacent words that may belong to ASan (which may happen if
              s_chunkSize is larger than sizeof(uintptr_t)).

           c. fixing a bug in Page dirtyBits management for when the size of the value to
              write is greater than s_chunkSize.  The fix in generic, but in practice,
              this currently only manifests on 32-bit ASan builds because
              sizeof(uintptr_t) and s_chunkSize are 32-bit, and we may write 64-bit
              values.

           d. making Page::m_dirtyBits 64 bits always.  This maximizes the number of
              s_chunksPerPage we can have even on ASan builds.

        2. Fixed the bottom most Probe::Context and Probe::Stack get/set methods to use
           std::memcpy to avoid strict aliasing issues.

        3. Optimized the implementation of Page::physicalAddressFor().

        4. Optimized the implementation of Stack::set() in the recording of the low
           watermark.  We just record the lowest raw pointer now, and only compute the
           alignment to its chuck boundary later when the low watermark is requested.

        5. Changed a value in testmasm to make the test less vulnerable to rounding issues.

        No new test needed because this is already covered by testmasm with ASan enabled.

        * assembler/ProbeContext.h:
        (JSC::Probe::CPUState::gpr const):
        (JSC::Probe::CPUState::spr const):
        (JSC::Probe::Context::gpr):
        (JSC::Probe::Context::spr):
        (JSC::Probe::Context::fpr):
        (JSC::Probe::Context::gprName):
        (JSC::Probe::Context::sprName):
        (JSC::Probe::Context::fprName):
        (JSC::Probe::Context::gpr const):
        (JSC::Probe::Context::spr const):
        (JSC::Probe::Context::fpr const):
        (JSC::Probe::Context::pc):
        (JSC::Probe::Context::fp):
        (JSC::Probe::Context::sp):
        (JSC::Probe:: const): Deleted.
        * assembler/ProbeStack.cpp:
        (JSC::Probe::copyStackPage):
        (JSC::Probe::Page::Page):
        (JSC::Probe::Page::flushWrites):
        * assembler/ProbeStack.h:
        (JSC::Probe::Page::get):
        (JSC::Probe::Page::set):
        (JSC::Probe::Page::dirtyBitFor):
        (JSC::Probe::Page::physicalAddressFor):
        (JSC::Probe::Stack::lowWatermark):
        (JSC::Probe::Stack::get):
        (JSC::Probe::Stack::set):
        * assembler/testmasm.cpp:
        (JSC::testProbeModifiesStackValues):

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

        [JSC] Disable Arity Fixup Inlining until crash in facebook.com is fixed
        https://bugs.webkit.org/show_bug.cgi?id=176917

        Reviewed by Saam Barati.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::inliningCost):
        * runtime/Options.h:

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

        [JSC] Add PrivateSymbolMode::{Include,Exclude} for PropertyNameArray
        https://bugs.webkit.org/show_bug.cgi?id=176867

        Reviewed by Sam Weinig.

        We rarely require private symbols when enumerating property names.
        This patch adds PrivateSymbolMode::{Include,Exclude}. If PrivateSymbolMode::Exclude
        is specified, PropertyNameArray does not include private symbols.
        This removes many ad-hoc `Identifier::isPrivateName()` in enumeration operations.

        One additional good thing is that we do not need to filter private symbols out from PropertyNameArray.
        It allows us to use Object.keys()'s fast path for Object.getOwnPropertySymbols.

        object-get-own-property-symbols                48.6275+-1.0021     ^     38.1846+-1.7934        ^ definitely 1.2735x faster

        * API/JSObjectRef.cpp:
        (JSObjectCopyPropertyNames):
        * bindings/ScriptValue.cpp:
        (Inspector::jsToInspectorValue):
        * bytecode/ObjectAllocationProfile.h:
        (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount):
        * runtime/EnumerationMode.h:
        * runtime/IntlObject.cpp:
        (JSC::supportedLocales):
        * runtime/JSONObject.cpp:
        (JSC::Stringifier::Stringifier):
        (JSC::Stringifier::Holder::appendNextProperty):
        (JSC::Walker::walk):
        * runtime/JSPropertyNameEnumerator.cpp:
        (JSC::JSPropertyNameEnumerator::create):
        * runtime/JSPropertyNameEnumerator.h:
        (JSC::propertyNameEnumerator):
        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorGetOwnPropertyDescriptors):
        (JSC::objectConstructorAssign):
        (JSC::objectConstructorValues):
        (JSC::defineProperties):
        (JSC::setIntegrityLevel):
        (JSC::testIntegrityLevel):
        (JSC::ownPropertyKeys):
        * runtime/PropertyNameArray.h:
        (JSC::PropertyNameArray::PropertyNameArray):
        (JSC::PropertyNameArray::propertyNameMode const):
        (JSC::PropertyNameArray::privateSymbolMode const):
        (JSC::PropertyNameArray::addUncheckedInternal):
        (JSC::PropertyNameArray::addUnchecked):
        (JSC::PropertyNameArray::add):
        (JSC::PropertyNameArray::isUidMatchedToTypeMode):
        (JSC::PropertyNameArray::includeSymbolProperties const):
        (JSC::PropertyNameArray::includeStringProperties const):
        (JSC::PropertyNameArray::mode const): Deleted.
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::performGetOwnPropertyNames):

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

        Rolling out r221832: Regresses Speedometer by ~4% and Dromaeo CSS YUI by ~20%.
        https://bugs.webkit.org/show_bug.cgi?id=176888
        <rdar://problem/34381832>

        Not reviewed.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/MacroAssembler.cpp:
        (JSC::stdFunctionCallback):
        * assembler/MacroAssemblerPrinter.cpp:
        (JSC::Printer::printCallback):
        * assembler/ProbeContext.h:
        (JSC::Probe:: const):
        (JSC::Probe::Context::Context):
        (JSC::Probe::Context::gpr):
        (JSC::Probe::Context::spr):
        (JSC::Probe::Context::fpr):
        (JSC::Probe::Context::gprName):
        (JSC::Probe::Context::sprName):
        (JSC::Probe::Context::fprName):
        (JSC::Probe::Context::pc):
        (JSC::Probe::Context::fp):
        (JSC::Probe::Context::sp):
        (JSC::Probe::CPUState::gpr const): Deleted.
        (JSC::Probe::CPUState::spr const): Deleted.
        (JSC::Probe::Context::arg): Deleted.
        (JSC::Probe::Context::gpr const): Deleted.
        (JSC::Probe::Context::spr const): Deleted.
        (JSC::Probe::Context::fpr const): Deleted.
        * assembler/ProbeFrame.h: Removed.
        * assembler/ProbeStack.cpp:
        (JSC::Probe::Page::Page):
        * assembler/ProbeStack.h:
        (JSC::Probe::Page::get):
        (JSC::Probe::Page::set):
        (JSC::Probe::Page::physicalAddressFor):
        (JSC::Probe::Stack::lowWatermark):
        (JSC::Probe::Stack::get):
        (JSC::Probe::Stack::set):
        * bytecode/ArithProfile.cpp:
        * bytecode/ArithProfile.h:
        * bytecode/ArrayProfile.h:
        (JSC::ArrayProfile::observeArrayMode): Deleted.
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::updateOSRExitCounterAndCheckIfNeedToReoptimize): Deleted.
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::addressOfOSRExitCounter):
        * bytecode/ExecutionCounter.h:
        (JSC::ExecutionCounter::hasCrossedThreshold const): Deleted.
        (JSC::ExecutionCounter::setNewThresholdForOSRExit): Deleted.
        * bytecode/MethodOfGettingAValueProfile.cpp:
        (JSC::MethodOfGettingAValueProfile::reportValue): Deleted.
        * bytecode/MethodOfGettingAValueProfile.h:
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compileImpl):
        * dfg/DFGJITCode.cpp:
        (JSC::DFG::JITCode::findPC):
        * dfg/DFGJITCode.h:
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::linkOSRExits):
        (JSC::DFG::JITCompiler::link):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::setPatchableCodeOffset):
        (JSC::DFG::OSRExit::getPatchableCodeOffsetAsJump const):
        (JSC::DFG::OSRExit::codeLocationForRepatch const):
        (JSC::DFG::OSRExit::correctJump):
        (JSC::DFG::OSRExit::emitRestoreArguments):
        (JSC::DFG::OSRExit::compileOSRExit):
        (JSC::DFG::OSRExit::compileExit):
        (JSC::DFG::OSRExit::debugOperationPrintSpeculationFailure):
        (JSC::DFG::jsValueFor): Deleted.
        (JSC::DFG::restoreCalleeSavesFor): Deleted.
        (JSC::DFG::saveCalleeSavesFor): Deleted.
        (JSC::DFG::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer): Deleted.
        (JSC::DFG::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer): Deleted.
        (JSC::DFG::saveOrCopyCalleeSavesFor): Deleted.
        (JSC::DFG::createDirectArgumentsDuringExit): Deleted.
        (JSC::DFG::createClonedArgumentsDuringExit): Deleted.
        (JSC::DFG::emitRestoreArguments): Deleted.
        (JSC::DFG::OSRExit::executeOSRExit): Deleted.
        (JSC::DFG::reifyInlinedCallFrames): Deleted.
        (JSC::DFG::adjustAndJumpToTarget): Deleted.
        (JSC::DFG::printOSRExit): Deleted.
        * dfg/DFGOSRExit.h:
        (JSC::DFG::OSRExitState::OSRExitState): Deleted.
        * dfg/DFGOSRExitCompilerCommon.cpp:
        * dfg/DFGOSRExitCompilerCommon.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGThunks.cpp:
        (JSC::DFG::osrExitGenerationThunkGenerator):
        (JSC::DFG::osrExitThunkGenerator): Deleted.
        * dfg/DFGThunks.h:
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::debugCall):
        * jit/AssemblyHelpers.h:
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * profiler/ProfilerOSRExit.h:
        (JSC::Profiler::OSRExit::incCount): Deleted.
        * runtime/JSCJSValue.h:
        * runtime/JSCJSValueInlines.h:
        * runtime/VM.h:

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

        [JSC] Move class/struct used in other class' member out of anonymous namespace
        https://bugs.webkit.org/show_bug.cgi?id=176876

        Reviewed by Saam Barati.

        GCC warns if a class has a base or field whose type uses the anonymous namespace
        and it is defined in an included file. This is because this possibly violates
        one definition rule (ODR): if an included file has the anonymous namespace, each
        translation unit creates its private anonymous namespace. Thus, each type
        inside the anonymous namespace becomes different in each translation unit if
        the file is included in multiple translation units.

        While the current use in JSC is not violating ODR since these cpp files are included
        only once for unified sources, specifying `-Wno-subobject-linkage` could miss
        the actual bugs. So, in this patch, we just move related classes/structs out of
        the anonymous namespace.

        * dfg/DFGIntegerCheckCombiningPhase.cpp:
        (JSC::DFG::IntegerCheckCombiningPhase::RangeKey::addition):
        (JSC::DFG::IntegerCheckCombiningPhase::RangeKey::arrayBounds):
        (JSC::DFG::IntegerCheckCombiningPhase::RangeKey::operator! const):
        (JSC::DFG::IntegerCheckCombiningPhase::RangeKey::hash const):
        (JSC::DFG::IntegerCheckCombiningPhase::RangeKey::operator== const):
        (JSC::DFG::IntegerCheckCombiningPhase::RangeKey::dump const):
        (JSC::DFG::IntegerCheckCombiningPhase::RangeKeyAndAddend::RangeKeyAndAddend):
        (JSC::DFG::IntegerCheckCombiningPhase::RangeKeyAndAddend::operator! const):
        (JSC::DFG::IntegerCheckCombiningPhase::RangeKeyAndAddend::dump const):
        (JSC::DFG::IntegerCheckCombiningPhase::Range::dump const):
        * dfg/DFGLICMPhase.cpp:

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

        Web Inspector: Event Listeners section does not update when listeners are added/removed
        https://bugs.webkit.org/show_bug.cgi?id=170570
        <rdar://problem/31501645>

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/DOM.json:
        Add two new events: "didAddEventListener" and "willRemoveEventListener". These events do not
        contain any information about the event listeners that were added/removed. They serve more
        as indications that something has changed, and to refetch the data again via `getEventListenersForNode`.

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

        [JSC] Fix Array allocation in Object.keys
        https://bugs.webkit.org/show_bug.cgi?id=176826

        Reviewed by Saam Barati.

        When isHavingABadTime() is true, array allocation does not become ArrayWithContiguous.
        We check isHavingABadTime() in ownPropertyKeys fast path.
        And we also ensures that ownPropertyKeys uses putDirect operation instead of put by a test.

        * runtime/ObjectConstructor.cpp:
        (JSC::ownPropertyKeys):

2017-09-12  Yusuke Suzuki  <utatane.tea@gmail.com>

        [DFG] Optimize WeakMap::get by adding intrinsic and fixup
        https://bugs.webkit.org/show_bug.cgi?id=176010

        Reviewed by Filip Pizlo.

        It reveals that Ember.js consumes 3.8% of execution time for WeakMap#get.
        It is used for meta property for objects (see peekMeta function in Ember.js).

        This patch optimizes WeakMap#get.

        1. We use inlineGet to inline WeakMap#get operation in the native function.
        Since this native function itself is very small, we should inline HashMap#get
        entirely in this function.

        2. We add JSWeakMapType and JSWeakSetType. This allows us to perform `isJSWeakMap()`
        very fast. And this patch wires this to DFG and FTL to add WeakMapObjectUse and WeakSetObjectUse
        to drop unnecessary type checking. We add fixup rules for WeakMapGet DFG node by using WeakMapObjectUse,
        ObjectUse, and Int32Use.

        3. We add intrinsic for WeakMap#get, and handle it in DFG and FTL. We use MapHash to
        calculate hash value for the key's Object and use this hash value to look up value from
        JSWeakMap's HashMap. Currently, we just call the operationWeakMapGet function in DFG and FTL.
        It is worth considering that implementing this operation entirely in JIT, like GetMapBucket.
        But anyway, the current one already optimizes the performance, so we leave this for the subsequent
        patches.

        We currently do not implement any other intrinsics (like, WeakMap#has, WeakSet) because they are
        not used in Ember.js right now.

        This patch optimizes WeakMap#get by 50%.

                                 baseline                  patched

        weak-map-key         88.6456+-3.9564     ^     59.1502+-2.2406        ^ definitely 1.4987x faster

        * bytecode/DirectEvalCodeCache.h:
        (JSC::DirectEvalCodeCache::tryGet):
        * bytecode/SpeculatedType.cpp:
        (JSC::dumpSpeculation):
        (JSC::speculationFromClassInfo):
        (JSC::speculationFromJSType):
        (JSC::speculationFromString):
        * bytecode/SpeculatedType.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/DFGHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGHeapLocation.h:
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasHeapPrediction):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::SafeToExecuteEdge::operator()):
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::speculateWeakMapObject):
        (JSC::DFG::SpeculativeJIT::speculateWeakSetObject):
        (JSC::DFG::SpeculativeJIT::speculate):
        (JSC::DFG::SpeculativeJIT::compileWeakMapGet):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGUseKind.cpp:
        (WTF::printInternal):
        * dfg/DFGUseKind.h:
        (JSC::DFG::typeFilterFor):
        (JSC::DFG::isCell):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileWeakMapGet):
        (JSC::FTL::DFG::LowerDFGToB3::lowWeakMapObject):
        (JSC::FTL::DFG::LowerDFGToB3::lowWeakSetObject):
        (JSC::FTL::DFG::LowerDFGToB3::speculate):
        (JSC::FTL::DFG::LowerDFGToB3::speculateWeakMapObject):
        (JSC::FTL::DFG::LowerDFGToB3::speculateWeakSetObject):
        * jit/JITOperations.h:
        * runtime/HashMapImpl.h:
        (JSC::WeakMapHash::hash):
        (JSC::WeakMapHash::equal):
        * runtime/Intrinsic.cpp:
        (JSC::intrinsicName):
        * runtime/Intrinsic.h:
        * runtime/JSType.h:
        * runtime/JSWeakMap.h:
        (JSC::isJSWeakMap):
        * runtime/JSWeakSet.h:
        (JSC::isJSWeakSet):
        * runtime/WeakMapBase.cpp:
        (JSC::WeakMapBase::get):
        * runtime/WeakMapBase.h:
        (JSC::WeakMapBase::HashTranslator::hash):
        (JSC::WeakMapBase::HashTranslator::equal):
        (JSC::WeakMapBase::inlineGet):
        * runtime/WeakMapPrototype.cpp:
        (JSC::WeakMapPrototype::finishCreation):
        (JSC::getWeakMap):
        (JSC::protoFuncWeakMapGet):
        * runtime/WeakSetPrototype.cpp:
        (JSC::getWeakSet):

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

        Rename JavaScriptCore CMake unifiable sources list
        https://bugs.webkit.org/show_bug.cgi?id=176823

        Reviewed by Joseph Pecoraro.

        This patch also changes the error message when the unified source
        bundler fails to be more accurate.

        * CMakeLists.txt:

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

        Do unified source builds for JSC
        https://bugs.webkit.org/show_bug.cgi?id=176076

        Reviewed by Geoffrey Garen.

        This patch switches the CMake JavaScriptCore build to use unified sources.
        The Xcode build will be upgraded in a follow up patch.

        Most of the source changes in this patch are fixing static
        variable/functions name collisions. The most common collisions
        were from our use of "static const bool verbose" and "using
        namespace ...". I fixed all the verbose cases and fixed the "using
        namespace" issues that occurred under the current bundling
        strategy. It's likely that more of the "using namespace" issues
        will need to be resolved in the future, particularly in the FTL.

        I don't expect either of these problems will apply to other parts
        of the project nearly as much as in JSC. Using a verbose variable
        is a JSC idiom and JSC tends use the same, canonical, class name
        in multiple parts of the engine.

        * CMakeLists.txt:
        * b3/B3CheckSpecial.cpp:
        (JSC::B3::CheckSpecial::forEachArg):
        (JSC::B3::CheckSpecial::generate):
        (JSC::B3::Air::numB3Args): Deleted.
        * b3/B3DuplicateTails.cpp:
        * b3/B3EliminateCommonSubexpressions.cpp:
        * b3/B3FixSSA.cpp:
        (JSC::B3::demoteValues):
        * b3/B3FoldPathConstants.cpp:
        * b3/B3InferSwitches.cpp:
        * b3/B3LowerMacrosAfterOptimizations.cpp:
        (): Deleted.
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::LowerToAir): Deleted.
        (JSC::B3::Air::LowerToAir::run): Deleted.
        (JSC::B3::Air::LowerToAir::shouldCopyPropagate): Deleted.
        (JSC::B3::Air::LowerToAir::ArgPromise::ArgPromise): Deleted.
        (JSC::B3::Air::LowerToAir::ArgPromise::swap): Deleted.
        (JSC::B3::Air::LowerToAir::ArgPromise::operator=): Deleted.
        (JSC::B3::Air::LowerToAir::ArgPromise::~ArgPromise): Deleted.
        (JSC::B3::Air::LowerToAir::ArgPromise::setTraps): Deleted.
        (JSC::B3::Air::LowerToAir::ArgPromise::tmp): Deleted.
        (JSC::B3::Air::LowerToAir::ArgPromise::operator bool const): Deleted.
        (JSC::B3::Air::LowerToAir::ArgPromise::kind const): Deleted.
        (JSC::B3::Air::LowerToAir::ArgPromise::peek const): Deleted.
        (JSC::B3::Air::LowerToAir::ArgPromise::consume): Deleted.
        (JSC::B3::Air::LowerToAir::ArgPromise::inst): Deleted.
        (JSC::B3::Air::LowerToAir::tmp): Deleted.
        (JSC::B3::Air::LowerToAir::tmpPromise): Deleted.
        (JSC::B3::Air::LowerToAir::canBeInternal): Deleted.
        (JSC::B3::Air::LowerToAir::commitInternal): Deleted.
        (JSC::B3::Air::LowerToAir::crossesInterference): Deleted.
        (JSC::B3::Air::LowerToAir::scaleForShl): Deleted.
        (JSC::B3::Air::LowerToAir::effectiveAddr): Deleted.
        (JSC::B3::Air::LowerToAir::addr): Deleted.
        (JSC::B3::Air::LowerToAir::trappingInst): Deleted.
        (JSC::B3::Air::LowerToAir::loadPromiseAnyOpcode): Deleted.
        (JSC::B3::Air::LowerToAir::loadPromise): Deleted.
        (JSC::B3::Air::LowerToAir::imm): Deleted.
        (JSC::B3::Air::LowerToAir::bitImm): Deleted.
        (JSC::B3::Air::LowerToAir::bitImm64): Deleted.
        (JSC::B3::Air::LowerToAir::immOrTmp): Deleted.
        (JSC::B3::Air::LowerToAir::tryOpcodeForType): Deleted.
        (JSC::B3::Air::LowerToAir::opcodeForType): Deleted.
        (JSC::B3::Air::LowerToAir::appendUnOp): Deleted.
        (JSC::B3::Air::LowerToAir::preferRightForResult): Deleted.
        (JSC::B3::Air::LowerToAir::appendBinOp): Deleted.
        (JSC::B3::Air::LowerToAir::appendShift): Deleted.
        (JSC::B3::Air::LowerToAir::tryAppendStoreUnOp): Deleted.
        (JSC::B3::Air::LowerToAir::tryAppendStoreBinOp): Deleted.
        (JSC::B3::Air::LowerToAir::createStore): Deleted.
        (JSC::B3::Air::LowerToAir::storeOpcode): Deleted.
        (JSC::B3::Air::LowerToAir::appendStore): Deleted.
        (JSC::B3::Air::LowerToAir::moveForType): Deleted.
        (JSC::B3::Air::LowerToAir::relaxedMoveForType): Deleted.
        (JSC::B3::Air::LowerToAir::print): Deleted.
        (JSC::B3::Air::LowerToAir::append): Deleted.
        (JSC::B3::Air::LowerToAir::appendTrapping): Deleted.
        (JSC::B3::Air::LowerToAir::finishAppendingInstructions): Deleted.
        (JSC::B3::Air::LowerToAir::newBlock): Deleted.
        (JSC::B3::Air::LowerToAir::splitBlock): Deleted.
        (JSC::B3::Air::LowerToAir::ensureSpecial): Deleted.
        (JSC::B3::Air::LowerToAir::ensureCheckSpecial): Deleted.
        (JSC::B3::Air::LowerToAir::fillStackmap): Deleted.
        (JSC::B3::Air::LowerToAir::createGenericCompare): Deleted.
        (JSC::B3::Air::LowerToAir::createBranch): Deleted.
        (JSC::B3::Air::LowerToAir::createCompare): Deleted.
        (JSC::B3::Air::LowerToAir::createSelect): Deleted.
        (JSC::B3::Air::LowerToAir::tryAppendLea): Deleted.
        (JSC::B3::Air::LowerToAir::appendX86Div): Deleted.
        (JSC::B3::Air::LowerToAir::appendX86UDiv): Deleted.
        (JSC::B3::Air::LowerToAir::loadLinkOpcode): Deleted.
        (JSC::B3::Air::LowerToAir::storeCondOpcode): Deleted.
        (JSC::B3::Air::LowerToAir::appendCAS): Deleted.
        (JSC::B3::Air::LowerToAir::appendVoidAtomic): Deleted.
        (JSC::B3::Air::LowerToAir::appendGeneralAtomic): Deleted.
        (JSC::B3::Air::LowerToAir::lower): Deleted.
        * b3/B3PatchpointSpecial.cpp:
        (JSC::B3::PatchpointSpecial::generate):
        * b3/B3ReduceDoubleToFloat.cpp:
        (JSC::B3::reduceDoubleToFloat):
        * b3/B3ReduceStrength.cpp:
        * b3/B3StackmapGenerationParams.cpp:
        * b3/B3StackmapSpecial.cpp:
        (JSC::B3::StackmapSpecial::repsImpl):
        (JSC::B3::StackmapSpecial::repForArg):
        * b3/air/AirAllocateStackByGraphColoring.cpp:
        (JSC::B3::Air::allocateStackByGraphColoring):
        * b3/air/AirEmitShuffle.cpp:
        (JSC::B3::Air::emitShuffle):
        * b3/air/AirFixObviousSpills.cpp:
        * b3/air/AirLowerAfterRegAlloc.cpp:
        (JSC::B3::Air::lowerAfterRegAlloc):
        * b3/air/AirStackAllocation.cpp:
        (JSC::B3::Air::attemptAssignment):
        (JSC::B3::Air::assign):
        * bytecode/AccessCase.cpp:
        (JSC::AccessCase::generateImpl):
        * bytecode/CallLinkStatus.cpp:
        (JSC::CallLinkStatus::computeDFGStatuses):
        * bytecode/GetterSetterAccessCase.cpp:
        (JSC::GetterSetterAccessCase::emitDOMJITGetter):
        * bytecode/ObjectPropertyConditionSet.cpp:
        * bytecode/PolymorphicAccess.cpp:
        (JSC::PolymorphicAccess::addCases):
        (JSC::PolymorphicAccess::regenerate):
        * bytecode/PropertyCondition.cpp:
        (JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint const):
        * bytecode/StructureStubInfo.cpp:
        (JSC::StructureStubInfo::addAccessCase):
        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::DelayedSetLocal::DelayedSetLocal):
        (JSC::DFG::ByteCodeParser::inliningCost):
        (JSC::DFG::ByteCodeParser::inlineCall):
        (JSC::DFG::ByteCodeParser::attemptToInlineCall):
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::planLoad):
        (JSC::DFG::ByteCodeParser::store):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::linkBlock):
        (JSC::DFG::ByteCodeParser::linkBlocks):
        * dfg/DFGCSEPhase.cpp:
        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::InPlaceAbstractState::merge):
        * dfg/DFGIntegerCheckCombiningPhase.cpp:
        (JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
        * dfg/DFGIntegerRangeOptimizationPhase.cpp:
        * dfg/DFGMovHintRemovalPhase.cpp:
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        * dfg/DFGPhantomInsertionPhase.cpp:
        * dfg/DFGPutStackSinkingPhase.cpp:
        * dfg/DFGStoreBarrierInsertionPhase.cpp:
        * dfg/DFGVarargsForwardingPhase.cpp:
        * ftl/FTLAbstractHeap.cpp:
        (JSC::FTL::AbstractHeap::compute):
        * ftl/FTLAbstractHeapRepository.cpp:
        (JSC::FTL::AbstractHeapRepository::decorateMemory):
        (JSC::FTL::AbstractHeapRepository::decorateCCallRead):
        (JSC::FTL::AbstractHeapRepository::decorateCCallWrite):
        (JSC::FTL::AbstractHeapRepository::decoratePatchpointRead):
        (JSC::FTL::AbstractHeapRepository::decoratePatchpointWrite):
        (JSC::FTL::AbstractHeapRepository::decorateFenceRead):
        (JSC::FTL::AbstractHeapRepository::decorateFenceWrite):
        (JSC::FTL::AbstractHeapRepository::decorateFencedAccess):
        (JSC::FTL::AbstractHeapRepository::computeRangesAndDecorateInstructions):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * heap/MarkingConstraintSet.cpp:
        (JSC::MarkingConstraintSet::add):
        * interpreter/ShadowChicken.cpp:
        (JSC::ShadowChicken::update):
        * jit/BinarySwitch.cpp:
        (JSC::BinarySwitch::BinarySwitch):
        (JSC::BinarySwitch::build):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::loadStats):
        (JSC::LLInt::Data::saveStats):
        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::tryInitializeSpeciesWatchpoint):
        (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::handleFire):
        * runtime/ErrorInstance.cpp:
        (JSC::FindFirstCallerFrameWithCodeblockFunctor::FindFirstCallerFrameWithCodeblockFunctor): Deleted.
        (JSC::FindFirstCallerFrameWithCodeblockFunctor::operator()): Deleted.
        (JSC::FindFirstCallerFrameWithCodeblockFunctor::foundCallFrame const): Deleted.
        (JSC::FindFirstCallerFrameWithCodeblockFunctor::index const): Deleted.
        * runtime/IntlDateTimeFormat.cpp:
        (JSC::IntlDateTimeFormat::initializeDateTimeFormat):
        * runtime/PromiseDeferredTimer.cpp:
        (JSC::PromiseDeferredTimer::doWork):
        (JSC::PromiseDeferredTimer::addPendingPromise):
        (JSC::PromiseDeferredTimer::cancelPendingPromise):
        * runtime/TypeProfiler.cpp:
        (JSC::TypeProfiler::insertNewLocation):
        * runtime/TypeProfilerLog.cpp:
        (JSC::TypeProfilerLog::processLogEntries):
        * runtime/WeakMapPrototype.cpp:
        (JSC::protoFuncWeakMapDelete):
        (JSC::protoFuncWeakMapGet):
        (JSC::protoFuncWeakMapHas):
        (JSC::protoFuncWeakMapSet):
        (JSC::getWeakMapData): Deleted.
        * runtime/WeakSetPrototype.cpp:
        (JSC::protoFuncWeakSetDelete):
        (JSC::protoFuncWeakSetHas):
        (JSC::protoFuncWeakSetAdd):
        (JSC::getWeakMapData): Deleted.
        * testRegExp.cpp:
        (testOneRegExp):
        (runFromFiles):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::parseAndCompile):
        * wasm/WasmBBQPlan.cpp:
        (JSC::Wasm::BBQPlan::moveToState):
        (JSC::Wasm::BBQPlan::parseAndValidateModule):
        (JSC::Wasm::BBQPlan::prepare):
        (JSC::Wasm::BBQPlan::compileFunctions):
        (JSC::Wasm::BBQPlan::complete):
        * wasm/WasmFaultSignalHandler.cpp:
        (JSC::Wasm::trapHandler):
        * wasm/WasmOMGPlan.cpp:
        (JSC::Wasm::OMGPlan::OMGPlan):
        (JSC::Wasm::OMGPlan::work):
        * wasm/WasmPlan.cpp:
        (JSC::Wasm::Plan::fail):
        * wasm/WasmSignature.cpp:
        (JSC::Wasm::SignatureInformation::adopt):
        * wasm/WasmWorklist.cpp:
        (JSC::Wasm::Worklist::enqueue):

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

        String.prototype.replace() puts extra '<' in result when a named capture reference is used without named captures in the RegExp
        https://bugs.webkit.org/show_bug.cgi?id=176814

        Reviewed by Mark Lam.

        The copy and advance indices where off by one and needed a little fine tuning.

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

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

        More exception check book-keeping needed found by 32-bit JSC test failures.
        https://bugs.webkit.org/show_bug.cgi?id=176742

        Reviewed by Michael Saboff and Keith Miller.

        * dfg/DFGOperations.cpp:

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

        Make jsc dump the command line if JSC_dumpOption environment variable is set with a non-zero value.
        https://bugs.webkit.org/show_bug.cgi?id=176722

        Reviewed by Saam Barati.

        For PLATFORM(COCOA), I also dumped the JSC_* environmental variables that are
        in effect when jsc is invoked.

        * jsc.cpp:
        (CommandLine::parseArguments):

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

        Unreviewed, rolling out r221854.

        The test added with this change fails on 32-bit JSC bots.

        Reverted changeset:

        "[DFG] Optimize WeakMap::get by adding intrinsic and fixup"
        https://bugs.webkit.org/show_bug.cgi?id=176010
        http://trac.webkit.org/changeset/221854

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

        [DFG] Optimize WeakMap::get by adding intrinsic and fixup
        https://bugs.webkit.org/show_bug.cgi?id=176010

        Reviewed by Filip Pizlo.

        It reveals that Ember.js consumes 3.8% of execution time for WeakMap#get.
        It is used for meta property for objects (see peekMeta function in Ember.js).

        This patch optimizes WeakMap#get.

        1. We use inlineGet to inline WeakMap#get operation in the native function.
        Since this native function itself is very small, we should inline HashMap#get
        entirely in this function.

        2. We add JSWeakMapType and JSWeakSetType. This allows us to perform `isJSWeakMap()`
        very fast. And this patch wires this to DFG and FTL to add WeakMapObjectUse and WeakSetObjectUse
        to drop unnecessary type checking. We add fixup rules for WeakMapGet DFG node by using WeakMapObjectUse,
        ObjectUse, and Int32Use.

        3. We add intrinsic for WeakMap#get, and handle it in DFG and FTL. We use MapHash to
        calculate hash value for the key's Object and use this hash value to look up value from
        JSWeakMap's HashMap. Currently, we just call the operationWeakMapGet function in DFG and FTL.
        It is worth considering that implementing this operation entirely in JIT, like GetMapBucket.
        But anyway, the current one already optimizes the performance, so we leave this for the subsequent
        patches.

        We currently do not implement any other intrinsics (like, WeakMap#has, WeakSet) because they are
        not used in Ember.js right now.

        This patch optimizes WeakMap#get by 50%.

                                 baseline                  patched

        weak-map-key         88.6456+-3.9564     ^     59.1502+-2.2406        ^ definitely 1.4987x faster

        * bytecode/DirectEvalCodeCache.h:
        (JSC::DirectEvalCodeCache::tryGet):
        * bytecode/SpeculatedType.cpp:
        (JSC::dumpSpeculation):
        (JSC::speculationFromClassInfo):
        (JSC::speculationFromJSType):
        (JSC::speculationFromString):
        * bytecode/SpeculatedType.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/DFGHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGHeapLocation.h:
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasHeapPrediction):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::SafeToExecuteEdge::operator()):
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::speculateWeakMapObject):
        (JSC::DFG::SpeculativeJIT::speculateWeakSetObject):
        (JSC::DFG::SpeculativeJIT::speculate):
        (JSC::DFG::SpeculativeJIT::compileWeakMapGet):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGUseKind.cpp:
        (WTF::printInternal):
        * dfg/DFGUseKind.h:
        (JSC::DFG::typeFilterFor):
        (JSC::DFG::isCell):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileWeakMapGet):
        (JSC::FTL::DFG::LowerDFGToB3::lowWeakMapObject):
        (JSC::FTL::DFG::LowerDFGToB3::lowWeakSetObject):
        (JSC::FTL::DFG::LowerDFGToB3::speculate):
        (JSC::FTL::DFG::LowerDFGToB3::speculateWeakMapObject):
        (JSC::FTL::DFG::LowerDFGToB3::speculateWeakSetObject):
        * jit/JITOperations.h:
        * runtime/Intrinsic.cpp:
        (JSC::intrinsicName):
        * runtime/Intrinsic.h:
        * runtime/JSType.h:
        * runtime/JSWeakMap.h:
        (JSC::isJSWeakMap):
        * runtime/JSWeakSet.h:
        (JSC::isJSWeakSet):
        * runtime/WeakMapBase.cpp:
        (JSC::WeakMapBase::get):
        * runtime/WeakMapBase.h:
        (JSC::WeakMapBase::HashTranslator::hash):
        (JSC::WeakMapBase::HashTranslator::equal):
        (JSC::WeakMapBase::inlineGet):
        * runtime/WeakMapPrototype.cpp:
        (JSC::WeakMapPrototype::finishCreation):
        (JSC::getWeakMap):
        (JSC::protoFuncWeakMapGet):
        * runtime/WeakSetPrototype.cpp:
        (JSC::getWeakSet):

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

        [JSC] Optimize Object.keys by using careful array allocation
        https://bugs.webkit.org/show_bug.cgi?id=176654

        Reviewed by Darin Adler.

        SixSpeed object-assign.es6 stresses Object.keys. Object.keys is one of frequently used
        function in JS apps. Luckily Object.keys has several good features.

        1. Once PropertyNameArray is allocated, we know the length of the result array since
        we do not need to filter out keys listed in PropertyNameArray. The execption is ProxyObject,
        but it rarely appears. ProxyObject case goes to the generic path.

        2. Object.keys does not need to access object after listing PropertyNameArray. It means
        that we do not need to worry about enumeration attribute change by touching object.

        This patch adds a fast path for Object.keys's array allocation. We allocate the JSArray
        with the size and ArrayContiguous indexing shape.

        This further improves SixSpeed object-assign.es5 by 13%.

                                            baseline                  patched
        Microbenchmarks:
           object-keys-map-values       73.4324+-2.5397     ^     62.5933+-2.6677        ^ definitely 1.1732x faster
           object-keys                  40.8828+-1.5851     ^     29.2066+-1.8944        ^ definitely 1.3998x faster

                                            baseline                  patched
        SixSpeed:
           object-assign.es5           384.8719+-10.7204    ^    340.2734+-12.0947       ^ definitely 1.1311x faster

        BTW, the further optimization of Object.keys can be considered: introducing own property keys
        cache which is similar to the current enumeration cache. But this patch is orthogonal to
        this optimization!

        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorValues):
        (JSC::ownPropertyKeys):
        * runtime/ObjectConstructor.h:

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

        Fix all ExceptionScope verification failures in JavaScriptCore.
        https://bugs.webkit.org/show_bug.cgi?id=176662
        <rdar://problem/34352085>

        Reviewed by Filip Pizlo.

        1. Introduced EXCEPTION_ASSERT macros so that we can enable exception scope
           verification for release builds too (though this requires manually setting
           ENABLE_EXCEPTION_SCOPE_VERIFICATION to 1 in Platform.h).

           This is useful because it allows us to run the tests more quickly to check
           if any regressions have occurred.  Debug builds run so much slower and not
           good for a quick turn around.  Debug builds are necessary though to get
           trace information without inlining by the C++ compiler.  This is necessary to
           diagnose where the missing exception check is.

        2. Repurposed the JSC_dumpSimulatedThrows=true options to capture and dump the last
           simulated throw when an exception scope verification fails.

           Previously, this option dumps the stack trace on all simulated throws.  That
           turned out to not be very useful, and slows down the debugging process.
           Instead, the new implementation captures the stack trace and only dumps it
           if we have a verification failure.

        3. Fixed missing exception checks and book-keeping needed to allow the JSC tests
           to pass with JSC_validateExceptionChecks=true.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::executeOSRExit):
        * dfg/DFGOperations.cpp:
        * interpreter/Interpreter.cpp:
        (JSC::eval):
        (JSC::loadVarargs):
        (JSC::Interpreter::unwind):
        (JSC::Interpreter::executeProgram):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        (JSC::Interpreter::prepareForRepeatCall):
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeModuleProgram):
        * jit/JITOperations.cpp:
        (JSC::getByVal):
        * jsc.cpp:
        (WTF::CustomGetter::customGetterAcessor):
        (GlobalObject::moduleLoaderImportModule):
        (GlobalObject::moduleLoaderResolve):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::getByVal):
        (JSC::LLInt::setUpCall):
        * parser/Parser.h:
        (JSC::Parser::popScopeInternal):
        * runtime/AbstractModuleRecord.cpp:
        (JSC::AbstractModuleRecord::hostResolveImportedModule):
        (JSC::AbstractModuleRecord::resolveImport):
        (JSC::AbstractModuleRecord::resolveExportImpl):
        (JSC::getExportedNames):
        (JSC::AbstractModuleRecord::getModuleNamespace):
        * runtime/ArrayPrototype.cpp:
        (JSC::getProperty):
        (JSC::unshift):
        (JSC::arrayProtoFuncToString):
        (JSC::arrayProtoFuncToLocaleString):
        (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::arrayProtoPrivateFuncAppendMemcpy):
        * runtime/CatchScope.h:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/DatePrototype.cpp:
        (JSC::dateProtoFuncSetTime):
        (JSC::setNewValueFromTimeArgs):
        * runtime/DirectArguments.h:
        (JSC::DirectArguments::length const):
        * runtime/ErrorPrototype.cpp:
        (JSC::errorProtoFuncToString):
        * runtime/ExceptionFuzz.cpp:
        (JSC::doExceptionFuzzing):
        * runtime/ExceptionScope.h:
        (JSC::ExceptionScope::needExceptionCheck):
        (JSC::ExceptionScope::assertNoException):
        * runtime/GenericArgumentsInlines.h:
        (JSC::GenericArguments<Type>::defineOwnProperty):
        * runtime/HashMapImpl.h:
        (JSC::HashMapImpl::rehash):
        * runtime/IntlDateTimeFormat.cpp:
        (JSC::IntlDateTimeFormat::formatToParts):
        * runtime/JSArray.cpp:
        (JSC::JSArray::defineOwnProperty):
        (JSC::JSArray::put):
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::putToPrimitive):
        (JSC::JSValue::putToPrimitiveByIndex):
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::toIndex const):
        (JSC::JSValue::get const):
        (JSC::JSValue::getPropertySlot const):
        (JSC::JSValue::equalSlowCaseInline):
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::constructGenericTypedArrayViewFromIterator):
        (JSC::constructGenericTypedArrayViewWithArguments):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::set):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::put):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::decode):
        (JSC::globalFuncEval):
        (JSC::globalFuncProtoGetter):
        (JSC::globalFuncProtoSetter):
        (JSC::globalFuncImportModule):
        * runtime/JSInternalPromise.cpp:
        (JSC::JSInternalPromise::then):
        * runtime/JSInternalPromiseDeferred.cpp:
        (JSC::JSInternalPromiseDeferred::create):
        * runtime/JSJob.cpp:
        (JSC::JSJobMicrotask::run):
        * runtime/JSModuleEnvironment.cpp:
        (JSC::JSModuleEnvironment::getOwnPropertySlot):
        (JSC::JSModuleEnvironment::put):
        (JSC::JSModuleEnvironment::deleteProperty):
        * runtime/JSModuleLoader.cpp:
        (JSC::JSModuleLoader::provide):
        (JSC::JSModuleLoader::loadAndEvaluateModule):
        (JSC::JSModuleLoader::loadModule):
        (JSC::JSModuleLoader::linkAndEvaluateModule):
        (JSC::JSModuleLoader::requestImportModule):
        * runtime/JSModuleRecord.cpp:
        (JSC::JSModuleRecord::link):
        (JSC::JSModuleRecord::instantiateDeclarations):
        * runtime/JSONObject.cpp:
        (JSC::Stringifier::stringify):
        (JSC::Stringifier::toJSON):
        (JSC::JSONProtoFuncParse):
        * runtime/JSObject.cpp:
        (JSC::JSObject::calculatedClassName):
        (JSC::ordinarySetSlow):
        (JSC::JSObject::putInlineSlow):
        (JSC::JSObject::ordinaryToPrimitive const):
        (JSC::JSObject::toPrimitive const):
        (JSC::JSObject::hasInstance):
        (JSC::JSObject::getPropertyNames):
        (JSC::JSObject::toNumber const):
        (JSC::JSObject::defineOwnIndexedProperty):
        (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes):
        (JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage):
        (JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage):
        (JSC::validateAndApplyPropertyDescriptor):
        (JSC::JSObject::defineOwnNonIndexProperty):
        (JSC::JSObject::getGenericPropertyNames):
        * runtime/JSObject.h:
        (JSC::JSObject::get const):
        * runtime/JSObjectInlines.h:
        (JSC::JSObject::getPropertySlot const):
        (JSC::JSObject::getPropertySlot):
        (JSC::JSObject::getNonIndexPropertySlot):
        (JSC::JSObject::putInlineForJSObject):
        * runtime/JSPromiseConstructor.cpp:
        (JSC::constructPromise):
        * runtime/JSPromiseDeferred.cpp:
        (JSC::JSPromiseDeferred::create):
        * runtime/JSScope.cpp:
        (JSC::abstractAccess):
        (JSC::JSScope::resolve):
        (JSC::JSScope::resolveScopeForHoistingFuncDeclInEval):
        (JSC::JSScope::abstractResolve):
        * runtime/LiteralParser.cpp:
        (JSC::LiteralParser<CharType>::tryJSONPParse):
        (JSC::LiteralParser<CharType>::parse):
        * runtime/Lookup.h:
        (JSC::putEntry):
        * runtime/MapConstructor.cpp:
        (JSC::constructMap):
        * runtime/NumberPrototype.cpp:
        (JSC::numberProtoFuncToString):
        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorSetPrototypeOf):
        (JSC::objectConstructorGetOwnPropertyDescriptor):
        (JSC::objectConstructorGetOwnPropertyDescriptors):
        (JSC::objectConstructorAssign):
        (JSC::objectConstructorValues):
        (JSC::toPropertyDescriptor):
        (JSC::objectConstructorDefineProperty):
        (JSC::defineProperties):
        (JSC::objectConstructorDefineProperties):
        (JSC::ownPropertyKeys):
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncHasOwnProperty):
        (JSC::objectProtoFuncIsPrototypeOf):
        (JSC::objectProtoFuncLookupGetter):
        (JSC::objectProtoFuncLookupSetter):
        (JSC::objectProtoFuncToLocaleString):
        (JSC::objectProtoFuncToString):
        * runtime/Options.h:
        * runtime/ParseInt.h:
        (JSC::toStringView):
        * runtime/ProxyObject.cpp:
        (JSC::performProxyGet):
        (JSC::ProxyObject::performPut):
        * runtime/ReflectObject.cpp:
        (JSC::reflectObjectDefineProperty):
        * runtime/RegExpConstructor.cpp:
        (JSC::toFlags):
        (JSC::regExpCreate):
        (JSC::constructRegExp):
        * runtime/RegExpObject.cpp:
        (JSC::collectMatches):
        * runtime/RegExpObjectInlines.h:
        (JSC::RegExpObject::execInline):
        (JSC::RegExpObject::matchInline):
        * runtime/RegExpPrototype.cpp:
        (JSC::regExpProtoFuncTestFast):
        (JSC::regExpProtoFuncExec):
        (JSC::regExpProtoFuncMatchFast):
        (JSC::regExpProtoFuncToString):
        (JSC::regExpProtoFuncSplitFast):
        * runtime/ScriptExecutable.cpp:
        (JSC::ScriptExecutable::newCodeBlockFor):
        (JSC::ScriptExecutable::prepareForExecutionImpl):
        * runtime/SetConstructor.cpp:
        (JSC::constructSet):
        * runtime/ThrowScope.cpp:
        (JSC::ThrowScope::simulateThrow):
        * runtime/VM.cpp:
        (JSC::VM::verifyExceptionCheckNeedIsSatisfied):
        * runtime/VM.h:
        * runtime/WeakMapPrototype.cpp:
        (JSC::protoFuncWeakMapSet):
        * runtime/WeakSetPrototype.cpp:
        (JSC::protoFuncWeakSetAdd):
        * wasm/js/WebAssemblyModuleConstructor.cpp:
        (JSC::WebAssemblyModuleConstructor::createModule):
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::link):
        * wasm/js/WebAssemblyPrototype.cpp:
        (JSC::reject):
        (JSC::webAssemblyCompileFunc):
        (JSC::resolve):
        (JSC::webAssemblyInstantiateFunc):

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

        Error should compute .stack and friends lazily
        https://bugs.webkit.org/show_bug.cgi?id=176645

        Reviewed by Saam Barati.
        
        Building the string portion of the stack trace after we walk the stack accounts for most of
        the cost of computing the .stack property. So, this patch makes ErrorInstance hold onto the
        Vector<StackFrame> so that it can build the string only once it's really needed.
        
        This is an enormous speed-up for programs that allocate and throw exceptions.
        
        It's a 5.6x speed-up for "new Error()" with a stack that is 4 functions deep.
        
        It's a 2.2x speed-up for throwing and catching an Error.
        
        It's a 1.17x speed-up for the WSL test suite (which throws a lot).
        
        It's a significant speed-up on many of our existing try-catch microbenchmarks. For example,
        delta-blue-try-catch is 1.16x faster.

        * interpreter/Interpreter.cpp:
        (JSC::GetStackTraceFunctor::GetStackTraceFunctor):
        (JSC::GetStackTraceFunctor::operator() const):
        (JSC::Interpreter::getStackTrace):
        * interpreter/Interpreter.h:
        * runtime/Error.cpp:
        (JSC::getStackTrace):
        (JSC::getBytecodeOffset):
        (JSC::addErrorInfo):
        (JSC::addErrorInfoAndGetBytecodeOffset): Deleted.
        * runtime/Error.h:
        * runtime/ErrorInstance.cpp:
        (JSC::ErrorInstance::ErrorInstance):
        (JSC::ErrorInstance::finishCreation):
        (JSC::ErrorInstance::materializeErrorInfoIfNeeded):
        (JSC::ErrorInstance::visitChildren):
        (JSC::ErrorInstance::getOwnPropertySlot):
        (JSC::ErrorInstance::getOwnNonIndexPropertyNames):
        (JSC::ErrorInstance::defineOwnProperty):
        (JSC::ErrorInstance::put):
        (JSC::ErrorInstance::deleteProperty):
        * runtime/ErrorInstance.h:
        * runtime/Exception.cpp:
        (JSC::Exception::visitChildren):
        (JSC::Exception::finishCreation):
        * runtime/Exception.h:
        * runtime/StackFrame.cpp:
        (JSC::StackFrame::visitChildren):
        * runtime/StackFrame.h:
        (JSC::StackFrame::StackFrame):

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

        [Re-landing] Use JIT probes for DFG OSR exit.
        https://bugs.webkit.org/show_bug.cgi?id=175144
        <rdar://problem/33437050>

        Not reviewed.  Original patch reviewed by Saam Barati.

        Relanding r221774.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/MacroAssembler.cpp:
        (JSC::stdFunctionCallback):
        * assembler/MacroAssemblerPrinter.cpp:
        (JSC::Printer::printCallback):
        * assembler/ProbeContext.h:
        (JSC::Probe::CPUState::gpr const):
        (JSC::Probe::CPUState::spr const):
        (JSC::Probe::Context::Context):
        (JSC::Probe::Context::arg):
        (JSC::Probe::Context::gpr):
        (JSC::Probe::Context::spr):
        (JSC::Probe::Context::fpr):
        (JSC::Probe::Context::gprName):
        (JSC::Probe::Context::sprName):
        (JSC::Probe::Context::fprName):
        (JSC::Probe::Context::gpr const):
        (JSC::Probe::Context::spr const):
        (JSC::Probe::Context::fpr const):
        (JSC::Probe::Context::pc):
        (JSC::Probe::Context::fp):
        (JSC::Probe::Context::sp):
        (JSC::Probe:: const): Deleted.
        * assembler/ProbeFrame.h: Copied from Source/JavaScriptCore/assembler/ProbeFrame.h.
        * assembler/ProbeStack.cpp:
        (JSC::Probe::Page::Page):
        * assembler/ProbeStack.h:
        (JSC::Probe::Page::get):
        (JSC::Probe::Page::set):
        (JSC::Probe::Page::physicalAddressFor):
        (JSC::Probe::Stack::lowWatermark):
        (JSC::Probe::Stack::get):
        (JSC::Probe::Stack::set):
        * bytecode/ArithProfile.cpp:
        * bytecode/ArithProfile.h:
        * bytecode/ArrayProfile.h:
        (JSC::ArrayProfile::observeArrayMode):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::updateOSRExitCounterAndCheckIfNeedToReoptimize):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::addressOfOSRExitCounter): Deleted.
        * bytecode/ExecutionCounter.h:
        (JSC::ExecutionCounter::hasCrossedThreshold const):
        (JSC::ExecutionCounter::setNewThresholdForOSRExit):
        * bytecode/MethodOfGettingAValueProfile.cpp:
        (JSC::MethodOfGettingAValueProfile::reportValue):
        * bytecode/MethodOfGettingAValueProfile.h:
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compileImpl):
        * dfg/DFGJITCode.cpp:
        (JSC::DFG::JITCode::findPC): Deleted.
        * dfg/DFGJITCode.h:
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::linkOSRExits):
        (JSC::DFG::JITCompiler::link):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::jsValueFor):
        (JSC::DFG::restoreCalleeSavesFor):
        (JSC::DFG::saveCalleeSavesFor):
        (JSC::DFG::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
        (JSC::DFG::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
        (JSC::DFG::saveOrCopyCalleeSavesFor):
        (JSC::DFG::createDirectArgumentsDuringExit):
        (JSC::DFG::createClonedArgumentsDuringExit):
        (JSC::DFG::OSRExit::OSRExit):
        (JSC::DFG::emitRestoreArguments):
        (JSC::DFG::OSRExit::executeOSRExit):
        (JSC::DFG::reifyInlinedCallFrames):
        (JSC::DFG::adjustAndJumpToTarget):
        (JSC::DFG::printOSRExit):
        (JSC::DFG::OSRExit::setPatchableCodeOffset): Deleted.
        (JSC::DFG::OSRExit::getPatchableCodeOffsetAsJump const): Deleted.
        (JSC::DFG::OSRExit::codeLocationForRepatch const): Deleted.
        (JSC::DFG::OSRExit::correctJump): Deleted.
        (JSC::DFG::OSRExit::emitRestoreArguments): Deleted.
        (JSC::DFG::OSRExit::compileOSRExit): Deleted.
        (JSC::DFG::OSRExit::compileExit): Deleted.
        (JSC::DFG::OSRExit::debugOperationPrintSpeculationFailure): Deleted.
        * dfg/DFGOSRExit.h:
        (JSC::DFG::OSRExitState::OSRExitState):
        (JSC::DFG::OSRExit::considerAddingAsFrequentExitSite):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        * dfg/DFGOSRExitCompilerCommon.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGThunks.cpp:
        (JSC::DFG::osrExitThunkGenerator):
        (JSC::DFG::osrExitGenerationThunkGenerator): Deleted.
        * dfg/DFGThunks.h:
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::debugCall): Deleted.
        * jit/AssemblyHelpers.h:
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * profiler/ProfilerOSRExit.h:
        (JSC::Profiler::OSRExit::incCount):
        * runtime/JSCJSValue.h:
        * runtime/JSCJSValueInlines.h:
        * runtime/VM.h:

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

        Unreviewed, rolling out r221774.

        This change introduced three debug JSC test timeouts.

        Reverted changeset:

        "Use JIT probes for DFG OSR exit."
        https://bugs.webkit.org/show_bug.cgi?id=175144
        http://trac.webkit.org/changeset/221774

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

        Avoid duplicate computations of ExecState::vm().
        https://bugs.webkit.org/show_bug.cgi?id=176647

        Reviewed by Saam Barati.

        Because while computing ExecState::vm() is cheap, it is not free.

        This patch also:
        1. gets rids of some convenience methods in CallFrame that implicitly does a
           ExecState::vm() computation.  This minimizes the chance of us accidentally
           computing ExecState::vm() more than necessary.
        2. passes vm (when available) to methodTable().
        3. passes vm (when available) to JSLockHolder.

        * API/JSBase.cpp:
        (JSCheckScriptSyntax):
        (JSGarbageCollect):
        (JSReportExtraMemoryCost):
        (JSSynchronousGarbageCollectForDebugging):
        (JSSynchronousEdenCollectForDebugging):
        * API/JSCallbackConstructor.h:
        (JSC::JSCallbackConstructor::create):
        * API/JSCallbackObject.h:
        (JSC::JSCallbackObject::create):
        * API/JSContext.mm:
        (-[JSContext setException:]):
        * API/JSContextRef.cpp:
        (JSContextGetGlobalObject):
        (JSContextCreateBacktrace):
        * API/JSManagedValue.mm:
        (-[JSManagedValue value]):
        * API/JSObjectRef.cpp:
        (JSObjectMake):
        (JSObjectMakeFunctionWithCallback):
        (JSObjectMakeConstructor):
        (JSObjectMakeFunction):
        (JSObjectSetPrototype):
        (JSObjectHasProperty):
        (JSObjectGetProperty):
        (JSObjectSetProperty):
        (JSObjectSetPropertyAtIndex):
        (JSObjectDeleteProperty):
        (JSObjectGetPrivateProperty):
        (JSObjectSetPrivateProperty):
        (JSObjectDeletePrivateProperty):
        (JSObjectIsFunction):
        (JSObjectCallAsFunction):
        (JSObjectCallAsConstructor):
        (JSObjectCopyPropertyNames):
        (JSPropertyNameAccumulatorAddName):
        * API/JSScriptRef.cpp:
        * API/JSTypedArray.cpp:
        (JSValueGetTypedArrayType):
        (JSObjectMakeTypedArrayWithArrayBuffer):
        (JSObjectMakeTypedArrayWithArrayBufferAndOffset):
        (JSObjectGetTypedArrayBytesPtr):
        (JSObjectGetTypedArrayBuffer):
        (JSObjectMakeArrayBufferWithBytesNoCopy):
        (JSObjectGetArrayBufferBytesPtr):
        * API/JSWeakObjectMapRefPrivate.cpp:
        * API/JSWrapperMap.mm:
        (constructorHasInstance):
        (makeWrapper):
        * API/ObjCCallbackFunction.mm:
        (objCCallbackFunctionForInvocation):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::jettison):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::addConstant):
        (JSC::CodeBlock::replaceConstant):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFromLLInt):
        (JSC::PutByIdStatus::computeFor):
        * dfg/DFGDesiredWatchpoints.cpp:
        (JSC::DFG::ArrayBufferViewWatchpointAdaptor::add):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::globalThisObjectFor):
        * dfg/DFGOperations.cpp:
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileFTLOSRExit):
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationPopulateObjectInOSR):
        (JSC::FTL::operationMaterializeObjectInOSR):
        * heap/GCAssertions.h:
        * inspector/InjectedScriptHost.cpp:
        (Inspector::InjectedScriptHost::wrapper):
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::subtype):
        (Inspector::constructInternalProperty):
        (Inspector::JSInjectedScriptHost::getInternalProperties):
        (Inspector::JSInjectedScriptHost::weakMapEntries):
        (Inspector::JSInjectedScriptHost::weakSetEntries):
        (Inspector::JSInjectedScriptHost::iteratorEntries):
        * inspector/JSJavaScriptCallFrame.cpp:
        (Inspector::valueForScopeLocation):
        (Inspector::JSJavaScriptCallFrame::scopeDescriptions):
        (Inspector::toJS):
        * inspector/ScriptCallStackFactory.cpp:
        (Inspector::extractSourceInformationFromException):
        (Inspector::createScriptArguments):
        * interpreter/CachedCall.h:
        (JSC::CachedCall::CachedCall):
        * interpreter/CallFrame.h:
        (JSC::ExecState::atomicStringTable const): Deleted.
        (JSC::ExecState::propertyNames const): Deleted.
        (JSC::ExecState::emptyList const): Deleted.
        (JSC::ExecState::interpreter): Deleted.
        (JSC::ExecState::heap): Deleted.
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::executeProgram):
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeModuleProgram):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JITOperations.cpp:
        * jit/JITWorklist.cpp:
        (JSC::JITWorklist::compileNow):
        * jsc.cpp:
        (WTF::RuntimeArray::create):
        (WTF::RuntimeArray::getOwnPropertySlot):
        (WTF::DOMJITGetter::DOMJITAttribute::slowCall):
        (WTF::DOMJITFunctionObject::unsafeFunction):
        (WTF::DOMJITCheckSubClassObject::unsafeFunction):
        (GlobalObject::moduleLoaderFetch):
        (functionDumpCallFrame):
        (functionCreateRoot):
        (functionGetElement):
        (functionSetElementRoot):
        (functionCreateSimpleObject):
        (functionSetHiddenValue):
        (functionCreateProxy):
        (functionCreateImpureGetter):
        (functionCreateCustomGetterObject):
        (functionCreateDOMJITNodeObject):
        (functionCreateDOMJITGetterObject):
        (functionCreateDOMJITGetterComplexObject):
        (functionCreateDOMJITFunctionObject):
        (functionCreateDOMJITCheckSubClassObject):
        (functionGCAndSweep):
        (functionFullGC):
        (functionEdenGC):
        (functionHeapSize):
        (functionShadowChickenFunctionsOnStack):
        (functionSetGlobalConstRedeclarationShouldNotThrow):
        (functionJSCOptions):
        (functionFailNextNewCodeBlock):
        (functionMakeMasquerader):
        (functionDumpTypesForAllVariables):
        (functionFindTypeForExpression):
        (functionReturnTypeFor):
        (functionDumpBasicBlockExecutionRanges):
        (functionBasicBlockExecutionCount):
        (functionDrainMicrotasks):
        (functionGenerateHeapSnapshot):
        (functionEnsureArrayStorage):
        (functionStartSamplingProfiler):
        (runInteractive):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * parser/ModuleAnalyzer.cpp:
        (JSC::ModuleAnalyzer::ModuleAnalyzer):
        * profiler/ProfilerBytecode.cpp:
        (JSC::Profiler::Bytecode::toJS const):
        * profiler/ProfilerBytecodeSequence.cpp:
        (JSC::Profiler::BytecodeSequence::addSequenceProperties const):
        * profiler/ProfilerBytecodes.cpp:
        (JSC::Profiler::Bytecodes::toJS const):
        * profiler/ProfilerCompilation.cpp:
        (JSC::Profiler::Compilation::toJS const):
        * profiler/ProfilerCompiledBytecode.cpp:
        (JSC::Profiler::CompiledBytecode::toJS const):
        * profiler/ProfilerDatabase.cpp:
        (JSC::Profiler::Database::toJS const):
        * profiler/ProfilerEvent.cpp:
        (JSC::Profiler::Event::toJS const):
        * profiler/ProfilerOSRExit.cpp:
        (JSC::Profiler::OSRExit::toJS const):
        * profiler/ProfilerOrigin.cpp:
        (JSC::Profiler::Origin::toJS const):
        * profiler/ProfilerProfiledBytecodes.cpp:
        (JSC::Profiler::ProfiledBytecodes::toJS const):
        * runtime/AbstractModuleRecord.cpp:
        (JSC::identifierToJSValue):
        (JSC::AbstractModuleRecord::resolveExportImpl):
        (JSC::getExportedNames):
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncToString):
        (JSC::arrayProtoFuncToLocaleString):
        * runtime/BooleanConstructor.cpp:
        (JSC::constructBooleanFromImmediateBoolean):
        * runtime/CallData.cpp:
        (JSC::call):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
        (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
        * runtime/Completion.cpp:
        (JSC::checkSyntax):
        (JSC::evaluate):
        (JSC::loadAndEvaluateModule):
        (JSC::loadModule):
        (JSC::linkAndEvaluateModule):
        (JSC::importModule):
        * runtime/ConstructData.cpp:
        (JSC::construct):
        * runtime/DatePrototype.cpp:
        (JSC::dateProtoFuncToJSON):
        * runtime/DirectArguments.h:
        (JSC::DirectArguments::length const):
        * runtime/DirectEvalExecutable.cpp:
        (JSC::DirectEvalExecutable::create):
        * runtime/ErrorPrototype.cpp:
        (JSC::errorProtoFuncToString):
        * runtime/ExceptionHelpers.cpp:
        (JSC::createUndefinedVariableError):
        (JSC::errorDescriptionForValue):
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunction):
        * runtime/GenericArgumentsInlines.h:
        (JSC::GenericArguments<Type>::getOwnPropertyNames):
        * runtime/IdentifierInlines.h:
        (JSC::Identifier::add):
        * runtime/IndirectEvalExecutable.cpp:
        (JSC::IndirectEvalExecutable::create):
        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::finishCreation):
        (JSC::InternalFunction::createSubclassStructureSlow):
        * runtime/JSArray.cpp:
        (JSC::JSArray::getOwnPropertySlot):
        (JSC::JSArray::put):
        (JSC::JSArray::deleteProperty):
        (JSC::JSArray::getOwnNonIndexPropertyNames):
        (JSC::JSArray::isIteratorProtocolFastAndNonObservable):
        * runtime/JSArray.h:
        (JSC::JSArray::shiftCountForShift):
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::dumpForBacktrace const):
        * runtime/JSDataView.cpp:
        (JSC::JSDataView::getOwnPropertySlot):
        (JSC::JSDataView::deleteProperty):
        (JSC::JSDataView::getOwnNonIndexPropertyNames):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::getOwnPropertySlot):
        (JSC::JSFunction::deleteProperty):
        (JSC::JSFunction::reifyName):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncEval):
        * runtime/JSInternalPromise.cpp:
        (JSC::JSInternalPromise::then):
        * runtime/JSLexicalEnvironment.cpp:
        (JSC::JSLexicalEnvironment::deleteProperty):
        * runtime/JSMap.cpp:
        (JSC::JSMap::isIteratorProtocolFastAndNonObservable):
        * runtime/JSMapIterator.h:
        (JSC::JSMapIterator::advanceIter):
        * runtime/JSModuleEnvironment.cpp:
        (JSC::JSModuleEnvironment::getOwnNonIndexPropertyNames):
        * runtime/JSModuleLoader.cpp:
        (JSC::printableModuleKey):
        (JSC::JSModuleLoader::provide):
        (JSC::JSModuleLoader::loadAndEvaluateModule):
        (JSC::JSModuleLoader::loadModule):
        (JSC::JSModuleLoader::linkAndEvaluateModule):
        (JSC::JSModuleLoader::requestImportModule):
        * runtime/JSModuleNamespaceObject.h:
        * runtime/JSModuleRecord.cpp:
        (JSC::JSModuleRecord::evaluate):
        * runtime/JSONObject.cpp:
        (JSC::Stringifier::Stringifier):
        (JSC::Stringifier::appendStringifiedValue):
        (JSC::Stringifier::Holder::appendNextProperty):
        * runtime/JSObject.cpp:
        (JSC::JSObject::calculatedClassName):
        (JSC::JSObject::putByIndex):
        (JSC::JSObject::ordinaryToPrimitive const):
        (JSC::JSObject::toPrimitive const):
        (JSC::JSObject::hasInstance):
        (JSC::JSObject::getOwnPropertyNames):
        (JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength):
        (JSC::getCustomGetterSetterFunctionForGetterSetter):
        (JSC::JSObject::getOwnPropertyDescriptor):
        (JSC::JSObject::getMethod):
        * runtime/JSObject.h:
        (JSC::JSObject::createRawObject):
        (JSC::JSFinalObject::create):
        * runtime/JSObjectInlines.h:
        (JSC::JSObject::canPerformFastPutInline):
        (JSC::JSObject::putInlineForJSObject):
        (JSC::JSObject::hasOwnProperty const):
        * runtime/JSScope.cpp:
        (JSC::isUnscopable):
        (JSC::JSScope::resolveScopeForHoistingFuncDeclInEval):
        * runtime/JSSet.cpp:
        (JSC::JSSet::isIteratorProtocolFastAndNonObservable):
        * runtime/JSSetIterator.h:
        (JSC::JSSetIterator::advanceIter):
        * runtime/JSString.cpp:
        (JSC::JSString::getStringPropertyDescriptor):
        * runtime/JSString.h:
        (JSC::JSString::getStringPropertySlot):
        * runtime/MapConstructor.cpp:
        (JSC::constructMap):
        * runtime/ModuleProgramExecutable.cpp:
        (JSC::ModuleProgramExecutable::create):
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncToLocaleString):
        * runtime/ProgramExecutable.h:
        * runtime/RegExpObject.cpp:
        (JSC::RegExpObject::getOwnPropertySlot):
        (JSC::RegExpObject::deleteProperty):
        (JSC::RegExpObject::getOwnNonIndexPropertyNames):
        (JSC::RegExpObject::getPropertyNames):
        (JSC::RegExpObject::getGenericPropertyNames):
        (JSC::RegExpObject::put):
        * runtime/ScopedArguments.h:
        (JSC::ScopedArguments::length const):
        * runtime/StrictEvalActivation.h:
        (JSC::StrictEvalActivation::create):
        * runtime/StringObject.cpp:
        (JSC::isStringOwnProperty):
        (JSC::StringObject::deleteProperty):
        (JSC::StringObject::getOwnNonIndexPropertyNames):
        * tools/JSDollarVMPrototype.cpp:
        (JSC::JSDollarVMPrototype::gc):
        (JSC::JSDollarVMPrototype::edenGC):
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::evaluate):

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

        [DFG] NewArrayWithSize(size)'s size does not care negative zero
        https://bugs.webkit.org/show_bug.cgi?id=176300

        Reviewed by Saam Barati.

        NewArrayWithSize(size)'s size does not care negative zero as
        is the same to NewTypedArray. We propagate this information
        in DFGBackwardsPropagationPhase. This removes negative zero
        check in kraken fft's deinterleave function.

        * dfg/DFGBackwardsPropagationPhase.cpp:
        (JSC::DFG::BackwardsPropagationPhase::propagate):

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

        [DFG] PutByVal with Array::Generic is too generic
        https://bugs.webkit.org/show_bug.cgi?id=176345

        Reviewed by Filip Pizlo.

        Our DFG/FTL's PutByVal with Array::Generic is too generic implementation.
        We could have the case like,

            dst[key] = src[key];

        with string or symbol keys. But they are handled in slow path.
        This patch adds PutByVal(CellUse, StringUse/SymbolUse, UntypedUse). They go
        to optimized path that does not have generic checks like (isInt32() / isDouble() etc.).

        This improves SixSpeed object-assign.es5 by 9.1%.

        object-assign.es5             424.3159+-11.0471    ^    388.8771+-10.9239       ^ definitely 1.0911x faster

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGOperations.cpp:
        (JSC::DFG::putByVal):
        (JSC::DFG::putByValInternal):
        (JSC::DFG::putByValCellInternal):
        (JSC::DFG::putByValCellStringInternal):
        (JSC::DFG::operationPutByValInternal): Deleted.
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compilePutByValForCellWithString):
        (JSC::DFG::SpeculativeJIT::compilePutByValForCellWithSymbol):
        * 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::compilePutByVal):
        * jit/JITOperations.h:

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

        [DFG][FTL] GetByVal(ObjectUse with Array::Generic, StringUse/SymbolUse) should be supported
        https://bugs.webkit.org/show_bug.cgi?id=176590

        Reviewed by Saam Barati.

        We add fixup edges for GetByVal(Array::Generic) to call faster operation instead of generic operationGetByVal.

                                         baseline                  patched

        object-iterate                5.8531+-0.3029            5.7903+-0.2795          might be 1.0108x faster
        object-iterate-symbols        7.4099+-0.3993     ^      5.8254+-0.2276        ^ definitely 1.2720x faster

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGOperations.cpp:
        (JSC::DFG::getByValObject):
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValForObjectWithString):
        (JSC::DFG::SpeculativeJIT::compileGetByValForObjectWithSymbol):
        * 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::compileGetByVal):

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

        Use JIT probes for DFG OSR exit.
        https://bugs.webkit.org/show_bug.cgi?id=175144
        <rdar://problem/33437050>

        Reviewed by Saam Barati.

        This patch does the following:
        1. Replaces osrExitGenerationThunkGenerator() with osrExitThunkGenerator().
           While osrExitGenerationThunkGenerator() generates a thunk that compiles a
           unique OSR offramp for each DFG OSR exit site, osrExitThunkGenerator()
           generates a thunk that just executes the OSR exit.

           The osrExitThunkGenerator() generated thunk works by using a single JIT probe
           to call OSRExit::executeOSRExit().  The JIT probe takes care of preserving
           CPU registers, and providing the Probe::Stack mechanism for modifying the
           stack frame.

           OSRExit::executeOSRExit() replaces OSRExit::compileOSRExit() and
           OSRExit::compileExit().  It is basically a re-write of those functions to
           execute the OSR exit work instead of compiling code to execute the work.

           As a result, we get the following savings:
           a. no more OSR exit ramp compilation time.
           b. no use of JIT executable memory for storing each unique OSR exit ramp.

           On the negative side, we incur these costs:

           c. the OSRExit::executeOSRExit() ramp may be a little slower than the compiled
              version of the ramp.  However, OSR exits are rare.  Hence, this small
              difference should not matter much.  It is also offset by the savings from
              (a).

           d. the Probe::Stack allocates 1K pages for memory for buffering stack
              modifcations.  The number of these pages depends on the span of stack memory
              that the OSR exit ramp reads from and writes to.  Since the OSR exit ramp
              tends to only modify values in the current DFG frame and the current
              VMEntryRecord, the number of pages tends to only be 1 or 2.

              Using the jsc tests as a workload, the vast majority of tests that do OSR
              exit, uses 3 or less 1K pages (with the overwhelming number using just 1 page).
              A few tests that are pathological uses up to 14 pages, and one particularly
              bad test (function-apply-many-args.js) uses 513 pages.

           Similar to the old code, the OSR exit ramp still has 2 parts: 1 part that is
           only executed once to compute some values for the exit site that is used by
           all exit operations from that site, and a 2nd part to execute the exit.  The
           1st part is protected by a checking if exit.exitState has already been
           initialized.  The computed values are cached in exit.exitState.

           Because the OSR exit thunk no longer compiles an OSR exit off-ramp, we no
           longer need the facility to patch the site that jumps to the OSR exit ramp.
           The DFG::JITCompiler has been modified to remove this patching code.

        2. Fixed the bottom most Probe::Context and Probe::Stack get/set methods to use
           std::memcpy to avoid strict aliasing issues.

           Also optimized the implementation of Probe::Stack::physicalAddressFor().

        3. Miscellaneous convenience methods added to make the Probe::Context easier of
           use.

        4. Added a Probe::Frame class that makes it easier to get/set operands and
           arguments in a given frame using the deferred write properties of the
           Probe::Stack.  Probe::Frame makes it easier to do some of the recovery work in
           the OSR exit ramp.

        5. Cloned or converted some functions needed by the OSR exit ramp.  The original
           JIT versions of these functions are still left in place because they are still
           needed for FTL OSR exit.  A FIXME comment has been added to remove them later.
           These functions include:

           DFGOSRExitCompilerCommon.cpp's handleExitCounts() ==>
               CodeBlock::updateOSRExitCounterAndCheckIfNeedToReoptimize()
           DFGOSRExitCompilerCommon.cpp's reifyInlinedCallFrames() ==>
               DFGOSRExit.cpp's reifyInlinedCallFrames()
           DFGOSRExitCompilerCommon.cpp's adjustAndJumpToTarget() ==>
               DFGOSRExit.cpp's adjustAndJumpToTarget()

           MethodOfGettingAValueProfile::emitReportValue() ==>
               MethodOfGettingAValueProfile::reportValue()

           DFGOperations.cpp's operationCreateDirectArgumentsDuringExit() ==>
               DFGOSRExit.cpp's createDirectArgumentsDuringExit()
           DFGOperations.cpp's operationCreateClonedArgumentsDuringExit() ==>
               DFGOSRExit.cpp's createClonedArgumentsDuringExit()

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/MacroAssembler.cpp:
        (JSC::stdFunctionCallback):
        * assembler/MacroAssemblerPrinter.cpp:
        (JSC::Printer::printCallback):
        * assembler/ProbeContext.h:
        (JSC::Probe::CPUState::gpr const):
        (JSC::Probe::CPUState::spr const):
        (JSC::Probe::Context::Context):
        (JSC::Probe::Context::arg):
        (JSC::Probe::Context::gpr):
        (JSC::Probe::Context::spr):
        (JSC::Probe::Context::fpr):
        (JSC::Probe::Context::gprName):
        (JSC::Probe::Context::sprName):
        (JSC::Probe::Context::fprName):
        (JSC::Probe::Context::gpr const):
        (JSC::Probe::Context::spr const):
        (JSC::Probe::Context::fpr const):
        (JSC::Probe::Context::pc):
        (JSC::Probe::Context::fp):
        (JSC::Probe::Context::sp):
        (JSC::Probe:: const): Deleted.
        * assembler/ProbeFrame.h: Added.
        (JSC::Probe::Frame::Frame):
        (JSC::Probe::Frame::getArgument):
        (JSC::Probe::Frame::getOperand):
        (JSC::Probe::Frame::get):
        (JSC::Probe::Frame::setArgument):
        (JSC::Probe::Frame::setOperand):
        (JSC::Probe::Frame::set):
        * assembler/ProbeStack.cpp:
        (JSC::Probe::Page::Page):
        * assembler/ProbeStack.h:
        (JSC::Probe::Page::get):
        (JSC::Probe::Page::set):
        (JSC::Probe::Page::physicalAddressFor):
        (JSC::Probe::Stack::lowWatermark):
        (JSC::Probe::Stack::get):
        (JSC::Probe::Stack::set):
        * bytecode/ArithProfile.cpp:
        * bytecode/ArithProfile.h:
        * bytecode/ArrayProfile.h:
        (JSC::ArrayProfile::observeArrayMode):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::updateOSRExitCounterAndCheckIfNeedToReoptimize):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::addressOfOSRExitCounter): Deleted.
        * bytecode/ExecutionCounter.h:
        (JSC::ExecutionCounter::hasCrossedThreshold const):
        (JSC::ExecutionCounter::setNewThresholdForOSRExit):
        * bytecode/MethodOfGettingAValueProfile.cpp:
        (JSC::MethodOfGettingAValueProfile::reportValue):
        * bytecode/MethodOfGettingAValueProfile.h:
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compileImpl):
        * dfg/DFGJITCode.cpp:
        (JSC::DFG::JITCode::findPC): Deleted.
        * dfg/DFGJITCode.h:
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::linkOSRExits):
        (JSC::DFG::JITCompiler::link):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::jsValueFor):
        (JSC::DFG::restoreCalleeSavesFor):
        (JSC::DFG::saveCalleeSavesFor):
        (JSC::DFG::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
        (JSC::DFG::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
        (JSC::DFG::saveOrCopyCalleeSavesFor):
        (JSC::DFG::createDirectArgumentsDuringExit):
        (JSC::DFG::createClonedArgumentsDuringExit):
        (JSC::DFG::OSRExit::OSRExit):
        (JSC::DFG::emitRestoreArguments):
        (JSC::DFG::OSRExit::executeOSRExit):
        (JSC::DFG::reifyInlinedCallFrames):
        (JSC::DFG::adjustAndJumpToTarget):
        (JSC::DFG::printOSRExit):
        (JSC::DFG::OSRExit::setPatchableCodeOffset): Deleted.
        (JSC::DFG::OSRExit::getPatchableCodeOffsetAsJump const): Deleted.
        (JSC::DFG::OSRExit::codeLocationForRepatch const): Deleted.
        (JSC::DFG::OSRExit::correctJump): Deleted.
        (JSC::DFG::OSRExit::emitRestoreArguments): Deleted.
        (JSC::DFG::OSRExit::compileOSRExit): Deleted.
        (JSC::DFG::OSRExit::compileExit): Deleted.
        (JSC::DFG::OSRExit::debugOperationPrintSpeculationFailure): Deleted.
        * dfg/DFGOSRExit.h:
        (JSC::DFG::OSRExitState::OSRExitState):
        (JSC::DFG::OSRExit::considerAddingAsFrequentExitSite):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        * dfg/DFGOSRExitCompilerCommon.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGThunks.cpp:
        (JSC::DFG::osrExitThunkGenerator):
        (JSC::DFG::osrExitGenerationThunkGenerator): Deleted.
        * dfg/DFGThunks.h:
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::debugCall): Deleted.
        * jit/AssemblyHelpers.h:
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * profiler/ProfilerOSRExit.h:
        (JSC::Profiler::OSRExit::incCount):
        * runtime/JSCJSValue.h:
        * runtime/JSCJSValueInlines.h:
        * runtime/VM.h:

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

        Add support for RegExp named capture groups
        https://bugs.webkit.org/show_bug.cgi?id=176435

        Reviewed by Filip Pizlo.

        Added parsing for both naming a captured parenthesis as well and using a named group in
        a back reference.  Also added support for using named groups with String.prototype.replace().

        This patch does not throw Syntax Errors as described in the current spec text for the two
        cases of malformed back references in String.prototype.replace() as I believe that it
        is inconsistent with the current semantics for handling of other malformed replacement
        tokens.  I filed an issue for the requested change to the proposed spec and also filed
        a FIXME bug https://bugs.webkit.org/show_bug.cgi?id=176434.

        This patch does not implement strength reduction in the optimizing JITs for named capture
        groups.  Filed https://bugs.webkit.org/show_bug.cgi?id=176464.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        * runtime/CommonIdentifiers.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::haveABadTime):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::regExpMatchesArrayWithGroupsStructure const):
        * runtime/RegExp.cpp:
        (JSC::RegExp::finishCreation):
        * runtime/RegExp.h:
        * runtime/RegExpMatchesArray.cpp:
        (JSC::createStructureImpl):
        (JSC::createRegExpMatchesArrayWithGroupsStructure):
        (JSC::createRegExpMatchesArrayWithGroupsSlowPutStructure):
        * runtime/RegExpMatchesArray.h:
        (JSC::createRegExpMatchesArray):
        * runtime/StringPrototype.cpp:
        (JSC::substituteBackreferencesSlow):
        (JSC::replaceUsingRegExpSearch):
        * yarr/YarrParser.h:
        (JSC::Yarr::Parser::CharacterClassParserDelegate::atomNamedBackReference):
        (JSC::Yarr::Parser::parseEscape):
        (JSC::Yarr::Parser::parseParenthesesBegin):
        (JSC::Yarr::Parser::tryConsumeUnicodeEscape):
        (JSC::Yarr::Parser::tryConsumeIdentifierCharacter):
        (JSC::Yarr::Parser::isIdentifierStart):
        (JSC::Yarr::Parser::isIdentifierPart):
        (JSC::Yarr::Parser::tryConsumeGroupName):
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::YarrPatternConstructor::atomParenthesesSubpatternBegin):
        (JSC::Yarr::YarrPatternConstructor::atomNamedBackReference):
        (JSC::Yarr::YarrPattern::errorMessage):
        * yarr/YarrPattern.h:
        (JSC::Yarr::YarrPattern::reset):
        * yarr/YarrSyntaxChecker.cpp:
        (JSC::Yarr::SyntaxChecker::atomParenthesesSubpatternBegin):
        (JSC::Yarr::SyntaxChecker::atomNamedBackReference):

2017-09-07  Myles C. Maxfield  <mmaxfield@apple.com>

        [PAL] Unify PlatformUserPreferredLanguages.h with Language.h
        https://bugs.webkit.org/show_bug.cgi?id=176561

        Reviewed by Brent Fulgham.

        * runtime/IntlObject.cpp:
        (JSC::defaultLocale):

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

        Augmented Inspector: Provide a way to inspect a DOM Node (DOM.inspect)
        https://bugs.webkit.org/show_bug.cgi?id=176563
        <rdar://problem/19639583>

        Reviewed by Matt Baker.

        * inspector/protocol/DOM.json:
        Add an event that is useful for augmented inspectors to inspect
        a node. Web pages will still prefer Inspector.inspect.

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

        [JSC] Remove "malloc" and "free" from JSC/API
        https://bugs.webkit.org/show_bug.cgi?id=176331

        Reviewed by Keith Miller.

        Remove "malloc" and "free" manual calls in JSC/API.

        * API/JSValue.mm:
        (createStructHandlerMap):
        * API/JSWrapperMap.mm:
        (parsePropertyAttributes):
        (makeSetterName):
        (copyPrototypeProperties):
        Use RetainPtr<NSString> to keep NSString. We avoid repeated "char*" to "NSString" conversion.

        * API/ObjcRuntimeExtras.h:
        (adoptSystem):
        Add adoptSystem to automate calling system free().

        (protocolImplementsProtocol):
        (forEachProtocolImplementingProtocol):
        (forEachMethodInClass):
        (forEachMethodInProtocol):
        (forEachPropertyInProtocol):
        (StringRange::StringRange):
        (StringRange::operator const char* const):
        (StringRange::get const):
        Use CString for backend.

        (StructBuffer::StructBuffer):
        (StructBuffer::~StructBuffer):
        (StringRange::~StringRange): Deleted.
        Use fastAlignedMalloc/astAlignedFree to get aligned memory.

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

        constructGenericTypedArrayViewWithArguments() is missing an exception check.
        https://bugs.webkit.org/show_bug.cgi?id=176485
        <rdar://problem/33898874>

        Reviewed by Keith Miller.

        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::constructGenericTypedArrayViewWithArguments):

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

        Air should have a Vector of prologue generators instead of a HashMap representing an optional prologue generator
        https://bugs.webkit.org/show_bug.cgi?id=176346

        Reviewed by Mark Lam.

        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::Procedure):
        (JSC::B3::Procedure::setNumEntrypoints):
        * b3/B3Procedure.h:
        (JSC::B3::Procedure::setNumEntrypoints): Deleted.
        * b3/air/AirCode.cpp:
        (JSC::B3::Air::defaultPrologueGenerator):
        (JSC::B3::Air::Code::Code):
        (JSC::B3::Air::Code::setNumEntrypoints):
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::setPrologueForEntrypoint):
        (JSC::B3::Air::Code::prologueGeneratorForEntrypoint):
        (JSC::B3::Air::Code::setEntrypoints):
        (JSC::B3::Air::Code::setEntrypointLabels):
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::generate):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::lower):

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

        ASSERTION FAILED: op() == CheckStructure in Source/JavaScriptCore/dfg/DFGNode.h(443)
        https://bugs.webkit.org/show_bug.cgi?id=176470

        Reviewed by Mark Lam.

        Update Node::convertToCheckStructureImmediate's assertion to allow
        the node to either be a CheckStructure or CheckStructureOrEmpty.

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

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

        isNotCellSpeculation is wrong with respect to SpecEmpty
        https://bugs.webkit.org/show_bug.cgi?id=176429

        Reviewed by Michael Saboff.

        The isNotCellSpeculation(SpeculatedType t) function was not taking into account
        SpecEmpty in the set for t. It should return false when SpecEmpty is present, since
        the empty value will fail a NotCell check. This bug would cause us to erroneously
        generate NotCellUse UseKinds for inputs that are the empty value, causing repeated OSR exits.

        * bytecode/SpeculatedType.h:
        (JSC::isNotCellSpeculation):

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

        Make the distinction between entrypoints and CFG roots more clear by naming things better
        https://bugs.webkit.org/show_bug.cgi?id=176336

        Reviewed by Mark Lam and Keith Miller and Michael Saboff.

        This patch does renaming to make the distinction between Graph::m_entrypoints
        and Graph::m_numberOfEntrypoints more clear. The source of confusion is that
        Graph::m_entrypoints.size() is not equivalent to Graph::m_numberOfEntrypoints.
        Graph::m_entrypoints is really just the CFG roots. In CPS, this vector has
        size >= 1. In SSA, the size is always 1. This patch renames Graph::m_entrypoints
        to Graph::m_roots. To be consistent, this patch also renames Graph's m_entrypointToArguments
        field to m_rootToArguments.
        
        Graph::m_numberOfEntrypoints retains its name. This field is only used in SSA
        when compiling with EntrySwitch. It represents the logical number of entrypoints
        the compilation will end up with. Each EntrySwitch has m_numberOfEntrypoints
        cases.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::parseCodeBlock):
        * dfg/DFGCFG.h:
        (JSC::DFG::CFG::roots):
        (JSC::DFG::CPSCFG::CPSCFG):
        * dfg/DFGCPSRethreadingPhase.cpp:
        (JSC::DFG::CPSRethreadingPhase::specialCaseArguments):
        * dfg/DFGDCEPhase.cpp:
        (JSC::DFG::DCEPhase::run):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        (JSC::DFG::Graph::determineReachability):
        (JSC::DFG::Graph::blocksInPreOrder):
        (JSC::DFG::Graph::blocksInPostOrder):
        (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::isRoot):
        (JSC::DFG::Graph::isEntrypoint): Deleted.
        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::InPlaceAbstractState::initialize):
        * dfg/DFGLoopPreHeaderCreationPhase.cpp:
        (JSC::DFG::createPreHeader):
        * dfg/DFGMaximalFlushInsertionPhase.cpp:
        (JSC::DFG::MaximalFlushInsertionPhase::run):
        (JSC::DFG::MaximalFlushInsertionPhase::treatRegularBlock):
        * dfg/DFGOSREntrypointCreationPhase.cpp:
        (JSC::DFG::OSREntrypointCreationPhase::run):
        * dfg/DFGPredictionInjectionPhase.cpp:
        (JSC::DFG::PredictionInjectionPhase::run):
        * dfg/DFGSSAConversionPhase.cpp:
        (JSC::DFG::SSAConversionPhase::run):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
        (JSC::DFG::SpeculativeJIT::linkOSREntries):
        * dfg/DFGTypeCheckHoistingPhase.cpp:
        (JSC::DFG::TypeCheckHoistingPhase::run):
        * dfg/DFGValidate.cpp:

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

        test262: Completion values for control flow do not match the spec
        https://bugs.webkit.org/show_bug.cgi?id=171265

        Reviewed by Saam Barati.

        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::shouldBeConcernedWithCompletionValue):
        When we care about having proper completion values (global code
        in programs, modules, and eval) insert undefined results for
        control flow statements.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::SourceElements::emitBytecode):
        Reduce writing a default `undefined` value to the completion result to
        only once before the last statement we know will produce a value.

        (JSC::IfElseNode::emitBytecode):
        (JSC::WithNode::emitBytecode):
        (JSC::WhileNode::emitBytecode):
        (JSC::ForNode::emitBytecode):
        (JSC::ForInNode::emitBytecode):
        (JSC::ForOfNode::emitBytecode):
        (JSC::SwitchNode::emitBytecode):
        Insert an undefined to handle cases where code may break out of an
        if/else or with statement (break/continue).

        (JSC::TryNode::emitBytecode):
        Same handling for break cases. Also, finally block statement completion
        values are always ignored for the try statement result.

        (JSC::ClassDeclNode::emitBytecode):
        Class declarations, like function declarations, produce an empty result.

        * parser/Nodes.cpp:
        (JSC::SourceElements::lastStatement):
        (JSC::SourceElements::hasCompletionValue):
        (JSC::SourceElements::hasEarlyBreakOrContinue):
        (JSC::BlockNode::lastStatement):
        (JSC::BlockNode::singleStatement):
        (JSC::BlockNode::hasCompletionValue):
        (JSC::BlockNode::hasEarlyBreakOrContinue):
        (JSC::ScopeNode::singleStatement):
        (JSC::ScopeNode::hasCompletionValue):
        (JSC::ScopeNode::hasEarlyBreakOrContinue):
        The only non-trivial cases need to loop through their list of statements
        to determine if this has a completion value or not. Likewise for
        determining if there is an early break / continue, meaning a break or
        continue statement with no preceding statement that has a completion value.

        * parser/Nodes.h:
        (JSC::StatementNode::next):
        (JSC::StatementNode::hasCompletionValue):
        Helper to check if a statement nodes produces a completion value or not.

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

        typeCheckHoistingPhase may emit a CheckStructure on the empty value which leads to a dereference of zero on 64 bit platforms
        https://bugs.webkit.org/show_bug.cgi?id=176317

        Reviewed by Keith Miller.

        It turns out that TypeCheckHoistingPhase may hoist a CheckStructure up to 
        the SetLocal of a particular value where the value is the empty JSValue.
        On 64-bit platforms, the empty value is zero. This means that the empty value
        passes a cell check. This will lead to a crash when we dereference null to load
        the value's structure. This patch teaches TypeCheckHoistingPhase to be conservative
        in the structure checks it hoists. On 64-bit platforms, instead of emitting a
        CheckStructure node, we now emit a CheckStructureOrEmpty node. This node allows
        the empty value to flow through. If the value isn't empty, it'll perform the normal
        structure check that CheckStructure performs. For now, we only emit CheckStructureOrEmpty
        on 64-bit platforms since a cell check on 32-bit platforms does not allow the empty
        value to flow through.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGArgumentsEliminationPhase.cpp:
        * 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::convertCheckStructureOrEmptyToCheckStructure):
        (JSC::DFG::Node::hasStructureSet):
        * dfg/DFGNodeType.h:
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::SafeToExecuteEdge::SafeToExecuteEdge):
        (JSC::DFG::SafeToExecuteEdge::operator()):
        (JSC::DFG::SafeToExecuteEdge::maySeeEmptyChild):
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitStructureCheck):
        (JSC::DFG::SpeculativeJIT::compileCheckStructure):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGTypeCheckHoistingPhase.cpp:
        (JSC::DFG::TypeCheckHoistingPhase::run):
        * dfg/DFGValidate.cpp:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileCheckStructureOrEmpty):

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

        Support compiling catch in the FTL
        https://bugs.webkit.org/show_bug.cgi?id=175396

        Reviewed by Filip Pizlo.

        This patch implements op_catch in the FTL. It extends the DFG implementation
        by supporting multiple entrypoints in DFG-SSA. This patch implements this
        by introducing an EntrySwitch node. When converting to SSA, we introduce a new
        root block with an EntrySwitch that has the previous DFG entrypoints as its
        successors. By convention, we pick the zeroth entry point index to be the
        op_enter entrypoint. Like in B3, in DFG-SSA, EntrySwitch just acts like a
        switch over the entrypoint index argument. DFG::EntrySwitch in the FTL
        simply lowers to B3::EntrySwitch. The EntrySwitch in the root block that
        SSAConversion creates can not exit because we would both not know where to exit
        to in the program: we would not have valid OSR exit state. This design also
        mandates that anything we hoist above EntrySwitch in the new root block
        can not exit since they also do not have valid OSR exit state.
        
        This patch also adds a new metadata node named InitializeEntrypointArguments.
        InitializeEntrypointArguments is a metadata node that initializes the flush format for
        the arguments at a given entrypoint. For a given entrypoint index, this node
        tells AI and OSRAvailabilityAnalysis what the flush format for each argument
        is. This allows each individual entrypoint to have an independent set of
        argument types. Currently, this won't happen in practice because ArgumentPosition
        unifies flush formats, but this is an implementation detail we probably want
        to modify in the future. SSAConversion will add InitializeEntrypointArguments
        to the beginning of each of the original DFG entrypoint blocks.
        
        This patch also adds the ability to specify custom prologue code generators in Air.
        This allows the FTL to specify a custom prologue for catch entrypoints that
        matches the op_catch OSR entry calling convention that the DFG uses. This way,
        the baseline JIT code OSR enters into op_catch the same way both in the DFG
        and the FTL. In the future, we can use this same mechanism to perform stack
        overflow checks instead of using a patchpoint.

        * b3/air/AirCode.cpp:
        (JSC::B3::Air::Code::isEntrypoint):
        (JSC::B3::Air::Code::entrypointIndex):
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::setPrologueForEntrypoint):
        (JSC::B3::Air::Code::prologueGeneratorForEntrypoint):
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::generate):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGBasicBlock.h:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::parse):
        * dfg/DFGCFG.h:
        (JSC::DFG::selectCFG):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGClobbersExitState.cpp:
        (JSC::DFG::clobbersExitState):
        * dfg/DFGCommonData.cpp:
        (JSC::DFG::CommonData::shrinkToFit):
        (JSC::DFG::CommonData::finalizeCatchEntrypoints):
        * dfg/DFGCommonData.h:
        (JSC::DFG::CommonData::catchOSREntryDataForBytecodeIndex):
        (JSC::DFG::CommonData::appendCatchEntrypoint):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        (JSC::DFG::Graph::invalidateCFG):
        (JSC::DFG::Graph::ensureCPSCFG):
        (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::isEntrypoint):
        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::InPlaceAbstractState::initialize):
        (JSC::DFG::InPlaceAbstractState::mergeToSuccessors):
        * dfg/DFGJITCode.cpp:
        (JSC::DFG::JITCode::shrinkToFit):
        (JSC::DFG::JITCode::finalizeOSREntrypoints):
        * dfg/DFGJITCode.h:
        (JSC::DFG::JITCode::catchOSREntryDataForBytecodeIndex): Deleted.
        (JSC::DFG::JITCode::appendCatchEntrypoint): Deleted.
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::noticeCatchEntrypoint):
        (JSC::DFG::JITCompiler::makeCatchOSREntryBuffer):
        * dfg/DFGMayExit.cpp:
        * dfg/DFGNode.h:
        (JSC::DFG::Node::isEntrySwitch):
        (JSC::DFG::Node::isTerminal):
        (JSC::DFG::Node::entrySwitchData):
        (JSC::DFG::Node::numSuccessors):
        (JSC::DFG::Node::successor):
        (JSC::DFG::Node::entrypointIndex):
        * dfg/DFGNodeType.h:
        * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
        (JSC::DFG::OSRAvailabilityAnalysisPhase::run):
        (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareCatchOSREntry):
        * dfg/DFGOSREntry.h:
        * dfg/DFGOSREntrypointCreationPhase.cpp:
        (JSC::DFG::OSREntrypointCreationPhase::run):
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSSAConversionPhase.cpp:
        (JSC::DFG::SSAConversionPhase::SSAConversionPhase):
        (JSC::DFG::SSAConversionPhase::run):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::linkOSREntries):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStaticExecutionCountEstimationPhase.cpp:
        (JSC::DFG::StaticExecutionCountEstimationPhase::run):
        * dfg/DFGValidate.cpp:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::lower):
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileExtractCatchLocal):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetStack):
        (JSC::FTL::DFG::LowerDFGToB3::compileEntrySwitch):
        (JSC::FTL::DFG::LowerDFGToB3::speculate):
        (JSC::FTL::DFG::LowerDFGToB3::appendOSRExitDescriptor):
        (JSC::FTL::DFG::LowerDFGToB3::appendOSRExit):
        (JSC::FTL::DFG::LowerDFGToB3::blessSpeculation):
        * ftl/FTLOutput.cpp:
        (JSC::FTL::Output::entrySwitch):
        * ftl/FTLOutput.h:
        * jit/JITOperations.cpp:

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

        [DFG][FTL] Efficiently execute number#toString()
        https://bugs.webkit.org/show_bug.cgi?id=170007

        Reviewed by Keith Miller.

        In JS, the natural way to convert number to string with radix is `number.toString(radix)`.
        However, our IC only cares about cells. If the base value is a number, it always goes to the slow path.

        While extending our IC for number and boolean, the most meaningful use of this IC is calling `number.toString(radix)`.
        So, in this patch, we first add a fast path for this in DFG by using watchpoint. We set up a watchpoint for
        Number.prototype.toString. And if this watchpoint is kept alive and GetById(base, "toString")'s base should be
        speculated as Number, we emit Number related Checks and convert GetById to Number.prototype.toString constant.
        It removes costly GetById slow path, and makes it non-clobbering node (JSConstant).

        In addition, we add NumberToStringWithValidRadixConstant node. We have NumberToStringWithRadix node, but it may
        throw an error if the valid value is incorrect (for example, number.toString(2000)). So its clobbering rule is
        conservatively use read(World)/write(Heap). But in reality, `number.toString` is mostly called with the constant
        radix, and we can easily figure out this radix is valid (2 <= radix && radix < 32).
        We add a rule to the constant folding phase to convert NumberToStringWithRadix to NumberToStringWithValidRadixConstant.
        It ensures that it has valid constant radix. And we relax our clobbering rule for NumberToStringWithValidRadixConstant.

        Added microbenchmarks show performance improvement.

                                                      baseline                  patched

        number-to-string-with-radix-cse           43.8312+-1.3017     ^      7.4930+-0.5105        ^ definitely 5.8496x faster
        number-to-string-with-radix-10             7.2775+-0.5225     ^      2.1906+-0.1864        ^ definitely 3.3222x faster
        number-to-string-with-radix               39.7378+-1.4921     ^     16.6137+-0.7776        ^ definitely 2.3919x faster
        number-to-string-strength-reduction       94.9667+-2.7157     ^      9.3060+-0.7202        ^ definitely 10.2049x faster

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * 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/DFGGraph.h:
        (JSC::DFG::Graph::isWatchingGlobalObjectWatchpoint):
        (JSC::DFG::Graph::isWatchingArrayIteratorProtocolWatchpoint):
        (JSC::DFG::Graph::isWatchingNumberToStringWatchpoint):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToNumberToStringWithValidRadixConstant):
        (JSC::DFG::Node::hasValidRadixConstant):
        (JSC::DFG::Node::validRadixConstant):
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructor):
        (JSC::DFG::SpeculativeJIT::compileNumberToStringWithValidRadixConstant):
        (JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOnNumber): Deleted.
        * dfg/DFGSpeculativeJIT.h:
        * 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::compileNumberToStringWithValidRadixConstant):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::JSGlobalObject):
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::numberToStringWatchpoint):
        (JSC::JSGlobalObject::numberProtoToStringFunction const):
        * runtime/NumberPrototype.cpp:
        (JSC::NumberPrototype::finishCreation):
        (JSC::toStringWithRadixInternal):
        (JSC::toStringWithRadix):
        (JSC::int32ToStringInternal):
        (JSC::numberToStringInternal):
        * runtime/NumberPrototype.h:

2017-09-04  Yusuke Suzuki  <utatane.tea@gmail.com>

        [DFG] Consider increasing the number of DFG worklist threads
        https://bugs.webkit.org/show_bug.cgi?id=176222

        Reviewed by Saam Barati.

        Attempt to add one more thread to DFG worklist. DFG compiler sometimes takes
        very long time if the target function is very large. However, DFG worklist
        has only one thread before this patch. Therefore, one function that takes
        too much time to be compiled can prevent the other functions from being
        compiled in DFG or upper tiers.

        One example is Octane/zlib. In zlib, compiling "a1" function in DFG takes
        super long time (447 ms) because of its super large size of the function.
        While this function never gets compiled in FTL due to its large size,
        it can be compiled in DFG and takes super long time. Subsequent "a8" function
        compilation in DFG is blocked by this "a1". As a consequence, the benchmark
        takes very long time in a1/Baseline code, which is slower than DFG of course.

        While FTL has a bit more threads, DFG worklist has only one thread. This patch
        adds one more thread to DFG worklist to alleviate the above situation. This
        change significantly improves Octane/zlib performance.

                                    baseline                  patched

        zlib           x2     482.32825+-6.07640    ^   408.66072+-14.03856      ^ definitely 1.1803x faster

        * runtime/Options.h:

2017-09-04  Sam Weinig  <sam@webkit.org>

        [WebIDL] Unify and simplify EnableBySettings with the rest of the runtime settings
        https://bugs.webkit.org/show_bug.cgi?id=176312

        Reviewed by Darin Adler.

        * runtime/CommonIdentifiers.h:

            Remove WebCore specific identifiers from CommonIdentifiers. They have been moved
            to WebCoreBuiltinNames in WebCore.

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

        Remove "malloc" and "free" use
        https://bugs.webkit.org/show_bug.cgi?id=176310

        Reviewed by Darin Adler.

        Use Vector instead.

        * API/JSWrapperMap.mm:
        (selectorToPropertyName):

2017-09-03  Darin Adler  <darin@apple.com>

        Try to fix Windows build.

        * runtime/JSGlobalObjectFunctions.cpp: #include <unicode/utf8.h>.

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

        [WTF] Add C++03 allocator interface for GCC < 6
        https://bugs.webkit.org/show_bug.cgi?id=176301

        Reviewed by Darin Adler.

        * dfg/DFGObjectAllocationSinkingPhase.cpp:

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

        Unreviewed, rolling out r221555.

        Did not fix Windows build

        Reverted changeset:

        "Unreviewed attempt to fix Windows build."
        http://trac.webkit.org/changeset/221555

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

        Unreviewed attempt to fix Windows build.

        * runtime/JSGlobalObjectFunctions.cpp:

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

        Unreviewed, rolling out r221552.

        Broke the build

        Reverted changeset:

        "[WTF] Add C++03 allocator interface for GCC < 6"
        https://bugs.webkit.org/show_bug.cgi?id=176301
        http://trac.webkit.org/changeset/221552

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

        [WTF] Add C++03 allocator interface for GCC < 6
        https://bugs.webkit.org/show_bug.cgi?id=176301

        Reviewed by Darin Adler.

        * dfg/DFGObjectAllocationSinkingPhase.cpp:

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

        [JSC] Clean up BytecodeLivenessAnalysis
        https://bugs.webkit.org/show_bug.cgi?id=176295

        Reviewed by Saam Barati.

        Previously, computeDefsForBytecodeOffset was a bit customizable.
        This is used for try-catch handler's liveness analysis. But after
        careful generatorification implementation, it is now not necessary.
        This patch drops this customizability.

        * bytecode/BytecodeGeneratorification.cpp:
        (JSC::GeneratorLivenessAnalysis::computeDefsForBytecodeOffset): Deleted.
        (JSC::GeneratorLivenessAnalysis::computeUsesForBytecodeOffset): Deleted.
        * bytecode/BytecodeLivenessAnalysis.cpp:
        (JSC::BytecodeLivenessAnalysis::computeKills):
        (JSC::BytecodeLivenessAnalysis::computeDefsForBytecodeOffset): Deleted.
        (JSC::BytecodeLivenessAnalysis::computeUsesForBytecodeOffset): Deleted.
        * bytecode/BytecodeLivenessAnalysis.h:
        * bytecode/BytecodeLivenessAnalysisInlines.h:
        (JSC::BytecodeLivenessPropagation::stepOverInstruction):
        (JSC::BytecodeLivenessPropagation::computeLocalLivenessForBytecodeOffset):
        (JSC::BytecodeLivenessPropagation::computeLocalLivenessForBlock):
        (JSC::BytecodeLivenessPropagation::getLivenessInfoAtBytecodeOffset):
        (JSC::BytecodeLivenessPropagation::runLivenessFixpoint):
        (JSC::BytecodeLivenessPropagation<DerivedAnalysis>::stepOverInstruction): Deleted.
        (JSC::BytecodeLivenessPropagation<DerivedAnalysis>::computeLocalLivenessForBytecodeOffset): Deleted.
        (JSC::BytecodeLivenessPropagation<DerivedAnalysis>::computeLocalLivenessForBlock): Deleted.
        (JSC::BytecodeLivenessPropagation<DerivedAnalysis>::getLivenessInfoAtBytecodeOffset): Deleted.
        (JSC::BytecodeLivenessPropagation<DerivedAnalysis>::runLivenessFixpoint): Deleted.

2017-09-03  Sam Weinig  <sam@webkit.org>

        Remove CanvasProxy
        https://bugs.webkit.org/show_bug.cgi?id=176288

        Reviewed by Yusuke Suzuki.

        CanvasProxy does not appear to be in any current HTML spec
        and was disabled and unimplemented in our tree. Time to 
        get rid of it.

        * Configurations/FeatureDefines.xcconfig:

2017-09-02  Oliver Hunt  <oliver@apple.com>

        Need an API to get the global context from JSObjectRef
        https://bugs.webkit.org/show_bug.cgi?id=176291

        Reviewed by Saam Barati.

        Very simple additional API, starting off as SPI on principle.

        * API/JSObjectRef.cpp:
        (JSObjectGetGlobalContext):
        * API/JSObjectRefPrivate.h:
        * API/tests/testapi.c:
        (main):

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

        [DFG] Relax arity requirement
        https://bugs.webkit.org/show_bug.cgi?id=175523

        Reviewed by Saam Barati.

        Our DFG pipeline gives up inlining when the arity of the target function is more than the number of the arguments.
        It effectively prevents us from inlining and optimizing functions, which takes some optional arguments in the form
        of the pre-ES6.

        This patch removes the above restriction by performing the arity fixup in DFG.

        SixSpeed shows improvement when we can inline arity-mismatched functions. (For example, calling generator.next()).

                                       baseline                  patched

        defaults.es5             1232.1226+-20.6775    ^    442.3326+-26.1883       ^ definitely 2.7855x faster
        rest.es6                    5.3406+-0.8588     ^      3.5812+-0.5388        ^ definitely 1.4913x faster
        spread-generator.es6      320.9107+-12.4808         310.4295+-12.0047         might be 1.0338x faster
        generator.es6             318.3514+-9.6023     ^    286.4974+-12.6203       ^ definitely 1.1112x faster

        * bytecode/InlineCallFrame.cpp:
        (JSC::InlineCallFrame::dumpInContext const):
        * bytecode/InlineCallFrame.h:
        (JSC::InlineCallFrame::InlineCallFrame):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGArgumentsUtilities.cpp:
        (JSC::DFG::argumentsInvolveStackSlot):
        (JSC::DFG::emitCodeToGetArgumentsArrayLength):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::setLocal):
        (JSC::DFG::ByteCodeParser::setArgument):
        (JSC::DFG::ByteCodeParser::findArgumentPositionForLocal):
        (JSC::DFG::ByteCodeParser::flush):
        (JSC::DFG::ByteCodeParser::getArgumentCount):
        (JSC::DFG::ByteCodeParser::inliningCost):
        (JSC::DFG::ByteCodeParser::inlineCall):
        (JSC::DFG::ByteCodeParser::attemptToInlineCall):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        * dfg/DFGCommonData.cpp:
        (JSC::DFG::CommonData::validateReferences):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::isLiveInBytecode):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
        * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
        (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::emitRestoreArguments):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::reifyInlinedCallFrames):
        * dfg/DFGPreciseLocalClobberize.h:
        (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitGetLength):
        (JSC::DFG::SpeculativeJIT::compileCreateDirectArguments):
        * dfg/DFGStackLayoutPhase.cpp:
        (JSC::DFG::StackLayoutPhase::run):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileGetMyArgumentByVal):
        (JSC::FTL::DFG::LowerDFGToB3::getArgumentsLength):
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationMaterializeObjectInOSR):
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::readInlinedFrame):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::argumentsStart):
        * jit/SetupVarargsFrame.cpp:
        (JSC::emitSetupVarargsFrameFastCase):
        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::createWithInlineFrame):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::numberOfExtraSlots):
        (JSC::CommonSlowPaths::numberOfStackPaddingSlots):
        (JSC::CommonSlowPaths::numberOfStackPaddingSlotsWithExtraSlots):
        (JSC::CommonSlowPaths::arityCheckFor):
        * runtime/StackAlignment.h:
        (JSC::stackAlignmentBytes):
        (JSC::stackAlignmentRegisters):

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

        [FTL] FTL allocation for async Function is incorrect
        https://bugs.webkit.org/show_bug.cgi?id=176214

        Reviewed by Saam Barati.

        In FTL, allocating async function / async generator function was incorrectly using
        JSFunction logic. While it is not observable right now since sizeof(JSFunction) == sizeof(JSAsyncFunction),
        but it is a bug.

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

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

        [JSC] Fix "name" and "length" of Proxy revoke function
        https://bugs.webkit.org/show_bug.cgi?id=176155

        Reviewed by Mark Lam.

        ProxyRevoke's length should be configurable. And it does not have
        its own name. We add NameVisibility enum to InternalFunction to
        control visibility of the name.

        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::finishCreation):
        * runtime/InternalFunction.h:
        * runtime/ProxyRevoke.cpp:
        (JSC::ProxyRevoke::finishCreation):

2017-08-31  Saam Barati  <sbarati@apple.com>

        Throwing an exception in the DFG/FTL should not cause a jettison
        https://bugs.webkit.org/show_bug.cgi?id=176060
        <rdar://problem/34143348>

        Reviewed by Keith Miller.

        Throwing an exception is not something that should be a jettison-able
        OSR exit. We used to count Throw/ThrowStaticError towards our OSR exit
        counts which could cause a CodeBlock to jettison and recompile. This
        was dumb. Throwing an exception is not a reason to jettison and
        recompile in the way that a speculation failure is. This patch
        treats Throw/ThrowStaticError as true terminals in DFG IR.

        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::InPlaceAbstractState::mergeToSuccessors):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::isTerminal):
        (JSC::DFG::Node::isPseudoTerminal):
        (JSC::DFG::Node::errorType):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileThrow):
        (JSC::DFG::SpeculativeJIT::compileThrowStaticError):
        * 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::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileThrow):
        (JSC::FTL::DFG::LowerDFGToB3::compileThrowStaticError):
        * jit/JITOperations.h:

2017-08-31  Saam Barati  <sbarati@apple.com>

        Graph::methodOfGettingAValueProfileFor compares NodeOrigin instead of the semantic CodeOrigin
        https://bugs.webkit.org/show_bug.cgi?id=176206

        Reviewed by Keith Miller.

        Mark fixed the main issue in Graph::methodOfGettingAValueProfileFor in r208560
        when he fixed it from overwriting invalid parts of the ArithProfile when the
        currentNode and the operandNode are from the same bytecode. However, the
        mechanism used to determine same bytecode was comparing NodeOrigin. That's
        slightly wrong. We need to compare semantic origin, since two NodeOrigins can
        have the same semantic origin, but differ only in exitOK. For example,
        in the below IR, the DoubleRep and the Phi have the same semantic
        origin, but different NodeOrigins.

        43 Phi(JS|PureInt, NonBoolInt32|NonIntAsdouble, W:SideState, bc#63, ExitInvalid)
        58 ExitOK(MustGen, W:SideState, bc#63)
        51 DoubleRep(Check:Number:Kill:@43, Double|PureInt, BytecodeDouble, Exits, bc#63)
        54 ArithNegate(DoubleRep:Kill:@51<Double>, Double|UseAsOther|MayHaveDoubleResult, AnyIntAsDouble|NonIntAsdouble, NotSet, Exits, bc#63)

        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::methodOfGettingAValueProfileFor):

2017-08-31  Don Olmstead  <don.olmstead@sony.com>

        [CMake] Make USE_CF conditional within Windows
        https://bugs.webkit.org/show_bug.cgi?id=176173

        Reviewed by Alex Christensen.

        * PlatformWin.cmake:

2017-08-31  Saam Barati  <sbarati@apple.com>

        useSeparatedWXHeap should never be true when not on iOS
        https://bugs.webkit.org/show_bug.cgi?id=176190

        Reviewed by JF Bastien.

        If you set useSeparatedWXHeap to true on X86_64, and launch the jsc shell,
        the process insta-crashes. Let's silently ignore that option and set it
        to false when not on iOS.

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

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

        Fix debug crashes.

        Rubber stamped by Mark Lam.

        * runtime/JSArrayBufferView.cpp:
        (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):

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

        All of the different ArrayBuffer::data's should be CagedPtr<>
        https://bugs.webkit.org/show_bug.cgi?id=175515

        Reviewed by Michael Saboff.
        
        This straightforwardly implements what the title says.

        * runtime/ArrayBuffer.cpp:
        (JSC::SharedArrayBufferContents::~SharedArrayBufferContents):
        (JSC::ArrayBufferContents::destroy):
        (JSC::ArrayBufferContents::tryAllocate):
        (JSC::ArrayBufferContents::makeShared):
        (JSC::ArrayBufferContents::copyTo):
        (JSC::ArrayBuffer::createFromBytes):
        (JSC::ArrayBuffer::transferTo):
        * runtime/ArrayBuffer.h:
        (JSC::SharedArrayBufferContents::data const):
        (JSC::ArrayBufferContents::data const):
        (JSC::ArrayBuffer::data):
        (JSC::ArrayBuffer::data const):
        * runtime/ArrayBufferView.h:
        (JSC::ArrayBufferView::baseAddress const):
        * runtime/CagedBarrierPtr.h: Added a specialization so that CagedBarrierPtr<Gigacage::Foo, void> is valid.
        * runtime/DataView.h:
        (JSC::DataView::get):
        (JSC::DataView::set):
        * runtime/JSArrayBufferView.cpp:
        (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
        * runtime/JSArrayBufferView.h:
        (JSC::JSArrayBufferView::ConstructionContext::vector const):
        (JSC::JSArrayBufferView::vector const):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren):

2017-08-22  Filip Pizlo  <fpizlo@apple.com>

        Strings need to be in some kind of gigacage
        https://bugs.webkit.org/show_bug.cgi?id=174924

        Reviewed by Oliver Hunt.

        * runtime/JSString.cpp:
        (JSC::JSRopeString::resolveRopeToAtomicString const):
        (JSC::JSRopeString::resolveRope const):
        * runtime/JSString.h:
        (JSC::JSString::create):
        (JSC::JSString::createHasOtherOwner):
        * runtime/JSStringBuilder.h:
        * runtime/VM.h:
        (JSC::VM::gigacageAuxiliarySpace):

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

        [JSC] Use reifying system for "name" property of builtin JSFunction
        https://bugs.webkit.org/show_bug.cgi?id=175260

        Reviewed by Saam Barati.

        Currently builtin JSFunction uses direct property for "name", which is different
        from usual JSFunction. Usual JSFunction uses reifying system for "name". We would like
        to apply this reifying mechanism to builtin JSFunction to simplify code and drop
        JSFunction::createBuiltinFunction.

        We would like to store the "correct" name in FunctionExecutable. For example,
        we would like to store the name like "get [Symbol.species]" to FunctionExecutable
        instead of specifying name when creating JSFunction. To do so, we add a new
        annotations, @getter and @overriddenName. When @getter is specified, the name of
        the function becomes "get xxx". And when @overriddenName="xxx" is specified,
        the name of the function becomes "xxx".

        We also treat @xxx as anonymous builtin functions that cannot be achieved in
        the current JS without privilege.

        * Scripts/builtins/builtins_generate_combined_header.py:
        (generate_section_for_code_table_macro):
        * Scripts/builtins/builtins_generate_combined_implementation.py:
        (BuiltinsCombinedImplementationGenerator.generate_secondary_header_includes):
        * Scripts/builtins/builtins_generate_separate_header.py:
        (generate_section_for_code_table_macro):
        * Scripts/builtins/builtins_generate_separate_implementation.py:
        (BuiltinsSeparateImplementationGenerator.generate_secondary_header_includes):
        * Scripts/builtins/builtins_model.py:
        (BuiltinFunction.__init__):
        (BuiltinFunction.fromString):
        * Scripts/builtins/builtins_templates.py:
        * Scripts/tests/builtins/JavaScriptCore-Builtin.prototype-Combined.js:
        (overriddenName.string_appeared_here.match):
        (intrinsic.RegExpTestIntrinsic.test):
        * Scripts/tests/builtins/JavaScriptCore-Builtin.prototype-Separate.js:
        (overriddenName.string_appeared_here.match):
        (intrinsic.RegExpTestIntrinsic.test):
        * 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:
        * builtins/AsyncIteratorPrototype.js:
        (symbolAsyncIteratorGetter): Deleted.
        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::BuiltinExecutables):
        * builtins/BuiltinExecutables.h:
        * builtins/BuiltinNames.h:
        * builtins/FunctionPrototype.js:
        (symbolHasInstance): Deleted.
        * builtins/GlobalOperations.js:
        (globalPrivate.speciesGetter): Deleted.
        * builtins/IteratorPrototype.js:
        (symbolIteratorGetter): Deleted.
        * builtins/PromiseConstructor.js:
        (all.newResolveElement.return.resolve):
        (all.newResolveElement):
        (all):
        * builtins/PromiseOperations.js:
        (globalPrivate.newPromiseCapability.executor):
        (globalPrivate.newPromiseCapability):
        (globalPrivate.createResolvingFunctions.resolve):
        (globalPrivate.createResolvingFunctions.reject):
        (globalPrivate.createResolvingFunctions):
        * builtins/RegExpPrototype.js:
        (match): Deleted.
        (replace): Deleted.
        (search): Deleted.
        (split): Deleted.
        * jsc.cpp:
        (functionCreateBuiltin):
        * runtime/AsyncIteratorPrototype.cpp:
        (JSC::AsyncIteratorPrototype::finishCreation):
        * runtime/FunctionPrototype.cpp:
        (JSC::FunctionPrototype::addFunctionProperties):
        * runtime/IteratorPrototype.cpp:
        (JSC::IteratorPrototype::finishCreation):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::finishCreation):
        (JSC::JSFunction::getOwnNonIndexPropertyNames):
        (JSC::JSFunction::reifyLazyBoundNameIfNeeded):
        (JSC::JSFunction::createBuiltinFunction): Deleted.
        * runtime/JSFunction.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSObject.cpp:
        (JSC::JSObject::putDirectBuiltinFunction):
        (JSC::JSObject::putDirectBuiltinFunctionWithoutTransition):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::JSTypedArrayViewPrototype::finishCreation):
        * runtime/Lookup.cpp:
        (JSC::reifyStaticAccessor):
        * runtime/MapPrototype.cpp:
        (JSC::MapPrototype::finishCreation):
        * runtime/RegExpPrototype.cpp:
        (JSC::RegExpPrototype::finishCreation):
        * runtime/SetPrototype.cpp:
        (JSC::SetPrototype::finishCreation):

2017-08-30  Ryan Haddad  <ryanhaddad@apple.com>

        Unreviewed, rolling out r221327.

        This change caused test262 failures.

        Reverted changeset:

        "[JSC] Use reifying system for "name" property of builtin
        JSFunction"
        https://bugs.webkit.org/show_bug.cgi?id=175260
        http://trac.webkit.org/changeset/221327

2017-08-30  Matt Lewis  <jlewis3@apple.com>

        Unreviewed, rolling out r221384.

        This patch caused multiple 32-bit JSC test failures.

        Reverted changeset:

        "Strings need to be in some kind of gigacage"
        https://bugs.webkit.org/show_bug.cgi?id=174924
        http://trac.webkit.org/changeset/221384

2017-08-30  Saam Barati  <sbarati@apple.com>

        semicolon is being interpreted as an = in the LiteralParser
        https://bugs.webkit.org/show_bug.cgi?id=176114

        Reviewed by Oliver Hunt.

        When lexing a semicolon in the LiteralParser, we were properly
        setting the TokenType on the current token, however, we were
        *returning* the wrong TokenType. The lex function both returns
        the TokenType and sets it on the current token. Semicolon was
        setting the TokenType to semicolon, but returning the TokenType
        for '='. This caused programs like `x;123` to be interpreted as
        `x=123`.

        * runtime/LiteralParser.cpp:
        (JSC::LiteralParser<CharType>::Lexer::lex):
        (JSC::LiteralParser<CharType>::Lexer::next):

2017-08-22  Filip Pizlo  <fpizlo@apple.com>

        Strings need to be in some kind of gigacage
        https://bugs.webkit.org/show_bug.cgi?id=174924

        Reviewed by Oliver Hunt.

        * runtime/JSString.cpp:
        (JSC::JSRopeString::resolveRopeToAtomicString const):
        (JSC::JSRopeString::resolveRope const):
        * runtime/JSString.h:
        (JSC::JSString::create):
        (JSC::JSString::createHasOtherOwner):
        * runtime/JSStringBuilder.h:
        * runtime/VM.h:
        (JSC::VM::gigacageAuxiliarySpace):

2017-08-30  Oleksandr Skachkov  <gskachkov@gmail.com>

        [ESNext] Async iteration - Implement async iteration statement: for-await-of
        https://bugs.webkit.org/show_bug.cgi?id=166698

        Reviewed by Yusuke Suzuki.

        Implementation of the for-await-of statement.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitEnumeration):
        (JSC::BytecodeGenerator::emitIteratorNext):
        * bytecompiler/BytecodeGenerator.h:
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createForOfLoop):
        * parser/NodeConstructors.h:
        (JSC::ForOfNode::ForOfNode):
        * parser/Nodes.h:
        (JSC::ForOfNode::isForAwait const):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseForStatement):
        * parser/Parser.h:
        (JSC::Scope::setSourceParseMode):
        (JSC::Scope::setIsFunction):
        (JSC::Scope::setIsAsyncGeneratorFunction):
        (JSC::Scope::setIsAsyncGeneratorFunctionBody):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createForOfLoop):

2017-08-29  Commit Queue  <commit-queue@webkit.org>

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

        "It broke a testing mode because we will never FTL compile a
        function that repeatedly throws" (Requested by saamyjoon on
        #webkit).

        Reverted changeset:

        "Throwing an exception in the DFG/FTL should not be a
        jettison-able OSR exit"
        https://bugs.webkit.org/show_bug.cgi?id=176060
        http://trac.webkit.org/changeset/221317

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

        [DFG] Add constant folding rule to convert CompareStrictEq(Untyped, Untyped [with non string cell constant]) to CompareEqPtr(Untyped)
        https://bugs.webkit.org/show_bug.cgi?id=175895

        Reviewed by Saam Barati.

        We have `bucket === @sentinelMapBucket` code in builtin. Since @sentinelMapBucket and bucket
        are MapBucket cell (SpecCellOther), we do not have any good fixup for CompareStrictEq.
        But rather than introducing a special fixup edge (like, NonStringCellUse), converting
        CompareStrictEq(Untyped, Untyped) to CompareEqPtr is simpler.
        In constant folding phase, we convert CompareStrictEq(Untyped, Untyped) to CompareEqPtr(Untyed)
        if one side of the children is constant non String cell.

        This slightly optimizes map/set iteration.

        set-for-each          4.5064+-0.3072     ^      3.2862+-0.2098        ^ definitely 1.3713x faster
        large-map-iteration  56.2583+-1.6640           53.6798+-2.0097          might be 1.0480x faster
        set-for-of            8.8058+-0.5953     ^      7.5832+-0.3805        ^ definitely 1.1612x faster
        map-for-each          4.2633+-0.2694     ^      3.3967+-0.3013        ^ definitely 1.2551x faster
        map-for-of           13.1556+-0.5707           12.4911+-0.6004          might be 1.0532x faster

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToCompareEqPtr):

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

        [JSC] Use reifying system for "name" property of builtin JSFunction
        https://bugs.webkit.org/show_bug.cgi?id=175260

        Reviewed by Saam Barati.

        Currently builtin JSFunction uses direct property for "name", which is different
        from usual JSFunction. Usual JSFunction uses reifying system for "name". We would like
        to apply this reifying mechanism to builtin JSFunction to simplify code and drop
        JSFunction::createBuiltinFunction.

        We would like to store the "correct" name in FunctionExecutable. For example,
        we would like to store the name like "get [Symbol.species]" to FunctionExecutable
        instead of specifying name when creating JSFunction. To do so, we add a new
        annotations, @getter and @overriddenName. When @getter is specified, the name of
        the function becomes "get xxx". And when @overriddenName="xxx" is specified,
        the name of the function becomes "xxx".

        * Scripts/builtins/builtins_generate_combined_header.py:
        (generate_section_for_code_table_macro):
        * Scripts/builtins/builtins_generate_combined_implementation.py:
        (BuiltinsCombinedImplementationGenerator.generate_secondary_header_includes):
        * Scripts/builtins/builtins_generate_separate_header.py:
        (generate_section_for_code_table_macro):
        * Scripts/builtins/builtins_generate_separate_implementation.py:
        (BuiltinsSeparateImplementationGenerator.generate_secondary_header_includes):
        * Scripts/builtins/builtins_model.py:
        (BuiltinFunction.__init__):
        (BuiltinFunction.fromString):
        * Scripts/builtins/builtins_templates.py:
        * Scripts/tests/builtins/JavaScriptCore-Builtin.prototype-Combined.js:
        (overriddenName.string_appeared_here.match):
        (intrinsic.RegExpTestIntrinsic.test):
        * Scripts/tests/builtins/JavaScriptCore-Builtin.prototype-Separate.js:
        (overriddenName.string_appeared_here.match):
        (intrinsic.RegExpTestIntrinsic.test):
        * 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:
        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::BuiltinExecutables):
        * builtins/BuiltinExecutables.h:
        * builtins/FunctionPrototype.js:
        (symbolHasInstance): Deleted.
        * builtins/GlobalOperations.js:
        (globalPrivate.speciesGetter): Deleted.
        * builtins/IteratorPrototype.js:
        (symbolIteratorGetter): Deleted.
        * builtins/RegExpPrototype.js:
        (match): Deleted.
        (replace): Deleted.
        (search): Deleted.
        (split): Deleted.
        * jsc.cpp:
        (functionCreateBuiltin):
        * runtime/FunctionPrototype.cpp:
        (JSC::FunctionPrototype::addFunctionProperties):
        * runtime/IteratorPrototype.cpp:
        (JSC::IteratorPrototype::finishCreation):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::getOwnNonIndexPropertyNames):
        (JSC::JSFunction::reifyLazyBoundNameIfNeeded):
        (JSC::JSFunction::createBuiltinFunction): Deleted.
        * runtime/JSFunction.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSObject.cpp:
        (JSC::JSObject::putDirectBuiltinFunction):
        (JSC::JSObject::putDirectBuiltinFunctionWithoutTransition):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::JSTypedArrayViewPrototype::finishCreation):
        * runtime/Lookup.cpp:
        (JSC::reifyStaticAccessor):
        * runtime/RegExpPrototype.cpp:
        (JSC::RegExpPrototype::finishCreation):

2017-08-29  Saam Barati  <sbarati@apple.com>

        Throwing an exception in the DFG/FTL should not be a jettison-able OSR exit
        https://bugs.webkit.org/show_bug.cgi?id=176060

        Reviewed by Michael Saboff.

        OSR exitting when we throw an exception is expected behavior. We should
        not count these exits towards our jettison OSR exit threshold.

        * bytecode/ExitKind.cpp:
        (JSC::exitKindToString):
        (JSC::exitKindMayJettison):
        * bytecode/ExitKind.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileThrow):

2017-08-29  Chris Dumez  <cdumez@apple.com>

        Add initial support for dataTransferItem.webkitGetAsEntry()
        https://bugs.webkit.org/show_bug.cgi?id=176038
        <rdar://problem/34121095>

        Reviewed by Wenson Hsieh.

        Add CommonIdentifier needed by [EnabledAtRuntime].

        * runtime/CommonIdentifiers.h:

2017-08-27  Devin Rousso  <webkit@devinrousso.com>

        Web Inspector: Record actions performed on WebGLRenderingContext
        https://bugs.webkit.org/show_bug.cgi?id=174483
        <rdar://problem/34040722>

        Reviewed by Matt Baker.

        * inspector/protocol/Recording.json:
        * inspector/scripts/codegen/generator.py:
        Add type and mapping for WebGL: "canvas-webgl" => CanvasWebGL

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

        Unreviewed, suppress warnings in GTK port

        The "block" variable hides the argument variable.

        * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
        (JSC::DFG::LiveCatchVariablePreservationPhase::isValidFlushLocation):

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

        Merge WeakMapData into JSWeakMap and JSWeakSet
        https://bugs.webkit.org/show_bug.cgi?id=143919

        Reviewed by Darin Adler.

        This patch changes WeakMapData from JSCell to JSDestructibleObject,
        renaming it to WeakMapBase, and JSWeakMap and JSWeakSet simply inherit
        it instead of separately allocating WeakMapData. This reduces memory
        consumption and allocation times.

        Also this patch a bit optimizes sizeof(DeadKeyCleaner) by dropping m_target
        field. Since this class is always embedded in WeakMapBase, we can calculate
        WeakMapBase address from the address of DeadKeyCleaner.

        This patch does not include the optimization changing WeakMapData to Set
        for JSWeakSet.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::weakMapSize):
        (Inspector::JSInjectedScriptHost::weakMapEntries):
        (Inspector::JSInjectedScriptHost::weakSetSize):
        (Inspector::JSInjectedScriptHost::weakSetEntries):
        * runtime/JSWeakMap.cpp:
        (JSC::JSWeakMap::finishCreation): Deleted.
        (JSC::JSWeakMap::visitChildren): Deleted.
        * runtime/JSWeakMap.h:
        (JSC::JSWeakMap::createStructure): Deleted.
        (JSC::JSWeakMap::create): Deleted.
        (JSC::JSWeakMap::weakMapData): Deleted.
        (JSC::JSWeakMap::JSWeakMap): Deleted.
        * runtime/JSWeakSet.cpp:
        (JSC::JSWeakSet::finishCreation): Deleted.
        (JSC::JSWeakSet::visitChildren): Deleted.
        * runtime/JSWeakSet.h:
        (JSC::JSWeakSet::createStructure): Deleted.
        (JSC::JSWeakSet::create): Deleted.
        (JSC::JSWeakSet::weakMapData): Deleted.
        (JSC::JSWeakSet::JSWeakSet): Deleted.
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        * runtime/WeakMapBase.cpp: Renamed from Source/JavaScriptCore/runtime/WeakMapData.cpp.
        (JSC::WeakMapBase::WeakMapBase):
        (JSC::WeakMapBase::destroy):
        (JSC::WeakMapBase::estimatedSize):
        (JSC::WeakMapBase::visitChildren):
        (JSC::WeakMapBase::set):
        (JSC::WeakMapBase::get):
        (JSC::WeakMapBase::remove):
        (JSC::WeakMapBase::contains):
        (JSC::WeakMapBase::clear):
        (JSC::WeakMapBase::DeadKeyCleaner::target):
        (JSC::WeakMapBase::DeadKeyCleaner::visitWeakReferences):
        (JSC::WeakMapBase::DeadKeyCleaner::finalizeUnconditionally):
        * runtime/WeakMapBase.h: Renamed from Source/JavaScriptCore/runtime/WeakMapData.h.
        (JSC::WeakMapBase::size const):
        * runtime/WeakMapPrototype.cpp:
        (JSC::getWeakMap):
        (JSC::protoFuncWeakMapDelete):
        (JSC::protoFuncWeakMapGet):
        (JSC::protoFuncWeakMapHas):
        (JSC::protoFuncWeakMapSet):
        (JSC::getWeakMapData): Deleted.
        * runtime/WeakSetPrototype.cpp:
        (JSC::getWeakSet):
        (JSC::protoFuncWeakSetDelete):
        (JSC::protoFuncWeakSetHas):
        (JSC::protoFuncWeakSetAdd):
        (JSC::getWeakMapData): Deleted.

2017-08-25  Daniel Bates  <dabates@apple.com>

        Demarcate code added due to lack of NSDMI for aggregates
        https://bugs.webkit.org/show_bug.cgi?id=175990

        Reviewed by Andy Estes.

        * domjit/DOMJITEffect.h:
        (JSC::DOMJIT::Effect::Effect):
        (JSC::DOMJIT::Effect::forWrite):
        (JSC::DOMJIT::Effect::forRead):
        (JSC::DOMJIT::Effect::forReadWrite):
        (JSC::DOMJIT::Effect::forPure):
        (JSC::DOMJIT::Effect::forDef):
        * runtime/HasOwnPropertyCache.h:
        (JSC::HasOwnPropertyCache::Entry::Entry):
        (JSC::HasOwnPropertyCache::Entry::operator=): Deleted.
        * wasm/WasmFormat.h: Modernize some of the code while I am here. Also
        make some comments read well.
        (JSC::Wasm::CallableFunction::CallableFunction):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::WebAssemblyFunction::WebAssemblyFunction):
        * wasm/js/WebAssemblyWrapperFunction.cpp:
        (JSC::WebAssemblyWrapperFunction::create):

2017-08-25  Saam Barati  <sbarati@apple.com>

        Unreviewed. Fix 32-bit after r221196

        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_catch):

2017-08-25  Chris Dumez  <cdumez@apple.com>

        Land stubs for File and Directory Entries API interfaces
        https://bugs.webkit.org/show_bug.cgi?id=175993
        <rdar://problem/34087477>

        Reviewed by Ryosuke Niwa.

        Add CommonIdentifiers needed for [EnabledAtRuntime].

        * runtime/CommonIdentifiers.h:

2017-08-25  Brian Burg  <bburg@apple.com>

        Web Automation: add capabilities to control ICE candidate filtering and insecure media capture
        https://bugs.webkit.org/show_bug.cgi?id=175563
        <rdar://problem/33734492>

        Reviewed by Joseph Pecoraro.

        Add macros for new capability protocol string names. Let's use a reverse
        domain name notification for these capabilities so we know whether they are
        intended for a particular client/port or any WebKit client, and what feature they
        are related to (i.e., webrtc).

        * inspector/remote/RemoteInspectorConstants.h:

2017-08-24  Brian Burg  <bburg@apple.com>

        Web Automation: use automation session configurations to propagate per-session settings
        https://bugs.webkit.org/show_bug.cgi?id=175562
        <rdar://problem/30853362>

        Reviewed by Joseph Pecoraro.

        Add a Cocoa-specific code path to forward capabilities when requesting
        a new session from the remote inspector (i.e., automation) client.

        If other ports want to use this, then we can convert Cocoa types to WebKit types later.

        * inspector/remote/RemoteInspector.h:
        * inspector/remote/RemoteInspectorConstants.h:
        * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
        (Inspector::RemoteInspector::receivedAutomationSessionRequestMessage):

2017-08-25  Saam Barati  <sbarati@apple.com>

        DFG::JITCode::osrEntry should get sorted since we perform a binary search on it
        https://bugs.webkit.org/show_bug.cgi?id=175893

        Reviewed by Mark Lam.

        * dfg/DFGJITCode.cpp:
        (JSC::DFG::JITCode::finalizeOSREntrypoints):
        * dfg/DFGJITCode.h:
        (JSC::DFG::JITCode::finalizeCatchOSREntrypoints): Deleted.
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::linkOSREntries):

2017-08-25  Saam Barati  <sbarati@apple.com>

        Support compiling catch in the DFG
        https://bugs.webkit.org/show_bug.cgi?id=174590
        <rdar://problem/34047845>

        Reviewed by Filip Pizlo.

        This patch implements OSR entry into op_catch in the DFG. We will support OSR entry
        into the FTL in a followup: https://bugs.webkit.org/show_bug.cgi?id=175396
        
        To implement catch in the DFG, this patch introduces the concept of multiple
        entrypoints into CPS/LoadStore DFG IR. A lot of this patch is stringing this concept
        through the DFG. Many phases used to assume that Graph::block(0) is the only root, and this
        patch contains many straight forward changes generalizing the code to handle more than
        one entrypoint.
        
        A main building block of this is moving to two CFG types: SSACFG and CPSCFG. SSACFG
        is the same CFG we used to have. CPSCFG is a new type that introduces a fake root
        that has an outgoing edge to all the entrypoints. This allows our existing graph algorithms
        to Just Work over CPSCFG. For example, there is now the concept of SSADominators vs CPSDominators,
        and SSANaturalLoops vs CPSNaturalLoops.
        
        The way we compile the catch entrypoint is by bootstrapping the state
        of the program by loading all live bytecode locals from a buffer. The OSR
        entry code will store all live values into that buffer before jumping to
        the entrypoint. The OSR entry code is also responsible for performing type
        proofs of the arguments before doing an OSR entry. If there is a type
        mismatch, it's not legal to OSR enter into the DFG compilation. Currently,
        each catch entrypoint knows the argument type proofs it must perform to enter
        into the DFG. Currently, all entrypoints' arguments flush format are unified
        via ArgumentPosition, but this is just an implementation detail. The code is
        written more generally to assume that each entrypoint may perform its own distinct
        proof.
        
        op_catch now performs value profiling for all live bytecode locals in the
        LLInt and baseline JIT. This information is then fed into the DFG via the
        ExtractCatchLocal node in the prediction propagation phase.
        
        This patch also changes how we generate op_catch in bytecode. All op_catches
        are now split out at the end of the program in bytecode. This ensures that
        no op_catch is inside a try block. This is needed to ensure correctness in
        the DFGLiveCatchVariablePreservationPhase. That phase only inserts flushes
        before SetLocals inside a try block. If an op_catch were in a try block, this
        would cause the phase to insert a Flush before one of the state bootstrapping
        SetLocals, which would generate invalid IR. Moving op_catch to be generated on
        its own at the end of a bytecode stream seemed like the most elegant solution since
        it better represents that we treat op_catch as an entrypoint. This is true
        both in the DFG and in the baseline and LLInt: we don't reach an op_catch
        via normal control flow. Because op_catch cannot throw, this will not break
        any previous semantics of op_catch. Logically, it'd be valid to split try
        blocks around any non-throwing bytecode operation.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/BytecodeDumper.cpp:
        (JSC::BytecodeDumper<Block>::dumpBytecode):
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffset):
        (JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
        (JSC::CodeBlock::validate):
        * bytecode/CodeBlock.h:
        * bytecode/ValueProfile.h:
        (JSC::ValueProfile::ValueProfile):
        (JSC::ValueProfileAndOperandBuffer::ValueProfileAndOperandBuffer):
        (JSC::ValueProfileAndOperandBuffer::~ValueProfileAndOperandBuffer):
        (JSC::ValueProfileAndOperandBuffer::forEach):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitCatch):
        (JSC::BytecodeGenerator::emitEnumeration):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::TryNode::emitBytecode):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGBackwardsCFG.h:
        (JSC::DFG::BackwardsCFG::BackwardsCFG):
        * dfg/DFGBasicBlock.cpp:
        (JSC::DFG::BasicBlock::BasicBlock):
        * dfg/DFGBasicBlock.h:
        (JSC::DFG::BasicBlock::findTerminal const):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::setDirect):
        (JSC::DFG::ByteCodeParser::flush):
        (JSC::DFG::ByteCodeParser::DelayedSetLocal::DelayedSetLocal):
        (JSC::DFG::ByteCodeParser::DelayedSetLocal::execute):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::parseCodeBlock):
        (JSC::DFG::ByteCodeParser::parse):
        * dfg/DFGCFG.h:
        (JSC::DFG::CFG::root):
        (JSC::DFG::CFG::roots):
        (JSC::DFG::CPSCFG::CPSCFG):
        (JSC::DFG::selectCFG):
        * dfg/DFGCPSRethreadingPhase.cpp:
        (JSC::DFG::CPSRethreadingPhase::specialCaseArguments):
        * dfg/DFGCSEPhase.cpp:
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGControlEquivalenceAnalysis.h:
        (JSC::DFG::ControlEquivalenceAnalysis::ControlEquivalenceAnalysis):
        * dfg/DFGDCEPhase.cpp:
        (JSC::DFG::DCEPhase::run):
        * dfg/DFGDisassembler.cpp:
        (JSC::DFG::Disassembler::createDumpList):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGDominators.h:
        (JSC::DFG::Dominators::Dominators):
        (JSC::DFG::ensureDominatorsForCFG):
        * dfg/DFGEdgeDominates.h:
        (JSC::DFG::EdgeDominates::EdgeDominates):
        (JSC::DFG::EdgeDominates::operator()):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::fixupChecksInBlock):
        * dfg/DFGFlushFormat.h:
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::Graph):
        (JSC::DFG::unboxLoopNode):
        (JSC::DFG::Graph::dumpBlockHeader):
        (JSC::DFG::Graph::dump):
        (JSC::DFG::Graph::determineReachability):
        (JSC::DFG::Graph::invalidateCFG):
        (JSC::DFG::Graph::blocksInPreOrder):
        (JSC::DFG::Graph::blocksInPostOrder):
        (JSC::DFG::Graph::ensureCPSDominators):
        (JSC::DFG::Graph::ensureSSADominators):
        (JSC::DFG::Graph::ensureCPSNaturalLoops):
        (JSC::DFG::Graph::ensureSSANaturalLoops):
        (JSC::DFG::Graph::ensureBackwardsCFG):
        (JSC::DFG::Graph::ensureBackwardsDominators):
        (JSC::DFG::Graph::ensureControlEquivalenceAnalysis):
        (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
        (JSC::DFG::Graph::clearCPSCFGData):
        (JSC::DFG::Graph::ensureDominators): Deleted.
        (JSC::DFG::Graph::ensurePrePostNumbering): Deleted.
        (JSC::DFG::Graph::ensureNaturalLoops): Deleted.
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::willCatchExceptionInMachineFrame):
        (JSC::DFG::Graph::isEntrypoint const):
        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::InPlaceAbstractState::initialize):
        (JSC::DFG::InPlaceAbstractState::mergeToSuccessors):
        * dfg/DFGJITCode.cpp:
        (JSC::DFG::JITCode::shrinkToFit):
        * dfg/DFGJITCode.h:
        (JSC::DFG::JITCode::catchOSREntryDataForBytecodeIndex):
        (JSC::DFG::JITCode::finalizeCatchOSREntrypoints):
        (JSC::DFG::JITCode::appendCatchEntrypoint):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        (JSC::DFG::JITCompiler::noticeCatchEntrypoint):
        (JSC::DFG::JITCompiler::noticeOSREntry):
        (JSC::DFG::JITCompiler::makeCatchOSREntryBuffer):
        * dfg/DFGJITCompiler.h:
        * dfg/DFGLICMPhase.cpp:
        (JSC::DFG::LICMPhase::run):
        (JSC::DFG::LICMPhase::attemptHoist):
        * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
        (JSC::DFG::LiveCatchVariablePreservationPhase::run):
        (JSC::DFG::LiveCatchVariablePreservationPhase::isValidFlushLocation):
        (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch):
        (JSC::DFG::LiveCatchVariablePreservationPhase::newVariableAccessData):
        (JSC::DFG::LiveCatchVariablePreservationPhase::willCatchException): Deleted.
        (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlock): Deleted.
        * dfg/DFGLoopPreHeaderCreationPhase.cpp:
        (JSC::DFG::createPreHeader):
        (JSC::DFG::LoopPreHeaderCreationPhase::run):
        * dfg/DFGMaximalFlushInsertionPhase.cpp:
        (JSC::DFG::MaximalFlushInsertionPhase::run):
        (JSC::DFG::MaximalFlushInsertionPhase::treatRegularBlock):
        (JSC::DFG::MaximalFlushInsertionPhase::treatRootBlock):
        * dfg/DFGMayExit.cpp:
        * dfg/DFGNaturalLoops.h:
        (JSC::DFG::NaturalLoops::NaturalLoops):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::isSwitch const):
        (JSC::DFG::Node::successor):
        (JSC::DFG::Node::catchOSREntryIndex const):
        (JSC::DFG::Node::catchLocalPrediction):
        (JSC::DFG::Node::isSwitch): Deleted.
        * dfg/DFGNodeType.h:
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareCatchOSREntry):
        * dfg/DFGOSREntry.h:
        * dfg/DFGOSREntrypointCreationPhase.cpp:
        (JSC::DFG::OSREntrypointCreationPhase::run):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::handleExitCounts):
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGPrePostNumbering.cpp:
        (JSC::DFG::PrePostNumbering::PrePostNumbering): Deleted.
        (JSC::DFG::PrePostNumbering::~PrePostNumbering): Deleted.
        (WTF::printInternal): Deleted.
        * dfg/DFGPrePostNumbering.h:
        (): Deleted.
        (JSC::DFG::PrePostNumbering::preNumber const): Deleted.
        (JSC::DFG::PrePostNumbering::postNumber const): Deleted.
        (JSC::DFG::PrePostNumbering::isStrictAncestorOf const): Deleted.
        (JSC::DFG::PrePostNumbering::isAncestorOf const): Deleted.
        (JSC::DFG::PrePostNumbering::isStrictDescendantOf const): Deleted.
        (JSC::DFG::PrePostNumbering::isDescendantOf const): Deleted.
        (JSC::DFG::PrePostNumbering::edgeKind const): Deleted.
        * dfg/DFGPredictionInjectionPhase.cpp:
        (JSC::DFG::PredictionInjectionPhase::run):
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGPutStackSinkingPhase.cpp:
        * dfg/DFGSSACalculator.cpp:
        (JSC::DFG::SSACalculator::nonLocalReachingDef):
        (JSC::DFG::SSACalculator::reachingDefAtTail):
        * dfg/DFGSSACalculator.h:
        (JSC::DFG::SSACalculator::computePhis):
        * dfg/DFGSSAConversionPhase.cpp:
        (JSC::DFG::SSAConversionPhase::run):
        (JSC::DFG::performSSAConversion):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
        (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
        (JSC::DFG::SpeculativeJIT::createOSREntries):
        (JSC::DFG::SpeculativeJIT::linkOSREntries):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStaticExecutionCountEstimationPhase.cpp:
        (JSC::DFG::StaticExecutionCountEstimationPhase::run):
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        * dfg/DFGTierUpCheckInjectionPhase.cpp:
        (JSC::DFG::TierUpCheckInjectionPhase::run):
        (JSC::DFG::TierUpCheckInjectionPhase::buildNaturalLoopToLoopHintMap):
        * dfg/DFGTypeCheckHoistingPhase.cpp:
        (JSC::DFG::TypeCheckHoistingPhase::run):
        * dfg/DFGValidate.cpp:
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::lower):
        (JSC::FTL::DFG::LowerDFGToB3::safelyInvalidateAfterTermination):
        (JSC::FTL::DFG::LowerDFGToB3::isValid):
        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_catch):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_catch):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

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

        Explore increasing max JSString::m_length to UINT_MAX.
        https://bugs.webkit.org/show_bug.cgi?id=163955
        <rdar://problem/32001499>

        Reviewed by JF Bastien.

        This can cause us to release assert on some code paths. I don't
        see a reason to maintain this restriction.

        * runtime/JSString.h:
        (JSC::JSString::length const):
        (JSC::JSString::setLength):
        (JSC::JSString::isValidLength): Deleted.
        * runtime/JSStringBuilder.h:
        (JSC::jsMakeNontrivialString):

2017-08-24  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r221119, r221124, and r221143.
        https://bugs.webkit.org/show_bug.cgi?id=175973

        "I think it regressed JSBench by 20%" (Requested by saamyjoon
        on #webkit).

        Reverted changesets:

        "Support compiling catch in the DFG"
        https://bugs.webkit.org/show_bug.cgi?id=174590
        http://trac.webkit.org/changeset/221119

        "Unreviewed, build fix in GTK port"
        https://bugs.webkit.org/show_bug.cgi?id=174590
        http://trac.webkit.org/changeset/221124

        "DFG::JITCode::osrEntry should get sorted since we perform a
        binary search on it"
        https://bugs.webkit.org/show_bug.cgi?id=175893
        http://trac.webkit.org/changeset/221143

2017-08-24  Michael Saboff  <msaboff@apple.com>

        Enable moving fixed character class terms after fixed character terms for BMP only character classes
        https://bugs.webkit.org/show_bug.cgi?id=175958

        Reviewed by Saam Barati.

        Currently we don't perform the reordering optimiaztion of fixed character terms that
        follow fixed character class terms for Unicode patterns.

        This change allows that reordering when the character class contains only BMP
        characters.

        This fix is covered by existing tests.

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

2017-08-24  Michael Saboff  <msaboff@apple.com>

        Add support for RegExp "dotAll" flag
        https://bugs.webkit.org/show_bug.cgi?id=175924

        Reviewed by Keith Miller.

        The dotAll RegExp flag, 's', changes . to match any character including line terminators.
        Added a the "dotAll" identifier as well as RegExp.prototype.dotAll getter.
        Added a new any character CharacterClass that is used to match . terms in a dotAll flags
        RegExp.  In the YARR pattern and parsing code, changed the NewlineClassID, which was only
        used for '.' processing, to DotClassID.  The selection of which builtin character class
        that DotClassID resolves to when generating the pattern is conditional on the dotAll flag.
        This NewlineClassID to DotClassID refactoring includes the atomBuiltInCharacterClass() in
        the WebCore content extensions code in the PatternParser class.

        As an optimization, the Yarr JIT actually doesn't perform match checks against the builtin
        any character CharacterClass, it merely reads the character.  There is another optimization
        in our DotStart enclosure processing where a non-capturing regular expression in the form
        of .*<expression.*, with options beginning ^ and/or trailing $, match the contained
        expression and then look for the extents of the surrounding .*'s.  When used with the
        dotAll flag, that processing alwys results with the beinning of the string and the end
        of the string.  Therefore we short circuit the finding the beginning and end of the line
        or string with dotAll patterns.

        * bytecode/BytecodeDumper.cpp:
        (JSC::regexpToSourceString):
        * runtime/CommonIdentifiers.h:
        * runtime/RegExp.cpp:
        (JSC::regExpFlags):
        (JSC::RegExpFunctionalTestCollector::outputOneTest):
        * runtime/RegExp.h:
        * runtime/RegExpKey.h:
        * runtime/RegExpPrototype.cpp:
        (JSC::RegExpPrototype::finishCreation):
        (JSC::flagsString):
        (JSC::regExpProtoGetterDotAll):
        * yarr/YarrInterpreter.cpp:
        (JSC::Yarr::Interpreter::matchDotStarEnclosure):
        * yarr/YarrInterpreter.h:
        (JSC::Yarr::BytecodePattern::dotAll const):
        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::optimizeAlternative):
        (JSC::Yarr::YarrGenerator::generateCharacterClassOnce):
        (JSC::Yarr::YarrGenerator::generateCharacterClassFixed):
        (JSC::Yarr::YarrGenerator::generateCharacterClassGreedy):
        (JSC::Yarr::YarrGenerator::backtrackCharacterClassNonGreedy):
        (JSC::Yarr::YarrGenerator::generateDotStarEnclosure):
        * yarr/YarrParser.h:
        (JSC::Yarr::Parser::parseTokens):
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::YarrPatternConstructor::atomBuiltInCharacterClass):
        (JSC::Yarr::YarrPatternConstructor::atomCharacterClassBuiltIn):
        (JSC::Yarr::YarrPatternConstructor::optimizeDotStarWrappedExpressions):
        (JSC::Yarr::YarrPattern::YarrPattern):
        (JSC::Yarr::PatternTerm::dump):
        (JSC::Yarr::anycharCreate):
        * yarr/YarrPattern.h:
        (JSC::Yarr::YarrPattern::reset):
        (JSC::Yarr::YarrPattern::anyCharacterClass):
        (JSC::Yarr::YarrPattern::dotAll const):

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

        Reduce Gigacage sizes
        https://bugs.webkit.org/show_bug.cgi?id=175920

        Reviewed by Mark Lam.

        Teach all of the code generators to use the right gigacage masks.

        Also teach Wasm that it has much less memory for signaling memories. With 32GB, we have room for 7 signaling memories. But if
        we actually did that, then we'd have no memory left for anything else. So, this caps us at 4 signaling memories.

        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::caged):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::cage):
        (JSC::AssemblyHelpers::cageConditionally):
        * llint/LowLevelInterpreter64.asm:
        * runtime/Options.h:

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

        DFG::JITCode::osrEntry should get sorted since we perform a binary search on it
        https://bugs.webkit.org/show_bug.cgi?id=175893

        Reviewed by Mark Lam.

        * dfg/DFGJITCode.cpp:
        (JSC::DFG::JITCode::finalizeOSREntrypoints):
        * dfg/DFGJITCode.h:
        (JSC::DFG::JITCode::finalizeCatchOSREntrypoints): Deleted.
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::linkOSREntries):

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

        Fix Titzer bench on iOS.
        https://bugs.webkit.org/show_bug.cgi?id=175917

        Reviewed by Ryosuke Niwa.

        Currently, Titzer bench doesn't run on iOS since the benchmark
        allocates lots of physical pages that it never actually writes
        to. We limited the total number wasm physical pages to the ram
        size of the phone, which caused us to fail a memory
        allocation. This patch changes it so we will allocate up to 3x ram
        size, which seems to fix the problem.

        * wasm/WasmMemory.cpp:

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

        Unreviewed, fix for test262
        https://bugs.webkit.org/show_bug.cgi?id=175915

        * runtime/MapPrototype.cpp:
        (JSC::MapPrototype::finishCreation):
        * runtime/SetPrototype.cpp:
        (JSC::SetPrototype::finishCreation):

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

        Unreviewed, build fix in GTK port
        https://bugs.webkit.org/show_bug.cgi?id=174590

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

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

        Support compiling catch in the DFG
        https://bugs.webkit.org/show_bug.cgi?id=174590

        Reviewed by Filip Pizlo.

        This patch implements OSR entry into op_catch in the DFG. We will support OSR entry
        into the FTL in a followup: https://bugs.webkit.org/show_bug.cgi?id=175396
        
        To implement catch in the DFG, this patch introduces the concept of multiple
        entrypoints into CPS/LoadStore DFG IR. A lot of this patch is stringing this concept
        through the DFG. Many phases used to assume that Graph::block(0) is the only root, and this
        patch contains many straight forward changes generalizing the code to handle more than
        one entrypoint.
        
        A main building block of this is moving to two CFG types: SSACFG and CPSCFG. SSACFG
        is the same CFG we used to have. CPSCFG is a new type that introduces a fake root
        that has an outgoing edge to all the entrypoints. This allows our existing graph algorithms
        to Just Work over CPSCFG. For example, there is now the concept of SSADominators vs CPSDominators,
        and SSANaturalLoops vs CPSNaturalLoops.
        
        The way we compile the catch entrypoint is by bootstrapping the state
        of the program by loading all live bytecode locals from a buffer. The OSR
        entry code will store all live values into that buffer before jumping to
        the entrypoint. The OSR entry code is also responsible for performing type
        proofs of the arguments before doing an OSR entry. If there is a type
        mismatch, it's not legal to OSR enter into the DFG compilation. Currently,
        each catch entrypoint knows the argument type proofs it must perform to enter
        into the DFG. Currently, all entrypoints' arguments flush format are unified
        via ArgumentPosition, but this is just an implementation detail. The code is
        written more generally to assume that each entrypoint may perform its own distinct
        proof.
        
        op_catch now performs value profiling for all live bytecode locals in the
        LLInt and baseline JIT. This information is then fed into the DFG via the
        ExtractCatchLocal node in the prediction propagation phase.
        
        This patch also changes how we generate op_catch in bytecode. All op_catches
        are now split out at the end of the program in bytecode. This ensures that
        no op_catch is inside a try block. This is needed to ensure correctness in
        the DFGLiveCatchVariablePreservationPhase. That phase only inserts flushes
        before SetLocals inside a try block. If an op_catch were in a try block, this
        would cause the phase to insert a Flush before one of the state bootstrapping
        SetLocals, which would generate invalid IR. Moving op_catch to be generated on
        its own at the end of a bytecode stream seemed like the most elegant solution since
        it better represents that we treat op_catch as an entrypoint. This is true
        both in the DFG and in the baseline and LLInt: we don't reach an op_catch
        via normal control flow. Because op_catch cannot throw, this will not break
        any previous semantics of op_catch. Logically, it'd be valid to split try
        blocks around any non-throwing bytecode operation.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/BytecodeDumper.cpp:
        (JSC::BytecodeDumper<Block>::dumpBytecode):
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
        (JSC::CodeBlock::validate):
        * bytecode/CodeBlock.h:
        * bytecode/ValueProfile.h:
        (JSC::ValueProfile::ValueProfile):
        (JSC::ValueProfileAndOperandBuffer::ValueProfileAndOperandBuffer):
        (JSC::ValueProfileAndOperandBuffer::~ValueProfileAndOperandBuffer):
        (JSC::ValueProfileAndOperandBuffer::forEach):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitCatch):
        (JSC::BytecodeGenerator::emitEnumeration):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::TryNode::emitBytecode):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGBackwardsCFG.h:
        (JSC::DFG::BackwardsCFG::BackwardsCFG):
        * dfg/DFGBasicBlock.cpp:
        (JSC::DFG::BasicBlock::BasicBlock):
        * dfg/DFGBasicBlock.h:
        (JSC::DFG::BasicBlock::findTerminal const):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::setDirect):
        (JSC::DFG::ByteCodeParser::flush):
        (JSC::DFG::ByteCodeParser::DelayedSetLocal::DelayedSetLocal):
        (JSC::DFG::ByteCodeParser::DelayedSetLocal::execute):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::parseCodeBlock):
        (JSC::DFG::ByteCodeParser::parse):
        * dfg/DFGCFG.h:
        (JSC::DFG::CFG::root):
        (JSC::DFG::CFG::roots):
        (JSC::DFG::CPSCFG::CPSCFG):
        (JSC::DFG::selectCFG):
        * dfg/DFGCPSRethreadingPhase.cpp:
        (JSC::DFG::CPSRethreadingPhase::specialCaseArguments):
        * dfg/DFGCSEPhase.cpp:
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGControlEquivalenceAnalysis.h:
        (JSC::DFG::ControlEquivalenceAnalysis::ControlEquivalenceAnalysis):
        * dfg/DFGDCEPhase.cpp:
        (JSC::DFG::DCEPhase::run):
        * dfg/DFGDisassembler.cpp:
        (JSC::DFG::Disassembler::createDumpList):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGDominators.h:
        (JSC::DFG::Dominators::Dominators):
        (JSC::DFG::ensureDominatorsForCFG):
        * dfg/DFGEdgeDominates.h:
        (JSC::DFG::EdgeDominates::EdgeDominates):
        (JSC::DFG::EdgeDominates::operator()):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::fixupChecksInBlock):
        * dfg/DFGFlushFormat.h:
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::Graph):
        (JSC::DFG::unboxLoopNode):
        (JSC::DFG::Graph::dumpBlockHeader):
        (JSC::DFG::Graph::dump):
        (JSC::DFG::Graph::determineReachability):
        (JSC::DFG::Graph::invalidateCFG):
        (JSC::DFG::Graph::blocksInPreOrder):
        (JSC::DFG::Graph::blocksInPostOrder):
        (JSC::DFG::Graph::ensureCPSDominators):
        (JSC::DFG::Graph::ensureSSADominators):
        (JSC::DFG::Graph::ensureCPSNaturalLoops):
        (JSC::DFG::Graph::ensureSSANaturalLoops):
        (JSC::DFG::Graph::ensureBackwardsCFG):
        (JSC::DFG::Graph::ensureBackwardsDominators):
        (JSC::DFG::Graph::ensureControlEquivalenceAnalysis):
        (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
        (JSC::DFG::Graph::clearCPSCFGData):
        (JSC::DFG::Graph::ensureDominators): Deleted.
        (JSC::DFG::Graph::ensurePrePostNumbering): Deleted.
        (JSC::DFG::Graph::ensureNaturalLoops): Deleted.
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::willCatchExceptionInMachineFrame):
        (JSC::DFG::Graph::isEntrypoint const):
        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::InPlaceAbstractState::initialize):
        (JSC::DFG::InPlaceAbstractState::mergeToSuccessors):
        * dfg/DFGJITCode.cpp:
        (JSC::DFG::JITCode::shrinkToFit):
        * dfg/DFGJITCode.h:
        (JSC::DFG::JITCode::catchOSREntryDataForBytecodeIndex):
        (JSC::DFG::JITCode::finalizeCatchOSREntrypoints):
        (JSC::DFG::JITCode::appendCatchEntrypoint):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        (JSC::DFG::JITCompiler::noticeCatchEntrypoint):
        (JSC::DFG::JITCompiler::noticeOSREntry):
        (JSC::DFG::JITCompiler::makeCatchOSREntryBuffer):
        * dfg/DFGJITCompiler.h:
        * dfg/DFGLICMPhase.cpp:
        (JSC::DFG::LICMPhase::run):
        (JSC::DFG::LICMPhase::attemptHoist):
        * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
        (JSC::DFG::LiveCatchVariablePreservationPhase::run):
        (JSC::DFG::LiveCatchVariablePreservationPhase::isValidFlushLocation):
        (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch):
        (JSC::DFG::LiveCatchVariablePreservationPhase::newVariableAccessData):
        (JSC::DFG::LiveCatchVariablePreservationPhase::willCatchException): Deleted.
        (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlock): Deleted.
        * dfg/DFGLoopPreHeaderCreationPhase.cpp:
        (JSC::DFG::createPreHeader):
        (JSC::DFG::LoopPreHeaderCreationPhase::run):
        * dfg/DFGMaximalFlushInsertionPhase.cpp:
        (JSC::DFG::MaximalFlushInsertionPhase::run):
        (JSC::DFG::MaximalFlushInsertionPhase::treatRegularBlock):
        (JSC::DFG::MaximalFlushInsertionPhase::treatRootBlock):
        * dfg/DFGMayExit.cpp:
        * dfg/DFGNaturalLoops.h:
        (JSC::DFG::NaturalLoops::NaturalLoops):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::isSwitch const):
        (JSC::DFG::Node::successor):
        (JSC::DFG::Node::catchOSREntryIndex const):
        (JSC::DFG::Node::catchLocalPrediction):
        (JSC::DFG::Node::isSwitch): Deleted.
        * dfg/DFGNodeType.h:
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareCatchOSREntry):
        * dfg/DFGOSREntry.h:
        * dfg/DFGOSREntrypointCreationPhase.cpp:
        (JSC::DFG::OSREntrypointCreationPhase::run):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::handleExitCounts):
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGPrePostNumbering.cpp:
        (JSC::DFG::PrePostNumbering::PrePostNumbering): Deleted.
        (JSC::DFG::PrePostNumbering::~PrePostNumbering): Deleted.
        (WTF::printInternal): Deleted.
        * dfg/DFGPrePostNumbering.h:
        (): Deleted.
        (JSC::DFG::PrePostNumbering::preNumber const): Deleted.
        (JSC::DFG::PrePostNumbering::postNumber const): Deleted.
        (JSC::DFG::PrePostNumbering::isStrictAncestorOf const): Deleted.
        (JSC::DFG::PrePostNumbering::isAncestorOf const): Deleted.
        (JSC::DFG::PrePostNumbering::isStrictDescendantOf const): Deleted.
        (JSC::DFG::PrePostNumbering::isDescendantOf const): Deleted.
        (JSC::DFG::PrePostNumbering::edgeKind const): Deleted.
        * dfg/DFGPredictionInjectionPhase.cpp:
        (JSC::DFG::PredictionInjectionPhase::run):
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGPutStackSinkingPhase.cpp:
        * dfg/DFGSSACalculator.cpp:
        (JSC::DFG::SSACalculator::nonLocalReachingDef):
        (JSC::DFG::SSACalculator::reachingDefAtTail):
        * dfg/DFGSSACalculator.h:
        (JSC::DFG::SSACalculator::computePhis):
        * dfg/DFGSSAConversionPhase.cpp:
        (JSC::DFG::SSAConversionPhase::run):
        (JSC::DFG::performSSAConversion):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
        (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
        (JSC::DFG::SpeculativeJIT::createOSREntries):
        (JSC::DFG::SpeculativeJIT::linkOSREntries):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStaticExecutionCountEstimationPhase.cpp:
        (JSC::DFG::StaticExecutionCountEstimationPhase::run):
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        * dfg/DFGTierUpCheckInjectionPhase.cpp:
        (JSC::DFG::TierUpCheckInjectionPhase::run):
        (JSC::DFG::TierUpCheckInjectionPhase::buildNaturalLoopToLoopHintMap):
        * dfg/DFGTypeCheckHoistingPhase.cpp:
        (JSC::DFG::TypeCheckHoistingPhase::run):
        * dfg/DFGValidate.cpp:
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::lower):
        (JSC::FTL::DFG::LowerDFGToB3::safelyInvalidateAfterTermination):
        (JSC::FTL::DFG::LowerDFGToB3::isValid):
        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_catch):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_catch):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

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

        Unreviewed, debug build fix
        https://bugs.webkit.org/show_bug.cgi?id=174355

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

2017-08-23  Michael Saboff  <msaboff@apple.com>

        REGRESSION (r221052): DumpRenderTree crashed in com.apple.JavaScriptCore: JSC::Yarr::YarrCodeBlock::execute + 137
        https://bugs.webkit.org/show_bug.cgi?id=175903

        Reviewed by Saam Barati.

        In generateCharacterClassGreedy we were incrementing the "count" register before checking
        for the end of the input string.  The at-end-of-input check is the final check before
        knowing that the current character matched.  In this case, the end of input check
        indicates that we ran out of prechecked characters and therefore should fail the match of
        the current character.  The backtracking code uses the value in the "count" register as
        the number of character that successfully matched, which shouldn't include the current
        character.  Therefore we need to move the incrementing of "count" to after the
        at end of input check.

        Through code inspection of the expectations of other backtracking code, I determined that 
        the non greedy character class matching code had a similar issue.  I fixed that as well
        and added a new test case.

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

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

        [JSC] Optimize Map iteration with intrinsic
        https://bugs.webkit.org/show_bug.cgi?id=174355

        Reviewed by Saam Barati.

        This patch optimizes Map/Set iteration by taking the approach similar to Array iteration.
        We create a simple iterator object instead of JSMapIterator and JSSetIterator. And we
        directly handles Map/Set buckets in JS builtins. We carefully create mapIteratorNext and
        setIteratorNext functions which should be inlined. This leads significant performance boost
        when they are inlined in for-of iteration.

        This patch changes how DFG and FTL handles MapBucket if the bucket is not found.
        Previously, we use nullptr for that, and DFG and FTL specially handle this nullptr as bucket.
        Instead, this patch introduces sentinel buckets. They are marked as deleted, and not linked
        to any hash maps. And its key and value fields are filled with Undefined. By returning this
        sentinel bucket instead of returning nullptr, we simplify DFG and FTL's LoadXXXFromMapBucket
        code.

        We still keep JSMapIterator and JSSetIterator because they are useful to serialize Map and Set
        in WebCore. So they are not used in user observable JS. We change them from JS objects to JS cells.

        Existing microbenchmarks shows performance improvements.

        large-map-iteration                           164.1622+-4.1618     ^     56.6284+-1.5355        ^ definitely 2.8989x faster
        set-for-of                                     15.4369+-1.0631     ^      9.2955+-0.5979        ^ definitely 1.6607x faster
        map-for-each                                    7.5889+-0.5792     ^      6.3011+-0.4816        ^ definitely 1.2044x faster
        map-for-of                                     32.3904+-1.3003     ^     12.6907+-0.6118        ^ definitely 2.5523x faster
        map-rehash                                     13.9275+-0.9187     ^     11.5367+-0.6430        ^ definitely 1.2072x faster

        * CMakeLists.txt:
        * DerivedSources.make:
        * builtins/ArrayPrototype.js:
        (globalPrivate.createArrayIterator):
        * builtins/BuiltinNames.h:
        * builtins/MapIteratorPrototype.js: Copied from Source/JavaScriptCore/builtins/MapPrototype.js.
        (globalPrivate.mapIteratorNext):
        (next):
        * builtins/MapPrototype.js:
        (globalPrivate.createMapIterator):
        (values):
        (keys):
        (entries):
        (forEach):
        * builtins/SetIteratorPrototype.js: Copied from Source/JavaScriptCore/builtins/MapPrototype.js.
        (globalPrivate.setIteratorNext):
        (next):
        * builtins/SetPrototype.js:
        (globalPrivate.createSetIterator):
        (values):
        (entries):
        (forEach):
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecode/SpeculatedType.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/DFGHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGHeapLocation.h:
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasHeapPrediction):
        (JSC::DFG::Node::hasBucketOwnerType):
        (JSC::DFG::Node::bucketOwnerType):
        (JSC::DFG::Node::OpInfoWrapper::as const):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetMapBucketHead):
        (JSC::DFG::SpeculativeJIT::compileGetMapBucketNext):
        (JSC::DFG::SpeculativeJIT::compileLoadKeyFromMapBucket):
        (JSC::DFG::SpeculativeJIT::compileLoadValueFromMapBucket):
        (JSC::DFG::SpeculativeJIT::compileCompareEqPtr): Deleted.
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compileCompareEqPtr):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compileCompareEqPtr):
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucket):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucketHead):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucketNext):
        (JSC::FTL::DFG::LowerDFGToB3::compileLoadValueFromMapBucket):
        (JSC::FTL::DFG::LowerDFGToB3::compileLoadKeyFromMapBucket):
        (JSC::FTL::DFG::LowerDFGToB3::setStorage):
        (JSC::FTL::DFG::LowerDFGToB3::compileLoadFromJSMapBucket): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::compileIsNonEmptyMapBucket): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::lowMapBucket): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::setMapBucket): Deleted.
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::subtype):
        (Inspector::JSInjectedScriptHost::getInternalProperties):
        (Inspector::cloneMapIteratorObject):
        (Inspector::cloneSetIteratorObject):
        (Inspector::JSInjectedScriptHost::iteratorEntries):
        * runtime/HashMapImpl.h:
        (JSC::HashMapBucket::createSentinel):
        (JSC::HashMapBucket::offsetOfNext):
        (JSC::HashMapBucket::offsetOfDeleted):
        (JSC::HashMapImpl::offsetOfHead):
        * runtime/Intrinsic.cpp:
        (JSC::intrinsicName):
        * runtime/Intrinsic.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObject.h:
        * runtime/JSMap.h:
        * runtime/JSMapIterator.cpp:
        (JSC::JSMapIterator::clone): Deleted.
        * runtime/JSMapIterator.h:
        (JSC::JSMapIterator::iteratedValue const):
        * runtime/JSSet.h:
        * runtime/JSSetIterator.cpp:
        (JSC::JSSetIterator::clone): Deleted.
        * runtime/JSSetIterator.h:
        (JSC::JSSetIterator::iteratedValue const):
        * runtime/MapConstructor.cpp:
        (JSC::mapPrivateFuncMapBucketHead):
        (JSC::mapPrivateFuncMapBucketNext):
        (JSC::mapPrivateFuncMapBucketKey):
        (JSC::mapPrivateFuncMapBucketValue):
        * runtime/MapConstructor.h:
        * runtime/MapIteratorPrototype.cpp:
        (JSC::MapIteratorPrototype::finishCreation):
        (JSC::MapIteratorPrototypeFuncNext): Deleted.
        * runtime/MapPrototype.cpp:
        (JSC::MapPrototype::finishCreation):
        (JSC::mapProtoFuncValues): Deleted.
        (JSC::mapProtoFuncEntries): Deleted.
        (JSC::mapProtoFuncKeys): Deleted.
        (JSC::privateFuncMapIterator): Deleted.
        (JSC::privateFuncMapIteratorNext): Deleted.
        * runtime/MapPrototype.h:
        * runtime/SetConstructor.cpp:
        (JSC::setPrivateFuncSetBucketHead):
        (JSC::setPrivateFuncSetBucketNext):
        (JSC::setPrivateFuncSetBucketKey):
        * runtime/SetConstructor.h:
        * runtime/SetIteratorPrototype.cpp:
        (JSC::SetIteratorPrototype::finishCreation):
        (JSC::SetIteratorPrototypeFuncNext): Deleted.
        * runtime/SetPrototype.cpp:
        (JSC::SetPrototype::finishCreation):
        (JSC::setProtoFuncSize):
        (JSC::setProtoFuncValues): Deleted.
        (JSC::setProtoFuncEntries): Deleted.
        (JSC::privateFuncSetIterator): Deleted.
        (JSC::privateFuncSetIteratorNext): Deleted.
        * runtime/SetPrototype.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2017-08-23  David Kilzer  <ddkilzer@apple.com>

        Fix -Wcast-qual warnings in JavaScriptCore with new clang compiler
        <https://webkit.org/b/175889>
        <rdar://problem/33667497>

        Reviewed by Mark Lam.

        * API/ObjCCallbackFunction.mm:
        (JSC::objCCallbackFunctionCallAsConstructor): Use
        const_cast<JSObjectRef>() since JSValueRef is const while
        JSObjectRef is not.
        * API/tests/CurrentThisInsideBlockGetterTest.mm:
        (+[JSValue valueWithConstructorDescriptor:inContext:]): Use
        const_cast<void*>() since JSObjectMake() takes a void*, but
        CFBridgingRetain() returns const void*.

2017-08-23  Robin Morisset  <rmorisset@apple.com>

        Make GetDynamicVar propagate heap predictions instead of saying HeapTop
        https://bugs.webkit.org/show_bug.cgi?id=175738

        Reviewed by Saam Barati.

        The heap prediction always end up in m_opInfo2. But GetDynamicVar was already storing getPutInfo in there.
        So we move that one into m_opInfo. We can do this because it is 32-bit, and the already present identifierNumber
        is also 32-bit, so we can pack both in m_opInfo (which is 64 bits).

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::makeDynamicVarOpInfo):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::getPutInfo):
        (JSC::DFG::Node::hasHeapPrediction):
        * dfg/DFGPredictionPropagationPhase.cpp:

2017-08-23  Skachkov Oleksandr  <gskachkov@gmail.com>

        [ESNext] Async iteration - Implement Async Generator - runtime
        https://bugs.webkit.org/show_bug.cgi?id=175240

        Reviewed by Yusuke Suzuki.

        Current implementation is draft version of Async Iteration. 
        Link to spec https://tc39.github.io/proposal-async-iteration/
       
        To implement async generator added new states that show reason why async generator was suspended:
        # yield - return promise with result
        # await - wait until promise will be resolved and then continue
       
        The main difference between async function and async generator is that, 
        async function returns promise but async generator returns
        object with methods (next, throw and return) that return promise that 
        can be resolved with pair of properties value and done.
        Async generator functions are similar to generator functions, with the following differences:
        # When called, async generator functions return an object, an async generator 
        whose methods (next, throw, and return) return promises for { value, done }, 
        instead of directly returning { value, done }. 
        This automatically makes the returned async generator objects async iterators.
        # await expressions and for-await-of statements are allowed.
        # The behavior of yield* is modified to support 
          delegation to sync and async iterables

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/AsyncFromSyncIteratorPrototype.js: Added.
        (next.try):
        (next):
        (return.try):
        (return):
        (throw.try):
        (throw):
        (globalPrivate.createAsyncFromSyncIterator):
        (globalPrivate.AsyncFromSyncIteratorConstructor):
        * builtins/AsyncGeneratorPrototype.js: Added.
        (globalPrivate.createAsyncGeneratorQueue):
        (globalPrivate.asyncGeneratorQueueIsEmpty):
        (globalPrivate.asyncGeneratorQueueCreateItem):
        (globalPrivate.asyncGeneratorQueueEnqueue):
        (globalPrivate.asyncGeneratorQueueDequeue):
        (globalPrivate.asyncGeneratorQueueGetFirstValue):
        (globalPrivate.asyncGeneratorDequeue):
        (globalPrivate.isExecutionState):
        (globalPrivate.isSuspendYieldState):
        (globalPrivate.asyncGeneratorReject):
        (globalPrivate.asyncGeneratorResolve):
        (asyncGeneratorYieldAwaited):
        (globalPrivate.asyncGeneratorYield):
        (const.onRejected):
        (globalPrivate.awaitValue):
        (const.onFulfilled):
        (globalPrivate.doAsyncGeneratorBodyCall):
        (globalPrivate.asyncGeneratorResumeNext.):
        (globalPrivate.asyncGeneratorResumeNext):
        (globalPrivate.asyncGeneratorEnqueue):
        (next):
        (return):
        (throw):
        * builtins/AsyncIteratorPrototype.js: Added.
        (symbolAsyncIteratorGetter):
        * builtins/BuiltinNames.h:
        * bytecode/BytecodeDumper.cpp:
        (JSC::BytecodeDumper<Block>::dumpBytecode):
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitCreateAsyncGeneratorQueue):
        (JSC::BytecodeGenerator::emitPutAsyncGeneratorFields):
        (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
        (JSC::BytecodeGenerator::emitNewFunction):
        (JSC::BytecodeGenerator::emitIteratorNextWithValue):
        (JSC::BytecodeGenerator::emitIteratorClose):
        (JSC::BytecodeGenerator::emitYieldPoint):
        (JSC::BytecodeGenerator::emitYield):
        (JSC::BytecodeGenerator::emitCallIterator):
        (JSC::BytecodeGenerator::emitAwait):
        (JSC::BytecodeGenerator::emitGetIterator):
        (JSC::BytecodeGenerator::emitGetAsyncIterator):
        (JSC::BytecodeGenerator::emitDelegateYield):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ReturnNode::emitBytecode):
        (JSC::FunctionNode::emitBytecode):
        (JSC::YieldExprNode::emitBytecode):
        (JSC::AwaitExprNode::emitBytecode):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGClobbersExitState.cpp:
        (JSC::DFG::clobbersExitState):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGMayExit.cpp:
        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToPhantomNewFunction):
        (JSC::DFG::Node::convertToPhantomNewAsyncGeneratorFunction):
        (JSC::DFG::Node::hasCellOperand):
        (JSC::DFG::Node::isFunctionAllocation):
        (JSC::DFG::Node::isPhantomFunctionAllocation):
        (JSC::DFG::Node::isPhantomAllocation):
        * dfg/DFGNodeType.h:
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNewFunction):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStoreBarrierInsertionPhase.cpp:
        * dfg/DFGValidate.cpp:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationPopulateObjectInOSR):
        (JSC::FTL::operationMaterializeObjectInOSR):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emitNewFuncCommon):
        (JSC::JIT::emit_op_new_async_generator_func):
        (JSC::JIT::emit_op_new_async_func):
        (JSC::JIT::emitNewFuncExprCommon):
        (JSC::JIT::emit_op_new_async_generator_func_exp):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createFunctionMetadata):
        * runtime/AsyncFromSyncIteratorPrototype.cpp: Added.
        (JSC::AsyncFromSyncIteratorPrototype::AsyncFromSyncIteratorPrototype):
        (JSC::AsyncFromSyncIteratorPrototype::finishCreation):
        (JSC::AsyncFromSyncIteratorPrototype::create):
        * runtime/AsyncFromSyncIteratorPrototype.h: Added.
        (JSC::AsyncFromSyncIteratorPrototype::createStructure):
        * runtime/AsyncGeneratorFunctionConstructor.cpp: Added.
        (JSC::AsyncGeneratorFunctionConstructor::AsyncGeneratorFunctionConstructor):
        (JSC::AsyncGeneratorFunctionConstructor::finishCreation):
        (JSC::callAsyncGeneratorFunctionConstructor):
        (JSC::constructAsyncGeneratorFunctionConstructor):
        (JSC::AsyncGeneratorFunctionConstructor::getCallData):
        (JSC::AsyncGeneratorFunctionConstructor::getConstructData):
        * runtime/AsyncGeneratorFunctionConstructor.h: Added.
        (JSC::AsyncGeneratorFunctionConstructor::create):
        (JSC::AsyncGeneratorFunctionConstructor::createStructure):
        * runtime/AsyncGeneratorFunctionPrototype.cpp: Added.
        (JSC::AsyncGeneratorFunctionPrototype::AsyncGeneratorFunctionPrototype):
        (JSC::AsyncGeneratorFunctionPrototype::finishCreation):
        * runtime/AsyncGeneratorFunctionPrototype.h: Added.
        (JSC::AsyncGeneratorFunctionPrototype::create):
        (JSC::AsyncGeneratorFunctionPrototype::createStructure):
        * runtime/AsyncGeneratorPrototype.cpp: Added.
        (JSC::AsyncGeneratorPrototype::finishCreation):
        * runtime/AsyncGeneratorPrototype.h: Added.
        (JSC::AsyncGeneratorPrototype::create):
        (JSC::AsyncGeneratorPrototype::createStructure):
        (JSC::AsyncGeneratorPrototype::AsyncGeneratorPrototype):
        * runtime/AsyncIteratorPrototype.cpp: Added.
        (JSC::AsyncIteratorPrototype::finishCreation):
        * runtime/AsyncIteratorPrototype.h: Added.
        (JSC::AsyncIteratorPrototype::create):
        (JSC::AsyncIteratorPrototype::createStructure):
        (JSC::AsyncIteratorPrototype::AsyncIteratorPrototype):
        * runtime/CommonIdentifiers.h:
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * runtime/FunctionConstructor.h:
        * runtime/FunctionExecutable.h:
        * runtime/JSAsyncGeneratorFunction.cpp: Added.
        (JSC::JSAsyncGeneratorFunction::JSAsyncGeneratorFunction):
        (JSC::JSAsyncGeneratorFunction::createImpl):
        (JSC::JSAsyncGeneratorFunction::create):
        (JSC::JSAsyncGeneratorFunction::createWithInvalidatedReallocationWatchpoint):
        * runtime/JSAsyncGeneratorFunction.h: Added.
        (JSC::JSAsyncGeneratorFunction::allocationSize):
        (JSC::JSAsyncGeneratorFunction::createStructure):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::getOwnPropertySlot):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::asyncIteratorPrototype const):
        (JSC::JSGlobalObject::asyncGeneratorPrototype const):
        (JSC::JSGlobalObject::asyncGeneratorFunctionPrototype const):
        (JSC::JSGlobalObject::asyncGeneratorFunctionStructure const):
        * runtime/Options.h:

2017-08-22  Michael Saboff  <msaboff@apple.com>

        Implement Unicode RegExp support in the YARR JIT
        https://bugs.webkit.org/show_bug.cgi?id=174646

        Reviewed by Filip Pizlo.

        This support is only implemented for 64 bit platforms.  It wouldn't be too hard to add support
        for 32 bit platforms with a reasonable number of spare registers.  This code slightly refactors
        register usage to reduce the number of callee save registers used for non-Unicode expressions.
        For Unicode expressions, there are several more registers used to store constants values for
        processing surrogate pairs as well as discerning whether a character belongs to the Basic
        Multilingual Plane (BMP) or one of the Supplemental Planes.

        This implements JIT support for Unicode expressions very similar to how the interpreter works.
        Just like in the interpreter, backtracking code uses more space on the stack to save positions.
        Moved the BackTrackInfo* structs to YarrPattern as separate functions.  Added xxxIndex()
        functions to each of these to simplify how the JIT code reads and writes the structure fields.

        Given that reading surrogate pairs and transforming them into a single code point takes a
        little processing, the code that implements reading a Unicode character is implemented as a
        leaf function added to the end of the JIT'ed code.  The calling convention for
        "tryReadUnicodeCharacterHelper()" is non-standard given that the rest of the code assumes
        that argument values stay in argument registers for most of the generated code.
        That helper takes the starting character address in one register, regUnicodeInputAndTrail,
        and uses another dedicated temporary register, regUnicodeTemp.  The result is typically
        returned in regT0.  If another return register is requested, we'll create an inline copy of
        that function.

        Added a new flag to CharacterClass to signify if a class has non-BMP characters.  This flag
        is used in optimizeAlternative() where we swap the order of a fixed character class term with
        a fixed character term that immediately follows it.  Since the non-BMP character class may
        increment "index" when matching, that must be done first before trying to match a fixed
        character term later in the string.

        Given the usefulness of the LEA instruction on X86 to create a single pointer value from a
        base with index and offset, which the YARR JIT uses heavily, I added a new macroAssembler
        function, getEffectiveAddress64(), with an ARM64 implementation.  It just calls x86Lea64()
        on X86-64.  Also added an ImplicitAddress version of load16Unaligned().

        (JSC::MacroAssemblerARM64::load16Unaligned):
        (JSC::MacroAssemblerARM64::getEffectiveAddress64):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::load16Unaligned):
        (JSC::MacroAssemblerX86Common::load16):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::getEffectiveAddress64):
        * create_regex_tables:
        * runtime/RegExp.cpp:
        (JSC::RegExp::compile):
        * yarr/YarrInterpreter.cpp:
        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::optimizeAlternative):
        (JSC::Yarr::YarrGenerator::matchCharacterClass):
        (JSC::Yarr::YarrGenerator::tryReadUnicodeCharImpl):
        (JSC::Yarr::YarrGenerator::tryReadUnicodeChar):
        (JSC::Yarr::YarrGenerator::readCharacter):
        (JSC::Yarr::YarrGenerator::jumpIfCharNotEquals):
        (JSC::Yarr::YarrGenerator::matchAssertionWordchar):
        (JSC::Yarr::YarrGenerator::generateAssertionWordBoundary):
        (JSC::Yarr::YarrGenerator::generatePatternCharacterOnce):
        (JSC::Yarr::YarrGenerator::generatePatternCharacterFixed):
        (JSC::Yarr::YarrGenerator::generatePatternCharacterGreedy):
        (JSC::Yarr::YarrGenerator::backtrackPatternCharacterGreedy):
        (JSC::Yarr::YarrGenerator::generatePatternCharacterNonGreedy):
        (JSC::Yarr::YarrGenerator::backtrackPatternCharacterNonGreedy):
        (JSC::Yarr::YarrGenerator::generateCharacterClassOnce):
        (JSC::Yarr::YarrGenerator::backtrackCharacterClassOnce):
        (JSC::Yarr::YarrGenerator::generateCharacterClassFixed):
        (JSC::Yarr::YarrGenerator::generateCharacterClassGreedy):
        (JSC::Yarr::YarrGenerator::backtrackCharacterClassGreedy):
        (JSC::Yarr::YarrGenerator::generateCharacterClassNonGreedy):
        (JSC::Yarr::YarrGenerator::backtrackCharacterClassNonGreedy):
        (JSC::Yarr::YarrGenerator::generate):
        (JSC::Yarr::YarrGenerator::backtrack):
        (JSC::Yarr::YarrGenerator::generateTryReadUnicodeCharacterHelper):
        (JSC::Yarr::YarrGenerator::generateEnter):
        (JSC::Yarr::YarrGenerator::generateReturn):
        (JSC::Yarr::YarrGenerator::YarrGenerator):
        (JSC::Yarr::YarrGenerator::compile):
        * yarr/YarrJIT.h:
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::CharacterClassConstructor::CharacterClassConstructor):
        (JSC::Yarr::CharacterClassConstructor::reset):
        (JSC::Yarr::CharacterClassConstructor::charClass):
        (JSC::Yarr::CharacterClassConstructor::addSorted):
        (JSC::Yarr::CharacterClassConstructor::addSortedRange):
        (JSC::Yarr::CharacterClassConstructor::hasNonBMPCharacters):
        (JSC::Yarr::YarrPatternConstructor::setupAlternativeOffsets):
        * yarr/YarrPattern.h:
        (JSC::Yarr::CharacterClass::CharacterClass):
        (JSC::Yarr::BackTrackInfoPatternCharacter::beginIndex):
        (JSC::Yarr::BackTrackInfoPatternCharacter::matchAmountIndex):
        (JSC::Yarr::BackTrackInfoCharacterClass::beginIndex):
        (JSC::Yarr::BackTrackInfoCharacterClass::matchAmountIndex):
        (JSC::Yarr::BackTrackInfoBackReference::beginIndex):
        (JSC::Yarr::BackTrackInfoBackReference::matchAmountIndex):
        (JSC::Yarr::BackTrackInfoAlternative::offsetIndex):
        (JSC::Yarr::BackTrackInfoParentheticalAssertion::beginIndex):
        (JSC::Yarr::BackTrackInfoParenthesesOnce::beginIndex):
        (JSC::Yarr::BackTrackInfoParenthesesTerminal::beginIndex):

2017-08-22  Per Arne Vollan  <pvollan@apple.com>

        Implement 64-bit MacroAssembler::probe support for Windows.
        https://bugs.webkit.org/show_bug.cgi?id=175724

        Reviewed by Mark Lam.

        This is needed to enable the DFG. MSVC does no longer support inline assembly
        for 64-bit, which means we have to put the code in an asm file.

        * assembler/MacroAssemblerX86Common.cpp:
        (JSC::booleanTrueForAvoidingNoReturnDeclaration): Deleted.
        * jit/JITStubsMSVC64.asm:

2017-08-22  Devin Rousso  <webkit@devinrousso.com>

        Web Inspector: provide way for ShaderPrograms to be enabled/disabled
        https://bugs.webkit.org/show_bug.cgi?id=175400

        Reviewed by Matt Baker.

        * inspector/protocol/Canvas.json:
        Add `setShaderProgramDisabled` command that sets the `disabled` flag on the given shader
        program to the supplied boolean value. If this value is true, calls to `drawArrays` and
        `drawElements` when that program is in use will have no effect.

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

        Unriviewed, fix windows build... for realz.

        * CMakeLists.txt:

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

        We are using valueProfileForBytecodeOffset when there may not be a value profile
        https://bugs.webkit.org/show_bug.cgi?id=175812

        Reviewed by Michael Saboff.

        This patch uses the type system to aid the code around CodeBlock's ValueProfile
        accessor methods. valueProfileForBytecodeOffset used to return ValueProfile*,
        so there were callers of this that thought it could return nullptr when there
        was no such ValueProfile. This was not the case, it always returned a non-null
        pointer. This patch changes valueProfileForBytecodeOffset to return ValueProfile&
        and adds a new tryGetValueProfileForBytecodeOffset method that returns ValueProfile*
        and does the right thing if there is no such ValueProfile.
        
        This patch also changes the other ValueProfile accessors on CodeBlock to
        return ValueProfile& instead of ValueProfile*. Some callers handled the null
        case unnecessarily, and using the type system to specify the result can't be
        null removes these useless branches.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
        (JSC::CodeBlock::dumpValueProfiles):
        (JSC::CodeBlock::tryGetValueProfileForBytecodeOffset):
        (JSC::CodeBlock::valueProfileForBytecodeOffset):
        (JSC::CodeBlock::validate):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::valueProfileForArgument):
        (JSC::CodeBlock::valueProfile):
        (JSC::CodeBlock::valueProfilePredictionForBytecodeOffset):
        (JSC::CodeBlock::getFromAllValueProfiles):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleInlining):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
        * dfg/DFGPredictionInjectionPhase.cpp:
        (JSC::DFG::PredictionInjectionPhase::run):
        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::emitValueProfilingSite):
        * profiler/ProfilerBytecodeSequence.cpp:
        (JSC::Profiler::BytecodeSequence::BytecodeSequence):
        * tools/HeapVerifier.cpp:
        (JSC::HeapVerifier::validateJSCell):

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

        Unreviewed, fix windows build... maybe.

        * CMakeLists.txt:

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

        Unreviewed, fix cloop build.

        * JavaScriptCore.xcodeproj/project.pbxproj:

2017-08-22  Per Arne Vollan  <pvollan@apple.com>

        [Win][Release] Crash when running testmasm executable.
        https://bugs.webkit.org/show_bug.cgi?id=175772

        Reviewed by Mark Lam.

        We need to save and restore the modified registers in case one or more registers are callee saved
        on the relevant platforms.

        * assembler/testmasm.cpp:
        (JSC::testProbeReadsArgumentRegisters):
        (JSC::testProbeWritesArgumentRegisters):

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

        Change probe code to use static_assert instead of COMPILE_ASSERT.
        https://bugs.webkit.org/show_bug.cgi?id=175762

        Reviewed by JF Bastien.

        * assembler/MacroAssemblerARM.cpp:
        * assembler/MacroAssemblerARM64.cpp:
        (JSC::MacroAssembler::probe): Deleted.
        * assembler/MacroAssemblerARMv7.cpp:
        * assembler/MacroAssemblerX86Common.cpp:

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

        Make generate_offset_extractor.rb architectures argument more robust
        https://bugs.webkit.org/show_bug.cgi?id=175809

        Reviewed by Joseph Pecoraro.

        It turns out that some of our builders pass their architectures as
        space separated lists.  I decided to just make the splitting of
        our list robust to any reasonable combination of spaces and
        commas.

        * offlineasm/generate_offset_extractor.rb:

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

        Only generate offline asm for the ARCHS (xcodebuild) or the current system (CMake)
        https://bugs.webkit.org/show_bug.cgi?id=175690

        Reviewed by Michael Saboff.

        This should reduce some of the time we spend building offline asm
        in our builds (except for linux since they already did this).

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * offlineasm/backends.rb:
        * offlineasm/generate_offset_extractor.rb:

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

        Gardening: fix CLoop build.
        https://bugs.webkit.org/show_bug.cgi?id=175688
        <rdar://problem/33436870>

        Not reviewed.

        Make these files dependent on ENABLE(MASM_PROBE).

        * assembler/ProbeContext.cpp:
        * assembler/ProbeContext.h:
        * assembler/ProbeStack.cpp:
        * assembler/ProbeStack.h:

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

        Enhance MacroAssembler::probe() to allow the probe function to resize the stack frame and alter stack data in one pass.
        https://bugs.webkit.org/show_bug.cgi?id=175688
        <rdar://problem/33436870>

        Reviewed by JF Bastien.

        With this patch, the clients of the MacroAssembler::probe() can now change
        stack values without having to worry about whether there is enough room in the
        current stack frame for it or not.  This is done using the Probe::Context's stack
        member like so:

            jit.probe([] (Probe::Context& context) {
                auto cpu = context.cpu;
                auto stack = context.stack();
                uintptr_t* currentSP = cpu.sp<uintptr_t*>();

                // Get a value at the current stack pointer location.
                auto value = stack.get<uintptr_t>(currentSP);

                // Set a value above the current stack pointer (within current frame).
                stack.set<uintptr_t>(currentSP + 10, value);

                // Set a value below the current stack pointer (out of current frame).
                stack.set<uintptr_t>(currentSP - 10, value);

                // Set the new stack pointer.
                cpu.sp() = currentSP - 20;
            });

        What happens behind the scene:

        1. the generated JIT probe code will now call Probe::executeProbe(), and
           Probe::executeProbe() will in turn call the client's probe function.

           Probe::executeProbe() receives the Probe::State on the machine stack passed
           to it by the probe trampoline.  Probe::executeProbe() will instantiate a
           Probe::Context to be passed to the client's probe function.  The client will
           no longer see the Probe::State directly.

        2. The Probe::Context comes with a Probe::Stack which serves as a manager of
           stack pages.  Currently, each page is 1K in size.
           Probe::Context::stack() returns a reference to an instance of Probe::Stack.

        3. Invoking get() of set() on Probe::Stack with an address will lead to the
           following:

           a. the address will be decoded to a baseAddress that points to the 1K page
              that contains that address.

           b. the Probe::Stack will check if it already has a cached 1K page for that baseAddress.
              If so, go to step (f).  Else, continue with step (c).

           c. the Probe::Stack will malloc a 1K mirror page, and memcpy the 1K stack page
              for that specified baseAddress to this mirror page.

           d. the mirror page will be added to the ProbeStack's m_pages HashMap,
              keyed on the baseAddress.

           e. the ProbeStack will also cache the last baseAddress and its corresponding
              mirror page in use.  With memory accesses tending to be localized, this
              will save us from having to look up the page in the HashMap.

           f. get() will map the requested address to a physical address in the mirror
              page, and return the value at that location.

           g. set() will map the requested address to a physical address in the mirror
              page, and set the value at that location in the mirror page.

              set() will also set a dirty bit corresponding to the "cache line" that
              was modified in the mirror page.

        4. When the client's probe function returns, Probe::executeProbe() will check if
           there are stack changes that need to be applied.  If stack changes are needed:

           a. Probe::executeProbe() will adjust the stack pointer to ensure enough stack
              space is available to flush the dirty stack pages.  It will also register a
              flushStackDirtyPages callback function in the Probe::State.  Thereafter,
              Probe::executeProbe() returns to the probe trampoline.

           b. the probe trampoline adjusts the stack pointer, moves the Probe::State to
              a safe place if needed, and then calls the flushStackDirtyPages callback
              if needed.

           c. the flushStackDirtyPages() callback iterates the Probe::Stack's m_pages
              HashMap and flush all dirty "cache lines" to the machine stack.
              Thereafter, flushStackDirtyPages() returns to the probe trampoline.

           d. lastly, the probe trampoline will restore all register values and return
              to the pc set in the Probe::State.

        To make this patch work, I also had to do the following work:

        5. Refactor MacroAssembler::CPUState into Probe::CPUState.
           Mainly, this means moving the code over to ProbeContext.h.
           I also added some convenience accessor methods for spr registers. 

           Moved Probe::Context over to its own file ProbeContext.h/cpp.

        6. Fix all probe trampolines to pass the address of Probe::executeProbe in
           addition to the client's probe function and arg.

           I also took this opportunity to optimize the generated JIT probe code to
           minimize the amount of memory stores needed. 

        7. Simplified the ARM64 probe trampoline.  The ARM64 probe only supports changing
           either lr or pc (or neither), but not both at in the same probe invocation.
           The ARM64 probe trampoline used to have to check for this invariant in the
           assembly trampoline code.  With the introduction of Probe::executeProbe(),
           we can now do it there and simplify the trampoline.

        8. Fix a bug in the old  ARM64 probe trampoline for the case where the client
           changes lr.  That code path never worked before, but has now been fixed.

        9. Removed trustedImm32FromPtr() helper functions in MacroAssemblerARM and
           MacroAssemblerARMv7.

           We can now use move() with TrustedImmPtr, and it does the same thing but in a
           more generic way.

       10. ARMv7's move() emitter may encode a T1 move instruction, which happens to have
           the same semantics as movs (according to the Thumb spec).  This means these
           instructions may trash the APSR flags before we have a chance to preserve them.

           This patch changes MacroAssemblerARMv7's probe() to preserve the APSR register
           early on.  This entails adding support for the mrs instruction in the
           ARMv7Assembler.

       10. Change testmasm's testProbeModifiesStackValues() to now modify stack values
           the easy way.

           Also fixed testmasm tests which check flag registers to only compare the
           portions that are modifiable by the client i.e. some masking is applied.

        This patch has passed the testmasm tests on x86, x86_64, arm64, and armv7.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/ARMv7Assembler.h:
        (JSC::ARMv7Assembler::mrs):
        * assembler/AbstractMacroAssembler.h:
        * assembler/MacroAssembler.cpp:
        (JSC::stdFunctionCallback):
        (JSC::MacroAssembler::probe):
        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::CPUState::gprName): Deleted.
        (JSC::MacroAssembler::CPUState::sprName): Deleted.
        (JSC::MacroAssembler::CPUState::fprName): Deleted.
        (JSC::MacroAssembler::CPUState::gpr): Deleted.
        (JSC::MacroAssembler::CPUState::spr): Deleted.
        (JSC::MacroAssembler::CPUState::fpr): Deleted.
        (JSC:: const): Deleted.
        (JSC::MacroAssembler::CPUState::fpr const): Deleted.
        (JSC::MacroAssembler::CPUState::pc): Deleted.
        (JSC::MacroAssembler::CPUState::fp): Deleted.
        (JSC::MacroAssembler::CPUState::sp): Deleted.
        (JSC::MacroAssembler::CPUState::pc const): Deleted.
        (JSC::MacroAssembler::CPUState::fp const): Deleted.
        (JSC::MacroAssembler::CPUState::sp const): Deleted.
        (JSC::Probe::State::gpr): Deleted.
        (JSC::Probe::State::spr): Deleted.
        (JSC::Probe::State::fpr): Deleted.
        (JSC::Probe::State::gprName): Deleted.
        (JSC::Probe::State::sprName): Deleted.
        (JSC::Probe::State::fprName): Deleted.
        (JSC::Probe::State::pc): Deleted.
        (JSC::Probe::State::fp): Deleted.
        (JSC::Probe::State::sp): Deleted.
        * assembler/MacroAssemblerARM.cpp:
        (JSC::MacroAssembler::probe):
        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::trustedImm32FromPtr): Deleted.
        * assembler/MacroAssemblerARM64.cpp:
        (JSC::MacroAssembler::probe):
        (JSC::arm64ProbeError): Deleted.
        * assembler/MacroAssemblerARMv7.cpp:
        (JSC::MacroAssembler::probe):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::armV7Condition):
        (JSC::MacroAssemblerARMv7::trustedImm32FromPtr): Deleted.
        * assembler/MacroAssemblerPrinter.cpp:
        (JSC::Printer::printCallback):
        * assembler/MacroAssemblerPrinter.h:
        * assembler/MacroAssemblerX86Common.cpp:
        (JSC::ctiMasmProbeTrampoline):
        (JSC::MacroAssembler::probe):
        * assembler/Printer.h:
        (JSC::Printer::Context::Context):
        * assembler/ProbeContext.cpp: Added.
        (JSC::Probe::executeProbe):
        (JSC::Probe::handleProbeStackInitialization):
        (JSC::Probe::probeStateForContext):
        * assembler/ProbeContext.h: Added.
        (JSC::Probe::CPUState::gprName):
        (JSC::Probe::CPUState::sprName):
        (JSC::Probe::CPUState::fprName):
        (JSC::Probe::CPUState::gpr):
        (JSC::Probe::CPUState::spr):
        (JSC::Probe::CPUState::fpr):
        (JSC::Probe:: const):
        (JSC::Probe::CPUState::fpr const):
        (JSC::Probe::CPUState::pc):
        (JSC::Probe::CPUState::fp):
        (JSC::Probe::CPUState::sp):
        (JSC::Probe::CPUState::pc const):
        (JSC::Probe::CPUState::fp const):
        (JSC::Probe::CPUState::sp const):
        (JSC::Probe::Context::Context):
        (JSC::Probe::Context::gpr):
        (JSC::Probe::Context::spr):
        (JSC::Probe::Context::fpr):
        (JSC::Probe::Context::gprName):
        (JSC::Probe::Context::sprName):
        (JSC::Probe::Context::fprName):
        (JSC::Probe::Context::pc):
        (JSC::Probe::Context::fp):
        (JSC::Probe::Context::sp):
        (JSC::Probe::Context::stack):
        (JSC::Probe::Context::hasWritesToFlush):
        (JSC::Probe::Context::releaseStack):
        * assembler/ProbeStack.cpp: Added.
        (JSC::Probe::Page::Page):
        (JSC::Probe::Page::flushWrites):
        (JSC::Probe::Stack::Stack):
        (JSC::Probe::Stack::hasWritesToFlush):
        (JSC::Probe::Stack::flushWrites):
        (JSC::Probe::Stack::ensurePageFor):
        * assembler/ProbeStack.h: Added.
        (JSC::Probe::Page::baseAddressFor):
        (JSC::Probe::Page::chunkAddressFor):
        (JSC::Probe::Page::baseAddress):
        (JSC::Probe::Page::get):
        (JSC::Probe::Page::set):
        (JSC::Probe::Page::hasWritesToFlush const):
        (JSC::Probe::Page::flushWritesIfNeeded):
        (JSC::Probe::Page::dirtyBitFor):
        (JSC::Probe::Page::physicalAddressFor):
        (JSC::Probe::Stack::Stack):
        (JSC::Probe::Stack::lowWatermark):
        (JSC::Probe::Stack::get):
        (JSC::Probe::Stack::set):
        (JSC::Probe::Stack::newStackPointer const):
        (JSC::Probe::Stack::setNewStackPointer):
        (JSC::Probe::Stack::isValid):
        (JSC::Probe::Stack::pageFor):
        * assembler/testmasm.cpp:
        (JSC::testProbeReadsArgumentRegisters):
        (JSC::testProbeWritesArgumentRegisters):
        (JSC::testProbePreservesGPRS):
        (JSC::testProbeModifiesStackPointer):
        (JSC::testProbeModifiesStackPointerToInsideProbeStateOnStack):
        (JSC::testProbeModifiesStackPointerToNBytesBelowSP):
        (JSC::testProbeModifiesProgramCounter):
        (JSC::testProbeModifiesStackValues):
        (JSC::run):
        (): Deleted.
        (JSC::fillStack): Deleted.
        (JSC::testProbeModifiesStackWithCallback): Deleted.

2017-08-19  Andy Estes  <aestes@apple.com>

        [Payment Request] Add interface stubs
        https://bugs.webkit.org/show_bug.cgi?id=175730

        Reviewed by Youenn Fablet.

        * runtime/CommonIdentifiers.h:

2017-08-18  Per Arne Vollan  <pvollan@apple.com>

        Implement 32-bit MacroAssembler::probe support for Windows.
        https://bugs.webkit.org/show_bug.cgi?id=175449

        Reviewed by Mark Lam.

        This is needed to enable the DFG.

        * assembler/MacroAssemblerX86Common.cpp:
        * assembler/testmasm.cpp:
        (JSC::run):
        (dllLauncherEntryPoint):
        * shell/CMakeLists.txt:
        * shell/PlatformWin.cmake:

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

        Rename ProbeContext and ProbeFunction to Probe::State and Probe::Function.
        https://bugs.webkit.org/show_bug.cgi?id=175725
        <rdar://problem/33965477>

        Rubber-stamped by JF Bastien.

        This is purely a refactoring patch (in preparation for the introduction of a
        Probe::Context data structure in https://bugs.webkit.org/show_bug.cgi?id=175688
        later).  This patch does not change any semantics / behavior.

        * assembler/AbstractMacroAssembler.h:
        * assembler/MacroAssembler.cpp:
        (JSC::stdFunctionCallback):
        (JSC::MacroAssembler::probe):
        * assembler/MacroAssembler.h:
        (JSC::ProbeContext::gpr): Deleted.
        (JSC::ProbeContext::spr): Deleted.
        (JSC::ProbeContext::fpr): Deleted.
        (JSC::ProbeContext::gprName): Deleted.
        (JSC::ProbeContext::sprName): Deleted.
        (JSC::ProbeContext::fprName): Deleted.
        (JSC::ProbeContext::pc): Deleted.
        (JSC::ProbeContext::fp): Deleted.
        (JSC::ProbeContext::sp): Deleted.
        * assembler/MacroAssemblerARM.cpp:
        (JSC::MacroAssembler::probe):
        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::trustedImm32FromPtr):
        * assembler/MacroAssemblerARM64.cpp:
        (JSC::arm64ProbeError):
        (JSC::MacroAssembler::probe):
        * assembler/MacroAssemblerARMv7.cpp:
        (JSC::MacroAssembler::probe):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::trustedImm32FromPtr):
        * assembler/MacroAssemblerPrinter.cpp:
        (JSC::Printer::printCallback):
        * assembler/MacroAssemblerPrinter.h:
        * assembler/MacroAssemblerX86Common.cpp:
        (JSC::MacroAssembler::probe):
        * assembler/Printer.h:
        (JSC::Printer::Context::Context):
        * assembler/testmasm.cpp:
        (JSC::testProbeReadsArgumentRegisters):
        (JSC::testProbeWritesArgumentRegisters):
        (JSC::testProbePreservesGPRS):
        (JSC::testProbeModifiesStackPointer):
        (JSC::testProbeModifiesStackPointerToInsideProbeStateOnStack):
        (JSC::testProbeModifiesStackPointerToNBytesBelowSP):
        (JSC::testProbeModifiesProgramCounter):
        (JSC::fillStack):
        (JSC::testProbeModifiesStackWithCallback):
        (JSC::run):
        (JSC::testProbeModifiesStackPointerToInsideProbeContextOnStack): Deleted.

2017-08-17  JF Bastien  <jfbastien@apple.com>

        WebAssembly: const in unreachable code decoded incorrectly, erroneously rejects binary as invalid
        https://bugs.webkit.org/show_bug.cgi?id=175693
        <rdar://problem/33952443>

        Reviewed by Saam Barati.

        64-bit constants in an unreachable context were being decoded as
        32-bit constants. This is pretty benign because unreachable code
        shouldn't occur often. The effect is that 64-bit constants which
        can't be encoded as 32-bit constants would cause the binary to be
        rejected.

        At the same time, 32-bit integer constants should be decoded as signed.

        * wasm/WasmFunctionParser.h:
        (JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):

2017-08-17  Robin Morisset  <rmorisset@apple.com>

        Teach DFGFixupPhase.cpp that the current scope is always a cell
        https://bugs.webkit.org/show_bug.cgi?id=175610

        Reviewed by Keith Miller.

        Also teach it that the argument to with can usually be speculated to be an object,
        since toObject() is called on it.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compilePushWithScope):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compilePushWithScope):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:

2017-08-17  Matt Baker  <mattbaker@apple.com>

        Web Inspector: remove unused private struct from InspectorScriptProfilerAgent
        https://bugs.webkit.org/show_bug.cgi?id=175644

        Reviewed by Brian Burg.

        * inspector/agents/InspectorScriptProfilerAgent.h:

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

        Only use 16 VFP registers if !CPU(ARM_NEON).
        https://bugs.webkit.org/show_bug.cgi?id=175514

        Reviewed by JF Bastien.

        Deleted q16-q31 FPQuadRegisterID enums in ARMv7Assembler.h.  The NEON spec
        says that there are only 16 128-bit NEON registers.  This change is merely to
        correct the code documentation of these registers.  The FPQuadRegisterID are
        currently unused.

        * assembler/ARMAssembler.h:
        (JSC::ARMAssembler::lastFPRegister):
        (JSC::ARMAssembler::fprName):
        * assembler/ARMv7Assembler.h:
        (JSC::ARMv7Assembler::lastFPRegister):
        (JSC::ARMv7Assembler::fprName):
        * assembler/MacroAssemblerARM.cpp:
        * assembler/MacroAssemblerARMv7.cpp:

2017-08-17  Andreas Kling  <akling@apple.com>

        Disable CSS regions at compile time
        https://bugs.webkit.org/show_bug.cgi?id=175630

        Reviewed by Antti Koivisto.

        * Configurations/FeatureDefines.xcconfig:

2017-08-17  Jacobo Aragunde Pérez  <jaragunde@igalia.com>

        [WPE][GTK] Ensure proper casting of data in gvariants
        https://bugs.webkit.org/show_bug.cgi?id=175667

        Reviewed by Michael Catanzaro.

        g_variant_new requires data to have the correct width for their types, using
        casting if necessary. Some data of type `unsigned` were being saved to `guint64`
        types without explicit casting, leading to undefined behavior in some platforms.

        * inspector/remote/glib/RemoteInspectorGlib.cpp:
        (Inspector::RemoteInspector::listingForInspectionTarget const):
        (Inspector::RemoteInspector::listingForAutomationTarget const):
        (Inspector::RemoteInspector::sendMessageToRemote):

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

        [JSC] Avoid code bloating for iteration if block does not have "break"
        https://bugs.webkit.org/show_bug.cgi?id=173228

        Reviewed by Keith Miller.

        Currently, we always emit code for breaked path when emitting for-of iteration.
        But we can know that this breaked path can be used when emitting the bytecode.

        This patch adds LabelScope::breakTargetMayBeBound(), which returns true if
        the break label may be bound. We emit a breaked path only when it returns
        true. This reduces bytecode bloating when using for-of iteration.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::Label::setLocation):
        (JSC::BytecodeGenerator::newLabel):
        (JSC::BytecodeGenerator::emitLabel):
        (JSC::BytecodeGenerator::pushFinallyControlFlowScope):
        (JSC::BytecodeGenerator::breakTarget):
        (JSC::BytecodeGenerator::continueTarget):
        (JSC::BytecodeGenerator::emitEnumeration):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/Label.h:
        (JSC::Label::bind const):
        (JSC::Label::hasOneRef const):
        (JSC::Label::isBound const):
        (JSC::Label::Label): Deleted.
        * bytecompiler/LabelScope.h:
        (JSC::LabelScope::hasOneRef const):
        (JSC::LabelScope::breakTargetMayBeBound const):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ContinueNode::trivialTarget):
        (JSC::ContinueNode::emitBytecode):
        (JSC::BreakNode::trivialTarget):
        (JSC::BreakNode::emitBytecode):

2017-08-17  Csaba Osztrogonác  <ossy@webkit.org>

        ARM build fix after r220807 and r220834.
        https://bugs.webkit.org/show_bug.cgi?id=175617

        Unreviewed typo fix.

        * assembler/MacroAssemblerARM.cpp:

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

        Gardening: build fix for ARM_TRADITIONAL after r220807.
        https://bugs.webkit.org/show_bug.cgi?id=175617

        Not reviewed.

        * assembler/MacroAssemblerARM.cpp:

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

        Add back the ability to disable MASM_PROBE from the build.
        https://bugs.webkit.org/show_bug.cgi?id=175656
        <rdar://problem/33933720>

        Reviewed by Yusuke Suzuki.

        This is needed for ports that the existing MASM_PROBE implementation doesn't work
        well with e.g. GTK with ARM_THUMB2.  Note that if the DFG_JIT will be disabled by
        default if !ENABLE(MASM_PROBE).

        * assembler/AbstractMacroAssembler.h:
        * assembler/MacroAssembler.cpp:
        * assembler/MacroAssembler.h:
        * assembler/MacroAssemblerARM.cpp:
        * assembler/MacroAssemblerARM64.cpp:
        * assembler/MacroAssemblerARMv7.cpp:
        * assembler/MacroAssemblerPrinter.cpp:
        * assembler/MacroAssemblerPrinter.h:
        * assembler/MacroAssemblerX86Common.cpp:
        * assembler/testmasm.cpp:
        (JSC::run):
        * b3/B3LowerToAir.cpp:
        * b3/air/AirPrintSpecial.cpp:
        * b3/air/AirPrintSpecial.h:

2017-08-16  Dan Bernstein  <mitz@apple.com>

        [Cocoa] Older-iOS install name symbols are being exported on other platforms
        https://bugs.webkit.org/show_bug.cgi?id=175654

        Reviewed by Tim Horton.

        * API/JSBase.cpp: Define the symbols only when targeting iOS.

2017-08-16  Matt Baker  <mattbaker@apple.com>

        Web Inspector: capture async stack trace when workers/main context posts a message
        https://bugs.webkit.org/show_bug.cgi?id=167084
        <rdar://problem/30033673>

        Reviewed by Brian Burg.

        * inspector/agents/InspectorDebuggerAgent.h:
        Add `PostMessage` async call type.

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

        Enhance MacroAssembler::probe() to support an initializeStackFunction callback.
        https://bugs.webkit.org/show_bug.cgi?id=175617
        <rdar://problem/33912104>

        Reviewed by JF Bastien.

        This patch adds a new feature to MacroAssembler::probe() where the probe function
        can provide a ProbeFunction callback to fill in stack values after the stack
        pointer has been adjusted.  The probe function can use this feature as follows:

        1. Set the new sp value in the ProbeContext's CPUState.

        2. Set the ProbeContext's initializeStackFunction to a ProbeFunction callback
           which will do the work of filling in the stack values after the probe
           trampoline has adjusted the machine stack pointer.

        3. Set the ProbeContext's initializeStackArgs to any value that the client wants
           to pass to the initializeStackFunction callback.

        4. Return from the probe function.

        Upon returning from the probe function, the probe trampoline will adjust the
        the stack pointer based on the sp value in CPUState.  If initializeStackFunction
        is not set, the probe trampoline will restore registers and return to its caller.

        If initializeStackFunction is set, the trampoline will move the ProbeContext
        beyond the range of the stack pointer i.e. it will place the new ProbeContext at
        an address lower than where CPUState.sp() points.  This ensures that the
        ProbeContext will not be trashed by the initializeStackFunction when it writes to
        the stack.  Then, the trampoline will call back to the initializeStackFunction
        ProbeFunction to let it fill in the stack values as desired.  The
        initializeStackFunction ProbeFunction will be passed the moved ProbeContext at
        the new location.

        initializeStackFunction may now write to the stack at addresses greater or
        equal to CPUState.sp(), but not below that.  initializeStackFunction is also
        not allowed to change CPUState.sp().  If the initializeStackFunction does not
        abide by these rules, then behavior is undefined, and bad things may happen.

        For future reference, some implementation details that this patch needed to
        be mindful of:

        1. When the probe trampoline allocates stack space for the ProbeContext, it
           should include OUT_SIZE as well.  This ensures that it doesn't have to move
           the ProbeContext on exit if the probe function didn't change the sp.

        2. If the trampoline has to move the ProbeContext, it needs to point the machine
           sp to new ProbeContext first before copying over the ProbeContext data.  This
           protects the new ProbeContext from possibly being trashed by interrupts.

        3. When computing the new address of ProbeContext to move to, we need to make
           sure that it is properly aligned in accordance with stack ABI requirements
           (just like we did when we allocated the ProbeContext on entry to the
           probe trampoline).

        4. When copying the ProbeContext to its new location, the trampoline should
           always copy words from low addresses to high addresses.  This is because if
           we're moving the ProbeContext, we'll always be moving it to a lower address.

        * assembler/MacroAssembler.h:
        * assembler/MacroAssemblerARM.cpp:
        * assembler/MacroAssemblerARM64.cpp:
        * assembler/MacroAssemblerARMv7.cpp:
        * assembler/MacroAssemblerX86Common.cpp:
        * assembler/testmasm.cpp:
        (JSC::testProbePreservesGPRS):
        (JSC::testProbeModifiesStackPointer):
        (JSC::fillStack):
        (JSC::testProbeModifiesStackWithCallback):
        (JSC::run):

2017-08-16  Csaba Osztrogonác  <ossy@webkit.org>

        Fix JSCOnly ARM buildbots after r220047 and r220184
        https://bugs.webkit.org/show_bug.cgi?id=174993

        Reviewed by Carlos Alberto Lopez Perez.

        * CMakeLists.txt: Generate only one backend on Linux to save build time.

2017-08-16  Andy Estes  <aestes@apple.com>

        [Payment Request] Add an ENABLE flag and an experimental feature preference
        https://bugs.webkit.org/show_bug.cgi?id=175622

        Reviewed by Tim Horton.

        * Configurations/FeatureDefines.xcconfig:

2017-08-15  Robin Morisset  <rmorisset@apple.com>

        We are too conservative about the effects of PushWithScope
        https://bugs.webkit.org/show_bug.cgi?id=175584

        Reviewed by Saam Barati.

        PushWithScope converts its argument to an object (this can throw a type error,
        but has no other observable effect), and allocates a new scope, that it then
        makes the new current scope. We were a bit too
        conservative in saying that it clobbers the world.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):

2017-08-15  Ryosuke Niwa  <rniwa@webkit.org>

        Make DataTransferItemList work with plain text entries
        https://bugs.webkit.org/show_bug.cgi?id=175596

        Reviewed by Wenson Hsieh.

        Added DataTransferItem as a common identifier since it's a runtime enabled feature.

        * runtime/CommonIdentifiers.h:

2017-08-15  Robin Morisset  <rmorisset@apple.com>

        Support the 'with' keyword in FTL
        https://bugs.webkit.org/show_bug.cgi?id=175585

        Reviewed by Saam Barati.

        Also makes sure that the order of arguments of PushWithScope, op_push_with_scope, JSWithScope::create()
        and so on is consistent (always parentScope first, the new scopeObject second). We used to go from one
        to the other at different step which was quite confusing. I picked this order for consistency with CreateActivation
        that takes its parentScope argument first.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitPushWithScope):
        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::evaluateWithScopeExtension):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compilePushWithScope):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compilePushWithScope):
        * jit/JITOperations.cpp:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/Completion.cpp:
        (JSC::evaluateWithScopeExtension):
        * runtime/JSWithScope.cpp:
        (JSC::JSWithScope::create):
        * runtime/JSWithScope.h:

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

        Make VM::scratchBufferForSize thread safe
        https://bugs.webkit.org/show_bug.cgi?id=175604

        Reviewed by Geoffrey Garen and Mark Lam.

        I want to use the VM::scratchBufferForSize in another patch I'm writing.
        The use case for my other patch is to call it from the compiler thread.
        When reading the code, I saw that this API was not thread safe. This patch
        makes it thread safe. It actually turns out we were calling this API from
        the compiler thread already when we created FTL::State for an FTL OSR entry
        compilation, and from FTLLowerDFGToB3. That code was racy and wrong, but
        is now correct with this patch.

        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::~VM):
        (JSC::VM::gatherConservativeRoots):
        (JSC::VM::scratchBufferForSize):
        * runtime/VM.h:
        (JSC::VM::scratchBufferForSize): Deleted.

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

        JSC named bytecode offsets should use references rather than pointers
        https://bugs.webkit.org/show_bug.cgi?id=175601

        Reviewed by Saam Barati.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_overrides_has_instance):
        (JSC::JIT::emit_op_instanceof):
        (JSC::JIT::emitSlow_op_instanceof):
        (JSC::JIT::emitSlow_op_instanceof_custom):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_overrides_has_instance):
        (JSC::JIT::emit_op_instanceof):
        (JSC::JIT::emitSlow_op_instanceof):
        (JSC::JIT::emitSlow_op_instanceof_custom):

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

        Enable named offsets into JSC bytecodes
        https://bugs.webkit.org/show_bug.cgi?id=175561

        Reviewed by Mark Lam.

        This patch adds the ability to add named offsets into JSC's
        bytecodes.  In the bytecode json file, instead of listing a
        length, you can now list a set of names and their types. Each
        opcode with an offsets property will have a struct named after the
        opcode by in our C++ naming style. For example,
        op_overrides_has_instance would become OpOverridesHasInstance. The
        struct has the same memory layout as the instruction list has but
        comes with handy named accessors.

        As a first cut I converted the various instanceof bytecodes to use
        named offsets.

        As an example op_overrides_has_instance produces the following struct:

        struct OpOverridesHasInstance {
        public:
            Opcode& opcode() { return *reinterpret_cast<Opcode*>(&m_opcode); }
            const Opcode& opcode() const { return *reinterpret_cast<const Opcode*>(&m_opcode); }
            int& dst() { return *reinterpret_cast<int*>(&m_dst); }
            const int& dst() const { return *reinterpret_cast<const int*>(&m_dst); }
            int& constructor() { return *reinterpret_cast<int*>(&m_constructor); }
            const int& constructor() const { return *reinterpret_cast<const int*>(&m_constructor); }
            int& hasInstanceValue() { return *reinterpret_cast<int*>(&m_hasInstanceValue); }
            const int& hasInstanceValue() const { return *reinterpret_cast<const int*>(&m_hasInstanceValue); }

        private:
            friend class LLIntOffsetsExtractor;
            std::aligned_storage<sizeof(Opcode), sizeof(Instruction)>::type m_opcode;
            std::aligned_storage<sizeof(int), sizeof(Instruction)>::type m_dst;
            std::aligned_storage<sizeof(int), sizeof(Instruction)>::type m_constructor;
            std::aligned_storage<sizeof(int), sizeof(Instruction)>::type m_hasInstanceValue;
        };

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/BytecodeList.json:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * generate-bytecode-files:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_overrides_has_instance):
        (JSC::JIT::emit_op_instanceof):
        (JSC::JIT::emitSlow_op_instanceof):
        (JSC::JIT::emitSlow_op_instanceof_custom):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_overrides_has_instance):
        (JSC::JIT::emit_op_instanceof):
        (JSC::JIT::emitSlow_op_instanceof):
        (JSC::JIT::emitSlow_op_instanceof_custom):
        * llint/LLIntOffsetsExtractor.cpp:
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

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

        Update testmasm to use new CPUState APIs.
        https://bugs.webkit.org/show_bug.cgi?id=175573

        Reviewed by Keith Miller.

        1. Applied convenience CPUState accessors to minimize casting.
        2. Converted the CHECK macro to CHECK_EQ to get more friendly failure debugging
           messages.
        3. Removed the CHECK_DOUBLE_BITWISE_EQ macro.  We can just use CHECK_EQ now since
           casting is (mostly) no longer an issue.
        4. Replaced the use of testDoubleWord(id) with bitwise_cast<double>(testWord64(id))
           to make it clear that we're comparing against the bit values of testWord64(id).
        5. Added a "Completed N tests" message at the end of running all tests.
           This makes it easy to tell at a glance that testmasm completed successfully
           versus when it crashed midway in a test.  The number of tests also serves as
           a quick checksum to confirm that we ran the number of tests we expected.

        * assembler/testmasm.cpp:
        (WTF::printInternal):
        (JSC::testSimple):
        (JSC::testProbeReadsArgumentRegisters):
        (JSC::testProbeWritesArgumentRegisters):
        (JSC::testProbePreservesGPRS):
        (JSC::testProbeModifiesStackPointer):
        (JSC::testProbeModifiesProgramCounter):
        (JSC::run):

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

        Add testing tool to lie to the DFG about profiles
        https://bugs.webkit.org/show_bug.cgi?id=175487

        Reviewed by Saam Barati.

        This patch adds a new bytecode identity_with_profile that lets
        us lie to the DFG about what profiles it has seen as the input to
        another bytecode. Previously, there was no reliable way to force
        a given profile when we tired up.

        * bytecode/BytecodeDumper.cpp:
        (JSC::BytecodeDumper<Block>::dumpBytecode):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/SpeculatedType.cpp:
        (JSC::speculationFromString):
        * bytecode/SpeculatedType.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitIdWithProfile):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_idWithProfile):
        * 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/DFGMayExit.cpp:
        * dfg/DFGNode.h:
        (JSC::DFG::Node::getForcedPrediction):
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGValidate.cpp:
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_identity_with_profile):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_identity_with_profile):
        * llint/LowLevelInterpreter.asm:

2017-08-14  Simon Fraser  <simon.fraser@apple.com>

        Remove Proximity Events and related code
        https://bugs.webkit.org/show_bug.cgi?id=175545

        Reviewed by Daniel Bates.

        No platform enables Proximity Events, so remove code inside ENABLE(PROXIMITY_EVENTS)
        and other related code.

        * Configurations/FeatureDefines.xcconfig:

2017-08-14  Simon Fraser  <simon.fraser@apple.com>

        Remove ENABLE(REQUEST_AUTOCOMPLETE) code, which was disabled everywhere
        https://bugs.webkit.org/show_bug.cgi?id=175504

        Reviewed by Sam Weinig.

        * Configurations/FeatureDefines.xcconfig:

2017-08-14  Simon Fraser  <simon.fraser@apple.com>

        Remove ENABLE_VIEW_MODE_CSS_MEDIA and related code
        https://bugs.webkit.org/show_bug.cgi?id=175557

        Reviewed by Jon Lee.

        No port cares about the ENABLE(VIEW_MODE_CSS_MEDIA) feature, so remove it.

        * Configurations/FeatureDefines.xcconfig:

2017-08-14  Robin Morisset  <rmorisset@apple.com>

        Support the 'with' keyword in DFG
        https://bugs.webkit.org/show_bug.cgi?id=175470

        Reviewed by Saam Barati.

        Not particularly optimized at the moment, the goal is just to avoid
        the DFG bailing out of any function with this keyword.

        * 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::compilePushWithScope):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:

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

        Add some convenience utility accessor methods to MacroAssembler::CPUState.
        https://bugs.webkit.org/show_bug.cgi?id=175549
        <rdar://problem/33884868>

        Reviewed by Saam Barati.

        Previously, in order to read ProbeContext CPUState registers, we used to need to
        do it this way:

            ExecState* exec = reinterpret_cast<ExecState*>(cpu.fp());
            uint32_t i32 = static_cast<uint32_t>(cpu.gpr(GPRInfo::regT0));
            void* p = reinterpret_cast<void*>(cpu.gpr(GPRInfo::regT1));
            uint64_t u64 = bitwise_cast<uint64_t>(cpu.fpr(FPRInfo::fpRegT0));

        With this patch, we can now read them this way instead:
        
            ExecState* exec = cpu.fp<ExecState*>();
            uint32_t i32 = cpu.gpr<uint32_t>(GPRInfo::regT0);
            void* p = cpu.gpr<void*>(GPRInfo::regT1);
            uint64_t u64 = cpu.fpr<uint64_t>(FPRInfo::fpRegT0);

        * assembler/MacroAssembler.h:
        (JSC:: const):
        (JSC::MacroAssembler::CPUState::fpr const):
        (JSC::MacroAssembler::CPUState::pc const):
        (JSC::MacroAssembler::CPUState::fp const):
        (JSC::MacroAssembler::CPUState::sp const):
        (JSC::ProbeContext::pc):
        (JSC::ProbeContext::fp):
        (JSC::ProbeContext::sp):

2017-08-12  Filip Pizlo  <fpizlo@apple.com>

        Put the ScopedArgumentsTable's ScopeOffset array in some gigacage
        https://bugs.webkit.org/show_bug.cgi?id=174921

        Reviewed by Mark Lam.
        
        Uses CagedUniquePtr<> to cage the ScopeOffset array.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitScopedArgumentsGetByVal):
        * runtime/ScopedArgumentsTable.cpp:
        (JSC::ScopedArgumentsTable::create):
        (JSC::ScopedArgumentsTable::setLength):
        * runtime/ScopedArgumentsTable.h:

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

        Gardening: fix Windows build.
        https://bugs.webkit.org/show_bug.cgi?id=175446

        Not reviewed.

        * assembler/MacroAssemblerX86Common.cpp:
        (JSC::booleanTrueForAvoidingNoReturnDeclaration):
        (JSC::ctiMasmProbeTrampoline):

2017-08-12  Csaba Osztrogonác  <ossy@webkit.org>

        [ARM64] Use x29 and x30 instead of fp and lr to make GCC happy
        https://bugs.webkit.org/show_bug.cgi?id=175512
        <rdar://problem/33863584>

        Reviewed by Mark Lam.

        * CMakeLists.txt: Added MacroAssemblerARM64.cpp.
        * assembler/MacroAssemblerARM64.cpp: Use x29 and x30 instead of fp and lr to make GCC happy.

2017-08-12  Csaba Osztrogonác  <ossy@webkit.org>

        ARM_TRADITIONAL: static assertion failed: ProbeContext_size_matches_ctiMasmProbeTrampoline
        https://bugs.webkit.org/show_bug.cgi?id=175513

        Reviewed by Mark Lam.

        * assembler/MacroAssemblerARM.cpp: Added d16-d31 FP registers too.

2017-08-12  Filip Pizlo  <fpizlo@apple.com>

        FTL's compileGetTypedArrayByteOffset needs to do caging
        https://bugs.webkit.org/show_bug.cgi?id=175366

        Reviewed by Saam Barati.
        
        While implementing boxing in the DFG, I noticed that there was some missing boxing in the FTL. This
        fixes the case in GetTypedArrayByteOffset, and files FIXMEs for more such cases.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset):
        (JSC::FTL::DFG::LowerDFGToB3::cagedMayBeNull):
        * runtime/ArrayBuffer.h:
        * runtime/ArrayBufferView.h:
        * runtime/JSArrayBufferView.h:

2017-08-11  Ryosuke Niwa  <rniwa@webkit.org>

        Replace DATA_TRANSFER_ITEMS by a runtime flag and add a stub implementation
        https://bugs.webkit.org/show_bug.cgi?id=175474
        <rdar://problem/33844628>

        Reviewed by Wenson Hsieh.

        * Configurations/FeatureDefines.xcconfig:
        * runtime/CommonIdentifiers.h:

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

        Caging shouldn't have to use a patchpoint for adding
        https://bugs.webkit.org/show_bug.cgi?id=175483

        Reviewed by Mark Lam.

        Caging involves doing a Add(ptr, largeConstant). All of B3's heuristics for how to deal with
        constants and associative operations dictate that you always want to sink constants. For example,
        Add(Add(a, constant), b) always becomes Add(Add(a, b), constant). This is profitable because in
        typical code, it reveals downstream optimizations. But it's terrible in the case of caging, because
        we want the large constant (which is shared by all caging operations) to be hoisted. Reassociating to
        sink constants obscures the constant in this case. Currently, moveConstants is not smart enough to
        reassociate, so instead of sinking largeConstant, it tries (and often fails) to sink some other
        constants instead. Without some hacks, this is a 5% Kraken regression and a 1.6% Octane regression.
        It's not clear that moveConstants could ever be smart enough to rematerialize that constant and then
        hoist it - that would require quite a bit of algebraic reasoning. But the only case we know of where
        our current constant reassociation heuristics are wrong is caging. So, we can get away with some
        hacks for just stopping B3's reassociation only in this specific case.
        
        Previously, we achieved this by concealing the Add(ptr, largeConstant) inside a patchpoint. That's
        OK, but patchpoints are expensive. They require a SharedTask instance. They require callbacks from
        the backend, including during register allocation. And they cannot be CSE'd. We do want B3 to know
        that if we cage the same pointer in two places, both places will compute the same value.
        
        This patch improves the situation by introducing the Opaque opcode. This is handled by LowerToAir as
        if it was Identity, but all prior phases treat it as an unknown pure unary idempotent operation. I.e.
        they know that Opaque(x) == Opaque(x) and that Opaque(Opaque(x)) == Opaque(x). But they don't know
        that Opaque(x) == x until LowerToAir. So, you can use Opaque exactly when you know that B3 will mess
        up your code but Air won't. (Currently we know of no cases where Air messes things up on a large
        enough scale to warrant new opcodes.)
        
        This change is perf-neutral, but may start to help as I add more uses of caged() in the FTL. It also
        makes the code a bit less ugly.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::shouldCopyPropagate):
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3Opcode.cpp:
        (WTF::printInternal):
        * b3/B3Opcode.h:
        * b3/B3ReduceStrength.cpp:
        * b3/B3Validate.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::effects const):
        (JSC::B3::Value::key const):
        (JSC::B3::Value::isFree const):
        (JSC::B3::Value::typeFor):
        * b3/B3Value.h:
        * b3/B3ValueKey.cpp:
        (JSC::B3::ValueKey::materialize const):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::caged):
        * ftl/FTLOutput.cpp:
        (JSC::FTL::Output::opaque):
        * ftl/FTLOutput.h:

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

        ScopedArguments overflow storage needs to be in the JSValue gigacage
        https://bugs.webkit.org/show_bug.cgi?id=174923

        Reviewed by Saam Barati.
        
        ScopedArguments overflow storage sits at the end of the ScopedArguments object, so we put that
        object into the JSValue gigacage.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitScopedArgumentsGetByVal):
        * runtime/ScopedArguments.h:
        (JSC::ScopedArguments::subspaceFor):
        (JSC::ScopedArguments::overflowStorage const):

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

        JSLexicalEnvironment needs to be in the JSValue gigacage
        https://bugs.webkit.org/show_bug.cgi?id=174922

        Reviewed by Michael Saboff.
        
        We can sorta random access the JSLexicalEnvironment. So, we put it in the JSValue gigacage and make
        the only random accesses use pointer caging.
        
        We don't need to do anything to normal lexical environment accesses.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
        * runtime/JSEnvironmentRecord.h:
        (JSC::JSEnvironmentRecord::subspaceFor):
        (JSC::JSEnvironmentRecord::variables):

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

        DirectArguments should be in the JSValue gigacage
        https://bugs.webkit.org/show_bug.cgi?id=174920

        Reviewed by Michael Saboff.
        
        This puts DirectArguments in a new subspace for cells that want to be in the JSValue gigacage. All
        indexed accesses to DirectArguments now do caging. get_from_arguments/put_to_arguments are exempted
        because they always operate on a DirectArguments that is pointed to directly from the stack, they are
        required to use fixed offsets, and you can only store JSValues.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnDirectArguments):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitDirectArgumentsGetByVal):
        * runtime/DirectArguments.h:
        (JSC::DirectArguments::subspaceFor):
        (JSC::DirectArguments::storage):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

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

        Unreviewed, add a FIXME.

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

2017-08-10  Sam Weinig  <sam@webkit.org>

        WTF::Function does not allow for reference / non-default constructible return types
        https://bugs.webkit.org/show_bug.cgi?id=175244

        Reviewed by Chris Dumez.

        * runtime/ArrayBuffer.cpp:
        (JSC::ArrayBufferContents::transferTo):
        Call reset(), rather than clear() to avoid the call to destroy() in clear(). The
        destroy call needed to be a no-op anyway, since the data is being moved.

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

        Gardening: fix CLoop build.
        https://bugs.webkit.org/show_bug.cgi?id=175446
        <rdar://problem/33836545>

        Not reviewed.

        * assembler/MacroAssemblerPrinter.cpp:

2017-08-08  Filip Pizlo  <fpizlo@apple.com>

        DFG should do caging
        https://bugs.webkit.org/show_bug.cgi?id=174918

        Reviewed by Saam Barati.
        
        Adds the appropriate cage() calls to the DFG, including a cageTypedArrayStorage() helper that does
        the conditional caging with a watchpoint.
        
        This might be a 1% SunSpider slow-down, but it's not clear.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
        (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
        (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
        (JSC::DFG::SpeculativeJIT::compileCreateRest):
        (JSC::DFG::SpeculativeJIT::compileSpread):
        (JSC::DFG::SpeculativeJIT::compileNewArrayWithSpread):
        (JSC::DFG::SpeculativeJIT::compileArraySlice):
        (JSC::DFG::SpeculativeJIT::compileGetButterfly):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

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

        Unreviewed, build fix for x86 GTK port
        https://bugs.webkit.org/show_bug.cgi?id=175446

        Use pushfl/popfl instead of pushfd/popfd.

        * assembler/MacroAssemblerX86Common.cpp:

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

        Make the MASM_PROBE mechanism mandatory for DFG and FTL builds.
        https://bugs.webkit.org/show_bug.cgi?id=175446
        <rdar://problem/33836545>

        Reviewed by Saam Barati.

        * assembler/AbstractMacroAssembler.h:
        * assembler/MacroAssembler.cpp:
        (JSC::MacroAssembler::probe):
        * assembler/MacroAssembler.h:
        * assembler/MacroAssemblerARM.cpp:
        (JSC::MacroAssembler::probe):
        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::trustedImm32FromPtr):
        * assembler/MacroAssemblerARM64.cpp:
        (JSC::MacroAssembler::probe):
        * assembler/MacroAssemblerARMv7.cpp:
        (JSC::MacroAssembler::probe):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::trustedImm32FromPtr):
        * assembler/MacroAssemblerPrinter.cpp:
        * assembler/MacroAssemblerPrinter.h:
        * assembler/MacroAssemblerX86Common.cpp:
        * assembler/testmasm.cpp:
        (JSC::isSpecialGPR):
        (JSC::testProbeModifiesProgramCounter):
        (JSC::run):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::print):
        * b3/air/AirPrintSpecial.cpp:
        * b3/air/AirPrintSpecial.h:

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

        Apply the UNLIKELY macro to some unlikely things.
        https://bugs.webkit.org/show_bug.cgi?id=175440
        <rdar://problem/33834767>

        Reviewed by Yusuke Suzuki.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::~CodeBlock):
        (JSC::CodeBlock::jettison):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleCall):
        (JSC::DFG::ByteCodeParser::handleVarargsCall):
        (JSC::DFG::ByteCodeParser::handleGetById):
        (JSC::DFG::ByteCodeParser::handlePutById):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::parseCodeBlock):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::JITCompiler):
        (JSC::DFG::JITCompiler::linkOSRExits):
        (JSC::DFG::JITCompiler::link):
        (JSC::DFG::JITCompiler::disassemble):
        * dfg/DFGJITFinalizer.cpp:
        (JSC::DFG::JITFinalizer::finalizeCommon):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::compileOSRExit):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::Plan):
        * ftl/FTLJITFinalizer.cpp:
        (JSC::FTL::JITFinalizer::finalizeCommon):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::compileWithoutLinking):
        (JSC::JIT::link):
        * runtime/ScriptExecutable.cpp:
        (JSC::ScriptExecutable::installCode):
        * runtime/VM.cpp:
        (JSC::VM::VM):

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

        [WTF] ThreadSpecific should not introduce additional indirection
        https://bugs.webkit.org/show_bug.cgi?id=175187

        Reviewed by Mark Lam.

        * runtime/Identifier.cpp:

2017-08-10  Tim Horton  <timothy_horton@apple.com>

        Remove some unused lambda captures so that WebKit builds with -Wunused-lambda-capture
        https://bugs.webkit.org/show_bug.cgi?id=175436
        <rdar://problem/33667497>

        Reviewed by Simon Fraser.

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

2017-08-10  Michael Catanzaro  <mcatanzaro@igalia.com>

        Remove ENABLE_GAMEPAD_DEPRECATED
        https://bugs.webkit.org/show_bug.cgi?id=175361

        Reviewed by Carlos Garcia Campos.

        * Configurations/FeatureDefines.xcconfig:

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

        [JSC] Create JSSet constructor that accepts it's size as parameter
        https://bugs.webkit.org/show_bug.cgi?id=173297

        Reviewed by Saam Barati.

        This patch is adding a new constructor to JSSet that gives its
        expected initial size. It is important to avoid re-hashing and mutiple
        allocations when we know the final size of JSSet, such as in
        CodeBlock::setConstantIdentifierSetRegisters.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::setConstantIdentifierSetRegisters):
        * runtime/HashMapImpl.h:
        (JSC::HashMapImpl::HashMapImpl):
        * runtime/JSSet.h:

2017-08-09  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r220466, r220477, and r220487.
        https://bugs.webkit.org/show_bug.cgi?id=175411

        This change broke existing API tests and follow up fixes did
        not resolve all the issues. (Requested by ryanhaddad on
        #webkit).

        Reverted changesets:

        https://bugs.webkit.org/show_bug.cgi?id=175244
        http://trac.webkit.org/changeset/220466

        "WTF::Function does not allow for reference / non-default
        constructible return types"
        https://bugs.webkit.org/show_bug.cgi?id=175244
        http://trac.webkit.org/changeset/220477

        https://bugs.webkit.org/show_bug.cgi?id=175244
        http://trac.webkit.org/changeset/220487

2017-08-09  Caitlin Potter  <caitp@igalia.com>

        Early error on ANY operator before new.target
        https://bugs.webkit.org/show_bug.cgi?id=157970

        Reviewed by Saam Barati.

        Instead of throwing if any unary operator precedes new.target, only
        throw if the unary operator updates the reference.

        The following become legal in JSC:

        ```
        !new.target
        ~new.target
        typeof new.target
        delete new.target
        void new.target
        ```

        All of which are legal in v8 and SpiderMonkey in strict and sloppy mode

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

2017-08-09  Sam Weinig  <sam@webkit.org>

        WTF::Function does not allow for reference / non-default constructible return types
        https://bugs.webkit.org/show_bug.cgi?id=175244

        Reviewed by Chris Dumez.

        * runtime/ArrayBuffer.cpp:
        (JSC::ArrayBufferContents::transferTo):
        Call reset(), rather than clear() to avoid the call to destroy() in clear(). The
        destroy call needed to be a no-op anyway, since the data is being moved.

2017-08-09  Wenson Hsieh  <wenson_hsieh@apple.com>

        [iOS DnD] ENABLE_DRAG_SUPPORT should be turned off for iOS 10 and enabled by default
        https://bugs.webkit.org/show_bug.cgi?id=175392
        <rdar://problem/33783207>

        Reviewed by Tim Horton and Megan Gardner.

        Tweak FeatureDefines to enable drag and drop by default, and disable only on unsupported platforms (i.e. iOS 10).

        * Configurations/FeatureDefines.xcconfig:

2017-08-09  Robin Morisset  <rmorisset@apple.com>

        Make JSC_validateExceptionChecks=1 succeed on JSTests/stress/v8-deltablue-strict.js.
        https://bugs.webkit.org/show_bug.cgi?id=175358

        Reviewed by Mark Lam.

        * jit/JITOperations.cpp:
        * runtime/JSObjectInlines.h:
        (JSC::JSObject::putInlineForJSObject):

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

        Unreviewed, rolling out r220457.

        This change introduced API test failures.

        Reverted changeset:

        "WTF::Function does not allow for reference / non-default
        constructible return types"
        https://bugs.webkit.org/show_bug.cgi?id=175244
        http://trac.webkit.org/changeset/220457

2017-08-09  Sam Weinig  <sam@webkit.org>

        WTF::Function does not allow for reference / non-default constructible return types
        https://bugs.webkit.org/show_bug.cgi?id=175244

        Reviewed by Chris Dumez.

        * runtime/ArrayBuffer.cpp:
        (JSC::ArrayBufferContents::transferTo):
        Call reset(), rather than clear() to avoid the call to destroy() in clear(). The
        destroy call needed to be a no-op anyway, since the data is being moved.

2017-08-09  Oleksandr Skachkov  <gskachkov@gmail.com>

        REGRESSION: 2 test262/test/language/statements/async-function failures
        https://bugs.webkit.org/show_bug.cgi?id=175334

        Reviewed by Yusuke Suzuki.

        Switch off useAsyncIterator by default

        * runtime/Options.h:

2017-08-08  Filip Pizlo  <fpizlo@apple.com>

        ICs should do caging
        https://bugs.webkit.org/show_bug.cgi?id=175295

        Reviewed by Saam Barati.
        
        Adds the appropriate cage() calls in our inline caches.

        * bytecode/AccessCase.cpp:
        (JSC::AccessCase::generateImpl):
        * bytecode/InlineAccess.cpp:
        (JSC::InlineAccess::dumpCacheSizesAndCrash):
        (JSC::InlineAccess::generateSelfPropertyAccess):
        (JSC::InlineAccess::generateSelfPropertyReplace):
        (JSC::InlineAccess::generateArrayLength):

2017-08-08  Devin Rousso  <drousso@apple.com>

        Web Inspector: Canvas: support editing WebGL shaders
        https://bugs.webkit.org/show_bug.cgi?id=124211
        <rdar://problem/15448958>

        Reviewed by Matt Baker.

        * inspector/protocol/Canvas.json:
        Add `updateShader` command that will change the given shader's source to the provided string,
        recompile, and relink it to its associated program.
        Drive-by: add description to `requestShaderSource` command.

2017-08-08  Robin Morisset  <rmorisset@apple.com>

        Make JSC_validateExceptionChecks=1 succeed on JSTests/slowMicrobenchmarks/spread-small-array.js.
        https://bugs.webkit.org/show_bug.cgi?id=175347

        Reviewed by Saam Barati.

        This is done by making finishCreation explicitely check for exceptions after setConstantRegister and setConstantIdentifiersSetRegisters.
        I chose to have this check replace the boolean returned previously by these functions for readability. The performance impact should be
        negligible considering how much more finishCreation does.
        This fix then caused another issue to appear as it was now clear that finishCreation can throw. And since it is called by ProgramCodeBlock::create(),
        FunctionCodeBlock::create() and friends, that are in turn called by ScriptExecutable::newCodeBlockFor, this last function also required a few tweaks.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::setConstantIdentifierSetRegisters):
        (JSC::CodeBlock::setConstantRegisters):
        * bytecode/CodeBlock.h:
        * runtime/ScriptExecutable.cpp:
        (JSC::ScriptExecutable::newCodeBlockFor):

2017-08-08  Michael Catanzaro  <mcatanzaro@igalia.com>

        Unreviewed, fix Ubuntu LTS build
        https://bugs.webkit.org/show_bug.cgi?id=174490

        * inspector/remote/glib/RemoteInspectorGlib.cpp:
        * inspector/remote/glib/RemoteInspectorServer.cpp:

2017-08-08  Filip Pizlo  <fpizlo@apple.com>

        Baseline JIT should do caging
        https://bugs.webkit.org/show_bug.cgi?id=175037

        Reviewed by Mark Lam.
        
        Adds a AssemblyHelpers::cage and cageConditionally. Uses it in the baseline JIT.
        
        Also modifies FTL caging to be more defensive when caging is disabled.
        
        Relanded with fixed AssemblyHelpers::cageConditionally().

        * bytecode/AccessCase.cpp:
        (JSC::AccessCase::generateImpl):
        * bytecode/InlineAccess.cpp:
        (JSC::InlineAccess::dumpCacheSizesAndCrash):
        (JSC::InlineAccess::generateSelfPropertyAccess):
        (JSC::InlineAccess::generateSelfPropertyReplace):
        (JSC::InlineAccess::generateArrayLength):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::caged):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::cage):
        (JSC::AssemblyHelpers::cageConditionally):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitDoubleLoad):
        (JSC::JIT::emitContiguousLoad):
        (JSC::JIT::emitArrayStorageLoad):
        (JSC::JIT::emitGenericContiguousPutByVal):
        (JSC::JIT::emitArrayStoragePutByVal):
        (JSC::JIT::emit_op_get_from_scope):
        (JSC::JIT::emit_op_put_to_scope):
        (JSC::JIT::emitIntTypedArrayGetByVal):
        (JSC::JIT::emitFloatTypedArrayGetByVal):
        (JSC::JIT::emitIntTypedArrayPutByVal):
        (JSC::JIT::emitFloatTypedArrayPutByVal):
        * jsc.cpp:
        (jscmain):
        (primitiveGigacageDisabled): Deleted.

2017-08-08  Ryan Haddad  <ryanhaddad@apple.com>

        Unreviewed, rolling out r220368.

        This change caused WK1 tests to exit early with crashes.

        Reverted changeset:

        "Baseline JIT should do caging"
        https://bugs.webkit.org/show_bug.cgi?id=175037
        http://trac.webkit.org/changeset/220368

2017-08-08  Michael Catanzaro  <mcatanzaro@igalia.com>

        [CMake] Properly test if compiler supports compiler flags
        https://bugs.webkit.org/show_bug.cgi?id=174490

        Reviewed by Konstantin Tokarev.

        * API/tests/PingPongStackOverflowTest.cpp:
        (testPingPongStackOverflow):
        * API/tests/testapi.c:
        * b3/testb3.cpp:
        (JSC::B3::testPatchpointLotsOfLateAnys):

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

        [Linux] Clear WasmMemory with madvice instead of memset
        https://bugs.webkit.org/show_bug.cgi?id=175150

        Reviewed by Filip Pizlo.

        In Linux, zeroing pages with memset populates backing store.
        Instead, we should use madvise with MADV_DONTNEED. It discards
        pages. And if you access these pages, on-demand-zero-pages will
        be shown.

        We also commit grown pages in all OSes.

        * wasm/WasmMemory.cpp:
        (JSC::Wasm::commitZeroPages):
        (JSC::Wasm::Memory::create):
        (JSC::Wasm::Memory::grow):

2017-08-07  Robin Morisset  <rmorisset@apple.com>

        GetOwnProperty of TypedArray indexed fields is wrongly configurable
        https://bugs.webkit.org/show_bug.cgi?id=175307

        Reviewed by Saam Barati.

        ```
        let a = new Uint8Array(10);
        let b = Object.getOwnPropertyDescriptor(a, 0);
        assert(b.configurable === false);
        ```
        should not fail: by section 9.4.5.1 (https://tc39.github.io/ecma262/#sec-integer-indexed-exotic-objects-getownproperty-p) 
        that applies to integer indexed exotic objects, and section 22.2.7 (https://tc39.github.io/ecma262/#sec-properties-of-typedarray-instances)
        that says that typed arrays are integer indexed exotic objects.

        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlotByIndex):

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

        Baseline JIT should do caging
        https://bugs.webkit.org/show_bug.cgi?id=175037

        Reviewed by Mark Lam.
        
        Adds a AssemblyHelpers::cage and cageConditionally. Uses it in the baseline JIT.
        
        Also modifies FTL caging to be more defensive when caging is disabled.

        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::caged):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::cage):
        (JSC::AssemblyHelpers::cageConditionally):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitDoubleLoad):
        (JSC::JIT::emitContiguousLoad):
        (JSC::JIT::emitArrayStorageLoad):
        (JSC::JIT::emitGenericContiguousPutByVal):
        (JSC::JIT::emitArrayStoragePutByVal):
        (JSC::JIT::emit_op_get_from_scope):
        (JSC::JIT::emit_op_put_to_scope):
        (JSC::JIT::emitIntTypedArrayGetByVal):
        (JSC::JIT::emitFloatTypedArrayGetByVal):
        (JSC::JIT::emitIntTypedArrayPutByVal):
        (JSC::JIT::emitFloatTypedArrayPutByVal):
        * jsc.cpp:
        (jscmain):
        (primitiveGigacageDisabled): Deleted.

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

        Primitive auxiliaries and JSValue auxiliaries should have separate gigacages
        https://bugs.webkit.org/show_bug.cgi?id=174919

        Reviewed by Keith Miller.
        
        This adapts JSC to there being two gigacages.
        
        To make matters simpler, this turns AlignedMemoryAllocators into per-VM instances rather than
        singletons. I don't think we were gaining anything by making them be singletons.
        
        This makes it easy to teach GigacageAlignedMemoryAllocator that there are multiple kinds of
        gigacages. We'll have one of those allocators per cage.
        
        From there, this change teaches everyone who previously knew about cages that there are two cages.
        This means having to specify either Gigacage::Primitive or Gigacage::JSValue. In most places, this is
        easy: typed arrays are Primitive and butterflies are JSValue. But there are a few places where it's
        not so obvious, so this change introduces some helpers to make it easy to define what cage you want
        to use in one place and refer to it abstractly. We do this in DirectArguments and GenericArguments.h
        
        A lot of the magic of this change is due to CagedBarrierPtr, which combines AuxiliaryBarrier and
        CagedPtr. This removes one layer of "get()" calls from a bunch of places.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/AccessCase.cpp:
        (JSC::AccessCase::generateImpl):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
        (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
        (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
        (JSC::DFG::SpeculativeJIT::compileNewTypedArray):
        (JSC::DFG::SpeculativeJIT::emitAllocateButterfly):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileGetButterfly):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetDirectPname):
        (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
        (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorageWithSizeImpl):
        (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
        (JSC::FTL::DFG::LowerDFGToB3::caged):
        * heap/FastMallocAlignedMemoryAllocator.cpp:
        (JSC::FastMallocAlignedMemoryAllocator::instance): Deleted.
        * heap/FastMallocAlignedMemoryAllocator.h:
        * heap/GigacageAlignedMemoryAllocator.cpp:
        (JSC::GigacageAlignedMemoryAllocator::GigacageAlignedMemoryAllocator):
        (JSC::GigacageAlignedMemoryAllocator::tryAllocateAlignedMemory):
        (JSC::GigacageAlignedMemoryAllocator::freeAlignedMemory):
        (JSC::GigacageAlignedMemoryAllocator::dump const):
        (JSC::GigacageAlignedMemoryAllocator::instance): Deleted.
        * heap/GigacageAlignedMemoryAllocator.h:
        * jsc.cpp:
        (primitiveGigacageDisabled):
        (jscmain):
        (gigacageDisabled): Deleted.
        * llint/LowLevelInterpreter64.asm:
        * runtime/ArrayBuffer.cpp:
        (JSC::ArrayBufferContents::tryAllocate):
        (JSC::ArrayBuffer::createAdopted):
        (JSC::ArrayBuffer::createFromBytes):
        * runtime/AuxiliaryBarrier.h:
        * runtime/ButterflyInlines.h:
        (JSC::Butterfly::createUninitialized):
        (JSC::Butterfly::tryCreate):
        (JSC::Butterfly::growArrayRight):
        * runtime/CagedBarrierPtr.h: Added.
        (JSC::CagedBarrierPtr::CagedBarrierPtr):
        (JSC::CagedBarrierPtr::clear):
        (JSC::CagedBarrierPtr::set):
        (JSC::CagedBarrierPtr::get const):
        (JSC::CagedBarrierPtr::getMayBeNull const):
        (JSC::CagedBarrierPtr::operator== const):
        (JSC::CagedBarrierPtr::operator!= const):
        (JSC::CagedBarrierPtr::operator bool const):
        (JSC::CagedBarrierPtr::setWithoutBarrier):
        (JSC::CagedBarrierPtr::operator* const):
        (JSC::CagedBarrierPtr::operator-> const):
        (JSC::CagedBarrierPtr::operator[] const):
        * runtime/DirectArguments.cpp:
        (JSC::DirectArguments::overrideThings):
        (JSC::DirectArguments::unmapArgument):
        * runtime/DirectArguments.h:
        (JSC::DirectArguments::isMappedArgument const):
        * runtime/GenericArguments.h:
        * runtime/GenericArgumentsInlines.h:
        (JSC::GenericArguments<Type>::initModifiedArgumentsDescriptor):
        (JSC::GenericArguments<Type>::setModifiedArgumentDescriptor):
        (JSC::GenericArguments<Type>::isModifiedArgumentDescriptor):
        * runtime/HashMapImpl.cpp:
        (JSC::HashMapImpl<HashMapBucket>::visitChildren):
        * runtime/HashMapImpl.h:
        (JSC::HashMapBuffer::create):
        (JSC::HashMapImpl::buffer const):
        (JSC::HashMapImpl::rehash):
        * runtime/JSArray.cpp:
        (JSC::JSArray::tryCreateUninitializedRestricted):
        (JSC::JSArray::unshiftCountSlowCase):
        (JSC::JSArray::setLength):
        (JSC::JSArray::pop):
        (JSC::JSArray::push):
        (JSC::JSArray::fastSlice):
        (JSC::JSArray::shiftCountWithArrayStorage):
        (JSC::JSArray::shiftCountWithAnyIndexingType):
        (JSC::JSArray::unshiftCountWithAnyIndexingType):
        (JSC::JSArray::fillArgList):
        (JSC::JSArray::copyToArguments):
        * runtime/JSArray.h:
        (JSC::JSArray::tryCreate):
        * runtime/JSArrayBufferView.cpp:
        (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
        (JSC::JSArrayBufferView::finalize):
        * runtime/JSLock.cpp:
        (JSC::JSLock::didAcquireLock):
        * runtime/JSObject.cpp:
        (JSC::JSObject::heapSnapshot):
        (JSC::JSObject::getOwnPropertySlotByIndex):
        (JSC::JSObject::putByIndex):
        (JSC::JSObject::enterDictionaryIndexingMode):
        (JSC::JSObject::createInitialIndexedStorage):
        (JSC::JSObject::createArrayStorage):
        (JSC::JSObject::convertUndecidedToInt32):
        (JSC::JSObject::convertUndecidedToDouble):
        (JSC::JSObject::convertUndecidedToContiguous):
        (JSC::JSObject::constructConvertedArrayStorageWithoutCopyingElements):
        (JSC::JSObject::convertUndecidedToArrayStorage):
        (JSC::JSObject::convertInt32ToDouble):
        (JSC::JSObject::convertInt32ToContiguous):
        (JSC::JSObject::convertInt32ToArrayStorage):
        (JSC::JSObject::convertDoubleToContiguous):
        (JSC::JSObject::convertDoubleToArrayStorage):
        (JSC::JSObject::convertContiguousToArrayStorage):
        (JSC::JSObject::setIndexQuicklyToUndecided):
        (JSC::JSObject::ensureArrayStorageExistsAndEnterDictionaryIndexingMode):
        (JSC::JSObject::deletePropertyByIndex):
        (JSC::JSObject::getOwnPropertyNames):
        (JSC::JSObject::putIndexedDescriptor):
        (JSC::JSObject::defineOwnIndexedProperty):
        (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes):
        (JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength):
        (JSC::JSObject::getNewVectorLength):
        (JSC::JSObject::ensureLengthSlow):
        (JSC::JSObject::reallocateAndShrinkButterfly):
        (JSC::JSObject::allocateMoreOutOfLineStorage):
        (JSC::JSObject::getEnumerableLength):
        * runtime/JSObject.h:
        (JSC::JSObject::getArrayLength const):
        (JSC::JSObject::getVectorLength):
        (JSC::JSObject::putDirectIndex):
        (JSC::JSObject::canGetIndexQuickly):
        (JSC::JSObject::getIndexQuickly):
        (JSC::JSObject::tryGetIndexQuickly const):
        (JSC::JSObject::canSetIndexQuickly):
        (JSC::JSObject::setIndexQuickly):
        (JSC::JSObject::initializeIndex):
        (JSC::JSObject::initializeIndexWithoutBarrier):
        (JSC::JSObject::hasSparseMap):
        (JSC::JSObject::inSparseIndexingMode):
        (JSC::JSObject::butterfly const):
        (JSC::JSObject::butterfly):
        (JSC::JSObject::outOfLineStorage const):
        (JSC::JSObject::outOfLineStorage):
        (JSC::JSObject::ensureInt32):
        (JSC::JSObject::ensureDouble):
        (JSC::JSObject::ensureContiguous):
        (JSC::JSObject::ensureArrayStorage):
        (JSC::JSObject::arrayStorage):
        (JSC::JSObject::arrayStorageOrNull):
        (JSC::JSObject::ensureLength):
        * runtime/RegExpMatchesArray.h:
        (JSC::tryCreateUninitializedRegExpMatchesArray):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::~VM):
        (JSC::VM::primitiveGigacageDisabledCallback):
        (JSC::VM::primitiveGigacageDisabled):
        (JSC::VM::gigacageDisabledCallback): Deleted.
        (JSC::VM::gigacageDisabled): Deleted.
        * runtime/VM.h:
        (JSC::VM::gigacageAuxiliarySpace):
        (JSC::VM::firePrimitiveGigacageEnabledIfNecessary):
        (JSC::VM::primitiveGigacageEnabled):
        (JSC::VM::fireGigacageEnabledIfNecessary): Deleted.
        (JSC::VM::gigacageEnabled): Deleted.
        * wasm/WasmMemory.cpp:
        (JSC::Wasm::Memory::create):
        (JSC::Wasm::Memory::~Memory):
        (JSC::Wasm::Memory::grow):

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

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

        "It did not actually speed things up in the way I expected"
        (Requested by saamyjoon on #webkit).

        Reverted changeset:

        "On memory-constrained iOS devices, reduce the rate at which
        the JS heap grows before a GC to try to keep more memory
        available for the system"
        https://bugs.webkit.org/show_bug.cgi?id=175041
        http://trac.webkit.org/changeset/220144

2017-08-07  Ryan Haddad  <ryanhaddad@apple.com>

        Unreviewed, rolling out r220299.

        This change caused LayoutTest inspector/dom-debugger/dom-
        breakpoints.html to fail.

        Reverted changeset:

        "Web Inspector: capture async stack trace when workers/main
        context posts a message"
        https://bugs.webkit.org/show_bug.cgi?id=167084
        http://trac.webkit.org/changeset/220299

2017-08-07  Brian Burg  <bburg@apple.com>

        Remove CANVAS_PATH compilation guard
        https://bugs.webkit.org/show_bug.cgi?id=175207

        Reviewed by Sam Weinig.

        * Configurations/FeatureDefines.xcconfig:

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

        REGRESSION: wasm.yaml/wasm/js-api/dont-mmap-zero-byte-memory.js failing on JSC Debug bots
        https://bugs.webkit.org/show_bug.cgi?id=175256

        Reviewed by Saam Barati.

        The check in createFromBytes just needed to check that the buffer was not null before
        calling isCaged.

        * runtime/ArrayBuffer.cpp:
        (JSC::ArrayBuffer::createFromBytes):

2017-08-05  Carlos Garcia Campos  <cgarcia@igalia.com>

        [GTK][WPE] Add API to provide browser information required by automation
        https://bugs.webkit.org/show_bug.cgi?id=175130

        Reviewed by Brian Burg.

        Add browserName and browserVersion to RemoteInspector::Client::Capabilities and virtual methods to the Client to
        get them.

        * inspector/remote/RemoteInspector.cpp:
        (Inspector::RemoteInspector::updateClientCapabilities): Update also browserName and browserVersion.
        * inspector/remote/RemoteInspector.h:
        * inspector/remote/glib/RemoteInspectorGlib.cpp:
        (Inspector::RemoteInspector::requestAutomationSession): Call updateClientCapabilities() after the session is
        requested to ensure they are updated before StartAutomationSession reply is sent.
        * inspector/remote/glib/RemoteInspectorServer.cpp: Add browserName and browserVersion as return values of
        StartAutomationSession mesasage.

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

        Promise resolve and reject function should have length = 1
        https://bugs.webkit.org/show_bug.cgi?id=175242

        Reviewed by Saam Barati.

        Previously we have separate system for "length" and "name" for builtin functions.
        The builtin functions do not use lazy reifying system. Instead, they have direct
        properties when instantiating it. While the function created for properties (like
        Array.prototype.filter) is created by JSFunction::createBuiltin(), function inside
        these builtin functions are just created by JSFunction::create(). Since it does
        not set any values for "length", these functions do not have "length" property.
        So, the resolve and reject functions passed to Promise's executor do not have
        "length" property.

        This patch make builtin functions use standard lazy reifying system for "length".
        So, "length" property of the builtin function just works as if the normal functions
        do.

        * runtime/JSFunction.cpp:
        (JSC::JSFunction::createBuiltinFunction):
        (JSC::JSFunction::getOwnPropertySlot):
        (JSC::JSFunction::getOwnNonIndexPropertyNames):
        (JSC::JSFunction::put):
        (JSC::JSFunction::deleteProperty):
        (JSC::JSFunction::defineOwnProperty):
        (JSC::JSFunction::reifyLazyPropertyIfNeeded):
        (JSC::JSFunction::reifyLazyPropertyForHostOrBuiltinIfNeeded):
        (JSC::JSFunction::reifyLazyLengthIfNeeded):
        (JSC::JSFunction::reifyLazyBoundNameIfNeeded):
        (JSC::JSFunction::reifyBoundNameIfNeeded): Deleted.
        * runtime/JSFunction.h:

2017-08-06  Oleksandr Skachkov  <gskachkov@gmail.com>

        [ESNext] Async iteration - Implement Async Generator - parser
        https://bugs.webkit.org/show_bug.cgi?id=175210

        Reviewed by Yusuke Suzuki.

        Current implementation is draft version of Async Iteration. 
        Link to spec https://tc39.github.io/proposal-async-iteration/

        Current patch implement only parser part of the Async generator
        Runtime part will be in next ptches

        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createFunctionMetadata):
        * parser/Parser.cpp:
        (JSC::getAsynFunctionBodyParseMode):
        (JSC::Parser<LexerType>::parseInner):
        (JSC::Parser<LexerType>::parseAsyncFunctionSourceElements):
        (JSC::Parser<LexerType>::parseAsyncGeneratorFunctionSourceElements):
        (JSC::stringArticleForFunctionMode):
        (JSC::stringForFunctionMode):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseAsyncFunctionDeclaration):
        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parseProperty):
        (JSC::Parser<LexerType>::parsePropertyMethod):
        (JSC::Parser<LexerType>::parseAsyncFunctionExpression):
        * parser/Parser.h:
        (JSC::Scope::setSourceParseMode):
        * parser/ParserModes.h:
        (JSC::isFunctionParseMode):
        (JSC::isAsyncFunctionParseMode):
        (JSC::isAsyncArrowFunctionParseMode):
        (JSC::isAsyncGeneratorFunctionParseMode):
        (JSC::isAsyncFunctionOrAsyncGeneratorWrapperParseMode):
        (JSC::isAsyncFunctionWrapperParseMode):
        (JSC::isAsyncFunctionBodyParseMode):
        (JSC::isGeneratorMethodParseMode):
        (JSC::isAsyncMethodParseMode):
        (JSC::isAsyncGeneratorMethodParseMode):
        (JSC::isMethodParseMode):
        (JSC::isGeneratorOrAsyncFunctionBodyParseMode):
        (JSC::isGeneratorOrAsyncFunctionWrapperParseMode):

2017-08-05  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION (r219895-219897): Number of leaks on Open Source went from 9240 to 235983 and is now at 302372
        https://bugs.webkit.org/show_bug.cgi?id=175083

        Reviewed by Oliver Hunt.
        
        This fixes the leak by making MarkedBlock::specializedSweep call destructors when the block is empty,
        even if we are using the pop path.
        
        Also, this fixes HeapCellInlines.h to no longer include MarkedBlockInlines.h. That's pretty
        important, since MarkedBlockInlines.h is the GC's internal guts - we don't want to have to recompile
        the world just because we changed it.
        
        Finally, this adds a new testing SPI for waiting for all VMs to finish destructing. This makes it
        easier to debug leaks.

        * bytecode/AccessCase.cpp:
        * bytecode/PolymorphicAccess.cpp:
        * heap/HeapCell.cpp:
        (JSC::HeapCell::isLive):
        * heap/HeapCellInlines.h:
        (JSC::HeapCell::isLive): Deleted.
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::tryAllocateWithoutCollecting):
        (JSC::MarkedAllocator::endMarking):
        * heap/MarkedBlockInlines.h:
        (JSC::MarkedBlock::Handle::specializedSweep):
        * jit/AssemblyHelpers.cpp:
        * jit/Repatch.cpp:
        * runtime/TestRunnerUtils.h:
        * runtime/VM.cpp:
        (JSC::waitForVMDestruction):
        (JSC::VM::~VM):

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

        Move DFG::OSRExitCompiler methods into DFG::OSRExit [step 3].
        https://bugs.webkit.org/show_bug.cgi?id=175228
        <rdar://problem/33735737>

        Reviewed by Saam Barati.

        Merge the 32-bit OSRExit::compileExit() method into the 64-bit version, and
        delete OSRExit32_64.cpp.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::compileExit):
        * dfg/DFGOSRExit32_64.cpp: Removed.
        * jit/GPRInfo.h:
        (JSC::JSValueSource::payloadGPR const):

2017-08-04  Youenn Fablet  <youenn@apple.com>

        [Cache API] Add Cache and CacheStorage IDL definitions
        https://bugs.webkit.org/show_bug.cgi?id=175201

        Reviewed by Brady Eidson.

        * runtime/CommonIdentifiers.h:

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

        Fix typo in testmasm.cpp: ENABLE(JSVALUE64) should be USE(JSVALUE64).
        https://bugs.webkit.org/show_bug.cgi?id=175230
        <rdar://problem/33735857>

        Reviewed by Saam Barati.

        * assembler/testmasm.cpp:
        (JSC::testProbeReadsArgumentRegisters):
        (JSC::testProbeWritesArgumentRegisters):

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

        Move DFG::OSRExitCompiler methods into DFG::OSRExit [step 2].
        https://bugs.webkit.org/show_bug.cgi?id=175214
        <rdar://problem/33733308>

        Rubber-stamped by Michael Saboff.

        Copy the 64-bit and common methods into DFGOSRExit.cpp, and delete the unused
        DFGOSRExitCompiler files.

        Also renamed DFGOSRExitCompiler32_64.cpp to DFGOSRExit32_64.cpp.

        Also move debugOperationPrintSpeculationFailure() into DFGOSRExit.cpp.  It's only
        used by compileOSRExit(), and will be changed to not be a DFG operation function
        when we use JIT probes for DFG OSR exits later in
        https://bugs.webkit.org/show_bug.cgi?id=175144.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGJITCompiler.cpp:
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::emitRestoreArguments):
        (JSC::DFG::OSRExit::compileOSRExit):
        (JSC::DFG::OSRExit::compileExit):
        (JSC::DFG::OSRExit::debugOperationPrintSpeculationFailure):
        * dfg/DFGOSRExit.h:
        * dfg/DFGOSRExit32_64.cpp: Copied from Source/JavaScriptCore/dfg/DFGOSRExitCompiler32_64.cpp.
        * dfg/DFGOSRExitCompiler.cpp: Removed.
        * dfg/DFGOSRExitCompiler.h: Removed.
        * dfg/DFGOSRExitCompiler32_64.cpp: Removed.
        * dfg/DFGOSRExitCompiler64.cpp: Removed.
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGThunks.cpp:

2017-08-04  Matt Baker  <mattbaker@apple.com>

        Web Inspector: capture async stack trace when workers/main context posts a message
        https://bugs.webkit.org/show_bug.cgi?id=167084
        <rdar://problem/30033673>

        Reviewed by Brian Burg.

        * inspector/agents/InspectorDebuggerAgent.h:
        Add `PostMessage` async call type.

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

        Move DFG::OSRExitCompiler methods into DFG::OSRExit [step 1].
        https://bugs.webkit.org/show_bug.cgi?id=175208
        <rdar://problem/33732402>

        Reviewed by Saam Barati.

        This will minimize the code diff and make it easier to review the patch for
        https://bugs.webkit.org/show_bug.cgi?id=175144 later.  We'll do this patch in 3
        steps:

        1. Do the code changes to move methods into OSRExit.
        2. Copy the 64-bit and common methods into DFGOSRExit.cpp, and delete the unused DFGOSRExitCompiler files.
        3. Merge the 32-bit OSRExitCompiler methods into the 64-bit version, and delete DFGOSRExitCompiler32_64.cpp.

        Splitting this refactoring into these 3 steps also makes it easier to review this
        patch and understand what is being changed.

        * dfg/DFGOSRExit.h:
        * dfg/DFGOSRExitCompiler.cpp:
        (JSC::DFG::OSRExit::emitRestoreArguments):
        (JSC::DFG::OSRExit::compileOSRExit):
        (JSC::DFG::OSRExitCompiler::emitRestoreArguments): Deleted.
        (): Deleted.
        * dfg/DFGOSRExitCompiler.h:
        (JSC::DFG::OSRExitCompiler::OSRExitCompiler): Deleted.
        (): Deleted.
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExit::compileExit):
        (JSC::DFG::OSRExitCompiler::compileExit): Deleted.
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExit::compileExit):
        (JSC::DFG::OSRExitCompiler::compileExit): Deleted.
        * dfg/DFGThunks.cpp:
        (JSC::DFG::osrExitGenerationThunkGenerator):

2017-08-04  Devin Rousso  <drousso@apple.com>

        Web Inspector: add source view for WebGL shader programs
        https://bugs.webkit.org/show_bug.cgi?id=138593
        <rdar://problem/18936194>

        Reviewed by Matt Baker.

        * inspector/protocol/Canvas.json:
         - Add `ShaderType` enum that contains "vertex" and "fragment".
         - Add `requestShaderSource` command that will return the original source code for a given
           shader program and shader type.

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

        The allocator used to allocate memory for MarkedBlocks and LargeAllocations should not be the Subspace itself
        https://bugs.webkit.org/show_bug.cgi?id=175141

        Reviewed by Mark Lam.
        
        To make it easier to have multiple gigacages and maybe even fancier methods of allocating, this
        decouples the allocator used to allocate memory from the GC Subspace. This means we no longer have
        to create a new Subspace subclass to allocate memory a different way. Instead, the allocator is now
        determined by the AlignedMemoryAllocator object.
        
        This also simplifies trading of blocks. Before, Subspaces had to determine if other Subspaces could
        trade blocks with them using canTradeBlocksWith(). This makes it difficult for two different
        Subspaces that both use the same underlying allocator to realize that they can trade blocks with
        each other. Now, you just need to ask the block being stolen and the subspace doing the stealing if
        they use the same AlignedMemoryAllocator.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/AlignedMemoryAllocator.cpp: Added.
        (JSC::AlignedMemoryAllocator::AlignedMemoryAllocator):
        (JSC::AlignedMemoryAllocator::~AlignedMemoryAllocator):
        * heap/AlignedMemoryAllocator.h: Added.
        * heap/FastMallocAlignedMemoryAllocator.cpp: Added.
        (JSC::FastMallocAlignedMemoryAllocator::singleton):
        (JSC::FastMallocAlignedMemoryAllocator::FastMallocAlignedMemoryAllocator):
        (JSC::FastMallocAlignedMemoryAllocator::~FastMallocAlignedMemoryAllocator):
        (JSC::FastMallocAlignedMemoryAllocator::tryAllocateAlignedMemory):
        (JSC::FastMallocAlignedMemoryAllocator::freeAlignedMemory):
        (JSC::FastMallocAlignedMemoryAllocator::dump const):
        * heap/FastMallocAlignedMemoryAllocator.h: Added.
        * heap/GigacageAlignedMemoryAllocator.cpp: Added.
        (JSC::GigacageAlignedMemoryAllocator::singleton):
        (JSC::GigacageAlignedMemoryAllocator::GigacageAlignedMemoryAllocator):
        (JSC::GigacageAlignedMemoryAllocator::~GigacageAlignedMemoryAllocator):
        (JSC::GigacageAlignedMemoryAllocator::tryAllocateAlignedMemory):
        (JSC::GigacageAlignedMemoryAllocator::freeAlignedMemory):
        (JSC::GigacageAlignedMemoryAllocator::dump const):
        * heap/GigacageAlignedMemoryAllocator.h: Added.
        * heap/GigacageSubspace.cpp: Removed.
        * heap/GigacageSubspace.h: Removed.
        * heap/LargeAllocation.cpp:
        (JSC::LargeAllocation::tryCreate):
        (JSC::LargeAllocation::destroy):
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::tryAllocateWithoutCollecting):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::tryCreate):
        (JSC::MarkedBlock::Handle::Handle):
        (JSC::MarkedBlock::Handle::~Handle):
        (JSC::MarkedBlock::Handle::didAddToAllocator):
        (JSC::MarkedBlock::Handle::subspace const):
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::Handle::alignedMemoryAllocator const):
        (JSC::MarkedBlock::Handle::subspace const): Deleted.
        * heap/Subspace.cpp:
        (JSC::Subspace::Subspace):
        (JSC::Subspace::findEmptyBlockToSteal):
        (JSC::Subspace::canTradeBlocksWith): Deleted.
        (JSC::Subspace::tryAllocateAlignedMemory): Deleted.
        (JSC::Subspace::freeAlignedMemory): Deleted.
        * heap/Subspace.h:
        (JSC::Subspace::name const):
        (JSC::Subspace::alignedMemoryAllocator const):
        * runtime/JSDestructibleObjectSubspace.cpp:
        (JSC::JSDestructibleObjectSubspace::JSDestructibleObjectSubspace):
        * runtime/JSDestructibleObjectSubspace.h:
        * runtime/JSSegmentedVariableObjectSubspace.cpp:
        (JSC::JSSegmentedVariableObjectSubspace::JSSegmentedVariableObjectSubspace):
        * runtime/JSSegmentedVariableObjectSubspace.h:
        * runtime/JSStringSubspace.cpp:
        (JSC::JSStringSubspace::JSStringSubspace):
        * runtime/JSStringSubspace.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        * wasm/js/JSWebAssemblyCodeBlockSubspace.cpp:
        (JSC::JSWebAssemblyCodeBlockSubspace::JSWebAssemblyCodeBlockSubspace):
        * wasm/js/JSWebAssemblyCodeBlockSubspace.h:

2017-08-04  Oleksandr Skachkov  <gskachkov@gmail.com>

        [ESNext] Async iteration - update feature.json
        https://bugs.webkit.org/show_bug.cgi?id=175197

        Reviewed by Yusuke Suzuki.

        Update feature.json to add status of the Async Iteration

        * features.json:

2017-08-04  Matt Lewis  <jlewis3@apple.com>

        Unreviewed, rolling out r220271.

        Rolling out due to Layout Test failing on iOS Simulator.

        Reverted changeset:

        "Remove STREAMS_API compilation guard"
        https://bugs.webkit.org/show_bug.cgi?id=175165
        http://trac.webkit.org/changeset/220271

2017-08-04  Youenn Fablet  <youenn@apple.com>

        Remove STREAMS_API compilation guard
        https://bugs.webkit.org/show_bug.cgi?id=175165

        Reviewed by Darin Adler.

        * Configurations/FeatureDefines.xcconfig:

2017-08-04  Oleksandr Skachkov  <gskachkov@gmail.com>

        [EsNext] Async iteration - Add feature flag
        https://bugs.webkit.org/show_bug.cgi?id=166694

        Reviewed by Yusuke Suzuki.

        Add feature flag to JSC to switch on/off Async Iterator

        * runtime/Options.h:

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

        Remove ENABLE(WEB_SOCKET) guards
        https://bugs.webkit.org/show_bug.cgi?id=167044

        Reviewed by Joseph Pecoraro.

        * Configurations/FeatureDefines.xcconfig:

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

        Remove FETCH_API compilation guard
        https://bugs.webkit.org/show_bug.cgi?id=175154

        Reviewed by Chris Dumez.

        * Configurations/FeatureDefines.xcconfig:

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

        Web Inspector: Instrument WebGLProgram created/deleted
        https://bugs.webkit.org/show_bug.cgi?id=175059

        Reviewed by Devin Rousso.

        Extend the Canvas protocol with types/events for tracking WebGLPrograms.

        * inspector/protocol/Canvas.json:

2017-08-03  Brady Eidson  <beidson@apple.com>

        Add SW IDLs and stub out basic functionality.
        https://bugs.webkit.org/show_bug.cgi?id=175115

        Reviewed by Chris Dumez.

        * Configurations/FeatureDefines.xcconfig:

        * runtime/CommonIdentifiers.h:

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

        Rename ScratchBuffer::activeLengthPtr to addressOfActiveLength.
        https://bugs.webkit.org/show_bug.cgi?id=175142
        <rdar://problem/33704528>

        Reviewed by Filip Pizlo.

        The convention in the rest of of JSC for such methods which return the address of
        a field is to name them "addressOf<field name>".  We'll rename
        ScratchBuffer::activeLengthPtr to be consistent with this convention.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNewArrayWithSpread):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGThunks.cpp:
        (JSC::DFG::osrExitGenerationThunkGenerator):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArray):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread):
        * ftl/FTLThunks.cpp:
        (JSC::FTL::genericGenerationThunkGenerator):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::debugCall):
        * jit/ScratchRegisterAllocator.cpp:
        (JSC::ScratchRegisterAllocator::preserveUsedRegistersToScratchBufferForCall):
        (JSC::ScratchRegisterAllocator::restoreUsedRegistersFromScratchBufferForCall):
        * runtime/VM.h:
        (JSC::ScratchBuffer::addressOfActiveLength):
        (JSC::ScratchBuffer::activeLengthPtr): Deleted.
        * wasm/WasmBinding.cpp:
        (JSC::Wasm::wasmToJs):

2017-08-02  Devin Rousso  <drousso@apple.com>

        Web Inspector: add stack trace information for each RecordingAction
        https://bugs.webkit.org/show_bug.cgi?id=174663

        Reviewed by Joseph Pecoraro.

        * inspector/ScriptCallFrame.h:
        Add `operator==` so that when a ScriptCallFrame object is held in a Vector, calling `find`
        with an existing value doesn't need require a functor and can use existing code.

        * interpreter/StackVisitor.h:
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::isWasmFrame const): Inlined in header.

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

        Merge WTFThreadData to Thread::current
        https://bugs.webkit.org/show_bug.cgi?id=174716

        Reviewed by Mark Lam.

        Use Thread::current() instead.

        * API/JSContext.mm:
        (+[JSContext currentContext]):
        (+[JSContext currentThis]):
        (+[JSContext currentCallee]):
        (+[JSContext currentArguments]):
        (-[JSContext beginCallbackWithData:calleeValue:thisValue:argumentCount:arguments:]):
        (-[JSContext endCallbackWithData:]):
        * heap/Heap.cpp:
        (JSC::Heap::requestCollection):
        * runtime/Completion.cpp:
        (JSC::checkSyntax):
        (JSC::checkModuleSyntax):
        (JSC::evaluate):
        (JSC::loadAndEvaluateModule):
        (JSC::loadModule):
        (JSC::linkAndEvaluateModule):
        (JSC::importModule):
        * runtime/Identifier.cpp:
        (JSC::Identifier::checkCurrentAtomicStringTable):
        * runtime/InitializeThreading.cpp:
        (JSC::initializeThreading):
        * runtime/JSLock.cpp:
        (JSC::JSLock::didAcquireLock):
        (JSC::JSLock::willReleaseLock):
        (JSC::JSLock::dropAllLocks):
        (JSC::JSLock::grabAllLocks):
        * runtime/JSLock.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::updateStackLimits):
        (JSC::VM::committedStackByteCount):
        * runtime/VM.h:
        (JSC::VM::isSafeToRecurse const):
        * runtime/VMEntryScope.cpp:
        (JSC::VMEntryScope::VMEntryScope):
        * runtime/VMInlines.h:
        (JSC::VM::ensureStackCapacityFor):
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::YarrPatternConstructor::isSafeToRecurse const):

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

        LLInt should do pointer caging
        https://bugs.webkit.org/show_bug.cgi?id=175036

        Reviewed by Keith Miller.

        Implementing this in the LLInt was challenging because offlineasm did not previously know
        how to load from globals. This teaches it how to do that on Darwin/x86_64, which happens
        to be where the Gigacage is enabled right now.

        * llint/LLIntOfflineAsmConfig.h:
        * llint/LowLevelInterpreter64.asm:
        * offlineasm/ast.rb:
        * offlineasm/x86.rb:

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

        Sweeping should only scribble when sweeping to free list
        https://bugs.webkit.org/show_bug.cgi?id=175105

        Reviewed by Saam Barati.
        
        I just saw a crash on the bots where a destructor call attempt dereferenced scribbled memory. This
        can happen because the bump path of specializedSweep will scribble in SweepOnly, which replaces the
        zap word (i.e. 0) with the scribble word (i.e. 0xbadbeef0). This is a recent regression, since we
        didn't used to do destruction on the bump path. No destruction, no zapping. Looking at the pop
        path, we only scribble when we SweepToFreeList. This ensures that we only overwrite the zap word
        when it doesn't matter anyway because we're building a free list.
        
        This is a fix for those crashes on the bots because it means that we'll no longer scribble over the
        zap.

        * heap/MarkedBlockInlines.h:
        (JSC::MarkedBlock::Handle::specializedSweep):

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

        All C++ accesses to JSObject::m_butterfly should do caging
        https://bugs.webkit.org/show_bug.cgi?id=175039

        Reviewed by Keith Miller.
        
        Makes JSObject::m_butterfly a AuxiliaryBarrier<CagedPtr<Butterfly>> and adopts the CagedPtr<> API.
        This ensures that you can't cause C++ code to access a butterfly that has been rewired to point
        outside the gigacage.

        * runtime/JSArray.cpp:
        (JSC::JSArray::setLength):
        (JSC::JSArray::pop):
        (JSC::JSArray::push):
        (JSC::JSArray::shiftCountWithAnyIndexingType):
        (JSC::JSArray::unshiftCountWithAnyIndexingType):
        (JSC::JSArray::fillArgList):
        (JSC::JSArray::copyToArguments):
        * runtime/JSObject.cpp:
        (JSC::JSObject::heapSnapshot):
        (JSC::JSObject::createInitialIndexedStorage):
        (JSC::JSObject::createArrayStorage):
        (JSC::JSObject::convertUndecidedToInt32):
        (JSC::JSObject::convertUndecidedToDouble):
        (JSC::JSObject::convertUndecidedToContiguous):
        (JSC::JSObject::convertInt32ToDouble):
        (JSC::JSObject::convertInt32ToArrayStorage):
        (JSC::JSObject::convertDoubleToContiguous):
        (JSC::JSObject::convertDoubleToArrayStorage):
        (JSC::JSObject::convertContiguousToArrayStorage):
        (JSC::JSObject::defineOwnIndexedProperty):
        (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes):
        (JSC::JSObject::ensureLengthSlow):
        (JSC::JSObject::allocateMoreOutOfLineStorage):
        * runtime/JSObject.h:
        (JSC::JSObject::canGetIndexQuickly):
        (JSC::JSObject::getIndexQuickly):
        (JSC::JSObject::tryGetIndexQuickly const):
        (JSC::JSObject::canSetIndexQuickly):
        (JSC::JSObject::setIndexQuickly):
        (JSC::JSObject::initializeIndex):
        (JSC::JSObject::initializeIndexWithoutBarrier):
        (JSC::JSObject::butterfly const):
        (JSC::JSObject::butterfly):

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

        We should be OK with the gigacage being disabled on gmalloc
        https://bugs.webkit.org/show_bug.cgi?id=175082

        Reviewed by Michael Saboff.

        * jsc.cpp:
        (jscmain):

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

        On memory-constrained iOS devices, reduce the rate at which the JS heap grows before a GC to try to keep more memory available for the system
        https://bugs.webkit.org/show_bug.cgi?id=175041
        <rdar://problem/33659370>

        Reviewed by Filip Pizlo.

        The testing I have done shows that this new function is a ~10%
        progression running JetStream on 1GB iOS devices. I've also tried
        this on a few > 1GB iOS devices, and the testing shows this is either neutral
        or a regression. Right now, we'll just enable this for <= 1GB devices
        since it's a win. In the future, we might want to either look into
        tweaking these parameters or coming up with a new function for > 1GB
        devices.

        * heap/Heap.cpp:
        * runtime/Options.h:

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

        Bmalloc and GC should put auxiliaries (butterflies, typed array backing stores) in a gigacage (separate multi-GB VM region)
        https://bugs.webkit.org/show_bug.cgi?id=174727

        Reviewed by Mark Lam.
        
        This adopts the Gigacage for the GigacageSubspace, which we use for Auxiliary allocations. Also, in
        one place in the code - the FTL codegen for butterfly and typed array access - we "cage" the accesses
        themselves. Basically, we do masking to ensure that the pointer points into the gigacage.
        
        This is neutral on JetStream.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3InsertionSet.cpp:
        (JSC::B3::InsertionSet::execute):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGClobberize.cpp:
        (JSC::DFG::readsOverlap):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixedButterflyAccessUncagingPhase.cpp: Added.
        (JSC::DFG::performFixedButterflyAccessUncaging):
        * dfg/DFGFixedButterflyAccessUncagingPhase.h: Added.
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGHeapLocation.h:
        * dfg/DFGNodeType.h:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetButterfly):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGTypeCheckHoistingPhase.cpp:
        (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
        (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetButterfly):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
        (JSC::FTL::DFG::LowerDFGToB3::compileStringCharCodeAt):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucket):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetDirectPname):
        (JSC::FTL::DFG::LowerDFGToB3::compileToLowerCase):
        (JSC::FTL::DFG::LowerDFGToB3::caged):
        * heap/GigacageSubspace.cpp: Added.
        (JSC::GigacageSubspace::GigacageSubspace):
        (JSC::GigacageSubspace::~GigacageSubspace):
        (JSC::GigacageSubspace::tryAllocateAlignedMemory):
        (JSC::GigacageSubspace::freeAlignedMemory):
        (JSC::GigacageSubspace::canTradeBlocksWith):
        * heap/GigacageSubspace.h: Added.
        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::lastChanceToFinalize):
        (JSC::Heap::finalize):
        (JSC::Heap::sweepInFinalize):
        (JSC::Heap::updateAllocationLimits):
        (JSC::Heap::shouldDoFullCollection):
        (JSC::Heap::collectIfNecessaryOrDefer):
        (JSC::Heap::reportWebAssemblyFastMemoriesAllocated): Deleted.
        (JSC::Heap::webAssemblyFastMemoriesThisCycleAtThreshold const): Deleted.
        (JSC::Heap::sweepLargeAllocations): Deleted.
        (JSC::Heap::didAllocateWebAssemblyFastMemories): Deleted.
        * heap/Heap.h:
        * heap/LargeAllocation.cpp:
        (JSC::LargeAllocation::tryCreate):
        (JSC::LargeAllocation::destroy):
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::tryAllocateWithoutCollecting):
        (JSC::MarkedAllocator::tryAllocateBlock):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::tryCreate):
        (JSC::MarkedBlock::Handle::Handle):
        (JSC::MarkedBlock::Handle::~Handle):
        (JSC::MarkedBlock::Handle::didAddToAllocator):
        (JSC::MarkedBlock::Handle::subspace const): Deleted.
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::Handle::subspace const):
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::~MarkedSpace):
        (JSC::MarkedSpace::freeMemory):
        (JSC::MarkedSpace::prepareForAllocation):
        (JSC::MarkedSpace::addMarkedAllocator):
        (JSC::MarkedSpace::findEmptyBlockToSteal): Deleted.
        * heap/MarkedSpace.h:
        (JSC::MarkedSpace::firstAllocator const):
        (JSC::MarkedSpace::allocatorForEmptyAllocation const): Deleted.
        * heap/Subspace.cpp:
        (JSC::Subspace::Subspace):
        (JSC::Subspace::canTradeBlocksWith):
        (JSC::Subspace::tryAllocateAlignedMemory):
        (JSC::Subspace::freeAlignedMemory):
        (JSC::Subspace::prepareForAllocation):
        (JSC::Subspace::findEmptyBlockToSteal):
        * heap/Subspace.h:
        (JSC::Subspace::didCreateFirstAllocator):
        * heap/SubspaceInlines.h:
        (JSC::Subspace::forEachAllocator):
        (JSC::Subspace::forEachMarkedBlock):
        (JSC::Subspace::forEachNotEmptyMarkedBlock):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitDoubleLoad):
        (JSC::JIT::emitContiguousLoad):
        (JSC::JIT::emitArrayStorageLoad):
        (JSC::JIT::emitGenericContiguousPutByVal):
        (JSC::JIT::emitArrayStoragePutByVal):
        (JSC::JIT::emit_op_get_from_scope):
        (JSC::JIT::emit_op_put_to_scope):
        (JSC::JIT::emitIntTypedArrayGetByVal):
        (JSC::JIT::emitFloatTypedArrayGetByVal):
        (JSC::JIT::emitIntTypedArrayPutByVal):
        (JSC::JIT::emitFloatTypedArrayPutByVal):
        * jsc.cpp:
        (fillBufferWithContentsOfFile):
        (functionReadFile):
        (gigacageDisabled):
        (jscmain):
        * llint/LowLevelInterpreter64.asm:
        * runtime/ArrayBuffer.cpp:
        (JSC::ArrayBufferContents::tryAllocate):
        (JSC::ArrayBuffer::createAdopted):
        (JSC::ArrayBuffer::createFromBytes):
        (JSC::ArrayBuffer::tryCreate):
        * runtime/IndexingHeader.h:
        * runtime/InitializeThreading.cpp:
        (JSC::initializeThreading):
        * runtime/JSArrayBuffer.cpp:
        * runtime/JSArrayBufferView.cpp:
        (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
        (JSC::JSArrayBufferView::finalize):
        * runtime/JSLock.cpp:
        (JSC::JSLock::didAcquireLock):
        * runtime/JSObject.h:
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):
        * runtime/Options.h:
        * runtime/ScopedArgumentsTable.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::~VM):
        (JSC::VM::gigacageDisabledCallback):
        (JSC::VM::gigacageDisabled):
        * runtime/VM.h:
        (JSC::VM::fireGigacageEnabledIfNecessary):
        (JSC::VM::gigacageEnabled):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
        * wasm/WasmCodeBlock.cpp:
        (JSC::Wasm::CodeBlock::isSafeToRun):
        * wasm/WasmMemory.cpp:
        (JSC::Wasm::makeString):
        (JSC::Wasm::Memory::create):
        (JSC::Wasm::Memory::~Memory):
        (JSC::Wasm::Memory::addressIsInActiveFastMemory):
        (JSC::Wasm::Memory::grow):
        (JSC::Wasm::Memory::initializePreallocations): Deleted.
        (JSC::Wasm::Memory::maxFastMemoryCount): Deleted.
        * wasm/WasmMemory.h:
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::create):
        * wasm/js/JSWebAssemblyMemory.cpp:
        (JSC::JSWebAssemblyMemory::grow):
        (JSC::JSWebAssemblyMemory::finishCreation):
        * wasm/js/JSWebAssemblyMemory.h:
        (JSC::JSWebAssemblyMemory::subspaceFor):

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

        Added some UNLIKELYs to operationOptimize().
        https://bugs.webkit.org/show_bug.cgi?id=174976

        Reviewed by JF Bastien.

        * jit/JITOperations.cpp:

2017-07-31  Keith Miller  <keith_miller@apple.com>

        Make more things LLInt constexprs
        https://bugs.webkit.org/show_bug.cgi?id=174994

        Reviewed by Saam Barati.

        This patch makes more const values in the LLInt constexprs.
        It also deletes all of the no longer necessary static_asserts in
        LLIntData.cpp. Finally, it fixes a typo in parser.rb.

        * interpreter/ShadowChicken.h:
        (JSC::ShadowChicken::Packet::tailMarker):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LowLevelInterpreter.asm:
        * offlineasm/generate_offset_extractor.rb:
        * offlineasm/parser.rb:

2017-07-31  Matt Lewis  <jlewis3@apple.com>

        Unreviewed, rolling out r220060.

        This broke our internal builds. Contact reviewer of patch for
        more information.

        Reverted changeset:

        "Merge WTFThreadData to Thread::current"
        https://bugs.webkit.org/show_bug.cgi?id=174716
        http://trac.webkit.org/changeset/220060

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

        [JSC] Support optional catch binding
        https://bugs.webkit.org/show_bug.cgi?id=174981

        Reviewed by Saam Barati.

        This patch implements optional catch binding proposal[1], which is now stage 3.
        This proposal adds a new `catch` brace with no error value binding.

            ```
                try {
                    ...
                } catch {
                    ...
                }
            ```

        Sometimes we do not need to get error value actually. For example, the function returns
        boolean which means whether the function succeeds.

            ```
            function parse(result) // -> bool
            {
                 try {
                     parseInner(result);
                 } catch {
                     return false;
                 }
                 return true;
            }
            ```

        In the above case, we are not interested in the actual error value. Without this syntax,
        we always need to introduce a binding for an error value that is just ignored.

        [1]: https://michaelficarra.github.io/optional-catch-binding-proposal/

        * bytecompiler/NodesCodegen.cpp:
        (JSC::TryNode::emitBytecode):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseTryStatement):

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

        Merge WTFThreadData to Thread::current
        https://bugs.webkit.org/show_bug.cgi?id=174716

        Reviewed by Sam Weinig.

        Use Thread::current() instead.

        * API/JSContext.mm:
        (+[JSContext currentContext]):
        (+[JSContext currentThis]):
        (+[JSContext currentCallee]):
        (+[JSContext currentArguments]):
        (-[JSContext beginCallbackWithData:calleeValue:thisValue:argumentCount:arguments:]):
        (-[JSContext endCallbackWithData:]):
        * heap/Heap.cpp:
        (JSC::Heap::requestCollection):
        * runtime/Completion.cpp:
        (JSC::checkSyntax):
        (JSC::checkModuleSyntax):
        (JSC::evaluate):
        (JSC::loadAndEvaluateModule):
        (JSC::loadModule):
        (JSC::linkAndEvaluateModule):
        (JSC::importModule):
        * runtime/Identifier.cpp:
        (JSC::Identifier::checkCurrentAtomicStringTable):
        * runtime/InitializeThreading.cpp:
        (JSC::initializeThreading):
        * runtime/JSLock.cpp:
        (JSC::JSLock::didAcquireLock):
        (JSC::JSLock::willReleaseLock):
        (JSC::JSLock::dropAllLocks):
        (JSC::JSLock::grabAllLocks):
        * runtime/JSLock.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::updateStackLimits):
        (JSC::VM::committedStackByteCount):
        * runtime/VM.h:
        (JSC::VM::isSafeToRecurse const):
        * runtime/VMEntryScope.cpp:
        (JSC::VMEntryScope::VMEntryScope):
        * runtime/VMInlines.h:
        (JSC::VM::ensureStackCapacityFor):
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::YarrPatternConstructor::isSafeToRecurse const):

2017-07-30  Yusuke Suzuki  <utatane.tea@gmail.com>

        [WTF] Introduce Private Symbols
        https://bugs.webkit.org/show_bug.cgi?id=174935

        Reviewed by Darin Adler.

        Use SymbolImpl::isPrivate().

        * builtins/BuiltinNames.cpp:
        * builtins/BuiltinNames.h:
        (JSC::BuiltinNames::isPrivateName): Deleted.
        * builtins/BuiltinUtils.h:
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::lookup):
        * runtime/CommonIdentifiers.cpp:
        (JSC::CommonIdentifiers::isPrivateName): Deleted.
        * runtime/CommonIdentifiers.h:
        * runtime/ExceptionHelpers.cpp:
        (JSC::createUndefinedVariableError):
        * runtime/Identifier.h:
        (JSC::Identifier::isPrivateName):
        * runtime/IdentifierInlines.h:
        (JSC::identifierToSafePublicJSValue):
        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorAssign):
        (JSC::defineProperties):
        (JSC::setIntegrityLevel):
        (JSC::testIntegrityLevel):
        (JSC::ownPropertyKeys):
        * runtime/PrivateName.h:
        (JSC::PrivateName::PrivateName):
        * runtime/PropertyName.h:
        (JSC::PropertyName::isPrivateName):
        * runtime/ProxyObject.cpp:
        (JSC::performProxyGet):
        (JSC::ProxyObject::performInternalMethodGetOwnProperty):
        (JSC::ProxyObject::performHasProperty):
        (JSC::ProxyObject::performPut):
        (JSC::ProxyObject::performDelete):
        (JSC::ProxyObject::performDefineOwnProperty):

2017-07-29  Keith Miller  <keith_miller@apple.com>

        LLInt offsets extractor should be able to handle C++ constexprs
        https://bugs.webkit.org/show_bug.cgi?id=174964

        Reviewed by Saam Barati.

        This patch adds new syntax to the offline asm language. The new keyword,
        constexpr, takes the subsequent identifier and maps it to a C++ constexpr
        expression. Additionally, if the value is not an identifier you can wrap it in
        parentheses. e.g. constexpr (myConstexprFunction() + OBJECT_OFFSET(Foo, bar)),
        which will get converted into:
        static_cast<int64_t>(myConstexprFunction() + OBJECT_OFFSET(Foo, bar));

        This patch also changes the data format the LLIntOffsetsExtractor
        binary produces.  Previously, it would produce unsigned values,
        after this patch every value is an int64_t.  Using an int64_t is
        useful because it means that we can represent any constant needed.
        int32_t masks are sign extended then passed then converted to a
        negative literal sting in the assembler so it will be the constant
        expected.

        * llint/LLIntOffsetsExtractor.cpp:
        (JSC::LLIntOffsetsExtractor::dummy):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter64.asm:
        * offlineasm/asm.rb:
        * offlineasm/ast.rb:
        * offlineasm/generate_offset_extractor.rb:
        * offlineasm/offsets.rb:
        * offlineasm/parser.rb:
        * offlineasm/transform.rb:

2017-07-28  Matt Baker  <mattbaker@apple.com>

        Web Inspector: capture an async stack trace when web content calls addEventListener
        https://bugs.webkit.org/show_bug.cgi?id=174739
        <rdar://problem/33468197>

        Reviewed by Brian Burg.

        Allow debugger agents to perform custom logic when asynchronous stack
        trace data is cleared. For example, the PageDebuggerAgent would clear
        its list of registered listeners for which call stacks have been recorded.

        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::clearAsyncStackTraceData):
        * inspector/agents/InspectorDebuggerAgent.h:

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

        ObjectToStringAdaptiveStructureWatchpoint should not fire if it's dying imminently.
        https://bugs.webkit.org/show_bug.cgi?id=174948
        <rdar://problem/33495680>

        Reviewed by Filip Pizlo.

        ObjectToStringAdaptiveStructureWatchpoint is owned by StructureRareData.  If its
        owner StructureRareData is already known to be dead (in terms of GC liveness) but
        hasn't been destructed yet (i.e. not swept by the GC yet), we should ignore all
        requests to fire this watchpoint.

        If the GC had the chance to sweep the StructureRareData, thereby destructing the
        ObjectToStringAdaptiveStructureWatchpoint, it (the watchpoint) would have removed
        itself from the WatchpointSet it was on.  Hence, it would not have been fired.

        But since the watchpoint hasn't been destructed yet, it still remains on the
        WatchpointSet and needs to guard against being fired in this state.  The fix is
        to simply return early if its owner StructureRareData is not live.  This has the
        effect of the watchpoint fire being a no-op, which is equivalent to the watchpoint
        not firing as we would expect.

        This patch also removes some cargo cult copying of watchpoint code which
        instantiates a StringFireDetail.  In a few cases, that StringFireDetail is never
        used.  This patch removes these unnecessary instantiations.

        * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
        * runtime/StructureRareData.cpp:
        (JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
        (JSC::ObjectToStringAdaptiveInferredPropertyValueWatchpoint::handleFire):

2017-07-28  Yusuke Suzuki  <utatane.tea@gmail.com>

        ASSERTION FAILED: candidate->op() == PhantomCreateRest || candidate->op() == PhantomDirectArguments || candidate->op() == PhantomClonedArguments || candidate->op() == PhantomSpread || candidate->op() == PhantomNewArrayWithSpread
        https://bugs.webkit.org/show_bug.cgi?id=174900

        Reviewed by Saam Barati.

        In the arguments elimination phase, due to high cost of AI, we intentionally do not run AI.
        Instead, we use ForceOSRExit etc. (pseudo terminals) not to look into unreachable nodes.
        The problem is that even transforming phase also checks this pseudo terminals.

            BB1
            1: ForceOSRExit
            2: CreateDirectArguments

            BB2
            3: GetButterfly(@2)
            4: ForceOSRExit

        In the above case, @2 is not converted to PhantomDirectArguments. But @3 is processed. And the assertion fires.

        In this patch, we do not list candidates up after seeing pseudo terminals in basic blocks.

        * dfg/DFGArgumentsEliminationPhase.cpp:

2017-07-27  Oleksandr Skachkov  <gskachkov@gmail.com>

        [ES] Add support finally to Promise
        https://bugs.webkit.org/show_bug.cgi?id=174503

        Reviewed by Yusuke Suzuki.

        Add support `finally` method to Promise according
        to the https://bugs.webkit.org/show_bug.cgi?id=174503
        Current spec on STAGE 3 
        https://github.com/tc39/proposal-promise-finally

        * builtins/PromisePrototype.js:
        (finally):
        (const.valueThunk):
        (globalPrivate.getThenFinally):
        (const.thrower):
        (globalPrivate.getCatchFinally):
        * runtime/JSPromisePrototype.cpp:

2017-07-27  Yusuke Suzuki  <utatane.tea@gmail.com>

        Unreviewed, build fix for CLoop
        https://bugs.webkit.org/show_bug.cgi?id=171637

        * domjit/DOMJITGetterSetter.h:

2017-07-27  Yusuke Suzuki  <utatane.tea@gmail.com>

        Hoist DOM binding attribute getter prologue into JavaScriptCore taking advantage of DOMJIT / CheckSubClass
        https://bugs.webkit.org/show_bug.cgi?id=171637

        Reviewed by Darin Adler.

        Each DOM attribute getter has the code to perform ClassInfo check. But it is largely duplicate and causes code bloating.
        In this patch, we move ClassInfo check from WebCore to JSC and reduce code size.

        We introduce DOMAnnotation which has ClassInfo* and DOMJIT::GetterSetter*. If the getter is not DOMJIT getter, this
        DOMJIT::GetterSetter becomes nullptr. We support such a CustomAccessorGetter in all the JIT tiers.

        In IC, we drop CheckSubClass completely since IC's Structure check subsumes it. We do not enable this optimization for
        op_get_by_id_with_this case yet.
        In DFG and FTL, we emit CheckSubClass node. Which is typically removed by CheckStructure leading to CheckSubClass.

        And we add DOMAttributeGetterSetter, which is derived class of CustomGetterSetter. It holds DOMAnnotation and perform
        ClassInfo check.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/AccessCase.cpp:
        (JSC::AccessCase::generateImpl):
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
        * bytecode/GetByIdVariant.cpp:
        (JSC::GetByIdVariant::GetByIdVariant):
        (JSC::GetByIdVariant::operator=):
        (JSC::GetByIdVariant::attemptToMerge):
        (JSC::GetByIdVariant::dumpInContext):
        * bytecode/GetByIdVariant.h:
        (JSC::GetByIdVariant::customAccessorGetter):
        (JSC::GetByIdVariant::domAttribute):
        (JSC::GetByIdVariant::domJIT): Deleted.
        * bytecode/GetterSetterAccessCase.cpp:
        (JSC::GetterSetterAccessCase::create):
        (JSC::GetterSetterAccessCase::GetterSetterAccessCase):
        (JSC::GetterSetterAccessCase::emitDOMJITGetter):
        * bytecode/GetterSetterAccessCase.h:
        (JSC::GetterSetterAccessCase::domAttribute):
        (JSC::GetterSetterAccessCase::customAccessor):
        (JSC::GetterSetterAccessCase::domJIT): Deleted.
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::instantiateLexicalVariables):
        * create_hash_table:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::blessCallDOMGetter):
        (JSC::DFG::ByteCodeParser::handleDOMJITGetter):
        (JSC::DFG::ByteCodeParser::handleGetById):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNode.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCallDOMGetter):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callCustomGetter):
        * domjit/DOMJITGetterSetter.h:
        (JSC::DOMJIT::GetterSetter::GetterSetter):
        (JSC::DOMJIT::GetterSetter::getter):
        (JSC::DOMJIT::GetterSetter::compiler):
        (JSC::DOMJIT::GetterSetter::resultType):
        (JSC::DOMJIT::GetterSetter::~GetterSetter): Deleted.
        (JSC::DOMJIT::GetterSetter::setter): Deleted.
        (JSC::DOMJIT::GetterSetter::thisClassInfo): Deleted.
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileCallDOMGetter):
        * jit/Repatch.cpp:
        (JSC::tryCacheGetByID):
        * jsc.cpp:
        (WTF::DOMJITGetter::DOMJITAttribute::DOMJITAttribute):
        (WTF::DOMJITGetter::DOMJITAttribute::callDOMGetter):
        (WTF::DOMJITGetter::customGetter):
        (WTF::DOMJITGetter::finishCreation):
        (WTF::DOMJITGetterComplex::DOMJITAttribute::DOMJITAttribute):
        (WTF::DOMJITGetterComplex::DOMJITAttribute::callDOMGetter):
        (WTF::DOMJITGetterComplex::customGetter):
        (WTF::DOMJITGetterComplex::finishCreation):
        (WTF::DOMJITGetter::DOMJITNodeDOMJIT::DOMJITNodeDOMJIT): Deleted.
        (WTF::DOMJITGetter::DOMJITNodeDOMJIT::slowCall): Deleted.
        (WTF::DOMJITGetter::domJITNodeGetterSetter): Deleted.
        (WTF::DOMJITGetterComplex::DOMJITNodeDOMJIT::DOMJITNodeDOMJIT): Deleted.
        (WTF::DOMJITGetterComplex::DOMJITNodeDOMJIT::slowCall): Deleted.
        (WTF::DOMJITGetterComplex::domJITNodeGetterSetter): Deleted.
        * runtime/CustomGetterSetter.h:
        (JSC::CustomGetterSetter::create):
        (JSC::CustomGetterSetter::setter):
        (JSC::CustomGetterSetter::CustomGetterSetter):
        (): Deleted.
        * runtime/DOMAnnotation.h: Added.
        (JSC::operator==):
        (JSC::operator!=):
        * runtime/DOMAttributeGetterSetter.cpp: Added.
        * runtime/DOMAttributeGetterSetter.h: Copied from Source/JavaScriptCore/runtime/CustomGetterSetter.h.
        (JSC::isDOMAttributeGetterSetter):
        * runtime/Error.cpp:
        (JSC::throwDOMAttributeGetterTypeError):
        * runtime/Error.h:
        (JSC::throwVMDOMAttributeGetterTypeError):
        * runtime/JSCustomGetterSetterFunction.cpp:
        (JSC::JSCustomGetterSetterFunction::customGetterSetterFunctionCall):
        * runtime/JSObject.cpp:
        (JSC::JSObject::putInlineSlow):
        (JSC::JSObject::deleteProperty):
        (JSC::JSObject::getOwnStaticPropertySlot):
        (JSC::JSObject::reifyAllStaticProperties):
        (JSC::JSObject::fillGetterPropertySlot):
        (JSC::JSObject::findPropertyHashEntry): Deleted.
        * runtime/JSObject.h:
        (JSC::JSObject::getOwnNonIndexPropertySlot):
        (JSC::JSObject::fillCustomGetterPropertySlot):
        * runtime/Lookup.cpp:
        (JSC::setUpStaticFunctionSlot):
        * runtime/Lookup.h:
        (JSC::HashTableValue::domJIT):
        (JSC::getStaticPropertySlotFromTable):
        (JSC::putEntry):
        (JSC::lookupPut):
        (JSC::reifyStaticProperty):
        (JSC::reifyStaticProperties):
        Each static property table has a new field ClassInfo*. It indicates that which ClassInfo check DOMAttribute registered in
        this static property table requires.

        * runtime/ProgramExecutable.cpp:
        (JSC::ProgramExecutable::initializeGlobalProperties):
        * runtime/PropertyName.h:
        * runtime/PropertySlot.cpp:
        (JSC::PropertySlot::customGetter):
        (JSC::PropertySlot::customAccessorGetter):
        * runtime/PropertySlot.h:
        (JSC::PropertySlot::domAttribute):
        (JSC::PropertySlot::setCustom):
        (JSC::PropertySlot::setCacheableCustom):
        (JSC::PropertySlot::getValue):
        (JSC::PropertySlot::domJIT): Deleted.
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2017-07-26  Devin Rousso  <drousso@apple.com>

        Web Inspector: create protocol for recording Canvas contexts
        https://bugs.webkit.org/show_bug.cgi?id=174481

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/Canvas.json:
         - Add `requestRecording` command to mark the provided canvas as having requested a recording.
         - Add `cancelRecording` command to clear a previously marked canvas and flush any recorded data.
         - Add `recordingFinished` event that is fired once a recording is finished.

        * CMakeLists.txt:
        * DerivedSources.make:
        * inspector/protocol/Recording.json: Added.
         - Add `Type` enum that lists the types of recordings
         - Add `InitialState` type that contains information about the canvas context at the
           beginning of the recording.
         - Add `Frame` type that holds a list of actions that were recorded.
         - Add `Recording` type as the container object of recording data.

        * inspector/scripts/codegen/generate_js_backend_commands.py:
        (JSBackendCommandsGenerator.generate_domain):
        Create an agent for domains with no events or commands.

        * inspector/InspectorValues.h:
        Make Array `get` public so that values can be retrieved if needed.

2017-07-26  Brian Burg  <bburg@apple.com>

        Remove WEB_TIMING feature flag
        https://bugs.webkit.org/show_bug.cgi?id=174795

        Reviewed by Alex Christensen.

        * Configurations/FeatureDefines.xcconfig:

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

        Add the ability to change sp and pc to the ARM64 JIT probe.
        https://bugs.webkit.org/show_bug.cgi?id=174697
        <rdar://problem/33436965>

        Reviewed by JF Bastien.

        This patch implements the following:

        1. The ARM64 probe now supports modifying the pc and sp.

           However, lr is not preserved when modifying the pc because it is used as the
           scratch register for the indirect jump. Hence, the probe handler function
           may not modify both lr and pc in the same probe invocation.

        2. Fix probe tests to use bitwise comparison when comparing double register
           values. Otherwise, equivalent nan values will be interpreted as not equivalent.

        3. Change the minimum offset increment in testProbeModifiesStackPointer to be
           16 bytes for ARM64.  This is because the ARM64 probe now uses the ldp and stp
           instructions which require 16 byte alignment for their memory access.

        * assembler/MacroAssemblerARM64.cpp:
        (JSC::arm64ProbeError):
        (JSC::MacroAssembler::probe):
        (JSC::arm64ProbeTrampoline): Deleted.
        * assembler/testmasm.cpp:
        (JSC::isSpecialGPR):
        (JSC::testProbeReadsArgumentRegisters):
        (JSC::testProbeWritesArgumentRegisters):
        (JSC::testProbePreservesGPRS):
        (JSC::testProbeModifiesStackPointer):
        (JSC::testProbeModifiesStackPointerToInsideProbeContextOnStack):
        (JSC::testProbeModifiesStackPointerToNBytesBelowSP):

2017-07-25  JF Bastien  <jfbastien@apple.com>

        WebAssembly: generate smaller binaries
        https://bugs.webkit.org/show_bug.cgi?id=174818

        Reviewed by Filip Pizlo.

        This patch reduces generated code size for WebAssembly in 2 ways:

        1. Use the ZR register when storing zero on ARM64.
        2. Synthesize wasm context lazily.

        This leads to a modest size reduction on both x86-64 and ARM64 for
        large WebAssembly games, without any performance loss on WasmBench
        and TitzerBench.

        The reason this works is that these games, using Emscripten,
        generate 100k+ tiny functions, and our JIT allocation granule
        rounds all allocations up to 32 bytes. There are plenty of other
        simple gains to be had, I've filed a follow-up bug at
        webkit.org/b/174819

        We should further avoid the per-function cost of tiering, which
        represents the bulk of code generated for small functions.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::storeZero64):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::storeZero64):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::createStore): this doesn't make sense
        for x86 because it constrains register reuse and codegen in a way
        that doesn't affect ARM64 because it has a dedicated zero
        register.
        * b3/air/AirOpcode.opcodes: add the storeZero64 opcode.
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::instanceValue):
        (JSC::Wasm::B3IRGenerator::restoreWasmContext):
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        (JSC::Wasm::B3IRGenerator::materializeWasmContext): Deleted.

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

        B3 should do LICM
        https://bugs.webkit.org/show_bug.cgi?id=174750

        Reviewed by Keith Miller and Saam Barati.
        
        Added a LICM phase to B3. This phase is called hoistLoopInvariantValues, to conform to the B3 naming
        convention for phases (it has to be an imperative). The phase uses NaturalLoops and BackwardsDominators,
        so this adds those analyses to B3. BackwardsDominators was already available in templatized form. This
        change templatizes DFG::NaturalLoops so that we can just use it.
        
        The LICM phase itself is really simple. We are decently precise with our handling of everything except
        the relationship between control dependence and side exits.
        
        Also added a bunch of tests.
        
        This isn't super important. It's perf-neutral on JS benchmarks. FTL already does LICM on DFG SSA IR, and
        probably all current WebAssembly content has had LICM done to it. That being said, this is a cheap phase
        so it doesn't hurt to have it.
        
        I wrote it because I thought I needed it for bug 174727. It turns out that there's a better way to
        handle the problem I had, so I ended up not needed it - but by then I had already written it. I think
        it's good to have it because LICM is one of those core compiler phases; every compiler has it
        eventually.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3BackwardsCFG.h: Added.
        (JSC::B3::BackwardsCFG::BackwardsCFG):
        * b3/B3BackwardsDominators.h: Added.
        (JSC::B3::BackwardsDominators::BackwardsDominators):
        * b3/B3BasicBlock.cpp:
        (JSC::B3::BasicBlock::appendNonTerminal):
        * b3/B3Effects.h:
        * b3/B3EnsureLoopPreHeaders.cpp: Added.
        (JSC::B3::ensureLoopPreHeaders):
        * b3/B3EnsureLoopPreHeaders.h: Added.
        * b3/B3Generate.cpp:
        (JSC::B3::generateToAir):
        * b3/B3HoistLoopInvariantValues.cpp: Added.
        (JSC::B3::hoistLoopInvariantValues):
        * b3/B3HoistLoopInvariantValues.h: Added.
        * b3/B3NaturalLoops.h: Added.
        (JSC::B3::NaturalLoops::NaturalLoops):
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::invalidateCFG):
        (JSC::B3::Procedure::naturalLoops):
        (JSC::B3::Procedure::backwardsCFG):
        (JSC::B3::Procedure::backwardsDominators):
        * b3/B3Procedure.h:
        * b3/testb3.cpp:
        (JSC::B3::generateLoop):
        (JSC::B3::makeArrayForLoops):
        (JSC::B3::generateLoopNotBackwardsDominant):
        (JSC::B3::oneFunction):
        (JSC::B3::noOpFunction):
        (JSC::B3::testLICMPure):
        (JSC::B3::testLICMPureSideExits):
        (JSC::B3::testLICMPureWritesPinned):
        (JSC::B3::testLICMPureWrites):
        (JSC::B3::testLICMReadsLocalState):
        (JSC::B3::testLICMReadsPinned):
        (JSC::B3::testLICMReads):
        (JSC::B3::testLICMPureNotBackwardsDominant):
        (JSC::B3::testLICMPureFoiledByChild):
        (JSC::B3::testLICMPureNotBackwardsDominantFoiledByChild):
        (JSC::B3::testLICMExitsSideways):
        (JSC::B3::testLICMWritesLocalState):
        (JSC::B3::testLICMWrites):
        (JSC::B3::testLICMFence):
        (JSC::B3::testLICMWritesPinned):
        (JSC::B3::testLICMControlDependent):
        (JSC::B3::testLICMControlDependentNotBackwardsDominant):
        (JSC::B3::testLICMControlDependentSideExits):
        (JSC::B3::testLICMReadsPinnedWritesPinned):
        (JSC::B3::testLICMReadsWritesDifferentHeaps):
        (JSC::B3::testLICMReadsWritesOverlappingHeaps):
        (JSC::B3::testLICMDefaultCall):
        (JSC::B3::run):
        * dfg/DFGBasicBlock.h:
        * dfg/DFGCFG.h:
        * dfg/DFGNaturalLoops.cpp: Removed.
        * dfg/DFGNaturalLoops.h:
        (JSC::DFG::NaturalLoops::NaturalLoops):
        (JSC::DFG::NaturalLoop::NaturalLoop): Deleted.
        (JSC::DFG::NaturalLoop::header): Deleted.
        (JSC::DFG::NaturalLoop::size): Deleted.
        (JSC::DFG::NaturalLoop::at): Deleted.
        (JSC::DFG::NaturalLoop::operator[]): Deleted.
        (JSC::DFG::NaturalLoop::contains): Deleted.
        (JSC::DFG::NaturalLoop::index): Deleted.
        (JSC::DFG::NaturalLoop::isOuterMostLoop): Deleted.
        (JSC::DFG::NaturalLoop::addBlock): Deleted.
        (JSC::DFG::NaturalLoops::numLoops): Deleted.
        (JSC::DFG::NaturalLoops::loop): Deleted.
        (JSC::DFG::NaturalLoops::headerOf): Deleted.
        (JSC::DFG::NaturalLoops::innerMostLoopOf): Deleted.
        (JSC::DFG::NaturalLoops::innerMostOuterLoop): Deleted.
        (JSC::DFG::NaturalLoops::belongsTo): Deleted.
        (JSC::DFG::NaturalLoops::loopDepth): Deleted.

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

        GC should be fine with trading blocks between destructor and non-destructor blocks
        https://bugs.webkit.org/show_bug.cgi?id=174811

        Reviewed by Mark Lam.
        
        Our GC has the ability to trade blocks between MarkedAllocators. A MarkedAllocator is a
        size-class-within-a-Subspace. The ability to trade helps reduce memory wastage due to
        fragmentation. Prior to this change, this only worked between blocks that did not have destructors.
        This was partly a policy decision. But mostly, it was fallout from the way we use the `empty` block
        set.
        
        Here's how `empty` used to work. If a block is empty, we don't run destructors. We say that a block
        is empty if:
        
        A) It has no live objects and its a non-destructor block, or
        B) We just allocated it (so it has no destructors even if it's a destructor block), or
        C) We just stole it from another allocator (so it also has no destructors), or
        D) We just swept the block and ran all destructors.
        
        Case (A) is for trading blocks. That's how a different MarkedAllocator would know that this is a
        block that could be stolen.

        Cases (B) and (C) need to be detected for correctness, since otherwise we might try to run
        destructors in blocks that have garbage bits. In that case, the isZapped check won't detect that
        cells don't need destruction, so without having the `empty` bit we would try to destruct garbage
        and crash. Currently, we know that we have cases (B) and (C) when the block is empty.
        
        Case (D) is necessary for detecting which blocks can be removed when we `shrink` the heap.
        
        If we tried to enable trading of blocks between allocators without making any changes to how
        `empty` works, then it just would not work. We have to set the `empty` bits of blocks that have no
        live objects in order for those bits to be candidates for trading. But if we do that, then our
        logic for cases (B-D) will think that the block has no destructible objects. That's bad, since then
        our destructors won't run and we'll leak memory.
        
        This change fixes this issue by decoupling the "do I have destructors" question from the "do I have
        live objects" question by introducing a new `destructible` bitvector. The GC flags all live blocks
        as being destructible at the end. We clear the destructible bit in cases (B-D). Cases (B-C) are
        handled entirely by the new destrictible bit, while case (D) is detected by looking for blocks that
        are (empty & ~destructible).
        
        Then we can simply remove all destructor-oriented special-casing of the `empty` bit. And we can
        remove destructor-oriented special-casing of block trading.

        This is a perf-neutral change. We expect most free memory to be in non-destructor blocks anyway,
        so this change is more about clean-up than perf. But, this could reduce memory usage in some
        pathological cases.
        
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::findEmptyBlockToSteal):
        (JSC::MarkedAllocator::tryAllocateWithoutCollecting):
        (JSC::MarkedAllocator::endMarking):
        (JSC::MarkedAllocator::shrink):
        (JSC::MarkedAllocator::shouldStealEmptyBlocksFromOtherAllocators): Deleted.
        * heap/MarkedAllocator.h:
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::Handle::lastChanceToFinalize):
        (JSC::MarkedBlock::Handle::sweep):
        * heap/MarkedBlockInlines.h:
        (JSC::MarkedBlock::Handle::specializedSweep):
        (JSC::MarkedBlock::Handle::finishSweepKnowingSubspace):
        (JSC::MarkedBlock::Handle::emptyMode):

2017-07-25  Keith Miller  <keith_miller@apple.com>

        Remove Broken CompareEq constant folding phase.
        https://bugs.webkit.org/show_bug.cgi?id=174846
        <rdar://problem/32978808>

        Reviewed by Saam Barati.

        This bug happened when we would get code like the following:

        a: JSConst(Undefined)
        b: GetLocal(SomeObjectOrUndefined)
        ...
        c: CompareEq(Check:ObjectOrOther:b, Check:ObjectOrOther:a)

        constant folding will turn this into:

        a: JSConst(Undefined)
        b: GetLocal(SomeObjectOrUndefined)
        ...
        c: CompareEq(Check:ObjectOrOther:b, Other:a)

        But the SpeculativeJIT/FTL lowering will fail to check b
        properly which leads to an assertion failure in the AI.

        I'll follow up with a more robust fix later. For now, I'll remove the
        case that generates the code. Removing the code appears to be perf
        neutral.

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

2017-07-25  Matt Baker  <mattbaker@apple.com>

        Web Inspector: Refactoring: extract async stack trace logic from InspectorInstrumentation
        https://bugs.webkit.org/show_bug.cgi?id=174738

        Reviewed by Brian Burg.

        Move AsyncCallType enum to InspectorDebuggerAgent, which manages async
        stack traces. This preserves the call type in JSC, makes the range of
        possible call types explicit, and is safer than passing ints.

        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::asyncCallIdentifier):
        (Inspector::InspectorDebuggerAgent::didScheduleAsyncCall):
        (Inspector::InspectorDebuggerAgent::didCancelAsyncCall):
        (Inspector::InspectorDebuggerAgent::willDispatchAsyncCall):
        * inspector/agents/InspectorDebuggerAgent.h:

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

        Fix bugs in probe code to change sp on x86, x86_64 and 32-bit ARM.
        https://bugs.webkit.org/show_bug.cgi?id=174809
        <rdar://problem/33504759>

        Reviewed by Filip Pizlo.

        1. When the probe handler function changes the sp register to point to the
           region of stack in the middle of the ProbeContext on the stack, there is a
           bug where the ProbeContext's register values to be restored can be over-written
           before they can be restored.  This is now fixed.

        2. Added more robust probe tests for changing the sp register.

        3. Made existing probe tests to ensure that probe handlers were actually called.

        4. Added some verification to testProbePreservesGPRS().

        5. Change all the probe tests to fail early on discovering an error instead of
           batching till the end of the test.  This helps point a finger to the failing
           issue earlier.

        This patch was tested on x86, x86_64, and ARMv7.  ARM64 probe code will be fixed
        next in https://bugs.webkit.org/show_bug.cgi?id=174697.

        * assembler/MacroAssemblerARM.cpp:
        * assembler/MacroAssemblerARMv7.cpp:
        * assembler/MacroAssemblerX86Common.cpp:
        * assembler/testmasm.cpp:
        (JSC::testProbeReadsArgumentRegisters):
        (JSC::testProbeWritesArgumentRegisters):
        (JSC::testProbePreservesGPRS):
        (JSC::testProbeModifiesStackPointer):
        (JSC::testProbeModifiesStackPointerToInsideProbeContextOnStack):
        (JSC::testProbeModifiesStackPointerToNBytesBelowSP):
        (JSC::testProbeModifiesProgramCounter):
        (JSC::run):

2017-07-25  Brian Burg  <bburg@apple.com>

        Web Automation: add support for uploading files
        https://bugs.webkit.org/show_bug.cgi?id=174797
        <rdar://problem/28485063>

        Reviewed by Joseph Pecoraro.

        * inspector/scripts/generate-inspector-protocol-bindings.py:
        (generate_from_specification):
        Start generating frontend dispatcher code if the target framework is 'WebKit'.

        * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
        (CppFrontendDispatcherImplementationGenerator.generate_output):
        Use a framework include for InspectorFrontendRouter.h since this generated code
        will be compiled outside of WebCore.framework.

        * 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/type-with-open-parameters.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 code generator tests.

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

        Gardening: fixed C Loop build after r219790.
        https://bugs.webkit.org/show_bug.cgi?id=174696

        Not reviewed.

        * assembler/testmasm.cpp:

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

        Create regression tests for the JIT probe.
        https://bugs.webkit.org/show_bug.cgi?id=174696
        <rdar://problem/33436922>

        Reviewed by Saam Barati.

        The new testmasm will test the following:
        1. the probe is able to read the value of CPU registers.
        2. the probe is able to write the value of CPU registers.
        3. the probe is able to preserve all CPU registers.
        4. special case of (2): the probe is able to change the value of the stack pointer.
        5. special case of (2): the probe is able to change the value of the program counter
           i.e. the probe can change where the code continues executing upon returning from
           the probe.

        Currently, the x86, x86_64, and ARMv7 ports passes the test.  ARM64 does not
        because it does not support changing the sp and pc yet.  The ARM64 probe
        implementation will be fixed in https://bugs.webkit.org/show_bug.cgi?id=174697
        later.

        * Configurations/ToolExecutable.xcconfig:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::CPUState::pc):
        (JSC::MacroAssembler::CPUState::fp):
        (JSC::MacroAssembler::CPUState::sp):
        (JSC::ProbeContext::pc):
        (JSC::ProbeContext::fp):
        (JSC::ProbeContext::sp):
        * assembler/MacroAssemblerARM64.cpp:
        (JSC::arm64ProbeTrampoline):
        * assembler/MacroAssemblerPrinter.cpp:
        (JSC::Printer::printPCRegister):
        * assembler/testmasm.cpp: Added.
        (hiddenTruthBecauseNoReturnIsStupid):
        (usage):
        (JSC::nextID):
        (JSC::isPC):
        (JSC::isSP):
        (JSC::isFP):
        (JSC::compile):
        (JSC::invoke):
        (JSC::compileAndRun):
        (JSC::testSimple):
        (JSC::testProbeReadsArgumentRegisters):
        (JSC::testProbeWritesArgumentRegisters):
        (JSC::testFunctionToTrashRegisters):
        (JSC::testProbePreservesGPRS):
        (JSC::testProbeModifiesStackPointer):
        (JSC::testProbeModifiesProgramCounter):
        (JSC::run):
        (run):
        (main):
        * b3/air/testair.cpp:
        (usage):
        * shell/CMakeLists.txt:

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

        It should be easy to decide how WebKit yields
        https://bugs.webkit.org/show_bug.cgi?id=174298

        Reviewed by Saam Barati.
        
        Use the new WTF::Thread::yield() function for yielding instead of the C++ function.

        * heap/Heap.cpp:
        (JSC::Heap::resumeThePeriphery):
        * heap/VisitingTimeout.h:
        * runtime/JSCell.cpp:
        (JSC::JSCell::lockSlow):
        (JSC::JSCell::unlockSlow):
        * runtime/JSCell.h:
        * runtime/JSCellInlines.h:
        (JSC::JSCell::lock):
        (JSC::JSCell::unlock):
        * runtime/JSLock.cpp:
        (JSC::JSLock::grabAllLocks):
        * runtime/SamplingProfiler.cpp:

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

        Refactor MASM probe CPUState to use arrays for register storage.
        https://bugs.webkit.org/show_bug.cgi?id=174694

        Reviewed by Keith Miller.

        Using arrays for register storage in CPUState allows us to do away with the
        huge switch statements to decode each register id.  We can now simply index into
        the arrays.

        With this patch, we now:

        1. Remove the need for macros for defining the list of CPU registers.
           We can go back to simple enums.  This makes the code easier to read.

        2. Make the assembler the authority on register names.
           Most of this code is moved into the assembler from GPRInfo and FPRInfo.
           GPRInfo and FPRInfo now forwards to the assembler.

        3. Make the assembler the authority on the number of registers of each type.

        4. Fix a "bug" in ARMv7's lastRegister().  It was previously omitting lr and pc.
           This is inconsistent with how every other CPU architecture implements
           lastRegister().  This patch fixes it to return the true last GPR i.e. pc, but
           updates RegisterSet::reservedHardwareRegisters() to exclude those registers.

        * assembler/ARM64Assembler.h:
        (JSC::ARM64Assembler::numberOfRegisters):
        (JSC::ARM64Assembler::firstSPRegister):
        (JSC::ARM64Assembler::lastSPRegister):
        (JSC::ARM64Assembler::numberOfSPRegisters):
        (JSC::ARM64Assembler::numberOfFPRegisters):
        (JSC::ARM64Assembler::gprName):
        (JSC::ARM64Assembler::sprName):
        (JSC::ARM64Assembler::fprName):
        * assembler/ARMAssembler.h:
        (JSC::ARMAssembler::numberOfRegisters):
        (JSC::ARMAssembler::firstSPRegister):
        (JSC::ARMAssembler::lastSPRegister):
        (JSC::ARMAssembler::numberOfSPRegisters):
        (JSC::ARMAssembler::numberOfFPRegisters):
        (JSC::ARMAssembler::gprName):
        (JSC::ARMAssembler::sprName):
        (JSC::ARMAssembler::fprName):
        * assembler/ARMv7Assembler.h:
        (JSC::ARMv7Assembler::lastRegister):
        (JSC::ARMv7Assembler::numberOfRegisters):
        (JSC::ARMv7Assembler::firstSPRegister):
        (JSC::ARMv7Assembler::lastSPRegister):
        (JSC::ARMv7Assembler::numberOfSPRegisters):
        (JSC::ARMv7Assembler::numberOfFPRegisters):
        (JSC::ARMv7Assembler::gprName):
        (JSC::ARMv7Assembler::sprName):
        (JSC::ARMv7Assembler::fprName):
        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::numberOfRegisters):
        (JSC::AbstractMacroAssembler::gprName):
        (JSC::AbstractMacroAssembler::firstSPRegister):
        (JSC::AbstractMacroAssembler::lastSPRegister):
        (JSC::AbstractMacroAssembler::numberOfSPRegisters):
        (JSC::AbstractMacroAssembler::sprName):
        (JSC::AbstractMacroAssembler::numberOfFPRegisters):
        (JSC::AbstractMacroAssembler::fprName):
        * assembler/MIPSAssembler.h:
        (JSC::MIPSAssembler::numberOfRegisters):
        (JSC::MIPSAssembler::firstSPRegister):
        (JSC::MIPSAssembler::lastSPRegister):
        (JSC::MIPSAssembler::numberOfSPRegisters):
        (JSC::MIPSAssembler::numberOfFPRegisters):
        (JSC::MIPSAssembler::gprName):
        (JSC::MIPSAssembler::sprName):
        (JSC::MIPSAssembler::fprName):
        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::CPUState::gprName):
        (JSC::MacroAssembler::CPUState::sprName):
        (JSC::MacroAssembler::CPUState::fprName):
        (JSC::MacroAssembler::CPUState::gpr):
        (JSC::MacroAssembler::CPUState::spr):
        (JSC::MacroAssembler::CPUState::fpr):
        (JSC::MacroAssembler::CPUState::pc):
        (JSC::MacroAssembler::CPUState::fp):
        (JSC::MacroAssembler::CPUState::sp):
        (JSC::ProbeContext::gpr):
        (JSC::ProbeContext::spr):
        (JSC::ProbeContext::fpr):
        (JSC::ProbeContext::gprName):
        (JSC::ProbeContext::sprName):
        (JSC::ProbeContext::fprName):
        (JSC::MacroAssembler::numberOfRegisters): Deleted.
        (JSC::MacroAssembler::numberOfFPRegisters): Deleted.
        * assembler/MacroAssemblerARM.cpp:
        * assembler/MacroAssemblerARM64.cpp:
        (JSC::arm64ProbeTrampoline):
        * assembler/MacroAssemblerARMv7.cpp:
        * assembler/MacroAssemblerPrinter.cpp:
        (JSC::Printer::nextID):
        (JSC::Printer::printAllRegisters):
        (JSC::Printer::printPCRegister):
        (JSC::Printer::printRegisterID):
        (JSC::Printer::printAddress):
        * assembler/MacroAssemblerX86Common.cpp:
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::numberOfRegisters):
        (JSC::X86Assembler::firstSPRegister):
        (JSC::X86Assembler::lastSPRegister):
        (JSC::X86Assembler::numberOfSPRegisters):
        (JSC::X86Assembler::numberOfFPRegisters):
        (JSC::X86Assembler::gprName):
        (JSC::X86Assembler::sprName):
        (JSC::X86Assembler::fprName):
        * jit/FPRInfo.h:
        (JSC::FPRInfo::debugName):
        * jit/GPRInfo.h:
        (JSC::GPRInfo::debugName):
        * jit/RegisterSet.cpp:
        (JSC::RegisterSet::reservedHardwareRegisters):

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

        [JSC] Introduce static symbols
        https://bugs.webkit.org/show_bug.cgi?id=158863

        Reviewed by Darin Adler.

        We use StaticSymbolImpl to initialize PrivateNames and builtin Symbols.
        As a result, we can share the same Symbol values between VMs and threads.
        And we do not need to allocate Ref<SymbolImpl> for these symbols at runtime.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/BuiltinNames.cpp: Added.
        Suppress warning C4307, integral constant overflow. It is intentional in constexpr hash value calculation.

        * builtins/BuiltinNames.h:
        (JSC::BuiltinNames::BuiltinNames):
        * builtins/BuiltinUtils.h:

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

        [FTL] Arguments elimination is suppressed by unreachable blocks
        https://bugs.webkit.org/show_bug.cgi?id=174352

        Reviewed by Filip Pizlo.

        If we do not execute `op_get_by_id`, our value profiling tells us unpredictable and DFG emits ForceOSRExit.
        The problem is that arguments elimination phase checks escaping even when ForceOSRExit preceeds.
        Since GetById without information can escape arguments if it is specified, non-executed code including
        op_get_by_id with arguments can escape arguments.

        For example,

            function test(flag)
            {
                if (flag) {
                    // This is not executed, but emits GetById with arguments.
                    // It prevents us from eliminating materialization.
                    return arguments.length;
                }
                return arguments.length;
            }
            noInline(test);
            while (true)
                test(false);

        We do not perform CFA and dead-node clipping yet when performing arguments elimination phase.
        So this GetById exists and escapes arguments.

        To solve this problem, our arguments elimination phase checks preceding pseudo-terminal nodes.
        If it is shown, following GetById does not escape arguments. Compared to performing AI, it is
        lightweight. But it catches much of typical cases we failed to perform arguments elimination.

        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGNode.h:
        (JSC::DFG::Node::isPseudoTerminal):
        * dfg/DFGValidate.cpp:

2017-07-20  Chris Dumez  <cdumez@apple.com>

        Replace calls to Vector::resize() with calls to more efficient shrink() / grow() when applicable
        https://bugs.webkit.org/show_bug.cgi?id=174660

        Reviewed by Geoffrey Garen.

        Replace calls to Vector::resize() with calls to more efficient shrink() / grow() when applicable.
        This essentially replaces a branch to figure out if the new size is less or greater than the
        current size by an assertion.

        * b3/B3BasicBlockUtils.h:
        (JSC::B3::clearPredecessors):
        * b3/B3InferSwitches.cpp:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::finishAppendingInstructions):
        * b3/B3ReduceStrength.cpp:
        * b3/B3SparseCollection.h:
        (JSC::B3::SparseCollection::packIndices):
        * b3/B3UseCounts.cpp:
        (JSC::B3::UseCounts::UseCounts):
        * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp:
        * b3/air/AirEmitShuffle.cpp:
        (JSC::B3::Air::emitShuffle):
        * b3/air/AirLowerAfterRegAlloc.cpp:
        (JSC::B3::Air::lowerAfterRegAlloc):
        * b3/air/AirOptimizeBlockOrder.cpp:
        (JSC::B3::Air::optimizeBlockOrder):
        * bytecode/Operands.h:
        (JSC::Operands::ensureLocals):
        * bytecode/PreciseJumpTargets.cpp:
        (JSC::computePreciseJumpTargetsInternal):
        * dfg/DFGBlockInsertionSet.cpp:
        (JSC::DFG::BlockInsertionSet::execute):
        * dfg/DFGBlockMapInlines.h:
        (JSC::DFG::BlockMap<T>::BlockMap):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::processSetLocalQueue):
        (JSC::DFG::ByteCodeParser::clearCaches):
        * dfg/DFGDisassembler.cpp:
        (JSC::DFG::Disassembler::Disassembler):
        * dfg/DFGFlowIndexing.cpp:
        (JSC::DFG::FlowIndexing::recompute):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::registerFrozenValues):
        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::setLiveValues):
        * dfg/DFGLICMPhase.cpp:
        (JSC::DFG::LICMPhase::run):
        * dfg/DFGLivenessAnalysisPhase.cpp:
        * dfg/DFGNaturalLoops.cpp:
        (JSC::DFG::NaturalLoops::NaturalLoops):
        * dfg/DFGStoreBarrierClusteringPhase.cpp:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        * heap/CodeBlockSet.cpp:
        (JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::sweepLargeAllocations):
        * inspector/ContentSearchUtilities.cpp:
        (Inspector::ContentSearchUtilities::findMagicComment):
        * interpreter/ShadowChicken.cpp:
        (JSC::ShadowChicken::update):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::shrinkOperandStackBy):
        * parser/Lexer.h:
        (JSC::Lexer::setOffset):
        * runtime/RegExpInlines.h:
        (JSC::RegExp::matchInline):
        * runtime/RegExpPrototype.cpp:
        (JSC::genericSplit):
        * yarr/RegularExpression.cpp:
        (JSC::Yarr::RegularExpression::match):

2017-07-20  Yusuke Suzuki  <utatane.tea@gmail.com>

        [WTF] Use ThreadGroup to bookkeep active threads for Mach exception
        https://bugs.webkit.org/show_bug.cgi?id=174678

        Reviewed by Mark Lam.

        Use Thread& instead.

        * runtime/JSLock.cpp:
        (JSC::JSLock::didAcquireLock):

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

        [WTF] Implement WTF::ThreadGroup
        https://bugs.webkit.org/show_bug.cgi?id=174081

        Reviewed by Mark Lam.

        Large part of MachineThreads are now removed and replaced with WTF::ThreadGroup.
        And SamplingProfiler and others interact with WTF::Thread directly.

        * API/tests/ExecutionTimeLimitTest.cpp:
        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::MachineThreads):
        (JSC::captureStack):
        (JSC::MachineThreads::tryCopyOtherThreadStack):
        (JSC::MachineThreads::tryCopyOtherThreadStacks):
        (JSC::MachineThreads::gatherConservativeRoots):
        (JSC::ActiveMachineThreadsManager::Locker::Locker): Deleted.
        (JSC::ActiveMachineThreadsManager::add): Deleted.
        (JSC::ActiveMachineThreadsManager::remove): Deleted.
        (JSC::ActiveMachineThreadsManager::contains): Deleted.
        (JSC::ActiveMachineThreadsManager::ActiveMachineThreadsManager): Deleted.
        (JSC::activeMachineThreadsManager): Deleted.
        (JSC::MachineThreads::~MachineThreads): Deleted.
        (JSC::MachineThreads::addCurrentThread): Deleted.
        (): Deleted.
        (JSC::MachineThreads::removeThread): Deleted.
        (JSC::MachineThreads::removeThreadIfFound): Deleted.
        (JSC::MachineThreads::MachineThread::MachineThread): Deleted.
        (JSC::MachineThreads::MachineThread::getRegisters): Deleted.
        (JSC::MachineThreads::MachineThread::Registers::stackPointer): Deleted.
        (JSC::MachineThreads::MachineThread::Registers::framePointer): Deleted.
        (JSC::MachineThreads::MachineThread::Registers::instructionPointer): Deleted.
        (JSC::MachineThreads::MachineThread::Registers::llintPC): Deleted.
        (JSC::MachineThreads::MachineThread::captureStack): Deleted.
        * heap/MachineStackMarker.h:
        (JSC::MachineThreads::addCurrentThread):
        (JSC::MachineThreads::getLock):
        (JSC::MachineThreads::threads):
        (JSC::MachineThreads::MachineThread::suspend): Deleted.
        (JSC::MachineThreads::MachineThread::resume): Deleted.
        (JSC::MachineThreads::MachineThread::threadID): Deleted.
        (JSC::MachineThreads::MachineThread::stackBase): Deleted.
        (JSC::MachineThreads::MachineThread::stackEnd): Deleted.
        (JSC::MachineThreads::threadsListHead): Deleted.
        * runtime/SamplingProfiler.cpp:
        (JSC::FrameWalker::isValidFramePointer):
        (JSC::SamplingProfiler::SamplingProfiler):
        (JSC::SamplingProfiler::takeSample):
        (JSC::SamplingProfiler::noticeCurrentThreadAsJSCExecutionThread):
        * runtime/SamplingProfiler.h:
        * wasm/WasmMachineThreads.cpp:
        (JSC::Wasm::resetInstructionCacheOnAllThreads):

2017-07-18  Andy Estes  <aestes@apple.com>

        [Xcode] Enable CLANG_WARN_RANGE_LOOP_ANALYSIS
        https://bugs.webkit.org/show_bug.cgi?id=174631

        Reviewed by Tim Horton.

        * Configurations/Base.xcconfig:
        * b3/B3FoldPathConstants.cpp:
        * b3/B3LowerMacros.cpp:
        * b3/air/AirAllocateRegistersByGraphColoring.cpp:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::check):
        (JSC::DFG::ByteCodeParser::planLoad):

2017-07-18  Yusuke Suzuki  <utatane.tea@gmail.com>

        WTF::Thread should have the threads stack bounds.
        https://bugs.webkit.org/show_bug.cgi?id=173975

        Reviewed by Mark Lam.

        There is a site in JSC that try to walk another thread's stack.
        Currently, stack bounds are stored in WTFThreadData which is located
        in TLS. Thus, only the thread itself can access its own WTFThreadData.
        We workaround this situation by holding StackBounds in MachineThread in JSC,
        but StackBounds should be put in WTF::Thread instead.

        This patch adds StackBounds to WTF::Thread. StackBounds information is tightly
        coupled with Thread. Thus putting it in WTF::Thread is natural choice.

        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::MachineThread::MachineThread):
        (JSC::MachineThreads::MachineThread::captureStack):
        * heap/MachineStackMarker.h:
        (JSC::MachineThreads::MachineThread::stackBase):
        (JSC::MachineThreads::MachineThread::stackEnd):
        * runtime/VMTraps.cpp:

2017-07-18  Andy Estes  <aestes@apple.com>

        [Xcode] Enable CLANG_WARN_OBJC_LITERAL_CONVERSION
        https://bugs.webkit.org/show_bug.cgi?id=174631

        Reviewed by Sam Weinig.

        * Configurations/Base.xcconfig:

2017-07-18  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Modernize InjectedScriptSource
        https://bugs.webkit.org/show_bug.cgi?id=173890

        Reviewed by Brian Burg.

        * inspector/InjectedScript.h:
        Reorder functions to be slightly better.

        * inspector/InjectedScriptSource.js:
        - Convert to classes named InjectedScript and RemoteObject
        - Align InjectedScript's API with the wrapper C++ interfaces
        - Move some code to RemoteObject where appropriate (subtype, describe)
        - Move some code to helper functions (isPrimitiveValue, isDefined)
        - Refactor for readability and modern features
        - Remove some unused / unnecessary code

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

        Butterfly storage need not be initialized for indexing type Undecided.
        https://bugs.webkit.org/show_bug.cgi?id=174516

        Reviewed by Saam Barati.

        While it's not incorrect to initialize the butterfly storage when the
        indexingType is Undecided, it is inefficient as we'll end up initializing
        it again later when we convert the storage to a different indexingType.
        Some of our code already skips initializing Undecided butterflies.
        This patch makes it the consistent behavior everywhere.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
        * runtime/JSArray.cpp:
        (JSC::JSArray::tryCreateUninitializedRestricted):
        * runtime/JSArray.h:
        (JSC::JSArray::tryCreate):
        * runtime/JSObject.cpp:
        (JSC::JSObject::ensureLengthSlow):

2017-07-18  Saam Barati  <sbarati@apple.com>

        AirLowerAfterRegAlloc may incorrectly use a callee save that's live as a scratch register
        https://bugs.webkit.org/show_bug.cgi?id=174515
        <rdar://problem/33358092>

        Reviewed by Filip Pizlo.

        AirLowerAfterRegAlloc was computing the set of available scratch
        registers incorrectly. It was always excluding callee save registers
        from the set of live registers. It did not guarantee that live callee save
        registers were not in the set of scratch registers that could
        get clobbered. That's incorrect as the shuffling code is free
        to overwrite whatever is in the scratch register it gets passed.

        * b3/air/AirLowerAfterRegAlloc.cpp:
        (JSC::B3::Air::lowerAfterRegAlloc):
        * b3/testb3.cpp:
        (JSC::B3::functionNineArgs):
        (JSC::B3::testShuffleDoesntTrashCalleeSaves):
        (JSC::B3::run):
        * jit/RegisterSet.h:

2017-07-18  Andy Estes  <aestes@apple.com>

        [Xcode] Enable CLANG_WARN_NON_LITERAL_NULL_CONVERSION
        https://bugs.webkit.org/show_bug.cgi?id=174631

        Reviewed by Dan Bernstein.

        * Configurations/Base.xcconfig:

2017-07-18  Devin Rousso  <drousso@apple.com>

        Web Inspector: Add memoryCost to Inspector Protocol objects
        https://bugs.webkit.org/show_bug.cgi?id=174478

        Reviewed by Joseph Pecoraro.

        For non-array and non-object InspectorValue, calculate memoryCost as the sizeof the object,
        plus the memoryCost of the data if it is a string.

        For array InspectorValue, calculate memoryCost as the sum of the memoryCost of all items.

        For object InspectorValue, calculate memoryCost as the sum of the memoryCost of the string
        key plus the memoryCost of the InspectorValue for each entry.

        Test: TestWebKitAPI/Tests/JavaScriptCore/InspectorValue.cpp

        * inspector/InspectorValues.h:
        * inspector/InspectorValues.cpp:
        (Inspector::InspectorValue::memoryCost):
        (Inspector::InspectorObjectBase::memoryCost):
        (Inspector::InspectorArrayBase::memoryCost):

2017-07-18  Andy Estes  <aestes@apple.com>

        [Xcode] Enable CLANG_WARN_BLOCK_CAPTURE_AUTORELEASING
        https://bugs.webkit.org/show_bug.cgi?id=174631

        Reviewed by Darin Adler.

        * Configurations/Base.xcconfig:

2017-07-18  Michael Saboff  <msaboff@apple.com>

        [JSC] There should be a debug option to dump a compiled RegExp Pattern
        https://bugs.webkit.org/show_bug.cgi?id=174601

        Reviewed by Alex Christensen.

        Added the debug option dumpCompiledRegExpPatterns which will dump the YarrPattern and related
        objects after a regular expression has been compiled.

        * runtime/Options.h:
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::YarrPattern::compile):
        (JSC::Yarr::indentForNestingLevel):
        (JSC::Yarr::dumpUChar32):
        (JSC::Yarr::PatternAlternative::dump):
        (JSC::Yarr::PatternTerm::dumpQuantifier):
        (JSC::Yarr::PatternTerm::dump):
        (JSC::Yarr::PatternDisjunction::dump):
        (JSC::Yarr::YarrPattern::dumpPattern):
        * yarr/YarrPattern.h:
        (JSC::Yarr::YarrPattern::global):

2017-07-17  Darin Adler  <darin@apple.com>

        Improve use of NeverDestroyed
        https://bugs.webkit.org/show_bug.cgi?id=174348

        Reviewed by Sam Weinig.

        * heap/MachineStackMarker.cpp:
        * wasm/WasmMemory.cpp:
        Removed unneeded includes of NeverDestroyed.h in files that do not make use
        of NeverDestroyed.

2017-07-17  Michael Catanzaro  <mcatanzaro@igalia.com>

        [CMake] Macros in WebKitMacros.cmake should be prefixed with WEBKIT_ namespace
        https://bugs.webkit.org/show_bug.cgi?id=174547

        Reviewed by Alex Christensen.

        * CMakeLists.txt:
        * shell/CMakeLists.txt:

2017-07-17  Saam Barati  <sbarati@apple.com>

        Remove custom defined RELEASE_ASSERT in DFGObjectAllocationSinkingPhase
        https://bugs.webkit.org/show_bug.cgi?id=174584

        Rubber stamped by Keith Miller.

        I used it to diagnose a bug. The bug is now fixed. This custom
        RELEASE_ASSERT is no longer needed.

        * dfg/DFGObjectAllocationSinkingPhase.cpp:

2017-07-17  Michael Catanzaro  <mcatanzaro@igalia.com>

        -Wformat-truncation warning in ConfigFile.cpp
        https://bugs.webkit.org/show_bug.cgi?id=174506

        Reviewed by Darin Adler.

        Check if the JSC config filename would be truncated due to exceeding max path length. If so,
        return ParseError.

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

2017-07-17  Konstantin Tokarev  <annulen@yandex.ru>

        [CMake] Create targets before WEBKIT_INCLUDE_CONFIG_FILES_IF_EXISTS is called
        https://bugs.webkit.org/show_bug.cgi?id=174557

        Reviewed by Michael Catanzaro.

        * CMakeLists.txt:

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

        [WTF] Use std::unique_ptr for StackTrace
        https://bugs.webkit.org/show_bug.cgi?id=174495

        Reviewed by Alex Christensen.

        * runtime/ExceptionScope.cpp:
        (JSC::ExceptionScope::unexpectedExceptionMessage):
        * runtime/VM.cpp:
        (JSC::VM::throwException):

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

        [JSC] Use WTFMove to prune liveness in DFGAvailabilityMap
        https://bugs.webkit.org/show_bug.cgi?id=174423

        Reviewed by Saam Barati.

        * dfg/DFGAvailabilityMap.cpp:
        (JSC::DFG::AvailabilityMap::pruneHeap):
        (JSC::DFG::AvailabilityMap::pruneByLiveness):

2017-07-13  Michael Catanzaro  <mcatanzaro@igalia.com>

        Fix compiler warnings when building with GCC 7
        https://bugs.webkit.org/show_bug.cgi?id=174463

        Reviewed by Darin Adler.

        * disassembler/udis86/udis86_decode.c:
        (decode_operand):

2017-07-13  Michael Catanzaro  <mcatanzaro@igalia.com>

        Incorrect assertion in JSC::CallLinkInfo::callTypeFor
        https://bugs.webkit.org/show_bug.cgi?id=174467

        Reviewed by Saam Barati.

        * bytecode/CallLinkInfo.cpp:
        (JSC::CallLinkInfo::callTypeFor):

2017-07-13  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Remove unused and untested Page domain commands
        https://bugs.webkit.org/show_bug.cgi?id=174429

        Reviewed by Timothy Hatcher.

        * inspector/protocol/Page.json:

2017-07-13  Saam Barati  <sbarati@apple.com>

        Missing exception check in JSObject::hasInstance
        https://bugs.webkit.org/show_bug.cgi?id=174455
        <rdar://problem/31384608>

        Reviewed by Mark Lam.

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

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

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

        Reviewed by Saam Barati.

        This patch implements ECMA262 stage 3 Object Spread proposal [1].
        It's implemented using CopyDataPropertiesNoExclusions to copy
        all enumerable keys from object being spreaded. The implementation of
        CopyDataPropertiesNoExclusions follows the CopyDataProperties
        implementation, however we don't receive excludedNames as parameter.

        [1] - https://github.com/tc39/proposal-object-rest-spread

        * builtins/GlobalOperations.js:
        (globalPrivate.copyDataPropertiesNoExclusions):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitLoad):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::PropertyListNode::emitBytecode):
        (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):

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

        Gardening: build fix after r219434.
        https://bugs.webkit.org/show_bug.cgi?id=174441

        Not reviewed.

        Make public some MacroAssembler functions that are needed by the probe implementationq.

        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::trustedImm32FromPtr):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::linkCall):

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

        Move Probe code from AbstractMacroAssembler to MacroAssembler.
        https://bugs.webkit.org/show_bug.cgi?id=174441

        Reviewed by Saam Barati.

        This is a pure refactoring patch for moving probe code from the AbstractMacroAssembler
        to MacroAssembler.  There is no code behavior change.

        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler<AssemblerType>::Address::indexedBy):
        (JSC::AbstractMacroAssembler::CPUState::gprName): Deleted.
        (JSC::AbstractMacroAssembler::CPUState::fprName): Deleted.
        (JSC::AbstractMacroAssembler::CPUState::gpr): Deleted.
        (JSC::AbstractMacroAssembler::CPUState::fpr): Deleted.
        (JSC::MacroAssemblerType>::Address::indexedBy): Deleted.
        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::CPUState::gprName):
        (JSC::MacroAssembler::CPUState::fprName):
        (JSC::MacroAssembler::CPUState::gpr):
        (JSC::MacroAssembler::CPUState::fpr):
        * assembler/MacroAssemblerARM.cpp:
        (JSC::MacroAssembler::probe):
        (JSC::MacroAssemblerARM::probe): Deleted.
        * assembler/MacroAssemblerARM.h:
        * assembler/MacroAssemblerARM64.cpp:
        (JSC::MacroAssembler::probe):
        (JSC::MacroAssemblerARM64::probe): Deleted.
        * assembler/MacroAssemblerARM64.h:
        * assembler/MacroAssemblerARMv7.cpp:
        (JSC::MacroAssembler::probe):
        (JSC::MacroAssemblerARMv7::probe): Deleted.
        * assembler/MacroAssemblerARMv7.h:
        * assembler/MacroAssemblerMIPS.h:
        * assembler/MacroAssemblerX86Common.cpp:
        (JSC::MacroAssembler::probe):
        (JSC::MacroAssemblerX86Common::probe): Deleted.
        * assembler/MacroAssemblerX86Common.h:

2017-07-12  Saam Barati  <sbarati@apple.com>

        GenericArguments consults the wrong state when tracking modified argument descriptors and mapped arguments
        https://bugs.webkit.org/show_bug.cgi?id=174411
        <rdar://problem/31696186>

        Reviewed by Mark Lam.

        The code for deleting an argument was incorrectly referencing state
        when it decided if it should unmap or mark a property as having its
        descriptor modified. This patch fixes the bug where if we delete a
        property, we would sometimes not unmap an argument when deleting it.

        * runtime/GenericArgumentsInlines.h:
        (JSC::GenericArguments<Type>::getOwnPropertySlot):
        (JSC::GenericArguments<Type>::getOwnPropertySlotByIndex):
        (JSC::GenericArguments<Type>::deleteProperty):
        (JSC::GenericArguments<Type>::deletePropertyByIndex):

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

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

        "Can cause infinite recursion on iOS" (Requested by mlam on
        #webkit).

        Reverted changeset:

        "WTF::Thread should have the threads stack bounds."
        https://bugs.webkit.org/show_bug.cgi?id=173975
        http://trac.webkit.org/changeset/219176

2017-07-12  Matt Lewis  <jlewis3@apple.com>

        Unreviewed, rolling out r219401.

        This revision rolled out the previous patch, but after talking
        with reviewer, a rebaseline is what was needed.Rolling back in
        before rebaseline.

        Reverted changeset:

        "Unreviewed, rolling out r219379."
        https://bugs.webkit.org/show_bug.cgi?id=174400
        http://trac.webkit.org/changeset/219401

2017-07-12  Matt Lewis  <jlewis3@apple.com>

        Unreviewed, rolling out r219379.

        This revision caused a consistent failure in the test
        fast/dom/Window/property-access-on-cached-window-after-frame-
        removed.html.

        Reverted changeset:

        "Remove NAVIGATOR_HWCONCURRENCY"
        https://bugs.webkit.org/show_bug.cgi?id=174400
        http://trac.webkit.org/changeset/219379

2017-07-12  Tooru Fujisawa [:arai]  <arai.unmht@gmail.com>

        Wrong radix used in Unicode Escape in invalid character error message
        https://bugs.webkit.org/show_bug.cgi?id=174419

        Reviewed by Alex Christensen.

        * parser/Lexer.cpp:
        (JSC::Lexer<T>::invalidCharacterMessage):

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

        Remove NAVIGATOR_HWCONCURRENCY
        https://bugs.webkit.org/show_bug.cgi?id=174400

        Reviewed by Sam Weinig.

        * Configurations/FeatureDefines.xcconfig:

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

        Rolling out r219372.

        * Configurations/FeatureDefines.xcconfig:

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

        Remove NAVIGATOR_HWCONCURRENCY
        https://bugs.webkit.org/show_bug.cgi?id=174400

        Reviewed by Sam Weinig.

        * Configurations/FeatureDefines.xcconfig:

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

        remove the empty JavaScriptCore/wasm/js/WebAssemblyFunctionCell.* files
        https://bugs.webkit.org/show_bug.cgi?id=174397

        Rubber stamped by David Kilzer.

        * wasm/js/WebAssemblyFunctionCell.cpp: Removed.
        * wasm/js/WebAssemblyFunctionCell.h: Removed.

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

        Allocation sinking phase should consider a CheckStructure that would fail as an escape
        https://bugs.webkit.org/show_bug.cgi?id=174321
        <rdar://problem/32604963>

        Reviewed by Filip Pizlo.

        When the allocation sinking phase was generating stores to materialize
        objects in a cycle with each other, it would assume that each materialized
        object had a valid, non empty, set of structures. This is an OK assumption for
        the phase to make because how do you materialize an object with no structure?
        
        The abstract interpretation part of the phase will model what's in the heap.
        However, it would sometimes model that a CheckStructure would fail. The phase
        did nothing special for this; it just stored the empty set of structures for
        its representation of a particular allocation. However, what the phase proved
        in such a scenario is that, had the CheckStructure executed, it would have exited.
        
        This patch treats such CheckStructures and MultiGetByOffsets as escape points.
        This will cause the allocation in question to be materialized just before
        the CheckStructure, and then at execution time, the CheckStructure will exit.
        
        I wasn't able to write a test case for this. However, I was able to reproduce
        this crash by manually editing the IR. I've opened a separate bug to help us
        create a testing framework for writing tests for hard to reproduce bugs like this:
        https://bugs.webkit.org/show_bug.cgi?id=174322

        * dfg/DFGObjectAllocationSinkingPhase.cpp:

2017-07-10  Devin Rousso  <drousso@apple.com>

        Web Inspector: Highlight matching CSS canvas clients when hovering contexts in the Resources tab
        https://bugs.webkit.org/show_bug.cgi?id=174279

        Reviewed by Matt Baker.

        * inspector/protocol/DOM.json:
        Add `highlightNodeList` command that will highlight each node in the given list.

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

        Web Replay: remove some unused code
        https://bugs.webkit.org/show_bug.cgi?id=173903

        Rubber-stamped by Joseph Pecoraro.

        * CMakeLists.txt:
        * Configurations/FeatureDefines.xcconfig:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * inspector/protocol/Replay.json: Removed.
        * replay/EmptyInputCursor.h: Removed.
        * replay/EncodedValue.cpp: Removed.
        * replay/EncodedValue.h: Removed.
        * replay/InputCursor.h: Removed.
        * replay/JSInputs.json: Removed.
        * replay/NondeterministicInput.h: Removed.
        * replay/scripts/CodeGeneratorReplayInputs.py: Removed.
        * replay/scripts/CodeGeneratorReplayInputsTemplates.py: Removed.
        * replay/scripts/tests/expected/fail-on-c-style-enum-no-storage.json-error: Removed.
        * replay/scripts/tests/expected/fail-on-duplicate-enum-type.json-error: Removed.
        * replay/scripts/tests/expected/fail-on-duplicate-input-names.json-error: Removed.
        * replay/scripts/tests/expected/fail-on-duplicate-type-names.json-error: Removed.
        * replay/scripts/tests/expected/fail-on-enum-type-missing-values.json-error: Removed.
        * replay/scripts/tests/expected/fail-on-missing-input-member-name.json-error: Removed.
        * replay/scripts/tests/expected/fail-on-missing-input-name.json-error: Removed.
        * replay/scripts/tests/expected/fail-on-missing-input-queue.json-error: Removed.
        * replay/scripts/tests/expected/fail-on-missing-type-mode.json-error: Removed.
        * replay/scripts/tests/expected/fail-on-missing-type-name.json-error: Removed.
        * replay/scripts/tests/expected/fail-on-unknown-input-queue.json-error: Removed.
        * replay/scripts/tests/expected/fail-on-unknown-member-type.json-error: Removed.
        * replay/scripts/tests/expected/fail-on-unknown-type-mode.json-error: Removed.
        * replay/scripts/tests/expected/generate-enum-encoding-helpers-with-guarded-values.json-TestReplayInputs.cpp: Removed.
        * replay/scripts/tests/expected/generate-enum-encoding-helpers-with-guarded-values.json-TestReplayInputs.h: Removed.
        * replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.cpp: Removed.
        * replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.h: Removed.
        * replay/scripts/tests/expected/generate-enum-with-guard.json-TestReplayInputs.cpp: Removed.
        * replay/scripts/tests/expected/generate-enum-with-guard.json-TestReplayInputs.h: Removed.
        * replay/scripts/tests/expected/generate-enums-with-same-base-name.json-TestReplayInputs.cpp: Removed.
        * replay/scripts/tests/expected/generate-enums-with-same-base-name.json-TestReplayInputs.h: Removed.
        * replay/scripts/tests/expected/generate-event-loop-shape-types.json-error: Removed.
        * replay/scripts/tests/expected/generate-input-with-guard.json-TestReplayInputs.cpp: Removed.
        * replay/scripts/tests/expected/generate-input-with-guard.json-TestReplayInputs.h: Removed.
        * replay/scripts/tests/expected/generate-input-with-vector-members.json-TestReplayInputs.cpp: Removed.
        * replay/scripts/tests/expected/generate-input-with-vector-members.json-TestReplayInputs.h: Removed.
        * replay/scripts/tests/expected/generate-inputs-with-flags.json-TestReplayInputs.cpp: Removed.
        * replay/scripts/tests/expected/generate-inputs-with-flags.json-TestReplayInputs.h: Removed.
        * replay/scripts/tests/expected/generate-memoized-type-modes.json-TestReplayInputs.cpp: Removed.
        * replay/scripts/tests/expected/generate-memoized-type-modes.json-TestReplayInputs.h: Removed.
        * replay/scripts/tests/fail-on-c-style-enum-no-storage.json: Removed.
        * replay/scripts/tests/fail-on-duplicate-enum-type.json: Removed.
        * replay/scripts/tests/fail-on-duplicate-input-names.json: Removed.
        * replay/scripts/tests/fail-on-duplicate-type-names.json: Removed.
        * replay/scripts/tests/fail-on-enum-type-missing-values.json: Removed.
        * replay/scripts/tests/fail-on-missing-input-member-name.json: Removed.
        * replay/scripts/tests/fail-on-missing-input-name.json: Removed.
        * replay/scripts/tests/fail-on-missing-input-queue.json: Removed.
        * replay/scripts/tests/fail-on-missing-type-mode.json: Removed.
        * replay/scripts/tests/fail-on-missing-type-name.json: Removed.
        * replay/scripts/tests/fail-on-unknown-input-queue.json: Removed.
        * replay/scripts/tests/fail-on-unknown-member-type.json: Removed.
        * replay/scripts/tests/fail-on-unknown-type-mode.json: Removed.
        * replay/scripts/tests/generate-enum-encoding-helpers-with-guarded-values.json: Removed.
        * replay/scripts/tests/generate-enum-encoding-helpers.json: Removed.
        * replay/scripts/tests/generate-enum-with-guard.json: Removed.
        * replay/scripts/tests/generate-enums-with-same-base-name.json: Removed.
        * replay/scripts/tests/generate-event-loop-shape-types.json: Removed.
        * replay/scripts/tests/generate-input-with-guard.json: Removed.
        * replay/scripts/tests/generate-input-with-vector-members.json: Removed.
        * replay/scripts/tests/generate-inputs-with-flags.json: Removed.
        * replay/scripts/tests/generate-memoized-type-modes.json: Removed.
        * runtime/DateConstructor.cpp:
        (JSC::constructDate):
        (JSC::dateNow):
        (JSC::deterministicCurrentTime): Deleted.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::JSGlobalObject):
        (JSC::JSGlobalObject::setInputCursor): Deleted.
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::inputCursor): Deleted.

2017-07-10  Carlos Garcia Campos  <cgarcia@igalia.com>

        Move make-js-file-arrays.py from WebCore to JavaScriptCore
        https://bugs.webkit.org/show_bug.cgi?id=174024

        Reviewed by Michael Catanzaro.

        It's currently used only by WebCore, but it depends on other JavaScriptCore scripts and it's not WebCore
        specific at all. I plan to use it to compile the JavaScript atoms used by the WebDriver implementation.
        Added command line option to pass the namespace to use instead of using WebCore.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Scripts/make-js-file-arrays.py: Renamed from Source/WebCore/Scripts/make-js-file-arrays.py.
        (main):

2017-07-09  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Drop LineNumberAdder since we no longer treat <LF><CR> (not <CR><LF>) as one line terminator
        https://bugs.webkit.org/show_bug.cgi?id=174296

        Reviewed by Mark Lam.

        Previously, we treat <LF><CR> as one line terminator. So we increase line number by one.
        It caused a problem in scanning template literals. While template literals normalize
        <LF><CR> to <LF><LF>, we still needed to increase line number by only one.
        To handle it correctly, LineNumberAdder is introduced.

        As of r219263, <LF><CR> is counted as two line terminators. So we do not need to have
        LineNumberAdder. Let's just use shiftLineTerminator() instead.

        * parser/Lexer.cpp:
        (JSC::Lexer<T>::parseTemplateLiteral):
        (JSC::LineNumberAdder::LineNumberAdder): Deleted.
        (JSC::LineNumberAdder::clear): Deleted.
        (JSC::LineNumberAdder::add): Deleted.

2017-07-09  Dan Bernstein  <mitz@apple.com>

        [Xcode] ICU headers aren’t treated as system headers after r219155
        https://bugs.webkit.org/show_bug.cgi?id=174299

        Reviewed by Sam Weinig.

        * Configurations/JavaScriptCore.xcconfig: Pass --system-header-prefix=unicode/ to the C and
          C++ compilers.

* runtime/IntlCollator.cpp: Removed documentation warning suppression.
        * runtime/IntlDateTimeFormat.cpp: Ditto.
        * runtime/JSGlobalObject.cpp: Ditto.
        * runtime/StringPrototype.cpp: Ditto.

2017-07-09  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Use fastMalloc / fastFree for STL containers
        https://bugs.webkit.org/show_bug.cgi?id=174297

        Reviewed by Sam Weinig.

        In some places, we intentionally use STL containers over WTF containers.
        For example, we sometimes use std::unordered_{set,map} instead of WTF::Hash{Set,Map}
        because we do not have effective empty / deleted representations in the space of key's value.
        But just using STL container means using libc's malloc instead of our fast malloc (bmalloc if it is enabled).

        We introduce WTF::FastAllocator. This is C++ allocator implementation using fastMalloc and fastFree.
        We specify this allocator to STL containers' template parameter to allocate memory from fastMalloc.

        This WTF::FastAllocator gives us a chance to use STL containers if it is necessary
        without compromising memory allocation throughput.

        * dfg/DFGGraph.h:
        * dfg/DFGIntegerCheckCombiningPhase.cpp:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::switchStringSlow):
        * runtime/FunctionHasExecutedCache.h:
        * runtime/TypeLocationCache.h:

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

        Drop NOSNIFF compile flag
        https://bugs.webkit.org/show_bug.cgi?id=174289

        Reviewed by Michael Catanzaro.

        * Configurations/FeatureDefines.xcconfig:

2017-07-07  AJ Ringer  <aringer@apple.com>

        Lower the max_protection for the separated heap
        https://bugs.webkit.org/show_bug.cgi?id=174281

        Reviewed by Oliver Hunt.

        Switch to vm_protect so we can set maximum page protection.

        * jit/ExecutableAllocator.cpp:
        (JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps):
        (JSC::ExecutableAllocator::allocate):

2017-07-07  Devin Rousso  <drousso@apple.com>

        Web Inspector: Show all elements currently using a given CSS Canvas
        https://bugs.webkit.org/show_bug.cgi?id=173965

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/Canvas.json:
         - Add `requestCSSCanvasClientNodes` command for getting the node IDs all nodes using this
           canvas via -webkit-canvas.
         - Add `cssCanvasClientNodesChanged` event that is dispatched whenever a node is
           added/removed from the list of -webkit-canvas clients.

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

        \n\r is not the same as \r\n.
        https://bugs.webkit.org/show_bug.cgi?id=173053

        Reviewed by Keith Miller.

        * parser/Lexer.cpp:
        (JSC::Lexer<T>::shiftLineTerminator):
        (JSC::LineNumberAdder::add):

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

        Unreviewed, rolling out r219238, r219239, and r219241.
        https://bugs.webkit.org/show_bug.cgi?id=174265

        "fast/workers/dedicated-worker-lifecycle.html is flaky"
        (Requested by yusukesuzuki on #webkit).

        Reverted changesets:

        "[WTF] Implement WTF::ThreadGroup"
        https://bugs.webkit.org/show_bug.cgi?id=174081
        http://trac.webkit.org/changeset/219238

        "Unreviewed, build fix after r219238"
        https://bugs.webkit.org/show_bug.cgi?id=174081
        http://trac.webkit.org/changeset/219239

        "Unreviewed, CLoop build fix after r219238"
        https://bugs.webkit.org/show_bug.cgi?id=174081
        http://trac.webkit.org/changeset/219241

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

        Unreviewed, CLoop build fix after r219238
        https://bugs.webkit.org/show_bug.cgi?id=174081

        * heap/MachineStackMarker.cpp:

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

        [WTF] Implement WTF::ThreadGroup
        https://bugs.webkit.org/show_bug.cgi?id=174081

        Reviewed by Mark Lam.

        Large part of MachineThreads are now removed and replaced with WTF::ThreadGroup.
        And SamplingProfiler and others interact with WTF::Thread directly.

        * API/tests/ExecutionTimeLimitTest.cpp:
        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::MachineThreads):
        (JSC::captureStack):
        (JSC::MachineThreads::tryCopyOtherThreadStack):
        (JSC::MachineThreads::tryCopyOtherThreadStacks):
        (JSC::MachineThreads::gatherConservativeRoots):
        (JSC::ActiveMachineThreadsManager::Locker::Locker): Deleted.
        (JSC::ActiveMachineThreadsManager::add): Deleted.
        (JSC::ActiveMachineThreadsManager::remove): Deleted.
        (JSC::ActiveMachineThreadsManager::contains): Deleted.
        (JSC::ActiveMachineThreadsManager::ActiveMachineThreadsManager): Deleted.
        (JSC::activeMachineThreadsManager): Deleted.
        (JSC::MachineThreads::~MachineThreads): Deleted.
        (JSC::MachineThreads::addCurrentThread): Deleted.
        (): Deleted.
        (JSC::MachineThreads::removeThread): Deleted.
        (JSC::MachineThreads::removeThreadIfFound): Deleted.
        (JSC::MachineThreads::MachineThread::MachineThread): Deleted.
        (JSC::MachineThreads::MachineThread::getRegisters): Deleted.
        (JSC::MachineThreads::MachineThread::Registers::stackPointer): Deleted.
        (JSC::MachineThreads::MachineThread::Registers::framePointer): Deleted.
        (JSC::MachineThreads::MachineThread::Registers::instructionPointer): Deleted.
        (JSC::MachineThreads::MachineThread::Registers::llintPC): Deleted.
        (JSC::MachineThreads::MachineThread::captureStack): Deleted.
        * heap/MachineStackMarker.h:
        (JSC::MachineThreads::addCurrentThread):
        (JSC::MachineThreads::getLock):
        (JSC::MachineThreads::threads):
        (JSC::MachineThreads::MachineThread::suspend): Deleted.
        (JSC::MachineThreads::MachineThread::resume): Deleted.
        (JSC::MachineThreads::MachineThread::threadID): Deleted.
        (JSC::MachineThreads::MachineThread::stackBase): Deleted.
        (JSC::MachineThreads::MachineThread::stackEnd): Deleted.
        (JSC::MachineThreads::threadsListHead): Deleted.
        * runtime/SamplingProfiler.cpp:
        (JSC::FrameWalker::isValidFramePointer):
        (JSC::SamplingProfiler::SamplingProfiler):
        (JSC::SamplingProfiler::takeSample):
        (JSC::SamplingProfiler::noticeCurrentThreadAsJSCExecutionThread):
        * runtime/SamplingProfiler.h:
        * wasm/WasmMachineThreads.cpp:
        (JSC::Wasm::resetInstructionCacheOnAllThreads):

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

        We are missing places where we invalidate the for-in context
        https://bugs.webkit.org/show_bug.cgi?id=174184

        Reviewed by Geoffrey Garen.

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

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

        Unreviewed, suppress warnings in GCC environment

        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        * runtime/IntlCollator.cpp:
        * runtime/IntlDateTimeFormat.cpp:
        * runtime/JSGlobalObject.cpp:
        * runtime/StringPrototype.cpp:

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

        NewArray in FTLLowerDFGToB3 does not handle speculating on doubles when having a bad time
        https://bugs.webkit.org/show_bug.cgi?id=174188
        <rdar://problem/30581423>

        Reviewed by Mark Lam.

        We were calling lowJSValue(edge) when we were speculating the
        edge as double. This isn't allowed. We should have been using
        lowDouble.
        
        This patch also adds a new option, called useArrayAllocationProfiling,
        which defaults to true. When false, it will make the array allocation
        profile not actually sample seen arrays. It'll force the allocation
        profile's predicted indexing type to be ArrayWithUndecided. Adding
        this option made it trivial to write a test for this bug.

        * bytecode/ArrayAllocationProfile.cpp:
        (JSC::ArrayAllocationProfile::updateIndexingType):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArray):
        * runtime/Options.h:

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

        WTF::Thread should have the threads stack bounds.
        https://bugs.webkit.org/show_bug.cgi?id=173975

        Reviewed by Keith Miller.

        There is a site in JSC that try to walk another thread's stack.
        Currently, stack bounds are stored in WTFThreadData which is located
        in TLS. Thus, only the thread itself can access its own WTFThreadData.
        We workaround this situation by holding StackBounds in MachineThread in JSC,
        but StackBounds should be put in WTF::Thread instead.

        This patch moves StackBounds from WTFThreadData to WTF::Thread. StackBounds
        information is tightly coupled with Thread. Thus putting it in WTF::Thread
        is natural choice.

        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::MachineThread::MachineThread):
        (JSC::MachineThreads::MachineThread::captureStack):
        * heap/MachineStackMarker.h:
        (JSC::MachineThreads::MachineThread::stackBase):
        (JSC::MachineThreads::MachineThread::stackEnd):
        * runtime/InitializeThreading.cpp:
        (JSC::initializeThreading):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::updateStackLimits):
        (JSC::VM::committedStackByteCount):
        * runtime/VM.h:
        (JSC::VM::isSafeToRecurse):
        * runtime/VMEntryScope.cpp:
        (JSC::VMEntryScope::VMEntryScope):
        * runtime/VMInlines.h:
        (JSC::VM::ensureStackCapacityFor):
        * runtime/VMTraps.cpp:
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::YarrPatternConstructor::isSafeToRecurse):

2017-07-05  Keith Miller  <keith_miller@apple.com>

        Crashing with information should have an abort reason
        https://bugs.webkit.org/show_bug.cgi?id=174185

        Reviewed by Saam Barati.

        Add crash information for the abstract interpreter and add an enum
        value for object allocation sinking.

        * assembler/AbortReason.h:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::verifyEdge):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::logDFGAssertionFailure):
        * dfg/DFGObjectAllocationSinkingPhase.cpp:

2017-07-03  Myles C. Maxfield  <mmaxfield@apple.com>

        Remove copy of ICU headers from WebKit
        https://bugs.webkit.org/show_bug.cgi?id=116407

        Reviewed by Alex Christensen.

        Use WTF's copy of ICU headers.

        * Configurations/Base.xcconfig:
        * icu/unicode/localpointer.h: Removed.
        * icu/unicode/parseerr.h: Removed.
        * icu/unicode/platform.h: Removed.
        * icu/unicode/ptypes.h: Removed.
        * icu/unicode/putil.h: Removed.
        * icu/unicode/uchar.h: Removed.
        * icu/unicode/ucnv.h: Removed.
        * icu/unicode/ucnv_err.h: Removed.
        * icu/unicode/ucol.h: Removed.
        * icu/unicode/uconfig.h: Removed.
        * icu/unicode/ucurr.h: Removed.
        * icu/unicode/uenum.h: Removed.
        * icu/unicode/uiter.h: Removed.
        * icu/unicode/uloc.h: Removed.
        * icu/unicode/umachine.h: Removed.
        * icu/unicode/unorm.h: Removed.
        * icu/unicode/unorm2.h: Removed.
        * icu/unicode/urename.h: Removed.
        * icu/unicode/uscript.h: Removed.
        * icu/unicode/uset.h: Removed.
        * icu/unicode/ustring.h: Removed.
        * icu/unicode/utf.h: Removed.
        * icu/unicode/utf16.h: Removed.
        * icu/unicode/utf8.h: Removed.
        * icu/unicode/utf_old.h: Removed.
        * icu/unicode/utypes.h: Removed.
        * icu/unicode/uvernum.h: Removed.
        * icu/unicode/uversion.h: Removed.
        * runtime/IntlCollator.cpp:
        * runtime/IntlDateTimeFormat.cpp:
        (JSC::IntlDateTimeFormat::partTypeString):
        * runtime/JSGlobalObject.cpp:
        * runtime/StringPrototype.cpp:
        (JSC::normalize):
        (JSC::stringProtoFuncNormalize):

2017-07-05  Devin Rousso  <drousso@apple.com>

        Web Inspector: Allow users to log any tracked canvas context
        https://bugs.webkit.org/show_bug.cgi?id=173397
        <rdar://problem/33111581>

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/Canvas.json:
        Add `resolveCanvasContext` command that returns a RemoteObject for the given canvas context.

2017-07-05  Jonathan Bedard  <jbedard@apple.com>

        Add WebKitPrivateFrameworkStubs for iOS 11
        https://bugs.webkit.org/show_bug.cgi?id=173988

        Reviewed by David Kilzer.

        * Configurations/Base.xcconfig: iphoneos and iphonesimulator should use the
        same directory for private framework stubs.

2017-07-05  JF Bastien  <jfbastien@apple.com>

        WebAssembly: implement name section's module name, skip unknown sections
        https://bugs.webkit.org/show_bug.cgi?id=172008

        Reviewed by Keith Miller.

        Parse the WebAssembly module name properly, and skip unknown
        sections. This is useful because as toolchains support new types
        of names we want to keep displaying the information we know about
        and simply ignore new information. That capability was designed
        into WebAssembly's name section.

        Failure to commit this patch would mean that WebKit won't display
        stack trace information, which would make developers sad.

        Module names were added here: https://github.com/WebAssembly/design/pull/1055

        Note that this patch doesn't do anything with the parsed name! Two
        reasons for this: module names aren't supported in binaryen yet,
        so I can't write a simple binary test; and using the name is a
        slightly riskier change because it requires changing StackVisitor
        + StackFrame (where they print "[wasm code]") which requires
        figuring out the frame's Module. The latter bit isn't trivial
        because we only know wasm frames from their tag bits, and
        CodeBlocks are always nullptr.

        Binaryen bug: https://github.com/WebAssembly/binaryen/issues/1010

        I filed #174098 to use the module name.

        * wasm/WasmFormat.h:
        (JSC::Wasm::isValidNameType):
        * wasm/WasmNameSectionParser.cpp:

2017-07-04  Joseph Pecoraro  <pecoraro@apple.com>

        Cleanup some StringBuilder use
        https://bugs.webkit.org/show_bug.cgi?id=174118

        Reviewed by Andreas Kling.

        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * tools/FunctionOverrides.cpp:
        (JSC::parseClause):
        * wasm/WasmOMGPlan.cpp:
        * wasm/WasmPlan.cpp:
        * wasm/WasmValidate.cpp:

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

        LayoutTest workers/bomb.html is a Crash
        https://bugs.webkit.org/show_bug.cgi?id=167757
        <rdar://problem/33086462>

        Reviewed by Keith Miller.

        VMTraps::SignalSender was accessing VM fields even after
        the VM was destroyed. This happened when the SignalSender
        thread was in the middle of its work() function while VMTraps
        was notified that the VM was shutting down. The VM would proceed
        to run its destructor even after the SignalSender thread finished
        doing its work. This means that the SignalSender thread was accessing
        VM field eve after VM was destructed (including itself, since it is
        transitively owned by the VM). The VM must wait for the SignalSender
        thread to shutdown before it can continue to destruct itself.

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

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

        DFGBytecodeParser op_to_this does not access the correct instruction offset for to this status
        https://bugs.webkit.org/show_bug.cgi?id=174110

        Reviewed by Michael Saboff.

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

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

        Add a new assertion to object allocation sinking phase
        https://bugs.webkit.org/show_bug.cgi?id=174107

        Rubber stamped by Filip Pizlo.

        * dfg/DFGObjectAllocationSinkingPhase.cpp:

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

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

        crashing constantly when initializing UIWebView (Requested by
        thorton on #webkit).

        Reverted changeset:

        "WTF::Thread should have the threads stack bounds."
        https://bugs.webkit.org/show_bug.cgi?id=173975
        http://trac.webkit.org/changeset/219060

2017-07-03  Matt Lewis  <jlewis3@apple.com>

        Unreviewed, rolling out r219103.

        Caused multiple build failures.

        Reverted changeset:

        "Remove copy of ICU headers from WebKit"
        https://bugs.webkit.org/show_bug.cgi?id=116407
        http://trac.webkit.org/changeset/219103

2017-07-03  Myles C. Maxfield  <mmaxfield@apple.com>

        Remove copy of ICU headers from WebKit
        https://bugs.webkit.org/show_bug.cgi?id=116407

        Reviewed by Alex Christensen.

        Use WTF's copy of ICU headers.

        * Configurations/Base.xcconfig:
        * icu/unicode/localpointer.h: Removed.
        * icu/unicode/parseerr.h: Removed.
        * icu/unicode/platform.h: Removed.
        * icu/unicode/ptypes.h: Removed.
        * icu/unicode/putil.h: Removed.
        * icu/unicode/uchar.h: Removed.
        * icu/unicode/ucnv.h: Removed.
        * icu/unicode/ucnv_err.h: Removed.
        * icu/unicode/ucol.h: Removed.
        * icu/unicode/uconfig.h: Removed.
        * icu/unicode/ucurr.h: Removed.
        * icu/unicode/uenum.h: Removed.
        * icu/unicode/uiter.h: Removed.
        * icu/unicode/uloc.h: Removed.
        * icu/unicode/umachine.h: Removed.
        * icu/unicode/unorm.h: Removed.
        * icu/unicode/unorm2.h: Removed.
        * icu/unicode/urename.h: Removed.
        * icu/unicode/uscript.h: Removed.
        * icu/unicode/uset.h: Removed.
        * icu/unicode/ustring.h: Removed.
        * icu/unicode/utf.h: Removed.
        * icu/unicode/utf16.h: Removed.
        * icu/unicode/utf8.h: Removed.
        * icu/unicode/utf_old.h: Removed.
        * icu/unicode/utypes.h: Removed.
        * icu/unicode/uvernum.h: Removed.
        * icu/unicode/uversion.h: Removed.
        * runtime/IntlCollator.cpp:
        * runtime/IntlDateTimeFormat.cpp:
        * runtime/JSGlobalObject.cpp:
        * runtime/StringPrototype.cpp:

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

        Add better crash logging for allocation sinking phase
        https://bugs.webkit.org/show_bug.cgi?id=174102
        <rdar://problem/33112092>

        Rubber stamped by Filip Pizlo.

        I'm trying to gather better information from crashlogs about why
        we're crashing in the allocation sinking phase. I'm adding a allocation
        sinking specific RELEASE_ASSERT as well as marking a few functions as
        NEVER_INLINE to have the stack traces in the crash trace contain more
        actionable information.

        * dfg/DFGObjectAllocationSinkingPhase.cpp:

2017-07-03  Sam Weinig  <sam@webkit.org>

        [WebIDL] Remove more unnecessary uses of the preprocessor in idl files
        https://bugs.webkit.org/show_bug.cgi?id=174083

        Reviewed by Alex Christensen.

        * Configurations/FeatureDefines.xcconfig:
        Add ENABLE_NAVIGATOR_STANDALONE.

2017-07-03  Andy Estes  <aestes@apple.com>

        [Xcode] Add an experimental setting to build with ccache
        https://bugs.webkit.org/show_bug.cgi?id=173875

        Reviewed by Tim Horton.

        * Configurations/DebugRelease.xcconfig: Included ccache.xcconfig.

2017-07-03  Devin Rousso  <drousso@apple.com>

        Web Inspector: Support listing WebGL2 and WebGPU contexts
        https://bugs.webkit.org/show_bug.cgi?id=173396

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/Canvas.json:
        * inspector/scripts/codegen/generator.py:
        (Generator.stylized_name_for_enum_value):
        Add cases for handling new Canvas.ContextType protocol enumerations:
         - "webgl2" maps to `WebGL2`
         - "webgpu" maps to `WebGPU`

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

        WTF::Thread should have the threads stack bounds.
        https://bugs.webkit.org/show_bug.cgi?id=173975

        Reviewed by Mark Lam.

        There is a site in JSC that try to walk another thread's stack.
        Currently, stack bounds are stored in WTFThreadData which is located
        in TLS. Thus, only the thread itself can access its own WTFThreadData.
        We workaround this situation by holding StackBounds in MachineThread in JSC,
        but StackBounds should be put in WTF::Thread instead.

        This patch moves StackBounds from WTFThreadData to WTF::Thread. StackBounds
        information is tightly coupled with Thread. Thus putting it in WTF::Thread
        is natural choice.

        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::MachineThread::MachineThread):
        (JSC::MachineThreads::MachineThread::captureStack):
        * heap/MachineStackMarker.h:
        (JSC::MachineThreads::MachineThread::stackBase):
        (JSC::MachineThreads::MachineThread::stackEnd):
        * runtime/InitializeThreading.cpp:
        (JSC::initializeThreading):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::updateStackLimits):
        (JSC::VM::committedStackByteCount):
        * runtime/VM.h:
        (JSC::VM::isSafeToRecurse):
        * runtime/VMEntryScope.cpp:
        (JSC::VMEntryScope::VMEntryScope):
        * runtime/VMInlines.h:
        (JSC::VM::ensureStackCapacityFor):
        * runtime/VMTraps.cpp:
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::YarrPatternConstructor::isSafeToRecurse):

2017-07-01  Dan Bernstein  <mitz@apple.com>

        [iOS] Remove code only needed when building for iOS 9.x
        https://bugs.webkit.org/show_bug.cgi?id=174068

        Reviewed by Tim Horton.

        * Configurations/FeatureDefines.xcconfig:
        * jit/ExecutableAllocator.cpp:
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):

2017-07-01  Dan Bernstein  <mitz@apple.com>

        [macOS] Remove code only needed when building for OS X Yosemite
        https://bugs.webkit.org/show_bug.cgi?id=174067

        Reviewed by Tim Horton.

        * API/WebKitAvailability.h:
        * Configurations/Base.xcconfig:
        * Configurations/DebugRelease.xcconfig:
        * Configurations/FeatureDefines.xcconfig:
        * Configurations/Version.xcconfig:

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

        Unreviewed, build fix for GCC
        https://bugs.webkit.org/show_bug.cgi?id=174034

        * b3/testb3.cpp:
        (JSC::B3::testDoubleLiteralComparison):

2017-06-30  Keith Miller  <keith_miller@apple.com>

        Force crashWithInfo to be out of line.
        https://bugs.webkit.org/show_bug.cgi?id=174028

        Reviewed by Filip Pizlo.

        Update DFG_ASSERT macro to call CRASH_WITH_SECURITY_IMPLICATION_AND_INFO.

        * dfg/DFGGraph.cpp:
        (JSC::DFG::logDFGAssertionFailure):
        (JSC::DFG::Graph::logAssertionFailure):
        (JSC::DFG::crash): Deleted.
        (JSC::DFG::Graph::handleAssertionFailure): Deleted.
        * dfg/DFGGraph.h:

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

        [JSC] Use AbstractMacroAssembler::random instead of holding WeakRandom in JIT
        https://bugs.webkit.org/show_bug.cgi?id=174053

        Reviewed by Geoffrey Garen.

        We already have AbstractMacroAssembler::random() function. Use it instead.

        * jit/JIT.cpp:
        (JSC::JIT::JIT):
        (JSC::JIT::compileWithoutLinking):
        * jit/JIT.h:

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

        [WTF] Drop SymbolRegistry::keyForSymbol
        https://bugs.webkit.org/show_bug.cgi?id=174052

        Reviewed by Sam Weinig.

        * runtime/SymbolConstructor.cpp:
        (JSC::symbolConstructorKeyFor):

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

        B3ReduceStrength should reduce EqualOrUnordered over const float input
        https://bugs.webkit.org/show_bug.cgi?id=174039

        Reviewed by Michael Saboff.

        We perform this folding for ConstDoubleValue. It is simply
        an oversight that we didn't do it for ConstFloatValue.

        * b3/B3ConstFloatValue.cpp:
        (JSC::B3::ConstFloatValue::equalOrUnorderedConstant):
        * b3/B3ConstFloatValue.h:
        * b3/testb3.cpp:
        (JSC::B3::testFloatEqualOrUnorderedFolding):
        (JSC::B3::testFloatEqualOrUnorderedFoldingNaN):
        (JSC::B3::testFloatEqualOrUnorderedDontFold):
        (JSC::B3::run):

2017-06-30  Matt Baker  <mattbaker@apple.com>

        Web Inspector: AsyncStackTrace nodes can be corrupted when truncating
        https://bugs.webkit.org/show_bug.cgi?id=173840
        <rdar://problem/30840820>

        Reviewed by Joseph Pecoraro.

        When truncating an asynchronous stack trace, the parent chain is traversed
        until a locked node is found. The path from this node to the root is shared
        by more than one stack trace, and cannot be safely modified. Starting at
        the first locked node, the path is cloned and becomes a new stack trace tree.

        However, the clone operation initialized each new AsyncStackTrace node with
        the original node's parent. This would increment the child count of the original
        node. When cloning nodes, new nodes should not have their parent set until the
        next node up the parent chain is cloned.

        * inspector/AsyncStackTrace.cpp:
        (Inspector::AsyncStackTrace::truncate):

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

        RegExp's  anchored with .* with \g flag can return wrong match start for strings with multiple matches
        https://bugs.webkit.org/show_bug.cgi?id=174044

        Reviewed by Oliver Hunt.

        The .* enclosure optimization didn't respect that we can start matching from a non-zero
        index.  This optimization treats /.*<some-terms>.*/ by first matching the <some-terms> and
        then finding the extent of the match by going back to the beginning of the line and going
        forward to the end of the line.  The code that went back to the beginning of the line
        checked for an index of 0 instead of comparing the index to the start position.  This start
        position is passed as the initial index.

        Added another temporary register to the YARR JIT to contain the start position for
        platforms that have spare registers.

        * yarr/Yarr.h:
        * yarr/YarrInterpreter.cpp:
        (JSC::Yarr::Interpreter::matchDotStarEnclosure):
        (JSC::Yarr::Interpreter::Interpreter):
        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::generateDotStarEnclosure):
        (JSC::Yarr::YarrGenerator::compile):
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::YarrPattern::YarrPattern):
        * yarr/YarrPattern.h:
        (JSC::Yarr::YarrPattern::reset):

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

        B3MoveConstants floatZero() returns the wrong ValueKey
        https://bugs.webkit.org/show_bug.cgi?id=174040

        Reviewed by Filip Pizlo.

        It had a typo where the ValueKey for floatZero() produces a Double
        instead of a Float.

        * b3/B3MoveConstants.cpp:

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

        B3ReduceDoubleToFloat incorrectly reduces operations over two double constants
        https://bugs.webkit.org/show_bug.cgi?id=174034
        <rdar://problem/30793007>

        Reviewed by Filip Pizlo.

        B3ReduceDoubleToFloat had a bug in it where it would incorrectly
        reduce binary operations over double constants into the same binary
        operation over the double constants casted to floats. This is clearly
        incorrect as these two things will produce different values. For example:
        
        a = DoubleConst(bitwise_cast<double>(0x8000000000000001ull))
        b = DoubleConst(bitwise_cast<double>(0x0000000000000000ull))
        c = EqualOrUnordered(@a, @b) // produces 0
        
        into:
        
        a = FloatConst(static_cast<float>(bitwise_cast<double>(0x8000000000000001ull)))
        b = FloatConst(static_cast<float>(bitwise_cast<double>(0x0000000000000000ull)))
        c = EqualOrUnordered(@a, @b) // produces 1
        
        Which produces a different value for @c.

        * b3/B3ReduceDoubleToFloat.cpp:
        * b3/testb3.cpp:
        (JSC::B3::doubleEq):
        (JSC::B3::doubleNeq):
        (JSC::B3::doubleGt):
        (JSC::B3::doubleGte):
        (JSC::B3::doubleLt):
        (JSC::B3::doubleLte):
        (JSC::B3::testDoubleLiteralComparison):
        (JSC::B3::run):

2017-06-29  Jer Noble  <jer.noble@apple.com>

        Make Legacy EME API controlled by RuntimeEnabled setting.
        https://bugs.webkit.org/show_bug.cgi?id=173994

        Reviewed by Sam Weinig.

        * Configurations/FeatureDefines.xcconfig:
        * runtime/CommonIdentifiers.h:

2017-06-30  Ryosuke Niwa  <rniwa@webkit.org>

        Ran sort-Xcode-project-file.

        * JavaScriptCore.xcodeproj/project.pbxproj:

2017-06-30  Matt Lewis  <jlewis3@apple.com>

        Unreviewed, rolling out r218992.

        The patch broke the iOS device builds.

        Reverted changeset:

        "DFG_ASSERT should allow stuffing registers before trapping."
        https://bugs.webkit.org/show_bug.cgi?id=174005
        http://trac.webkit.org/changeset/218992

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

        RegExpCachedResult::setInput should reify left and right contexts
        https://bugs.webkit.org/show_bug.cgi?id=173818

        Reviewed by Keith Miller.
        
        If you don't reify them in setInput, then when you later try to reify them, you'll end up
        using indices into an old input string to create a substring of a new input string. That
        never goes well.

        * runtime/RegExpCachedResult.cpp:
        (JSC::RegExpCachedResult::setInput):

2017-06-30  Keith Miller  <keith_miller@apple.com>

        DFG_ASSERT should allow stuffing registers before trapping.
        https://bugs.webkit.org/show_bug.cgi?id=174005

        Reviewed by Mark Lam.

        DFG_ASSERT currently prints error data to stderr before crashing,
        which is nice for local development. In the wild, however, we
        can't see this information in crash logs. This patch enables
        stuffing some of the most useful information from DFG_ASSERTS into
        up to five registers right before crashing. The values stuffed
        should not impact any logging during local development.

        * assembler/AbortReason.h:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::verifyEdge):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::logForCrash):
        (JSC::DFG::Graph::logAssertionFailure):
        (JSC::DFG::crash): Deleted.
        (JSC::DFG::Graph::handleAssertionFailure): Deleted.
        * dfg/DFGGraph.h:

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

        Calculating postCapacity in unshiftCountSlowCase is wrong
        https://bugs.webkit.org/show_bug.cgi?id=173992
        <rdar://problem/32283199>

        Reviewed by Keith Miller.

        This patch fixes a bug inside unshiftCountSlowCase where we would use
        more memory than we allocated. The bug was when deciding how much extra
        space we have after the vector we've allocated. This area is called the
        postCapacity. The largest legal postCapacity value we could use is the
        space we allocated minus the space we need:
        largestPossiblePostCapacity = newStorageCapacity - requiredVectorLength;
        However, the code was calculating the postCapacity as:
        postCapacity = max(newStorageCapacity - requiredVectorLength, count);
        
        where count is how many elements we're appending. Depending on the inputs,
        count could be larger than (newStorageCapacity - requiredVectorLength). This
        would cause us to use more memory than we actually allocated.

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

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

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

        "It changes the behavior of the JS API's JSEvaluateScript
        which breaks TurboTax" (Requested by saamyjoon on #webkit).

        Reverted changeset:

        "test262: Completion values for control flow do not match the
        spec"
        https://bugs.webkit.org/show_bug.cgi?id=171265
        http://trac.webkit.org/changeset/218512

2017-06-29  JF Bastien  <jfbastien@apple.com>

        WebAssembly: disable some APIs under CSP
        https://bugs.webkit.org/show_bug.cgi?id=173892
        <rdar://problem/32914613>

        Reviewed by Daniel Bates.

        We should disable parts of WebAssembly under Content Security
        Policy as discussed here:

        https://github.com/WebAssembly/design/issues/1092

        Exactly what should be disabled isn't super clear, so we may as
        well be conservative and disable many things if developers already
        opted into CSP. It's easy to loosen what we disable later.

        This patch disables:
        - WebAssembly.Instance
        - WebAssembly.instantiate
        - WebAssembly.Memory
        - WebAssembly.Table

        And leaves:
        - WebAssembly on the global object
        - WebAssembly.Module
        - WebAssembly.compile
        - WebAssembly.CompileError
        - WebAssembly.LinkError

        Nothing because currently unimplmented:
        - WebAssembly.compileStreaming
        - WebAssembly.instantiateStreaming

        That way it won't be possible to call WebAssembly-compiled code,
        or create memories (which use fancy 4GiB allocations
        sometimes). Table isn't really useful on its own, and eventually
        we may make them shareable so without more details it seems benign
        to disable them (and useless if we don't).

        I haven't done anything with postMessage, so you can still
        postMessage a WebAssembly.Module cross-CSP, but you can't
        instantiate it so it's useless. Because of this I elected to leave
        WebAssembly.Module and friends available.

        I haven't added any new directives. It's still unsafe-eval. We can
        add something else later, but it seems odd to add a WebAssembly as
        a new capability and tell developers "you should have been using
        this directive which we just implemented if you wanted to disable
        WebAssembly which didn't exist when you adopted CSP". So IMO we
        should keep unsafe-eval as it currently is, add WebAssembly to
        what it disables, and later consider having two new directives
        which do each individually or something.

        In all cases I throw an EvalError *before* other WebAssembly
        errors would be produced.

        Note that, as for eval, reporting doesn't work and is tracked by
        https://webkit.org/b/111869

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::JSGlobalObject):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::webAssemblyEnabled):
        (JSC::JSGlobalObject::webAssemblyDisabledErrorMessage):
        (JSC::JSGlobalObject::setWebAssemblyEnabled):
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::create):
        * wasm/js/JSWebAssemblyMemory.cpp:
        (JSC::JSWebAssemblyMemory::create):
        * wasm/js/JSWebAssemblyMemory.h:
        * wasm/js/JSWebAssemblyTable.cpp:
        (JSC::JSWebAssemblyTable::create):
        * wasm/js/WebAssemblyMemoryConstructor.cpp:
        (JSC::constructJSWebAssemblyMemory):

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

        VMTraps has some races
        https://bugs.webkit.org/show_bug.cgi?id=173941

        Reviewed by Michael Saboff.

        This patch refactors much of the VMTraps API.

        On the message sending side:

        1) No longer uses the Yarr JIT check to determine if we are in
        RegExp code. That was unsound because RegExp JIT code can be run
        on compilation threads.  Instead it looks at the current frame's
        code block slot and checks if it is valid, which is the same as
        what it did for JIT code previously.

        2) Only have one signal sender thread, previously, there could be
        many at once, which caused some data races. Additionally, the
        signal sender thread is an automatic thread so it will deallocate
        itself when not in use.

        On the VMTraps breakpoint side:

        1) We now have a true mapping of if we hit a breakpoint instead of
        a JIT assertion. So the exception handler won't eat JIT assertions
        anymore.

        2) It jettisons all CodeBlocks that have VMTraps breakpoints on
        them instead of every CodeBlock on the stack. This both prevents
        us from hitting stale VMTraps breakpoints and also doesn't OSR
        codeblocks that otherwise don't need to be jettisoned.

        3) The old exception handler could theoretically fail for a couple
        of reasons then resume execution with a clobbered instruction
        set. This patch will kill the program if the exception handler
        would fail.

        This patch also refactors some of the jsc.cpp functions to take the
        CommandLine options object instead of individual options. Also, there
        is a new command line option that makes exceptions due to watchdog
        timeouts an acceptable result.

        * API/tests/testapi.c:
        (main):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::installVMTrapBreakpoints):
        * dfg/DFGCommonData.cpp:
        (JSC::DFG::pcCodeBlockMap):
        (JSC::DFG::CommonData::invalidate):
        (JSC::DFG::CommonData::~CommonData):
        (JSC::DFG::CommonData::installVMTrapBreakpoints):
        (JSC::DFG::codeBlockForVMTrapPC):
        * dfg/DFGCommonData.h:
        * jsc.cpp:
        (functionDollarAgentStart):
        (checkUncaughtException):
        (checkException):
        (runWithOptions):
        (printUsageStatement):
        (CommandLine::parseArguments):
        (jscmain):
        (runWithScripts): Deleted.
        * runtime/JSLock.cpp:
        (JSC::JSLock::didAcquireLock):
        * runtime/VMTraps.cpp:
        (JSC::sanitizedTopCallFrame):
        (JSC::VMTraps::tryInstallTrapBreakpoints):
        (JSC::VMTraps::willDestroyVM):
        (JSC::VMTraps::fireTrap):
        (JSC::VMTraps::handleTraps):
        (JSC::VMTraps::VMTraps):
        (JSC::VMTraps::~VMTraps):
        (JSC::findActiveVMAndStackBounds): Deleted.
        (JSC::installSignalHandler): Deleted.
        (JSC::VMTraps::addSignalSender): Deleted.
        (JSC::VMTraps::removeSignalSender): Deleted.
        (JSC::VMTraps::SignalSender::willDestroyVM): Deleted.
        (JSC::VMTraps::SignalSender::send): Deleted.
        * runtime/VMTraps.h:
        (JSC::VMTraps::~VMTraps): Deleted.
        (JSC::VMTraps::SignalSender::SignalSender): Deleted.

2017-06-28  Devin Rousso  <drousso@apple.com>

        Web Inspector: Instrument active pixel memory used by canvases
        https://bugs.webkit.org/show_bug.cgi?id=173087
        <rdar://problem/32719261>

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/Canvas.json:
         - Add optional `memoryCost` attribute to the `Canvas` type.
         - Add `canvasMemoryChanged` event that is dispatched when the `memoryCost` of a canvas changes.

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

        Web Inspector: Cleanup Protocol JSON files
        https://bugs.webkit.org/show_bug.cgi?id=173934

        Reviewed by Matt Baker.

        * inspector/protocol/ApplicationCache.json:
        * inspector/protocol/CSS.json:
        * inspector/protocol/Console.json:
        * inspector/protocol/DOM.json:
        * inspector/protocol/DOMDebugger.json:
        * inspector/protocol/Debugger.json:
        * inspector/protocol/LayerTree.json:
        * inspector/protocol/Network.json:
        * inspector/protocol/Page.json:
        * inspector/protocol/Runtime.json:
        Be more consistent about placement of `description` property.

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

        Web Inspector: Remove unused Inspector domain events
        https://bugs.webkit.org/show_bug.cgi?id=173905

        Reviewed by Matt Baker.

        * inspector/protocol/Inspector.json:

2017-06-28  JF Bastien  <jfbastien@apple.com>

        Ensure that computed new stack pointer values do not underflow.
        https://bugs.webkit.org/show_bug.cgi?id=173700
        <rdar://problem/32926032>

        Reviewed by Filip Pizlo and Saam Barati, update reviewed by Mark Lam.

        Patch by Mark Lam, with the following fix:

        Re-apply this patch, it originally broke the ARM build because the llint code
        generated `subs xzr, x3, sp` which isn't valid ARM64: the third operand cannot
        be SP (that encoding would be ZR instead, subtracting zero). Flip the comparison
        and operands to emit valid code (because the second operand can be SP).

        1. Added a RELEASE_ASSERT to BytecodeGenerator::generate() to ensure that
           m_numCalleeLocals is sane.

        2. Added underflow checks in LLInt code and VarargsFrame code.

        3. Introduce minimumReservedZoneSize, which is hardcoded to 16K.
           Ensure that Options::reservedZoneSize() is at least minimumReservedZoneSize.
           Ensure that Options::softReservedZoneSize() is at least greater than
           Options::reservedZoneSize() by minimumReservedZoneSize.

        4. Ensure that stack checks emitted by JIT tiers include an underflow check if
           and only if the max size of the frame is greater than Options::reservedZoneSize().

           By design, we are guaranteed to have at least Options::reservedZoneSize() bytes
           of memory at the bottom (end) of the stack.  This means that, at any time, the
           frame pointer must be at least Options::reservedZoneSize() bytes away from the
           end of the stack.  Hence, if the max frame size is less than
           Options::reservedZoneSize(), there's no way that frame pointer - max
           frame size can underflow, and we can elide the underflow check.

           Note that we use Options::reservedZoneSize() instead of
           Options::softReservedZoneSize() for determine if we need an underflow check.
           This is because the softStackLimit that is used for stack checks can be set
           based on Options::reservedZoneSize() during error handling (e.g. when creating
           strings for instantiating the Error object).  Hence, the guaranteed minimum of
           distance between the frame pointer and the end of the stack is
           Options::reservedZoneSize() and nor Options::softReservedZoneSize().

           Note also that we ensure that Options::reservedZoneSize() is at least
           minimumReservedZoneSize (i.e. 16K).  In typical deployments,
           Options::reservedZoneSize() may be larger.  Using Options::reservedZoneSize()
           instead of minimumReservedZoneSize gives us more chances to elide underflow
           checks.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::requiredRegisterCountForExecutionAndExit):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::emitStackOverflowCheck):
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::lower):
        * jit/JIT.cpp:
        (JSC::JIT::compileWithoutLinking):
        * jit/SetupVarargsFrame.cpp:
        (JSC::emitSetupVarargsFrameFastCase):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/MinimumReservedZoneSize.h: Added.
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):
        * runtime/VM.cpp:
        (JSC::VM::updateStackLimits):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction):

2017-06-28  Chris Dumez  <cdumez@apple.com>

        Unreviewed, rolling out r218869.

        Broke the iOS build

        Reverted changeset:

        "Ensure that computed new stack pointer values do not
        underflow."
        https://bugs.webkit.org/show_bug.cgi?id=173700
        http://trac.webkit.org/changeset/218869

2017-06-28  Chris Dumez  <cdumez@apple.com>

        Unreviewed, rolling out r218873.

        Broke the iOS build

        Reverted changeset:

        "Gardening: CLoop build fix."
        https://bugs.webkit.org/show_bug.cgi?id=173700
        http://trac.webkit.org/changeset/218873

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

        Gardening: CLoop build fix.
        https://bugs.webkit.org/show_bug.cgi?id=173700
        <rdar://problem/32926032>

        Not reviewed.

        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):

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

        Ensure that computed new stack pointer values do not underflow.
        https://bugs.webkit.org/show_bug.cgi?id=173700
        <rdar://problem/32926032>

        Reviewed by Filip Pizlo and Saam Barati.

        1. Added a RELEASE_ASSERT to BytecodeGenerator::generate() to ensure that
           m_numCalleeLocals is sane.

        2. Added underflow checks in LLInt code and VarargsFrame code.

        3. Introduce minimumReservedZoneSize, which is hardcoded to 16K.
           Ensure that Options::reservedZoneSize() is at least minimumReservedZoneSize.
           Ensure that Options::softReservedZoneSize() is at least greater than
           Options::reservedZoneSize() by minimumReservedZoneSize.

        4. Ensure that stack checks emitted by JIT tiers include an underflow check if
           and only if the max size of the frame is greater than Options::reservedZoneSize().

           By design, we are guaranteed to have at least Options::reservedZoneSize() bytes
           of memory at the bottom (end) of the stack.  This means that, at any time, the
           frame pointer must be at least Options::reservedZoneSize() bytes away from the
           end of the stack.  Hence, if the max frame size is less than
           Options::reservedZoneSize(), there's no way that frame pointer - max
           frame size can underflow, and we can elide the underflow check.

           Note that we use Options::reservedZoneSize() instead of
           Options::softReservedZoneSize() for determine if we need an underflow check.
           This is because the softStackLimit that is used for stack checks can be set
           based on Options::reservedZoneSize() during error handling (e.g. when creating
           strings for instantiating the Error object).  Hence, the guaranteed minimum of
           distance between the frame pointer and the end of the stack is
           Options::reservedZoneSize() and nor Options::softReservedZoneSize().

           Note also that we ensure that Options::reservedZoneSize() is at least
           minimumReservedZoneSize (i.e. 16K).  In typical deployments,
           Options::reservedZoneSize() may be larger.  Using Options::reservedZoneSize()
           instead of minimumReservedZoneSize gives us more chances to elide underflow
           checks.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::requiredRegisterCountForExecutionAndExit):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::lower):
        * jit/JIT.cpp:
        (JSC::JIT::compileWithoutLinking):
        * jit/SetupVarargsFrame.cpp:
        (JSC::emitSetupVarargsFrameFastCase):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/MinimumReservedZoneSize.h: Added.
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):
        * runtime/VM.cpp:
        (JSC::VM::updateStackLimits):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction):

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

        WebAssembly: running out of executable memory should throw OoM
        https://bugs.webkit.org/show_bug.cgi?id=171537
        <rdar://problem/32963338>

        Reviewed by Saam Barati.

        Both on first compile with BBQ as well as on tier-up with OMG,
        running out of X memory shouldn't cause the entire program to
        terminate. An exception will do when compiling initial code (since
        we don't have any other fallback at the moment), and refusal to
        tier up will do as well (it'll just be slower).

        This is useful because programs which generate huge amounts of
        code simply look like crashes, which developers report to
        us. Getting a JavaScript exception instead is much clearer.

        * jit/ExecutableAllocator.cpp:
        (JSC::ExecutableAllocator::allocate):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::shouldJIT):
        * runtime/Options.h:
        * wasm/WasmBBQPlan.cpp:
        (JSC::Wasm::BBQPlan::prepare):
        (JSC::Wasm::BBQPlan::complete):
        * wasm/WasmBinding.cpp:
        (JSC::Wasm::wasmToJs):
        (JSC::Wasm::wasmToWasm):
        * wasm/WasmBinding.h:
        * wasm/WasmOMGPlan.cpp:
        (JSC::Wasm::OMGPlan::work):
        * wasm/js/JSWebAssemblyCodeBlock.cpp:
        (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock):
        * wasm/js/JSWebAssemblyCodeBlock.h:
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::finalizeCreation):

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

        JITStubRoutine::passesFilter should use isJITPC
        https://bugs.webkit.org/show_bug.cgi?id=173906

        Reviewed by JF Bastien.

        This patch makes JITStubRoutine use the isJITPC abstraction defined
        inside ExecutableAllocator.h. Before, JITStubRoutine was using a
        hardcoded platform size constant. This means it'd do the wrong thing
        if Options::jitMemoryReservationSize() was larger than the defined
        constant for that platform. This patch also removes a bunch of
        dead code in that file.

        * jit/ExecutableAllocator.cpp:
        * jit/ExecutableAllocator.h:
        * jit/JITStubRoutine.h:
        (JSC::JITStubRoutine::passesFilter):
        (JSC::JITStubRoutine::canPerformRangeFilter): Deleted.
        (JSC::JITStubRoutine::filteringStartAddress): Deleted.
        (JSC::JITStubRoutine::filteringExtentSize): Deleted.

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

        Fix some stale comments in Wasm code base
        https://bugs.webkit.org/show_bug.cgi?id=173814

        Reviewed by Mark Lam.

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

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

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

        Reviewed by Saam Barati.

        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
        set the identifiers of already destructured properties, following spec draft
        section[2], and then pass it as excludedNames to CopyDataProperties.
        The rest destructuring 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.

        In this implementation we aren't using excludeList as constant if
        destructuring pattern contains computed property, i.e. we can
        just determine the key to be excluded at runtime. If we can define all
        identifiers in the pattern in compile time, we then create a
        constant JSSet. This approach gives a good performance improvement,
        since we allocate the excludeSet just once, reducing GC pressure.

        [1] - https://github.com/tc39/proposal-object-rest-spread
        [2] - https://tc39.github.io/proposal-object-rest-spread/#Rest-RuntimeSemantics-PropertyDestructuringAssignmentEvaluation
        [3] - https://tc39.github.io/proposal-object-rest-spread/#AbstractOperations-CopyDataProperties

        * builtins/BuiltinNames.h:
        * builtins/GlobalOperations.js:
        (globalPrivate.copyDataProperties):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        * 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/JSGlobalObject.h:
        (JSC::JSGlobalObject::asyncFunctionStructure):
        (JSC::JSGlobalObject::setStructure): Deleted.
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::privateToObject):
        * runtime/JSGlobalObjectFunctions.h:
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructor::finishCreation):
        * runtime/SetPrototype.cpp:
        (JSC::SetPrototype::finishCreation):

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

        [JSC] Do not touch VM after notifying Ready in DFG::Worklist
        https://bugs.webkit.org/show_bug.cgi?id=173888

        Reviewed by Saam Barati.

        After notifying Plan::Ready and releasing Worklist lock, VM can be destroyed.
        Thus, Plan::vm() can return a destroyed VM. Do not touch it.
        This causes occasional SEGV / assertion failures in workers/bomb test.

        * dfg/DFGWorklist.cpp:

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

        Remove an inaccurate comment inside DFGClobberize.h
        https://bugs.webkit.org/show_bug.cgi?id=163874

        Reviewed by Filip Pizlo.

        The comment said that Clobberize may or may not be sound if run prior to
        doing type inference. This is not correct, though. Clobberize *must* be sound
        prior do doing type inference since we use it inside the BytecodeParser, which
        is the very first thing the DFG does.

        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):

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

        Function constructor needs to follow the spec and validate parameters and body independently
        https://bugs.webkit.org/show_bug.cgi?id=173303
        <rdar://problem/32732526>

        Reviewed by Keith Miller.

        The Function constructor must check the arguments and body strings
        independently for syntax errors. People rely on this specified behavior
        to verify that a particular string is a valid function body. We used
        to check these things strings concatenated together, instead of
        independently. For example, this used to be valid: `Function("/*", "*/){")`.
        However, we should throw a syntax error here since "(/*)" is not a valid
        parameter list, and "*/){" is not a valid body.
        
        To implement the specified behavior, we check the syntax independently of
        both the body and the parameter list. To check that the parameter list has
        valid syntax, we check that it is valid if in a function with an empty body.
        To check that the body has valid syntax, we check it is valid in a function
        with an empty parameter list.

        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck):

2017-06-27  Ting-Wei Lan  <lantw44@gmail.com>

        Add missing includes to fix compilation error on FreeBSD
        https://bugs.webkit.org/show_bug.cgi?id=172919

        Reviewed by Mark Lam.

        * API/JSRemoteInspector.h:
        * API/tests/GlobalContextWithFinalizerTest.cpp:
        * API/tests/TypedArrayCTest.cpp:

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

        Web Inspector: Crash generating object preview for ArrayIterator
        https://bugs.webkit.org/show_bug.cgi?id=173754
        <rdar://problem/32859012>

        Reviewed by Saam Barati.

        When Inspector generates an object preview for an ArrayIterator instance it made
        a "clone" of the original ArrayIterator instance by constructing a new object with
        the instance's structure. However, user code could have modified that instance's
        structure, such as adding / removing properties. The `return` property had special
        meaning, and our clone did not fill that slot. This approach is brittle in that
        we weren't satisfying the expectations of an object with a particular Structure,
        and the original goal of having Web Inspector peek values of built-in Iterators
        was to avoid observable behavior.

        This tightens Web Inspector's Iterator preview to only peek values if the
        Iterators would actually be non-observable. It also builds an ArrayIterator
        clone like a regular object construction.

        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::cloneArrayIteratorObject):
        Build up the Object from scratch with a new ArrayIterator prototype.

        (Inspector::JSInjectedScriptHost::iteratorEntries):
        Only clone and peek iterators if it would not be observable.
        Also update iteration to be more in line with IterationOperations, such as when
        we call iteratorClose.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::JSGlobalObject):
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::stringIteratorProtocolWatchpoint):
        * runtime/JSGlobalObjectInlines.h:
        (JSC::JSGlobalObject::isStringPrototypeIteratorProtocolFastAndNonObservable):
        Add a StringIterator WatchPoint in line with the Array/Map/Set iterator watchpoints.

        * runtime/JSMap.cpp:
        (JSC::JSMap::isIteratorProtocolFastAndNonObservable):
        (JSC::JSMap::canCloneFastAndNonObservable):
        * runtime/JSMap.h:
        * runtime/JSSet.cpp:
        (JSC::JSSet::isIteratorProtocolFastAndNonObservable):
        (JSC::JSSet::canCloneFastAndNonObservable):
        * runtime/JSSet.h:
        Promote isIteratorProtocolFastAndNonObservable to a method.

        * runtime/JSObject.cpp:
        (JSC::canDoFastPutDirectIndex):
        * runtime/JSTypeInfo.h:
        (JSC::TypeInfo::isArgumentsType):
        Helper to detect if an Object is an Arguments type.

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

        RegExpPrototype.js builtin uses for-of iteration which is almost certainly incorrect
        https://bugs.webkit.org/show_bug.cgi?id=173740

        Reviewed by Mark Lam.

        The builtin was using for-of iteration to iterate over an internal
        list in its algorithm. For-of iteration is observable via user code
        in the global object, so this approach was wrong as it would break if
        a user changed the Array iteration protocol in some way.

        * builtins/RegExpPrototype.js:
        (replace):

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

        Renamed DumpRegisterFunctor to DumpReturnVirtualPCFunctor.
        https://bugs.webkit.org/show_bug.cgi?id=173848

        Reviewed by JF Bastien.

        This functor only dumps the return VirtualPC.

        * interpreter/Interpreter.cpp:
        (JSC::DumpReturnVirtualPCFunctor::DumpReturnVirtualPCFunctor):
        (JSC::Interpreter::dumpRegisters):
        (JSC::DumpRegisterFunctor::DumpRegisterFunctor): Deleted.
        (JSC::DumpRegisterFunctor::operator()): Deleted.

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

        Crash in JSC::Lexer<unsigned char>::setCode
        https://bugs.webkit.org/show_bug.cgi?id=172754

        Reviewed by Mark Lam.

        The lexer was asking one of its buffers to reserve initial space that
        was O(text size in bytes). For large sources, this would end up causing
        the vector to overflow and crash. This patch changes this code be like
        the Lexer's other buffers and to only reserve a small starting buffer.

        * parser/Lexer.cpp:
        (JSC::Lexer<T>::setCode):

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

        [WTF] Drop Thread::create(obsolete things) API since we can use lambda
        https://bugs.webkit.org/show_bug.cgi?id=173825

        Reviewed by Saam Barati.

        * jsc.cpp:
        (startTimeoutThreadIfNeeded):
        (timeoutThreadMain): Deleted.

2017-06-26  Konstantin Tokarev  <annulen@yandex.ru>

        Unreviewed, add missing header for CLoop

        * runtime/SymbolTable.cpp:

2017-06-26  Konstantin Tokarev  <annulen@yandex.ru>

        Unreviewed, add missing header icncludes

        * parser/Lexer.h:

2017-06-25  Konstantin Tokarev  <annulen@yandex.ru>

        Remove excessive headers from JavaScriptCore
        https://bugs.webkit.org/show_bug.cgi?id=173812

        Reviewed by Darin Adler.

        * API/APIUtils.h:
        * assembler/LinkBuffer.cpp:
        * assembler/MacroAssemblerCodeRef.cpp:
        * b3/air/AirLiveness.h:
        * b3/air/AirLowerAfterRegAlloc.cpp:
        * bindings/ScriptValue.cpp:
        * bindings/ScriptValue.h:
        * bytecode/AccessCase.cpp:
        * bytecode/AccessCase.h:
        * bytecode/ArrayProfile.h:
        * bytecode/BytecodeDumper.h:
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        * bytecode/BytecodeKills.h:
        * bytecode/BytecodeLivenessAnalysis.h:
        * bytecode/BytecodeUseDef.h:
        * bytecode/CallLinkStatus.h:
        * bytecode/CodeBlock.h:
        * bytecode/CodeOrigin.h:
        * bytecode/ComplexGetStatus.h:
        * bytecode/GetByIdStatus.h:
        * bytecode/GetByIdVariant.h:
        * bytecode/InlineCallFrame.h:
        * bytecode/InlineCallFrameSet.h:
        * bytecode/Instruction.h:
        * bytecode/InternalFunctionAllocationProfile.h:
        * bytecode/JumpTable.h:
        * bytecode/MethodOfGettingAValueProfile.h:
        * bytecode/ObjectPropertyConditionSet.h:
        * bytecode/Operands.h:
        * bytecode/PolymorphicAccess.h:
        * bytecode/PutByIdStatus.h:
        * bytecode/SpeculatedType.cpp:
        * bytecode/StructureSet.h:
        * bytecode/StructureStubInfo.h:
        * bytecode/UnlinkedCodeBlock.h:
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecode/ValueProfile.h:
        * bytecompiler/BytecodeGenerator.cpp:
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/Label.h:
        * bytecompiler/StaticPropertyAnalysis.h:
        * debugger/DebuggerCallFrame.cpp:
        * dfg/DFGAbstractInterpreter.h:
        * dfg/DFGAdjacencyList.h:
        * dfg/DFGArgumentsUtilities.h:
        * dfg/DFGArrayMode.h:
        * dfg/DFGArrayifySlowPathGenerator.h:
        * dfg/DFGBackwardsPropagationPhase.h:
        * dfg/DFGBasicBlock.h:
        * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
        * dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h:
        * dfg/DFGCapabilities.h:
        * dfg/DFGCommon.h:
        * dfg/DFGCommonData.h:
        * dfg/DFGDesiredIdentifiers.h:
        * dfg/DFGDesiredWatchpoints.h:
        * dfg/DFGDisassembler.cpp:
        * dfg/DFGDominators.h:
        * dfg/DFGDriver.cpp:
        * dfg/DFGDriver.h:
        * dfg/DFGEdgeDominates.h:
        * dfg/DFGFinalizer.h:
        * dfg/DFGGenerationInfo.h:
        * dfg/DFGJITCompiler.cpp:
        * dfg/DFGJITCompiler.h:
        * dfg/DFGJITFinalizer.h:
        * dfg/DFGLivenessAnalysisPhase.h:
        * dfg/DFGMinifiedNode.h:
        * dfg/DFGMultiGetByOffsetData.h:
        * dfg/DFGNaturalLoops.cpp:
        * dfg/DFGNaturalLoops.h:
        * dfg/DFGNode.h:
        * dfg/DFGOSRAvailabilityAnalysisPhase.h:
        * dfg/DFGOSRExit.h:
        * dfg/DFGOSRExitCompilationInfo.h:
        * dfg/DFGOSRExitCompiler.cpp:
        * dfg/DFGOSRExitCompiler.h:
        * dfg/DFGOSRExitJumpPlaceholder.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPlan.h:
        * dfg/DFGPreciseLocalClobberize.h:
        * dfg/DFGPromotedHeapLocation.h:
        * dfg/DFGRegisteredStructure.h:
        * dfg/DFGRegisteredStructureSet.h:
        * dfg/DFGSaneStringGetByValSlowPathGenerator.h:
        * dfg/DFGSlowPathGenerator.h:
        * dfg/DFGSnippetParams.h:
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGToFTLDeferredCompilationCallback.h:
        * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.h:
        * dfg/DFGValidate.h:
        * dfg/DFGValueSource.h:
        * dfg/DFGVariableEvent.h:
        * dfg/DFGVariableEventStream.h:
        * dfg/DFGWorklist.h:
        * domjit/DOMJITCallDOMGetterSnippet.h:
        * domjit/DOMJITEffect.h:
        * ftl/FTLLink.cpp:
        * ftl/FTLLowerDFGToB3.cpp:
        * ftl/FTLPatchpointExceptionHandle.h:
        * heap/AllocatorAttributes.h:
        * heap/CodeBlockSet.h:
        * heap/DeferGC.h:
        * heap/GCSegmentedArray.h:
        * heap/Heap.cpp:
        * heap/Heap.h:
        * heap/IncrementalSweeper.h:
        * heap/ListableHandler.h:
        * heap/MachineStackMarker.h:
        * heap/MarkedAllocator.h:
        * heap/MarkedBlock.cpp:
        * heap/MarkedBlock.h:
        * heap/MarkingConstraint.h:
        * heap/SlotVisitor.cpp:
        * heap/SlotVisitor.h:
        * inspector/ConsoleMessage.cpp:
        * inspector/ConsoleMessage.h:
        * inspector/InjectedScript.h:
        * inspector/InjectedScriptHost.h:
        * inspector/InjectedScriptManager.cpp:
        * inspector/JSGlobalObjectInspectorController.cpp:
        * inspector/JavaScriptCallFrame.h:
        * inspector/ScriptCallStack.h:
        * inspector/ScriptCallStackFactory.cpp:
        * inspector/ScriptDebugServer.h:
        * inspector/agents/InspectorConsoleAgent.h:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        * 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/agents/JSGlobalObjectConsoleAgent.h:
        * inspector/agents/JSGlobalObjectDebuggerAgent.cpp:
        * inspector/agents/JSGlobalObjectDebuggerAgent.h:
        * inspector/agents/JSGlobalObjectRuntimeAgent.h:
        * inspector/augmentable/AlternateDispatchableAgent.h:
        * interpreter/CLoopStack.h:
        * interpreter/CachedCall.h:
        * interpreter/CallFrame.h:
        * interpreter/Interpreter.cpp:
        * interpreter/Interpreter.h:
        * jit/AssemblyHelpers.cpp:
        * jit/AssemblyHelpers.h:
        * jit/CCallHelpers.h:
        * jit/CallFrameShuffler.h:
        * jit/ExecutableAllocator.h:
        * jit/GCAwareJITStubRoutine.h:
        * jit/HostCallReturnValue.h:
        * jit/ICStats.h:
        * jit/JIT.cpp:
        * jit/JIT.h:
        * jit/JITAddGenerator.h:
        * jit/JITCall32_64.cpp:
        * jit/JITCode.h:
        * jit/JITDisassembler.cpp:
        * jit/JITExceptions.cpp:
        * jit/JITMathIC.h:
        * jit/JITOpcodes.cpp:
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITThunks.cpp:
        * jit/JITThunks.h:
        * jit/JSInterfaceJIT.h:
        * jit/PCToCodeOriginMap.h:
        * jit/PolymorphicCallStubRoutine.h:
        * jit/RegisterSet.h:
        * jit/Repatch.h:
        * jit/SetupVarargsFrame.h:
        * jit/Snippet.h:
        * jit/SnippetParams.h:
        * jit/ThunkGenerators.h:
        * jsc.cpp:
        * llint/LLIntCLoop.h:
        * llint/LLIntEntrypoint.h:
        * llint/LLIntExceptions.h:
        * llint/LLIntOfflineAsmConfig.h:
        * llint/LLIntSlowPaths.cpp:
        * parser/NodeConstructors.h:
        * parser/Nodes.cpp:
        * parser/Nodes.h:
        * parser/Parser.cpp:
        * parser/Parser.h:
        * parser/ParserTokens.h:
        * parser/SourceProviderCacheItem.h:
        * profiler/ProfilerBytecodeSequence.h:
        * profiler/ProfilerDatabase.cpp:
        * profiler/ProfilerDatabase.h:
        * profiler/ProfilerOrigin.h:
        * profiler/ProfilerOriginStack.h:
        * profiler/ProfilerProfiledBytecodes.h:
        * profiler/ProfilerUID.h:
        * runtime/AbstractModuleRecord.h:
        * runtime/ArrayConstructor.h:
        * runtime/ArrayConventions.h:
        * runtime/ArrayIteratorPrototype.h:
        * runtime/ArrayPrototype.h:
        * runtime/BasicBlockLocation.h:
        * runtime/Butterfly.h:
        * runtime/CallData.cpp:
        * runtime/CodeCache.h:
        * runtime/CommonSlowPaths.cpp:
        * runtime/CommonSlowPaths.h:
        * runtime/CommonSlowPathsExceptions.cpp:
        * runtime/Completion.cpp:
        * runtime/ControlFlowProfiler.h:
        * runtime/DateInstanceCache.h:
        * runtime/ErrorConstructor.h:
        * runtime/ErrorInstance.h:
        * runtime/ExceptionHelpers.cpp:
        * runtime/ExceptionHelpers.h:
        * runtime/ExecutableBase.h:
        * runtime/FunctionExecutable.h:
        * runtime/HasOwnPropertyCache.h:
        * runtime/Identifier.h:
        * runtime/InternalFunction.h:
        * runtime/IntlCollator.cpp:
        * runtime/IntlCollatorPrototype.h:
        * runtime/IntlDateTimeFormatPrototype.h:
        * runtime/IntlNumberFormat.cpp:
        * runtime/IntlNumberFormatPrototype.h:
        * runtime/IteratorOperations.cpp:
        * runtime/JSArray.h:
        * runtime/JSArrayBufferPrototype.h:
        * runtime/JSCJSValue.h:
        * runtime/JSCJSValueInlines.h:
        * runtime/JSCell.h:
        * runtime/JSFunction.cpp:
        * runtime/JSFunction.h:
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        * runtime/JSGlobalObject.cpp:
        * runtime/JSGlobalObject.h:
        * runtime/JSGlobalObjectDebuggable.cpp:
        * runtime/JSGlobalObjectDebuggable.h:
        * runtime/JSGlobalObjectFunctions.cpp:
        * runtime/JSGlobalObjectFunctions.h:
        * runtime/JSJob.cpp:
        * runtime/JSLock.h:
        * runtime/JSModuleLoader.cpp:
        * runtime/JSModuleNamespaceObject.h:
        * runtime/JSModuleRecord.h:
        * runtime/JSObject.cpp:
        * runtime/JSObject.h:
        * runtime/JSRunLoopTimer.h:
        * runtime/JSTemplateRegistryKey.h:
        * runtime/JSTypedArrayPrototypes.cpp:
        * runtime/JSTypedArrayPrototypes.h:
        * runtime/JSTypedArrays.h:
        * runtime/LiteralParser.h:
        * runtime/MatchResult.h:
        * runtime/MemoryStatistics.h:
        * runtime/PrivateName.h:
        * runtime/PromiseDeferredTimer.h:
        * runtime/ProxyObject.h:
        * runtime/RegExp.h:
        * runtime/SamplingProfiler.cpp:
        * runtime/SmallStrings.h:
        * runtime/StringPrototype.cpp:
        * runtime/StringRecursionChecker.h:
        * runtime/Structure.h:
        * runtime/SymbolConstructor.h:
        * runtime/SymbolPrototype.cpp:
        * runtime/SymbolPrototype.h:
        * runtime/TypeProfiler.h:
        * runtime/TypeProfilerLog.h:
        * runtime/TypedArrayType.h:
        * runtime/VM.cpp:
        * runtime/VM.h:
        * runtime/VMEntryScope.h:
        * runtime/WeakMapData.h:
        * runtime/WriteBarrier.h:
        * tools/FunctionOverrides.cpp:
        * tools/FunctionOverrides.h:
        * wasm/WasmBinding.cpp:
        * wasm/js/JSWebAssemblyCodeBlock.h:
        * wasm/js/WebAssemblyPrototype.cpp:
        * yarr/Yarr.h:
        * yarr/YarrJIT.cpp:
        * yarr/YarrJIT.h:
        * yarr/YarrParser.h:

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

        [JSC] Clean up Object.entries implementation
        https://bugs.webkit.org/show_bug.cgi?id=173759

        Reviewed by Sam Weinig.

        This patch cleans up Object.entries implementation.
        We drop unused private functions. And we merge the
        implementation into Object.entries.

        It slightly speeds up Object.entries speed.

                                     baseline                  patched

            object-entries      148.0101+-5.6627          142.1877+-4.8661          might be 1.0409x faster


        * builtins/BuiltinNames.h:
        * builtins/ObjectConstructor.js:
        (entries):
        (globalPrivate.enumerableOwnProperties): Deleted.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/ObjectConstructor.cpp:
        (JSC::ownEnumerablePropertyKeys): Deleted.
        * runtime/ObjectConstructor.h:

2017-06-24  Joseph Pecoraro  <pecoraro@apple.com>

        Remove Reflect.enumerate
        https://bugs.webkit.org/show_bug.cgi?id=173806

        Reviewed by Yusuke Suzuki.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::subtype):
        (Inspector::JSInjectedScriptHost::getInternalProperties):
        (Inspector::JSInjectedScriptHost::iteratorEntries):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSPropertyNameIterator.cpp: Removed.
        * runtime/JSPropertyNameIterator.h: Removed.
        * runtime/ReflectObject.cpp:
        (JSC::reflectObjectEnumerate): Deleted.

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

        Switch VMTraps to use halt instructions rather than breakpoint instructions
        https://bugs.webkit.org/show_bug.cgi?id=173677
        <rdar://problem/32178892>

        Reviewed by JF Bastien.

        Using the breakpoint instruction for VMTraps caused issues with lldb.
        Since we only need some way to stop execution we can, in theory, use
        any exceptioning instruction we want. I went with the halt instruction
        on X86 since that is the only one byte instruction that does not
        breakpoint (in my tests both 0xf1 and 0xd6 produced EXC_BREAKPOINT).
        On ARM we use the data cache clearing instruction with the zero register,
        which triggers a segmentation fault.

        Also, update the platform code to only use signaling VMTraps
        on where we have an appropriate instruction (x86 and ARM64).

        * API/tests/ExecutionTimeLimitTest.cpp:
        (testExecutionTimeLimit):
        * assembler/ARM64Assembler.h:
        (JSC::ARM64Assembler::replaceWithVMHalt):
        (JSC::ARM64Assembler::dataCacheZeroVirtualAddress):
        (JSC::ARM64Assembler::replaceWithBkpt): Deleted.
        * assembler/ARMAssembler.h:
        (JSC::ARMAssembler::replaceWithBkpt): Deleted.
        * assembler/ARMv7Assembler.h:
        (JSC::ARMv7Assembler::replaceWithBkpt): Deleted.
        * assembler/MIPSAssembler.h:
        (JSC::MIPSAssembler::replaceWithBkpt): Deleted.
        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::replaceWithBreakpoint): Deleted.
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::replaceWithVMHalt):
        (JSC::MacroAssemblerARM64::replaceWithBreakpoint): Deleted.
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::storeFence):
        (JSC::MacroAssemblerARMv7::replaceWithBreakpoint): Deleted.
        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::replaceWithBreakpoint): Deleted.
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::replaceWithVMHalt):
        (JSC::MacroAssemblerX86Common::replaceWithBreakpoint): Deleted.
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::replaceWithHlt):
        (JSC::X86Assembler::replaceWithInt3): Deleted.
        * dfg/DFGJumpReplacement.cpp:
        (JSC::DFG::JumpReplacement::installVMTrapBreakpoint):
        * runtime/VMTraps.cpp:
        (JSC::SignalContext::SignalContext):
        (JSC::installSignalHandler):
        (JSC::SignalContext::adjustPCToPointToTrappingInstruction): Deleted.
        * wasm/WasmFaultSignalHandler.cpp:
        (JSC::Wasm::enableFastMemory):

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

        The lowering of Identity in the DFG backend needs to use ManualOperandSpeculation
        https://bugs.webkit.org/show_bug.cgi?id=173743
        <rdar://problem/32932536>

        Reviewed by Mark Lam.

        The code always manually speculates, however, we weren't specifying
        ManualOperandSpeculation when creating a JSValueOperand. This would
        fire an assertion in JSValueOperand construction for a node like:
        Identity(String:@otherNode)
        
        I spent about 45 minutes trying to craft a test and came up
        empty. However, this fixes a debug assertion on an internal
        Apple website.

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

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

        ValueRep(DoubleRep(@v)) can not simply convert to @v
        https://bugs.webkit.org/show_bug.cgi?id=173687
        <rdar://problem/32855563>

        Reviewed by Mark Lam.

        Consider this IR:
         block#x
          p: Phi() // int32 and double flows into this phi from various control flow
          d: DoubleRep(@p)
          some uses of @d here
          v: ValueRep(DoubleRepUse:@d)
          a: NewArrayWithSize(Int32:@v)
          some more nodes here ...
        
        Because the flow of ValueRep(DoubleRep(@p)) will not produce an Int32,
        AI proves that the Int32 check will fail. Constant folding phase removes
        all nodes after @a and inserts an Unreachable after the NewArrayWithSize node.
        
        The IR then looks like this:
        block#x
          p: Phi() // int32 and double flows into this phi from various control flow
          d: DoubleRep(@p)
          some uses of @d here
          v: ValueRep(DoubleRepUse:@d)
          a: NewArrayWithSize(Int32:@v)
          Unreachable
        
        However, there was a strength reduction rule that tries eliminate redundant
        conversions. It used to convert the program to:
        block#x
          p: Phi() // int32 and double flows into this phi from various control flow
          d: DoubleRep(@p)
          some uses of @d here
          a: NewArrayWithSize(Int32:@p)
          Unreachable
        
        However, at runtime, @p will actually be an Int32, so @a will not OSR exit,
        and we'll crash. This patch removes this strength reduction rule since it
        does not maintain what would have happened if we executed the program before
        the rule.
        
        This rule is also wrong for other types of programs (I'm not sure we'd
        actually emit this code, but if such IR were generated, we would previously
        optimize it incorrectly):
        @a: Constant(JSTrue)
        @b: DoubleRep(@a)
        @c: ValueRep(@b)
        @d: use(@c)
        
        However, the strength reduction rule would've transformed this into:
        @a: Constant(JSTrue)
        @d: use(@a)
        
        And this would be wrong because node @c before the transformation would
        have produced the JSValue jsNumber(1.0).
        
        This patch was neutral in the benchmark run I did.

        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):

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

        ARM64: doubled executable memory limit from 32MiB to 64MiB
        https://bugs.webkit.org/show_bug.cgi?id=173734
        <rdar://problem/32932407>

        Reviewed by Oliver Hunt.

        Some WebAssembly programs stress the amount of memory we have
        available, especially when we consider tiering (BBQ never dies,
        and is bigger that OMG). Tiering to OMG just piles on more memory,
        and we're also competing with JavaScript.

        * jit/ExecutableAllocator.h:

2017-06-22  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Pausing with a deep call stack can be very slow, avoid eagerly generating object previews
        https://bugs.webkit.org/show_bug.cgi?id=173698

        Reviewed by Matt Baker.

        When pausing in a deep call stack the majority of the time spent in JavaScriptCore
        when preparing Inspector pause information is spent generating object previews for
        the `thisObject` of each of the call frames. In some cases, this could be more
        than 95% of the time generating pause information. In the common case, only one of
        these (the top frame) will ever be seen by users. This change avoids eagerly
        generating object previews up front and let the frontend request previews if they
        are needed.

        This introduces the `Runtime.getPreview` protocol command. This can be used to:

            - Get a preview for a RemoteObject that did not have a preview but could.
            - Update a preview for a RemoteObject that had a preview.

        This patch only uses it for the first case, but the second is valid and may be
        something we want to do in the future.

        * inspector/protocol/Runtime.json:
        A new command to get an up to date preview for an object.

        * inspector/InjectedScript.h:
        * inspector/InjectedScript.cpp:
        (Inspector::InjectedScript::getPreview):
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::getPreview):
        * inspector/agents/InspectorRuntimeAgent.h:
        Plumbing for the new command.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.prototype.getPreview):
        Implementation just uses the existing helper.

        (InjectedScript.CallFrameProxy):
        Do not generate a preview for the this object as it may not be shown.
        Let the frontend request a preview if it wants or needs one.

2017-06-22  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Remove stale "rawScopes" concept that was never available in JSC
        https://bugs.webkit.org/show_bug.cgi?id=173686

        Reviewed by Mark Lam.

        * inspector/InjectedScript.cpp:
        (Inspector::InjectedScript::functionDetails):
        * inspector/InjectedScriptSource.js:
        (InjectedScript.prototype.functionDetails):
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::functionDetails):

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

        [JSC] Object.values should be implemented in C++
        https://bugs.webkit.org/show_bug.cgi?id=173703

        Reviewed by Sam Weinig.

        As the same to Object.assign, Object.values() is also inherently polymorphic.
        And allocating JSString / Symbol for Identifier and JSArray for Object.keys()
        result is costly.

        In this patch, we implement Object.values() in C++. It can avoid above allocations.
        Furthermore, by using `slot.isTaintedByOpaqueObject()` information, we can skip
        non-observable JSObject::get() calls.

        This improves performance by 2.49x. And also now Object.values() beats
        Object.keys(object).map(key => object[key]) implementation.

                                             baseline                  patched

            object-values               132.1551+-3.7209     ^     53.1254+-1.6139        ^ definitely 2.4876x faster
            object-keys-map-values       78.2008+-2.1378     ?     78.9078+-2.2121        ?

        * builtins/ObjectConstructor.js:
        (values): Deleted.
        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorValues):

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

        ArrayPrototype.map builtin declares a var it does not use
        https://bugs.webkit.org/show_bug.cgi?id=173685

        Reviewed by Keith Miller.

        * builtins/ArrayPrototype.js:
        (map):

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

        eval virtual call is incorrect in the baseline JIT
        https://bugs.webkit.org/show_bug.cgi?id=173587
        <rdar://problem/32867897>

        Reviewed by Michael Saboff.

        When making a virtual call for call_eval, e.g, when the thing
        we're calling isn't actually eval, we end up calling the caller
        instead of the callee. This is clearly wrong. The code ends up
        issuing a load for the Callee in the callers frame instead of
        the callee we're calling. The fix is simple, we just need to
        load the real callee. Only the 32-bit baseline JIT had this bug.

        * jit/JITCall32_64.cpp:
        (JSC::JIT::compileCallEvalSlowCase):

2017-06-21  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Using "break on all exceptions" when throwing stack overflow hangs inspector
        https://bugs.webkit.org/show_bug.cgi?id=172432
        <rdar://problem/29870873>

        Reviewed by Saam Barati.

        Avoid pausing on StackOverflow and OutOfMemory errors to avoid a hang.
        We will proceed to improve debugging of these cases in the follow-up bugs.

        * debugger/Debugger.cpp:
        (JSC::Debugger::exception):
        Ignore pausing on these errors.

        * runtime/ErrorInstance.h:
        (JSC::ErrorInstance::setStackOverflowError):
        (JSC::ErrorInstance::isStackOverflowError):
        (JSC::ErrorInstance::setOutOfMemoryError):
        (JSC::ErrorInstance::isOutOfMemoryError):
        * runtime/ExceptionHelpers.cpp:
        (JSC::createStackOverflowError):
        * runtime/Error.cpp:
        (JSC::createOutOfMemoryError):
        Mark these kinds of errors.

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

        Make it clear that regenerating ICs are holding the CodeBlock's lock by passing the locker as a parameter
        https://bugs.webkit.org/show_bug.cgi?id=173609

        Reviewed by Keith Miller.

        This patch makes many of the IC generating functions require a locker as
        a parameter. We do this in other places in JSC to indicate that
        a particular API is only valid while a particular lock is held.
        This is the case when generating ICs. This patch just makes it
        explicit in the IC generating interface.

        * bytecode/PolymorphicAccess.cpp:
        (JSC::PolymorphicAccess::addCases):
        (JSC::PolymorphicAccess::addCase):
        (JSC::PolymorphicAccess::commit):
        (JSC::PolymorphicAccess::regenerate):
        * bytecode/PolymorphicAccess.h:
        * bytecode/StructureStubInfo.cpp:
        (JSC::StructureStubInfo::addAccessCase):
        (JSC::StructureStubInfo::initStub): Deleted.
        * bytecode/StructureStubInfo.h:
        * jit/Repatch.cpp:
        (JSC::tryCacheGetByID):
        (JSC::repatchGetByID):
        (JSC::tryCachePutByID):
        (JSC::repatchPutByID):
        (JSC::tryRepatchIn):
        (JSC::repatchIn):

2017-06-20  Myles C. Maxfield  <mmaxfield@apple.com>

        Disable font variations on macOS Sierra and iOS 10
        https://bugs.webkit.org/show_bug.cgi?id=173618
        <rdar://problem/32879164>

        Reviewed by Jon Lee.

        * Configurations/FeatureDefines.xcconfig:

2017-06-20  Keith Miller  <keith_miller@apple.com>

        Fix leak of ModuleInformations in BBQPlan constructors.
        https://bugs.webkit.org/show_bug.cgi?id=173577

        Reviewed by Saam Barati.

        This patch fixes a leak in the BBQPlan constructiors. Previously,
        the plans were calling makeRef on the newly constructed objects.
        This patch fixes the issue and uses adoptRef instead. Additionally,
        an old, incorrect, attempt to fix the leak is removed.

        * inspector/remote/cocoa/RemoteInspectorXPCConnection.mm:
        (Inspector::RemoteInspectorXPCConnection::RemoteInspectorXPCConnection):
        * jit/JITWorklist.cpp:
        (JSC::JITWorklist::Thread::Thread):
        * runtime/PromiseDeferredTimer.cpp:
        (JSC::PromiseDeferredTimer::addPendingPromise):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * wasm/WasmBBQPlan.cpp:
        (JSC::Wasm::BBQPlan::BBQPlan):
        * wasm/WasmPlan.cpp:
        (JSC::Wasm::Plan::Plan):

2017-06-20  Devin Rousso  <drousso@apple.com>

        Web Inspector: Send context attributes for tracked canvases
        https://bugs.webkit.org/show_bug.cgi?id=173327

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/Canvas.json:
        Add ContextAttributes object type that is optionally used for WebGL canvases.

2017-06-20  Konstantin Tokarev  <annulen@yandex.ru>

        Remove excessive include directives from WTF
        https://bugs.webkit.org/show_bug.cgi?id=173553

        Reviewed by Saam Barati.

        * profiler/ProfilerDatabase.cpp: Added missing include directive.
        * runtime/SamplingProfiler.cpp: Ditto.

2017-06-20  Oleksandr Skachkov  <gskachkov@gmail.com>

        Revert changes in bug#160417 about extending `null` not being a derived class
        https://bugs.webkit.org/show_bug.cgi?id=169293

        Reviewed by Saam Barati.

        Reverted changes in bug#160417 about extending `null` not being a derived class 
        according to changes in spec:
        https://github.com/tc39/ecma262/commit/c57ef95c45a371f9c9485bb1c3881dbdc04524a2

        * builtins/BuiltinNames.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitReturn):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ClassExprNode::emitBytecode):

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

        repatchIn needs to lock the CodeBlock's lock
        https://bugs.webkit.org/show_bug.cgi?id=173573

        Reviewed by Yusuke Suzuki.

        CodeBlock::propagateTransitions and CodeBlock::visitWeakly grab the CodeBlock's
        lock before modifying the StructureStubInfo/PolymorphicAccess. When regenerating
        an IC, we must hold the CodeBlock's to prevent the executing thread from racing
        with the marking thread. repatchIn was not grabbing the lock. I haven't been
        able to get it to crash, but this is needed for the same reasons that get and put IC
        regeneration grab the lock.

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

2017-06-19  Devin Rousso  <drousso@apple.com>

        Web Inspector: create canvas content view and details sidebar panel
        https://bugs.webkit.org/show_bug.cgi?id=138941
        <rdar://problem/19051672>

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/Canvas.json:
         - Add an optional `nodeId` attribute to the `Canvas` type.
         - Add `requestNode` command for getting the node id of the backing canvas element.
         - Add `requestContent` command for getting the current image content of the canvas.

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

        Unreviewed, build fix for ARM

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

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

        [DFG] More ArrayIndexOf fixups for various types
        https://bugs.webkit.org/show_bug.cgi?id=173176

        Reviewed by Saam Barati.

        This patch further expands coverage of ArrayIndexOf optimization in DFG and FTL.

        1. We attempt to fold ArrayIndexOf to constant (-1) if we know that its array
        never contains the given search value.

        2. We support Symbol and Other specialization additionally. Especially, Other is
        useful because null/undefined can be used as a sentinel value.

        One interesting thing is that Array.prototype.indexOf does not consider holes as
        undefineds. Thus,

            var array = [,,,,,,,];
            array.indexOf(undefined); // => -1

        This can be trivially achieved in JSC because Empty and Undefined are different values.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::fixupArrayIndexOf):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArrayIndexOf):
        (JSC::DFG::SpeculativeJIT::speculateOther):
        * dfg/DFGSpeculativeJIT.h:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileArrayIndexOf):

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

        [ARMv6][DFG] ARM MacroAssembler is always emitting cmn when immediate is 0
        https://bugs.webkit.org/show_bug.cgi?id=172972

        Reviewed by Mark Lam.

        We are changing internalCompare32 implementation in ARM
        MacroAssembler to emit "cmp" when the "right.value" is 0.
        It is generating wrong comparison cases, since the
        semantics of cmn is opposite of cmp[1]. One case that it's breaking is
        "branch32(MacroAssembler::Above, gpr, TrustedImm32(0))", where ends
        resulting in following assembly code:

        ```
        cmn $r0, #0
        bhi <address>
        ```

        However, as cmn is similar to "adds", it will never take the branch
        when $r0 > 0. In that case, the correct opcode is "cmp". With this
        patch we will fix current broken tests that uses
        "branch32(MacroAssembler::Above, gpr, TrustedImm32(0))",
        such as ForwardVarargs, Spread and GetRestLength.

        [1] - http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204j/Cihiddid.html

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

2017-06-19  Joseph Pecoraro  <pecoraro@apple.com>

        test262: Completion values for control flow do not match the spec
        https://bugs.webkit.org/show_bug.cgi?id=171265

        Reviewed by Saam Barati.

        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::shouldBeConcernedWithCompletionValue):
        When we care about having proper completion values (global code
        in programs, modules, and eval) insert undefined results for
        control flow statements.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::SourceElements::emitBytecode):
        Reduce writing a default `undefined` value to the completion result to
        only once before the last statement we know will produce a value.

        (JSC::IfElseNode::emitBytecode):
        (JSC::WithNode::emitBytecode):
        (JSC::WhileNode::emitBytecode):
        (JSC::ForNode::emitBytecode):
        (JSC::ForInNode::emitBytecode):
        (JSC::ForOfNode::emitBytecode):
        (JSC::SwitchNode::emitBytecode):
        Insert an undefined to handle cases where code may break out of an
        if/else or with statement (break/continue).

        (JSC::TryNode::emitBytecode):
        Same handling for break cases. Also, finally block statement completion
        values are always ignored for the try statement result.

        (JSC::ClassDeclNode::emitBytecode):
        Class declarations, like function declarations, produce an empty result.

        * parser/Nodes.cpp:
        (JSC::SourceElements::lastStatement):
        (JSC::SourceElements::hasCompletionValue):
        (JSC::SourceElements::hasEarlyBreakOrContinue):
        (JSC::BlockNode::lastStatement):
        (JSC::BlockNode::singleStatement):
        (JSC::BlockNode::hasCompletionValue):
        (JSC::BlockNode::hasEarlyBreakOrContinue):
        (JSC::ScopeNode::singleStatement):
        (JSC::ScopeNode::hasCompletionValue):
        (JSC::ScopeNode::hasEarlyBreakOrContinue):
        The only non-trivial cases need to loop through their list of statements
        to determine if this has a completion value or not. Likewise for
        determining if there is an early break / continue, meaning a break or
        continue statement with no preceding statement that has a completion value.

        * parser/Nodes.h:
        (JSC::StatementNode::next):
        (JSC::StatementNode::hasCompletionValue):
        Helper to check if a statement nodes produces a completion value or not.

2017-06-19  Adrian Perez de Castro  <aperez@igalia.com>

        Missing <functional> includes make builds fail with GCC 7.x
        https://bugs.webkit.org/show_bug.cgi?id=173544

        Unreviewed gardening.

        Fix compilation with GCC 7.

        * API/tests/CompareAndSwapTest.cpp:
        * runtime/VMEntryScope.h:

2017-06-17  Keith Miller  <keith_miller@apple.com>

        ArrayBuffer constructor needs to create subclass structures before its buffer
        https://bugs.webkit.org/show_bug.cgi?id=173510

        Reviewed by Yusuke Suzuki.

        * runtime/JSArrayBufferConstructor.cpp:
        (JSC::constructArrayBuffer):

2017-06-17  Keith Miller  <keith_miller@apple.com>

        ArrayPrototype methods should use JSValue::toLength for non-Arrays.
        https://bugs.webkit.org/show_bug.cgi?id=173506

        Reviewed by Ryosuke Niwa.

        This patch changes the result of unshift if old length +
        unshift.arguments.length > (2 ** 53) - 1 to be a type error. Also,
        the getLength function, which was always incorrect to use, has
        been removed. Additionally, some cases where we were using a
        constant for (2 ** 53) - 1 have been replaced with
        maxSafeInteger()

        * interpreter/Interpreter.cpp:
        (JSC::sizeOfVarargs):
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncToLocaleString):
        (JSC::arrayProtoFuncPop):
        (JSC::arrayProtoFuncPush):
        (JSC::arrayProtoFuncReverse):
        (JSC::arrayProtoFuncShift):
        (JSC::arrayProtoFuncSlice):
        (JSC::arrayProtoFuncSplice):
        (JSC::arrayProtoFuncUnShift):
        (JSC::arrayProtoFuncIndexOf):
        (JSC::arrayProtoFuncLastIndexOf):
        * runtime/JSArrayInlines.h:
        (JSC::getLength): Deleted.
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::toLength):
        * runtime/NumberConstructor.cpp:
        (JSC::numberConstructorFuncIsSafeInteger):

2017-06-16  Matt Baker  <mattbaker@apple.com>

        Web Inspector: Instrument 2D/WebGL canvas contexts in the backend
        https://bugs.webkit.org/show_bug.cgi?id=172623
        <rdar://problem/32415986>

        Reviewed by Devin Rousso and Joseph Pecoraro.

        This patch adds a basic Canvas protocol. It includes Canvas and related
        types and events for monitoring the lifetime of canvases in the page.

        * CMakeLists.txt:
        * DerivedSources.make:
        * inspector/protocol/Canvas.json: Added.

        * inspector/scripts/codegen/generator.py:
        (Generator.stylized_name_for_enum_value):
        Add special handling for Canvas.ContextType protocol enumeration,
        so that "canvas-2d" and "webgl" map to `Canvas2D` and `WebGL`.

2017-06-16  Wenson Hsieh  <wenson_hsieh@apple.com>

        [iOS DnD] Upstream iOS drag and drop implementation into OpenSource WebKit
        https://bugs.webkit.org/show_bug.cgi?id=173366
        <rdar://problem/32767014>

        Reviewed by Tim Horton.

        Introduce ENABLE_DATA_INTERACTION and ENABLE_DRAG_SUPPORT to FeatureDefines.xcconfig.

        * Configurations/FeatureDefines.xcconfig:

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

        [JSC] Add fast path for Object.assign
        https://bugs.webkit.org/show_bug.cgi?id=173416

        Reviewed by Mark Lam.

        In Object.assign implementation, we need to ensure that given key is still enumerable own key.
        This seems duplicate look up. And we want to avoid this. However, we still need to perform this
        check in the face of Proxy. Proxy can observe that this check is done correctly.

        In almost all the cases, the above check is duplicate to the subsequent [[Get]] operation.
        In this patch, we perform this check. But at that time, we investigate `isTaintedByOpaqueObject()`.
        If it is false, we can say that getOwnPropertySlot is pure. In that case, we can just retrieve the
        value by calling `slot.getValue()`.

        This further improves performance of Object.assign.

                                        baseline                  patched

            object-assign.es6      363.6706+-6.4381     ^    324.1769+-6.9624        ^ definitely 1.1218x faster

        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorAssign):

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

        Intermittent crash running Internal/Tests/InternalJSTests/Regress/radar-24300617.js
        https://bugs.webkit.org/show_bug.cgi?id=173488

        Reviewed by Filip Pizlo.

        ClonedArguments lazily sets its callee and interator properties and it used its own inline
        code to initialize its butterfly.  This means that these lazily set properties can have
        bogus values in those slots.  Instead, let's use the standard BUtterfly:tryCreate() method
        to create the butterfly as it clears out of line properties.

        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::createEmpty):

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

        Interpreter methods for mapping between Opcode and OpcodeID need not be instance methods.
        https://bugs.webkit.org/show_bug.cgi?id=173491

        Reviewed by Keith Miller.

        The implementation are based on static data. There's no need to get the
        interpreter instance. Hence, we can make these methods static and avoid doing
        unnecessary work to compute the interpreter this pointer.

        Also removed the unused isCallBytecode method.

        * bytecode/BytecodeBasicBlock.cpp:
        (JSC::BytecodeBasicBlock::computeImpl):
        * bytecode/BytecodeDumper.cpp:
        (JSC::BytecodeDumper<Block>::printGetByIdOp):
        (JSC::BytecodeDumper<Block>::printGetByIdCacheStatus):
        (JSC::BytecodeDumper<Block>::dumpBytecode):
        (JSC::BytecodeDumper<Block>::dumpBlock):
        * bytecode/BytecodeLivenessAnalysis.cpp:
        (JSC::BytecodeLivenessAnalysis::dumpResults):
        * bytecode/BytecodeLivenessAnalysisInlines.h:
        (JSC::BytecodeLivenessPropagation<DerivedAnalysis>::stepOverInstruction):
        * bytecode/BytecodeRewriter.cpp:
        (JSC::BytecodeRewriter::adjustJumpTargetsInFragment):
        * bytecode/CallLinkStatus.cpp:
        (JSC::CallLinkStatus::computeFromLLInt):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::propagateTransitions):
        (JSC::CodeBlock::finalizeLLIntInlineCaches):
        (JSC::CodeBlock::hasOpDebugForLineAndColumn):
        (JSC::CodeBlock::usesOpcode):
        (JSC::CodeBlock::valueProfileForBytecodeOffset):
        (JSC::CodeBlock::arithProfileForPC):
        (JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
        * bytecode/PreciseJumpTargets.cpp:
        (JSC::getJumpTargetsForBytecodeOffset):
        (JSC::computePreciseJumpTargetsInternal):
        (JSC::findJumpTargetsForBytecodeOffset):
        * bytecode/PreciseJumpTargetsInlines.h:
        (JSC::extractStoredJumpTargetsForBytecodeOffset):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::applyModification):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::Interpreter):
        (JSC::Interpreter::isOpcode):
        (): Deleted.
        * interpreter/Interpreter.h:
        (JSC::Interpreter::getOpcode): Deleted.
        (JSC::Interpreter::getOpcodeID): Deleted.
        (JSC::Interpreter::isCallBytecode): Deleted.
        * interpreter/InterpreterInlines.h:
        (JSC::Interpreter::getOpcode):
        (JSC::Interpreter::getOpcodeID):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emitNewFuncCommon):
        (JSC::JIT::emitNewFuncExprCommon):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitSlow_op_put_by_val):
        (JSC::JIT::privateCompilePutByVal):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emitSlow_op_put_by_val):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::llint_trace_operand):
        (JSC::LLInt::llint_trace_value):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * profiler/ProfilerBytecodeSequence.cpp:
        (JSC::Profiler::BytecodeSequence::BytecodeSequence):

2017-06-16  Matt Lewis  <jlewis3@apple.com>

        Unreviewed, rolling out r218376.

        The patch cause multiple Layout Test Crashes.

        Reverted changeset:

        "Web Inspector: Instrument 2D/WebGL canvas contexts in the
        backend"
        https://bugs.webkit.org/show_bug.cgi?id=172623
        http://trac.webkit.org/changeset/218376

2017-06-16  Konstantin Tokarev  <annulen@yandex.ru>

        REGRESSION(r166799): LogsPageMessagesToSystemConsoleEnabled corrupts non-ASCII characters
        https://bugs.webkit.org/show_bug.cgi?id=173470

        Reviewed by Joseph Pecoraro.

        ConsoleClient::printConsoleMessageWithArguments() incorrectly uses
        const char* overload of StringBuilder::append() that assummes Latin1
        encoding, not UTF8.

        * runtime/ConsoleClient.cpp:
        (JSC::ConsoleClient::printConsoleMessageWithArguments):

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

        Add a JSRunLoopTimer registry in VM.
        https://bugs.webkit.org/show_bug.cgi?id=173429
        <rdar://problem/31287961>

        Reviewed by Filip Pizlo.

        This way, we can be sure we've got every JSRunLoopTimer instance covered if we
        need to change their run loop (e.g. when setting to the WebThread's run loop).

        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::setRunLoop): Deleted.
        * heap/Heap.h:
        (JSC::Heap::runLoop): Deleted.
        * runtime/JSRunLoopTimer.cpp:
        (JSC::JSRunLoopTimer::JSRunLoopTimer):
        (JSC::JSRunLoopTimer::setRunLoop):
        (JSC::JSRunLoopTimer::~JSRunLoopTimer):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::registerRunLoopTimer):
        (JSC::VM::unregisterRunLoopTimer):
        (JSC::VM::setRunLoop):
        * runtime/VM.h:
        (JSC::VM::runLoop):

2017-06-15  Joseph Pecoraro  <pecoraro@apple.com>

        [Cocoa] Modernize some internal initializers to use instancetype instead of id
        https://bugs.webkit.org/show_bug.cgi?id=173112

        Reviewed by Wenson Hsieh.

        * API/JSContextInternal.h:
        * API/JSWrapperMap.h:
        * API/JSWrapperMap.mm:
        (-[JSObjCClassInfo initForClass:]):
        (-[JSWrapperMap initWithGlobalContextRef:]):

2017-06-15  Matt Baker  <mattbaker@apple.com>

        Web Inspector: Instrument 2D/WebGL canvas contexts in the backend
        https://bugs.webkit.org/show_bug.cgi?id=172623
        <rdar://problem/32415986>

        Reviewed by Devin Rousso.

        This patch adds a basic Canvas protocol. It includes Canvas and related
        types and events for monitoring the lifetime of canvases in the page.

        * CMakeLists.txt:
        * DerivedSources.make:
        * inspector/protocol/Canvas.json: Added.

        * inspector/scripts/codegen/generator.py:
        (Generator.stylized_name_for_enum_value):
        Add special handling for Canvas.ContextType protocol enumeration,
        so that "canvas-2d" and "webgl" map to `Canvas2D` and `WebGL`.

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

        Add logging to MachineStackMarker to try to diagnose crashes in the wild
        https://bugs.webkit.org/show_bug.cgi?id=173427

        Reviewed by Mark Lam.

        This patch adds some logging to the MachineStackMarker constructor
        to help figure out where we are seeing crashes. Since macOS does
        not support os_log_info my hope is that if we set all the callee
        save registers before making any calls in the C++ code we can
        figure out which calls is the source of the crash. We also, set
        all the caller save registers before returning in case some
        weirdness is happening in the Heap constructor.

        This logging should not matter from a performance perspective. We
        only create MachineStackMarkers when we are creating a new VM,
        which is already expensive.

        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::MachineThreads):

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

        [JSC] Implement Object.assign in C++
        https://bugs.webkit.org/show_bug.cgi?id=173414

        Reviewed by Saam Barati.

        Implementing Object.assign in JS is not so good compared to C++ version because,

        1. JS version allocates JS array for object own keys. And we allocate JSString / Symbol for each key.
        But basically, they can be handled as UniquedStringImpl in C++. Allocating these cells are wasteful.

        2. While implementing builtins in JS offers some good type speculation chances, Object.assign is inherently super polymorphic.
        So JS's type profile doesn't help well.

        3. We have a chance to introduce various fast path for Object.assign in C++.

        This patch moves implementation from JS to C++. It achieves the above (1) and (2). (3) is filed in [1].

        We can see 1.65x improvement in SixSpeed object-assign.es6.

                                    baseline                  patched

        object-assign.es6      643.3253+-8.0521     ^    389.1075+-8.8840        ^ definitely 1.6533x faster

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

        * builtins/ObjectConstructor.js:
        (entries):
        (assign): Deleted.
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::putInline):
        * runtime/JSCell.h:
        * runtime/JSCellInlines.h:
        (JSC::JSCell::putInline):
        * runtime/JSObject.cpp:
        (JSC::JSObject::put):
        * runtime/JSObject.h:
        * runtime/JSObjectInlines.h:
        (JSC::JSObject::putInlineForJSObject):
        (JSC::JSObject::putInline): Deleted.
        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorAssign):

2017-06-14  Dan Bernstein  <mitz@apple.com>

        [Cocoa] Objective-C class whose name begins with an underscore can’t be exported to JavaScript
        https://bugs.webkit.org/show_bug.cgi?id=168578

        Reviewed by Geoff Garen.

        * API/JSWrapperMap.mm:
        (allocateConstructorForCustomClass): Updated for change to forEachProtocolImplementingProtocol.
        (-[JSObjCClassInfo allocateConstructorAndPrototype]): Ditto.
        (-[JSWrapperMap classInfoForClass:]): If the class name begins with an underscore, check if
          it defines conformance to a JSExport-derived protocol and if so, avoid using the
          superclass as a substitute as we’d normally do.

        * API/ObjcRuntimeExtras.h:
        (forEachProtocolImplementingProtocol): Added a "stop" argument to the block to let callers
          bail out.

        * API/tests/JSExportTests.mm:
        (+[JSExportTests classNamePrefixedWithUnderscoreTest]): New test for this.
        (runJSExportTests): Run new test.

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

        Unreviewed, suppress invalid register alloation validation assertion in 32 bit part 2
        https://bugs.webkit.org/show_bug.cgi?id=172421

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

2017-06-14  Claudio Saavedra  <csaavedra@igalia.com>

        REGRESSION: 15 new jsc failures in WPE and GTK+
        https://bugs.webkit.org/show_bug.cgi?id=173349

        Reviewed by JF Bastien.

        Recent changes to generateWasm.py are not accounted for from
        CMake, which leads to WasmOps.h not being regenerated in partial
        builds. Make generateWasm.py an additional dependency.
        * CMakeLists.txt:

2017-06-13  Joseph Pecoraro  <pecoraro@apple.com>

        Debugger has unexpected effect on program correctness
        https://bugs.webkit.org/show_bug.cgi?id=172683

        Reviewed by Saam Barati.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.RemoteObject.prototype._appendPropertyPreviews):
        (InjectedScript.RemoteObject.prototype._isPreviewableObjectInternal):
        (BasicCommandLineAPI):
        Eliminate for..of use with Arrays from InjectedScriptSource as it can be observable.
        We still use it for Set / Map iteration which we can eliminate when moving to builtins.

2017-06-13  JF Bastien  <jfbastien@apple.com>

        WebAssembly: fix erroneous signature comment
        https://bugs.webkit.org/show_bug.cgi?id=173334

        Reviewed by Keith Miller.

        * wasm/WasmSignature.h:

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

        Refactor AbsenceOfSetter to AbsenceOfSetEffects
        https://bugs.webkit.org/show_bug.cgi?id=173322

        Reviewed by Filip Pizlo.

        * bytecode/ObjectPropertyCondition.h:
        (JSC::ObjectPropertyCondition::absenceOfSetEffectWithoutBarrier):
        (JSC::ObjectPropertyCondition::absenceOfSetEffect):
        (JSC::ObjectPropertyCondition::absenceOfSetterWithoutBarrier): Deleted.
        (JSC::ObjectPropertyCondition::absenceOfSetter): Deleted.
        * bytecode/ObjectPropertyConditionSet.cpp:
        (JSC::generateConditionsForPropertySetterMiss):
        (JSC::generateConditionsForPropertySetterMissConcurrently):
        * bytecode/PropertyCondition.cpp:
        (JSC::PropertyCondition::dumpInContext):
        (JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint):
        (JSC::PropertyCondition::isStillValid):
        (WTF::printInternal):
        * bytecode/PropertyCondition.h:
        (JSC::PropertyCondition::absenceOfSetEffectWithoutBarrier):
        (JSC::PropertyCondition::absenceOfSetEffect):
        (JSC::PropertyCondition::hasPrototype):
        (JSC::PropertyCondition::hash):
        (JSC::PropertyCondition::operator==):
        (JSC::PropertyCondition::absenceOfSetterWithoutBarrier): Deleted.
        (JSC::PropertyCondition::absenceOfSetter): Deleted.

2017-06-13  JF Bastien  <jfbastien@apple.com>

        WebAssembly: import updated spec tests
        https://bugs.webkit.org/show_bug.cgi?id=173287
        <rdar://problem/32725975>

        Reviewed by Saam Barati.

        Import spec tests as of 31c641cc15f2aedbec2fa45a5185f68416df578b,
        with a few modifications so things work.

        Fix a bunch of bugs found through this process, and punt a few tests (which I
        marked as blocked by this bug).

        Fixes:

        Fix load / store alignment: r216908 erroneously implemented it as bit alignment
        instead of byte alignment. It was also missing memory-alignment.js despite it
        being in the ChangeLog, so add it too. This allows spec-test/align.wast.js to
        pass.

        Tables can be imported or in a section. There can be only one, but sections can
        be empty. An Elements section can exist if there's no Table, as long as it is
        also empty.

        Memories can be imported or in a section. There can be only one, but sections
        can be empty. A Data section can exist if there's no Memory, as long as it is
        also empty.

        Prototypes: stringify without .prototype. in the string.

        WebAssembly.Table.prototype.grow was plain wrong: it takes a delta parameter,
        not a final size, and throws a RangeError on failure, not a TypeError.

        Fix compile / instantiate so the reject the promise if given an argument of the
        wrong type (instead of failing instantly).

        Fix async on neuter test.

        Element section shouldn't affect any Table if any of the elements are out of
        bounds. We need to process it in two passes.

        Segment section shouldn't affect any Data if any of the segments are out of
        bounds. We need to process it in two passes.

        Empty data segments are valid, but only when there is no memory. Their index
        still gets validated, and has to be zero.

        Punts:

        Error messages with context, the test seems overly restrictive but this is
        minor.

        compile/instantiate/validate property descriptors.

        UTF-8 bugs.

        Temporarily disable NaN tests. We need to go back and implement the following
        semantics: https://github.com/WebAssembly/spec/pull/414 This doesn't matter as
        much as getting all the other tests passing.

        Worth noting for NaNs: f64.no_fold_mul_one (also a NaN test) as well as
        no_fold_promote_demote (an interesting corner case which we get wrong). mul by
        one is (assert_return (invoke \"f64.no_fold_mul_one\" (i64.const
        0x7ff4000000000000)) (i64.const 0x7ff8000000000000)) which means converting sNaN
        to qNaN, and promote/demote is (assert_return (invoke \"no_fold_promote_demote\"
        (i32.const 0x7fa00000)) (i32.const 0x7fc00000)) which is the same. I'm not sure
        why they're not allowed.

        * wasm/WasmB3IRGenerator.cpp:
        * wasm/WasmFunctionParser.h:
        * wasm/WasmModuleParser.cpp:
        * wasm/WasmModuleParser.h:
        * wasm/WasmParser.h:
        (JSC::Wasm::Parser<SuccessType>::consumeUTF8String):
        * wasm/generateWasm.py:
        (memoryLog2Alignment):
        * wasm/js/JSWebAssemblyTable.cpp:
        (JSC::JSWebAssemblyTable::grow):
        * wasm/js/JSWebAssemblyTable.h:
        * wasm/js/WebAssemblyCompileErrorPrototype.cpp:
        * wasm/js/WebAssemblyInstancePrototype.cpp:
        * wasm/js/WebAssemblyLinkErrorPrototype.cpp:
        * wasm/js/WebAssemblyMemoryPrototype.cpp:
        * wasm/js/WebAssemblyModulePrototype.cpp:
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::evaluate):
        * wasm/js/WebAssemblyPrototype.cpp:
        (JSC::webAssemblyCompileFunc):
        (JSC::resolve):
        (JSC::instantiate):
        (JSC::compileAndInstantiate):
        (JSC::webAssemblyInstantiateFunc):
        * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
        * wasm/js/WebAssemblyTablePrototype.cpp:
        (JSC::webAssemblyTableProtoFuncGrow):

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

        DFG doesn't properly handle a property that is change to read only in a prototype
        https://bugs.webkit.org/show_bug.cgi?id=173321

        Reviewed by Filip Pizlo.

        We need to check for ReadOnly as well as a not being a Setter when checking
        an AbsenceOfSetter.

        * bytecode/PropertyCondition.cpp:
        (JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint):

2017-06-13  Daniel Bates  <dabates@apple.com>

        Implement W3C Secure Contexts Draft Specification
        https://bugs.webkit.org/show_bug.cgi?id=158121
        <rdar://problem/26012994>

        Reviewed by Brent Fulgham.

        Part 4

        Adds isSecureContext to the list of common identifiers as needed to support
        toggling its exposure from a runtime enabled feature flag.

        * runtime/CommonIdentifiers.h:

2017-06-13  Don Olmstead  <don.olmstead@sony.com>

        [JSC] Remove redundant includes in config.h
        https://bugs.webkit.org/show_bug.cgi?id=173294

        Reviewed by Alex Christensen.

        * config.h:

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

        We should not claim that SpecEmpty is filtered out of cell checks on 64 bit platforms
        https://bugs.webkit.org/show_bug.cgi?id=172957
        <rdar://problem/32602704>

        Reviewed by Filip Pizlo.

        Consider this program:
        ```
        block#1:
        n: GetClosureVar(..., |this|) // this will load empty JSValue()
        SetLocal(Cell:@n, locFoo) // Cell check succeeds because JSValue() looks like a cell
        Branch(#2, #3)
        
        Block#3:
        x: GetLocal(locFoo)
        y: CheckNotEmpty(@x)
        ```
        
        If we claim that a cell check filters out the empty value, we will
        incorrectly eliminate the CheckNotEmpty node @y. This patch fixes AI,
        FTLLowerDFGToB3, and DFGSpeculativeJIT to no longer make this claim.
        
        On 64 bit platforms:
        - Cell use kind *now allows* the empty value to pass through.
        - CellOrOther use kind *now allows* for the empty value to pass through
        - NotCell use kind *no longer allows* the empty value to pass through.

        * assembler/CPU.h:
        (JSC::isARMv7IDIVSupported):
        (JSC::isARM64):
        (JSC::isX86):
        (JSC::isX86_64):
        (JSC::is64Bit):
        (JSC::is32Bit):
        (JSC::isMIPS):
        Make these functions constexpr so we can use them in static variable assignment.

        * bytecode/SpeculatedType.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileValueToInt32):
        (JSC::DFG::SpeculativeJIT::compileDoubleRep):
        (JSC::DFG::SpeculativeJIT::compileLogicalNotStringOrOther):
        (JSC::DFG::SpeculativeJIT::emitStringOrOtherBranch):
        (JSC::DFG::SpeculativeJIT::speculateCell):
        (JSC::DFG::SpeculativeJIT::speculateCellOrOther):
        (JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
        (JSC::DFG::SpeculativeJIT::speculateString):
        (JSC::DFG::SpeculativeJIT::speculateStringOrOther):
        (JSC::DFG::SpeculativeJIT::speculateSymbol):
        (JSC::DFG::SpeculativeJIT::speculateNotCell):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
        (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
        (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
        * dfg/DFGUseKind.h:
        (JSC::DFG::typeFilterFor):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileDoubleRep):
        (JSC::FTL::DFG::LowerDFGToB3::numberOrNotCellToInt32):
        (JSC::FTL::DFG::LowerDFGToB3::compareEqObjectOrOtherToObject):
        (JSC::FTL::DFG::LowerDFGToB3::boolify):
        (JSC::FTL::DFG::LowerDFGToB3::equalNullOrUndefined):
        (JSC::FTL::DFG::LowerDFGToB3::lowCell):
        (JSC::FTL::DFG::LowerDFGToB3::lowNotCell):
        (JSC::FTL::DFG::LowerDFGToB3::isCellOrMisc):
        (JSC::FTL::DFG::LowerDFGToB3::isNotCellOrMisc):
        (JSC::FTL::DFG::LowerDFGToB3::isNotCell):
        (JSC::FTL::DFG::LowerDFGToB3::isCell):
        (JSC::FTL::DFG::LowerDFGToB3::speculateCellOrOther):
        (JSC::FTL::DFG::LowerDFGToB3::speculateObjectOrOther):
        (JSC::FTL::DFG::LowerDFGToB3::speculateString):
        (JSC::FTL::DFG::LowerDFGToB3::speculateStringOrOther):
        (JSC::FTL::DFG::LowerDFGToB3::speculateSymbol):

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

        Unreviewed, suppress invalid register alloation validation assertion in 32 bit
        https://bugs.webkit.org/show_bug.cgi?id=172421

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

2017-06-12  Oleksandr Skachkov  <gskachkov@gmail.com>

        We incorrectly allow escaped characters in keyword tokens
        https://bugs.webkit.org/show_bug.cgi?id=171310

        Reviewed by Yusuke Suzuki.

        According spec it is not allow to use escaped characters in 
        keywords. https://tc39.github.io/ecma262/#sec-reserved-words
        Current patch implements this requirements.


        * parser/Lexer.cpp:
        (JSC::Lexer<CharacterType>::parseIdentifierSlowCase):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::printUnexpectedTokenText):
        * parser/ParserTokens.h:

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

        Unreviewed, add branch64(Cond, BaseIndex, RegisterID) for ARM64
        https://bugs.webkit.org/show_bug.cgi?id=172421

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::branch64):
        (JSC::MacroAssemblerARM64::branchPtr):

2017-06-12  Commit Queue  <commit-queue@webkit.org>

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

        Break builds (Requested by yusukesuzuki on #webkit).

        Reverted changeset:

        "Unreviewed, build fix for ARM64"
        https://bugs.webkit.org/show_bug.cgi?id=172421
        http://trac.webkit.org/changeset/218093

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

        Unreviewed, build fix for ARM64
        https://bugs.webkit.org/show_bug.cgi?id=172421

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

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

        [DFG] Add ArrayIndexOf intrinsic
        https://bugs.webkit.org/show_bug.cgi?id=172421

        Reviewed by Saam Barati.

        This patch introduces ArrayIndexOfInstrinsic for DFG and FTL optimizations.
        We emit array check and go fast path if the array is Array::Int32, Array::Double
        or Array::Continugous. In addition, for Array::Int32 and Array::Double case,
        we have inlined fast paths.

        With updated ARES-6 Babylon,

        Before
            firstIteration:     45.76 +- 3.87 ms
            averageWorstCase:   24.41 +- 2.17 ms
            steadyState:        8.01 +- 0.22 ms
        After
            firstIteration:     45.64 +- 4.23 ms
            averageWorstCase:   23.03 +- 3.34 ms
            steadyState:        7.33 +- 0.34 ms

        In SixSpeed.
                                         baseline                  patched

            map-set-lookup.es5      734.4701+-10.4383    ^    102.0968+-2.6357        ^ definitely 7.1939x faster
            map-set.es5              41.1396+-1.0558     ^     33.1916+-0.7986        ^ definitely 1.2395x faster
            map-set-object.es5       62.8317+-1.2518     ^     45.6944+-0.8369        ^ definitely 1.3750x faster

        * 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::hasArrayMode):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArrayIndexOf):
        (JSC::DFG::SpeculativeJIT::speculateObject):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::speculateInt32):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileArrayIndexOf):
        * jit/JITOperations.h:
        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation):
        * runtime/Intrinsic.cpp:
        (JSC::intrinsicName):
        * runtime/Intrinsic.h:

2017-06-11  Keith Miller  <keith_miller@apple.com>

        TypedArray constructor with string shouldn't throw
        https://bugs.webkit.org/show_bug.cgi?id=173181

        Reviewed by JF Bastien.

        We should be coercing primitive arguments to numbers in the various
        TypedArray constructors.

        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::constructGenericTypedArrayViewWithArguments):

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

        [WTF] Make ThreadMessage portable
        https://bugs.webkit.org/show_bug.cgi?id=172073

        Reviewed by Keith Miller.

        * runtime/MachineContext.h:
        (JSC::MachineContext::stackPointer):
        * tools/CodeProfiling.cpp:
        (JSC::profilingTimer):

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

        [JSC] Shrink Structure size
        https://bugs.webkit.org/show_bug.cgi?id=173239

        Reviewed by Mark Lam.

        We find that the size of our Structure is slightly enlarged due to paddings.
        By changing the order of members, we can reduce the size from 120 to 112.
        This is good because 120 and 112 are categorized into different size classes.
        For 120, we allocate 128 bytes. And for 112, we allocate 112 bytes.
        We now save 16 bytes per Structure for free.

        * runtime/ConcurrentJSLock.h:
        * runtime/Structure.cpp:
        (JSC::Structure::Structure):
        * runtime/Structure.h:

2017-06-11  Konstantin Tokarev  <annulen@yandex.ru>

        Unreviewed, attempt to fix JSC tests on Win after r217771

        * jsc.cpp:
        (currentWorkingDirectory): buffer is not NULL-terminated

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

        [WTF] Add RegisteredSymbolImpl
        https://bugs.webkit.org/show_bug.cgi?id=173230

        Reviewed by Mark Lam.

        * runtime/SymbolConstructor.cpp:
        (JSC::symbolConstructorKeyFor):

2017-06-10  Dan Bernstein  <mitz@apple.com>

        Reverted r218056 because it made the IDE reindex constantly.

        * Configurations/DebugRelease.xcconfig:

2017-06-10  Dan Bernstein  <mitz@apple.com>

        [Xcode] With Xcode 9 developer beta, everything rebuilds when switching between command-line and IDE
        https://bugs.webkit.org/show_bug.cgi?id=173223

        Reviewed by Sam Weinig.

        The rebuilds were happening due to a difference in the compiler options that the IDE and
        xcodebuild were specifying. Only the IDE was passing the -index-store-path option. To make
        xcodebuild pass that option, too, set CLANG_INDEX_STORE_ENABLE to YES if it is unset, and
        specify an appropriate path in CLANG_INDEX_STORE_PATH.

        * Configurations/DebugRelease.xcconfig:

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

        [JSC] Update RegExp.prototype.[@@search]] implementation according to the latest spec
        https://bugs.webkit.org/show_bug.cgi?id=173227

        Reviewed by Mark Lam.

        The latest spec introduces slight change to RegExp.prototype.[@@search].
        This patch applies this change. Basically, this change is done in the slow path of
        the RegExp.prototype[@@search].
        https://tc39.github.io/ecma262/#sec-regexp.prototype-@@search

        * builtins/RegExpPrototype.js:
        (search):

2017-06-09  Chris Dumez  <cdumez@apple.com>

        Update Thread::create() to take in a WTF::Function instead of a std::function
        https://bugs.webkit.org/show_bug.cgi?id=173175

        Reviewed by Mark Lam.

        * API/tests/CompareAndSwapTest.cpp:
        (testCompareAndSwap):

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

        [DFG] Add verboseDFGOSRExit
        https://bugs.webkit.org/show_bug.cgi?id=173156

        Reviewed by Saam Barati.

        This patch adds verboseDFGOSRExit which is similar to verboseFTLOSRExit.

        * dfg/DFGOSRExitCompiler.cpp:
        * runtime/Options.h:

2017-06-09  Guillaume Emont  <guijemont@igalia.com>

        [JSC][MIPS] Add MacroAssemblerMIPS::xor32(Address, RegisterID) implementation
        https://bugs.webkit.org/show_bug.cgi?id=173170

        Reviewed by Yusuke Suzuki.

        MIPS does not build since r217711 because it is missing this
        implementation. This patch fixes the build.

        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::xor32):

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

        [JSC] FTL does not require dlfcn
        https://bugs.webkit.org/show_bug.cgi?id=173143

        Reviewed by Darin Adler.

        We no longer use LLVM library. Thus, dlfcn.h is not necessary.
        Also, ProcessID is not used in FTLLowerDFGToB3.cpp.

        * ftl/FTLLowerDFGToB3.cpp:

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

        [DFG] Add --verboseDFGFailure
        https://bugs.webkit.org/show_bug.cgi?id=173155

        Reviewed by Sam Weinig.

        Similar to verboseFTLFailure, JSC should have verboseDFGFailure flag to show DFG failures quickly.

        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::verboseCapabilities):
        (JSC::DFG::debugFail):
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):
        * runtime/Options.h:

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

        [JSC] Drop OS(DARWIN) for VM_TAG_FOR_WEBASSEMBLY_MEMORY
        https://bugs.webkit.org/show_bug.cgi?id=173147

        Reviewed by JF Bastien.

        Because this value becomes -1 in non-Darwin environments.
        Thus, we do not need to use OS(DARWIN) here.

        * wasm/WasmMemory.cpp:

2017-06-09  Daewoong Jang  <daewoong.jang@navercorp.com>

        Reduce compiler warnings
        https://bugs.webkit.org/show_bug.cgi?id=172078

        Reviewed by Yusuke Suzuki.

        * runtime/IntlDateTimeFormat.h:

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

        [Cocoa] JSWrapperMap leaks for all JSContexts
        https://bugs.webkit.org/show_bug.cgi?id=173110
        <rdar://problem/32602198>

        Reviewed by Geoffrey Garen.

        * API/JSContext.mm:
        (-[JSContext ensureWrapperMap]):
        Ensure this allocation gets released.

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

        REGRESSION: js/dom/prototype-chain-caching-with-impure-get-own-property-slot-traps-5.html has a flaky failure
        https://bugs.webkit.org/show_bug.cgi?id=161156

        Reviewed by Saam Barati.
        
        Since LLInt does not register impure property watchpoints for self property accesses, it
        shouldn't try to cache accesses that require a watchpoint.
        
        This manifested as a flaky failure because the test would fire the watchpoint after we had
        usually already tiered up. Without concurrent JIT, we would have always tiered up before
        getting to the bad case. With concurrent JIT, we would sometimes not tier up by that time. This
        also adds a test that deterministically failed in LLInt without this change; it does so by just
        running a lot shorter.

        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):

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

        WebAssembly: We should only create wrappers for functions that can be exported
        https://bugs.webkit.org/show_bug.cgi?id=173088

        Reviewed by Saam Barati.

        This patch makes it so we only create wrappers for WebAssembly functions that
        can actually be exported. It appears to be a ~2.5% speedup on WasmBench compile times.

        This patch also removes most of the old testWasmModuleFunctions api from the jsc CLI.
        Most of the tests were duplicates of ones in the spec-tests directory. The others I
        have converted to use the normal API.

        * jsc.cpp:
        (GlobalObject::finishCreation):
        (valueWithTypeOfWasmValue): Deleted.
        (box): Deleted.
        (callWasmFunction): Deleted.
        (functionTestWasmModuleFunctions): Deleted.
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        (JSC::Wasm::createJSToWasmWrapper):
        (JSC::Wasm::parseAndCompile):
        * wasm/WasmB3IRGenerator.h:
        * wasm/WasmBBQPlan.cpp:
        (JSC::Wasm::BBQPlan::prepare):
        (JSC::Wasm::BBQPlan::compileFunctions):
        (JSC::Wasm::BBQPlan::complete):
        * wasm/WasmBBQPlan.h:
        * wasm/WasmBBQPlanInlines.h:
        (JSC::Wasm::BBQPlan::initializeCallees):
        * wasm/WasmCodeBlock.cpp:
        (JSC::Wasm::CodeBlock::CodeBlock):
        * wasm/WasmCodeBlock.h:
        (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace):
        * wasm/WasmFormat.h:
        * wasm/WasmOMGPlan.cpp:
        (JSC::Wasm::OMGPlan::work):

2017-06-07  JF Bastien  <jfbastien@apple.com>

        WebAssembly: test imports and exports with 16-bit characters
        https://bugs.webkit.org/show_bug.cgi?id=165977
        <rdar://problem/29760130>

        Reviewed by Saam Barati.

        Add the missing UTF-8 conversions. Improve import failure error
        messages, otherwise it's hard to figure out which import is wrong.

        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::create):
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::finishCreation):
        (JSC::WebAssemblyModuleRecord::link):

2017-06-07  Devin Rousso  <drousso@apple.com>

        Web Inspector: Add ContextMenu item to log WebSocket object to console
        https://bugs.webkit.org/show_bug.cgi?id=172878

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/Network.json:
        Add resolveWebSocket command.

2017-06-07  Jon Davis  <jond@apple.com>

        Update feature status for features Supported In Preview
        https://bugs.webkit.org/show_bug.cgi?id=173071

        Reviewed by Darin Adler.

        Updated Media Capture and Streams, Performance Observer, Resource Timing Level 2,
        User Timing Level 2, Web Cryptography API, WebGL 2, WebRTC.

        * features.json:

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

        Assertion failure in com.apple.WebKit.WebContent.Development in com.apple.JavaScriptCore: JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNullOrUndefined + 141
        https://bugs.webkit.org/show_bug.cgi?id=172673
        <rdar://problem/32250144>

        Reviewed by Mark Lam.

        This patch simply removes this assertion. It's faulty because it
        races with the main thread when doing concurrent compilation.
        
        Consider a program with:
        - a FrozenValue over an object O and Structure S1. S1 starts off as dfgWatchable() being true.
        - Structure S2
        
        The DFG IR is like so:
          a: JSConstant(O) // FrozenValue {O, S1}
          b: CheckStructure(@a, S2)
          c: ToThis(@a)
          d: CheckEq(@c, nullConstant)
          Branch(@d)
        
        The AbstractValue for @a will start off as having a finite structure because S1 is dfgWatchable().
        When running AI, we'll notice that node @b will OSR exit, so nodes after
        @b are unreachable. Later in the compilation, S1 is no longer dfgWatchable().
        Now, when running AI, @a will have Top for its structure set. No longer will
        we think @b exits.
        
        The DFG backend asserts that under such a situation, we should have simplified
        the CheckEq to false. However, this is a racy thing to assert, since the
        transition from dfgWatchable() to !dfgWatchable() can happen right before we
        enter the backend. Hence, this assertion is not valid.
        
        (Note, the generated code for the above program will never actually execute.
        Since we noticed S1 as dfgWatchable(), we make the compilation dependent on
        S1 not transitioning. S1 transitions, so we won't actually run the code that
        gets compiled.)

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

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

        [JSC] has_generic_property never accepts non-String
        https://bugs.webkit.org/show_bug.cgi?id=173057

        Reviewed by Darin Adler.

        We never pass non-String value to has_generic_property bytecode.

        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):

2017-06-06  Fujii Hironori  <Hironori.Fujii@sony.com>

        [Win][x86-64] Some callee saved registers aren't preserved
        https://bugs.webkit.org/show_bug.cgi?id=171266

        Reviewed by Saam Barati.

        * jit/RegisterSet.cpp:
        (JSC::RegisterSet::calleeSaveRegisters): Added edi and esi for X86_64 Windows.

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

        Contiguous storage butterfly length should not exceed MAX_STORAGE_VECTOR_LENGTH.
        https://bugs.webkit.org/show_bug.cgi?id=173035
        <rdar://problem/32554593>

        Reviewed by Geoffrey Garen and Filip Pizlo.

        Also added and fixed up some assertions.

        * runtime/ArrayConventions.h:
        * runtime/JSArray.cpp:
        (JSC::JSArray::setLength):
        * runtime/JSObject.cpp:
        (JSC::JSObject::createInitialIndexedStorage):
        (JSC::JSObject::ensureLengthSlow):
        (JSC::JSObject::reallocateAndShrinkButterfly):
        * runtime/JSObject.h:
        (JSC::JSObject::ensureLength):
        * runtime/RegExpObject.cpp:
        (JSC::collectMatches):
        * runtime/RegExpPrototype.cpp:
        (JSC::regExpProtoFuncSplitFast):

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

        Make sure we restore SP when doing calls that could be to JS
        https://bugs.webkit.org/show_bug.cgi?id=172946
        <rdar://problem/32579026>

        Reviewed by JF Bastien.

        I was worried that there was a bug where we'd call JS, JS would tail call,
        and we'd end up with a bogus SP. However, this bug does not exist since wasm
        always calls to JS through a stub, and the stub treats SP as a callee save.
        
        I wrote a test for this, and also made a note that this is the needed ABI.

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

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

        OMG tier up checks should be a patchpoint
        https://bugs.webkit.org/show_bug.cgi?id=172944

        Reviewed by Saam Barati.

        Tier up checks in BBQ should be done as a patchpoint rather than individual B3 opcodes.
        In order to reduce code generated out of line in each function. We generate a single stub
        that pushes all the callee-saves. This looks like a 5-10% compile time speedup.

        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        (JSC::Wasm::B3IRGenerator::emitTierUpCheck):
        (JSC::Wasm::B3IRGenerator::addLoop):
        * wasm/WasmThunks.cpp:
        (JSC::Wasm::triggerOMGTierUpThunkGenerator):
        * wasm/WasmThunks.h:

2017-06-06  Darin Adler  <darin@apple.com>

        Cut down use of WTF_ARRAY_LENGTH
        https://bugs.webkit.org/show_bug.cgi?id=172997

        Reviewed by Chris Dumez.

        * parser/Lexer.cpp:
        (JSC::singleEscape): Use WTF_ARRAY_LENGTH instead of ARRAY_SIZE.

        * runtime/NumberPrototype.cpp:
        (JSC::toStringWithRadix): Use std::end instead of WTF_ARRAY_LENGTH.

2017-06-06  Konstantin Tokarev  <annulen@yandex.ru>

        Add missing <functional> includes
        https://bugs.webkit.org/show_bug.cgi?id=173017

        Patch by Thiago Macieira <thiago.macieira@intel.com>
        Reviewed by Yusuke Suzuki.

        This patch fixes compilation with GCC 7.

        * inspector/InspectorBackendDispatcher.h:

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

        Unreviewed, fix 32-bit build.

        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_unreachable):

2017-06-06  Joseph Pecoraro  <pecoraro@apple.com>

        Unreviewed rollout r217807. Caused a test to crash.

        * heap/HeapSnapshotBuilder.cpp:
        (JSC::HeapSnapshotBuilder::buildSnapshot):
        (JSC::HeapSnapshotBuilder::json):
        (): Deleted.
        * heap/HeapSnapshotBuilder.h:
        * runtime/JSObject.cpp:
        (JSC::JSObject::calculatedClassName):

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

        index out of bound in bytecodebasicblock
        https://bugs.webkit.org/show_bug.cgi?id=172963

        Reviewed by Saam Barati and Mark Lam.
        
        We were leaving an unterminated basic block when generating CodeForCall for a class
        constructor. This was mostly benign since that unterminated block was not reachable, but it
        does cause an ASSERT.
        
        This fixes the issue by appending op_unreachable to that block. I added op_unreachable because
        this really is the cleanest and most idiomatic way to solve this problem, so even though it
        makes the change bigger it's probabably worth it.

        * bytecode/BytecodeDumper.cpp:
        (JSC::BytecodeDumper<Block>::dumpBytecode):
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/Opcode.h:
        (JSC::isTerminal):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate):
        (JSC::BytecodeGenerator::emitUnreachable):
        * bytecompiler/BytecodeGenerator.h:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileUnreachable):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_unreachable):
        * llint/LowLevelInterpreter.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:

2017-06-06  Ryan Haddad  <ryanhaddad@apple.com>

        Unreviewed, rolling out r217812.

        This change caused test failures on arm64.

        Reverted changeset:

        "OMG tier up checks should be a patchpoint"
        https://bugs.webkit.org/show_bug.cgi?id=172944
        http://trac.webkit.org/changeset/217812

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

        [WPE] Enable remote inspector
        https://bugs.webkit.org/show_bug.cgi?id=172971

        Reviewed by Žan Doberšek.

        We can just build the current glib remote inspector, without adding a frontend implementation and using a
        WebKitGTK+ browser as frontend for now.

        * PlatformWPE.cmake: Add remote inspector files to compilation.
        * inspector/remote/glib/RemoteInspectorUtils.cpp:
        (Inspector::backendCommands): Load the inspector resources library.

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

        [GLIB] Make remote inspector DBus protocol common to all glib based ports
        https://bugs.webkit.org/show_bug.cgi?id=172970

        Reviewed by Žan Doberšek.

        We are currently using "webkitgtk" in the names of DBus interfaces and object paths inside an ifdef with the
        idea that other ports could use their own names. However, the protocol is the same, so we could use the same
        names and make all glib based ports compatible to each other. This way we could use the GTK+ MiniBrowser to
        debug WPE, without having to implement the frontend part in WPE yet.

        * inspector/remote/glib/RemoteInspectorGlib.cpp: Use webkit instead of webkitgtk and reomve platform idfeds.
        * inspector/remote/glib/RemoteInspectorServer.cpp: Ditto.

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

        [GTK] Web Process deadlock when closing the remote inspector frontend
        https://bugs.webkit.org/show_bug.cgi?id=172973

        Reviewed by Žan Doberšek.

        We are taking the remote inspector mutex twice. First close message is received, and receivedCloseMessage()
        takes the mutex. Then RemoteConnectionToTarget::close() is called that, when connected, calls
        PageDebuggable::disconnect() that ends up calling RemoteInspector::updateTarget() that also takes the remote
        inspector mutex. We should release the mutex before calling RemoteConnectionToTarget::close().

        * inspector/remote/glib/RemoteInspectorGlib.cpp:
        (Inspector::RemoteInspector::receivedCloseMessage):

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

        Try to fix features.json by adding an ESNext section.

        Unreviewed.

        * features.json:

2017-06-05  David Kilzer  <ddkilzer@apple.com>

        Follow-up: Update JSC's features.json
        https://bugs.webkit.org/show_bug.cgi?id=172942

        Rubber-stamped by Jon Davis.

        * features.json: Change "Supported in preview" to
        "Supported" to try to fix <https://webkit.org/status/>.

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

        We don't properly parse init_expr when the opcode is an unexpected opcode
        https://bugs.webkit.org/show_bug.cgi?id=172945

        Reviewed by JF Bastien.

        The bug is a simple typo. It should use the constant
        `true` instead of `false` when invoking the WASM_PARSER_FAIL_IF
        macro. This failure is already caught by spec tests that fail
        on arm64 devices.

        * wasm/WasmModuleParser.cpp:

2017-06-05  Keith Miller  <keith_miller@apple.com>

        OMG tier up checks should be a patchpoint
        https://bugs.webkit.org/show_bug.cgi?id=172944

        Reviewed by Saam Barati.

        Tier up checks in BBQ should be done as a patchpoint rather than individual B3 opcodes.
        In order to reduce code generated out of line in each function. We generate a single stub
        that pushes all the callee-saves. This looks like a 5-10% compile time speedup.

        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        (JSC::Wasm::B3IRGenerator::emitTierUpCheck):
        (JSC::Wasm::B3IRGenerator::addLoop):
        * wasm/WasmThunks.cpp:
        (JSC::Wasm::triggerOMGTierUpThunkGenerator):
        * wasm/WasmThunks.h:

2017-06-05  Joseph Pecoraro  <pecoraro@apple.com>

        Remove unused VM members
        https://bugs.webkit.org/show_bug.cgi?id=172941

        Reviewed by Mark Lam.

        * runtime/HashMapImpl.h:
        (JSC::HashMapImpl::selectStructure): Deleted.
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2017-06-05  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Improve ES6 Class instances in Heap Snapshot instances view
        https://bugs.webkit.org/show_bug.cgi?id=172848
        <rdar://problem/25709212>

        Reviewed by Saam Barati.

        * heap/HeapSnapshotBuilder.h:
        * heap/HeapSnapshotBuilder.cpp:
        Update the snapshot version. Change the node's 0 | 1 internal value
        to be a 32bit bit flag. This is nice in that it is both compatible
        with the previous snapshot version and the same size. We can use more
        flags in the future.

        (JSC::HeapSnapshotBuilder::json):
        In cases where the classInfo gives us "Object" check for a better
        class name by checking (o).__proto__.constructor.name. We avoid this
        check in cases where (o).hasOwnProperty("constructor") which is the
        case for most Foo.prototype objects. Otherwise this would get the
        name of the Foo superclass for the Foo.prototype object.

        * runtime/JSObject.cpp:
        (JSC::JSObject::calculatedClassName):
        Handle some possible edge cases that were not handled before. Such
        as a JSObject without a GlobalObject, and an object which doesn't
        have a default getPrototype. Try to make the code a little clearer.

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

        Update JSC's features.json
        https://bugs.webkit.org/show_bug.cgi?id=172942

        Rubber stamped by Mark Lam.

        * features.json:

2017-06-04  Konstantin Tokarev  <annulen@yandex.ru>

        Fix build of Windows-specific code with ICU 59.1
        https://bugs.webkit.org/show_bug.cgi?id=172729

        Reviewed by Darin Adler.

        Fix conversions from WTF::String to wchar_t* and vice versa.

        * jsc.cpp:
        (currentWorkingDirectory):
        (fetchModuleFromLocalFileSystem):
        * runtime/DateConversion.cpp:
        (JSC::formatDateTime):

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

        [JSC] Drop unnecessary USE(CF) guard for getenv
        https://bugs.webkit.org/show_bug.cgi?id=172903

        Reviewed by Sam Weinig.

        getenv is not related to USE(CF) and OS(UNIX). It seems that this
        ifdef only hits in WinCairo, but WinCairo can use getenv.
        Moreover, in VM::VM, we already use getenv without any ifdef guard.

        This patch just drops it.

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

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

        [JSC] Drop OS(DARWIN) for uintptr_t type conflict
        https://bugs.webkit.org/show_bug.cgi?id=172904

        Reviewed by Sam Weinig.

        In non-Darwin environment, uintptr_t may have the same type
        to uint64_t. We avoided the compile error by using OS(DARWIN).
        But, since it depends on cstdint implementaion rather than OS, it is flaky.
        Instead, we just use template parameter IntegralType.
        And we describe the type constraint in a SFINAE manner.

        * dfg/DFGOpInfo.h:
        (JSC::DFG::OpInfo::OpInfo):

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

        [ARM] Unreviewed buildfix after r217711.

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

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

        ASSERTION FAILED: "We should only declare a function as a lexically scoped variable in scopes where var declarations aren't allowed. ..." for function redeclaration with async function module export
        https://bugs.webkit.org/show_bug.cgi?id=168844

        Reviewed by Saam Barati.

        As the same to the exported function declaration, we should set statementDepth = 1 for exported async function declaration.

        * parser/Parser.cpp:
        (JSC::DepthManager::DepthManager):
        (JSC::Parser<LexerType>::parseExportDeclaration):
        * parser/Parser.h:
        (JSC::Parser::DepthManager::DepthManager): Deleted.
        (JSC::Parser::DepthManager::~DepthManager): Deleted.

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

        Defer installing mach breakpoint handler until watchdog is actually called
        https://bugs.webkit.org/show_bug.cgi?id=172885

        Reviewed by Saam Barati.

        Eagerly installing the mach breakpoint handler causes issues with Xcode GUI debugging.
        This hides the issue, so it won't occur as often.

        * runtime/VMTraps.cpp:
        (JSC::VMTraps::SignalSender::send):
        (JSC::VMTraps::VMTraps): Deleted.
        * runtime/VMTraps.h:

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

        Atomics.load and Atomics.store need to be fully fenced
        https://bugs.webkit.org/show_bug.cgi?id=172844

        Reviewed by Keith Miller.
        
        Implement fully fenced loads and stores in FTL using AtomicXchgAdd(0, ptr) for the load and
        AtomicXchg(value, ptr) for the store.
        
        DFG needed no changes because it implements all atomics using a CAS loop.
        
        AtomicsObject.cpp now uses new Atomic<> API for fully fences loads and stores.
        
        Prior to this change, we used half fences (acquire/release) for atomic loads and stores. This
        is not correct according to my current understanding of the SAB memory model, which requires
        that atomic operations are SC with respect to everything not just other atomics.

        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileAtomicsReadModifyWrite):
        * ftl/FTLOutput.cpp:
        (JSC::FTL::Output::atomicWeakCAS):
        * ftl/FTLOutput.h:
        * runtime/AtomicsObject.cpp:

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

        Unreviewed, attempt to fix the iOS build after r217711.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::xor32):
        (JSC::MacroAssemblerARM64::xor64):

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

        GC should use scrambled free-lists
        https://bugs.webkit.org/show_bug.cgi?id=172793

        Reviewed by Mark Lam.
        
        Previously, our bump'n'pop allocator would use a conventional linked-list for the free-list.
        The linked-list would be threaded through free memory, as is the usual convention.
        
        This scrambles the next pointers of that free-list. It also scrambles the head pointer, because
        this leads to a more natural fast-path structure and saves one register on ARM64.
        
        The secret with which pointers are scrambled is per-allocator. Allocators choose a new secret
        every time they do a sweep-to-pop.
        
        This doesn't change the behavior of the bump part of bump'n'pop, but it does refactor the code
        quite a bit. Previously, there were four copies of the allocator fast path: two in
        MarkedAllocatorInlines.h, one in MarkedAllocator.cpp, and one in AssemblyHelpers.h. The JIT one
        was obviously different-looking, but the other three were almost identical. This moves all of
        that logic into FreeList. There are now just two copies of the allocator: FreeListInlines.h and
        AssemblyHelpers.h.
        
        This appears to be just as fast as our previously allocator.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/FreeList.cpp:
        (JSC::FreeList::FreeList):
        (JSC::FreeList::~FreeList):
        (JSC::FreeList::clear):
        (JSC::FreeList::initializeList):
        (JSC::FreeList::initializeBump):
        (JSC::FreeList::contains):
        (JSC::FreeList::dump):
        * heap/FreeList.h:
        (JSC::FreeList::allocationWillFail):
        (JSC::FreeList::originalSize):
        (JSC::FreeList::addressOfList):
        (JSC::FreeList::offsetOfBlock):
        (JSC::FreeList::offsetOfList):
        (JSC::FreeList::offsetOfIndex):
        (JSC::FreeList::offsetOfPayloadEnd):
        (JSC::FreeList::offsetOfRemaining):
        (JSC::FreeList::offsetOfOriginalSize):
        (JSC::FreeList::FreeList): Deleted.
        (JSC::FreeList::list): Deleted.
        (JSC::FreeList::bump): Deleted.
        (JSC::FreeList::operator==): Deleted.
        (JSC::FreeList::operator!=): Deleted.
        (JSC::FreeList::operator bool): Deleted.
        * heap/FreeListInlines.h: Added.
        (JSC::FreeList::addFreeCell):
        (JSC::FreeList::allocate):
        (JSC::FreeList::forEach):
        (JSC::FreeList::toOffset):
        (JSC::FreeList::fromOffset):
        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::sweepNextBlock):
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::MarkedAllocator):
        (JSC::MarkedAllocator::didConsumeFreeList):
        (JSC::MarkedAllocator::tryAllocateWithoutCollecting):
        (JSC::MarkedAllocator::tryAllocateIn):
        (JSC::MarkedAllocator::allocateSlowCaseImpl):
        (JSC::MarkedAllocator::stopAllocating):
        (JSC::MarkedAllocator::prepareForAllocation):
        (JSC::MarkedAllocator::resumeAllocating):
        (JSC::MarkedAllocator::sweep):
        (JSC::MarkedAllocator::setFreeList): Deleted.
        * heap/MarkedAllocator.h:
        (JSC::MarkedAllocator::freeList):
        (JSC::MarkedAllocator::isFreeListedCell): Deleted.
        * heap/MarkedAllocatorInlines.h:
        (JSC::MarkedAllocator::isFreeListedCell):
        (JSC::MarkedAllocator::tryAllocate):
        (JSC::MarkedAllocator::allocate):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::Handle::stopAllocating):
        (JSC::MarkedBlock::Handle::lastChanceToFinalize):
        (JSC::MarkedBlock::Handle::resumeAllocating):
        (JSC::MarkedBlock::Handle::zap):
        (JSC::MarkedBlock::Handle::sweep):
        (JSC::MarkedBlock::Handle::isFreeListedCell):
        (JSC::MarkedBlock::Handle::forEachFreeCell): Deleted.
        * heap/MarkedBlock.h:
        * heap/MarkedBlockInlines.h:
        (JSC::MarkedBlock::Handle::specializedSweep):
        (JSC::MarkedBlock::Handle::finishSweepKnowingSubspace):
        (JSC::MarkedBlock::Handle::isFreeListedCell): Deleted.
        * heap/Subspace.cpp:
        (JSC::Subspace::finishSweep):
        * heap/Subspace.h:
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator):
        * runtime/JSDestructibleObjectSubspace.cpp:
        (JSC::JSDestructibleObjectSubspace::finishSweep):
        * runtime/JSDestructibleObjectSubspace.h:
        * runtime/JSSegmentedVariableObjectSubspace.cpp:
        (JSC::JSSegmentedVariableObjectSubspace::finishSweep):
        * runtime/JSSegmentedVariableObjectSubspace.h:
        * runtime/JSStringSubspace.cpp:
        (JSC::JSStringSubspace::finishSweep):
        * runtime/JSStringSubspace.h:
        * wasm/js/JSWebAssemblyCodeBlockSubspace.cpp:
        (JSC::JSWebAssemblyCodeBlockSubspace::finishSweep):
        * wasm/js/JSWebAssemblyCodeBlockSubspace.h:

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

        [JSC] Use @globalPrivate for concatSlowPath
        https://bugs.webkit.org/show_bug.cgi?id=172802

        Reviewed by Darin Adler.

        Use @globalPrivate instead of manually putting it to JSGlobalObject.

        * builtins/ArrayPrototype.js:
        (concatSlowPath): Deleted.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):

2017-06-01  Andy Estes  <aestes@apple.com>

        REGRESSION (r217626): ENABLE_APPLE_PAY_SESSION_V3 was disabled by mistake
        https://bugs.webkit.org/show_bug.cgi?id=172828

        Reviewed by Beth Dakin.

        * Configurations/FeatureDefines.xcconfig:

2017-06-01  Keith Miller  <keith_miller@apple.com>

        Undo rollout in r217638 with bug fix
        https://bugs.webkit.org/show_bug.cgi?id=172824

        Unreviewed, reland patch with unused set_state code removed.

        * API/tests/ExecutionTimeLimitTest.cpp:
        (dispatchTermitateCallback):
        (testExecutionTimeLimit):
        * runtime/JSLock.cpp:
        (JSC::JSLock::didAcquireLock):
        * runtime/Options.cpp:
        (JSC::overrideDefaults):
        (JSC::Options::initialize):
        * runtime/Options.h:
        * runtime/VMTraps.cpp:
        (JSC::SignalContext::SignalContext):
        (JSC::SignalContext::adjustPCToPointToTrappingInstruction):
        (JSC::installSignalHandler):
        (JSC::VMTraps::SignalSender::send):
        * tools/SigillCrashAnalyzer.cpp:
        (JSC::SignalContext::SignalContext):
        (JSC::SignalContext::dump):
        (JSC::installCrashHandler):
        * wasm/WasmBBQPlan.cpp:
        (JSC::Wasm::BBQPlan::compileFunctions):
        * wasm/WasmFaultSignalHandler.cpp:
        (JSC::Wasm::trapHandler):
        (JSC::Wasm::enableFastMemory):
        * wasm/WasmMachineThreads.cpp:
        (JSC::Wasm::resetInstructionCacheOnAllThreads):

2017-06-01  Guillaume Emont  <guijemont@igalia.com>

        [JSC][MIPS] SamplingProfiler::timerLoop() sleeps for 4000+ seconds
        https://bugs.webkit.org/show_bug.cgi?id=172800

        Reviewed by Saam Barati.

        This fixes a static_cast<uint64_t> by making it a cast to int64_t
        instead, which looks like the original intent. This fixes the
        sampling-profiler tests in JSTests/stress.

        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::timerLoop):

2017-06-01  Tomas Popela  <tpopela@redhat.com>, Mark Lam  <mark.lam@apple.com>

        RELEASE_ASSERT_NOT_REACHED() in InferredType::kindForFlags() on Big-Endians
        https://bugs.webkit.org/show_bug.cgi?id=170945

        Reviewed by Mark Lam.

        Re-define PutByIdFlags as a int32_t enum explicitly because it is
        stored as an int32_t value in UnlinkedInstruction.  This prevents
        a bug on 64-bit big endian architectures where the word order is
        inverted (when we convert the UnlinkedInstruction into a CodeBlock
        Instruction), resulting in the PutByIdFlags value not being stored in
        the 32-bit word that the rest of the code expects it to be in.

        * bytecode/PutByIdFlags.h:

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

        [JSC] Implement String.prototype.concat in JS builtins
        https://bugs.webkit.org/show_bug.cgi?id=172798

        Reviewed by Sam Weinig.

        Since we have highly effective + operation for strings,
        implementing String.prototype.concat in JS simplifies the
        implementation and improves performance by using speculated
        types.

        Added microbenchmarks show performance improvement.

        string-concat-long-convert     1063.2787+-12.9101    ^    109.0855+-2.8083        ^ definitely 9.7472x faster
        string-concat-convert          1111.1366+-12.2363    ^     99.3402+-1.9874        ^ definitely 11.1852x faster
        string-concat                   131.7377+-3.8359     ^     54.3949+-0.9580        ^ definitely 2.4219x faster
        string-concat-long               79.4726+-1.9644     ^     64.6301+-1.4941        ^ definitely 1.2297x faster

        * builtins/StringPrototype.js:
        (globalPrivate.stringConcatSlowPath):
        (concat):
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        (JSC::stringProtoFuncConcat): Deleted.

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

        Remove overrides of visitChildren() that do not add any functionality.
        https://bugs.webkit.org/show_bug.cgi?id=172789
        <rdar://problem/32500865>

        Reviewed by Andreas Kling.

        * bytecode/UnlinkedModuleProgramCodeBlock.cpp:
        (JSC::UnlinkedModuleProgramCodeBlock::visitChildren): Deleted.
        * bytecode/UnlinkedModuleProgramCodeBlock.h:
        * bytecode/UnlinkedProgramCodeBlock.cpp:
        (JSC::UnlinkedProgramCodeBlock::visitChildren): Deleted.
        * bytecode/UnlinkedProgramCodeBlock.h:
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::WebAssemblyFunction::visitChildren): Deleted.
        * wasm/js/WebAssemblyFunction.h:
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::WebAssemblyInstanceConstructor::visitChildren): Deleted.
        * wasm/js/WebAssemblyInstanceConstructor.h:
        * wasm/js/WebAssemblyMemoryConstructor.cpp:
        (JSC::WebAssemblyMemoryConstructor::visitChildren): Deleted.
        * wasm/js/WebAssemblyMemoryConstructor.h:
        * wasm/js/WebAssemblyModuleConstructor.cpp:
        (JSC::WebAssemblyModuleConstructor::visitChildren): Deleted.
        * wasm/js/WebAssemblyModuleConstructor.h:
        * wasm/js/WebAssemblyTableConstructor.cpp:
        (JSC::WebAssemblyTableConstructor::visitChildren): Deleted.
        * wasm/js/WebAssemblyTableConstructor.h:

2017-05-31  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r217611 and r217631.
        https://bugs.webkit.org/show_bug.cgi?id=172785

        "caused wasm-hashset-many.html to become flaky." (Requested by
        keith_miller on #webkit).

        Reverted changesets:

        "Reland r216808, underlying lldb bug has been fixed."
        https://bugs.webkit.org/show_bug.cgi?id=172759
        http://trac.webkit.org/changeset/217611

        "Use dispatch queues for mach exceptions"
        https://bugs.webkit.org/show_bug.cgi?id=172775
        http://trac.webkit.org/changeset/217631

2017-05-31  Oleksandr Skachkov  <gskachkov@gmail.com>

        Rolling out: Prevent async methods named 'function'
        https://bugs.webkit.org/show_bug.cgi?id=172776

        Reviewed by Mark Lam.

        Rolling out https://bugs.webkit.org/show_bug.cgi?id=172660 r217578, 
        https://bugs.webkit.org/show_bug.cgi?id=172598  r217478
        PR to spec was closed, so changes need to roll out. See
        https://github.com/tc39/ecma262/pull/884#issuecomment-305212494 

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

2017-05-31  Andy Estes  <aestes@apple.com>

        Rename ENABLE_APPLE_PAY_DELEGATE to ENABLE_APPLE_PAY_SESSION_V3 and bump the supported version number
        https://bugs.webkit.org/show_bug.cgi?id=172366

        Reviewed by Daniel Bates.

        * Configurations/FeatureDefines.xcconfig:

2017-05-31  Keith Miller  <keith_miller@apple.com>

        Reland r216808, underlying lldb bug has been fixed.
        https://bugs.webkit.org/show_bug.cgi?id=172759


        Unreviewed, relanding old patch. See: rdar://problem/31183352

        * API/tests/ExecutionTimeLimitTest.cpp:
        (dispatchTermitateCallback):
        (testExecutionTimeLimit):
        * runtime/JSLock.cpp:
        (JSC::JSLock::didAcquireLock):
        * runtime/Options.cpp:
        (JSC::overrideDefaults):
        (JSC::Options::initialize):
        * runtime/Options.h:
        * runtime/VMTraps.cpp:
        (JSC::SignalContext::SignalContext):
        (JSC::SignalContext::adjustPCToPointToTrappingInstruction):
        (JSC::installSignalHandler):
        (JSC::VMTraps::SignalSender::send):
        * tools/SigillCrashAnalyzer.cpp:
        (JSC::SignalContext::SignalContext):
        (JSC::SignalContext::dump):
        (JSC::installCrashHandler):
        * wasm/WasmBBQPlan.cpp:
        (JSC::Wasm::BBQPlan::compileFunctions):
        * wasm/WasmFaultSignalHandler.cpp:
        (JSC::Wasm::trapHandler):
        (JSC::Wasm::enableFastMemory):
        * wasm/WasmMachineThreads.cpp:
        (JSC::Wasm::resetInstructionCacheOnAllThreads):

2017-05-31  Keith Miller  <keith_miller@apple.com>

        Fix leak in PromiseDeferredTimer
        https://bugs.webkit.org/show_bug.cgi?id=172755

        Reviewed by JF Bastien.

        We were not properly freeing the list of dependencies if we were already tracking the promise before.
        This is because addPendingPromise takes the list of dependencies as an rvalue-reference. In the case
        where we were already tracking the promise we append the provided dependency list to the existing list.
        Since we never bound or rvalue-ref to a non-temporary value we never destructed the Vector, leaking its
        contents.

        * runtime/PromiseDeferredTimer.cpp:
        (JSC::PromiseDeferredTimer::addPendingPromise):

2017-05-30  Oleksandr Skachkov  <gskachkov@gmail.com>

        Prevent async methods named 'function' in Object literal
        https://bugs.webkit.org/show_bug.cgi?id=172660

        Reviewed by Saam Barati.

        Prevent async method named 'function' in object.
        https://github.com/tc39/ecma262/pull/884

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

2017-05-30  Oleksandr Skachkov  <gskachkov@gmail.com>

        ASSERTION FAILED: generator.isConstructor() || generator.derivedContextType() == DerivedContextType::DerivedConstructorContext
        https://bugs.webkit.org/show_bug.cgi?id=171274

        Reviewed by Saam Barati.

        Current patch allow to use async arrow function within constructor,
        and allow to access to `this`. Current patch force load 'this' from 
        virtual scope each time as we access to `this` in async arrow function
        within constructor it is neccessary because async function can be 
        suspended and `superCall` can be called and async function resumed. 
   
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitPutGeneratorFields):
        (JSC::BytecodeGenerator::ensureThis):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::makeFunction):

2017-05-30  Ali Juma  <ajuma@chromium.org>

        [CredentialManagement] Incorporate IDL updates from latest spec
        https://bugs.webkit.org/show_bug.cgi?id=172011

        Reviewed by Daniel Bates.

        * runtime/CommonIdentifiers.h:

2017-05-30  Alex Christensen  <achristensen@webkit.org>

        Update libwebrtc configuration
        https://bugs.webkit.org/show_bug.cgi?id=172727

        Reviewed by Geoffrey Garen.

        * Configurations/FeatureDefines.xcconfig:

2017-05-28  Dan Bernstein  <mitz@apple.com>

        [Xcode] ALWAYS_SEARCH_USER_PATHS is set to YES
        https://bugs.webkit.org/show_bug.cgi?id=172691

        Reviewed by Tim Horton.

        * Configurations/Base.xcconfig: Set ALWAYS_SEARCH_USER_PATHS to NO.
        * JavaScriptCore.xcodeproj/project.pbxproj: Added ParseInt.h to the JavaScriptCore target.

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

        [JSC] Provide better type information of toLength and tighten bytecode
        https://bugs.webkit.org/show_bug.cgi?id=172690

        Reviewed by Sam Weinig.

        In this patch, we carefully leverage operator + in order to

        1. tighten bytecode

        operator+ emits to_number bytecode. What this bytecode does is the same
        to @Number() call. It is more efficient, and it is smaller bytecode
        than @Number() call (load global variable @Number, set up arguments, and
        call it).

        2. offer better type prediction data

        Now, we have code like

            length > 0 ? (length < @MAX_SAFE_INTEGER ? length : @MAX_SAFE_INTEGER) : 0

        This is not good because DFG prediction propagation phase predicts as Double
        since @MAX_SAFE_INTEGER is double. But actually it rarely becomes Double.
        Usually, the result becomes Int32. This patch leverages to_number in a bit
        interesting way: to_number has value profiling to offer better type prediction.
        This value profiling can offer a chance to change the prediction to Int32 efficiently.
        It is a bit tricky. But it is worth doing to speed up our builtin functions,
        which should leverage all the JSC's tricky things to be optimized.

        Related microbenchmarks show performance improvement.

                                                  baseline                  patched

            array-prototype-forEach           50.2348+-2.2331           49.7568+-2.3507
            array-prototype-map               51.0574+-1.8166           47.9531+-2.1653          might be 1.0647x faster
            array-prototype-some              52.3926+-1.8882     ^     48.3632+-2.0852        ^ definitely 1.0833x faster
            array-prototype-every             52.7394+-2.0712           50.2896+-2.1480          might be 1.0487x faster
            array-prototype-reduce            54.9994+-2.3638           51.8716+-2.6253          might be 1.0603x faster
            array-prototype-reduceRight      209.7594+-9.2594     ^     51.5867+-2.5745        ^ definitely 4.0662x faster


        * builtins/GlobalOperations.js:
        (globalPrivate.toInteger):
        (globalPrivate.toLength):

2017-05-28  Sam Weinig  <sam@webkit.org>

        [WebIDL] @@iterator should only be accessed once when disambiguating a union type
        https://bugs.webkit.org/show_bug.cgi?id=172684

        Reviewed by Yusuke Suzuki.

        * runtime/IteratorOperations.cpp:
        (JSC::iteratorMethod):
        (JSC::iteratorForIterable):
        * runtime/IteratorOperations.h:
        (JSC::forEachInIterable):
        Add additional iterator helpers to allow union + sequence conversion code
        to check for iterability by getting the iterator method, and iterate using
        that method later on.

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

        Unreviewed, build fix for Windows
        https://bugs.webkit.org/show_bug.cgi?id=172413

        Optimized jsDynamicCast for JSMap and JSSet will be handled in [1].

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

        * runtime/JSMap.h:
        (JSC::isJSMap):
        (JSC::jsDynamicCast): Deleted.
        (JSC::>): Deleted.
        * runtime/JSSet.h:
        (JSC::isJSSet):
        (JSC::jsDynamicCast): Deleted.
        (JSC::>): Deleted.
        * runtime/MapConstructor.cpp:
        (JSC::constructMap):
        * runtime/SetConstructor.cpp:
        (JSC::constructSet):

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

        Implement a faster Interpreter::getOpcodeID().
        https://bugs.webkit.org/show_bug.cgi?id=172669

        Reviewed by Saam Barati.

        We can implement Interpreter::getOpcodeID() without a hash table lookup by always
        embedding the OpcodeID in the 32-bit word just before the start of the LLInt
        handler code that executes each opcode.  getOpcodeID() can therefore just read
        the 32-bits before the opcode address to get its OpcodeID.

        This is currently only enabled for CPU(X86), CPU(X86_64), CPU(ARM64),
        CPU(ARM_THUMB2), and only for OS(DARWIN).  It'll probably just work for linux as
        well, but I'll let the Linux folks turn that on after they have verified that it
        works on linux too.

        I'll also take this opportunity to clean up how we initialize the opcodeIDTable:
        1. we only need to initialize it once per process, not once per VM / interpreter
           instance.
        2. we can initialize it in the Interpreter constructor instead of requiring a
           separate call to an initialize() function.

        On debug builds, the Interpreter constructor will also verify that getOpcodeID()
        is working correctly for each opcode when USE(LLINT_EMBEDDED_OPCODE_ID).

        * bytecode/BytecodeList.json:
        * generate-bytecode-files:
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::Interpreter):
        (JSC::Interpreter::opcodeIDTable):
        (JSC::Interpreter::initialize): Deleted.
        * interpreter/Interpreter.h:
        (JSC::Interpreter::getOpcode):
        (JSC::Interpreter::getOpcodeID):
        * llint/LowLevelInterpreter.cpp:
        * runtime/VM.cpp:
        (JSC::VM::VM):

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

        [JSC] Map and Set constructors should have fast path for cloning
        https://bugs.webkit.org/show_bug.cgi?id=172413

        Reviewed by Saam Barati.

        In this patch, we add a fast path for cloning in Set and Map constructors.

        In ARES-6 Air, we have code like `new Set(set)` to clone the given set.
        At that time, our generic path just iterates the given set object and add
        it to the newly created one. It is quite slow because we need to follow
        the iterator protocol inside C++ and we need to call set.add() repeatedly
        while the given set guarantees the elements are unique.

        This patch implements clone() function to JSMap and JSSet. Cloning JSMap
        and JSSet are done really fast without invoking any observable JS functions.
        To check whether we can use this clone() function in Set and Map constructors,
        we set several watchpoints.

        In the case of Set,

        1. Set.prototype[Symbol.iterator] is not changed.
        2. SetIterator.prototype.next is not changed.
        3. Set.prototype.add is not changed.
        4. The given Set does not have [Symbol.iterator] function in its instance.
        5. The given Set's [[Prototype]] is Set.prototype.
        6. Newly created set's [[Prototype]] is Set.prototype.

        If the above requirements are met, cloning the given Set is not observable to users.
        Thus we can take a fast path.

        Currently, we do not integrate this optimization into DFG and FTL.
        And we do not optimize other iterables. For example, we can optimize Set
        constructor taking Int32 Array. And we should optimize generic iterator cases too.
        They are planned as part of a separate bug[1].

        This change improves ARES-6 Air by 5.3% in steady state.

        Baseline:
            Running... Air ( 1  to go)
            firstIteration:     76.41 +- 15.60 ms
            averageWorstCase:   40.63 +- 7.54 ms
            steadyState:        9.13 +- 0.51 ms


        Patched:
            Running... Air ( 1  to go)
            firstIteration:     75.00 +- 22.54 ms
            averageWorstCase:   39.18 +- 8.45 ms
            steadyState:        8.67 +- 0.28 ms

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

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/ArrayIteratorAdaptiveWatchpoint.cpp: Removed.
        * runtime/HashMapImpl.h:
        (JSC::HashMapBucket::extractValue):
        (JSC::HashMapImpl::finishCreation):
        (JSC::HashMapImpl::add):
        (JSC::HashMapImpl::setUpHeadAndTail):
        (JSC::HashMapImpl::addNormalizedNonExistingForCloning):
        (JSC::HashMapImpl::addNormalizedInternal):
        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::createSubclassStructureSlow):
        (JSC::InternalFunction::createSubclassStructure): Deleted.
        * runtime/InternalFunction.h:
        (JSC::InternalFunction::createSubclassStructure):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::JSGlobalObject):
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::mapIteratorProtocolWatchpoint):
        (JSC::JSGlobalObject::setIteratorProtocolWatchpoint):
        (JSC::JSGlobalObject::mapSetWatchpoint):
        (JSC::JSGlobalObject::setAddWatchpoint):
        (JSC::JSGlobalObject::mapPrototype):
        (JSC::JSGlobalObject::jsSetPrototype):
        (JSC::JSGlobalObject::setStructure):
        * runtime/JSGlobalObjectInlines.h:
        (JSC::JSGlobalObject::isMapPrototypeIteratorProtocolFastAndNonObservable):
        (JSC::JSGlobalObject::isSetPrototypeIteratorProtocolFastAndNonObservable):
        (JSC::JSGlobalObject::isMapPrototypeSetFastAndNonObservable):
        (JSC::JSGlobalObject::isSetPrototypeAddFastAndNonObservable):
        * runtime/JSMap.cpp:
        (JSC::JSMap::clone):
        (JSC::JSMap::canCloneFastAndNonObservable):
        * runtime/JSMap.h:
        (JSC::jsDynamicCast):
        (JSC::>):
        (JSC::JSMap::createStructure): Deleted.
        (JSC::JSMap::create): Deleted.
        (JSC::JSMap::set): Deleted.
        (JSC::JSMap::JSMap): Deleted.
        * runtime/JSSet.cpp:
        (JSC::JSSet::clone):
        (JSC::JSSet::canCloneFastAndNonObservable):
        * runtime/JSSet.h:
        (JSC::jsDynamicCast):
        (JSC::>):
        (JSC::JSSet::createStructure): Deleted.
        (JSC::JSSet::create): Deleted.
        (JSC::JSSet::JSSet): Deleted.
        * runtime/MapConstructor.cpp:
        (JSC::constructMap):
        * runtime/ObjectPropertyChangeAdaptiveWatchpoint.h: Renamed from Source/JavaScriptCore/runtime/ArrayIteratorAdaptiveWatchpoint.h.
        (JSC::ObjectPropertyChangeAdaptiveWatchpoint::ObjectPropertyChangeAdaptiveWatchpoint):
        * runtime/SetConstructor.cpp:
        (JSC::constructSet):

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

        [DOMJIT] Move DOMJIT patchpoint infrastructure out of domjit
        https://bugs.webkit.org/show_bug.cgi?id=172260

        Reviewed by Filip Pizlo.

        DOMJIT::Patchpoint is now used for generalized CheckSubClass. And it becomes mature enough
        to be used as a general-purpose injectable compiler over all the JIT tiers.

        We extract DOMJIT::Patchpoint to jit/ and rename it JSC::Snippet.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/AccessCaseSnippetParams.cpp: Renamed from Source/JavaScriptCore/bytecode/DOMJITAccessCasePatchpointParams.cpp.
        (JSC::SlowPathCallGeneratorWithArguments::generateImpl):
        (JSC::AccessCaseSnippetParams::emitSlowPathCalls):
        * bytecode/AccessCaseSnippetParams.h: Renamed from Source/JavaScriptCore/bytecode/DOMJITAccessCasePatchpointParams.h.
        (JSC::AccessCaseSnippetParams::AccessCaseSnippetParams):
        * bytecode/GetterSetterAccessCase.cpp:
        (JSC::GetterSetterAccessCase::emitDOMJITGetter):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::blessCallDOMGetter):
        (JSC::DFG::ByteCodeParser::handleDOMJITGetter):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGGraph.h:
        * dfg/DFGNode.h:
        * dfg/DFGSnippetParams.cpp: Renamed from Source/JavaScriptCore/dfg/DFGDOMJITPatchpointParams.cpp.
        * dfg/DFGSnippetParams.h: Renamed from Source/JavaScriptCore/dfg/DFGDOMJITPatchpointParams.h.
        (JSC::DFG::SnippetParams::SnippetParams):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::allocateTemporaryRegistersForSnippet):
        (JSC::DFG::SpeculativeJIT::compileCallDOMGetter):
        (JSC::DFG::SpeculativeJIT::compileCheckSubClass):
        (JSC::DFG::allocateTemporaryRegistersForPatchpoint): Deleted.
        * domjit/DOMJITCallDOMGetterSnippet.h: Renamed from Source/JavaScriptCore/domjit/DOMJITCallDOMGetterPatchpoint.h.
        (JSC::DOMJIT::CallDOMGetterSnippet::create):
        * domjit/DOMJITGetterSetter.h:
        * domjit/DOMJITSignature.h:
        * domjit/DOMJITValue.h: Removed.
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallDOMGetter):
        * ftl/FTLSnippetParams.cpp: Renamed from Source/JavaScriptCore/ftl/FTLDOMJITPatchpointParams.cpp.
        * ftl/FTLSnippetParams.h: Renamed from Source/JavaScriptCore/ftl/FTLDOMJITPatchpointParams.h.
        (JSC::FTL::SnippetParams::SnippetParams):
        * jit/Snippet.h: Renamed from Source/JavaScriptCore/domjit/DOMJITPatchpoint.h.
        (JSC::Snippet::create):
        (JSC::Snippet::setGenerator):
        (JSC::Snippet::generator):
        * jit/SnippetParams.h: Renamed from Source/JavaScriptCore/domjit/DOMJITPatchpointParams.h.
        (JSC::SnippetParams::~SnippetParams):
        (JSC::SnippetParams::Value::Value):
        (JSC::SnippetParams::Value::isGPR):
        (JSC::SnippetParams::Value::isFPR):
        (JSC::SnippetParams::Value::isJSValueRegs):
        (JSC::SnippetParams::Value::gpr):
        (JSC::SnippetParams::Value::fpr):
        (JSC::SnippetParams::Value::jsValueRegs):
        (JSC::SnippetParams::Value::reg):
        (JSC::SnippetParams::Value::value):
        (JSC::SnippetParams::SnippetParams):
        * jit/SnippetReg.h: Renamed from Source/JavaScriptCore/domjit/DOMJITReg.h.
        (JSC::SnippetReg::SnippetReg):
        * jit/SnippetSlowPathCalls.h: Renamed from Source/JavaScriptCore/domjit/DOMJITSlowPathCalls.h.
        * jsc.cpp:
        (WTF::DOMJITNode::checkSubClassSnippet):
        (WTF::DOMJITFunctionObject::checkSubClassSnippet):
        (WTF::DOMJITNode::checkSubClassPatchpoint): Deleted.
        (WTF::DOMJITFunctionObject::checkSubClassPatchpoint): Deleted.
        * runtime/ClassInfo.h:

2017-05-26  Keith Miller  <keith_miller@apple.com>

        REEGRESSION(r217459): testapi fails in JSExportTest's wrapperForNSObjectisObject().
        https://bugs.webkit.org/show_bug.cgi?id=172654

        Reviewed by Mark Lam.

        The test's intent is to assert that an exception has not been
        thrown (as indicated by the message string), but the test was
        erroneously checking for ! the right condition. This is now fixed.

        * API/tests/JSExportTests.mm:
        (wrapperForNSObjectisObject):

2017-05-26  Joseph Pecoraro  <pecoraro@apple.com>

        JSContext Inspector: Improve the reliability of automatically pausing in auto-attach
        https://bugs.webkit.org/show_bug.cgi?id=172664
        <rdar://problem/32362933>

        Reviewed by Matt Baker.

        Automatically pause on connection was triggering a pause before the
        frontend may have initialized. Often during frontend initialization
        the frontend may perform an action that clears the pause state requested
        by the developer. This change defers the pause until after the frontend
        has initialized, right before returning to the application's code.

        * inspector/remote/RemoteControllableTarget.h:
        * inspector/remote/RemoteInspectionTarget.h:
        * inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
        (Inspector::RemoteConnectionToTarget::setup):
        * inspector/remote/glib/RemoteConnectionToTargetGlib.cpp:
        (Inspector::RemoteConnectionToTarget::setup):
        * runtime/JSGlobalObjectDebuggable.cpp:
        (JSC::JSGlobalObjectDebuggable::connect):
        (JSC::JSGlobalObjectDebuggable::pause): Deleted.
        * runtime/JSGlobalObjectDebuggable.h:
        Pass an immediatelyPause boolean on to the controller. Remove
        the current path that invokes a pause before initialization.

        * inspector/JSGlobalObjectInspectorController.h:
        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::connectFrontend):
        (Inspector::JSGlobalObjectInspectorController::disconnectFrontend):
        Manage should immediately pause state.

        (Inspector::JSGlobalObjectInspectorController::frontendInitialized):
        (Inspector::JSGlobalObjectInspectorController::pause): Deleted.
        When initialized, trigger a pause if requested.

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

        Temporarily commenting out a JSExportTest test until webkit.org/b/172654 is fixed.
        https://bugs.webkit.org/show_bug.cgi?id=172655

        Reviewed by Saam Barati.

        * API/tests/JSExportTests.mm:
        (wrapperForNSObjectisObject):

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

        REGRESSION(216914): testCFStrings encounters an invalid ExecState callee pointer.
        https://bugs.webkit.org/show_bug.cgi?id=172651

        Reviewed by Saam Barati.

        This is because the assertion utility functions used in testCFStrings() expects
        to get the JSGlobalContextRef from the global context variable.  However,
        testCFStrings() creates its own JSGlobalContextRef but does not set the global
        context variable to it.

        The fix is to make testCFStrings() initialize the global context variable properly.

        * API/tests/testapi.c:
        (testCFStrings):

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

        Give ModuleProgram the same treatment that we did for ProgramCode in bug#167725
        https://bugs.webkit.org/show_bug.cgi?id=167805

        Reviewed by Saam Barati.

        Since ModuleProgramExecutable is executed only once, we can skip compiling
        code unreachable from the current program count. This can skip massive
        initialization code.

        We already do this for global code in bug#167725. This patch extends it to
        module code.

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::executeModuleProgram):
        * interpreter/Interpreter.h:
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * runtime/JSModuleRecord.cpp:
        (JSC::JSModuleRecord::evaluate):
        * runtime/JSModuleRecord.h:
        (JSC::JSModuleRecord::moduleProgramExecutable): Deleted.

2017-05-26  Oleksandr Skachkov  <gskachkov@gmail.com>

        Prevent async methods named 'function'
        https://bugs.webkit.org/show_bug.cgi?id=172598

        Reviewed by Mark Lam.

        Prevent async method named 'function' in class.
        Link to change in ecma262 specification
        https://github.com/tc39/ecma262/pull/884

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

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

        Unreviewed, build fix for GCC

        std::tuple does not have implicit constructor.
        Thus, we cannot use implicit construction with initializer brace.
        We should specify the name like `GetInst { }`.

        * bytecompiler/BytecodeGenerator.h:
        (JSC::StructureForInContext::addGetInst):

2017-05-25  Keith Miller  <keith_miller@apple.com>

        Cleanup tests after r217240
        https://bugs.webkit.org/show_bug.cgi?id=172466

        Reviewed by Mark Lam.

        I forgot to make my test an actual test. Also, remove second call runJSExportTests()

        * API/tests/JSExportTests.mm:
        (wrapperForNSObjectisObject):
        * API/tests/testapi.mm:
        (testObjectiveCAPIMain):

2017-05-25  Michael Saboff  <msaboff@apple.com>

        The default setting of Option::criticalGCMemoryThreshold is too high for iOS
        https://bugs.webkit.org/show_bug.cgi?id=172617

        Reviewed by Mark Lam.

        Reducing criticalGCMemoryThreshold to 0.80 eliminated jetsam on iOS devices
        when tested running JetStream.

        * runtime/Options.h:

2017-05-25  Saam Barati  <sbarati@apple.com>

        Our for-in optimization in the bytecode generator does its static analysis incorrectly
        https://bugs.webkit.org/show_bug.cgi?id=172532
        <rdar://problem/32369452>

        Reviewed by Mark Lam.

        Our static analysis for when a for-in induction variable
        is written to tried to its analysis as we generate
        bytecode. This has issues, since it does not account for
        the dynamic execution path of the program. Let's consider
        a program where our old analysis worked:
        
        ```
        for (let p in o) {
            o[p]; // We can transform this into a fast get_direct_pname
            p = 20;
            o[p]; // We cannot transform this since p has been changed.
        }
        ```
        
        However, our static analysis did not account for loops, which exist
        in JavaScript. e.g, it would incorrectly compile this program as:
        ```
        for (let p in o) {
            for (let i = 0; i < 20; ++i) {
                o[p]; // It transforms this to use get_direct_pname even though p will be over-written if we get here from the inner loop back edge!
                p = 20;
                o[p]; // We correctly do not transform this.
            } 
        }
        ```
        
        Because of this flaw, I've made the optimization more conservative.
        We now optimistically emit code for the optimized access. However,
        if a for-in context is *ever* invalidated, before we pop it off
        the stack, we rewrite the program's optimized accesses to no longer
        be optimized. To do this, each context keeps track of its optimized
        accesses.
        
        This patch also adds a new bytecode, op_nop, which is just a no-op.
        It was helpful to add this because reverting get_direct_pname to get_by_val
        will leave us with an extra instruction word because get_direct_pname is
        has a length of 7 where get_by_val has a length of 6. This leaves us with
        an extra slot that we fill with an op_nop.

        * bytecode/BytecodeDumper.cpp:
        (JSC::BytecodeDumper<Block>::dumpBytecode):
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitGetByVal):
        (JSC::BytecodeGenerator::popIndexedForInScope):
        (JSC::BytecodeGenerator::popStructureForInScope):
        (JSC::BytecodeGenerator::invalidateForInContextForLocal):
        (JSC::StructureForInContext::pop):
        (JSC::IndexedForInContext::pop):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::StructureForInContext::addGetInst):
        (JSC::IndexedForInContext::addGetInst):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_nop):
        * llint/LowLevelInterpreter.asm:

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

        ObjectToStringAdaptiveInferredPropertyValueWatchpoint should not reinstall itself nor handleFire if it's dying shortly.
        https://bugs.webkit.org/show_bug.cgi?id=172548
        <rdar://problem/31458393>

        Reviewed by Filip Pizlo.

        Consider the following scenario:

        1. A ObjectToStringAdaptiveInferredPropertyValueWatchpoint O1, watches for
           structure transitions, e.g. structure S2 transitioning to structure S3.
           In this case, O1 would be installed in S2's watchpoint set.
        2. When the structure transition happens, structure S2 will fire watchpoint O1.
        3. O1's handler will normally re-install itself in the watchpoint set of the new
           "transitioned to" structure S3.
        4. "Installation" here requires writing into the StructureRareData SD3 of the new
           structure S3.  If SD3 does not exist yet, the installation process will trigger
           the allocation of StructureRareData SD3.
        5. It is possible that the Structure S1, and StructureRareData SD1 that owns the
           ObjectToStringAdaptiveInferredPropertyValueWatchpoint O1 is no longer reachable
           by the GC, and therefore will be collected soon.
        6. The allocation of SD3 in (4) may trigger the sweeping of the StructureRareData
           SD1.  This, in turn, triggers the deletion of the
           ObjectToStringAdaptiveInferredPropertyValueWatchpoint O1.

        After O1 is deleted in (6) and SD3 is allocated in (4), execution continues in
        AdaptiveInferredPropertyValueWatchpointBase::fire() where O1 gets installed in
        structure S3's watchpoint set.  This is obviously incorrect because O1 is already
        deleted.  The result is that badness happens later when S3's watchpoint set fires
        its watchpoints and accesses the deleted O1.

        The fix is to enhance AdaptiveInferredPropertyValueWatchpointBase::fire() to
        check if "this" is still valid before proceeding to re-install itself or to
        invoke its handleFire() method.

        ObjectToStringAdaptiveInferredPropertyValueWatchpoint (which extends
        AdaptiveInferredPropertyValueWatchpointBase) will override its isValid() method,
        and return false its owner StructureRareData is no longer reachable by the GC.
        This ensures that it won't be deleted while it's installed to any watchpoint set.

        Additional considerations and notes:
        1. In the above, I talked about the ObjectToStringAdaptiveInferredPropertyValueWatchpoint
           being installed in watchpoint sets.  What actually happens is that
           ObjectToStringAdaptiveInferredPropertyValueWatchpoint has 2 members
           (m_structureWatchpoint and m_propertyWatchpoint) which may be installed in
           watchpoint sets.  The ObjectToStringAdaptiveInferredPropertyValueWatchpoint is
           not itself a Watchpoint object.

           But for brevity, in the above, I refer to the ObjectToStringAdaptiveInferredPropertyValueWatchpoint
           instead of its Watchpoint members.  The description of the issue is still
           accurate given the life-cycle of the Watchpoint members are embedded in the
           enclosing ObjectToStringAdaptiveInferredPropertyValueWatchpoint object, and
           hence, they share the same life-cycle.

        2. The top of AdaptiveInferredPropertyValueWatchpointBase::fire() removes its
           m_structureWatchpoint and m_propertyWatchpoint if they have been added to any
           watchpoint sets.  This is safe to do even if the owner StructureRareData is no
           longer reachable by the GC.

           This is because the only way we can get to AdaptiveInferredPropertyValueWatchpointBase::fire()
           is if its Watchpoint members are still installed in some watchpoint set that
           fired.  This means that the AdaptiveInferredPropertyValueWatchpointBase
           instance has not been deleted yet, because its destructor will automatically
           remove the Watchpoint members from any watchpoint sets.

        * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::isValid):
        * bytecode/AdaptiveInferredPropertyValueWatchpointBase.h:
        * heap/FreeList.cpp:
        (JSC::FreeList::contains):
        * heap/FreeList.h:
        * heap/HeapCell.h:
        * heap/HeapCellInlines.h:
        (JSC::HeapCell::isLive):
        * heap/MarkedAllocator.h:
        (JSC::MarkedAllocator::isFreeListedCell):
        * heap/MarkedBlock.h:
        * heap/MarkedBlockInlines.h:
        (JSC::MarkedBlock::Handle::isFreeListedCell):
        * runtime/StructureRareData.cpp:
        (JSC::ObjectToStringAdaptiveInferredPropertyValueWatchpoint::isValid):

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

        We should not mmap zero bytes for a memory in Wasm
        https://bugs.webkit.org/show_bug.cgi?id=172528
        <rdar://problem/32257076>

        Reviewed by Mark Lam.

        This patch fixes a bug where we would call into mmap with zero bytes
        when creating a slow WasmMemory with zero initial page size. This fix
        is simple: if we don't have any initial bytes, we just call the constructor
        in WasmMemory that's meant to handle this case.

        * wasm/WasmMemory.cpp:
        (JSC::Wasm::Memory::create):

2017-05-23  Brian Burg  <bburg@apple.com>

        REGRESSION(r217051): Automation sessions fail to complete bootstrap
        https://bugs.webkit.org/show_bug.cgi?id=172513
        <rdar://problem/32338354>

        Reviewed by Joseph Pecoraro.

        The changes to be more strict about typechecking messages were too strict.

        * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
        (Inspector::RemoteInspector::receivedSetupMessage):
        WIRAutomatically is an optional key in the setup message. In the relay, this key gets copied
        into an NSDictionary as NSNull if the key isn't present in a forwarded command.
        We need to revert NSNull values to nil, since it's valid to call [nil boolValue] but not
        [[NSNull null] boolValue]. We also need to allow for nil in the typecheck for this key.

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

        Remove dead ENABLE(FONT_LOAD_EVENTS) code
        https://bugs.webkit.org/show_bug.cgi?id=172517

        Rubber-stamped by Simon Fraser.

        * Configurations/FeatureDefines.xcconfig:

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

        CFGSimplificationPhase should not merge a block with itself
        https://bugs.webkit.org/show_bug.cgi?id=172508
        <rdar://problem/28424006>

        Reviewed by Keith Miller.

        CFGSimplificationPhase can run into or create IR that ends up with a
        block that has a Jump to itself, and no other predecessors. It should
        gracefully handle such IR. Before this patch, it would not. The only criteria
        for merging 'block' with 'targetBlock' used to be that 'targetBlock.predecessors.size() == 1'.
        The code is written in such a way that if we merge a block with itself, we
        will infinite loop until we run out of memory.
        
        Merging a block with itself does not make sense for a few reasons. First,
        we're joining the contents of two blocks. What is the definition of joining
        a block with itself? I suppose we could simply unroll this self loop
        one level, but that would not be wise because this self loop is by definition
        unreachable unless it's the root block in the graph (which I think is
        invalid IR since we'd never generate bytecode that would do this).
        
        This patch employs an easy fix: we can't merge a block with itself.

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

2017-05-22  Brian Burg  <bburg@apple.com>

        Web Inspector: webkit reload policy should match default behavior
        https://bugs.webkit.org/show_bug.cgi?id=171385
        <rdar://problem/31871515>

        Reviewed by Joseph Pecoraro.

        Add a new option to Page.reload that allows the test harness
        to reload its test page using the old reload behavior.

        The new behavior of revalidating expired cached subresources only
        is the current default, since only the test harness needs the old behavior.

        * inspector/protocol/Page.json:

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

        [Cocoa] An exported Objective C class’s prototype and constructor don't persist across JSContext deallocation
        https://bugs.webkit.org/show_bug.cgi?id=167708

        Reviewed by Geoffrey Garen.

        This patch moves the Objective C wrapper map to the global object. In order to make this work the JSWrapperMap
        class no longer holds a reference to the JSContext. Instead, the context must be provided when getting a wrapper.

        Also, this patch fixes a "bug" where we would observe changes to the Object property on the global object when
        creating a wrapper for NSObject.

        * API/APICast.h:
        (toJSGlobalObject):
        * API/JSContext.mm:
        (-[JSContext ensureWrapperMap]):
        (-[JSContext initWithVirtualMachine:]):
        (-[JSContext dealloc]):
        (-[JSContext wrapperMap]):
        (-[JSContext initWithGlobalContextRef:]):
        (-[JSContext wrapperForObjCObject:]):
        (-[JSContext wrapperForJSObject:]):
        * API/JSWrapperMap.h:
        * API/JSWrapperMap.mm:
        (-[JSObjCClassInfo initForClass:]):
        (-[JSObjCClassInfo allocateConstructorAndPrototypeInContext:]):
        (-[JSObjCClassInfo wrapperForObject:inContext:]):
        (-[JSObjCClassInfo constructorInContext:]):
        (-[JSObjCClassInfo prototypeInContext:]):
        (-[JSWrapperMap initWithGlobalContextRef:]):
        (-[JSWrapperMap classInfoForClass:]):
        (-[JSWrapperMap jsWrapperForObject:inContext:]):
        (-[JSWrapperMap objcWrapperForJSValueRef:inContext:]):
        (-[JSObjCClassInfo initWithContext:forClass:]): Deleted.
        (-[JSObjCClassInfo allocateConstructorAndPrototype]): Deleted.
        (-[JSObjCClassInfo wrapperForObject:]): Deleted.
        (-[JSObjCClassInfo constructor]): Deleted.
        (-[JSObjCClassInfo prototype]): Deleted.
        (-[JSWrapperMap initWithContext:]): Deleted.
        (-[JSWrapperMap jsWrapperForObject:]): Deleted.
        (-[JSWrapperMap objcWrapperForJSValueRef:]): Deleted.
        * API/tests/JSExportTests.mm:
        (wrapperLifetimeIsTiedToGlobalObject):
        (runJSExportTests):
        * API/tests/testapi.mm:
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::wrapperMap):
        (JSC::JSGlobalObject::setWrapperMap):

2017-05-22  Filip Pizlo  <fpizlo@apple.com>

        FTL stack overflow handling should not assume that B3 never selects callee-saves in the prologue
        https://bugs.webkit.org/show_bug.cgi?id=172455

        Reviewed by Mark Lam.
        
        The FTL needs to run B3's callee-save register restoration before it runs the exception
        handler's callee-save register restoration.  This exposes B3's callee-save register
        algorithm in AssemblyHelpers so that the FTL can call it.

        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::generate):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::lower): Fix the bug.
        * heap/Subspace.cpp: Added some debugging support.
        (JSC::Subspace::allocate):
        (JSC::Subspace::tryAllocate):
        (JSC::Subspace::didAllocate):
        * heap/Subspace.h:
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::addressFor):
        (JSC::AssemblyHelpers::emitSave):
        (JSC::AssemblyHelpers::emitRestore):

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

        [FTL] Support GetByVal with ArrayStorage and SlowPutArrayStorage
        https://bugs.webkit.org/show_bug.cgi?id=172216

        Reviewed by Saam Barati.

        This patch adds GetByVal support for ArrayStorage and SlowPutArrayStorage.
        To lower CheckInBounds in FTL, we add a new GetVectorLength op. It only accepts
        ArrayStorage and SlowPutArrayStorage, then it produces vector length.
        CheckInBounds uses this vector length to perform bound checking for ArrayStorage
        and SlowPutArrayStorage.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::permitsBoundsCheckLowering):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGHeapLocation.h:
        * dfg/DFGIntegerRangeOptimizationPhase.cpp:
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasArrayMode):
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSSALoweringPhase.cpp:
        (JSC::DFG::SSALoweringPhase::lowerBoundsCheck):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLAbstractHeapRepository.h:
        (JSC::FTL::AbstractHeapRepository::forIndexingType):
        (JSC::FTL::AbstractHeapRepository::forArrayType):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetVectorLength):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitArrayStoragePutByVal):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emitArrayStorageLoad):
        (JSC::JIT::emitArrayStoragePutByVal):

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

        We incorrectly throw a syntax error when declaring a top level for-loop iteration variable the same as a parameter
        https://bugs.webkit.org/show_bug.cgi?id=171041
        <rdar://problem/32082516>

        Reviewed by Yusuke Suzuki.

        We were treating a for-loop variable declaration potentially as a top
        level statement, e.g, in a program like this:
        ```
        function foo() {
            for (let variable of expr) { }
        }
        ```
        But we should not be. This had the consequence of making this type of program
        throw a syntax error:
        ```
        function foo(arg) {
            for (let arg of expr) { }
        }
        ```
        even though it should not. The fix is simple, we just need to increment the
        statement depth before parsing anything inside the for loop.

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

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

        [JSC] Make get_by_val & string "499" to number 499
        https://bugs.webkit.org/show_bug.cgi?id=172225

        Reviewed by Saam Barati.

        Property subscript will be converted by ToString. So JS code is not aware of
        the original type of the subscript value. But our get_by_val can leverage
        information if the given subscript is number. Thus, passing number instead of
        string can improve the performance of get_by_val in all the tiers.

        In this patch, we add BytecodeGenerator::emitNodeForProperty. It attempts to
        convert the given value to Int32 index constant if the given value is a string
        that can be converted to Int32.

        This patch improves SixSpeed map-string.es5 by 9.8x. This accessing form can
        appear in some code like accessing the result of JSON.

            map-string.es5     1640.6738+-110.9182   ^    167.4121+-23.8328       ^ definitely 9.8002x faster

        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::emitNodeForProperty):
        (JSC::BytecodeGenerator::emitNodeForLeftHandSideForProperty):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::TaggedTemplateNode::emitBytecode):
        (JSC::BracketAccessorNode::emitBytecode):
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_putByValDirect):
        (JSC::FunctionCallBracketNode::emitBytecode):
        (JSC::PostfixNode::emitBracket):
        (JSC::PrefixNode::emitBracket):
        (JSC::AssignBracketNode::emitBytecode):
        (JSC::ReadModifyBracketNode::emitBytecode):
        (JSC::ForInNode::emitLoopHeader):
        (JSC::ForOfNode::emitBytecode):
        (JSC::ObjectPatternNode::bindValue):
        (JSC::AssignmentElementNode::bindValue):

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

        We overwrite the callee save space on the stack when throwing stack overflow from wasm
        https://bugs.webkit.org/show_bug.cgi?id=172316

        Reviewed by Mark Lam.

        When throwing a stack overflow exception, the overflow
        thunk would do the following:
          move fp, sp
          populate argument registers
          call C code
        
        However, the C function is allowed to clobber our spilled
        callee saves that live below fp. The reason I did this move is that
        when we jump to this code, we've proven that sp is out of bounds on
        the stack. So we're not allowed to just use its value or keep growing
        the stack from that point. However, this patch revises this approach
        to be the same in spirit, but actually correct. We conservatively assume
        the B3 function we're coming from could have saved all callee saves.
        So we emit code like this now:
          add -maxNumCalleeSaveSpace, fp, sp
          populate argument registers
          call C code
        
        This ensures our callee saves will not be overwritten. Note
        that fp is still in a valid stack range here, since the thing
        calling the wasm code did a stack check. Also note that maxNumCalleeSaveSpace
        is less than our redzone size, so it's safe to decrement sp by 
        this amount.
        
        The previously added wasm stack overflow test is an instance crash
        without this change on arm64. It also appears that this test crashed
        on some other x86 devices.

        * wasm/WasmThunks.cpp:
        (JSC::Wasm::throwStackOverflowFromWasmThunkGenerator):

2017-05-20  Chris Dumez  <cdumez@apple.com>

        Drop [NoInterfaceObject] from RTCDTMFSender and RTCStatsReport
        https://bugs.webkit.org/show_bug.cgi?id=172418

        Reviewed by Youenn Fablet.

        Add CommonIdentifiers that are now needed.

        * runtime/CommonIdentifiers.h:

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

        Unreviewed, add scope.release() to propertyIsEnumerable functions.
        https://bugs.webkit.org/show_bug.cgi?id=172411

        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncPropertyIsEnumerable):
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncPropertyIsEnumerable):

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

        [JSC] Drop MapBase
        https://bugs.webkit.org/show_bug.cgi?id=172417

        Reviewed by Sam Weinig.

        MapBase is a purely additional indirection. JSMap and JSSet can directly inherit HashMapImpl.
        Thus MapBase is unnecessary. This patch drops it.
        It is good because we can eliminate one indirection when accessing to map implementation.
        Moreover, we can drop one unnecessary allocation per Map and Set.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucket):
        * runtime/HashMapImpl.cpp:
        (JSC::HashMapImpl<HashMapBucket>::estimatedSize):
        (JSC::getHashMapImplKeyClassInfo): Deleted.
        (JSC::getHashMapImplKeyValueClassInfo): Deleted.
        * runtime/HashMapImpl.h:
        (JSC::HashMapImpl::finishCreation):
        (JSC::HashMapImpl::get):
        (JSC::HashMapImpl::info): Deleted.
        (JSC::HashMapImpl::createStructure): Deleted.
        (JSC::HashMapImpl::create): Deleted.
        * runtime/JSMap.h:
        (JSC::JSMap::set):
        (JSC::JSMap::get): Deleted.
        * runtime/JSMapIterator.cpp:
        (JSC::JSMapIterator::finishCreation):
        * runtime/JSSet.h:
        (JSC::JSSet::add): Deleted.
        * runtime/JSSetIterator.cpp:
        (JSC::JSSetIterator::finishCreation):
        * runtime/MapBase.cpp: Removed.
        * runtime/MapBase.h: Removed.
        * runtime/MapPrototype.cpp:
        (JSC::mapProtoFuncSize):
        * runtime/SetConstructor.cpp:
        (JSC::constructSet):
        * runtime/SetPrototype.cpp:
        (JSC::setProtoFuncSize):
        * runtime/VM.cpp:
        (JSC::VM::VM):

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

        [JSC] Speedup Object.assign for slow case by using propertyIsEnumerable
        https://bugs.webkit.org/show_bug.cgi?id=172411

        Reviewed by Sam Weinig.

        We use @Reflect.@getOwnPropertyDescriptor() to check

        1. the descriptor exists,
        2. and the descriptor.enumrable is true

        But Object::propertyIsEnumerable does the completely same thing without
        allocating a new object for property descriptor.

        In this patch, we add a new private function @propertyIsEnumerable, and
        use it in Object.assign implementation. It does not allocate unnecessary
        objects. It is good for GC-pressure and performance.

        This patch improves SixSpeed object-assign.es6 by 1.7x. While this patch
        does not introduce a fast path for objects that do not have accessors,
        and it could speed up things further, this patch can speed up the common
        slow path cases that is the current implementation of Object.assign.

            object-assign.es6     1103.2487+-21.5602    ^    621.8478+-34.9875       ^ definitely 1.7741x faster

        * builtins/BuiltinNames.h:
        * builtins/ObjectConstructor.js:
        (globalPrivate.enumerableOwnProperties):
        (assign):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncPropertyIsEnumerable):
        * runtime/JSGlobalObjectFunctions.h:

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

        [JSC] Enable testapi on Mac CMake build
        https://bugs.webkit.org/show_bug.cgi?id=172354

        Reviewed by Alex Christensen.

        This patch makes testapi buildable and runnable for Mac CMake port.

        * API/tests/DateTests.mm:
        (+[DateTests JSDateToNSDateTest]):
        (+[DateTests roundTripThroughJSDateTest]):
        This test only works with the en_US locale.

        * shell/CMakeLists.txt:
        * shell/PlatformMac.cmake:
        Some of tests rely on ARC. We enable ARC for those files.

        * shell/PlatformWin.cmake:
        Clean up.

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

        [Re-landing] DFG::SpeculativeJIT::pickCanTrample() is wrongly ignoring result registers.
        https://bugs.webkit.org/show_bug.cgi?id=172383
        <rdar://problem/31418651>

        Reviewed by Filip Pizlo.

        pickCanTrample() is wrongly assuming that one of regT0 and regT1 is always
        available as a scratch register.  This assumption is wrong if this canTrample
        register is used for a silentFill() after an operation that returns a result in
        regT0 or regT1.

        Turns out the only reason we need the canTrample register is for
        SetDoubleConstant.  We can remove the need for this canTrample register by
        introducing a moveDouble() pseudo instruction in the MacroAssembler to do the
        job using the scratchRegister() on X86_64 or the dataMemoryTempRegister() on
        ARM64.  In so doing, we can simplify the silentFill() code and eliminate the bug.

        Update for re-landing: Changed ARM64 to use scratchRegister() as well.
        scratchRegister() is the proper way to get the underlying dataMemoryTempRegister()
        as a scratch register.

        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::moveDouble):
        * dfg/DFGArrayifySlowPathGenerator.h:
        * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
        (JSC::DFG::CallArrayAllocatorWithVariableStructureVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableStructureVariableSizeSlowPathGenerator):
        * dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h:
        * dfg/DFGSaneStringGetByValSlowPathGenerator.h:
        * dfg/DFGSlowPathGenerator.h:
        (JSC::DFG::CallSlowPathGenerator::tearDown):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::silentFill):
        (JSC::DFG::SpeculativeJIT::compileToLowerCase):
        (JSC::DFG::SpeculativeJIT::compileValueToInt32):
        (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
        (JSC::DFG::SpeculativeJIT::emitUntypedBitOp):
        (JSC::DFG::SpeculativeJIT::emitUntypedRightShiftBitOp):
        (JSC::DFG::SpeculativeJIT::compileArithDiv):
        (JSC::DFG::SpeculativeJIT::compileArraySlice):
        (JSC::DFG::SpeculativeJIT::emitSwitchImm):
        (JSC::DFG::SpeculativeJIT::emitSwitchStringOnString):
        (JSC::DFG::SpeculativeJIT::compileStoreBarrier):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::silentFill):
        (JSC::DFG::SpeculativeJIT::silentSpillAllRegisters):
        (JSC::DFG::SpeculativeJIT::silentFillAllRegisters):
        (JSC::DFG::SpeculativeJIT::pickCanTrample): Deleted.
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::convertAnyInt):

2017-05-19  Ryan Haddad  <ryanhaddad@apple.com>

        Unreviewed, rolling out r217156.

        This change broke the iOS build.

        Reverted changeset:

        "DFG::SpeculativeJIT::pickCanTrample() is wrongly ignoring
        result registers."
        https://bugs.webkit.org/show_bug.cgi?id=172383
        http://trac.webkit.org/changeset/217156

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

        Add missing exception check.
        https://bugs.webkit.org/show_bug.cgi?id=172346
        <rdar://problem/32289640>

        Reviewed by Geoffrey Garen.

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

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

        DFG::SpeculativeJIT::pickCanTrample() is wrongly ignoring result registers.
        https://bugs.webkit.org/show_bug.cgi?id=172383
        <rdar://problem/31418651>

        Reviewed by Filip Pizlo.

        pickCanTrample() is wrongly assuming that one of regT0 and regT1 is always
        available as a scratch register.  This assumption is wrong if this canTrample
        register is used for a silentFill() after an operation that returns a result in
        regT0 or regT1.

        Turns out the only reason we need the canTrample register is for
        SetDoubleConstant.  We can remove the need for this canTrample register by
        introducing a moveDouble() pseudo instruction in the MacroAssembler to do the
        job using the scratchRegister() on X86_64 or the dataMemoryTempRegister() on
        ARM64.  In so doing, we can simplify the silentFill() code and eliminate the bug.

        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::moveDouble):
        * dfg/DFGArrayifySlowPathGenerator.h:
        * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
        (JSC::DFG::CallArrayAllocatorWithVariableStructureVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableStructureVariableSizeSlowPathGenerator):
        * dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h:
        * dfg/DFGSaneStringGetByValSlowPathGenerator.h:
        * dfg/DFGSlowPathGenerator.h:
        (JSC::DFG::CallSlowPathGenerator::tearDown):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::silentFill):
        (JSC::DFG::SpeculativeJIT::compileToLowerCase):
        (JSC::DFG::SpeculativeJIT::compileValueToInt32):
        (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
        (JSC::DFG::SpeculativeJIT::emitUntypedBitOp):
        (JSC::DFG::SpeculativeJIT::emitUntypedRightShiftBitOp):
        (JSC::DFG::SpeculativeJIT::compileArithDiv):
        (JSC::DFG::SpeculativeJIT::compileArraySlice):
        (JSC::DFG::SpeculativeJIT::emitSwitchImm):
        (JSC::DFG::SpeculativeJIT::emitSwitchStringOnString):
        (JSC::DFG::SpeculativeJIT::compileStoreBarrier):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::silentFill):
        (JSC::DFG::SpeculativeJIT::silentSpillAllRegisters):
        (JSC::DFG::SpeculativeJIT::silentFillAllRegisters):
        (JSC::DFG::SpeculativeJIT::pickCanTrample): Deleted.
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::convertAnyInt):

2017-05-19  Filip Pizlo  <fpizlo@apple.com>

        Deduplicate some code in arrayProtoPrivateFuncConcatMemcpy
        https://bugs.webkit.org/show_bug.cgi?id=172382

        Reviewed by Saam Barati.
        
        This is just a small clean-up - my last patch here created some unnecessary code duplication.

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

2017-05-19  Filip Pizlo  <fpizlo@apple.com>

        arrayProtoPrivateFuncConcatMemcpy needs to be down with firstArray being undecided
        https://bugs.webkit.org/show_bug.cgi?id=172369

        Reviewed by Mark Lam.

        * heap/Subspace.cpp: Reshaped the code a bit to aid debugging.
        (JSC::Subspace::allocate):
        (JSC::Subspace::tryAllocate):
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoPrivateFuncConcatMemcpy): Fix the bug!
        * runtime/ObjectInitializationScope.cpp: Provide even better feedback.
        (JSC::ObjectInitializationScope::verifyPropertiesAreInitialized):

2017-05-18  Filip Pizlo  <fpizlo@apple.com>

        B3::Value::effects() says that having a fence range implies the fence bit, but on x86_64 we lower loadAcq/storeRel to load/store so the store-before-load fence bit orderings won't be honored
        https://bugs.webkit.org/show_bug.cgi?id=172306

        Reviewed by Michael Saboff.
        
        This changes B3 to emit xchg and its variants for fenced stores on x86. This ensures that
        fenced stores cannot be reordered around other fenced instructions. Previously, B3 emitted
        normal store instructions for fenced stores. That's wrong because then you get reorderings
        that are possible in TSO but impossible in SC. Fenced instructions are supposed to be SC
        with respect for each other.
        
        This is imprecise. If you really just wanted a store-release, then every X86 store does this.
        But, in B3, fenced stores are ARM-style store-release, meaning that they are fenced with
        respect to all other fences. If we ever did want to say that something is a store release in
        the traditional sense, then we'd want MemoryValue to have a fence flag. Then, having a fence
        range without the fence flag would mean the traditional store-release, which lowers to a
        normal store on x86. But to my knowledge, that traditional store-release is only useful for
        unlocking spinlocks. We don't use spinlocks in JSC. Adaptive locks require CAS for unlock,
        and B3 CAS is plenty fast. I think it's OK to have this small imprecision of giving clients
        an ARM-style store-release on x86 using xchg.
        
        The implication of this change is that the FTL no longer violates the SAB memory model.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::xchg8):
        (JSC::MacroAssemblerX86Common::xchg16):
        (JSC::MacroAssemblerX86Common::xchg32):
        (JSC::MacroAssemblerX86Common::loadAcq8): Deleted.
        (JSC::MacroAssemblerX86Common::loadAcq8SignedExtendTo32): Deleted.
        (JSC::MacroAssemblerX86Common::loadAcq16): Deleted.
        (JSC::MacroAssemblerX86Common::loadAcq16SignedExtendTo32): Deleted.
        (JSC::MacroAssemblerX86Common::loadAcq32): Deleted.
        (JSC::MacroAssemblerX86Common::storeRel8): Deleted.
        (JSC::MacroAssemblerX86Common::storeRel16): Deleted.
        (JSC::MacroAssemblerX86Common::storeRel32): Deleted.
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::xchg64):
        (JSC::MacroAssemblerX86_64::loadAcq64): Deleted.
        (JSC::MacroAssemblerX86_64::storeRel64): Deleted.
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::ArgPromise::inst):
        (JSC::B3::Air::LowerToAir::trappingInst):
        (JSC::B3::Air::LowerToAir::tryAppendStoreBinOp):
        (JSC::B3::Air::LowerToAir::createStore):
        (JSC::B3::Air::LowerToAir::storeOpcode):
        (JSC::B3::Air::LowerToAir::appendStore):
        (JSC::B3::Air::LowerToAir::append):
        (JSC::B3::Air::LowerToAir::appendTrapping):
        (JSC::B3::Air::LowerToAir::fillStackmap):
        (JSC::B3::Air::LowerToAir::lower):
        * b3/air/AirKind.cpp:
        (JSC::B3::Air::Kind::dump):
        * b3/air/AirKind.h:
        (JSC::B3::Air::Kind::Kind):
        (JSC::B3::Air::Kind::operator==):
        (JSC::B3::Air::Kind::hash):
        * b3/air/AirLowerAfterRegAlloc.cpp:
        (JSC::B3::Air::lowerAfterRegAlloc):
        * b3/air/AirLowerMacros.cpp:
        (JSC::B3::Air::lowerMacros):
        * b3/air/AirOpcode.opcodes:
        * b3/air/AirValidate.cpp:
        * b3/air/opcode_generator.rb:
        * b3/testb3.cpp:
        (JSC::B3::correctSqrt):
        (JSC::B3::testSqrtArg):
        (JSC::B3::testSqrtImm):
        (JSC::B3::testSqrtMem):
        (JSC::B3::testSqrtArgWithUselessDoubleConversion):
        (JSC::B3::testSqrtArgWithEffectfulDoubleConversion):
        (JSC::B3::testStoreRelAddLoadAcq32):
        (JSC::B3::testTrappingLoad):
        (JSC::B3::testTrappingStore):
        (JSC::B3::testTrappingLoadAddStore):
        (JSC::B3::testTrappingLoadDCE):

2017-05-19  Don Olmstead  <don.olmstead@am.sony.com>

        [JSC] Remove PLATFORM(WIN) references
        https://bugs.webkit.org/show_bug.cgi?id=172294

        Reviewed by Yusuke Suzuki.

        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::removeThread):
        * llint/LLIntOfflineAsmConfig.h:
        * runtime/ConfigFile.h:
        * runtime/VM.cpp:
        (JSC::VM::updateStackLimits):

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

        [JSC][DFG][DOMJIT] Extend CheckDOM to CheckSubClass
        https://bugs.webkit.org/show_bug.cgi?id=172098

        Reviewed by Saam Barati.

        In this patch, we generalize CheckDOM to CheckSubClass.
        It can accept any ClassInfo and perform ClassInfo check
        in DFG / FTL. Now, we add a new function pointer to ClassInfo,
        checkSubClassPatchpoint. It can create DOMJIT patchpoint
        for that ClassInfo. It it natural that ClassInfo holds the
        way to emit DOMJIT::Patchpoint to perform CheckSubClass
        rather than having it in each DOMJIT getter / function
        signature annotation.

        One problem is that it enlarges the size of ClassInfo.
        But this is the best place to put this function pointer.
        By doing so, we can add a patchpoint for CheckSubClass
        in an non-intrusive manner: WebCore can inject patchpoints
        without interactive JSC.

        We still have a way to reduce the size of ClassInfo if
        we move ArrayBuffer related methods out to the other places.

        This patch touches many files because we add a new function
        pointer to ClassInfo. But they are basically mechanical change.

        * API/JSAPIWrapperObject.mm:
        * API/JSCallbackConstructor.cpp:
        * API/JSCallbackFunction.cpp:
        * API/JSCallbackObject.cpp:
        * API/ObjCCallbackFunction.mm:
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        * bytecode/DOMJITAccessCasePatchpointParams.h:
        (JSC::DOMJITAccessCasePatchpointParams::DOMJITAccessCasePatchpointParams):
        * bytecode/EvalCodeBlock.cpp:
        * bytecode/FunctionCodeBlock.cpp:
        * bytecode/GetterSetterAccessCase.cpp:
        (JSC::GetterSetterAccessCase::emitDOMJITGetter):
        * bytecode/ModuleProgramCodeBlock.cpp:
        * bytecode/ProgramCodeBlock.cpp:
        * bytecode/UnlinkedCodeBlock.cpp:
        * bytecode/UnlinkedEvalCodeBlock.cpp:
        * bytecode/UnlinkedFunctionCodeBlock.cpp:
        * bytecode/UnlinkedFunctionExecutable.cpp:
        * bytecode/UnlinkedModuleProgramCodeBlock.cpp:
        * bytecode/UnlinkedProgramCodeBlock.cpp:
        * debugger/DebuggerScope.cpp:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleDOMJITGetter):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGDOMJITPatchpointParams.h:
        (JSC::DFG::DOMJITPatchpointParams::DOMJITPatchpointParams):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::attemptToMakeCallDOM):
        (JSC::DFG::FixupPhase::fixupCheckSubClass):
        (JSC::DFG::FixupPhase::fixupCheckDOM): Deleted.
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasClassInfo):
        (JSC::DFG::Node::classInfo):
        (JSC::DFG::Node::hasCheckDOMPatchpoint): Deleted.
        (JSC::DFG::Node::checkDOMPatchpoint): Deleted.
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCheckSubClass):
        (JSC::DFG::SpeculativeJIT::compileCheckDOM): Deleted.
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::vm):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * domjit/DOMJITGetterSetter.h:
        * domjit/DOMJITPatchpointParams.h:
        (JSC::DOMJIT::PatchpointParams::PatchpointParams):
        (JSC::DOMJIT::PatchpointParams::vm):
        * domjit/DOMJITSignature.h:
        (JSC::DOMJIT::Signature::Signature):
        (JSC::DOMJIT::Signature::checkDOM): Deleted.
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLDOMJITPatchpointParams.h:
        (JSC::FTL::DOMJITPatchpointParams::DOMJITPatchpointParams):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass):
        (JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM): Deleted.
        * inspector/JSInjectedScriptHost.cpp:
        * inspector/JSInjectedScriptHostPrototype.cpp:
        * inspector/JSJavaScriptCallFrame.cpp:
        * inspector/JSJavaScriptCallFramePrototype.cpp:
        * jsc.cpp:
        (WTF::DOMJITNode::checkSubClassPatchpoint):
        (WTF::DOMJITFunctionObject::checkSubClassPatchpoint):
        (WTF::DOMJITFunctionObject::finishCreation):
        (WTF::DOMJITCheckSubClassObject::DOMJITCheckSubClassObject):
        (WTF::DOMJITCheckSubClassObject::createStructure):
        (WTF::DOMJITCheckSubClassObject::create):
        (WTF::DOMJITCheckSubClassObject::safeFunction):
        (WTF::DOMJITCheckSubClassObject::unsafeFunction):
        (WTF::DOMJITCheckSubClassObject::finishCreation):
        (GlobalObject::finishCreation):
        (functionCreateDOMJITCheckSubClassObject):
        (WTF::DOMJITNode::checkDOMJITNode): Deleted.
        (WTF::DOMJITFunctionObject::checkDOMJITNode): Deleted.
        * runtime/AbstractModuleRecord.cpp:
        * runtime/ArrayBufferNeuteringWatchpoint.cpp:
        * runtime/ArrayConstructor.cpp:
        * runtime/ArrayIteratorPrototype.cpp:
        * runtime/ArrayPrototype.cpp:
        * runtime/AsyncFunctionConstructor.cpp:
        * runtime/AsyncFunctionPrototype.cpp:
        * runtime/AtomicsObject.cpp:
        * runtime/BooleanConstructor.cpp:
        * runtime/BooleanObject.cpp:
        * runtime/BooleanPrototype.cpp:
        * runtime/ClassInfo.cpp: Copied from Source/JavaScriptCore/tools/JSDollarVM.cpp.
        (JSC::ClassInfo::dump):
        * runtime/ClassInfo.h:
        (JSC::ClassInfo::offsetOfParentClass):
        * runtime/ClonedArguments.cpp:
        * runtime/ConsoleObject.cpp:
        * runtime/CustomGetterSetter.cpp:
        * runtime/DateConstructor.cpp:
        * runtime/DateInstance.cpp:
        * runtime/DatePrototype.cpp:
        * runtime/DirectArguments.cpp:
        * runtime/Error.cpp:
        * runtime/ErrorConstructor.cpp:
        * runtime/ErrorInstance.cpp:
        * runtime/ErrorPrototype.cpp:
        * runtime/EvalExecutable.cpp:
        * runtime/Exception.cpp:
        * runtime/ExceptionHelpers.cpp:
        * runtime/ExecutableBase.cpp:
        * runtime/FunctionConstructor.cpp:
        * runtime/FunctionExecutable.cpp:
        * runtime/FunctionPrototype.cpp:
        * runtime/FunctionRareData.cpp:
        * runtime/GeneratorFunctionConstructor.cpp:
        * runtime/GeneratorFunctionPrototype.cpp:
        * runtime/GeneratorPrototype.cpp:
        * runtime/GetterSetter.cpp:
        * runtime/HashMapImpl.cpp:
        * runtime/HashMapImpl.h:
        * runtime/InferredType.cpp:
        (JSC::InferredType::create):
        * runtime/InferredTypeTable.cpp:
        * runtime/InferredValue.cpp:
        * runtime/InspectorInstrumentationObject.cpp:
        * runtime/InternalFunction.cpp:
        * runtime/IntlCollator.cpp:
        * runtime/IntlCollatorConstructor.cpp:
        * runtime/IntlCollatorPrototype.cpp:
        * runtime/IntlDateTimeFormat.cpp:
        * runtime/IntlDateTimeFormatConstructor.cpp:
        * runtime/IntlDateTimeFormatPrototype.cpp:
        * runtime/IntlNumberFormat.cpp:
        * runtime/IntlNumberFormatConstructor.cpp:
        * runtime/IntlNumberFormatPrototype.cpp:
        * runtime/IntlObject.cpp:
        * runtime/IteratorPrototype.cpp:
        * runtime/JSAPIValueWrapper.cpp:
        * runtime/JSArray.cpp:
        * runtime/JSArrayBuffer.cpp:
        * runtime/JSArrayBufferConstructor.cpp:
        * runtime/JSArrayBufferPrototype.cpp:
        * runtime/JSArrayBufferView.cpp:
        * runtime/JSAsyncFunction.cpp:
        * runtime/JSBoundFunction.cpp:
        * runtime/JSCallee.cpp:
        * runtime/JSCustomGetterSetterFunction.cpp:
        * runtime/JSDataView.cpp:
        * runtime/JSDataViewPrototype.cpp:
        * runtime/JSEnvironmentRecord.cpp:
        * runtime/JSFixedArray.cpp:
        * runtime/JSFunction.cpp:
        * runtime/JSGeneratorFunction.cpp:
        * runtime/JSGlobalLexicalEnvironment.cpp:
        * runtime/JSGlobalObject.cpp:
        * runtime/JSInternalPromise.cpp:
        * runtime/JSInternalPromiseConstructor.cpp:
        * runtime/JSInternalPromiseDeferred.cpp:
        * runtime/JSInternalPromisePrototype.cpp:
        * runtime/JSLexicalEnvironment.cpp:
        * runtime/JSMap.cpp:
        * runtime/JSMapIterator.cpp:
        * runtime/JSModuleEnvironment.cpp:
        * runtime/JSModuleLoader.cpp:
        * runtime/JSModuleNamespaceObject.cpp:
        * runtime/JSModuleRecord.cpp:
        * runtime/JSNativeStdFunction.cpp:
        * runtime/JSONObject.cpp:
        * runtime/JSObject.cpp:
        * runtime/JSPromise.cpp:
        * runtime/JSPromiseConstructor.cpp:
        * runtime/JSPromiseDeferred.cpp:
        * runtime/JSPromisePrototype.cpp:
        * runtime/JSPropertyNameEnumerator.cpp:
        * runtime/JSPropertyNameIterator.cpp:
        * runtime/JSProxy.cpp:
        * runtime/JSScriptFetcher.cpp:
        * runtime/JSSet.cpp:
        * runtime/JSSetIterator.cpp:
        * runtime/JSSourceCode.cpp:
        * runtime/JSString.cpp:
        * runtime/JSStringIterator.cpp:
        * runtime/JSSymbolTableObject.cpp:
        * runtime/JSTemplateRegistryKey.cpp:
        * runtime/JSTypedArrayConstructors.cpp:
        * runtime/JSTypedArrayPrototypes.cpp:
        * runtime/JSTypedArrayViewConstructor.cpp:
        * runtime/JSTypedArrays.cpp:
        * runtime/JSWeakMap.cpp:
        * runtime/JSWeakSet.cpp:
        * runtime/JSWithScope.cpp:
        * runtime/MapConstructor.cpp:
        * runtime/MapIteratorPrototype.cpp:
        * runtime/MapPrototype.cpp:
        * runtime/MathObject.cpp:
        * runtime/ModuleLoaderPrototype.cpp:
        * runtime/ModuleProgramExecutable.cpp:
        * runtime/NativeErrorConstructor.cpp:
        * runtime/NativeExecutable.cpp:
        * runtime/NativeStdFunctionCell.cpp:
        * runtime/NullGetterFunction.cpp:
        * runtime/NullSetterFunction.cpp:
        * runtime/NumberConstructor.cpp:
        * runtime/NumberObject.cpp:
        * runtime/NumberPrototype.cpp:
        * runtime/ObjectConstructor.cpp:
        * runtime/ObjectPrototype.cpp:
        * runtime/ProgramExecutable.cpp:
        * runtime/PropertyTable.cpp:
        * runtime/ProxyConstructor.cpp:
        * runtime/ProxyObject.cpp:
        * runtime/ProxyRevoke.cpp:
        * runtime/ReflectObject.cpp:
        * runtime/RegExp.cpp:
        * runtime/RegExpConstructor.cpp:
        * runtime/RegExpObject.cpp:
        * runtime/RegExpPrototype.cpp:
        * runtime/ScopedArguments.cpp:
        * runtime/ScopedArgumentsTable.cpp:
        * runtime/ScriptExecutable.cpp:
        * runtime/SetConstructor.cpp:
        * runtime/SetIteratorPrototype.cpp:
        * runtime/SetPrototype.cpp:
        * runtime/SparseArrayValueMap.cpp:
        * runtime/StrictEvalActivation.cpp:
        * runtime/StringConstructor.cpp:
        * runtime/StringIteratorPrototype.cpp:
        * runtime/StringObject.cpp:
        * runtime/StringPrototype.cpp:
        * runtime/Structure.cpp:
        * runtime/StructureChain.cpp:
        * runtime/StructureRareData.cpp:
        * runtime/Symbol.cpp:
        * runtime/SymbolConstructor.cpp:
        * runtime/SymbolObject.cpp:
        * runtime/SymbolPrototype.cpp:
        * runtime/SymbolTable.cpp:
        * runtime/WeakMapConstructor.cpp:
        * runtime/WeakMapData.cpp:
        * runtime/WeakMapPrototype.cpp:
        * runtime/WeakSetConstructor.cpp:
        * runtime/WeakSetPrototype.cpp:
        * testRegExp.cpp:
        * tools/JSDollarVM.cpp:
        * tools/JSDollarVMPrototype.cpp:
        * wasm/JSWebAssembly.cpp:
        * wasm/js/JSWebAssemblyCodeBlock.cpp:
        * wasm/js/JSWebAssemblyCompileError.cpp:
        * wasm/js/JSWebAssemblyInstance.cpp:
        * wasm/js/JSWebAssemblyLinkError.cpp:
        * wasm/js/JSWebAssemblyMemory.cpp:
        * wasm/js/JSWebAssemblyModule.cpp:
        * wasm/js/JSWebAssemblyRuntimeError.cpp:
        * wasm/js/JSWebAssemblyTable.cpp:
        * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
        * wasm/js/WebAssemblyCompileErrorPrototype.cpp:
        * wasm/js/WebAssemblyFunction.cpp:
        * wasm/js/WebAssemblyFunctionBase.cpp:
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        * wasm/js/WebAssemblyInstancePrototype.cpp:
        * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
        * wasm/js/WebAssemblyLinkErrorPrototype.cpp:
        * wasm/js/WebAssemblyMemoryConstructor.cpp:
        * wasm/js/WebAssemblyMemoryPrototype.cpp:
        * wasm/js/WebAssemblyModuleConstructor.cpp:
        * wasm/js/WebAssemblyModulePrototype.cpp:
        * wasm/js/WebAssemblyModuleRecord.cpp:
        * wasm/js/WebAssemblyPrototype.cpp:
        * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
        * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
        * wasm/js/WebAssemblyTableConstructor.cpp:
        * wasm/js/WebAssemblyTablePrototype.cpp:
        * wasm/js/WebAssemblyToJSCallee.cpp:
        * wasm/js/WebAssemblyWrapperFunction.cpp:

2017-05-18  JF Bastien  <jfbastien@apple.com>

        WebAssembly: exports is a getter
        https://bugs.webkit.org/show_bug.cgi?id=172129

        Reviewed by Saam Barati.

        As updated here: https://github.com/WebAssembly/design/pull/1062

        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::finishCreation): don't putDirect here anymore
        * wasm/js/JSWebAssemblyInstance.h:
        (JSC::JSWebAssemblyInstance::moduleNamespaceObject): add accessor
        * wasm/js/WebAssemblyFunctionBase.cpp: squelch causing a warning
        * wasm/js/WebAssemblyInstancePrototype.cpp: use LUT
        (JSC::getInstance): helper, as in surrounding files
        (JSC::webAssemblyInstanceProtoFuncExports): instead of putDirect
        * wasm/js/WebAssemblyMemoryPrototype.cpp: pass VM around as for Table
        (JSC::getMemory):
        (JSC::webAssemblyMemoryProtoFuncGrow):
        (JSC::webAssemblyMemoryProtoFuncBuffer):
        * wasm/js/WebAssemblyTablePrototype.cpp: static everywhere as with other code
        (JSC::webAssemblyTableProtoFuncLength):
        (JSC::webAssemblyTableProtoFuncGrow):
        (JSC::webAssemblyTableProtoFuncGet):
        (JSC::webAssemblyTableProtoFuncSet):

2017-05-18  Saam Barati  <sbarati@apple.com>

        Proxy's [[Get]] passes incorrect receiver
        https://bugs.webkit.org/show_bug.cgi?id=164849
        <rdar://problem/31767058>

        Reviewed by Yusuke Suzuki.

        * runtime/ProxyObject.cpp:
        (JSC::performProxyGet):

2017-05-18  Andy Estes  <aestes@apple.com>

        ENABLE(APPLE_PAY_DELEGATE) should be NO on macOS Sierra and earlier
        https://bugs.webkit.org/show_bug.cgi?id=172305

        Reviewed by Anders Carlsson.

        * Configurations/FeatureDefines.xcconfig:

2017-05-18  Saam Barati  <sbarati@apple.com>

        We need to destroy worker threads in jsc.cpp
        https://bugs.webkit.org/show_bug.cgi?id=170751
        <rdar://problem/31800412>

        Reviewed by Filip Pizlo.

        This patch fixes a bug where a $ agent worker would still
        have compilation threads running after the thread the worker
        was created on dies. This manifested itself inside DFG AI where
        we would notice a string constant is atomic, then the worker
        thread would die, destroying its atomic string table, then
        we'd notice the same string is no longer atomic, and we'd crash
        because we'd fail to see the same speculated type for the same
        JSValue.
        
        This patch makes it so that $ agent workers destroy their VM when
        they're done executing. Before a VM gets destroyed, it ensures that
        all its compilation threads finish.

        * jsc.cpp:
        (functionDollarAgentStart):
        (runJSC):
        (jscmain):

2017-05-18  Michael Saboff  <msaboff@apple.com>

        Add FTL whitelist debugging option
        https://bugs.webkit.org/show_bug.cgi?id=172321

        Reviewed by Saam Barati.

        * dfg/DFGTierUpCheckInjectionPhase.cpp:
        (JSC::DFG::ensureGlobalFTLWhitelist):
        (JSC::DFG::TierUpCheckInjectionPhase::run):
        * runtime/Options.h:
        * tools/FunctionWhitelist.cpp:
        (JSC::FunctionWhitelist::contains):

2017-05-18  Filip Pizlo  <fpizlo@apple.com>

        Constructor calls set this too early
        https://bugs.webkit.org/show_bug.cgi?id=172302

        Reviewed by Saam Barati.
        
        We were setting this before evaluating the arguments, so this code:
        
            var x = 42;
            new x(x = function() { });
        
        Would crash because we would pass 42 as this, and create_this would treat it as a cell.
        Dereferencing a non-cell is guaranteed to crash.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitConstruct):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::NewExprNode::emitBytecode):
        (JSC::FunctionCallValueNode::emitBytecode):

2017-05-18  Saam Barati  <sbarati@apple.com>

        WebAssembly: perform stack checks
        https://bugs.webkit.org/show_bug.cgi?id=165546
        <rdar://problem/29760307>

        Reviewed by Filip Pizlo.

        This patch adds stack checks to wasm. It implements it by storing the stack
        bounds on the Context.
        
        Stack checking works as normal, except we do a small optimization for terminal
        nodes in the call tree (nodes that don't make any calls). These nodes will
        only do a stack check if their frame size is beyond 1024 bytes. Otherwise,
        it's assumed the parent that called them did their stack check for them.
        This is because all things that make calls make sure to do an extra 1024
        bytes whenever doing a stack check.
        
        We also take into account stack size for potential JS calls when doing
        stack checks since our JS stubs don't do this on their own. Each frame
        will ensure it does a stack check large enough for any potential JS call
        stubs it'll execute.
        
        Surprisingly, this patch is neutral on WasmBench and TitzerBench.

        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LowLevelInterpreter.asm:
        * runtime/Error.cpp:
        (JSC::createRangeError):
        (JSC::addErrorInfoAndGetBytecodeOffset):
        I fixed a bug here where we assumed that the first frame that has line
        and column info would be in our stack trace. This is not correct
        since we limit our stack trace size. If everything in our limited
        size stack trace is Wasm, then we won't have any frames with line
        and column info.
        * runtime/Error.h:
        * runtime/ExceptionHelpers.cpp:
        (JSC::createStackOverflowError):
        * runtime/ExceptionHelpers.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::webAssemblyToJSCalleeStructure):
        * runtime/JSType.h:
        * runtime/Options.h: I've added a new option that controls
        whether or not we use fast TLS for the wasm context.
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        * wasm/WasmBinding.cpp:
        (JSC::Wasm::wasmToWasm):
        * wasm/WasmContext.cpp:
        (JSC::Wasm::loadContext):
        (JSC::Wasm::storeContext):
        * wasm/WasmContext.h:
        (JSC::Wasm::useFastTLSForContext):
        * wasm/WasmExceptionType.h:
        * wasm/WasmMemoryInformation.h:
        (JSC::Wasm::PinnedRegisterInfo::toSave):
        * wasm/WasmThunks.cpp:
        (JSC::Wasm::throwExceptionFromWasmThunkGenerator):
        (JSC::Wasm::throwStackOverflowFromWasmThunkGenerator):
        (JSC::Wasm::Thunks::stub):
        * wasm/WasmThunks.h:
        * wasm/js/JSWebAssemblyInstance.h:
        (JSC::JSWebAssemblyInstance::offsetOfCachedStackLimit):
        (JSC::JSWebAssemblyInstance::cachedStackLimit):
        (JSC::JSWebAssemblyInstance::setCachedStackLimit):
        * wasm/js/JSWebAssemblyModule.cpp:
        (JSC::JSWebAssemblyModule::finishCreation):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction):
        * wasm/js/WebAssemblyToJSCallee.cpp: Make this a descendent of object.
        This is needed for correctness because we may call into JS,
        and then the first JS frame could stack overflow. When it stack
        overflows, it rolls back one frame to the wasm->js call stub with
        the wasm->js callee. It gets the lexical global object from this
        frame, meaning it gets the global object from the callee. Therefore,
        we must make it an object since all objects have global objects.
        (JSC::WebAssemblyToJSCallee::create):
        * wasm/js/WebAssemblyToJSCallee.h:

2017-05-18  Keith Miller  <keith_miller@apple.com>

        WebAssembly API: test with neutered inputs
        https://bugs.webkit.org/show_bug.cgi?id=163899

        Reviewed by JF Bastien.

        Add tests to check that we properly throw a type error when
        we get a transferred ArrayBuffer. Also, we should make sure
        we cannot post message a wasm memory's ArrayBuffer.

        * API/JSTypedArray.cpp:
        (JSObjectGetArrayBufferBytesPtr):
        * runtime/ArrayBuffer.cpp:
        (JSC::ArrayBuffer::makeShared):
        (JSC::ArrayBuffer::makeWasmMemory):
        (JSC::ArrayBuffer::transferTo):
        (JSC::ArrayBuffer::neuter):
        (JSC::ArrayBuffer::notifyIncommingReferencesOfTransfer):
        (JSC::errorMesasgeForTransfer):
        * runtime/ArrayBuffer.h:
        (JSC::ArrayBuffer::isLocked):
        (JSC::ArrayBuffer::isWasmMemory):
        * wasm/js/JSWebAssemblyMemory.cpp:
        (JSC::JSWebAssemblyMemory::buffer):
        (JSC::JSWebAssemblyMemory::grow):

2017-05-18  Joseph Pecoraro  <pecoraro@apple.com>

        Remote Inspector: Be stricter about checking message types
        https://bugs.webkit.org/show_bug.cgi?id=172259
        <rdar://problem/32264839>

        Reviewed by Brian Burg.

        * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
        (Inspector::RemoteInspector::receivedSetupMessage):
        (Inspector::RemoteInspector::receivedDataMessage):
        (Inspector::RemoteInspector::receivedDidCloseMessage):
        (Inspector::RemoteInspector::receivedIndicateMessage):
        (Inspector::RemoteInspector::receivedConnectionDiedMessage):
        (Inspector::RemoteInspector::receivedAutomaticInspectionConfigurationMessage):
        (Inspector::RemoteInspector::receivedAutomaticInspectionRejectMessage):
        (Inspector::RemoteInspector::receivedAutomationSessionRequestMessage):
        * inspector/remote/cocoa/RemoteInspectorXPCConnection.mm:
        (Inspector::RemoteInspectorXPCConnection::deserializeMessage):
        (Inspector::RemoteInspectorXPCConnection::handleEvent):
        (Inspector::RemoteInspectorXPCConnection::sendMessage):
        Bail if we don't receive the expected types for message data.

2017-05-18  Filip Pizlo  <fpizlo@apple.com>

        DFG inlining should be hardened for the no-result case
        https://bugs.webkit.org/show_bug.cgi?id=172290

        Reviewed by Saam Barati.
        
        Previously, if we were inlining a setter call, we might have a bad time because the setter's
        result register is the invalid VirtualRegister(), and much of the intrinsic handling code
        assumes that the result register is valid.
        
        This doesn't usually cause problems because people don't usually point a setter at something
        that we recognize as an intrinsic.
        
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp: Fix a comment.
        * dfg/DFGByteCodeParser.cpp: Make RELEASE_ASSERT give accurate stacks. I was getting an absurd stack from the assert I added in DelayedSetLocal.
        (JSC::DFG::ByteCodeParser::DelayedSetLocal::DelayedSetLocal): Assert so we catch the problem sooner.
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall): Fix the bug.
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction): Fix the bug if constant internal functions were setter-inlineable (they ain't, because the bytecode parser doesn't fold GetSetter).
        * runtime/Intrinsic.cpp: Added. I needed this to debug.
        (JSC::intrinsicName):
        (WTF::printInternal):
        * runtime/Intrinsic.h:

2017-05-18  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r217031, r217032, and r217037.
        https://bugs.webkit.org/show_bug.cgi?id=172293

        cause linking errors in Windows (Requested by yusukesuzuki on
        #webkit).

        Reverted changesets:

        "[JSC][DFG][DOMJIT] Extend CheckDOM to CheckSubClass"
        https://bugs.webkit.org/show_bug.cgi?id=172098
        http://trac.webkit.org/changeset/217031

        "Unreviewed, rebaseline for newly added ClassInfo"
        https://bugs.webkit.org/show_bug.cgi?id=172098
        http://trac.webkit.org/changeset/217032

        "Unreviewed, fix debug and non-JIT build"
        https://bugs.webkit.org/show_bug.cgi?id=172098
        http://trac.webkit.org/changeset/217037

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

        Unreviewed, fix debug and non-JIT build
        https://bugs.webkit.org/show_bug.cgi?id=172098

        * jsc.cpp:
        (WTF::DOMJITFunctionObject::checkSubClassPatchpoint):

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

        Unreviewed, rebaseline for newly added ClassInfo
        https://bugs.webkit.org/show_bug.cgi?id=172098

        * wasm/js/WebAssemblyFunctionBase.cpp:

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

        [JSC][DFG][DOMJIT] Extend CheckDOM to CheckSubClass
        https://bugs.webkit.org/show_bug.cgi?id=172098

        Reviewed by Saam Barati.

        In this patch, we generalize CheckDOM to CheckSubClass.
        It can accept any ClassInfo and perform ClassInfo check
        in DFG / FTL. Now, we add a new function pointer to ClassInfo,
        checkSubClassPatchpoint. It can create DOMJIT patchpoint
        for that ClassInfo. It it natural that ClassInfo holds the
        way to emit DOMJIT::Patchpoint to perform CheckSubClass
        rather than having it in each DOMJIT getter / function
        signature annotation.

        One problem is that it enlarges the size of ClassInfo.
        But this is the best place to put this function pointer.
        By doing so, we can add a patchpoint for CheckSubClass
        in an non-intrusive manner: WebCore can inject patchpoints
        without interactive JSC.

        We still have a way to reduce the size of ClassInfo if
        we move ArrayBuffer related methods out to the other places.

        This patch touches many files because we add a new function
        pointer to ClassInfo. But they are basically mechanical change.

        * API/JSAPIWrapperObject.mm:
        * API/JSCallbackConstructor.cpp:
        * API/JSCallbackFunction.cpp:
        * API/JSCallbackObject.cpp:
        * API/ObjCCallbackFunction.mm:
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        * bytecode/DOMJITAccessCasePatchpointParams.h:
        (JSC::DOMJITAccessCasePatchpointParams::DOMJITAccessCasePatchpointParams):
        * bytecode/EvalCodeBlock.cpp:
        * bytecode/FunctionCodeBlock.cpp:
        * bytecode/GetterSetterAccessCase.cpp:
        (JSC::GetterSetterAccessCase::emitDOMJITGetter):
        * bytecode/ModuleProgramCodeBlock.cpp:
        * bytecode/ProgramCodeBlock.cpp:
        * bytecode/UnlinkedCodeBlock.cpp:
        * bytecode/UnlinkedEvalCodeBlock.cpp:
        * bytecode/UnlinkedFunctionCodeBlock.cpp:
        * bytecode/UnlinkedFunctionExecutable.cpp:
        * bytecode/UnlinkedModuleProgramCodeBlock.cpp:
        * bytecode/UnlinkedProgramCodeBlock.cpp:
        * debugger/DebuggerScope.cpp:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleDOMJITGetter):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGDOMJITPatchpointParams.h:
        (JSC::DFG::DOMJITPatchpointParams::DOMJITPatchpointParams):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::attemptToMakeCallDOM):
        (JSC::DFG::FixupPhase::fixupCheckSubClass):
        (JSC::DFG::FixupPhase::fixupCheckDOM): Deleted.
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasClassInfo):
        (JSC::DFG::Node::classInfo):
        (JSC::DFG::Node::hasCheckDOMPatchpoint): Deleted.
        (JSC::DFG::Node::checkDOMPatchpoint): Deleted.
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCheckSubClass):
        (JSC::DFG::SpeculativeJIT::compileCheckDOM): Deleted.
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::vm):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        In DFG, we rename CheckDOM to CheckSubClass. It just holds ClassInfo.
        And ClassInfo knows how to perform CheckSubClass efficiently.
        If ClassInfo does not have a way to perform CheckSubClass efficiently,
        we just perform jsDynamicCast thing in ASM.
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * domjit/DOMJITGetterSetter.h:
        * domjit/DOMJITPatchpointParams.h:
        (JSC::DOMJIT::PatchpointParams::PatchpointParams):
        (JSC::DOMJIT::PatchpointParams::vm):
        * domjit/DOMJITSignature.h:
        (JSC::DOMJIT::Signature::Signature):
        (JSC::DOMJIT::Signature::checkDOM): Deleted.
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLDOMJITPatchpointParams.h:
        (JSC::FTL::DOMJITPatchpointParams::DOMJITPatchpointParams):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass):
        (JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM): Deleted.
        * inspector/JSInjectedScriptHost.cpp:
        * inspector/JSInjectedScriptHostPrototype.cpp:
        * inspector/JSJavaScriptCallFrame.cpp:
        * inspector/JSJavaScriptCallFramePrototype.cpp:
        * jsc.cpp:
        (WTF::DOMJITNode::checkSubClassPatchpoint):
        (WTF::DOMJITFunctionObject::checkSubClassPatchpoint):
        (WTF::DOMJITFunctionObject::finishCreation):
        (WTF::DOMJITCheckSubClassObject::DOMJITCheckSubClassObject):
        (WTF::DOMJITCheckSubClassObject::createStructure):
        (WTF::DOMJITCheckSubClassObject::create):
        (WTF::DOMJITCheckSubClassObject::safeFunction):
        (WTF::DOMJITCheckSubClassObject::unsafeFunction):
        (WTF::DOMJITCheckSubClassObject::finishCreation):
        (GlobalObject::finishCreation):
        (functionCreateDOMJITCheckSubClassObject):
        (WTF::DOMJITNode::checkDOMJITNode): Deleted.
        (WTF::DOMJITFunctionObject::checkDOMJITNode): Deleted.
        * runtime/AbstractModuleRecord.cpp:
        * runtime/ArrayBufferNeuteringWatchpoint.cpp:
        * runtime/ArrayConstructor.cpp:
        * runtime/ArrayIteratorPrototype.cpp:
        * runtime/ArrayPrototype.cpp:
        * runtime/AsyncFunctionConstructor.cpp:
        * runtime/AsyncFunctionPrototype.cpp:
        * runtime/AtomicsObject.cpp:
        * runtime/BooleanConstructor.cpp:
        * runtime/BooleanObject.cpp:
        * runtime/BooleanPrototype.cpp:
        * runtime/ClassInfo.cpp: Copied from Source/JavaScriptCore/tools/JSDollarVM.cpp.
        (JSC::ClassInfo::dump):
        * runtime/ClassInfo.h:
        (JSC::ClassInfo::offsetOfParentClass):
        * runtime/ClonedArguments.cpp:
        * runtime/ConsoleObject.cpp:
        * runtime/CustomGetterSetter.cpp:
        * runtime/DateConstructor.cpp:
        * runtime/DateInstance.cpp:
        * runtime/DatePrototype.cpp:
        * runtime/DirectArguments.cpp:
        * runtime/Error.cpp:
        * runtime/ErrorConstructor.cpp:
        * runtime/ErrorInstance.cpp:
        * runtime/ErrorPrototype.cpp:
        * runtime/EvalExecutable.cpp:
        * runtime/Exception.cpp:
        * runtime/ExceptionHelpers.cpp:
        * runtime/ExecutableBase.cpp:
        * runtime/FunctionConstructor.cpp:
        * runtime/FunctionExecutable.cpp:
        * runtime/FunctionPrototype.cpp:
        * runtime/FunctionRareData.cpp:
        * runtime/GeneratorFunctionConstructor.cpp:
        * runtime/GeneratorFunctionPrototype.cpp:
        * runtime/GeneratorPrototype.cpp:
        * runtime/GetterSetter.cpp:
        * runtime/HashMapImpl.cpp:
        * runtime/HashMapImpl.h:
        * runtime/InferredType.cpp:
        (JSC::InferredType::create):
        * runtime/InferredTypeTable.cpp:
        * runtime/InferredValue.cpp:
        * runtime/InspectorInstrumentationObject.cpp:
        * runtime/InternalFunction.cpp:
        * runtime/IntlCollator.cpp:
        * runtime/IntlCollatorConstructor.cpp:
        * runtime/IntlCollatorPrototype.cpp:
        * runtime/IntlDateTimeFormat.cpp:
        * runtime/IntlDateTimeFormatConstructor.cpp:
        * runtime/IntlDateTimeFormatPrototype.cpp:
        * runtime/IntlNumberFormat.cpp:
        * runtime/IntlNumberFormatConstructor.cpp:
        * runtime/IntlNumberFormatPrototype.cpp:
        * runtime/IntlObject.cpp:
        * runtime/IteratorPrototype.cpp:
        * runtime/JSAPIValueWrapper.cpp:
        * runtime/JSArray.cpp:
        * runtime/JSArrayBuffer.cpp:
        * runtime/JSArrayBufferConstructor.cpp:
        * runtime/JSArrayBufferPrototype.cpp:
        * runtime/JSArrayBufferView.cpp:
        * runtime/JSAsyncFunction.cpp:
        * runtime/JSBoundFunction.cpp:
        * runtime/JSCallee.cpp:
        * runtime/JSCustomGetterSetterFunction.cpp:
        * runtime/JSDataView.cpp:
        * runtime/JSDataViewPrototype.cpp:
        * runtime/JSEnvironmentRecord.cpp:
        * runtime/JSFixedArray.cpp:
        * runtime/JSFunction.cpp:
        * runtime/JSGeneratorFunction.cpp:
        * runtime/JSGlobalLexicalEnvironment.cpp:
        * runtime/JSGlobalObject.cpp:
        * runtime/JSInternalPromise.cpp:
        * runtime/JSInternalPromiseConstructor.cpp:
        * runtime/JSInternalPromiseDeferred.cpp:
        * runtime/JSInternalPromisePrototype.cpp:
        * runtime/JSLexicalEnvironment.cpp:
        * runtime/JSMap.cpp:
        * runtime/JSMapIterator.cpp:
        * runtime/JSModuleEnvironment.cpp:
        * runtime/JSModuleLoader.cpp:
        * runtime/JSModuleNamespaceObject.cpp:
        * runtime/JSModuleRecord.cpp:
        * runtime/JSNativeStdFunction.cpp:
        * runtime/JSONObject.cpp:
        * runtime/JSObject.cpp:
        * runtime/JSPromise.cpp:
        * runtime/JSPromiseConstructor.cpp:
        * runtime/JSPromiseDeferred.cpp:
        * runtime/JSPromisePrototype.cpp:
        * runtime/JSPropertyNameEnumerator.cpp:
        * runtime/JSPropertyNameIterator.cpp:
        * runtime/JSProxy.cpp:
        * runtime/JSScriptFetcher.cpp:
        * runtime/JSSet.cpp:
        * runtime/JSSetIterator.cpp:
        * runtime/JSSourceCode.cpp:
        * runtime/JSString.cpp:
        * runtime/JSStringIterator.cpp:
        * runtime/JSSymbolTableObject.cpp:
        * runtime/JSTemplateRegistryKey.cpp:
        * runtime/JSTypedArrayConstructors.cpp:
        * runtime/JSTypedArrayPrototypes.cpp:
        * runtime/JSTypedArrayViewConstructor.cpp:
        * runtime/JSTypedArrays.cpp:
        * runtime/JSWeakMap.cpp:
        * runtime/JSWeakSet.cpp:
        * runtime/JSWithScope.cpp:
        * runtime/MapConstructor.cpp:
        * runtime/MapIteratorPrototype.cpp:
        * runtime/MapPrototype.cpp:
        * runtime/MathObject.cpp:
        * runtime/ModuleLoaderPrototype.cpp:
        * runtime/ModuleProgramExecutable.cpp:
        * runtime/NativeErrorConstructor.cpp:
        * runtime/NativeExecutable.cpp:
        * runtime/NativeStdFunctionCell.cpp:
        * runtime/NullGetterFunction.cpp:
        * runtime/NullSetterFunction.cpp:
        * runtime/NumberConstructor.cpp:
        * runtime/NumberObject.cpp:
        * runtime/NumberPrototype.cpp:
        * runtime/ObjectConstructor.cpp:
        * runtime/ObjectPrototype.cpp:
        * runtime/ProgramExecutable.cpp:
        * runtime/PropertyTable.cpp:
        * runtime/ProxyConstructor.cpp:
        * runtime/ProxyObject.cpp:
        * runtime/ProxyRevoke.cpp:
        * runtime/ReflectObject.cpp:
        * runtime/RegExp.cpp:
        * runtime/RegExpConstructor.cpp:
        * runtime/RegExpObject.cpp:
        * runtime/RegExpPrototype.cpp:
        * runtime/ScopedArguments.cpp:
        * runtime/ScopedArgumentsTable.cpp:
        * runtime/ScriptExecutable.cpp:
        * runtime/SetConstructor.cpp:
        * runtime/SetIteratorPrototype.cpp:
        * runtime/SetPrototype.cpp:
        * runtime/SparseArrayValueMap.cpp:
        * runtime/StrictEvalActivation.cpp:
        * runtime/StringConstructor.cpp:
        * runtime/StringIteratorPrototype.cpp:
        * runtime/StringObject.cpp:
        * runtime/StringPrototype.cpp:
        * runtime/Structure.cpp:
        * runtime/StructureChain.cpp:
        * runtime/StructureRareData.cpp:
        * runtime/Symbol.cpp:
        * runtime/SymbolConstructor.cpp:
        * runtime/SymbolObject.cpp:
        * runtime/SymbolPrototype.cpp:
        * runtime/SymbolTable.cpp:
        * runtime/WeakMapConstructor.cpp:
        * runtime/WeakMapData.cpp:
        * runtime/WeakMapPrototype.cpp:
        * runtime/WeakSetConstructor.cpp:
        * runtime/WeakSetPrototype.cpp:
        * testRegExp.cpp:
        * tools/JSDollarVM.cpp:
        * tools/JSDollarVMPrototype.cpp:
        * wasm/JSWebAssembly.cpp:
        * wasm/js/JSWebAssemblyCodeBlock.cpp:
        * wasm/js/JSWebAssemblyCompileError.cpp:
        * wasm/js/JSWebAssemblyInstance.cpp:
        * wasm/js/JSWebAssemblyLinkError.cpp:
        * wasm/js/JSWebAssemblyMemory.cpp:
        * wasm/js/JSWebAssemblyModule.cpp:
        * wasm/js/JSWebAssemblyRuntimeError.cpp:
        * wasm/js/JSWebAssemblyTable.cpp:
        * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
        * wasm/js/WebAssemblyCompileErrorPrototype.cpp:
        * wasm/js/WebAssemblyFunction.cpp:
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        * wasm/js/WebAssemblyInstancePrototype.cpp:
        * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
        * wasm/js/WebAssemblyLinkErrorPrototype.cpp:
        * wasm/js/WebAssemblyMemoryConstructor.cpp:
        * wasm/js/WebAssemblyMemoryPrototype.cpp:
        * wasm/js/WebAssemblyModuleConstructor.cpp:
        * wasm/js/WebAssemblyModulePrototype.cpp:
        * wasm/js/WebAssemblyModuleRecord.cpp:
        * wasm/js/WebAssemblyPrototype.cpp:
        * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
        * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
        * wasm/js/WebAssemblyTableConstructor.cpp:
        * wasm/js/WebAssemblyTablePrototype.cpp:
        * wasm/js/WebAssemblyToJSCallee.cpp:
        * wasm/js/WebAssemblyWrapperFunction.cpp:

2017-05-17  Saam Barati  <sbarati@apple.com>

        We don't do context switches for Wasm->Wasm call indirect
        https://bugs.webkit.org/show_bug.cgi?id=172188
        <rdar://problem/32231828>

        Reviewed by Keith Miller.

        We did not do a context switch when doing an indirect call. 
        This is clearly wrong, since the thing we're making an indirect
        call to could be from another instance. This patch fixes this
        oversight by doing a very simple context switch. I've also opened
        a bug to make indirect calls fast: https://bugs.webkit.org/show_bug.cgi?id=172197
        since this patch adds yet another branch to the indirect call path.
        I've also added tests that either throw or crash before this change.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * wasm/WasmB3IRGenerator.cpp:
        * wasm/js/JSWebAssemblyTable.h:
        (JSC::JSWebAssemblyTable::offsetOfJSFunctions):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::WebAssemblyFunction::visitChildren):
        (JSC::WebAssemblyFunction::finishCreation): Deleted.
        * wasm/js/WebAssemblyFunction.h:
        (JSC::WebAssemblyFunction::instance): Deleted.
        (JSC::WebAssemblyFunction::offsetOfInstance): Deleted.
        * wasm/js/WebAssemblyFunctionBase.cpp: Added.
        (JSC::WebAssemblyFunctionBase::WebAssemblyFunctionBase):
        (JSC::WebAssemblyFunctionBase::visitChildren):
        (JSC::WebAssemblyFunctionBase::finishCreation):
        * wasm/js/WebAssemblyFunctionBase.h: Added.
        (JSC::WebAssemblyFunctionBase::instance):
        (JSC::WebAssemblyFunctionBase::offsetOfInstance):
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::link):
        (JSC::WebAssemblyModuleRecord::evaluate):
        * wasm/js/WebAssemblyWrapperFunction.cpp:
        (JSC::WebAssemblyWrapperFunction::create):
        (JSC::WebAssemblyWrapperFunction::finishCreation):
        (JSC::WebAssemblyWrapperFunction::visitChildren):
        * wasm/js/WebAssemblyWrapperFunction.h:

2017-05-17  Filip Pizlo  <fpizlo@apple.com>

        JSC: Incorrect LoadVarargs handling in ArgumentsEliminationPhase::transform
        https://bugs.webkit.org/show_bug.cgi?id=172208

        Reviewed by Saam Barati.

        * dfg/DFGArgumentsEliminationPhase.cpp:

2017-05-17  Don Olmstead  <don.olmstead@am.sony.com>

        [Win] Support $vm.getpid()
        https://bugs.webkit.org/show_bug.cgi?id=172248

        Reviewed by Mark Lam.

        * tools/JSDollarVMPrototype.cpp:
        (JSC::functionGetPID):
        (JSC::JSDollarVMPrototype::finishCreation):

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

        [iOS] The Garbage Collector shouldn't rely on the bmalloc scavenger for up to date memory footprint info
        https://bugs.webkit.org/show_bug.cgi?id=172186

        Reviewed by Geoffrey Garen.

        The calls to bmalloc::api::memoryFootprint() and ::percentAvailableMemoryInUse() now call
        the OS to get up to date values.  In overCriticalMemoryThreshold(), we get the current value every
        100th call and use a cached value the rest of the time.  When colleciton is done, we start with
        a new overCriticalMemoryThreshold value for the next cycle.

        The choice of 1 out of 100 calls was validated by using JetStream and verifying that it didn't impact
        performance and still provides timely memory footprint data.  With additional debug logging, I
        determined that we call overCriticalMemoryThreshold() over 20,000 times/second running JetStream.
        Other logging showed that there were over 1700 calls to overCriticalMemoryThreshold() on average per
        GC cycle.  Dividing both of these numbers by 100 seems reasonable.

        * heap/Heap.cpp:
        (JSC::Heap::overCriticalMemoryThreshold):
        (JSC::Heap::updateAllocationLimits):
        (JSC::Heap::shouldDoFullCollection):
        * heap/Heap.h:

2017-05-17  Saam Barati  <sbarati@apple.com>

        PinnedRegisters should be better modeled in IRC/Briggs
        https://bugs.webkit.org/show_bug.cgi?id=171955

        Reviewed by Filip Pizlo.

        This patch fixes a bug in Briggs/IRC with respect to pinned registers.
        Pinned registers were not part of the assignable register file in IRC/Briggs,
        and this would lead to an asymmetry because they were modeled in the
        interference graph. The bug is that we use registerCount() to move various
        Tmps between various lists in the different allocators, and if a Tmp
        interfered with a pinned register (usually via a Patchpoint's clobbered set),
        we'd have an interference edge modeled in the degree for that Tmp, but the registerCount()
        would make us think that this particular Tmp is not assignable. This would
        lead us to fail to color a colorable graph. Specifically, this happened in
        our various patchpoint tests that stress the register allocator by forcing
        the entire register file into arguments for the patchpoint and then doing
        interesting things with the result, arguments, etc.
        
        This patch fixes the bug by coming up with an more natural way to model pinned
        registers. Pinned registers are now part of the register file. However,
        pinned registers are live at every point in the program (this is a defining
        property of a pinned register). In practice, this means that the only Tmps 
        that can be assigned to pinned registers are ones that are coalescing
        candidates. This means the program has some number of defs for a Tmp T like:
        MoveType pinnedReg, T
        
        Note, if any other defs for T happen, like:
        Add32, t1, t2, T
        T will have an interference edge with pinnedReg, since pinnedReg is live
        at every point in the program. Modeling pinned registers this way allows
        IRC/Briggs to have no special casing for them. It treats it like any other
        precolored Tmp. This allows us to do coalescing, biased coloring, etc, which
        could all lead to a Tmp being assigned to a pinned register.
        
        Interestingly, we used to have special handling for the frame pointer
        register, which in many ways, acts like a pinned register, since FP is
        always live, and we wanted it to take place in coalescing. The allocator
        had a side-table interference graph with FP. Interestingly, we didn't even
        handle this properly everywhere since we could rely on a patchpoint never
        claiming to clobber FP (this would be illegal). So the code only handled
        the pseudo-pinned register properties of FP in various places. This patch
        drops this special casing and pins FP since all pinned registers can take
        part in coalescing.

        * b3/B3PatchpointSpecial.h:
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::mutableGPRs):
        (JSC::B3::Procedure::mutableFPRs):
        * b3/B3Procedure.h:
        * b3/air/AirAllocateRegistersByGraphColoring.cpp:
        * b3/air/AirCode.cpp:
        (JSC::B3::Air::Code::Code):
        (JSC::B3::Air::Code::pinRegister):
        (JSC::B3::Air::Code::mutableGPRs):
        (JSC::B3::Air::Code::mutableFPRs):
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::pinnedRegisters):
        * b3/air/AirSpecial.h:
        * b3/air/testair.cpp:
        * b3/testb3.cpp:
        (JSC::B3::testSimplePatchpointWithOuputClobbersGPArgs):
        (JSC::B3::testSpillDefSmallerThanUse):
        (JSC::B3::testLateRegister):
        (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled):
        (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled2):
        (JSC::B3::testMoveConstants):

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

        [DFG] Constant Folding Phase should convert MakeRope("", String) => Identity(String)
        https://bugs.webkit.org/show_bug.cgi?id=172115

        Reviewed by Saam Barati.

        In Fixup phase, we attempt to fold MakeRope to Identity (or reduce arguments) by dropping
        empty strings. However, when we are in Fixup phase, we do not have much information about
        constant values.

        In ARES-6 Babylon, we find that we can constant-fold MakeRope by using constants figured
        out by CFA. Without it, Babylon repeatedly produces rope strings. To fix this, we introduce
        MakeRope handling in constant folding phase.

        It shows 7.5% performance improvement in ARES-6 Babylon steadyState.

            Before:

            firstIteration:     50.02 +- 14.56 ms
            averageWorstCase:   26.52 +- 4.52 ms
            steadyState:        8.15 +- 0.23 ms

            After:

            firstIteration:     49.08 +- 12.90 ms
            averageWorstCase:   25.16 +- 3.82 ms
            steadyState:        7.58 +- 0.21 ms

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

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

        Unreviewed, add Objective C files to CMake Mac port
        https://bugs.webkit.org/show_bug.cgi?id=172103

        * shell/PlatformMac.cmake: Added.

2017-05-16  JF Bastien  <jfbastien@apple.com>

        WebAssembly: enforce size limits
        https://bugs.webkit.org/show_bug.cgi?id=165833
        <rdar://problem/29760219>

        Reviewed by Keith Miller.

        Use the same limits as V8.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * wasm/WasmLimits.h: Added.
        * wasm/WasmModuleParser.cpp:
        * wasm/WasmParser.h:
        (JSC::Wasm::Parser<SuccessType>::consumeUTF8String):

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

        [JSC] Build testapi in non Apple ports
        https://bugs.webkit.org/show_bug.cgi?id=172103

        Reviewed by Filip Pizlo.

        This patch makes JSC testapi buildable in non-Apple ports.
        We isolate CF related tests in testapi.c. If we do not use
        CF, we include JavaScript.h instead of JavaScriptCore.h.

        By running the testapi in Linux, we found that contraints
        test have a bug: If constraint marker runs after WeakRefs
        are destroyed, it accesses destroyed WeakRef. This patch
        also fixes it.

        * API/tests/CurrentThisInsideBlockGetterTest.h:
        * API/tests/CustomGlobalObjectClassTest.c:
        * API/tests/ExecutionTimeLimitTest.cpp:
        * API/tests/FunctionOverridesTest.cpp:
        * API/tests/GlobalContextWithFinalizerTest.cpp:
        * API/tests/JSObjectGetProxyTargetTest.cpp:
        * API/tests/MultithreadedMultiVMExecutionTest.cpp:
        * API/tests/PingPongStackOverflowTest.cpp:
        * API/tests/TypedArrayCTest.cpp:
        * API/tests/testapi.c:
        (assertEqualsAsCharactersPtr):
        (markingConstraint):
        (testMarkingConstraintsAndHeapFinalizers):
        (testCFStrings):
        (main):
        * shell/CMakeLists.txt:

2017-05-16  JF Bastien  <jfbastien@apple.com>

        WebAssembly: report Memory usage to GC
        https://bugs.webkit.org/show_bug.cgi?id=170690
        <rdar://problem/31965310>

        Reviewed by Keith Miller.

        * wasm/js/JSWebAssemblyMemory.cpp:
        (JSC::JSWebAssemblyMemory::grow):
        (JSC::JSWebAssemblyMemory::finishCreation):
        (JSC::JSWebAssemblyMemory::visitChildren):

2017-05-16  JF Bastien  <jfbastien@apple.com>

        WebAssembly: validate load / store alignment
        https://bugs.webkit.org/show_bug.cgi?id=168836
        <rdar://problem/31965349>

        Reviewed by Keith Miller.

        * wasm/WasmFunctionParser.h: check the alignment
        * wasm/generateWasm.py: generate the log2 alignment helper
        (Wasm):
        (isSimple):
        (memoryLog2Alignment):
        * wasm/generateWasmOpsHeader.py:
        (memoryLog2AlignmentGenerator):
        * wasm/wasm.json: fix formatting

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

        Rolling out r214038 and r213697: Crashes when using computed properties with rest destructuring and object spread.
        https://bugs.webkit.org/show_bug.cgi?id=172147

        Rubber-stamped by Saam Barati.

        I rolled out every thing in those 2 patches except for the change to make
        CodeBlock::finishCreation() return a bool plus its clients that depend on this.
        I made this exception because r214931 relies on this change, and this part of
        the change looks correct.

        * builtins/BuiltinNames.h:
        * builtins/GlobalOperations.js:
        (globalPrivate.speciesConstructor):
        (globalPrivate.copyDataProperties): Deleted.
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::setConstantIdentifierSetRegisters): Deleted.
        * bytecode/CodeBlock.h:
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::addBitVector):
        (JSC::UnlinkedCodeBlock::constantRegisters):
        (JSC::UnlinkedCodeBlock::addSetConstant): Deleted.
        (JSC::UnlinkedCodeBlock::constantIdentifierSets): Deleted.
        * bytecompiler/BytecodeGenerator.cpp:
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::PropertyListNode::emitBytecode):
        (JSC::ObjectPatternNode::bindValue):
        (JSC::ObjectSpreadExpressionNode::emitBytecode): Deleted.
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createProperty):
        (JSC::ASTBuilder::appendObjectPatternEntry):
        (JSC::ASTBuilder::createObjectSpreadExpression): Deleted.
        (JSC::ASTBuilder::appendObjectPatternRestEntry): Deleted.
        (JSC::ASTBuilder::setContainsObjectRestElement): Deleted.
        * parser/NodeConstructors.h:
        (JSC::PropertyNode::PropertyNode):
        (JSC::SpreadExpressionNode::SpreadExpressionNode):
        (JSC::ObjectSpreadExpressionNode::ObjectSpreadExpressionNode): Deleted.
        * parser/Nodes.h:
        (JSC::ObjectPatternNode::appendEntry):
        (JSC::ObjectSpreadExpressionNode::expression): Deleted.
        (JSC::ObjectPatternNode::setContainsRestElement): Deleted.
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseDestructuringPattern):
        (JSC::Parser<LexerType>::parseProperty):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createSpreadExpression):
        (JSC::SyntaxChecker::createProperty):
        (JSC::SyntaxChecker::operatorStackPop):
        (JSC::SyntaxChecker::createObjectSpreadExpression): Deleted.
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructor::finishCreation):
        * runtime/SetPrototype.cpp:
        (JSC::SetPrototype::finishCreation):

2017-05-15  David Kilzer  <ddkilzer@apple.com>

        JSEnvironmentRecord::allocationSizeForScopeSize() and offsetOfVariable(ScopeOffset) should used checked arithmetic
        <https://webkit.org/b/172134>

        Reviewed by Saam Barati.

        * runtime/JSEnvironmentRecord.h:
        (JSC::JSEnvironmentRecord::offsetOfVariable): Change to return
        size_t and use checked arithmetic.
        (JSC::JSEnvironmentRecord::allocationSizeForScopeSize): Change
        to use checked arithmetic.

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

        WorkerRunLoop::Task::performTask() should check !scriptController->isTerminatingExecution().
        https://bugs.webkit.org/show_bug.cgi?id=171775
        <rdar://problem/30975761>

        Reviewed by Filip Pizlo.

        Increased the number of frames captured in VM::nativeStackTraceOfLastThrow()
        from 25 to 100.  From experience, I found that 25 is sometimes not sufficient
        for our debugging needs.

        Also added VM::throwingThread() to track which thread an exception was thrown in.
        This may be useful if the client is entering the VM from different threads.

        * runtime/ExceptionScope.cpp:
        (JSC::ExceptionScope::unexpectedExceptionMessage):
        * runtime/ExceptionScope.h:
        (JSC::ExceptionScope::exception):
        (JSC::ExceptionScope::unexpectedExceptionMessage):
        * runtime/Options.h:
        - Added the unexpectedExceptionStackTraceLimit option.
        * runtime/VM.cpp:
        (JSC::VM::throwException):
        * runtime/VM.h:
        (JSC::VM::throwingThread):
        (JSC::VM::clearException):

2017-05-13  David Kilzer  <ddkilzer@apple.com>

        Unused lambda capture in JSContextGroupAddMarkingConstraint()
        <https://webkit.org/b/172084>

        Reviewed by Saam Barati.

        Fixes the following warning with newer clang:

            Source/JavaScriptCore/API/JSMarkingConstraintPrivate.cpp:78:11: error: lambda capture 'vm' is not used [-Werror,-Wunused-lambda-capture]
                    [&vm, constraintCallback, userData]
                      ^

        * API/JSMarkingConstraintPrivate.cpp:
        (JSContextGroupAddMarkingConstraint): Remove unused lambda
        capture for '&vm'.

2017-05-13  David Kilzer  <ddkilzer@apple.com>

        [JSC] config.rb fails when checking some clang versions
        <https://webkit.org/b/172082>

        Reviewed by Mark Lam.

        * offlineasm/config.rb:
        - Add support for quad-dotted version of Apple clang (800.0.12.1).
        - Add support for checking open source clang version (5.0.0).

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

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

        caused lldb to hang when debugging (Requested by smfr on
        #webkit).

        Reverted changeset:

        "Use Mach exceptions instead of signals where possible"
        https://bugs.webkit.org/show_bug.cgi?id=171865
        http://trac.webkit.org/changeset/216808

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

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

        Many memory corruption crashes on worker threads (Requested by
        ap on #webkit).

        Reverted changeset:

        "WorkerRunLoop::Task::performTask() should check
        !scriptController->isTerminatingExecution()."
        https://bugs.webkit.org/show_bug.cgi?id=171775
        http://trac.webkit.org/changeset/216801

2017-05-12  Geoffrey Garen  <ggaren@apple.com>

        [JSC] DFG::Node should not have its own allocator
        https://bugs.webkit.org/show_bug.cgi?id=160098

        Reviewed by Saam Barati.

        I just rebased the patch from <http://trac.webkit.org/changeset/203808>.

        I ran Octane and JetStream locally on a MacBook Air and I wasn't able to
        reproduce a regression. Let's land this again and see what the bots say.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3SparseCollection.h:
        (JSC::B3::SparseCollection::packIndices):
        * dfg/DFGAllocator.h: Removed.
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compileImpl):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::Graph):
        (JSC::DFG::Graph::~Graph):
        (JSC::DFG::Graph::deleteNode):
        (JSC::DFG::Graph::packNodeIndices):
        (JSC::DFG::Graph::addNodeToMapByIndex): Deleted.
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::addNode):
        (JSC::DFG::Graph::maxNodeCount):
        (JSC::DFG::Graph::nodeAt):
        * dfg/DFGLongLivedState.cpp: Removed.
        * dfg/DFGLongLivedState.h: Removed.
        * dfg/DFGNode.h:
        * dfg/DFGNodeAllocator.h:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThread):
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGPlan.h:
        * dfg/DFGWorklist.cpp:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2017-05-12  Keith Miller  <keith_miller@apple.com>

        Use Mach exceptions instead of signals where possible
        https://bugs.webkit.org/show_bug.cgi?id=171865

        Reviewed by Mark Lam.

        This patch adds some new JSC options. The first is an option that
        enables or disables web assembly tier up. The second controls
        whether or not we use mach exceptions (where available).

        * API/tests/ExecutionTimeLimitTest.cpp:
        (dispatchTermitateCallback):
        (testExecutionTimeLimit):
        * runtime/JSLock.cpp:
        (JSC::JSLock::didAcquireLock):
        * runtime/Options.cpp:
        (JSC::overrideDefaults):
        (JSC::Options::initialize):
        * runtime/Options.h:
        * runtime/VMTraps.cpp:
        (JSC::SignalContext::SignalContext):
        (JSC::SignalContext::adjustPCToPointToTrappingInstruction):
        (JSC::installSignalHandler):
        (JSC::VMTraps::SignalSender::send):
        * tools/SigillCrashAnalyzer.cpp:
        (JSC::SignalContext::SignalContext):
        (JSC::SignalContext::dump):
        (JSC::installCrashHandler):
        * wasm/WasmBBQPlan.cpp:
        (JSC::Wasm::BBQPlan::compileFunctions):
        * wasm/WasmFaultSignalHandler.cpp:
        (JSC::Wasm::trapHandler):
        (JSC::Wasm::enableFastMemory):
        * wasm/WasmMachineThreads.cpp:
        (JSC::Wasm::resetInstructionCacheOnAllThreads):

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

        WorkerRunLoop::Task::performTask() should check !scriptController->isTerminatingExecution().
        https://bugs.webkit.org/show_bug.cgi?id=171775
        <rdar://problem/30975761>

        Reviewed by Saam Barati.

        Increased the number of frames captured in VM::nativeStackTraceOfLastThrow()
        from 25 to 100.  From experience, I found that 25 is sometimes not sufficient
        for our debugging needs.

        Also added VM::throwingThread() to track which thread an exception was thrown in.
        This may be useful if the client is entering the VM from different threads.

        * runtime/ExceptionScope.cpp:
        (JSC::ExceptionScope::unexpectedExceptionMessage):
        * runtime/ExceptionScope.h:
        (JSC::ExceptionScope::exception):
        (JSC::ExceptionScope::unexpectedExceptionMessage):
        * runtime/Options.h:
        - Added the unexpectedExceptionStackTraceLimit option.
        * runtime/VM.cpp:
        (JSC::VM::throwException):
        * runtime/VM.h:
        (JSC::VM::throwingThread):
        (JSC::VM::clearException):

2017-05-12  Daniel Bates  <dabates@apple.com>

        Cleanup: Make QueueTaskToEventLoopFunctionPtr take JSGlobalObject&
        https://bugs.webkit.org/show_bug.cgi?id=172021

        Reviewed by Mark Lam.

        Change the function alias for QueueTaskToEventLoopFunctionPtr to take JSGlobalObject&
        instead of a const JSGlobalObject* as all implementations expect to be passed a non-
        const, non-null JSGlobalObject object.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::queueMicrotask):
        * runtime/JSGlobalObject.h:
        * runtime/VM.cpp:
        (JSC::VM::queueMicrotask):
        * runtime/VM.h: Remove JS_EXPORT_PRIVATE annotation from queueMicrotask() as
        it is only called from JavaScriptCore code.

2017-05-12  Michael Saboff  <msaboff@apple.com>

        [iOS] Use memory footprint to dynamically adjust behavior of allocators
        https://bugs.webkit.org/show_bug.cgi?id=171944

        Reviewed by Filip Pizlo.

        This change is iOS only.

        Added the ability to react to when memory usage is critical.  This is defined as memory
        usage being above the newly added option criticalGCMemoryThreshold.  When we are in this
        critical state, all collections are Full and we limit the amount of memory we allocate
        between collections to 1/4th the memory above the critical threshold.

        Changed the calculation of proportionalHeapSize to be based on process memory footprint
        and not how big the heap is.  Also, the values of Options::smallHeapRAMFraction and
        Options::mediumHeapRAMFraction are overriden so that most of the heap growth is happens
        using the more agressive Options::smallHeapGrowthFactor.

        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::overCriticalMemoryThreshold):
        (JSC::Heap::shouldDoFullCollection):
        (JSC::Heap::collectIfNecessaryOrDefer):
        * heap/Heap.h:
        * runtime/Options.cpp:
        (JSC::overrideDefaults):
        (JSC::Options::initialize):
        * runtime/Options.h:

2017-05-11  Saam Barati  <sbarati@apple.com>

        Computing optionalDefArgWidth in CheckSpecial should not consider Scratch roles
        https://bugs.webkit.org/show_bug.cgi?id=171962

        Reviewed by Filip Pizlo.

        The purpose of getting the result width is to get the width of
        the result of the arithmetic. It does not care about that the
        Check happens to define scratches.

        * b3/B3CheckSpecial.cpp:
        (JSC::B3::CheckSpecial::forEachArg):
        * b3/testb3.cpp:
        (JSC::B3::testCheckMul):
        (JSC::B3::testCheckMulMemory):
        (JSC::B3::testCheckMul64):
        (JSC::B3::testCheckMulFold):
        (JSC::B3::testCheckMulFoldFail):
        (JSC::B3::testCheckMulArgumentAliasing64):
        (JSC::B3::testCheckMulArgumentAliasing32):
        (JSC::B3::testCheckMul64SShr):

2017-05-11  Saam Barati  <sbarati@apple.com>

        isValidForm for SimpleAddr should use ptr() instead of tmp()
        https://bugs.webkit.org/show_bug.cgi?id=171992

        Reviewed by Filip Pizlo.

        Arg::tmp() asserts that its kind is Tmp. Inst::isValidForm for
        SimpleAddr was using Arg::tmp() instead of ptr() to check
        if the address Tmp isGP(). It should be using Arg::ptr() instead
        of Arg::tmp() since Arg::ptr() is designed for SimpleAddr.
        
        This patch also fixes an incorrect assertion in the ARM64
        macro assembler. We were asserting various atomic ops were
        only over 32/64 bit operations. However, the code was properly handling
        8/16/32/64 bit ops. I changed the assertion to reflect what is
        actually going on.

        * assembler/ARM64Assembler.h:
        (JSC::ARM64Assembler::ldar):
        (JSC::ARM64Assembler::ldxr):
        (JSC::ARM64Assembler::ldaxr):
        (JSC::ARM64Assembler::stxr):
        (JSC::ARM64Assembler::stlr):
        (JSC::ARM64Assembler::stlxr):
        * 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::testAtomicWeakCAS):
        (JSC::B3::testAtomicStrongCAS):
        (JSC::B3::testAtomicXchg):

2017-05-11  Matt Lewis  <jlewis3@apple.com>

        Unreviewed, rolling out r216677.

        Patch caused layout test crashes.

        Reverted changeset:

        "WorkerThread::stop() should call
        scheduleExecutionTermination() last."
        https://bugs.webkit.org/show_bug.cgi?id=171775
        http://trac.webkit.org/changeset/216677

2017-05-11  Don Olmstead  <don.olmstead@am.sony.com>

        [CMake] Add HAVE check for regex.h
        https://bugs.webkit.org/show_bug.cgi?id=171950

        Reviewed by Michael Catanzaro.

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

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

        Callers of JSString::unsafeView() should check exceptions
        https://bugs.webkit.org/show_bug.cgi?id=171995

        Reviewed by Mark Lam.
        
        unsafeView() can throw OOME. So, callers of unsafeView() should check for exceptions before trying
        to access the view.

        Also, I made the functions surrounding unsafeView() take ExecState* not ExecState&, to comply with
        the rest of JSC.

        * dfg/DFGOperations.cpp:
        * jsc.cpp:
        (printInternal):
        (functionDebug):
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncJoin):
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * runtime/IntlCollatorPrototype.cpp:
        (JSC::IntlCollatorFuncCompare):
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewProtoFuncJoin):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncParseFloat):
        * runtime/JSONObject.cpp:
        (JSC::JSONProtoFuncParse):
        * runtime/JSString.cpp:
        (JSC::JSString::getPrimitiveNumber):
        (JSC::JSString::toNumber):
        * runtime/JSString.h:
        (JSC::JSString::getIndex):
        (JSC::JSRopeString::unsafeView):
        (JSC::JSRopeString::viewWithUnderlyingString):
        (JSC::JSString::unsafeView):
        (JSC::JSString::viewWithUnderlyingString):
        * runtime/JSStringJoiner.h:
        (JSC::JSStringJoiner::appendWithoutSideEffects):
        (JSC::JSStringJoiner::append):
        * runtime/ParseInt.h:
        (JSC::toStringView):
        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncRepeatCharacter):
        (JSC::stringProtoFuncCharAt):
        (JSC::stringProtoFuncCharCodeAt):
        (JSC::stringProtoFuncIndexOf):
        (JSC::stringProtoFuncNormalize):

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

        Offer SPI to notify clients that GC has happened
        https://bugs.webkit.org/show_bug.cgi?id=171980

        Reviewed by Geoffrey Garen.
        
        Sometimes when you're programming with weak references, it's most convenient if the GC tells
        you when it finishes. This adds exactly such an API. This API is called at the *flip*: the
        moment when the GC knows for sure which objects are dead and has definitely not allocated any
        new objects or executed any JS code. The finalization part of the flip, which is where this
        callback gets called, runs on the "main" thread - i.e. some thread that is attempting to
        execute JS code and holds the JS lock. This will usually run as a side-effect of some
        allocation or from the runloop.
        
        This means, for example, that if you implemented a vector of weak references and registered a
        callback to prune the vector of null weak references, then aside from the callback, nobody
        would ever see a null weak reference in the vector.

        * API/JSHeapFinalizerPrivate.cpp: Added.
        (JSContextGroupAddHeapFinalizer):
        (JSContextGroupRemoveHeapFinalizer):
        * API/JSHeapFinalizerPrivate.h: Added.
        * API/tests/testapi.c:
        (heapFinalizer):
        (testMarkingConstraintsAndHeapFinalizers):
        (main):
        (testMarkingConstraints): Deleted.
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/Heap.cpp:
        (JSC::Heap::finalize):
        (JSC::Heap::addHeapFinalizerCallback):
        (JSC::Heap::removeHeapFinalizerCallback):
        * heap/Heap.h:
        * heap/HeapFinalizerCallback.cpp: Added.
        (JSC::HeapFinalizerCallback::dump):
        * heap/HeapFinalizerCallback.h: Added.
        (JSC::HeapFinalizerCallback::HeapFinalizerCallback):
        (JSC::HeapFinalizerCallback::operator==):
        (JSC::HeapFinalizerCallback::operator!=):
        (JSC::HeapFinalizerCallback::operator bool):
        (JSC::HeapFinalizerCallback::run):

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

        JSWeakCreate/Retain/Release should take a JSContextGroupRef and not a JSContextRef
        https://bugs.webkit.org/show_bug.cgi?id=171979

        Reviewed by Mark Lam.
        
        Functions that don't execute arbitrary JS but just need access to the VM should take a
        JSContextGroupRef, not a JSContextRef.

        * API/JSWeakPrivate.cpp:
        (JSWeakCreate):
        (JSWeakRetain):
        (JSWeakRelease):
        * API/JSWeakPrivate.h:
        * API/tests/testapi.c:
        (testMarkingConstraints):

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

        WorkerThread::stop() should call scheduleExecutionTermination() last.
        https://bugs.webkit.org/show_bug.cgi?id=171775
        <rdar://problem/30975761>

        Reviewed by Geoffrey Garen.

        Increased the number of frames captured in VM::nativeStackTraceOfLastThrow()
        from 25 to 100.  From experience, I found that 25 is sometimes not sufficient
        for our debugging needs.

        Also added VM::throwingThread() to track which thread an exception was thrown in.
        This may be useful if the client is entering the VM from different threads.

        * runtime/ExceptionScope.cpp:
        (JSC::ExceptionScope::unexpectedExceptionMessage):
        (JSC::ExceptionScope::releaseAssertIsTerminatedExecutionException):
        * runtime/ExceptionScope.h:
        (JSC::ExceptionScope::exception):
        (JSC::ExceptionScope::unexpectedExceptionMessage):
        * runtime/VM.cpp:
        (JSC::VM::throwException):
        * runtime/VM.h:
        (JSC::VM::throwingThread):
        (JSC::VM::clearException):

2017-05-11  JF Bastien  <jfbastien@apple.com>

        WebAssembly: stop supporting 0xD
        https://bugs.webkit.org/show_bug.cgi?id=168788
        <rdar://problem/31880922>

        Reviewed by Saam Barati.

        Only version 1 is supported by other browsers, and there shouldn't
        be any 0xD binaries in the wild anymore.

        * wasm/WasmModuleParser.cpp:

2017-05-09  Sam Weinig  <sam@webkit.org>

        Remove support for legacy Notifications
        https://bugs.webkit.org/show_bug.cgi?id=171487

        Reviewed by Jon Lee.

        * Configurations/FeatureDefines.xcconfig:
        Remove definition of ENABLE_LEGACY_NOTIFICATIONS.

2017-05-10  Commit Queue  <commit-queue@webkit.org>

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

        "Some worker tests are failing". (Requested by mlam on #webkit).

        Reverted changeset:

        "WorkerThread::stop() should call
        scheduleExecutionTermination() last."
        https://bugs.webkit.org/show_bug.cgi?id=171775
        http://trac.webkit.org/changeset/216635

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

        Crash in JavaScriptCore GC when using JSC on dispatch queues (thread_get_state returns NULL stack pointer).
        https://bugs.webkit.org/show_bug.cgi?id=160337
        <rdar://problem/27611733>

        Not reviewed.

        Updated a comment per Geoff's suggestion.

        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::tryCopyOtherThreadStack):

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

        WorkerThread::stop() should call scheduleExecutionTermination() last.
        https://bugs.webkit.org/show_bug.cgi?id=171775
        <rdar://problem/30975761>

        Reviewed by Geoffrey Garen.

        Increased the number of frames captured in VM::nativeStackTraceOfLastThrow()
        from 25 to 100.  From experience, I found that 25 is sometimes not sufficient
        for our debugging needs.

        Also added VM::throwingThread() to track which thread an exception was thrown in.
        This may be useful if the client is entering the VM from different threads.

        * runtime/ExceptionScope.cpp:
        (JSC::ExceptionScope::unexpectedExceptionMessage):
        (JSC::ExceptionScope::releaseAssertIsTerminatedExecutionException):
        * runtime/ExceptionScope.h:
        (JSC::ExceptionScope::exception):
        (JSC::ExceptionScope::unexpectedExceptionMessage):
        * runtime/VM.cpp:
        (JSC::VM::throwException):
        * runtime/VM.h:
        (JSC::VM::throwingThread):
        (JSC::VM::clearException):

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

        Crash in JavaScriptCore GC when using JSC on dispatch queues (thread_get_state returns NULL stack pointer).
        https://bugs.webkit.org/show_bug.cgi?id=160337
        <rdar://problem/27611733>

        Reviewed by Filip Pizlo and Geoffrey Garen.

        This is a workaround for <rdar://problem/27607384>. During thread initialization,
        for some target platforms, thread state is momentarily set to 0 before being
        filled in with the target thread's real register values. As a result, there's
        a race condition that may result in us getting a null stackPointer during a GC scan.
        This issue may manifest with workqueue threads where the OS may choose to recycle
        a thread for an expired task.

        The workaround is simply to indicate that there's nothing to copy and return.
        This is correct because we will only ever observe a null pointer during thread
        initialization. Hence, by definition, there's nothing there that we need to scan
        yet, and therefore, nothing that needs to be copied.

        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::tryCopyOtherThreadStack):

2017-05-10  JF Bastien  <jfbastien@apple.com>

        WebAssembly: support name section

        https://bugs.webkit.org/show_bug.cgi?id=171263

        Reviewed by Keith Miller.

        The name section is an optional custom section in the WebAssembly
        spec. At least when debugging, developers expect to be able to use
        this section to obtain intelligible stack traces, otherwise we
        just number the wasm functions which is somewhat painful.

        This patch parses this section, dropping its content eagerly on
        error, and if there is a name section then backtraces use their
        value instead of numbers. Otherwise we stick to numbers as before.

        Note that the format of name sections changed in mid-February:
          https://github.com/WebAssembly/design/pull/984
        And binaryen was only updated in early March:
          https://github.com/WebAssembly/binaryen/pull/933

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * interpreter/Interpreter.cpp:
        (JSC::GetStackTraceFunctor::operator()):
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::readNonInlinedFrame):
        (JSC::StackVisitor::Frame::functionName):
        * interpreter/StackVisitor.h:
        (JSC::StackVisitor::Frame::wasmFunctionIndexOrName):
        * runtime/StackFrame.cpp:
        (JSC::StackFrame::functionName):
        * runtime/StackFrame.h:
        (JSC::StackFrame::StackFrame):
        (JSC::StackFrame::wasm):
        * wasm/WasmBBQPlanInlines.h:
        (JSC::Wasm::BBQPlan::initializeCallees):
        * wasm/WasmCallee.cpp:
        (JSC::Wasm::Callee::Callee):
        * wasm/WasmCallee.h:
        (JSC::Wasm::Callee::create):
        (JSC::Wasm::Callee::indexOrName):
        * wasm/WasmFormat.cpp:
        (JSC::Wasm::makeString):
        * wasm/WasmFormat.h:
        (JSC::Wasm::isValidExternalKind):
        (JSC::Wasm::isValidNameType):
        (JSC::Wasm::NameSection::get):
        * wasm/WasmIndexOrName.cpp: Copied from Source/JavaScriptCore/wasm/WasmCallee.cpp.
        (JSC::Wasm::IndexOrName::IndexOrName):
        (JSC::Wasm::makeString):
        * wasm/WasmIndexOrName.h: Copied from Source/JavaScriptCore/wasm/WasmFormat.cpp.
        * wasm/WasmModuleInformation.h:
        * wasm/WasmModuleParser.cpp:
        * wasm/WasmName.h: Copied from Source/JavaScriptCore/wasm/WasmCallee.cpp.
        * wasm/WasmNameSectionParser.cpp: Added.
        * wasm/WasmNameSectionParser.h: Copied from Source/JavaScriptCore/wasm/WasmCallee.cpp.
        (JSC::Wasm::NameSectionParser::NameSectionParser):
        * wasm/WasmOMGPlan.cpp:
        (JSC::Wasm::OMGPlan::work):
        * wasm/WasmParser.h:
        (JSC::Wasm::Parser<SuccessType>::consumeUTF8String):

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

        Null pointer dereference in WTF::RefPtr<WTF::StringImpl>::operator!() under slow_path_get_direct_pname
        https://bugs.webkit.org/show_bug.cgi?id=171801

        Reviewed by Michael Saboff.
        
        This was a goofy oversight. The for-in optimization relies on the bytecode generator
        to detect when the loop's index variable gets mutated. We forgot to have the hooks for
        detecting this in prefix and postfix operations (++i and i++).

        * bytecompiler/NodesCodegen.cpp:
        (JSC::PostfixNode::emitResolve):
        (JSC::PrefixNode::emitResolve):

2017-05-10  Michael Catanzaro  <mcatanzaro@igalia.com>

        [GTK] -Wmissing-field-initializers triggered by RemoteInspectorServer.cpp:128
        https://bugs.webkit.org/show_bug.cgi?id=171273

        Reviewed by Carlos Garcia Campos.

        * inspector/remote/glib/RemoteInspectorGlib.cpp:
        * inspector/remote/glib/RemoteInspectorServer.cpp:

2017-05-10  Adrian Perez de Castro  <aperez@igalia.com>

        Remove some last remnants of the EFL port
        https://bugs.webkit.org/show_bug.cgi?id=171922

        Reviewed by Antonio Gomes.

        The EFL port is no more.

        * PlatformEfl.cmake: Removed.
        * shell/PlatformEfl.cmake: Removed.

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

        JSInjectedScriptHost should get a copy of the boundArgs
        https://bugs.webkit.org/show_bug.cgi?id=171897

        Reviewed by Joseph Pecoraro.
        
        The boundArgs array is very special - it cannot be mutated in any way. So, it makes sense
        for the inspector to get a copy of it.

        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::getInternalProperties):
        * runtime/JSBoundFunction.cpp:
        (JSC::JSBoundFunction::boundArgsCopy):
        * runtime/JSBoundFunction.h:
        (JSC::JSBoundFunction::boundArgs):

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

        Unindent some code in Watchdog::shouldTerminate().
        https://bugs.webkit.org/show_bug.cgi?id=171896

        Rubber stamped by Keith Miller.

        I should have done this before I landed r213107, but I forgot.  Unindenting it now.

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

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

        Cap the number of FTL compilation threads on iOS to 2
        https://bugs.webkit.org/show_bug.cgi?id=171887

        Reviewed by Filip Pizlo.

        Set an iOS specific max of 2 threads.

        * runtime/Options.h:

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

        Heap::heap() should behave gracefully for null pointers
        https://bugs.webkit.org/show_bug.cgi?id=171888
        <rdar://problem/32005315>

        Reviewed by Mark Lam.
        
        Some callers of Heap::heap() can pass a null cell and they will behave gracefully if we
        return a null Heap. So, let's do that.
        
        This fixes a crash and it does not hurt performance. I'm seeing a possible 0.5% regression
        with 74% probability. That's a neutral result by our usual 95% standard.

        * heap/HeapInlines.h:
        (JSC::Heap::heap):

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

        Handle IDLPromise<> properly
        https://bugs.webkit.org/show_bug.cgi?id=166752

        Reviewed by Youenn Fablet.

        Add JSPromise::resolve static function.
        This applies `Promise.resolve()` conversion to a given value.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::promiseResolveFunction):
        * runtime/JSPromise.cpp:
        (JSC::JSPromise::resolve):
        * runtime/JSPromise.h:

2017-05-09  Zan Dobersek  <zdobersek@igalia.com>

        Upstream the WPE port
        https://bugs.webkit.org/show_bug.cgi?id=171110

        Reviewed by Alex Christensen.

        * PlatformWPE.cmake: Added.
        * shell/PlatformWPE.cmake: Added.

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

        CallLinkInfos belonging to Wasm->JS stubs need to be informed when we clearCode() from all Executables
        https://bugs.webkit.org/show_bug.cgi?id=171707
        <rdar://problem/31891649>

        Reviewed by Filip Pizlo.

        This patch fixes a bug where a Wasm->JS IC call stub would go stale
        and point into a CodeBlock no longer owned by any executable. The
        problematic scenario is this:

        1. We generate the call IC which has a branch on a callee check. This
           callee owns the Executable in question. If the branch succeeds, it
           will call code belonging to a particular CodeBlock associated with
           that Executable.

        2. Heap::deleteAllCodeBlocks is called. This leads the Executable to clear
           its various CodeBlock references.

        3. Wasm has no idea this happened, so now it has stale ICs that point into
           code from a CodeBlock no longer belonging to an Executable.

        This patch fixes the bug by informing all JSWebAssemblyCodeBlocks to unlink
        their CallLinkInfo when Heap::deleteAllCodeBlocks is called.

        We track all JSWebAssemblyCodeBlocks by creating a new subspace for them.
        This allows us to quickly iterate over the live JSWebAssemblyCodeBlocks in the
        heap.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/Heap.cpp:
        (JSC::Heap::deleteAllCodeBlocks):
        * heap/Subspace.h:
        * heap/SubspaceInlines.h:
        (JSC::Subspace::forEachLiveCell):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        * wasm/js/JSWebAssemblyCodeBlock.cpp:
        (JSC::JSWebAssemblyCodeBlock::clearJSCallICs):
        * wasm/js/JSWebAssemblyCodeBlock.h:
        (JSC::JSWebAssemblyCodeBlock::createStructure): Deleted.
        (JSC::JSWebAssemblyCodeBlock::functionImportCount): Deleted.
        (JSC::JSWebAssemblyCodeBlock::module): Deleted.
        (JSC::JSWebAssemblyCodeBlock::jsEntrypointCalleeFromFunctionIndexSpace): Deleted.
        (JSC::JSWebAssemblyCodeBlock::wasmEntrypointLoadLocationFromFunctionIndexSpace): Deleted.
        (JSC::JSWebAssemblyCodeBlock::wasmToJsCallStubForImport): Deleted.
        (JSC::JSWebAssemblyCodeBlock::offsetOfImportWasmToJSStub): Deleted.
        (JSC::JSWebAssemblyCodeBlock::codeBlock): Deleted.
        (JSC::JSWebAssemblyCodeBlock::offsetOfImportStubs): Deleted.
        (JSC::JSWebAssemblyCodeBlock::allocationSize): Deleted.
        (JSC::JSWebAssemblyCodeBlock::importWasmToJSStub): Deleted.
        * wasm/js/JSWebAssemblyCodeBlockSubspace.cpp: Added.
        (JSC::JSWebAssemblyCodeBlockSubspace::JSWebAssemblyCodeBlockSubspace):
        (JSC::JSWebAssemblyCodeBlockSubspace::~JSWebAssemblyCodeBlockSubspace):
        (JSC::JSWebAssemblyCodeBlockSubspace::finishSweep):
        (JSC::JSWebAssemblyCodeBlockSubspace::destroy):
        * wasm/js/JSWebAssemblyCodeBlockSubspace.h: Added.

2017-05-08  Saam Barati  <sbarati@apple.com>

        testWasmBoundsCheck and testCallFunctionWithHellaArguments is broken in testb3
        https://bugs.webkit.org/show_bug.cgi?id=171392
        <rdar://problem/31872222>

        Reviewed by Keith Miller.

        This patch fixes two bugs. The first one is:
        Inside testb3, we were using the wrong WasmBoundsCheckValue constructor.
        Everything compiled OK because of implicit casting in C. I've changed one
        of the constructors to take arguments in a different order so we don't
        run into this problem again.
        
        The second bug was that Air::ShufflePair::inst was assuming that a move
        from BigImm to its destination is always valid. This is not the case.
        For example, the store, `Move BigImm, Addr` is not allowed. I refactored
        the code to be correct by emitting more than one instruction when needeed.
        
        When testing my changes, I ran ARM64 testb3 both in debug and
        release. I ran into many pre-existing failures. I've opened
        a new bug to fix those here: https://bugs.webkit.org/show_bug.cgi?id=171826

        * b3/B3WasmBoundsCheckValue.cpp:
        (JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue):
        * b3/B3WasmBoundsCheckValue.h:
        * b3/air/AirEmitShuffle.cpp:
        (JSC::B3::Air::ShufflePair::insts):
        (JSC::B3::Air::ShufflePair::inst): Deleted.
        * b3/air/AirEmitShuffle.h:
        * b3/air/AirLowerMacros.cpp:
        (JSC::B3::Air::lowerMacros):
        * b3/testb3.cpp:
        (JSC::B3::testLoadAcq42):
        (JSC::B3::testStoreRelAddLoadAcq32):
        (JSC::B3::testStoreRelAddLoadAcq8):
        (JSC::B3::testStoreRelAddFenceLoadAcq8):
        (JSC::B3::testStoreRelAddLoadAcq16):
        (JSC::B3::testStoreRelAddLoadAcq64):
        (JSC::B3::testSimplePatchpointWithOuputClobbersGPArgs):
        (JSC::B3::testCheckMul):
        (JSC::B3::testCheckMulMemory):
        (JSC::B3::testCheckMul64):
        (JSC::B3::testCheckMulFold):
        (JSC::B3::testCheckMulFoldFail):
        (JSC::B3::testCheckMulArgumentAliasing64):
        (JSC::B3::testCheckMulArgumentAliasing32):
        (JSC::B3::testCheckMul64SShr):
        (JSC::B3::testCallFunctionWithHellaArguments):
        (JSC::B3::functionWithHellaArguments2):
        (JSC::B3::testCallFunctionWithHellaArguments2):
        (JSC::B3::functionWithHellaArguments3):
        (JSC::B3::testCallFunctionWithHellaArguments3):
        (JSC::B3::testSpillDefSmallerThanUse):
        (JSC::B3::testLateRegister):
        (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled):
        (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled2):
        (JSC::B3::testMoveConstants):
        (JSC::B3::testAtomicWeakCAS):
        (JSC::B3::testAtomicStrongCAS):
        (JSC::B3::testAtomicXchg):
        (JSC::B3::testWasmBoundsCheck):
        (JSC::B3::run):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):

2017-05-08  Filip Pizlo  <fpizlo@apple.com>

        Expose a function to get proxy targets
        https://bugs.webkit.org/show_bug.cgi?id=171797
        <rdar://problem/32027549>

        Reviewed by Mark Lam.
        
        This exposes a new private API function, JSObjectGetProxyTarget(), that gets the target of a
        proxy. It works with both ProxyObject and JSProxy, but it's primarily intended for use with
        JSProxy.

        * API/JSObjectRef.cpp:
        (JSObjectGetProxyTarget):
        * API/JSObjectRefPrivate.h:
        * API/tests/JSObjectGetProxyTargetTest.cpp: Added.
        (testJSObjectGetProxyTarget):
        * API/tests/JSObjectGetProxyTargetTest.h: Added.
        * API/tests/testapi.c:
        (main):
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/ProxyObject.h:
        * shell/PlatformWin.cmake: 

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

        op_throw_static_error's use of its first operand should be reflected in DFG BytecodeUseDef as well.
        https://bugs.webkit.org/show_bug.cgi?id=171786
        <rdar://problem/32051023>

        Reviewed by Saam Barati.

        * bytecode/BytecodeDumper.cpp:
        (JSC::BytecodeDumper<Block>::dumpBytecode):
        - Fix BytecodeDumper to dump op_throw_static_error correctly.  Previously,
          it was expecting op1 to always be a constant.  r206870 changed it to take a
          variable string as well.

        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        - Fix the bug.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        - Move the Phantom of op1 after the ThrowStaticError node, because technically,
          the ThrowStaticError represents op_throw_static_error, and op_throw_static_error
          uses op1.  In practice, this probably doesn't matter, but let's have the code
          accurately communicate the behavior we're expecting.

2017-05-08  JF Bastien  <jfbastien@apple.com>

        WebAssembly: don't just emit extended offset adds for patch
        https://bugs.webkit.org/show_bug.cgi?id=171799

        Reviewed by Mark Lam.

        It isn't necessary to restrict.

        * b3/air/AirLowerStackArgs.cpp:
        (JSC::B3::Air::lowerStackArgs):

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

        Introduce ExceptionScope::assertNoException() and releaseAssertNoException().
        https://bugs.webkit.org/show_bug.cgi?id=171776

        Reviewed by Keith Miller.

        Instead of ASSERT(!scope.exception()), we can now do scope.assertNoException().
        Ditto for RELEASE_ASSERT and scope.releaseAssertNoException().  

        The advantage of using ExceptionScope::assertNoException() and
        releaseAssertNoException() is that if the assertion fails, these utility
        functions will print the stack trace for where the unexpected exception is
        detected as well as where the unexpected exception was thrown from.  This makes
        it much easier to debug the source of unhandled exceptions.

        * debugger/Debugger.cpp:
        (JSC::Debugger::pauseIfNeeded):
        * dfg/DFGOperations.cpp:
        * interpreter/Interpreter.cpp:
        (JSC::eval):
        (JSC::notifyDebuggerOfUnwinding):
        (JSC::Interpreter::executeProgram):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        (JSC::Interpreter::prepareForRepeatCall):
        (JSC::Interpreter::execute):
        (JSC::Interpreter::debug):
        * interpreter/ShadowChicken.cpp:
        (JSC::ShadowChicken::functionsOnStack):
        * jsc.cpp:
        (GlobalObject::moduleLoaderResolve):
        (GlobalObject::moduleLoaderFetch):
        (functionGenerateHeapSnapshot):
        (functionSamplingProfilerStackTraces):
        (box):
        (runWithScripts):
        * runtime/AbstractModuleRecord.cpp:
        (JSC::AbstractModuleRecord::finishCreation):
        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::tryInitializeSpeciesWatchpoint):
        * runtime/Completion.cpp:
        (JSC::rejectPromise):
        * runtime/ErrorInstance.cpp:
        (JSC::ErrorInstance::sanitizedToString):
        * runtime/ExceptionHelpers.cpp:
        (JSC::createError):
        * runtime/ExceptionScope.cpp:
        (JSC::ExceptionScope::unexpectedExceptionMessage):
        * runtime/ExceptionScope.h:
        (JSC::ExceptionScope::assertNoException):
        (JSC::ExceptionScope::releaseAssertNoException):
        (JSC::ExceptionScope::unexpectedExceptionMessage):
        * runtime/GenericArgumentsInlines.h:
        (JSC::GenericArguments<Type>::defineOwnProperty):
        * runtime/IntlCollator.cpp:
        (JSC::IntlCollator::createCollator):
        (JSC::IntlCollator::resolvedOptions):
        * runtime/IntlDateTimeFormat.cpp:
        (JSC::IntlDateTimeFormat::resolvedOptions):
        (JSC::IntlDateTimeFormat::format):
        * runtime/IntlNumberFormat.cpp:
        (JSC::IntlNumberFormat::createNumberFormat):
        (JSC::IntlNumberFormat::resolvedOptions):
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::putToPrimitiveByIndex):
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewProtoFuncIncludes):
        (JSC::genericTypedArrayViewProtoFuncIndexOf):
        (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
        (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncHostPromiseRejectionTracker):
        * runtime/JSModuleEnvironment.cpp:
        (JSC::JSModuleEnvironment::getOwnPropertySlot):
        * runtime/JSModuleLoader.cpp:
        (JSC::JSModuleLoader::finishCreation):
        * runtime/JSModuleNamespaceObject.cpp:
        (JSC::JSModuleNamespaceObject::finishCreation):
        * runtime/JSONObject.cpp:
        (JSC::Stringifier::toJSON):
        * runtime/JSObject.cpp:
        (JSC::JSObject::ordinaryToPrimitive):
        * runtime/JSPropertyNameEnumerator.h:
        (JSC::propertyNameEnumerator):
        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorGetOwnPropertyDescriptors):
        (JSC::objectConstructorDefineProperty):
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncHasOwnProperty):
        * runtime/ProgramExecutable.cpp:
        (JSC::ProgramExecutable::initializeGlobalProperties):
        * runtime/ReflectObject.cpp:
        (JSC::reflectObjectDefineProperty):
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::StackFrame::nameFromCallee):
        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncRepeatCharacter):
        * runtime/TemplateRegistry.cpp:
        (JSC::TemplateRegistry::getTemplateObject):
        * runtime/VM.cpp:
        (JSC::VM::throwException):
        * runtime/VM.h:
        (JSC::VM::nativeStackTraceOfLastThrow):
        (JSC::VM::clearException):
        * wasm/WasmB3IRGenerator.cpp:
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::create):

2017-05-06  Bill Ming  <mbbill@gmail.com>

        Fix 32bit Windows build by giving correct parameters to MASM
        https://bugs.webkit.org/show_bug.cgi?id=170833

        Reviewed by Alex Christensen.

        * CMakeLists.txt:

2017-05-06  Oleksandr Skachkov  <gskachkov@gmail.com>

        [ES6] Arrow function. Issue in access to this after eval('super()') within constructor
        https://bugs.webkit.org/show_bug.cgi?id=171543

        Reviewed by Saam Barati.

        Current patch force to use 'this' within arrow function or eval 
        from virtual scope each time, instead of using thisRegister.

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

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

        Put does not properly consult the prototype chain
        https://bugs.webkit.org/show_bug.cgi?id=171754

        Reviewed by Saam Barati.

        We should do a follow up that cleans up the rest of put. See:
        https://bugs.webkit.org/show_bug.cgi?id=171759

        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::putToPrimitive):
        * runtime/JSObject.cpp:
        (JSC::JSObject::putInlineSlow):
        * runtime/JSObjectInlines.h:
        (JSC::JSObject::canPerformFastPutInline):

2017-05-05  JF Bastien  <jfbastien@apple.com>

        WebAssembly: Air::Inst::generate crashes on large binary on A64
        https://bugs.webkit.org/show_bug.cgi?id=170215

        Reviewed by Filip Pizlo.

        ARM can't encode all offsets in a single instruction. We usualy
        handle this type of detail early, or the macro assembler uses a
        scratch register to take care of the large immediate. After
        register allocation we assumed that we would never get large
        offsets, and asserted this was the case. That was a fine
        assumption with JavaScript, but WebAssembly ends up generating
        stack frames which are too big to encode.

        There are two places that needed to be fixed:
            1. AirGenerate
            2. AirLowerStackArgs

        We now unconditionally pin the dataTempRegister on ARM64, and use
        it when immediates don't fit.

        Number 1. is easy: we're just incrementing SP, make sure we can
        use a scratch register when that happens.

        Number 2. is more complex: not all Inst can receive a stack
        argument whose base register isn't SP or FP. Specifically,
        Patchpoints and Stackmaps get very sad because they just want to
        know the offset value, but when we materialize the offset as
        follows:

            Move (spill337), (spill201), %r0, @8735

        Becomes (where %r16 is dataTempRegister):
            Move $1404, %r16, @8736
            Add64 %sp, %r16, @8736
            Move (%r16), 2032(%sp), %r0, @8736

        The code currently doesn't see through our little dance. To work
        around this issue we introduce a new Air Arg kind:
        ExtendedOffsetAddr. This is the same as a regular Addr, but with
        an offset which may be too big to encode. Opcodes then declare
        whether their arguments can handle such inputs, and if so we
        generate them, otherwise we generate Addr as shown above.

        None of this affects x86 because it can always encode large
        immediates.

        This patch also drive-by converts some uses of `override` to
        `final`. It makes the code easier to grok, and maybe helps the
        optimizer sometimes but really that doens't matter.

        * assembler/MacroAssembler.h:
        * assembler/MacroAssemblerARM64.h:
        * b3/B3CheckSpecial.cpp:
        (JSC::B3::CheckSpecial::admitsExtendedOffsetAddr):
        * b3/B3CheckSpecial.h:
        * b3/B3Common.cpp:
        (JSC::B3::pinnedExtendedOffsetAddrRegister): keep the CPU-specific
        pinning information in a cpp file
        * b3/B3Common.h:
        * b3/B3PatchpointSpecial.cpp:
        (JSC::B3::PatchpointSpecial::admitsExtendedOffsetAddr):
        * b3/B3PatchpointSpecial.h:
        * b3/B3StackmapSpecial.cpp:
        (JSC::B3::StackmapSpecial::isArgValidForRep):
        (JSC::B3::StackmapSpecial::repForArg):
        * b3/B3StackmapSpecial.h:
        * b3/air/AirArg.cpp:
        (JSC::B3::Air::Arg::isStackMemory):
        (JSC::B3::Air::Arg::jsHash):
        (JSC::B3::Air::Arg::dump):
        (WTF::printInternal):
        (JSC::B3::Air::Arg::stackAddrImpl): Deleted. There was only one
        use of this (in AirLowerStackArgs) and it was now confusing to
        split the logic up between these two. Inline the code that used to
        be here into its one usepoint instead.
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::extendedOffsetAddr):
        (JSC::B3::Air::Arg::isExtendedOffsetAddr):
        (JSC::B3::Air::Arg::isMemory):
        (JSC::B3::Air::Arg::base):
        (JSC::B3::Air::Arg::offset):
        (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::stackAddr): Deleted.
        * b3/air/AirCCallSpecial.cpp:
        (JSC::B3::Air::CCallSpecial::isValid):
        (JSC::B3::Air::CCallSpecial::admitsExtendedOffsetAddr):
        (JSC::B3::Air::CCallSpecial::generate):
        * b3/air/AirCCallSpecial.h:
        * b3/air/AirCode.cpp:
        (JSC::B3::Air::Code::Code):
        (JSC::B3::Air::Code::pinRegister): Check that the register wasn't
        pinned before pinning it. It's likely a bug to pin the same
        register twice.
        * b3/air/AirCustom.h:
        (JSC::B3::Air::PatchCustom::admitsExtendedOffsetAddr):
        (JSC::B3::Air::CCallCustom::admitsExtendedOffsetAddr):
        (JSC::B3::Air::ShuffleCustom::admitsExtendedOffsetAddr):
        (JSC::B3::Air::EntrySwitchCustom::admitsExtendedOffsetAddr):
        (JSC::B3::Air::WasmBoundsCheckCustom::admitsExtendedOffsetAddr):
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::generate):
        * b3/air/AirInst.h:
        * b3/air/AirInstInlines.h:
        (JSC::B3::Air::Inst::admitsExtendedOffsetAddr):
        * b3/air/AirLowerStackArgs.cpp:
        (JSC::B3::Air::lowerStackArgs):
        * b3/air/AirPrintSpecial.cpp:
        (JSC::B3::Air::PrintSpecial::admitsExtendedOffsetAddr):
        (JSC::B3::Air::PrintSpecial::generate):
        * b3/air/AirPrintSpecial.h:
        * b3/air/AirSpecial.h:
        * b3/air/opcode_generator.rb:

2017-05-05  Oliver Hunt  <oliver@apple.com>

        Move trivial String prototype functions to JS builtins
        https://bugs.webkit.org/show_bug.cgi?id=171737

        Reviewed by Saam Barati.

        Super simple change to migrate all of the old school
        html-ifying string operations to builtin JS.

        Core implementation is basically a 1-for-1 match to the spec.

        * builtins/StringPrototype.js:
        (globalPrivate.createHTML):
        (anchor):
        (big):
        (blink):
        (bold):
        (fixed):
        (fontcolor):
        (fontsize):
        (italics):
        (link):
        (small):
        (strike):
        (sub):
        (sup):
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        (JSC::stringProtoFuncBig): Deleted.
        (JSC::stringProtoFuncSmall): Deleted.
        (JSC::stringProtoFuncBlink): Deleted.
        (JSC::stringProtoFuncBold): Deleted.
        (JSC::stringProtoFuncFixed): Deleted.
        (JSC::stringProtoFuncItalics): Deleted.
        (JSC::stringProtoFuncStrike): Deleted.
        (JSC::stringProtoFuncSub): Deleted.
        (JSC::stringProtoFuncSup): Deleted.
        (JSC::stringProtoFuncFontcolor): Deleted.
        (JSC::stringProtoFuncFontsize): Deleted.
        (JSC::stringProtoFuncAnchor): Deleted.
        (JSC::stringProtoFuncLink): Deleted.

2017-05-05  Don Olmstead  <don.olmstead@am.sony.com>

        [JSC] Remove export from Intrinsic
        https://bugs.webkit.org/show_bug.cgi?id=171752

        Reviewed by Alexey Proskuryakov.

        * runtime/Intrinsic.h:

2017-05-05  Saam Barati  <sbarati@apple.com>

        putDirectIndex does not properly do defineOwnProperty
        https://bugs.webkit.org/show_bug.cgi?id=171591
        <rdar://problem/31735695>

        Reviewed by Geoffrey Garen.

        This patch fixes putDirectIndex and its JIT implementations to be
        compatible with the ES6 spec. I think our code became out of date
        when we implemented ArraySpeciesCreate since ArraySpeciesCreate may
        return arbitrary objects. We perform putDirectIndex on that arbitrary
        object. The behavior we want is as if we performed defineProperty({configurable:true, enumerable:true, writable:true}).
        However, we weren't doing this. putDirectIndex assumed it could just splat
        data into any descendent of JSObject's butterfly. For example, this means
        we'd just splat into the butterfly of a typed array, even though a typed
        array doesn't use its butterfly to store its indexed properties in the usual
        way. Also, typed array properties are non-configurable, so this operation
        should throw. This also means if we saw a ProxyObject, we'd just splat
        into its butterfly, but this is obviously wrong because ProxyObject should
        intercept the defineProperty operation.
        
        This patch fixes this issue by adding a whitelist of cell types that can
        go down putDirectIndex's fast path. Anything not in that whitelist will
        simply call into defineOwnProperty.

        * bytecode/ByValInfo.h:
        (JSC::jitArrayModePermitsPutDirect):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::refine):
        * jit/JITOperations.cpp:
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncSplice):
        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::createStructure):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
        * runtime/JSObject.cpp:
        (JSC::canDoFastPutDirectIndex):
        (JSC::JSObject::defineOwnIndexedProperty):
        (JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength):
        (JSC::JSObject::putDirectIndexBeyondVectorLength): Deleted.
        * runtime/JSObject.h:
        (JSC::JSObject::putDirectIndex):
        (JSC::JSObject::canSetIndexQuicklyForPutDirect): Deleted.
        * runtime/JSType.h:

2017-05-05  Guillaume Emont  <guijemont@igalia.com>

        [JSC] include JSCInlines.h in ObjectInitializationScope.cpp
        https://bugs.webkit.org/show_bug.cgi?id=171744

        Reviewed by Mark Lam.

        * runtime/ObjectInitializationScope.cpp:


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

        [GTK] Assertion failure in Inspector::RemoteInspector::setRemoteInspectorClient when disposing WebKitWebContext
        https://bugs.webkit.org/show_bug.cgi?id=171644

        Reviewed by Michael Catanzaro.

        Fix ASSERT that requires given client to be a valid pointer, since it's valid to pass nullptr to unset the
        client. The ASSERT now ensures that client is set or unset. I also renamed the function to setClient because
        setRemoteInspectorClient is redundant for a class named RemoteInspector. And added a getter too, to check if the
        remote inspector has a client.

        * inspector/remote/RemoteInspector.cpp:
        (Inspector::RemoteInspector::setClient):
        * inspector/remote/RemoteInspector.h:

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

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

        Multiple LayoutTests crashing in Document::page() (Requested
        by ap on #webkit).

        Reverted changeset:

        "Remove support for legacy Notifications"
        https://bugs.webkit.org/show_bug.cgi?id=171487
        http://trac.webkit.org/changeset/216206

2017-05-04  Don Olmstead  <don.olmstead@am.sony.com>

        [Win] Remove redundant macros that are set in the CMake config
        https://bugs.webkit.org/show_bug.cgi?id=171571

        Reviewed by Brent Fulgham.

        * config.h:

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

        Gardening: Build fix for Windows after r216217.
        https://bugs.webkit.org/show_bug.cgi?id=171586

        Not reviewed.

        * shell/PlatformWin.cmake:

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

        JSC::Heap should expose a richer API for requesting GCs
        https://bugs.webkit.org/show_bug.cgi?id=171690

        Reviewed by Geoffrey Garen.
        
        I want to stop WebCore from requesting synchronous GCs. But various parts of that work
        may cause regressions, so I'd like to land it separately from the functionality that is
        needed on the JSC side. This change is mostly a JSC-side refactoring that does not
        change behavior. In the future I'll land the behavior changes (i.e. not requesting sync
        GCs).
        
        This change allows you to enumerate over synchronousness, so that we can make all APIs
        take synchronousness as an argument. It replaces the collectAllGarbage API with a
        collectNow(Synchronousness, GCRequest) API. GCRequest is a new concept, which subsumes
        std::optional<CollectionScope> and gives us the ability to register callbacks along
        with a GC. So, you can ask for an async GC and get a callback when it's done.
        
        Also adds ability to request that fastMalloc memory be released after the incremental
        sweeper finishes.
        
        * API/JSBase.cpp:
        (JSSynchronousGarbageCollectForDebugging):
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/FullGCActivityCallback.cpp:
        (JSC::FullGCActivityCallback::doCollection):
        * heap/FullGCActivityCallback.h:
        * heap/GCRequest.cpp: Added.
        (JSC::GCRequest::subsumedBy):
        (JSC::GCRequest::dump):
        * heap/GCRequest.h: Added.
        (JSC::GCRequest::GCRequest):
        * heap/Heap.cpp:
        (JSC::Heap::collect):
        (JSC::Heap::collectNow):
        (JSC::Heap::collectAsync):
        (JSC::Heap::collectSync):
        (JSC::Heap::runBeginPhase):
        (JSC::Heap::runEndPhase):
        (JSC::Heap::requestCollection):
        (JSC::Heap::willStartCollection):
        (JSC::Heap::sweeper):
        (JSC::Heap::collectNowFullIfNotDoneRecently):
        (JSC::Heap::shouldDoFullCollection):
        (JSC::Heap::collectAllGarbage): Deleted.
        (JSC::Heap::collectAllGarbageIfNotDoneRecently): Deleted.
        * heap/Heap.h:
        * heap/HeapSnapshotBuilder.cpp:
        (JSC::HeapSnapshotBuilder::buildSnapshot):
        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::doSweep):
        * heap/IncrementalSweeper.h:
        (JSC::IncrementalSweeper::freeFastMallocMemoryAfterSweeping):
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::doTestCollectionsIfNeeded):
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::sweep):
        * heap/Synchronousness.cpp: Added.
        (WTF::printInternal):
        * heap/Synchronousness.h: Added.
        * inspector/agents/InspectorHeapAgent.cpp:
        (Inspector::InspectorHeapAgent::gc):
        * jsc.cpp:
        (functionGCAndSweep):
        (runJSC):
        * tools/JSDollarVMPrototype.cpp:
        (JSC::JSDollarVMPrototype::gc):
        * wasm/WasmMemory.cpp:

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

        NeverDestroyed<String>(ASCIILiteral(...)) is not thread safe.
        https://bugs.webkit.org/show_bug.cgi?id=171586
        <rdar://problem/31873190>

        Reviewed by Yusuke Suzuki.

        JavaScriptCore allows multiple VMs to be instantiated, and each of these should
        be able to run concurrently on different threads.  There is code in the VM that
        allocates NeverDestroyed<String>(ASCIILiteral(...)) to defined immortal strings
        meant to be shared by all VMs.

        However, NeverDestroyed<String>(ASCIILiteral(...)) is not thread-safe because
        each thread will ref and deref the underlying StringImpl.  Since this ref and
        deref is not done in a thread-safe way, the NeverDestroyed<String> may get
        destroyed due to the ref/deref races.  Additionally, each thread may modify the
        StringImpl by setting its hash and also twiddling its flags.

        The fix is to use the StaticStringImpl class which is safe for ref/derefing
        concurrently from different threads.  StaticStringImpl is also pre-set with a
        hash on construction, and its flags are set in such a way as to prevent twiddling
        at runtime.  Hence, we will be able to share a NeverDestroyed<String> between
        VMs, as long as it is backed by a StaticStringImpl.

        An alternative solution would be to change all the uses of NeverDestroyed<String>
        to use per-VM strings.  However, this solution is cumbersome, and makes it harder
        to allocate the intended shared string.  It also uses more memory and takes more
        CPU time because it requires allocating the same string for each VM instance.
        The StaticStringImpl solution wins out because it is more efficient and is easier
        to use.

        The StaticStringImpl solution also can be used in WTF without a layer violation.
        See Source/WTF/wtf/text/icu/TextBreakIteratorICU.h for an example.

        Also added the MultithreadedMultiVMExecutionTest which runs multiple VMs in
        multiple threads, all banging on the BuiltinExecutable's baseConstructorCode
        NeverDestroyed<String>.  The test will manifest the issue reliably (before this
        fix) if run on an ASAN build.

        * API/tests/MultithreadedMultiVMExecutionTest.cpp: Added.
        (threadsList):
        (startMultithreadedMultiVMExecutionTest):
        (finalizeMultithreadedMultiVMExecutionTest):
        * API/tests/MultithreadedMultiVMExecutionTest.h: Added.
        * API/tests/testapi.c:
        (main):
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createDefaultConstructor):
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::objectGroupForBreakpointAction):
        * replay/scripts/CodeGeneratorReplayInputsTemplates.py:
        * replay/scripts/tests/expected/generate-enum-encoding-helpers-with-guarded-values.json-TestReplayInputs.cpp:
        (JSC::InputTraits<Test::SavedMouseButton>::type):
        * replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.cpp:
        (JSC::InputTraits<Test::SavedMouseButton>::type):
        * replay/scripts/tests/expected/generate-enum-with-guard.json-TestReplayInputs.cpp:
        (JSC::InputTraits<Test::HandleWheelEvent>::type):
        * replay/scripts/tests/expected/generate-enums-with-same-base-name.json-TestReplayInputs.cpp:
        (JSC::InputTraits<Test::FormCombo>::type):
        * replay/scripts/tests/expected/generate-input-with-guard.json-TestReplayInputs.cpp:
        (JSC::InputTraits<Test::GetCurrentTime>::type):
        (JSC::InputTraits<Test::SetRandomSeed>::type):
        * replay/scripts/tests/expected/generate-input-with-vector-members.json-TestReplayInputs.cpp:
        (JSC::InputTraits<Test::ArrayOfThings>::type):
        (JSC::InputTraits<Test::SavedHistory>::type):
        * replay/scripts/tests/expected/generate-inputs-with-flags.json-TestReplayInputs.cpp:
        (JSC::InputTraits<Test::ScalarInput1>::type):
        (JSC::InputTraits<Test::ScalarInput2>::type):
        * replay/scripts/tests/expected/generate-memoized-type-modes.json-TestReplayInputs.cpp:
        (JSC::InputTraits<Test::ScalarInput>::type):
        (JSC::InputTraits<Test::MapInput>::type):
        * runtime/IntlObject.cpp:
        (JSC::numberingSystemsForLocale):

2017-05-04  Sam Weinig  <sam@webkit.org>

        Remove support for legacy Notifications
        https://bugs.webkit.org/show_bug.cgi?id=171487

        Reviewed by Jon Lee.

        * Configurations/FeatureDefines.xcconfig:
        Remove definition of ENABLE_LEGACY_NOTIFICATIONS.

2017-05-04  Konstantin Tokarev  <annulen@yandex.ru>

        Fix compilation with ICU 59.1
        https://bugs.webkit.org/show_bug.cgi?id=171612

        Reviewed by Mark Lam.

        ICU 59.1 has broken source compatibility. Now it defines UChar as
        char16_t, which does not allow automatic type conversion from unsigned
        short in C++ code.

        * API/JSStringRef.cpp:
        (JSStringCreateWithCharacters):
        (JSStringCreateWithCharactersNoCopy):
        (JSStringGetCharactersPtr):
        * runtime/DateConversion.cpp:
        (JSC::formatDateTime):

2017-05-04  Saam Barati  <sbarati@apple.com>

        stress/call-apply-exponential-bytecode-size.js.no-llint failing on 32-bit debug for OOM on executable memory
        https://bugs.webkit.org/show_bug.cgi?id=171008

        Reviewed by Yusuke Suzuki.

        This patch lowers the threshold for .call/.apply recursion
        in an attempt to emit less code and not impact perf.
        We're currently failing tests on x86-32 by running out
        of executable memory. If perf gets impacted because of this,
        then I'll apply a stricter change just to 32-bit platforms.
        However, if this doesn't negatively impact perf, it's all around
        better than all platforms emit less bytecode.

        * bytecompiler/NodesCodegen.cpp:

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

        [JSC] Math unary functions should be handled by DFG
        https://bugs.webkit.org/show_bug.cgi?id=171269

        Reviewed by Saam Barati.

        ArithSin, ArithCos, and ArithLog are just calling a C runtime function.
        While handling them in DFG is not very effective for performance, they
        can drop some type checks & value conversions and mark them as pure
        operations. It is effective if they are involved in some complex
        optimization phase. Actually, ArithLog is effective in kraken.

        While a few of Math functions have DFG nodes, basically math functions
        are pure. And large part of these functions are just calling a C runtime
        function. This patch generalizes these nodes in DFG as ArithUnary. And
        we annotate many unary math functions with Intrinsics and convert them
        to ArithUnary in DFG. It also cleans up duplicate code in ArithSin,
        ArithCos, and ArithLog. If your math function has some good DFG / FTL
        optimization rather than calling a C runtime function, you should add
        a specialized DFG node, like ArithSqrt.

        We also create a new namespace JSC::Math. Inside it, we collect math functions.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGArithMode.cpp:
        (JSC::DFG::arithUnaryFunction):
        (JSC::DFG::arithUnaryOperation):
        (WTF::printInternal):
        * dfg/DFGArithMode.h:
        * dfg/DFGBackwardsPropagationPhase.cpp:
        (JSC::DFG::BackwardsPropagationPhase::propagate):
        * 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/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasArithUnaryType):
        (JSC::DFG::Node::arithUnaryType):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithUnary):
        (JSC::DFG::SpeculativeJIT::compileArithCos): Deleted.
        (JSC::DFG::SpeculativeJIT::compileArithTan): Deleted.
        (JSC::DFG::SpeculativeJIT::compileArithSin): Deleted.
        (JSC::DFG::SpeculativeJIT::compileArithLog): Deleted.
        * 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::compileArithUnary):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithSin): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::compileArithCos): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::compileArithTan): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::compileArithLog): Deleted.
        * ftl/FTLOutput.cpp:
        (JSC::FTL::Output::doubleUnary):
        (JSC::FTL::Output::doubleSin): Deleted.
        (JSC::FTL::Output::doubleCos): Deleted.
        (JSC::FTL::Output::doubleTan): Deleted.
        (JSC::FTL::Output::doubleLog): Deleted.
        * ftl/FTLOutput.h:
        * runtime/Intrinsic.h:
        * runtime/MathCommon.cpp:
        (JSC::Math::log1p):
        * runtime/MathCommon.h:
        * runtime/MathObject.cpp:
        (JSC::MathObject::finishCreation):
        (JSC::mathProtoFuncACos):
        (JSC::mathProtoFuncASin):
        (JSC::mathProtoFuncATan):
        (JSC::mathProtoFuncCos):
        (JSC::mathProtoFuncExp):
        (JSC::mathProtoFuncLog):
        (JSC::mathProtoFuncSin):
        (JSC::mathProtoFuncTan):
        (JSC::mathProtoFuncACosh):
        (JSC::mathProtoFuncASinh):
        (JSC::mathProtoFuncATanh):
        (JSC::mathProtoFuncCbrt):
        (JSC::mathProtoFuncCosh):
        (JSC::mathProtoFuncExpm1):
        (JSC::mathProtoFuncLog1p):
        (JSC::mathProtoFuncLog10):
        (JSC::mathProtoFuncLog2):
        (JSC::mathProtoFuncSinh):
        (JSC::mathProtoFuncTanh):

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

        How we build polymorphic cases is wrong when making a call from Wasm
        https://bugs.webkit.org/show_bug.cgi?id=171527

        Reviewed by JF Bastien.

        This patches fixes a bug when we emit a polymorphic call IC from
        Wasm. We were incorrectly assuming that if we made a call *from wasm*,
        then the thing we are *calling to* does not have a CodeBlock. This
        is obviously wrong. This patch fixes the incorrect assumption.
        
        This patch also does two more things:
        1. Add a new option that makes us make calls to JS using a
        slow path instead of using a call IC.
        2. Fixes a potential GC bug where we didn't populate JSWebAssemblyCodeBlock's
        JSWebAssemblyModule pointer.

        * jit/Repatch.cpp:
        (JSC::linkPolymorphicCall):
        * runtime/Options.h:
        * wasm/WasmBinding.cpp:
        (JSC::Wasm::wasmToJs):
        * wasm/js/JSWebAssemblyCodeBlock.cpp:
        (JSC::JSWebAssemblyCodeBlock::create):
        (JSC::JSWebAssemblyCodeBlock::finishCreation):
        * wasm/js/JSWebAssemblyCodeBlock.h:
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::finalizeCreation):

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

        Array.prototype.sort should also allow a null comparator
        https://bugs.webkit.org/show_bug.cgi?id=171621
        <rdar://problem/30757933>

        Reviewed by Michael Saboff.

        It looks like sort not accepting a null comparator
        causes some pages to stop working. Those pages work in
        Chrome/Firefox so we should try to match them.

        * builtins/ArrayPrototype.js:
        (sort):

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

        Use the CLoop for CPU(ARM64E).
        https://bugs.webkit.org/show_bug.cgi?id=171620
        <rdar://problem/31973027>

        Reviewed by Geoffrey Garen.

        * llint/LLIntOfflineAsmConfig.h:
        * tools/SigillCrashAnalyzer.cpp:
        (JSC::SigillCrashAnalyzer::dumpCodeBlock):

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

        Different behaviour with the .sort(callback) method (unlike Firefox & Chrome)
        https://bugs.webkit.org/show_bug.cgi?id=47825

        Reviewed by Saam Barati.

        This patch makes our sort function match the behavior of Firefox
        and Chrome when the result of the comparison function is a
        boolean. When we first switched to using merge sort, it regressed
        JQuery sorting of DOM nodes by 30%. The regression was do to the
        fact that JQuery was using compareDocumentPosition to compare the
        locations of objects. Since one of the benchmarks would pass a
        reverse sorted list to the sort function we would end up walking
        the entire DOM to do comparisons. The solution to this was to
        merge based on comparison(right, left) rather than
        comparison(left, right). Although, in practice this does nothing
        since sort could just as easily receive an already sorted list and
        we're back in the same spot.

        The downside of sorting with comparison(right, left) is that to
        maintain stability when sorting, you only want to merge from right
        when the comparison function returns a negative value. This is
        where the problem with booleans comes in. Since booleans toNumber
        false to 0 and true to 1 both values are "equal". This patch fixes
        this by special casing boolean return values.


        * builtins/ArrayPrototype.js:
        (sort.merge):

2017-05-03  Andy VanWagoner  <thetalecrafter@gmail.com>

        [INTL] Support dashed values in unicode locale extensions
        https://bugs.webkit.org/show_bug.cgi?id=171480

        Reviewed by JF Bastien.

        Implements the UnicodeExtensionSubtags operation and updates the ResolveLocale operation to use it.
        This fixes locale extensions with values that include '-'. The following calendars work now:
        ethiopic-amete-alem
        islamic-umalqura
        islamic-tbla
        islamic-civil
        islamic-rgsa

        While updating IntlObject, the comments containing spec text were replaced with a single url at the
        top of each function pointing to the relevant part of ECMA-402.

        * runtime/IntlObject.cpp:
        (JSC::unicodeExtensionSubTags): Added.
        (JSC::resolveLocale): Updated to latest standard.

2017-05-02  Don Olmstead  <don.olmstead@am.sony.com>

        Build fix after r216078
        https://bugs.webkit.org/show_bug.cgi?id=171554

        Reviewed by Saam Barati.

        * API/tests/testapi.c:

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

        Unreviewed, fix pedantic C compilers.

        * API/tests/testapi.c:
        (markingConstraint):
        (testMarkingConstraints):

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

        Unreviewed, fix cmake build.

        * CMakeLists.txt:

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

        JSC C API should expose GC marking constraints and weak references
        https://bugs.webkit.org/show_bug.cgi?id=171554

        Reviewed by Geoffrey Garen.
        
        This exposes an API that lets you participate in the GC's fixpoint. You can ask the GC
        what is marked and you can tell the GC to mark things. The constraint callback cannot
        do a whole lot, but it can query marking state and it can dereference weak references.
        
        Additionally, this exposes a very simple weak reference API in C.

        * API/JSMarkingConstraintPrivate.cpp: Added.
        (JSC::isMarked):
        (JSC::mark):
        (JSContextGroupRegisterMarkingConstraint):
        * API/JSMarkingConstraintPrivate.h: Added.
        * API/JSWeakPrivate.cpp: Added.
        (OpaqueJSWeak::OpaqueJSWeak):
        (JSWeakCreate):
        (JSWeakRetain):
        (JSWeakRelease):
        (JSWeakGetObject):
        * API/JSWeakPrivate.h: Added.
        * API/tests/testapi.c:
        (markingConstraint):
        (testMarkingConstraints):
        (main):
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/SlotVisitor.h:
        * heap/SlotVisitorInlines.h:
        (JSC::SlotVisitor::appendHiddenUnbarriered):
        (JSC::SlotVisitor::appendHidden):

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

        JSFixedArray::allocationSize() should not allow for allocation failure.
        https://bugs.webkit.org/show_bug.cgi?id=171516

        Reviewed by Geoffrey Garen.

        Since JSFixedArray::createFromArray() now handles allocation failures by throwing
        OutOfMemoryErrors, its helper function allocationSize() (which computes the buffer
        size to allocate) should also allow for allocation failure on overflow.

        This issue is covered by the stress/js-fixed-array-out-of-memory.js test when
        run on 32-bit builds.

        * runtime/JSFixedArray.h:
        (JSC::JSFixedArray::tryCreate):
        (JSC::JSFixedArray::allocationSize):

2017-05-01  Zan Dobersek  <zdobersek@igalia.com>

        [aarch64][Linux] m_allowScratchRegister assert hit in MacroAssemblerARM64 under B3::Air::CCallSpecial::generate()
        https://bugs.webkit.org/show_bug.cgi?id=170672

        Reviewed by Filip Pizlo.

        In Air::CCallSpecial::admitsStack() we reject admitting the callee argument on
        the stack for ARM64 because that can lead to disallowed usage of the scratch
        register in MacroAssemblerARM64 when generating a call with an address Arg
        in Air::CCallSpecial::generate().

        The testLinearScanWithCalleeOnStack test is added to testb3. It reproduces the
        original issue by force-spilling everything on the stack and enforcing the use
        of the linear scan register allocation by using an optimization level of 1.

        * b3/air/AirCCallSpecial.cpp:
        (JSC::B3::Air::CCallSpecial::admitsStack):
        * b3/testb3.cpp:
        (JSC::B3::testLinearScanWithCalleeOnStack):
        (JSC::B3::run):

2017-05-01  David Kilzer  <ddkilzer@apple.com>

        Stop using sprintf() in JavaScriptCore debugger
        <https://webkit.org/b/171512>

        Reviewed by Keith Miller.

        * disassembler/udis86/udis86.c:
        (ud_insn_hex): Switch from sprintf() to snprintf().

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

        Air::fixObviousSpills should remove totally redundant instructions
        https://bugs.webkit.org/show_bug.cgi?id=171131

        Reviewed by Saam Barati.
        
        This is a modest compile-time-neutral improvement to fixObviousSpills. That phase
        builds up a classic alias analysis data structure over spills and registers and then
        uses it to remove the most common spill pathologies we encounter. For example, if you
        use a spill but the spill is aliased to a register or constant, then we can replace the
        use of the spill with a use of the register or constant.
        
        But that phase was missing perhaps one of the most obvious fixups that its analysis
        allows us to do: if any instruction creates an alias we already know about, then the
        instruction is redundant. This turned out to be super important for
        https://bugs.webkit.org/show_bug.cgi?id=171075. That patch didn't work out, but this
        kind of optimization might be a good clean-up for many other kinds of optimizations.

        * b3/air/AirFixObviousSpills.cpp:

2017-04-30  Oleksandr Skachkov  <gskachkov@gmail.com>

        We initialize functions too early in an eval
        https://bugs.webkit.org/show_bug.cgi?id=161099

        Reviewed by Saam Barati.

        Current patch allow to fix problem with scope in function that is 
        declared within eval. Before scope was set inside Interpretator.cpp and it
        was scope where eval is executed, but in this case function would not 
        see let/const variables and classes declated in eval.
        This patch devide declaration and binding in two operation, first just declare
        variable with function name, and second bind variable to function with correct 
        scope

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * bytecompiler/BytecodeGenerator.h:
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):

2017-04-30  Oleksandr Skachkov  <gskachkov@gmail.com>

        [ES6]. Implement Annex B.3.3 function hoisting rules for eval
        https://bugs.webkit.org/show_bug.cgi?id=163208

        Reviewed by Saam Barati.

        Current patch implements Annex B.3.3 that is related to 
        hoisting of function declaration in eval. 
        https://tc39.github.io/ecma262/#sec-web-compat-evaldeclarationinstantiation
        Function declaration in eval should create variable with 
        function name in function scope where eval is invoked 
        or bind to variable if it declared outside of the eval. 
        If variable is created it can be removed by 'delete a;' command. 
        If eval is invoke in block scope that contains let/const 
        variable with the same name as function declaration 
        we do not bind. This patch leads to the following behavior: 
        '''
        function foo() {
           {
             print(boo); // undefined
             eval('{ function boo() {}}');
             print(boo); // function boo() {}
           }
           print(boo); // function boo() {}
        }

        function foobar() {
          { 
            let boo = 10;
            print(boo); // 10;
            eval('{ function boo() {}}');
            print(boo); // 10;
          }
          print(boo) // 10
        }

        function bar() {
           {
              var boo = 10;
              print(boo); // 10
              eval('{ function boo() {} }'); 
              print(boo); // function boo() {}
           }
           print(boo); // function boo() {}
        }       
        
        function bas() {
            {
                 let boo = 10;
                 eval(' { function boo() {} } ');
                 print(boo); // 10
            }
            print(boo); //Reference Error
        }
        '''

        Current implementation relies on already implemented 
        'hoist function in sloppy mode' feature, with small changes.
        In short it works in following way: during hoisting of function 
        with name S in eval, we are looking for first scope that 
        contains space for variable with name S and if this scope 
        has var type we bind function there

        To implement this feature was added bytecode ops:
        op_resolve_scope_for_hoisting_func_decl_in_eval - get variable scope 
        or return undefined if variable can't be binded there.

        There is a corner case, hoist function in eval within catch block,
        that is not covered by this patch, and will be fixed in 
        https://bugs.webkit.org/show_bug.cgi?id=168184

        * bytecode/BytecodeDumper.cpp:
        (JSC::BytecodeDumper<Block>::dumpBytecode):
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finalizeLLIntInlineCaches):
        * bytecode/EvalCodeBlock.h:
        (JSC::EvalCodeBlock::functionHoistingCandidate):
        (JSC::EvalCodeBlock::numFunctionHoistingCandidates):
        * bytecode/UnlinkedEvalCodeBlock.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary):
        (JSC::BytecodeGenerator::emitResolveScopeForHoistingFuncDeclInEval):
        * 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/DFGNode.h:
        (JSC::DFG::Node::hasIdentifier):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileResolveScopeForHoistingFuncDeclInEval):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileResolveScopeForHoistingFuncDeclInEval):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOperations.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval):
        * llint/LowLevelInterpreter.asm:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFunctionDeclarationStatement):
        * parser/Parser.h:
        (JSC::Scope::getSloppyModeHoistedFunctions):
        (JSC::Parser::declareFunction):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        * runtime/EvalExecutable.h:
        (JSC::EvalExecutable::numFunctionHoistingCandidates):
        (JSC::EvalExecutable::numTopLevelFunctionDecls):
        (JSC::EvalExecutable::numberOfFunctionDecls): Deleted.
        * runtime/JSScope.cpp:
        (JSC::JSScope::resolve):
        (JSC::JSScope::resolveScopeForHoistingFuncDeclInEval):
        * runtime/JSScope.h:

2017-04-29  Oleksandr Skachkov  <gskachkov@gmail.com>

        Deep nesting is leading to ReferenceError for hoisted function
        https://bugs.webkit.org/show_bug.cgi?id=171456

        Reviewed by Yusuke Suzuki.

        Current patch fix error that appears during hoisting of the function 
        in block scope. Error happens only when exist some deep scope that lead
        to increase scope stack, after which list of the hosted candidates do not 
        copied to updated scope stack.

        * parser/Parser.h:
        (JSC::Scope::Scope):

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

        [JSC] LabelScopePtr is not necessary
        https://bugs.webkit.org/show_bug.cgi?id=171474

        Reviewed by Geoffrey Garen.

        Originally, LabelScopePtr is introduced because LabelScopes uses Vector<> instead of SegmentedVector<>.
        LabelScopePtr holds the pointer to the vector owner and index instead of the pointer to LabelScope directly
        since Vector<> can relocate LocalScopes inside it.
        The reason why LabelScopes use Vector instead is that there is code copying this vector. SegmentedVector<>
        prohibits copying since it is so costly. So, we used Vector<> here instead of SegmentedVector<>.

        But the latest code does not have copying code for LabelScopes. Thus, we can take the same design to Label and
        RegisterID. Just use SegmentedVector<> and Ref<>/RefPtr<>. This patch removes LabelScopePtr since it is no
        longer necessary. And use SegmentedVector for LabelScopes.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::reclaim):
        (JSC::BytecodeGenerator::reclaimFreeRegisters):
        (JSC::BytecodeGenerator::newLabelScope):
        (JSC::BytecodeGenerator::newLabel):
        (JSC::BytecodeGenerator::pushFinallyControlFlowScope):
        (JSC::BytecodeGenerator::breakTarget):
        (JSC::BytecodeGenerator::continueTarget):
        (JSC::BytecodeGenerator::emitEnumeration):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/LabelScope.h:
        (JSC::LabelScope::LabelScope):
        (JSC::LabelScope::breakTarget):
        (JSC::LabelScope::continueTarget):
        (JSC::LabelScope::type):
        (JSC::LabelScope::name):
        (JSC::LabelScope::scopeDepth):
        (JSC::LabelScope::ref):
        (JSC::LabelScope::deref):
        (JSC::LabelScope::refCount):
        (JSC::LabelScopePtr::LabelScopePtr): Deleted.
        (JSC::LabelScopePtr::operator=): Deleted.
        (JSC::LabelScopePtr::~LabelScopePtr): Deleted.
        (JSC::LabelScopePtr::operator!): Deleted.
        (JSC::LabelScopePtr::operator*): Deleted.
        (JSC::LabelScopePtr::operator->): Deleted.
        (JSC::LabelScopePtr::null): Deleted.
        * bytecompiler/NodesCodegen.cpp:
        (JSC::DoWhileNode::emitBytecode):
        (JSC::WhileNode::emitBytecode):
        (JSC::ForNode::emitBytecode):
        (JSC::ForInNode::emitBytecode):
        (JSC::ContinueNode::trivialTarget):
        (JSC::ContinueNode::emitBytecode):
        (JSC::BreakNode::trivialTarget):
        (JSC::BreakNode::emitBytecode):
        (JSC::SwitchNode::emitBytecode):
        (JSC::LabelNode::emitBytecode):

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

        Revert instrumentation from https://bugs.webkit.org/show_bug.cgi?id=170086 that is no longer needed.
        https://bugs.webkit.org/show_bug.cgi?id=170094

        Reviewed by JF Bastien and Keith Miller.

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

2017-04-27  Andy VanWagoner  <thetalecrafter@gmail.com>

        [INTL] Implement the caseFirst option for Intl.Collator
        https://bugs.webkit.org/show_bug.cgi?id=158188

        Reviewed by Geoffrey Garen.

        Implements the caseFirst option and unicode locale extension.
        The caseFirst option explicitly determines whether upper or lower case comes first.

        * runtime/IntlCollator.cpp:
        (JSC::sortLocaleData): Added kf data.
        (JSC::searchLocaleData): Added kf data.
        (JSC::IntlCollator::initializeCollator): Set caseFirst option.
        (JSC::IntlCollator::createCollator): Set new attributes on ICU collator.
        (JSC::IntlCollator::caseFirstString): Added.
        (JSC::IntlCollator::resolvedOptions): Added caseFirst property.
        * runtime/IntlCollator.h:

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

        Fix some RELEASE_ASSERT failures caused by OutOfMemoryErrors.
        https://bugs.webkit.org/show_bug.cgi?id=171404
        <rdar://problem/31876178>

        Reviewed by Saam Barati.

        1. Added some tryAllocate() functions in JSCellInlines.h.
        2. Consolidated the implementations of allocateCell() template functions into a
           single tryAllocateCellHelper() to reduce redundancy and eliminate needing to
           copy-paste for variations of allocateCell and tryAllocateCell.
        3. Changed JSFixedArray::createFromArray() and constructEmptyArray() to check for
           allocation failure and throw an OutOfMemoryError.  It was already possible to
           throw errors from these functions for other reasons.  So, their clients are
           already ready to handle OOMEs.

        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationMaterializeObjectInOSR):
        * runtime/JSCInlines.h:
        * runtime/JSCell.h:
        * runtime/JSCellInlines.h:
        (JSC::tryAllocateCellHelper):
        (JSC::allocateCell):
        (JSC::tryAllocateCell):
        * runtime/JSFixedArray.h:
        (JSC::JSFixedArray::createFromArray):
        (JSC::JSFixedArray::tryCreate):
        (JSC::JSFixedArray::create): Deleted.
        * runtime/JSGlobalObject.h:
        (JSC::constructEmptyArray):

2017-04-27  Joseph Pecoraro  <pecoraro@apple.com>

        Support for promise rejection events (unhandledrejection)
        https://bugs.webkit.org/show_bug.cgi?id=150358
        <rdar://problem/28441651>

        Reviewed by Saam Barati.

        Patch by Joseph Pecoraro and Yusuke Suzuki.

        Implement support for promise.[[PromiseIsHandled]] and the
        HostPromiseRejectionTracker hook for HTML to track promise rejections:
        https://tc39.github.io/ecma262/#sec-host-promise-rejection-tracker
        https://html.spec.whatwg.org/multipage/webappapis.html#unhandled-promise-rejections

        * builtins/BuiltinNames.h:
        New private symbols.

        * builtins/PromiseOperations.js:
        (globalPrivate.newHandledRejectedPromise):
        Utility to create a rejected promise with [[PromiseIsHandled]] to true.

        (globalPrivate.rejectPromise):
        (globalPrivate.initializePromise):
        * builtins/PromisePrototype.js:
        (then):
        Implement standard behavior of [[PromiseIsHandled]] and the host hook.

        * runtime/JSPromise.cpp:
        (JSC::JSPromise::isHandled):
        * runtime/JSPromise.h:
        C++ accessors for the [[PromiseIsHandled]] state.

        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        * bytecode/BytecodeIntrinsicRegistry.h:
        Expose private values for the Reject / Handle enum values in built-ins.

        * jsc.cpp:
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::promiseResolveFunction):
        Add a new GlobalObjectMethodTable hook matching the promise rejection hook.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncHostPromiseRejectionTracker):
        * runtime/JSGlobalObjectFunctions.h:
        Plumb the builtin hook through to the optional GlobalObjectMethodTable hook.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.prototype.createFakeValueDescriptor):
        Silence possible rejected promises created internally via Web Inspector.

2017-04-27  Saam Barati  <sbarati@apple.com>

        B3::FoldPathConstants does not consider the fall through case for Switch
        https://bugs.webkit.org/show_bug.cgi?id=171390

        Reviewed by Filip Pizlo.

        foldPathConstants was not taking into account a Switch's default
        case when it tried to constant propagate the switch's operand value.
        e.g, we incorrectly transformed this code:
        
        ```
        x = argumentGPR0;
        switch (x) {
        case 10: return 20;
        
        case 0:
        default: return x == 0;
        }
        ```
        
        into:
        ```
        x = argumentGPR0;
        switch (x) {
        case 10: return 20;
        
        case 0:
        default: return 1;
        }
        ```
        
        Because we didn't take into account the default case, we incorrectly
        optimized the code as if case 0's block was only reachable if x is
        equal to zero. This is obviously not true, since it's the same block
        as the default case.
        
        This fix ensures that we can run the WebAssembly Tanks demo even when
        we set webAssemblyBBQOptimizationLevel=2.

        * b3/B3FoldPathConstants.cpp:
        * b3/B3SwitchValue.cpp:
        (JSC::B3::SwitchValue::fallThrough):
        (JSC::B3::SwitchValue::removeCase): Deleted.
        * b3/B3SwitchValue.h:
        * b3/testb3.cpp:
        (JSC::B3::testCallFunctionWithHellaArguments):
        (JSC::B3::testSwitchSameCaseAsDefault):
        (JSC::B3::testWasmBoundsCheck):
        (JSC::B3::run):

2017-04-27  Keith Miller  <keith_miller@apple.com>

        WebAssembly: Don't tier up the same function twice
        https://bugs.webkit.org/show_bug.cgi?id=171397

        Reviewed by Filip Pizlo.

        Because we don't CAS the tier up count on function entry/loop backedge and we use the least significant to indicate whether or not tier up has already started we could see the following:

        Threads A and B are running count in memory is (0):

        A: load tier up count (0)
        B: load tier up count (0)
        A: decrement count to -2 and see we need to check for tier up (0)
        A: store -2 to count (-2)
        A: exchangeOr(1) to tier up count (-1)
        B: decrement count to -2 and see we need to check for tier up (-1)
        B: store -2 to count (-2)
        B: exchangeOr(1) to tier up count (-1)

        This would cause us to tier up the same function twice, which we would rather avoid.

        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::emitTierUpCheck):
        * wasm/WasmTierUpCount.h:
        (JSC::Wasm::TierUpCount::TierUpCount):
        (JSC::Wasm::TierUpCount::loopDecrement):
        (JSC::Wasm::TierUpCount::functionEntryDecrement):
        (JSC::Wasm::TierUpCount::shouldStartTierUp):

2017-04-27  Keith Miller  <keith_miller@apple.com>

        REGRESSION (r215843): ASSERTION FAILED: !m_completionTasks[0].first in  JSC::Wasm::Plan::tryRemoveVMAndCancelIfLast(JSC::VM &)
        https://bugs.webkit.org/show_bug.cgi?id=171380

        Reviewed by JF Bastien.

        This patch fixes the association of VMs to Wasm::Plans. For validation
        we want all the completion tasks to be associate with a VM. For BBQ,
        we want the main task to not be associated with any VM.

        * jsc.cpp:
        (functionTestWasmModuleFunctions):
        * wasm/WasmBBQPlan.cpp:
        (JSC::Wasm::BBQPlan::BBQPlan):
        * wasm/WasmBBQPlan.h:
        * wasm/WasmCodeBlock.cpp:
        (JSC::Wasm::CodeBlock::CodeBlock):
        (JSC::Wasm::CodeBlock::compileAsync):
        * wasm/WasmCodeBlock.h:
        (JSC::Wasm::CodeBlock::create):
        * wasm/WasmModule.cpp:
        (JSC::Wasm::makeValidationCallback):
        (JSC::Wasm::Module::validateSync):
        (JSC::Wasm::Module::validateAsync):
        (JSC::Wasm::Module::getOrCreateCodeBlock):
        (JSC::Wasm::Module::compileSync):
        (JSC::Wasm::Module::compileAsync):
        * wasm/WasmModule.h:
        * wasm/WasmOMGPlan.cpp:
        (JSC::Wasm::OMGPlan::OMGPlan):
        (JSC::Wasm::runOMGPlanForIndex):
        * wasm/WasmOMGPlan.h:
        * wasm/WasmPlan.cpp:
        (JSC::Wasm::Plan::Plan):
        (JSC::Wasm::Plan::runCompletionTasks):
        (JSC::Wasm::Plan::addCompletionTask):
        (JSC::Wasm::Plan::tryRemoveVMAndCancelIfLast):
        * wasm/WasmPlan.h:
        (JSC::Wasm::Plan::dontFinalize):
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::constructJSWebAssemblyInstance):
        * wasm/js/WebAssemblyPrototype.cpp:
        (JSC::webAssemblyValidateFunc):

2017-04-27  Saam Barati  <sbarati@apple.com>

        Restore some caching functionality that got accidentally removed when doing Wasm PIC patches
        https://bugs.webkit.org/show_bug.cgi?id=171382

        Reviewed by Keith Miller.

        When I created Wasm::CodeBlock, I accidentally removed caching
        the creation of JSWebAssemblyCodeBlocks. This patch restores it.
        It's worth keeping JSWebAssemblyModule's JSWebAssemblyCodeBlock
        cache because creating a JSWebAssemblyCodeBlock does non trivial
        work by creating the various IC call stubs.

        * wasm/js/JSWebAssemblyCodeBlock.h:
        (JSC::JSWebAssemblyCodeBlock::codeBlock):
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::finalizeCreation):
        (JSC::JSWebAssemblyInstance::create):
        * wasm/js/JSWebAssemblyModule.h:

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

        Audit and fix incorrect uses of JSArray::tryCreateForInitializationPrivate().
        https://bugs.webkit.org/show_bug.cgi?id=171344
        <rdar://problem/31352667>

        Reviewed by Filip Pizlo.

        JSArray::tryCreateForInitializationPrivate() should only be used in performance
        critical paths, and should always be used with care because it creates an
        uninitialized object that needs to be initialized by its client before the object
        can be released into the system.  Before the object is fully initialized:
        a. the client should not re-enter the VM to execute JS code, and
        b. GC should not run.

        This is because until the object is fully initialized, it is an inconsistent
        state that the GC and JS code will not be happy about.

        In this patch, we do the following:

        1. Renamed JSArray::tryCreateForInitializationPrivate() to
           JSArray::tryCreateUninitializedRestricted() because "private" is a bit ambiguous
           and can be confused with APIs that are called freely within WebKit but are
           not meant for clients of WebKit.  In this case, we intend for use of this API
           to be restricted to only a few carefully considered and crafted cases.

        2. Introduce the ObjectInitializationScope RAII object which covers the period
           when the uninitialized object is created and gets initialized.

           ObjectInitializationScope will asserts that either the object is created
           fully initialized (in the case where the object structure is not an "original"
           structure) or if created uninitialized, is fully initialized at the end of
           the scope.

           If the object is created uninitialized, the ObjectInitializationScope also
           ensures that we do not GC nor re-enter the VM to execute JS code.  This is
           achieved by enabling DisallowGC and DisallowVMReentry scopes.

           tryCreateUninitializedRestricted() and initializeIndex() now requires an
           ObjectInitializationScope instance.  The ObjectInitializationScope replaces
           the VM& argument because it can be used to pass the VM& itself.  This is a
           small optimization that makes passing the ObjectInitializationScope free even
           on release builds.

        3. Factored a DisallowScope out of DisallowGC, and make DisallowGC extend it.
           Introduce a DisallowVMReentry class that extends DisallowScope.

        4. Fixed a bug found by the ObjectInitializationScope.  The bug is that there are
           scenarios where the structure passed to tryCreateUninitializedRestricted()
           that may not be an "original" structure.  As a result, initializeIndex() would
           end up allocating new structures, and therefore trigger a GC.

           The fix is to detect that the structure passed to tryCreateUninitializedRestricted()
           is not an "original" one, and pre-initialize the array with 0s.

           This bug was detected by existing tests. Hence, no new test needed.

        5. Replaced all inappropriate uses of tryCreateUninitializedRestricted() with
           tryCreate().  Inappropriate uses here means code that is not in performance
           critical paths.

           Similarly, replaced accompanying uses of initializeIndex() with putDirectIndex().

           This patch is performance neutral (according to the JSC command line benchmarks).

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGOperations.cpp:
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationMaterializeObjectInOSR):
        * heap/DeferGC.cpp:
        * heap/DeferGC.h:
        (JSC::DisallowGC::DisallowGC):
        (JSC::DisallowGC::initialize):
        (JSC::DisallowGC::scopeReentryCount):
        (JSC::DisallowGC::setScopeReentryCount):
        (JSC::DisallowGC::~DisallowGC): Deleted.
        (JSC::DisallowGC::isGCDisallowedOnCurrentThread): Deleted.
        * heap/GCDeferralContextInlines.h:
        (JSC::GCDeferralContext::~GCDeferralContext):
        * heap/Heap.cpp:
        (JSC::Heap::collectIfNecessaryOrDefer):
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoPrivateFuncConcatMemcpy):
        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::createWithInlineFrame):
        (JSC::ClonedArguments::createByCopyingFrom):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/DisallowScope.h: Added.
        (JSC::DisallowScope::DisallowScope):
        (JSC::DisallowScope::~DisallowScope):
        (JSC::DisallowScope::isInEffectOnCurrentThread):
        (JSC::DisallowScope::enable):
        (JSC::DisallowScope::enterScope):
        (JSC::DisallowScope::exitScope):
        * runtime/DisallowVMReentry.cpp: Added.
        * runtime/DisallowVMReentry.h: Added.
        (JSC::DisallowVMReentry::DisallowVMReentry):
        (JSC::DisallowVMReentry::initialize):
        (JSC::DisallowVMReentry::scopeReentryCount):
        (JSC::DisallowVMReentry::setScopeReentryCount):
        * runtime/InitializeThreading.cpp:
        (JSC::initializeThreading):
        * runtime/JSArray.cpp:
        (JSC::JSArray::tryCreateUninitializedRestricted):
        (JSC::JSArray::fastSlice):
        (JSC::JSArray::tryCreateForInitializationPrivate): Deleted.
        * runtime/JSArray.h:
        (JSC::JSArray::tryCreateUninitializedRestricted):
        (JSC::JSArray::tryCreate):
        (JSC::constructArray):
        (JSC::constructArrayNegativeIndexed):
        (JSC::JSArray::tryCreateForInitializationPrivate): Deleted.
        (JSC::createArrayButterfly): Deleted.
        * runtime/JSCellInlines.h:
        (JSC::allocateCell):
        * runtime/JSObject.h:
        (JSC::JSObject::initializeIndex):
        (JSC::JSObject::initializeIndexWithoutBarrier):
        * runtime/ObjectInitializationScope.cpp: Added.
        (JSC::ObjectInitializationScope::ObjectInitializationScope):
        (JSC::ObjectInitializationScope::~ObjectInitializationScope):
        (JSC::ObjectInitializationScope::notifyAllocated):
        (JSC::ObjectInitializationScope::verifyPropertiesAreInitialized):
        * runtime/ObjectInitializationScope.h: Added.
        (JSC::ObjectInitializationScope::ObjectInitializationScope):
        (JSC::ObjectInitializationScope::vm):
        (JSC::ObjectInitializationScope::notifyAllocated):
        * runtime/Operations.h:
        (JSC::isScribbledValue):
        (JSC::scribble):
        * runtime/RegExpMatchesArray.cpp:
        (JSC::createEmptyRegExpMatchesArray):
        * runtime/RegExpMatchesArray.h:
        (JSC::tryCreateUninitializedRegExpMatchesArray):
        (JSC::createRegExpMatchesArray):
        * runtime/VMEntryScope.cpp:
        (JSC::VMEntryScope::VMEntryScope):

2017-04-27  Carlos Garcia Campos  <cgarcia@igalia.com>

        [GTK] Remote inspector should support inspecting targets with previous version of backend commands
        https://bugs.webkit.org/show_bug.cgi?id=171267

        Reviewed by Michael Catanzaro.

        Rename GetTargetList DBus method as SetupInspectorClient since this method is actually called only once by
        client right after connecting to the server. The method now receives the client backend commands hash as
        argument and returns the contents of the backend commands file in case the hash doesn't match with the local
        version.

        * PlatformGTK.cmake: Add RemoteInspectorUtils to compilation.
        * inspector/remote/glib/RemoteInspectorServer.cpp:
        (Inspector::RemoteInspectorServer::setupInspectorClient):
        * inspector/remote/glib/RemoteInspectorServer.h:
        * inspector/remote/glib/RemoteInspectorUtils.cpp: Added.
        (Inspector::backendCommands):
        (Inspector::backendCommandsHash):
        * inspector/remote/glib/RemoteInspectorUtils.h: Added.

2017-04-27  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Handle PhantomSpread in LoadVarargs as the same to the others
        https://bugs.webkit.org/show_bug.cgi?id=171262

        Reviewed by Saam Barati.

        This is follow-up patch after r215720. In that patch, accidentally
        we did not apply the same change to LoadVarargs in argument elimination
        phase. This patch just does the same rewriting to handle PhantomSpread
        correctly.

        * dfg/DFGArgumentsEliminationPhase.cpp:

2017-04-26  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Uint8ClampedArray should be treated like an array, not an object
        https://bugs.webkit.org/show_bug.cgi?id=171364
        <rdar://problem/10873037>

        Reviewed by Sam Weinig.

        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::subtype):
        Treat Uint8ClampedArray (like other Typed Arrays) as an array.

2017-04-26  Saam Barati  <sbarati@apple.com>

        Print Wasm function index in stack trace
        https://bugs.webkit.org/show_bug.cgi?id=171349

        Reviewed by JF Bastien.

        This patch prints a Callee's index in the function index
        space in Error.stack.

        This will lead to stack traces that have lines of text like:
        wasm function index: 4@[wasm code]

        We don't ascribe indices to everything in wasm. Specifically, the
        Wasm->JS call stub callee does not get a name, and neither does
        the JS -> Wasm entrypoint.

        * interpreter/Interpreter.cpp:
        (JSC::GetStackTraceFunctor::operator()):
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::readNonInlinedFrame):
        (JSC::StackVisitor::Frame::functionName):
        * interpreter/StackVisitor.h:
        (JSC::StackVisitor::Frame::wasmFunctionIndex):
        * runtime/StackFrame.cpp:
        (JSC::StackFrame::functionName):
        * runtime/StackFrame.h:
        (JSC::StackFrame::StackFrame):
        (JSC::StackFrame::wasm):
        (JSC::StackFrame::hasBytecodeOffset):
        (JSC::StackFrame::bytecodeOffset):
        * wasm/WasmBBQPlanInlines.h:
        (JSC::Wasm::BBQPlan::initializeCallees):
        * wasm/WasmCallee.cpp:
        (JSC::Wasm::Callee::Callee):
        * wasm/WasmCallee.h:
        (JSC::Wasm::Callee::create):
        (JSC::Wasm::Callee::index):
        * wasm/WasmOMGPlan.cpp:
        (JSC::Wasm::OMGPlan::work):

2017-04-26  Keith Miller  <keith_miller@apple.com>

        Follow up to r215843
        https://bugs.webkit.org/show_bug.cgi?id=171361

        Reviewed by Saam Barati.

        This patch fixes some style comments Saam didn't get a chance to
        request before I landed: https://bugs.webkit.org/show_bug.cgi?id=170134.

        It renames Wasm::CodeBlock::m_wasmEntrypoints to
        m_wasmIndirectCallEntrypoints, as well as fixes some copyrights and
        indentation.

        * wasm/WasmBBQPlan.cpp:
        * wasm/WasmCodeBlock.cpp:
        (JSC::Wasm::CodeBlock::CodeBlock):
        * wasm/WasmCodeBlock.h:
        (JSC::Wasm::CodeBlock::wasmEntrypointLoadLocationFromFunctionIndexSpace):
        * wasm/WasmOMGPlan.cpp:
        (JSC::Wasm::OMGPlan::work):
        * wasm/WasmTierUpCount.h:
        (JSC::Wasm::TierUpCount::TierUpCount):
        (JSC::Wasm::TierUpCount::loopDecrement):
        (JSC::Wasm::TierUpCount::functionEntryDecrement):
        (JSC::Wasm::TierUpCount::shouldStartTierUp):
        (JSC::Wasm::TierUpCount::count):

2017-04-26  Saam Barati  <sbarati@apple.com>

        ASSERTION FAILED: inIndex != notFound in JSC::invalidParameterInSourceAppender()
        https://bugs.webkit.org/show_bug.cgi?id=170924
        <rdar://problem/31721052>

        Reviewed by Mark Lam.

        The error message handler for "in" was searching for the literal
        string "in". However, our parser incorrectly allows escaped characters
        to be part of keywords. So this is parsed as "in" in JSC: "i\u006E".
        It should not be parsed that way. I opened https://bugs.webkit.org/show_bug.cgi?id=171310
        to address this issue.
        
        Regardless, the error message handlers should handle unexpected text gracefully.
        All functions that try to augment error messages with the goal of
        providing a more textual context for the error message should use
        the original error message instead of crashing when they detect
        unexpected text.
        
        This patch also changes the already buggy code that tries to find
        the base of a function call. That could would fail for code like this:
        "zoo.bar("/abc\)*/");". See https://bugs.webkit.org/show_bug.cgi?id=146304
        It would think that the base is "z". However, the algorithm that tries
        to find the base can often tell when it fails, and when it does, it should
        happily return the approximate text error message instead of thinking
        that the base is "z".

        * runtime/ExceptionHelpers.cpp:
        (JSC::functionCallBase):
        (JSC::notAFunctionSourceAppender):
        (JSC::invalidParameterInSourceAppender):

2017-04-26  Keith Miller  <keith_miller@apple.com>

        WebAssembly: Implement tier up
        https://bugs.webkit.org/show_bug.cgi?id=170134

        Reviewed by Filip Pizlo.

        This patch implements tier up for wasm functions. Unlike with JS
        code, wasm code needs to be able to tier up concurrently with the
        running code.  Since JS code is synchronous we can always link on
        the running thread, wasm, however, can run the same code on more
        than one thread. In order to make patching work correctly, we need
        to ensure that all patches of callsites are aligned. On ARM we get
        this for free since every call is a near call. On X86 we ensure
        that the 32-bit relative offset is 32-bit aligned.

        This patch also modifies how Wasm::Plan works. Now Plan is a
        abstract super class and there are two subclasses, which
        correspond to the different tiers of our wasm engine.  The first,
        Build Bytecode Quickly (BBQ) tier, roughly does what the old plan
        code did before.  The new tier, Optimized Machine code Generation
        (OMG), can be called at any point by BBQ code and compiles exactly
        one function. Once an OMGPlan finishes it will link it's code
        internally then reset the instruction cache of all running wasm
        threads, via, a ThreadMessage. Once the instruction caches have
        been reset all the other functions will be patched to call the new
        code.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::ensureCacheLineSpace):
        * assembler/CodeLocation.h:
        (JSC::CodeLocationThreadSafeNearCall::CodeLocationThreadSafeNearCall):
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::threadSafePatchableNearCall):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::threadSafeNearCall):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::threadSafePatchableNearCall):
        * b3/air/AirEmitShuffle.cpp:
        (JSC::B3::Air::ShufflePair::inst):
        (JSC::B3::Air::ShufflePair::opcode): Deleted.
        * b3/air/AirEmitShuffle.h:
        * jsc.cpp:
        (functionTestWasmModuleFunctions):
        * runtime/JSLock.cpp:
        (JSC::JSLock::didAcquireLock):
        * runtime/Options.h:
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::materializeWasmContext):
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        (JSC::Wasm::B3IRGenerator::constant):
        (JSC::Wasm::B3IRGenerator::emitTierUpCheck):
        (JSC::Wasm::B3IRGenerator::addLoop):
        (JSC::Wasm::B3IRGenerator::addTopLevel):
        (JSC::Wasm::B3IRGenerator::addBlock):
        (JSC::Wasm::createJSToWasmWrapper):
        (JSC::Wasm::parseAndCompile):
        * wasm/WasmB3IRGenerator.h:
        * wasm/WasmBBQPlan.cpp: Copied from Source/JavaScriptCore/wasm/WasmPlan.cpp.
        (JSC::Wasm::BBQPlan::BBQPlan):
        (JSC::Wasm::BBQPlan::stateString):
        (JSC::Wasm::BBQPlan::moveToState):
        (JSC::Wasm::BBQPlan::parseAndValidateModule):
        (JSC::Wasm::BBQPlan::prepare):
        (JSC::Wasm::BBQPlan::ThreadCountHolder::ThreadCountHolder):
        (JSC::Wasm::BBQPlan::ThreadCountHolder::~ThreadCountHolder):
        (JSC::Wasm::BBQPlan::compileFunctions):
        (JSC::Wasm::BBQPlan::complete):
        (JSC::Wasm::BBQPlan::work):
        * wasm/WasmBBQPlan.h: Copied from Source/JavaScriptCore/wasm/WasmPlan.h.
        * wasm/WasmBBQPlanInlines.h: Copied from Source/JavaScriptCore/wasm/WasmPlanInlines.h.
        (JSC::Wasm::BBQPlan::initializeCallees):
        * wasm/WasmBinding.cpp:
        (JSC::Wasm::wasmToWasm):
        * wasm/WasmCallee.h:
        (JSC::Wasm::Callee::entrypoint):
        * wasm/WasmCodeBlock.cpp:
        (JSC::Wasm::CodeBlock::CodeBlock):
        * wasm/WasmCodeBlock.h:
        (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace):
        (JSC::Wasm::CodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace):
        (JSC::Wasm::CodeBlock::wasmEntrypointLoadLocationFromFunctionIndexSpace):
        (JSC::Wasm::CodeBlock::tierUpCount):
        (JSC::Wasm::CodeBlock::mode):
        * wasm/WasmFormat.h:
        (JSC::Wasm::CallableFunction::CallableFunction):
        (JSC::Wasm::CallableFunction::offsetOfWasmEntrypointLoadLocation):
        * wasm/WasmMachineThreads.cpp: Copied from Source/JavaScriptCore/wasm/WasmPlanInlines.h.
        (JSC::Wasm::wasmThreads):
        (JSC::Wasm::startTrackingCurrentThread):
        (JSC::Wasm::resetInstructionCacheOnAllThreads):
        * wasm/WasmMachineThreads.h: Copied from Source/JavaScriptCore/wasm/WasmCallee.h.
        * wasm/WasmModule.cpp:
        (JSC::Wasm::makeValidationResult):
        (JSC::Wasm::makeValidationCallback):
        (JSC::Wasm::Module::validateSync):
        (JSC::Wasm::Module::validateAsync):
        * wasm/WasmModule.h:
        (JSC::Wasm::Module::codeBlockFor):
        * wasm/WasmOMGPlan.cpp: Added.
        (JSC::Wasm::OMGPlan::OMGPlan):
        (JSC::Wasm::OMGPlan::work):
        (JSC::Wasm::runOMGPlanForIndex):
        * wasm/WasmOMGPlan.h: Copied from Source/JavaScriptCore/wasm/WasmPlanInlines.h.
        * wasm/WasmPlan.cpp:
        (JSC::Wasm::Plan::Plan):
        (JSC::Wasm::Plan::runCompletionTasks):
        (JSC::Wasm::Plan::addCompletionTask):
        (JSC::Wasm::Plan::waitForCompletion):
        (JSC::Wasm::Plan::tryRemoveVMAndCancelIfLast):
        (JSC::Wasm::Plan::fail):
        (JSC::Wasm::Plan::stateString): Deleted.
        (JSC::Wasm::Plan::moveToState): Deleted.
        (JSC::Wasm::Plan::parseAndValidateModule): Deleted.
        (JSC::Wasm::Plan::prepare): Deleted.
        (JSC::Wasm::Plan::ThreadCountHolder::ThreadCountHolder): Deleted.
        (JSC::Wasm::Plan::ThreadCountHolder::~ThreadCountHolder): Deleted.
        (JSC::Wasm::Plan::compileFunctions): Deleted.
        (JSC::Wasm::Plan::complete): Deleted.
        * wasm/WasmPlan.h:
        (JSC::Wasm::Plan::exports): Deleted.
        (JSC::Wasm::Plan::internalFunctionCount): Deleted.
        (JSC::Wasm::Plan::takeModuleInformation): Deleted.
        (JSC::Wasm::Plan::takeCallLinkInfos): Deleted.
        (JSC::Wasm::Plan::takeWasmToWasmExitStubs): Deleted.
        (JSC::Wasm::Plan::hasWork): Deleted.
        (JSC::Wasm::Plan::hasBeenPrepared): Deleted.
        * wasm/WasmTierUpCount.h: Renamed from Source/JavaScriptCore/wasm/WasmPlanInlines.h.
        (JSC::Wasm::TierUpCount::TierUpCount):
        (JSC::Wasm::TierUpCount::loopDecrement):
        (JSC::Wasm::TierUpCount::functionEntryDecrement):
        (JSC::Wasm::TierUpCount::shouldStartTierUp):
        (JSC::Wasm::TierUpCount::count):
        * wasm/WasmWorklist.cpp:
        * wasm/WasmWorklist.h:
        (JSC::Wasm::Worklist::nextTicket):
        * wasm/js/JSWebAssemblyCodeBlock.cpp:
        * wasm/js/JSWebAssemblyCodeBlock.h:
        (JSC::JSWebAssemblyCodeBlock::wasmEntrypointLoadLocationFromFunctionIndexSpace):
        (JSC::JSWebAssemblyCodeBlock::wasmToJsCallStubForImport):
        (JSC::JSWebAssemblyCodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace): Deleted.
        * wasm/js/JSWebAssemblyTable.cpp:
        (JSC::JSWebAssemblyTable::setFunction):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::WebAssemblyFunction::create):
        (JSC::WebAssemblyFunction::WebAssemblyFunction):
        * wasm/js/WebAssemblyFunction.h:
        (JSC::WebAssemblyFunction::signatureIndex):
        (JSC::WebAssemblyFunction::wasmEntrypointLoadLocation):
        (JSC::WebAssemblyFunction::callableFunction):
        (JSC::WebAssemblyFunction::offsetOfWasmEntrypointLoadLocation):
        (JSC::WebAssemblyFunction::wasmEntrypoint): Deleted.
        (JSC::WebAssemblyFunction::offsetOfWasmEntrypoint): Deleted.
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::link):
        (JSC::WebAssemblyModuleRecord::evaluate):
        * wasm/js/WebAssemblyPrototype.cpp:
        (JSC::webAssemblyValidateFunc):
        * wasm/js/WebAssemblyWrapperFunction.cpp:
        (JSC::WebAssemblyWrapperFunction::WebAssemblyWrapperFunction):
        (JSC::WebAssemblyWrapperFunction::create):
        * wasm/js/WebAssemblyWrapperFunction.h:
        (JSC::WebAssemblyWrapperFunction::signatureIndex):
        (JSC::WebAssemblyWrapperFunction::wasmEntrypointLoadLocation):
        (JSC::WebAssemblyWrapperFunction::callableFunction):
        (JSC::WebAssemblyWrapperFunction::wasmEntrypoint): Deleted.

2017-04-26  Caitlin Potter  <caitp@igalia.com>

        [JSC] fix RETURN_IF_EXCEPTION() placement in ownPropertyKeys()
        https://bugs.webkit.org/show_bug.cgi?id=171330

        Reviewed by Mark Lam.

        Ensure RETURN_IF_EXCEPTION() following invokation of the
        filterPropertyIfNeeded() lambda.

        * runtime/ObjectConstructor.cpp:
        (JSC::ownPropertyKeys):

2017-04-26  Caitlin Potter  <caitp@igalia.com>

        [JSC] Object.keys() must discard property names with no PropertyDescriptor
        https://bugs.webkit.org/show_bug.cgi?id=171291

        Reviewed by Yusuke Suzuki.

        Proxy objects can produce an arbitrary list of property names from the
        "ownKeys" trap, however the Object.keys() algorithm is required to
        discard names which do not have a PropertyDescriptor. This also
        applies to other uses of the EnumerableOwnProperties() algorithm
        (https://tc39.github.io/ecma262/#sec-enumerableownproperties)

        Related to https://bugs.chromium.org/p/v8/issues/detail?id=6290

        * runtime/ObjectConstructor.cpp:
        (JSC::ownPropertyKeys):

2017-04-25  Andy VanWagoner  <thetalecrafter@gmail.com>

        Unhandled enumeration values in IntlDateTimeFormat.cpp
        https://bugs.webkit.org/show_bug.cgi?id=171241

        Reviewed by JF Bastien.

        Added some missing cases of the UDateFormatField to partTypeString,
        and made them conditional to the ICU version that added them.
        This should remove the warnings that appear on platform builds using the
        newer system ICU headers.

        * runtime/IntlDateTimeFormat.cpp:
        (JSC::IntlDateTimeFormat::partTypeString):

2017-04-25  Commit Queue  <commit-queue@webkit.org>

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

        "It broke JSBench" (Requested by saamyjoon on #webkit).

        Reverted changeset:

        "[ES6]. Implement Annex B.3.3 function hoisting rules for
        eval"
        https://bugs.webkit.org/show_bug.cgi?id=163208
        http://trac.webkit.org/changeset/215476

2017-04-25  Saam Barati  <sbarati@apple.com>

        JSArray::isArrayPrototypeIteratorProtocolFastAndNonObservable is wrong because it does not do the necessary checks on the base object
        https://bugs.webkit.org/show_bug.cgi?id=171150
        <rdar://problem/31771880>

        Reviewed by Sam Weinig.

        This patch fixes a huge oversight from the patch that introduced
        op_spread/Spread. The original patch did not account for the
        base object having Symbol.iterator or getters that could
        change the iterator protocol. This patch fixes the oversight both
        in the C code, as well as the DFG/FTL backends. We only perform
        the memcpy version of spread if we've proven that it's guaranteed
        to be side-effect free (no indexed getters), and if the iterator
        protocol is guaranteed to be the original protocol. To do this, we
        must prove that:
        1. The protocol on Array.prototype hasn't changed (this is the same as the
        introductory patch for op_spread).
        2. The base object's __proto__ is Array.prototype
        3. The base object does not have indexed getters
        4. The base object does not have Symbol.iterator property.

        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::canDoFastSpread):
        * dfg/DFGGraph.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileSpread):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileSpread):
        * runtime/JSArray.cpp:
        (JSC::JSArray::isIteratorProtocolFastAndNonObservable):
        * runtime/JSArray.h:
        * runtime/JSArrayInlines.h:
        (JSC::JSArray::isIteratorProtocolFastAndNonObservable): Deleted.
        * runtime/JSGlobalObject.h:
        * runtime/JSGlobalObjectInlines.h:
        (JSC::JSGlobalObject::isArrayPrototypeIteratorProtocolFastAndNonObservable):
        (JSC::JSGlobalObject::isArrayIteratorProtocolFastAndNonObservable): Deleted.

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

        Array.prototype.slice() should ensure that end >= begin.
        https://bugs.webkit.org/show_bug.cgi?id=170989
        <rdar://problem/31705652>

        Reviewed by Saam Barati.

        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncSlice):

2017-04-25  Don Olmstead  <don.olmstead@am.sony.com>

        [Win] Use Clang's __has_declspec_attribute for export macros
        https://bugs.webkit.org/show_bug.cgi?id=171240

        Reviewed by Alex Christensen.

        * runtime/JSExportMacros.h:

2017-04-25  Saam Barati  <sbarati@apple.com>

        Unreviewed. Attempt armv7k build fix after r215720

        I think we're just missing an include for the definition of ExecState::r().

        * runtime/JSFixedArray.cpp:

2017-04-25  Daniel Bates  <dabates@apple.com>

        [Cocoa][Win] Enable of X-Content-Type-Options: nosniff header
        https://bugs.webkit.org/show_bug.cgi?id=136452
        <rdar://problem/23412620>

        Reviewed by Brent Fulgham.

        Enable X-Content-Type-Options: nosniff on Mac, iOS and Windows platforms.

        * Configurations/FeatureDefines.xcconfig:

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

        Local CSE wrongly CSEs array accesses with different result types.
        https://bugs.webkit.org/show_bug.cgi?id=170990
        <rdar://problem/31705945>

        Reviewed by Saam Barati.

        The fix is to use different LocationKind enums for the different type of array
        result types.  This makes the HeapLocation values different based on the result
        types, and allows CSE to discern between them.

        * dfg/DFGCSEPhase.cpp:
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGHeapLocation.h:
        (JSC::DFG::indexedPropertyLocForResultType):

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

        Make DFG SpeculatedType dumps easier to read.
        https://bugs.webkit.org/show_bug.cgi?id=171280

        Reviewed by Saam Barati.

        Adding a pretty printer to insert |s between each type string and changing the
        dumped strings to match the SpeculatedType names case-wise.

        * bytecode/SpeculatedType.cpp:
        (JSC::PrettyPrinter::PrettyPrinter):
        (JSC::PrettyPrinter::print):
        (JSC::dumpSpeculation):
        * bytecode/SpeculatedType.h:

2017-04-25  JF Bastien  <jfbastien@apple.com>

        lowerStackArgs: check Arg::addr.isValidForm when falling back to SP offsets
        https://bugs.webkit.org/show_bug.cgi?id=171278

        Reviewed by Filip Pizlo.

        lowerStackArgs checked that the FP offsets it tries to generate
        are valid form, but didn't check that the fallback was valid
        form. This lead to stackAddr's assertion being dead, and the
        MaroAssembler asserting way later on move / add when handed a huge
        immediate.

        * b3/air/AirArg.cpp:
        (JSC::B3::Air::Arg::stackAddrImpl):

2017-04-25  Zan Dobersek  <zdobersek@igalia.com>

        [aarch64] moveConditionally32(), moveConditionallyTest32() should move from/to 64-bit registers
        https://bugs.webkit.org/show_bug.cgi?id=170891

        Reviewed by Saam Barati.

        moveConditionally32() and moveConditionallyTest32() operations in
        MacroAssemblerARM64 properly perform comparisons and tests on 32-bit
        values, but end up performing the moves from and to 32-bit registers.

        Move operations should instead be done on 64-bit registers, just like
        on the X86_64 platform. This is achieved by specifying 64 as the data
        size for the csel instructions.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::moveConditionally32):
        (JSC::MacroAssemblerARM64::moveConditionallyTest32):

2017-04-24  Joseph Pecoraro  <pecoraro@apple.com>

        test262: test262/test/language/expressions/object/method-definition/early-errors-object-method-duplicate-parameters.js
        https://bugs.webkit.org/show_bug.cgi?id=171190

        Reviewed by Saam Barati.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
        (JSC::BytecodeGenerator::emitNewFunction):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::FunctionNode::emitBytecode):
        (JSC::Scope::setSourceParseMode):
        * parser/ParserModes.h:
        (JSC::isFunctionParseMode):
        (JSC::isMethodParseMode):
        (JSC::isGeneratorOrAsyncFunctionWrapperParseMode):
        (JSC::isGeneratorParseMode):
        (JSC::isGeneratorWrapperParseMode):
        * runtime/FunctionExecutable.h:
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::getOwnPropertySlot):
        Add a new GeneratorWrapperMethodMode parse mode. The other function types
        (async, arrow) already have a FunctionMode and a MethodMode. Give
        generators one as well. This lets isMethodParseMode actually be accurate.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseInner):
        (JSC::Parser<LexerType>::isArrowFunctionParameters):
        (JSC::Parser<LexerType>::parseFormalParameters):
        (JSC::stringForFunctionMode):
        (JSC::Parser<LexerType>::parseFunctionParameters):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parsePropertyMethod):
        * parser/Parser.h:
        Add a duplicate parameter failure if there are duplicate parameters
        in method syntax.

2017-04-24  Andy VanWagoner  <thetalecrafter@gmail.com>

        Clean up ICU headers
        https://bugs.webkit.org/show_bug.cgi?id=170997

        Reviewed by JF Bastien.

        Update all icu headers to 55.1

        * icu/LICENSE: Update copyright
        * icu/README: Explain ICU headers for OS X better
        * icu/unicode/localpointer.h:
        (LocalPointer::LocalPointer):
        (LocalPointer::adoptInsteadAndCheckErrorCode):
        * icu/unicode/platform.h:
        * icu/unicode/putil.h:
        * icu/unicode/ucal.h:
        * icu/unicode/uchar.h:
        * icu/unicode/ucnv.h:
        * icu/unicode/ucol.h:
        * icu/unicode/uconfig.h:
        * icu/unicode/ucurr.h:
        * icu/unicode/udatpg.h:
        * icu/unicode/udisplaycontext.h:
        * icu/unicode/uformattable.h:
        * icu/unicode/uloc.h:
        * icu/unicode/umachine.h:
        * icu/unicode/unum.h:
        * icu/unicode/unumsys.h:
        * icu/unicode/urename.h:
        * icu/unicode/uscript.h:
        * icu/unicode/uset.h:
        * icu/unicode/ustring.h:
        * icu/unicode/utf8.h:
        * icu/unicode/utypes.h:

2017-04-24  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Use JSFixedArray directly when using call_varargs
        https://bugs.webkit.org/show_bug.cgi?id=171057

        Reviewed by Saam Barati.

        Previously we always emit new_array_with_spread when calling call(...args).
        But this array is unnecessary if varargs operation can handle Spread directly.

        This patch implements a peep-hole optimization in the bytecode compiler layer
        to omit new_array_with_spread. This is very simple and effective because this
        peep-hole optimization is quite common when using (...args) style calls and
        this optimization works all the tiers. While we can implement the phase to
        omit this NewArrayWithSpread in argument elimination phase, it only works
        for FTL. While such an optimization can work with complex data flow, this
        peep-hole optimization can optimize a common case easily.

        For now, Spread and PhantomSpread can be directly drained by CallVarargs
        and LoadVarargs related operations. We modify DFG and FTL to handle this correctly.

        This shows six-speed improvement.

            spread.es6                 89.4300+-2.0236     ^     69.6015+-1.7278        ^ definitely 1.2849x faster
            spread-generator.es6      344.7879+-5.9147     ^    331.2712+-6.8610        ^ definitely 1.0408x faster

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitCall):
        (JSC::BytecodeGenerator::emitConstruct):
        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGPreciseLocalClobberize.h:
        (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileSpread):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
        (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs):
        (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargsWithSpread):
        * interpreter/Interpreter.cpp:
        (JSC::sizeOfVarargs):
        (JSC::loadVarargs):
        * parser/Nodes.h:
        (JSC::ArrayNode::elements):
        * runtime/JSFixedArray.cpp:
        (JSC::JSFixedArray::copyToArguments):
        * runtime/JSFixedArray.h:

2017-04-24  Yusuke Suzuki  <utatane.tea@gmail.com>

        [WTF] Move JSC tools/StackTrace to WTF and unify stack trace dump code
        https://bugs.webkit.org/show_bug.cgi?id=171199

        Reviewed by Mark Lam.

        This patch adds a utility method to produce demangled names with dladdr.
        It fixes several memory leaks because the result of abi::__cxa_demangle()
        needs to be `free`-ed.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::appendAPIBacktrace):
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::StackFrame::displayName):
        * tools/CellProfile.h:
        * tools/CodeProfile.cpp:
        (JSC::CodeProfile::report):
        (JSC::symbolName): Deleted.

2017-04-24  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: ObjC RWIProtocol codegen should better handle optional members
        https://bugs.webkit.org/show_bug.cgi?id=171251
        <rdar://problem/31697002>

        Reviewed by Brian Burg.

        * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
        (ObjCProtocolTypesImplementationGenerator._generate_getter_for_member):
        * inspector/scripts/codegen/objc_generator.py:
        (ObjCGenerator.protocol_to_objc_expression_for_member):
        (ObjCGenerator.protocol_to_objc_code_block_for_object_member):
        Always be safe and nil check object property accesses, optional or not.

        * inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result:
        * inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:
        Rebaselined inspector generator tests.

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

        ASSERTION FAILED: m_table seen with workers/wasm-hashset LayoutTests
        https://bugs.webkit.org/show_bug.cgi?id=171119
        <rdar://problem/31760635>

        Reviewed by Keith Miller.

        The HashSet of timer set notification callbacks can be accessed
        and augmented simultaneously from different threads. e.g, the worker
        thread can augment it while the wasm compilation thread will
        access it. Therefore, accesses must be guarded by a lock.

        * runtime/JSRunLoopTimer.cpp:
        (JSC::JSRunLoopTimer::scheduleTimer):
        (JSC::JSRunLoopTimer::addTimerSetNotification):
        (JSC::JSRunLoopTimer::removeTimerSetNotification):
        * runtime/JSRunLoopTimer.h:

2017-04-24  Joseph Pecoraro  <pecoraro@apple.com>

        test262: test262/test/language/computed-property-names/class/static/getter-prototype.js
        https://bugs.webkit.org/show_bug.cgi?id=170897

        Reviewed by Saam Barati.

        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createArguments):
        (JSC::ASTBuilder::createArgumentsList):
        Reorder so all the createProperty methods are grouped together.

        * parser/Parser.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parseProperty):
        (JSC::Parser<LexerType>::parseGetterSetter):
        Refine the conditions for syntax errors for getter/setter
        properties names. "prototype" is not allowed as a static
        and "constructor" is not all when non-static.

        * runtime/JSObject.cpp:
        (JSC::JSObject::putGetter):
        (JSC::JSObject::putSetter):
        Throw exceptions. These methods are only used by this path
        via op_put_getter_by_val / op_put_setter_by_val.

2017-04-24  Joseph Pecoraro  <pecoraro@apple.com>

        test262: test262/test/language/statements/for-of/dstr-array-elem-init-fn-name-arrow.js
        https://bugs.webkit.org/show_bug.cgi?id=171160

        Reviewed by JF Bastien.

        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::tryInferNameInPattern):
        (JSC::ASTBuilder::tryInferNameInPatternWithIdentifier):
        We supported getting the name from a BindingNode.
        We extend this to support getting the name from a
        ResolveNode inside of an AssignmentElementNode.

        * parser/Nodes.h:
        (JSC::DestructuringPatternNode::isAssignmentElementNode):
        (JSC::AssignmentElementNode::isAssignmentElementNode):
        Make it possible to identify an assignment element node.

2017-04-24  Alex Christensen  <achristensen@webkit.org>

        Reduce copies and allocations in SharedBuffer::append
        https://bugs.webkit.org/show_bug.cgi?id=170956

        Reviewed by Andreas Kling.

        * runtime/ArrayBuffer.h:

2017-04-24  Carlos Garcia Campos  <cgarcia@igalia.com>

        [GTK] Switch to use ENABLE_REMOTE_INSPECTOR instead of ENABLE_INSPECTOR_SERVER for the remote inspector
        https://bugs.webkit.org/show_bug.cgi?id=166680

        Reviewed by Michael Catanzaro.

        Add GTK+ port implementation of RemoteInspector.

        * PlatformGTK.cmake:
        * inspector/remote/RemoteConnectionToTarget.h:
        * inspector/remote/RemoteInspector.h:
        * inspector/remote/glib/RemoteConnectionToTargetGlib.cpp: Added.
        (Inspector::RemoteConnectionToTarget::RemoteConnectionToTarget):
        (Inspector::RemoteConnectionToTarget::~RemoteConnectionToTarget):
        (Inspector::RemoteConnectionToTarget::setup):
        (Inspector::RemoteConnectionToTarget::sendMessageToTarget):
        (Inspector::RemoteConnectionToTarget::close):
        (Inspector::RemoteConnectionToTarget::targetClosed):
        (Inspector::RemoteConnectionToTarget::targetIdentifier):
        (Inspector::RemoteConnectionToTarget::sendMessageToFrontend):
        * inspector/remote/glib/RemoteInspectorGlib.cpp: Added.
        (Inspector::RemoteInspector::singleton):
        (Inspector::RemoteInspector::RemoteInspector):
        (Inspector::RemoteInspector::start):
        (Inspector::RemoteInspector::stopInternal):
        (Inspector::RemoteInspector::setupConnection):
        (Inspector::dbusConnectionCallAsyncReadyCallback):
        (Inspector::RemoteInspector::listingForInspectionTarget):
        (Inspector::RemoteInspector::listingForAutomationTarget):
        (Inspector::RemoteInspector::pushListingsNow):
        (Inspector::RemoteInspector::pushListingsSoon):
        (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
        (Inspector::RemoteInspector::sendAutomaticInspectionCandidateMessage):
        (Inspector::RemoteInspector::sendMessageToRemote):
        (Inspector::RemoteInspector::receivedGetTargetListMessage):
        (Inspector::RemoteInspector::receivedSetupMessage):
        (Inspector::RemoteInspector::receivedDataMessage):
        (Inspector::RemoteInspector::receivedCloseMessage):
        (Inspector::RemoteInspector::setup):
        (Inspector::RemoteInspector::sendMessageToTarget):
        (Inspector::RemoteInspector::requestAutomationSession):
        * inspector/remote/glib/RemoteInspectorServer.cpp: Added.
        (Inspector::generateConnectionID):
        (Inspector::RemoteInspectorServer::singleton):
        (Inspector::RemoteInspectorServer::~RemoteInspectorServer):
        (Inspector::RemoteInspectorServer::interfaceInfo):
        (Inspector::RemoteInspectorServer::start):
        (Inspector::RemoteInspectorServer::newConnectionCallback):
        (Inspector::RemoteInspectorServer::connectionClosedCallback):
        (Inspector::RemoteInspectorServer::newConnection):
        (Inspector::dbusConnectionCallAsyncReadyCallback):
        (Inspector::RemoteInspectorServer::setTargetList):
        (Inspector::RemoteInspectorServer::clientConnectionClosedCallback):
        (Inspector::RemoteInspectorServer::getTargetList):
        (Inspector::RemoteInspectorServer::setup):
        (Inspector::RemoteInspectorServer::close):
        (Inspector::RemoteInspectorServer::clientConnectionClosed):
        (Inspector::RemoteInspectorServer::connectionClosed):
        (Inspector::RemoteInspectorServer::sendMessageToBackend):
        (Inspector::RemoteInspectorServer::sendMessageToFrontend):
        (Inspector::RemoteInspectorServer::startAutomationSession):
        * inspector/remote/glib/RemoteInspectorServer.h: Added.
        (Inspector::RemoteInspectorServer::isRunning):

2017-04-24  Joseph Pecoraro  <pecoraro@apple.com>

        test262: test262/test/language/expressions/generators/yield-as-label.js
        https://bugs.webkit.org/show_bug.cgi?id=170979

        Reviewed by Saam Barati.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseVariableDeclarationList):
        (JSC::Parser<LexerType>::parseDestructuringPattern):
        (JSC::Parser<LexerType>::parseFormalParameters):
        Converge on "Cannot" instead of "Can't" in error messages.

        (JSC::Parser<LexerType>::parseFunctionInfo):
        Disallow "yield" as the generator function name in function expressions.
        This refers to the difference between Declaration and Expression, where
        only GeneratorExpression explicitly has [+Yield] disallowing yield for
        the generator name:

            GeneratorDeclaration[Yield, Await, Default]:
                function * BindingIdentifier[?Yield, ?Await] ...

            GeneratorExpression:
                function * BindingIdentifier[+Yield, ~Await]opt ...

        (JSC::Parser<LexerType>::parseExpressionOrLabelStatement):
        Disallow "yield" as a label name in strict mode or inside a generator.

        (JSC::Parser<LexerType>::parseProperty):
        Disallow "yield" or any keyword in object literal shorthands.

        * parser/Parser.h:
        (JSC::Parser::getToken):
        (JSC::Parser::isDisallowedIdentifierLet):
        (JSC::Parser::isDisallowedIdentifierYield):
        (JSC::Parser::disallowedIdentifierLetReason):
        (JSC::Parser::disallowedIdentifierYieldReason):
        Follow pattern for improved error messages based on context.

2017-04-23  Commit Queue  <commit-queue@webkit.org>

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

        Possible unintended commit. This patch was on the wrong bug.
        (Requested by JoePeck on #webkit).

        Reverted changeset:

        "test262: test262/test/language/expressions/generators/yield-
        as-label.js"
        https://bugs.webkit.org/show_bug.cgi?id=170979
        http://trac.webkit.org/changeset/215674

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

        test262: test262/test/built-ins/Number/prototype/toPrecision/nan.js
        https://bugs.webkit.org/show_bug.cgi?id=171197

        Reviewed by Saam Barati.

        * runtime/NumberPrototype.cpp:
        (JSC::numberProtoFuncToExponential):
        (JSC::numberProtoFuncToFixed):
        (JSC::numberProtoFuncToPrecision):
        Refine the order of operations to match the spec.

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

        test262: test262/test/language/expressions/generators/yield-as-label.js
        https://bugs.webkit.org/show_bug.cgi?id=170979

        Reviewed by Saam Barati.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseVariableDeclarationList):
        (JSC::Parser<LexerType>::parseDestructuringPattern):
        (JSC::Parser<LexerType>::parseFormalParameters):
        Converge on "Cannot" instead of "Can't" in error messages.

        (JSC::Parser<LexerType>::parseFunctionInfo):
        Disallow "yield" as the generator function name in function expressions.
        This refers to the difference between Declaration and Expression, where
        only GeneratorExpression explicitly has [+Yield] disallowing yield for
        the generator name:

            GeneratorDeclaration[Yield, Await, Default]:
                function * BindingIdentifier[?Yield, ?Await] ...

            GeneratorExpression:
                function * BindingIdentifier[+Yield, ~Await]opt ...

        (JSC::Parser<LexerType>::parseExpressionOrLabelStatement):
        Disallow "yield" as a label name in strict mode or inside a generator.

        (JSC::Parser<LexerType>::parseProperty):
        Disallow "yield" or any keyword in object literal shorthands.

        * parser/Parser.h:
        (JSC::Parser::getToken):
        (JSC::Parser::isDisallowedIdentifierLet):
        (JSC::Parser::isDisallowedIdentifierYield):
        (JSC::Parser::disallowedIdentifierLetReason):
        (JSC::Parser::disallowedIdentifierYieldReason):
        Follow pattern for improved error messages based on context.

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

        test262: test262/test/built-ins/Number/parseFloat.js
        https://bugs.webkit.org/show_bug.cgi?id=171193

        Reviewed by Yusuke Suzuki.

        * runtime/CommonIdentifiers.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::parseFloatFunction):
        Expose parseFloat on the global object to be shared with Number constructor.

        * runtime/NumberConstructor.cpp:
        (JSC::NumberConstructor::finishCreation):
        parseFloat uses the same value as the global parseFloat.

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

        [JSC] Use DoublyLinkedList for MachineThread
        https://bugs.webkit.org/show_bug.cgi?id=171171

        Reviewed by Mark Lam.

        MachineThread can use WTF::DoublyLinkedList to simplify
        its implementation. We should not use Vector<> etc. since
        we do not want to call allocations during suspending and
        resuming threads.

        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::MachineThreads):
        (JSC::MachineThreads::~MachineThreads):
        (JSC::MachineThreads::addCurrentThread):
        (JSC::MachineThreads::removeThreadIfFound):
        (JSC::MachineThreads::MachineThread::MachineThread):
        (JSC::MachineThreads::tryCopyOtherThreadStacks):
        * heap/MachineStackMarker.h:
        (JSC::MachineThreads::threadsListHead):
        * runtime/SamplingProfiler.cpp:
        (JSC::FrameWalker::isValidFramePointer):
        * runtime/VMTraps.cpp:
        (JSC::findActiveVMAndStackBounds):

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

        WebAssembly: Module.exports, Module.imports, Module.customSections are wrong
        https://bugs.webkit.org/show_bug.cgi?id=171078

        Reviewed by Saam Barati.

        They're static properties of Module, not instance properties of a module.
        https://github.com/WebAssembly/design/blob/master/JS.md#webassemblymoduleexports

        * wasm/js/WebAssemblyModuleConstructor.cpp:
        (JSC::webAssemblyModuleCustomSections):
        (JSC::webAssemblyModuleImports):
        (JSC::webAssemblyModuleExports):
        * wasm/js/WebAssemblyModulePrototype.cpp:
        (JSC::webAssemblyModuleProtoCustomSections): Deleted.
        (JSC::webAssemblyModuleProtoImports): Deleted.
        (JSC::webAssemblyModuleProtoExports): Deleted.

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

        SharedArrayBuffer-opt.js fails with Briggs
        https://bugs.webkit.org/show_bug.cgi?id=170948
        <rdar://problem/31740568>

        Reviewed by Michael Saboff.

        The bug was not actually with Briggs, but instead was with
        our X86-64 MacroAssembler. Michael fixed the bug here:
        https://trac.webkit.org/changeset/215618/webkit
        
        The issue was we weren't adding the REX byte for AtomicXchg8,
        leading to the incorrect encoding for the result register depending
        on which register it was. If you look at this code, you'll see the issue:

          Int32 @38 = AtomicXchg(@59, @64, width = 8, range = 0, fenceRange = 0, ControlDependent|Fence|Writes:0|Reads:0, DFG:@49)
              AtomicXchg8 %rsi, (%rax,%rdx), @38
                  0x2dcb5bc0015e: lock xchg %dh, (%rax,%rdx)
          Int32 @66 = Const32(255, DFG:@49)
          Int32 @67 = BitAnd(@38, $255(@66), DFG:@49)
              ZeroExtend8To32 %rsi, %rax, @67
                  0x2dcb5bc00162: movzx %sil, %eax

        Air thought the result was in the lower 8 bits of %rsi,
        however, the code we emitted stored it in the [8-15] bits
        of %rdx. Since this issue is fixed, I'm turning Briggs back
        on.

        * b3/air/AirAllocateRegistersByGraphColoring.h:
        (JSC::B3::Air::useIRC):

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

        Refactor MASM probe to allow printing of custom types.
        https://bugs.webkit.org/show_bug.cgi?id=171101

        Reviewed by JF Bastien.

        For example, this allows us to add MASM printing of CodeBlock* and Air::Args.

        In general, MASM print can be used like dataLog, except that it generates JITted
        code for doing the dataLogging later when the JITted code runs.  MASM print can
        print any value type that a specialized Printer template or a setPrinter()
        function implemented for that type.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/MacroAssembler.h:

        * assembler/MacroAssemblerPrinter.cpp:
        (JSC::Printer::printAllRegisters):
        (JSC::Printer::printPCRegister):
        (JSC::Printer::printRegisterID):
        (JSC::Printer::printFPRegisterID):
        (JSC::Printer::printAddress):
        (JSC::Printer::printMemory):
        (JSC::Printer::printCallback):
        (JSC::printIndent): Deleted.
        (JSC::printCPU): Deleted.
        (JSC::printCPURegisters): Deleted.
        (JSC::printPC): Deleted.
        (JSC::printRegister): Deleted.
        (JSC::printMemory): Deleted.
        (JSC::MacroAssemblerPrinter::printCallback): Deleted.
        * assembler/MacroAssemblerPrinter.h:
        (JSC::AllRegisters::AllRegisters):
        (JSC::Printer::Printer<AllRegisters>::Printer):
        (JSC::Printer::Printer<PCRegister>::Printer):
        (JSC::Printer::Printer<MacroAssembler::RegisterID>::Printer):
        (JSC::Printer::Printer<MacroAssembler::FPRegisterID>::Printer):
        (JSC::Printer::Printer<MacroAssembler::Address>::Printer):
        (JSC::Printer::Printer<Memory>::Printer):
        (JSC::Printer::Printer<MemWord<IntType>>::Printer):
        (JSC::MacroAssembler::print):
        (JSC::MacroAssemblerPrinter::print): Deleted.
        (JSC::MacroAssemblerPrinter::PrintArg::PrintArg): Deleted.
        (JSC::MacroAssemblerPrinter::appendPrintArg): Deleted.
        - Refactored to move the underlying PrintRecord (and associated data structures)
          out to Printer.cpp/h.
        - MacroAssemblerPrinter.cpp/h now only add custom Printers for MASM types like
          RegisterID and Memory.  It also defines the implementation of
          MacroAssembler::print().

          As before, JIT code that wishes to use MacroAssembler::print() needs to
          #include "MacroAssemblerPrinter.h".

        - Also added the ability to specify an optional indentation (in number of chars)
          when MASM printing AllRegisters.  This is useful because AllRegisters prints
          a block of data unlike other printers which print inline.

        * assembler/Printer.cpp: Added.
        (JSC::Printer::printConstCharString):
        (JSC::Printer::printIntptr):
        (JSC::Printer::printUintptr):
        (JSC::Printer::printPointer):
        (JSC::Printer::setPrinter):
        * assembler/Printer.h: Added.
        (JSC::Printer::Context::Context):
        (JSC::Printer::PrintRecord::PrintRecord):
        (JSC::Printer::appendPrinter):
        (JSC::Printer::makePrintRecordList):
        (JSC::Printer::Printer<RawPointer>::Printer):
        (JSC::Printer::setPrinter):
        (JSC::Printer::Printer::Printer):
        - Data structures for creating a list of PrintRecords.  Classes which wish to
          add custom support for MASM printing can #include "Printer.h" and implement
          either:
          1. a specialized Printer template, or
          2. a setPrinter() function.

          See Printer<Reg> and Printer<B3::Air::Tmp> in AirPrintSpecial.h for examples of
          (1).  See CodeBlock's setPrinter() for an example of (2).

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::print):
        * b3/air/AirPrintSpecial.cpp: Added.
        (JSC::B3::Air::PrintSpecial::PrintSpecial):
        (JSC::B3::Air::PrintSpecial::~PrintSpecial):
        (JSC::B3::Air::PrintSpecial::forEachArg):
        (JSC::B3::Air::PrintSpecial::isValid):
        (JSC::B3::Air::PrintSpecial::admitsStack):
        (JSC::B3::Air::PrintSpecial::reportUsedRegisters):
        (JSC::B3::Air::PrintSpecial::generate):
        (JSC::B3::Air::PrintSpecial::extraEarlyClobberedRegs):
        (JSC::B3::Air::PrintSpecial::extraClobberedRegs):
        (JSC::B3::Air::PrintSpecial::dumpImpl):
        (JSC::B3::Air::PrintSpecial::deepDumpImpl):
        (JSC::Printer::printAirArg):
        * b3/air/AirPrintSpecial.h: Added.
        (JSC::Printer::appendAirArg):
        (JSC::Printer::appendAirArgs):
        (JSC::Printer::Printer<B3::Air::Tmp>::Printer):
        (JSC::Printer::Printer<Reg>::Printer):
        - Add the print() operation for use in LowerToAir.  print() will emit a
          PrintSpecial that will ultimately emit a MASM print to print what we want.
        - LowerToAir's print() adds the ability to print Air::Args.
        - Unlike in the baseline JIT and the DFG, LowerToAir's print() can perturb the
          usage of registers.  This is because PrintSpecial is a patch point, and it
          prevents certain optimizations.  If not used carefully, an attempt to print()
          an Arg by taking a Tmp, can force the B3 Value into a Tmp earlier than it would
          otherwise do so.  So, use LowerToAir's print() with care.

        * bytecode/CodeBlock.cpp:
        (JSC::setPrinter):
        - Now we can MASM print CodeBlock*.
        (WTF::printInternal):
        - Now we can dataLog CodeBlock* (including null CodeBlock pointers).

        * bytecode/CodeBlock.h:

        * runtime/VM.cpp:
        (JSC::VM::throwException):
        - Use the new ability to dataLog CodeBlock*.  No need to do an explicit null
          check before printing anymore.

2017-04-21  Keith Miller  <keith_miller@apple.com>

        Unreviewed, rolling out r215634.

        underlying build issues should have been fixed

        Reverted changeset:

        "Unreviewed, rolling out r215620 and r215623."
        https://bugs.webkit.org/show_bug.cgi?id=171139
        http://trac.webkit.org/changeset/215634

2017-04-21  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r215620 and r215623.
        https://bugs.webkit.org/show_bug.cgi?id=171139

        broke arm64 build (Requested by keith_miller on #webkit).

        Reverted changesets:

        "Add signaling API"
        https://bugs.webkit.org/show_bug.cgi?id=170976
        http://trac.webkit.org/changeset/215620

        "Unreviewed, fix Cloop build."
        http://trac.webkit.org/changeset/215623

2017-04-21  Keith Miller  <keith_miller@apple.com>

        Remove LL/SC from Atomics
        https://bugs.webkit.org/show_bug.cgi?id=171141

        Reviewed by Saam Barati.

        Adding load link and store conditionally was not an actual progression
        and the existing code is causing problems for users of Atomics. So let's
        get rid of it.

        * heap/LargeAllocation.h:
        (JSC::LargeAllocation::testAndSetMarked):
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::testAndSetMarked):
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::setMarkedAndAppendToMarkStack):

2017-04-21  Keith Miller  <keith_miller@apple.com>

        Unreviewed, fix Cloop build.

        * jit/ExecutableAllocator.h:
        (JSC::isJITPC):

2017-04-20  Keith Miller  <keith_miller@apple.com>

        Add signaling API
        https://bugs.webkit.org/show_bug.cgi?id=170976

        Reviewed by Filip Pizlo.

        Update various uses of sigaction to use the new signaling API.
        Also switch VMTraps to use the thread message system instead of
        rolling it's own.

        * jit/ExecutableAllocator.h:
        (JSC::isJITPC):
        * runtime/VMTraps.cpp:
        (JSC::installSignalHandler):
        (JSC::VMTraps::VMTraps):
        (JSC::VMTraps::SignalSender::send):
        (JSC::handleSigusr1): Deleted.
        (JSC::handleSigtrap): Deleted.
        (JSC::installSignalHandlers): Deleted.
        * runtime/VMTraps.h:
        * tools/SigillCrashAnalyzer.cpp:
        (JSC::installCrashHandler):
        (JSC::handleCrash): Deleted.
        * wasm/WasmFaultSignalHandler.cpp:
        (JSC::Wasm::trapHandler):
        (JSC::Wasm::enableFastMemory):

2017-04-21  Michael Saboff  <msaboff@apple.com>

        X86-64 Assembler doesn't handle xchg with byte register src
        https://bugs.webkit.org/show_bug.cgi?id=171118

        Reviewed by Saam Barati.

        * assembler/X86Assembler.h:
        (JSC::X86Assembler::xchgb_rm): Use oneByteOp8() since these are 8 bit opcodes.

2017-04-21  Andy VanWagoner  <thetalecrafter@gmail.com>

        [INTL] Implement Intl.DateTimeFormat.prototype.formatToParts
        https://bugs.webkit.org/show_bug.cgi?id=169458

        Reviewed by JF Bastien.

        Use udat_formatForFields to iterate through the parts of a formatted date string.
        Make formatToParts and related functions dependent on ICU version >= 55.

        * icu/unicode/udat.h: Update to 55.1.
        * icu/unicode/ufieldpositer.h: Added from 55.1.
        * icu/unicode/uvernum.h: Update to 55.1
        * runtime/IntlDateTimeFormat.cpp:
        (JSC::IntlDateTimeFormat::partTypeString): Convert UDateFormatField to string.
        (JSC::IntlDateTimeFormat::formatToParts): Return parts of formatted date string.
        * runtime/IntlDateTimeFormat.h:
        * runtime/IntlDateTimeFormatPrototype.cpp:
        (JSC::IntlDateTimeFormatPrototypeFuncFormatToParts): Add prototype function formatToParts.

2017-04-20  Konstantin Tokarev  <annulen@yandex.ru>

        [cmake] Define FORWARDING_HEADERS_DIR in WebKitFS and use it everywhere
        https://bugs.webkit.org/show_bug.cgi?id=171071

        Reviewed by Michael Catanzaro.

        "${DERIVED_SOURCES_DIR}/ForwardingHeaders" path occurs very often in the
        build system files. GTK-specifc FORWARDING_HEADERS_DIR variable should
        be available for all ports.

        * CMakeLists.txt:
        * PlatformWin.cmake:

2017-04-20  Konstantin Tokarev  <annulen@yandex.ru>

        Remove unused lamda captures
        https://bugs.webkit.org/show_bug.cgi?id=171098

        Reviewed by Yusuke Suzuki.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::ArrayNode::emitBytecode):
        * ftl/FTLState.cpp:
        (JSC::FTL::State::State):
        * wasm/WasmB3IRGenerator.cpp:

2017-04-20  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC][FTL] FTL should support Arrayify
        https://bugs.webkit.org/show_bug.cgi?id=169596

        Reviewed by Saam Barati.

        This patch simply expands the coverage of FTL by supporting Arrayify.
        While ArrayifyToStructure is already supported, Arrayify is not supported
        in FTL. While supporting Arrayify in FTL itself does not offer so much
        performance difference from DFG's one, no FTL support for Arrayify
        prevents us applying FTL to the code including Arrayify.

        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::toIndexingShape):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileArrayify):
        (JSC::FTL::DFG::LowerDFGToB3::compileCheckArray):
        (JSC::FTL::DFG::LowerDFGToB3::isArrayTypeForArrayify):
        (JSC::FTL::DFG::LowerDFGToB3::isArrayTypeForCheckArray):
        (JSC::FTL::DFG::LowerDFGToB3::compileArrayifyToStructure): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::isArrayType): Deleted.

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

        virtualThunkFor() needs to materialize its of tagMaskRegister for tail calls.
        https://bugs.webkit.org/show_bug.cgi?id=171079
        <rdar://problem/31684756>

        Reviewed by Saam Barati.

        This is needed because tail calls would restore callee saved registers (and
        therefore, potentially clobber the tag registers) before jumping to the thunk.

        * jit/ThunkGenerators.cpp:
        (JSC::virtualThunkFor):

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

        Build fix after r215592.
        https://bugs.webkit.org/show_bug.cgi?id=171088

        Not reviewed.

        * assembler/MacroAssemblerPrinter.h:

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

        Update the MASM probe to only take 1 arg instead of 2 (in addition to the callback function).
        https://bugs.webkit.org/show_bug.cgi?id=171088

        Reviewed by Michael Saboff and Saam Barati.

        Experience shows that we never use the 2nd arg.  So, let's remove it to reduce
        the footprint at each probe site.

        Also fix the MacroAssembler::print() function so that it is a no-op when
        !ENABLE(MASM_PROBE).  This will allow us to have print() statements in JIT code
        without a lot of #if ENABLE(MASM_PROBE)s later.

        * assembler/AbstractMacroAssembler.h:
        * assembler/MacroAssembler.cpp:
        (JSC::stdFunctionCallback):
        (JSC::MacroAssembler::probe):
        * assembler/MacroAssembler.h:
        * assembler/MacroAssemblerARM.cpp:
        (JSC::MacroAssemblerARM::probe):
        * assembler/MacroAssemblerARM.h:
        * assembler/MacroAssemblerARM64.cpp:
        (JSC::MacroAssemblerARM64::probe):
        * assembler/MacroAssemblerARM64.h:
        * assembler/MacroAssemblerARMv7.cpp:
        (JSC::MacroAssemblerARMv7::probe):
        * assembler/MacroAssemblerARMv7.h:
        * assembler/MacroAssemblerPrinter.cpp:
        (JSC::MacroAssemblerPrinter::printCallback):
        * assembler/MacroAssemblerPrinter.h:
        (JSC::MacroAssemblerPrinter::print):
        (JSC::MacroAssembler::print):
        * assembler/MacroAssemblerX86Common.cpp:
        (JSC::MacroAssemblerX86Common::probe):
        * assembler/MacroAssemblerX86Common.h:

2017-04-20  Matt Baker  <mattbaker@apple.com>

        Web Inspector: Add regular expression support to XHR breakpoints
        https://bugs.webkit.org/show_bug.cgi?id=170099
        <rdar://problem/31558082>

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/DOMDebugger.json:
        New optional `isRegex` parameter denotes whether `url` contains
        a regular expression.

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

        Optimize SharedArrayBuffer in the DFG+FTL
        https://bugs.webkit.org/show_bug.cgi?id=164108

        Reviewed by Saam Barati.
        
        This adds atomics intrinsics to the DFG and wires them through to the DFG and FTL backends. This
        was super easy in the FTL since B3 already has comprehensive atomic intrinsics, which are more
        powerful than what we need right now. In the DFG backend, I went with an easy-to-write
        implementation that just reduces everything to a weak CAS loop. It's very inefficient with
        registers (it needs ~8) but it's the DFG backend, so it's not obvious how much we care.
        
        To make the rare cases easy to handle, I refactored AtomicsObject.cpp so that the operations for
        the slow paths can share code with the native functions.
        
        This also fixes register handling in the X86 implementations of CAS, in the case that
        expectedAndResult is not %rax. This also fixes the ARM64 implementation of branchWeakCAS.
        
        I adapted the CascadeLock from WTF/benchmarks/ToyLocks.h as a microbenchmark of lock performance.
        This benchmark performs 2.5x faster, in both the contended and uncontended case, thanks to this
        change. It's still about 3x slower than native. I investigated this only a bit. I suspect that
        the story will be different in asm.js code, which will get constant-folding of the typed array
        backing store by virtue of how it uses lexically scoped variables as pointers to the heap arrays.
        It's worth noting that the native lock I was comparing against, the very nicely-tuned
        CascadeLock, is at the very high end of lock throughput under virtually all conditions
        (uncontended, microcontended, held for a long time). I also compared to WTF::Lock and others, and
        the only ones that performed better in this microbenchmark were spinlocks. I don't recommend
        using those. So, when I say this is 3x slower than native, I really mean that it's 3x slower than
        the fastest native lock that I have in my arsenal.
        
        Also worth noting is that I experimented with exposing Atomics.yield(), which uses sched_yield,
        as a way of testing if adding a yield loop to the JS cascadeLock would help. It does not help. I
        did not investigate why.

        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::JumpList::append):
        * assembler/CPU.h:
        (JSC::is64Bit):
        (JSC::is32Bit):
        * b3/B3Common.h:
        (JSC::B3::is64Bit): Deleted.
        (JSC::B3::is32Bit): Deleted.
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::appendTrapping):
        (JSC::B3::Air::LowerToAir::appendCAS):
        (JSC::B3::Air::LowerToAir::appendGeneralAtomic):
        * 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:
        (JSC::DFG::isAtomicsIntrinsic):
        (JSC::DFG::numExtraAtomicsArgs):
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSSALoweringPhase.cpp:
        (JSC::DFG::SSALoweringPhase::handleNode):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::loadFromIntTypedArray):
        (JSC::DFG::SpeculativeJIT::setIntTypedArrayLoadResult):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
        (JSC::DFG::SpeculativeJIT::getIntTypedArrayStoreOperand):
        (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLAbstractHeapRepository.cpp:
        (JSC::FTL::AbstractHeapRepository::decorateFencedAccess):
        (JSC::FTL::AbstractHeapRepository::computeRangesAndDecorateInstructions):
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileAtomicsReadModifyWrite):
        (JSC::FTL::DFG::LowerDFGToB3::compileAtomicsIsLockFree):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal):
        (JSC::FTL::DFG::LowerDFGToB3::pointerIntoTypedArray):
        (JSC::FTL::DFG::LowerDFGToB3::loadFromIntTypedArray):
        (JSC::FTL::DFG::LowerDFGToB3::storeType):
        (JSC::FTL::DFG::LowerDFGToB3::setIntTypedArrayLoadResult):
        (JSC::FTL::DFG::LowerDFGToB3::getIntTypedArrayStoreOperand):
        (JSC::FTL::DFG::LowerDFGToB3::vmCall):
        * ftl/FTLOutput.cpp:
        (JSC::FTL::Output::store):
        (JSC::FTL::Output::store32As8):
        (JSC::FTL::Output::store32As16):
        (JSC::FTL::Output::atomicXchgAdd):
        (JSC::FTL::Output::atomicXchgAnd):
        (JSC::FTL::Output::atomicXchgOr):
        (JSC::FTL::Output::atomicXchgSub):
        (JSC::FTL::Output::atomicXchgXor):
        (JSC::FTL::Output::atomicXchg):
        (JSC::FTL::Output::atomicStrongCAS):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::store32):
        (JSC::FTL::Output::store64):
        (JSC::FTL::Output::storePtr):
        (JSC::FTL::Output::storeFloat):
        (JSC::FTL::Output::storeDouble):
        * jit/JITOperations.h:
        * runtime/AtomicsObject.cpp:
        (JSC::atomicsFuncAdd):
        (JSC::atomicsFuncAnd):
        (JSC::atomicsFuncCompareExchange):
        (JSC::atomicsFuncExchange):
        (JSC::atomicsFuncIsLockFree):
        (JSC::atomicsFuncLoad):
        (JSC::atomicsFuncOr):
        (JSC::atomicsFuncStore):
        (JSC::atomicsFuncSub):
        (JSC::atomicsFuncWait):
        (JSC::atomicsFuncWake):
        (JSC::atomicsFuncXor):
        (JSC::operationAtomicsAdd):
        (JSC::operationAtomicsAnd):
        (JSC::operationAtomicsCompareExchange):
        (JSC::operationAtomicsExchange):
        (JSC::operationAtomicsIsLockFree):
        (JSC::operationAtomicsLoad):
        (JSC::operationAtomicsOr):
        (JSC::operationAtomicsStore):
        (JSC::operationAtomicsSub):
        (JSC::operationAtomicsXor):
        * runtime/AtomicsObject.h:

2017-04-19  Youenn Fablet  <youenn@apple.com>

        [Mac] Allow customizing H264 encoder
        https://bugs.webkit.org/show_bug.cgi?id=170829

        Reviewed by Alex Christensen.

        * Configurations/FeatureDefines.xcconfig:

2017-04-19  Michael Saboff  <msaboff@apple.com>

        Tune GC related JSC options for iOS
        https://bugs.webkit.org/show_bug.cgi?id=171019

        Reviewed by Mark Lam.

        Always set these GC options on iOS.

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

2017-04-19  JF Bastien  <jfbastien@apple.com>

        WebAssembly: fast memory cleanups
        https://bugs.webkit.org/show_bug.cgi?id=170909

        Reviewed by Saam Barati.

        * b3/B3LowerToAir.cpp: correct comment, and make wasm-independent
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3Procedure.h:
        * b3/B3Validate.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::effects):
        * b3/B3WasmBoundsCheckValue.cpp: have the creator pass in a
        maximum, so we don't have to know so much about wasm here
        (JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue):
        (JSC::B3::WasmBoundsCheckValue::cloneImpl):
        (JSC::B3::WasmBoundsCheckValue::dumpMeta):
        * b3/B3WasmBoundsCheckValue.h:
        (JSC::B3::WasmBoundsCheckValue::boundsType):
        (JSC::B3::WasmBoundsCheckValue::bounds):
        * b3/air/AirCode.h:
        * b3/air/AirCustom.h:
        (JSC::B3::Air::WasmBoundsCheckCustom::generate):
        * b3/testb3.cpp:
        (JSC::B3::testWasmBoundsCheck):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
        (JSC::Wasm::createJSToWasmWrapper): remove dead code
        * wasm/WasmMemory.cpp: don't GC if no memory could possibly be free'd
        (JSC::Wasm::Memory::initializePreallocations): verbose-only code,
        and copy-pasta bug

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

        B3StackmapSpecial should handle when stackmap values are not recoverable from a Def'ed arg.
        https://bugs.webkit.org/show_bug.cgi?id=170973
        <rdar://problem/30318657>

        Reviewed by Filip Pizlo.

        In the event of an arithmetic overflow on a binary sub instruction (where the
        result register is same as one of the operand registers), the CheckSub FTL
        operation will try to recover the original value in the clobbered result register.

        This recover is done by adding the other operand value to the result register.
        However, this recovery method only works if the width of the original value in
        the result register is less or equal to the width of the expected result.  If the
        width of the original operand value (e.g. a JSInt32) is wider than the result
        (e.g. a machine Int32), then the sub operation would have zero extended the
        result and cleared the upper 32-bits of the result register.  Recovery by adding
        back the other operand will not restore the JSValue tag in the upper word.

        This poses a problem if the stackmap value for the operand relies on that same
        clobbered register.

        The fix is to detect this potential scenario (i.e. width of the Def's arg < width
        of a stackmap value).  If this condition is detected, we'll declare the stackmap
        value to be LateColdUse to ensure that the register allocator gives it a
        different register if needed so that it's not dependent on the clobbered register.

        * b3/B3CheckSpecial.cpp:
        (JSC::B3::CheckSpecial::forEachArg):
        * b3/B3PatchpointSpecial.cpp:
        (JSC::B3::PatchpointSpecial::forEachArg):
        * b3/B3StackmapSpecial.cpp:
        (JSC::B3::StackmapSpecial::forEachArgImpl):
        * b3/B3StackmapSpecial.h:

2017-04-19  JF Bastien  <jfbastien@apple.com>

        Unreviewed, rolling out r215520.

        Broke Debian 8

        Reverted changeset:

        "[INTL] Implement Intl.DateTimeFormat.prototype.formatToParts"
        https://bugs.webkit.org/show_bug.cgi?id=169458
        http://trac.webkit.org/changeset/215520

2017-04-19  JF Bastien  <jfbastien@apple.com>

        WebAssembly: limit slow memories
        https://bugs.webkit.org/show_bug.cgi?id=170825

        Reviewed by Saam Barati.

        We limits the number of fast memories, partly because ASLR. The
        code then falls back to slow memories. It first tries to virtually
        allocated any declared maximum (and in there, physically the
        initial), and if that fails it tries to physically allocate the
        initial without any extra.

        This can still be used to cause a bunch of virtual
        allocation. This patch imposes soft limit on slow memories as
        well. The total virtual maximum for slow memories is set at the
        same (theoretical) value as that for fast memories.

        Anything exceeding that limit causes allocation/grow to fail.

        * wasm/WasmMemory.cpp:

2017-04-19  JF Bastien  <jfbastien@apple.com>

        Cannot compile JavaScriptCore/runtime/VMTraps.cpp on FreeBSD because std::pair has a non-trivial copy constructor
        https://bugs.webkit.org/show_bug.cgi?id=170875

        Reviewed by Mark Lam.

        WTF::ExpectedDetail::ConstexprBase doesn't have a user-defined
        copy constructor, and its implicitly-defined copy constructor is
        deleted because the default std::pair implementation on FreeBSD
        has a non-trivial copy constructor. /usr/include/c++/v1/__config
        says _LIBCPP_TRIVIAL_PAIR_COPY_CTOR is disabled in order to keep
        ABI compatibility:
        https://svnweb.freebsd.org/changeset/base/261801.

        That's a huge bummer, and I'm not a fan of broken stdlibs, but in
        this case it's pretty nice to have a custom named type anyways and
        costs nothing.

        * runtime/VMTraps.cpp:
        (JSC::findActiveVMAndStackBounds):
        (JSC::handleSigusr1):
        (JSC::handleSigtrap):

2017-04-19  Andy VanWagoner  <thetalecrafter@gmail.com>

        [INTL] Implement Intl.DateTimeFormat.prototype.formatToParts
        https://bugs.webkit.org/show_bug.cgi?id=169458

        Reviewed by JF Bastien.

        Use udat_formatForFields to iterate through the parts of a formatted date string.

        * icu/unicode/udat.h: Update to 55.1.
        * icu/unicode/ufieldpositer.h: Added from 55.1.
        * runtime/IntlDateTimeFormat.cpp:
        (JSC::IntlDateTimeFormat::partTypeString): Convert UDateFormatField to string.
        (JSC::IntlDateTimeFormat::formatToParts): Return parts of formatted date string.
        * runtime/IntlDateTimeFormat.h:
        * runtime/IntlDateTimeFormatPrototype.cpp:
        (JSC::IntlDateTimeFormatPrototypeFuncFormatToParts): Add prototype function formatToParts.

2017-04-19  JF Bastien  <jfbastien@apple.com>

        WebAssembly: don't expose any WebAssembly JS object if JIT is off
        https://bugs.webkit.org/show_bug.cgi?id=170782

        Reviewed by Saam Barati.

        It's unexpected that we expose the global WebAssembly object if no
        JIT is present because it can't be used to compile or
        instantiate. Other APIs such as Memory should also be Inaccessible
        in those circumstances.

        Also ensure that we don't pre-allocate fast memories if
        WebAssembly won't be used, and don't mark our intention to use a
        fast TLS slot for WebAssembly.

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

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

        r211670 broke double to int conversion.
        https://bugs.webkit.org/show_bug.cgi?id=170961

        Reviewed by Mark Lam.

        In this patch, we take a template parameter way.
        While it reduces duplicate code, it effectively produces
        optimized code for operationToInt32SensibleSlow,
        and fixes kraken pbkdf2 regression on Linux.

        And this patch also fixes undefined behavior by changing
        int32_t to uint32_t. If exp is 31, missingOne is 1 << 31,
        INT32_MIN. Thus missingOne - 1 will cause int32_t overflow,
        and it is an undefined behavior.

        * runtime/MathCommon.cpp:
        (JSC::operationToInt32SensibleSlow):
        * runtime/MathCommon.h:
        (JSC::toInt32Internal):
        (JSC::toInt32):

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

        r211670 broke double to int conversion.
        https://bugs.webkit.org/show_bug.cgi?id=170961
        <rdar://problem/31687696>

        Reviewed by Yusuke Suzuki.

        This is because operationToInt32SensibleSlow() assumes that left shifts of greater
        than 31 bits on an 31-bit value will produce a 0.  However, the spec says that
        "if the value of the right operand is negative or is greater or equal to the
        number of bits in the promoted left operand, the behavior is undefined."
        See http://en.cppreference.com/w/cpp/language/operator_arithmetic#Bitwise_shift_operators.

        This patch fixes this by restoring the check to prevent a shift of greater than
        31 bits.  It also consolidates the optimization in operationToInt32SensibleSlow()
        back into toInt32() so that we don't have 2 copies of the same code with only a
        slight variation.

        JSC benchmarks shows that performance is neutral with this patch.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileValueToInt32):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::sensibleDoubleToInt32):
        * runtime/MathCommon.cpp:
        (JSC::operationToInt32SensibleSlow): Deleted.
        * runtime/MathCommon.h:
        (JSC::toInt32):

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

        [ES6]. Implement Annex B.3.3 function hoisting rules for eval
        https://bugs.webkit.org/show_bug.cgi?id=163208

        Reviewed by Saam Barati.

        Current patch implements Annex B.3.3 that is related to 
        hoisting of function declaration in eval. 
        https://tc39.github.io/ecma262/#sec-web-compat-evaldeclarationinstantiation
        Function declaration in eval should create variable with 
        function name in function scope where eval is invoked 
        or bind to variable if it declared outside of the eval. 
        If variable is created it can be removed by 'delete a;' command. 
        If eval is invoke in block scope that contains let/const 
        variable with the same name as function declaration 
        we do not bind. This patch leads to the following behavior: 
        '''
        function foo() {
           {
             print(boo); // undefined
             eval('{ function boo() {}}');
             print(boo); // function boo() {}
           }
           print(boo); // function boo() {}
        }

        function foobar() {
          { 
            let boo = 10;
            print(boo); // 10;
            eval('{ function boo() {}}');
            print(boo); // 10;
          }
          print(boo) // 10
        }

        function bar() {
           {
              var boo = 10;
              print(boo); // 10
              eval('{ function boo() {} }'); 
              print(boo); // function boo() {}
           }
           print(boo); // function boo() {}
        }       
        
        function bas() {
            {
                 let boo = 10;
                 eval(' { function boo() {} } ');
                 print(boo); // 10
            }
            print(boo); //Reference Error
        }
        '''

        Current implementation relies on already implemented 
        'hoist function in sloppy mode' feature, with small changes.
        In short it works in following way: during hoisting of function 
        with name S in eval, we are looking for first scope that 
        contains space for variable with name S and if this scope 
        has var type we bind function there

        To implement this feature was added bytecode ops:
        op_resolve_scope_for_hoisting_func_decl_in_eval - get variable scope 
        or return undefined if variable can't be binded there.

        There is a corner case, hoist function in eval within catch block,
        that is not covered by this patch, and will be fixed in 
        https://bugs.webkit.org/show_bug.cgi?id=168184

        * bytecode/BytecodeDumper.cpp:
        (JSC::BytecodeDumper<Block>::dumpBytecode):
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finalizeLLIntInlineCaches):
        * bytecode/EvalCodeBlock.h:
        (JSC::EvalCodeBlock::functionHoistingCandidate):
        (JSC::EvalCodeBlock::numFunctionHoistingCandidates):
        * bytecode/UnlinkedEvalCodeBlock.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary):
        (JSC::BytecodeGenerator::emitResolveScopeForHoistingFuncDeclInEval):
        * 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/DFGNode.h:
        (JSC::DFG::Node::hasIdentifier):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileResolveScopeForHoistingFuncDeclInEval):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileResolveScopeForHoistingFuncDeclInEval):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOperations.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval):
        * llint/LowLevelInterpreter.asm:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFunctionDeclarationStatement):
        * parser/Parser.h:
        (JSC::Scope::getSloppyModeHoistedFunctions):
        (JSC::Parser::declareFunction):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        * runtime/EvalExecutable.h:
        (JSC::EvalExecutable::numFunctionHoistingCandidates):
        (JSC::EvalExecutable::numTopLevelFunctionDecls):
        (JSC::EvalExecutable::numberOfFunctionDecls): Deleted.
        * runtime/JSScope.cpp:
        (JSC::JSScope::resolve):
        (JSC::JSScope::resolveScopeForHoistingFuncDeclInEval):
        * runtime/JSScope.h:

2017-04-18  Saam Barati  <sbarati@apple.com>

        Follow up to address Mark's comments after r215453

        Rubber stamped by Mark Lam.

        This patch chooses better names for things, adhering to Mark's suggestions
        in https://bugs.webkit.org/show_bug.cgi?id=139847

        * bytecompiler/NodesCodegen.cpp:
        (JSC::CallFunctionCallDotNode::emitBytecode):
        (JSC::ApplyFunctionCallDotNode::emitBytecode):
        * parser/NodeConstructors.h:
        (JSC::CallFunctionCallDotNode::CallFunctionCallDotNode):
        (JSC::ApplyFunctionCallDotNode::ApplyFunctionCallDotNode):
        * parser/Nodes.h:
        * parser/Parser.cpp:
        (JSC::recordCallOrApplyDepth):
        (JSC::Parser<LexerType>::parseMemberExpression):
        * parser/Parser.h:
        (JSC::Parser::CallOrApplyDepthScope::CallOrApplyDepthScope):
        (JSC::Parser::CallOrApplyDepthScope::distanceToInnermostChild):
        (JSC::Parser::CallOrApplyDepthScope::~CallOrApplyDepthScope):
        (JSC::Parser::CallOrApplyDepth::CallOrApplyDepth): Deleted.
        (JSC::Parser::CallOrApplyDepth::maxChildDepth): Deleted.
        (JSC::Parser::CallOrApplyDepth::~CallOrApplyDepth): Deleted.

2017-04-18  Yusuke Suzuki  <utatane.tea@gmail.com>

        [DFG] Convert ValueAdd(Int32, String) => MakeRope(ToString(Int32), String)
        https://bugs.webkit.org/show_bug.cgi?id=170943

        Reviewed by Geoffrey Garen.

        This patch converts ValueAdd(Int32, String) to MakeRope(ToString(Int32), String).
        This has 2 great features.

        1. MakeRope(ToString(Int32), String) is less clobbering.

        While ValueAdd ends up calling functions, VM knows much about MakeRope(ToString(Int32), String)
        and VM knows it is less clobbering. It encourages LICM and other operations that is conservatively
        executed because of ValueAdd's clobbering.

        2. Simply, MakeRope(ToString(Int32), String) is faster than ValueAdd.

        While ValueAdd ends up calling a generic function, our ToString(Int32) calls well-optimized toString
        operation. And later, MakeRope can fall into the fast path that just takes a string from a free list.
        It is simply faster than ValueAdd.

        We ensure that this patch shows performance improvement in attached benchmarks.

                                                        baseline                  patched

            number-to-string-with-add-empty         16.2763+-3.3930     ^     10.3142+-1.0967        ^ definitely 1.5780x faster
            number-to-string-with-add-in-loop      168.7621+-10.9738    ^     15.5307+-3.3179        ^ definitely 10.8664x faster
            number-to-string-with-add               18.8557+-4.8292           11.6901+-2.5650          might be 1.6130x faster

        In SixSpeed,

                                               baseline                  patched

            template_string_tag.es5       200.1027+-20.6871    ^     25.7925+-11.4052       ^ definitely 7.7582x faster
            template_string_tag.es6       331.3913+-12.1750    ^    286.6958+-26.0441       ^ definitely 1.1559x faster
            for-of-array.es5              412.4344+-23.2517    ^    272.8707+-47.2118       ^ definitely 1.5115x faster
            for-of-array.es6              504.0082+-65.5045    ^    300.3277+-12.8193       ^ definitely 1.6782x faster

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

2017-04-18  Michael Saboff  <msaboff@apple.com>

        REGRESSION(215272): microbenchmark/seal-and-do-work and microbenchmark/freeze-and-do-work are 27x slower
        https://bugs.webkit.org/show_bug.cgi?id=170881

        Reviewed by Saam Barati.

        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorSeal):
        (JSC::objectConstructorFreeze):
        Restored fast paths for final objects that don't have indexed properties.

2017-04-18  Yusuke Suzuki  <utatane.tea@gmail.com>

        [DFG] Use Phantom for base instead of getter when inlining intrinsic getter
        https://bugs.webkit.org/show_bug.cgi?id=170947

        Reviewed by Saam Barati.

        getter does not need to be live after OSR Exit.

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

2017-04-18  Yusuke Suzuki  <utatane.tea@gmail.com>

        Unreviewed, follow-up patch after r215459
        https://bugs.webkit.org/show_bug.cgi?id=170940

        Reviewed by Filip Pizlo.

        CheckCell can cause OSRExit. Thus Phantom should be placed after CheckCell.

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

2017-04-18  Yusuke Suzuki  <utatane.tea@gmail.com>

        [DFG] Drop unknown use of CheckCell's child2 to work ObjectAllocationSinking for Array iterator object
        https://bugs.webkit.org/show_bug.cgi?id=170940

        Reviewed by Filip Pizlo.

        The second argument of CheckCell is not used in meaningful way. It is just *use* the node.
        The problem is that it effectively *use* the child2 in ObjectAllocationSinking phase, and
        prevent us from eliminating object allocations. Actually, it materializes Array iterator
        when inlining `next()`. Instead, we should use Phantom in such a case.

        It improves destructuring.es6 in SixSpeed 2.5x.

        destructuring.es6      308.5184+-25.3490    ^    119.5680+-15.0520       ^ definitely 2.5803x faster

        Note that SixSpeed tested in arewefastyet executes all the tests in one process while our SixSpeed
        tests each one in isolated way.

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

2017-04-18  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC][GTK] glib RunLoop does not accept negative start interval
        https://bugs.webkit.org/show_bug.cgi?id=170775

        Reviewed by Saam Barati.

        * heap/GCActivityCallback.cpp:
        (JSC::GCActivityCallback::scheduleTimer):

2017-04-17  Saam Barati  <sbarati@apple.com>

        BytecodeGenerator ".call" and ".apply" is exponential in nesting depth
        https://bugs.webkit.org/show_bug.cgi?id=139847
        <rdar://problem/19321122>

        Reviewed by Oliver Hunt.

        The BytecodeGenerator's .apply(...) and .call(...) code would
        emit bytecode for the evaluation of its arguments twice. This
        is exponential, specifically, 2^n, where n is the nesting depth of
        .call(...) or .apply(...) inside other .call(...) or .apply(...).
        
        The reason we emit code for the arguments twice is that we try
        to emit efficient code for when .call or .apply is Function.prototype.call
        or Function.prototype.apply. Because of this, we compare .call/.apply to
        Function.prototype.call/.apply, and if they're the same, we emit a specialized
        function call in bytecode. Otherwise, we emit the generalized version.
        
        This patch makes it so that each .call(...) and .apply(...) records
        its max inner nesting depth. Then, we only perform the optimization
        for the bottom k (where k = 6) layers of the nesting tree. The reason we
        apply the optimization to the bottom k layers instead of top k layers
        is that we'll produce less code this way.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::CallFunctionCallDotNode::emitBytecode):
        (JSC::ApplyFunctionCallDotNode::emitBytecode):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::makeFunctionCallNode):
        * parser/NodeConstructors.h:
        (JSC::CallFunctionCallDotNode::CallFunctionCallDotNode):
        (JSC::ApplyFunctionCallDotNode::ApplyFunctionCallDotNode):
        * parser/Nodes.h:
        * parser/Parser.cpp:
        (JSC::recordCallOrApplyDepth):
        (JSC::Parser<LexerType>::parseMemberExpression):
        * parser/Parser.h:
        (JSC::Parser::CallOrApplyDepth::CallOrApplyDepth):
        (JSC::Parser::CallOrApplyDepth::maxChildDepth):
        (JSC::Parser::CallOrApplyDepth::~CallOrApplyDepth):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::makeFunctionCallNode):

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

        JSArray::appendMemcpy() needs to handle copying from Undecided indexing type too.
        https://bugs.webkit.org/show_bug.cgi?id=170896
        <rdar://problem/31651319>

        Reviewed by JF Bastien and Keith Miller.

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

2017-04-17  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Doesn't show size of compressed content correctly
        https://bugs.webkit.org/show_bug.cgi?id=155112
        <rdar://problem/25006728>

        Reviewed by Alex Christensen and Timothy Hatcher.

        * inspector/protocol/Network.json:
        New, exact size metrics, available after the load completes.

2017-04-17  Youenn Fablet  <youenn@apple.com>

        Disable outdated WritableStream API
        https://bugs.webkit.org/show_bug.cgi?id=170749
        <rdar://problem/31446233>

        Reviewed by Alex Christensen.

        * Configurations/FeatureDefines.xcconfig:

2017-04-17  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSCOnly] Fix build failures in macOS
        https://bugs.webkit.org/show_bug.cgi?id=170887

        Reviewed by Alex Christensen.

        Align ICU header configuration to MacCMake port.

        * PlatformJSCOnly.cmake:

2017-04-17  JF Bastien  <jfbastien@apple.com>

        B3: don't allow unsigned offsets in Value
        https://bugs.webkit.org/show_bug.cgi?id=170692

        Reviewed by Filip Pizlo.

        MemoryValue and similar B3 opcode classes always expects a signed
        offset. Giving it an out-of-bounds unsigned offset causes
        implementation-defined behavior, which can cause badness as I just
        fixed in WebAssembly.  This patch makes it impossible to create a
        Value opcodes with an unsigned value, or with an overly-large
        value.

        * b3/B3AtomicValue.cpp:
        (JSC::B3::AtomicValue::AtomicValue):
        * b3/B3AtomicValue.h:
        * b3/B3Common.h:
        (JSC::B3::isRepresentableAs):
        * b3/B3EliminateCommonSubexpressions.cpp:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::scaleForShl):
        (JSC::B3::Air::LowerToAir::effectiveAddr):
        (JSC::B3::Air::LowerToAir::addr):
        (JSC::B3::Air::LowerToAir::tryAppendLea):
        * b3/B3MemoryValue.cpp:
        (JSC::B3::MemoryValue::isLegalOffsetImpl):
        (JSC::B3::MemoryValue::MemoryValue):
        * b3/B3MemoryValue.h:
        * b3/B3MemoryValueInlines.h:
        (JSC::B3::MemoryValue::isLegalOffsetImpl):
        * b3/B3MoveConstants.cpp:
        * b3/B3ReduceStrength.cpp:
        * b3/B3StackmapSpecial.cpp:
        (JSC::B3::StackmapSpecial::repForArg):
        * b3/B3Value.h:
        * b3/air/AirArg.cpp:
        (JSC::B3::Air::Arg::stackAddrImpl):
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::addr):
        (JSC::B3::Air::Arg::stack):
        (JSC::B3::Air::Arg::callArg):
        (JSC::B3::Air::Arg::stackAddr):
        (JSC::B3::Air::Arg::index):
        (JSC::B3::Air::Arg::offset):
        (JSC::B3::Air::Arg::isValidAddrForm):
        (JSC::B3::Air::Arg::isValidIndexForm):
        (JSC::B3::Air::Arg::asTrustedImm32):
        (JSC::B3::Air::Arg::asAddress):
        (JSC::B3::Air::Arg::asBaseIndex):
        * b3/air/AirLowerStackArgs.cpp:
        (JSC::B3::Air::lowerStackArgs):
        * b3/testb3.cpp:
        (JSC::B3::testMulArgStore):
        (JSC::B3::testStore32):
        (JSC::B3::testStoreConstant):
        (JSC::B3::testStoreConstantPtr):
        (JSC::B3::testStoreAddLoad32):
        (JSC::B3::testStoreAddLoadImm32):
        (JSC::B3::testStoreAddLoad8):
        (JSC::B3::testStoreAddLoadImm8):
        (JSC::B3::testStoreAddLoad16):
        (JSC::B3::testStoreAddLoadImm16):
        (JSC::B3::testStoreAddLoad64):
        (JSC::B3::testStoreAddLoadImm64):
        (JSC::B3::testStoreAddLoad32Index):
        (JSC::B3::testStoreAddLoadImm32Index):
        (JSC::B3::testStoreAddLoad64Index):
        (JSC::B3::testStoreAddLoadImm64Index):
        (JSC::B3::testStoreSubLoad):
        (JSC::B3::testStoreAddLoadInterference):
        (JSC::B3::testStoreAddAndLoad):
        (JSC::B3::testStoreNegLoad32):
        (JSC::B3::testStoreNegLoadPtr):
        (JSC::B3::testLoadOffset):
        (JSC::B3::testLoadOffsetNotConstant):
        (JSC::B3::testLoadOffsetUsingAdd):
        (JSC::B3::testLoadOffsetUsingAddInterference):
        (JSC::B3::testLoadOffsetUsingAddNotConstant):
        (JSC::B3::testStoreLoadStackSlot):
        (JSC::B3::testLoad):
        (JSC::B3::testInterpreter):
        (JSC::B3::testTrappingStore):
        (JSC::B3::testTrappingLoadAddStore):
        (JSC::B3::testWasmAddress):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::fixupPointerPlusOffset):
        (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
        (JSC::Wasm::B3IRGenerator::emitLoadOp):
        (JSC::Wasm::B3IRGenerator::emitStoreOp):

2017-04-16  Joseph Pecoraro  <pecoraro@apple.com>

        test262: test262/test/built-ins/Object/prototype/toLocaleString/primitive_this_value.js
        https://bugs.webkit.org/show_bug.cgi?id=170882

        Reviewed by Saam Barati.

        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncToLocaleString):
        We should be using the this value without ToObject conversion both when
        getting the potential accessor and calling it. In strict mode, the this
        value will remain its simple value, in non-strict it is still converted.

2017-04-16  Joseph Pecoraro  <pecoraro@apple.com>

        test262: test262/test/built-ins/isNaN/toprimitive-not-callable-throws.js
        https://bugs.webkit.org/show_bug.cgi?id=170888

        Reviewed by Saam Barati.

        * runtime/ExceptionHelpers.h:
        * runtime/ExceptionHelpers.cpp:
        (JSC::createInvalidInstanceofParameterErrorHasInstanceValueNotFunction):
        Fix up this function name.

        * runtime/JSObject.cpp:
        (JSC::callToPrimitiveFunction):
        When called with @@isPrimitive, bail on undefined or null and
        throw a type error if the value is not callable.

        (JSC::JSObject::toPrimitive):
        Use throw scope to check for exception.

2017-04-16  Joseph Pecoraro  <pecoraro@apple.com>

        test262: test262/test/language/expressions/tagged-template/template-object.js
        https://bugs.webkit.org/show_bug.cgi?id=170878

        Reviewed by Saam Barati.

        * runtime/JSArray.cpp:
        (JSC::JSArray::put):
        The fast path for setting an Array's length should check if length is
        writable before checking for and possibly throwing a RangeError.

2017-04-16  Joseph Pecoraro  <pecoraro@apple.com>

        test262: test262/test/built-ins/Object/getOwnPropertyNames/15.2.3.4-4-44.js
        https://bugs.webkit.org/show_bug.cgi?id=170879

        Reviewed by Saam Barati.

        * runtime/StringObject.h:
        * runtime/StringObject.cpp:
        (JSC::StringObject::getOwnPropertyNames):
        (JSC::StringObject::getOwnNonIndexPropertyNames):
        Ensure 'length' comes after all indexed properties by moving
        it out to the getOwnNonIndexPropertyNames method which is called
        inside of getOwnPropertyNames after JSObject handles indices.

2017-04-16  Joseph Pecoraro  <pecoraro@apple.com>

        test262: test262/test/built-ins/Date/prototype/Symbol.toPrimitive/name.js
        https://bugs.webkit.org/show_bug.cgi?id=170884

        Reviewed by Yusuke Suzuki.

        * runtime/DatePrototype.cpp:
        (JSC::DatePrototype::finishCreation):
        * runtime/FunctionPrototype.cpp:
        (JSC::FunctionPrototype::addFunctionProperties):
        * runtime/RegExpPrototype.cpp:
        (JSC::RegExpPrototype::finishCreation):
        * runtime/SymbolPrototype.cpp:
        (JSC::SymbolPrototype::finishCreation):
        Give symbol property functions proper function names.
        This addresses function.name but not function.toString().

2017-04-15  Joseph Pecoraro  <pecoraro@apple.com>

        test262: test262/test/language/global-code/new.target-arrow.js
        https://bugs.webkit.org/show_bug.cgi?id=170872

        Reviewed by Saam Barati.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::Parser):
        Mark the global code scope.

        (JSC::Parser<LexerType>::parseMemberExpression):
        If new.target is detected in an arrow function defined in global scope
        throw a SyntaxError.

        * parser/Parser.h:
        (JSC::Scope::Scope):
        (JSC::Scope::setIsGlobalCodeScope):
        (JSC::Scope::isGlobalCodeScope):
        Marker for a global code scope.

        * parser/ParserModes.h:
        (JSC::isModuleParseMode):
        (JSC::isProgramParseMode):
        (JSC::isProgramOrModuleParseMode):
        Helper for detecting global code based on parse mode.

2017-04-14  Nikita Vasilyev  <nvasilyev@apple.com>

        Web Inspector: WebSockets: messages with non-latin letters are displayed incorrectly
        https://bugs.webkit.org/show_bug.cgi?id=170760

        Reviewed by Joseph Pecoraro.

        Add payloadLength property, which is used to display size. When payloadLength is unavailable,
        it is calculated from payloadData by Web Inspector frontend.

        This fixes <webkit.org/b/170609> Web Inspector: WebSockets: Transferred size is incorrect.

        * inspector/protocol/Network.json:

2017-04-14  Saam Barati  <sbarati@apple.com>

        ParseInt intrinsic in DFG backend doesn't properly flush its operands
        https://bugs.webkit.org/show_bug.cgi?id=170865

        Reviewed by Mark Lam and Geoffrey Garen.

        The DFG backend code needed to first call .gpr()/.jsValueRegs()
        before calling flushRegisters(), or the input JSValueOperand would
        not be flushed.

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

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

        Update architectures in xcconfig files.
        https://bugs.webkit.org/show_bug.cgi?id=170867
        <rdar://problem/31628104>

        Reviewed by Joseph Pecoraro.

        * Configurations/Base.xcconfig:
        * Configurations/FeatureDefines.xcconfig:
        * Configurations/JavaScriptCore.xcconfig:
        * Configurations/ToolExecutable.xcconfig:

2017-04-14  Keith Miller  <keith_miller@apple.com>

        WebAssembly: B3IRGenerator should use phis for result types
        https://bugs.webkit.org/show_bug.cgi?id=170863

        Reviewed by Filip Pizlo.

        Currently, we use variables for the result types of control flow in
        Wasm. We did this originally since we weren't sure that the phis we
        generated would be optimal. Since then, we have verified that the edges
        in wasm control flow ensure that each upsilon will dominate its phi
        so we don't need to use variables.

        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::ControlData::ControlData):
        (JSC::Wasm::B3IRGenerator::addTopLevel):
        (JSC::Wasm::B3IRGenerator::addBlock):
        (JSC::Wasm::B3IRGenerator::addLoop):
        (JSC::Wasm::B3IRGenerator::unify):

2017-04-14  Alex Christensen  <achristensen@webkit.org>

        Fix Windows build after r215368.
        https://bugs.webkit.org/show_bug.cgi?id=170641

        * CMakeLists.txt:
        Add new directory containing files needed in WebCore.

2017-04-14  Caitlin Potter  <caitp@igalia.com>

        [JSC] use ExpressionErrorClassifier for AwaitExpression operand
        https://bugs.webkit.org/show_bug.cgi?id=170844

        Reviewed by Saam Barati.

        In parseAssignmentExpression(), several cover grammars are handled, and
        use ExpressionErrorClassifier to record hints about which grammars to
        try.

        In parseAwaitExpression(), the hints recorded during parsing of the
        operand need to be discarded, because if they propagate to the outer
        parseAssignmentExpression(), the hints will lead the parser down invalid
        branches that should be skipped.

        This change adds an additional ExpressionErrorClassifier to
        parseAwaitExpression(), in order to discard hints recorded trying to
        parse the operand.

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

2017-04-14  Saam Barati  <sbarati@apple.com>

        WebAssembly: There is a short window of time where a CodeBlock could be destroyed before all of its async compilation callbacks are called
        https://bugs.webkit.org/show_bug.cgi?id=170641

        Reviewed by Keith Miller.

        There is an unlikely race when a CodeBlock compilation fails,
        the module compiles a new CodeBlock for that memory mode, all while
        the CodeBlock is notifying its callbacks that it has finished.
        There is a chance that the Module could deref its failed CodeBlock 
        at that point, destroying it, before the callbacks were able to
        grab a Ref to the CodeBlock. This patch fixes the race by having the
        callbacks ref the CodeBlock.

        This patch also has the Plan clear out all of its callbacks
        once it gets completed. This adds an extra defense to anybody
        that grabs refs to the Plan in the callback.

        * wasm/WasmCodeBlock.cpp:
        (JSC::Wasm::CodeBlock::CodeBlock):
        (JSC::Wasm::CodeBlock::compileAsync):
        * wasm/WasmPlan.cpp:
        (JSC::Wasm::Plan::complete):

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

        Air::RegLiveness should be constraint-based
        https://bugs.webkit.org/show_bug.cgi?id=170817

        Reviewed by Saam Barati.
        
        Previously, I changed the Air liveness analyses based on Air::Liveness<> to be
        constraint-based and this was a significant speed-up. Now I'm adding the same
        functionality to RegLiveness.
        
        This is a 1% speed-up on wasm B3 -O1 compile times.
        
        * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp:
        * b3/air/AirLivenessAdapter.h:
        (JSC::B3::Air::LivenessAdapter::LivenessAdapter):
        (JSC::B3::Air::LivenessAdapter::prepareToCompute):
        (JSC::B3::Air::LivenessAdapter::actionsAt):
        * b3/air/AirRegLiveness.cpp:
        (JSC::B3::Air::RegLiveness::RegLiveness):
        (JSC::B3::Air::RegLiveness::LocalCalcForUnifiedTmpLiveness::LocalCalcForUnifiedTmpLiveness):
        (JSC::B3::Air::RegLiveness::LocalCalcForUnifiedTmpLiveness::execute):
        (JSC::B3::Air::RegLiveness::LocalCalc::execute): Deleted.
        * b3/air/AirRegLiveness.h:
        (JSC::B3::Air::RegLiveness::Actions::Actions):
        (JSC::B3::Air::RegLiveness::LocalCalcBase::LocalCalcBase):
        (JSC::B3::Air::RegLiveness::LocalCalcBase::live):
        (JSC::B3::Air::RegLiveness::LocalCalcBase::isLive):
        (JSC::B3::Air::RegLiveness::LocalCalc::LocalCalc):
        (JSC::B3::Air::RegLiveness::LocalCalc::execute):
        (JSC::B3::Air::RegLiveness::LocalCalc::live): Deleted.
        (JSC::B3::Air::RegLiveness::LocalCalc::isLive): Deleted.

2017-04-13  JF Bastien  <jfbastien@apple.com>

        WebAssembly: fix windows build
        https://bugs.webkit.org/show_bug.cgi?id=170832

        Reviewed by Mark Lam.

        My previous patch re-declared isIOS which AssemblerCommon.h
        already provided, and which was already included by Options.cpp.

        * runtime/Options.cpp:

2017-04-13  Saam Barati  <sbarati@apple.com>

        WebAssembly: We should be able to postMessage a JSWebAssemblyModule
        https://bugs.webkit.org/show_bug.cgi?id=170573

        Reviewed by Filip Pizlo.

        This patch adds a callback to JSRunLoopTimer to notify
        clients that a timer has been set. This is used inside
        WorkerRunLoop in WebCore so that its RunLoop can perform
        an iteration when it sees that a timer got set.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/JSRunLoopTimer.cpp:
        (JSC::JSRunLoopTimer::scheduleTimer):
        (JSC::JSRunLoopTimer::addTimerSetNotification):
        (JSC::JSRunLoopTimer::removeTimerSetNotification):
        * runtime/JSRunLoopTimer.h:
        * wasm/WasmCodeBlock.cpp:
        (JSC::Wasm::CodeBlock::~CodeBlock):
        * wasm/WasmCodeBlock.h:
        * wasm/WasmModule.cpp:
        (JSC::Wasm::Module::~Module):
        (JSC::Wasm::Module::signatureIndexFromFunctionIndexSpace):
        (JSC::Wasm::makeValidationCallback):
        (JSC::Wasm::Module::validateSync):
        (JSC::Wasm::Module::validateAsync):
        (JSC::Wasm::Module::validateSyncImpl): Deleted.
        (JSC::Wasm::Module::makeValidationCallback): Deleted.
        * wasm/WasmModule.h:
        (JSC::Wasm::Module::validateSync): Deleted.
        (JSC::Wasm::Module::validateAsync): Deleted.
        (JSC::Wasm::Module::signatureIndexFromFunctionIndexSpace): Deleted.
        (JSC::Wasm::Module::nonNullCodeBlock): Deleted.
        * wasm/js/JSWebAssemblyCodeBlock.cpp:
        (JSC::JSWebAssemblyCodeBlock::create):
        * wasm/js/JSWebAssemblyCodeBlock.h:
        (JSC::JSWebAssemblyCodeBlock::create): Deleted.
        * wasm/js/JSWebAssemblyModule.cpp:
        (JSC::JSWebAssemblyModule::source):
        * wasm/js/JSWebAssemblyModule.h:
        (JSC::JSWebAssemblyModule::source): Deleted.
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction):
        * wasm/js/WebAssemblyModulePrototype.cpp:

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

        Should use flushDirect() when flushing the scopeRegister due to needsScopeRegister().
        https://bugs.webkit.org/show_bug.cgi?id=170661
        <rdar://problem/31579046>

        Reviewed by Filip Pizlo.

        Previously, we were using flush() to flush the outermost frame's scopeRegister.
        This is incorrect because flush() expects the VirtualRegister value passed to
        it to be that of the top most inlined frame.  In the event that we reach a
        terminal condition while inside an inlined frame, flush() will end up flushing
        the wrong register.  The fix is simply to use flushDirect() instead.

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

2017-04-13  Andy VanWagoner  <thetalecrafter@gmail.com>

        Change Intl prototypes to plain objects
        https://bugs.webkit.org/show_bug.cgi?id=168178

        Reviewed by JF Bastien.

        * builtins/StringPrototype.js:
        (localeCompare): Create default Collator once instead of using prototype.
        * runtime/IntlCollatorPrototype.cpp:
        (JSC::IntlCollatorPrototype::IntlCollatorPrototype):
        * runtime/IntlCollatorPrototype.h:
        * runtime/IntlDateTimeFormatPrototype.cpp:
        (JSC::IntlDateTimeFormatPrototype::IntlDateTimeFormatPrototype):
        * runtime/IntlDateTimeFormatPrototype.h:
        * runtime/IntlNumberFormatPrototype.cpp:
        (JSC::IntlNumberFormatPrototype::IntlNumberFormatPrototype):
        * runtime/IntlNumberFormatPrototype.h:
        * runtime/IntlObject.cpp:
        (JSC::IntlObject::finishCreation): Don't set constructor on each prototype.

2017-04-13  Oliver Hunt  <oliver@apple.com>

        allocationSize should use safe arithmetic by default
        https://bugs.webkit.org/show_bug.cgi?id=170804

        Reviewed by JF Bastien.

        Make all allocationSize() functions work in terms
        of Checked<size_t>

        * runtime/DirectArguments.h:
        (JSC::DirectArguments::offsetOfSlot):
        (JSC::DirectArguments::allocationSize):
        * runtime/HashMapImpl.h:
        (JSC::HashMapBuffer::allocationSize):
        * runtime/JSArray.h:
        (JSC::JSArray::allocationSize):
        * runtime/JSArrayBufferView.h:
        (JSC::JSArrayBufferView::allocationSize):
        * runtime/JSAsyncFunction.h:
        (JSC::JSAsyncFunction::allocationSize):
        * runtime/JSFixedArray.h:
        (JSC::JSFixedArray::allocationSize):
        * runtime/JSFunction.h:
        (JSC::JSFunction::allocationSize):
        * runtime/JSGeneratorFunction.h:
        (JSC::JSGeneratorFunction::allocationSize):
        * runtime/JSModuleNamespaceObject.h:
        * runtime/JSObject.h:
        (JSC::JSFinalObject::allocationSize):
        * runtime/JSWrapperObject.h:
        (JSC::JSWrapperObject::allocationSize):
        * runtime/ScopedArguments.h:
        (JSC::ScopedArguments::allocationSize):
        * runtime/VM.h:
        (JSC::ScratchBuffer::allocationSize):
        * wasm/js/JSWebAssemblyCodeBlock.h:
        (JSC::JSWebAssemblyCodeBlock::offsetOfImportStubs):
        (JSC::JSWebAssemblyCodeBlock::allocationSize):
        * wasm/js/JSWebAssemblyInstance.h:
        (JSC::JSWebAssemblyInstance::allocationSize):

2017-04-13  JF Bastien  <jfbastien@apple.com>

        WebAssembly: manage memory better
        https://bugs.webkit.org/show_bug.cgi?id=170628

        Reviewed by Keith Miller, Michael Saboff.

        WebAssembly fast memories weren't managed very well. This patch
        refactors it and puts us in a good position to further improve our
        fast memory handling in the future.

        We now cache fast memories at a process granularity, but make sure
        that they don't consume dirty pages. We add a cap to the total
        number of allocated fast memories to avoid ASLR degradation.

        We teach the GC about memories as a kind of resource it should
        care about because it didn't have visibility into the amount of
        memory each represented. This allows benchmarks which allocate
        memories back-to-back to reliably get fast memories 100% of the
        time, even on a system under load, which wasn't the case
        before. This reliability yields roughly 8% perf bump on x86-64
        WasmBench.

        The GC heuristic is as follows: each time we allocate a fast
        memory we notify the GC, which then keeps track of the total
        number of fast memories allocated since it last GC'd. We
        separately keep track of the total number of fast memories which
        have ever existed at any point in time (cached + allocated). This
        is a monotonically-increasing high watermark. The GC will force a
        full collection if, since it last ran, half or more of the high
        watermark of fast memories was allocated.

        At the same time, if we fail obtaining a fast memory from the
        cache we do a GC to try to find one. If that fails we'll allocate
        a new one (this can also fail, then we go to slow memory). This
        can also be improved, but it's a good start.

        This currently disables fast memories on iOS because getting fast
        memories isn't a guaranteed thing. Rather, we get quite a few of
        them and achieve significant speedups, but benchmarks which
        allocate memories back-to-back end up falling behind because the
        GC can conservatively hold onto memories, which then yields a perf
        cliff. That cliff isn't reliable, WasmBench gets roughly 10 of 18
        fast memories when in theory it should get all of them fast (as
        MacOS does). The patch significantly improves the state of iOS
        though, and in a follow-up we could re-enable fast memories.

        Part of this good positioning is a facility to pre-allocate fast
        memories very early at startup, before any fragmentation
        occurs. This is currently disabled but worked extremely reliably
        on iOS. Once we fix the above issues we'll want to re-visit and
        turn on pre-allocation.

        We also avoid locking for fast memory identification when
        performing signal handling. I'm very nervous about acquiring locks
        in a signal handler because in general signals can happen when
        we've messed up. This isn't the case with fast memories: we're
        raising a signal on purpose and handling it. However this doesn't
        mean we won't mess up elsewhere! This will get more complicated
        once we add support for multiple threads sharing memories and
        being able to grow their memories. One example: the code calls
        CRASH(), which executes the following code in release:

            *(int *)(uintptr_t)0xbbadbeef = 0;

        This is a segfault, which our fast memory signal handler tries to
        handle. It does so by first figuring out whether 0xbbadbeef is in
        a fast memory region, reqiring a lock. If we CRASH() while holding
        the lock then our thread self-deadlocks, giving us no crash report
        and a bad user experience.

        Avoiding a lock therefore it's not about speed or reduced
        contention. In fact, I'd use something else than a FIFO if these
        were a concern. We're also doing syscalls, which dwarf any locking
        cost.

        We now only allocate 4GiB + redzone of 64k * 128 for fast memories
        instead of 8GiB. This patch reuses the logic from
        B3::WasmBoundsCheck to perform bounds checks when accesses could
        exceed the redzone. We'll therefore benefit from CSE goodness when
        it reaches WasmBoundsCheck. See bug #163469.

        * b3/B3LowerToAir.cpp: fix a baaaaddd bug where unsigned->signed
        conversion allowed out-of-bounds reads by -2GiB. I'll follow-up in
        bug #170692 to prevent this type of bug once and for all.
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3Validate.cpp: update WasmBoundsCheck validation.
        * b3/B3Value.cpp:
        (JSC::B3::Value::effects): update WasmBoundsCheck effects.
        * b3/B3WasmBoundsCheckValue.cpp:
        (JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue):
        (JSC::B3::WasmBoundsCheckValue::redzoneLimit):
        (JSC::B3::WasmBoundsCheckValue::dumpMeta):
        * b3/B3WasmBoundsCheckValue.h:
        (JSC::B3::WasmBoundsCheckValue::maximum):
        * b3/air/AirCustom.cpp:
        (JSC::B3::Air::WasmBoundsCheckCustom::isValidForm):
        * b3/testb3.cpp:
        (JSC::B3::testWasmBoundsCheck):
        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::reportWebAssemblyFastMemoriesAllocated):
        (JSC::Heap::webAssemblyFastMemoriesThisCycleAtThreshold):
        (JSC::Heap::updateAllocationLimits):
        (JSC::Heap::didAllocateWebAssemblyFastMemories):
        (JSC::Heap::shouldDoFullCollection):
        (JSC::Heap::collectIfNecessaryOrDefer):
        * heap/Heap.h:
        * runtime/InitializeThreading.cpp:
        (JSC::initializeThreading):
        * runtime/Options.cpp:
        * runtime/Options.h:
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::fixupPointerPlusOffset):
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
        (JSC::Wasm::B3IRGenerator::emitLoadOp):
        (JSC::Wasm::B3IRGenerator::emitStoreOp):
        (JSC::Wasm::createJSToWasmWrapper):
        * wasm/WasmFaultSignalHandler.cpp:
        (JSC::Wasm::trapHandler):
        * wasm/WasmMemory.cpp: Rewrite.
        (JSC::Wasm::makeString):
        (JSC::Wasm::Memory::initializePreallocations):
        (JSC::Wasm::Memory::createImpl):
        (JSC::Wasm::Memory::create):
        (JSC::Wasm::Memory::~Memory):
        (JSC::Wasm::Memory::fastMappedRedzoneBytes):
        (JSC::Wasm::Memory::fastMappedBytes):
        (JSC::Wasm::Memory::maxFastMemoryCount):
        (JSC::Wasm::Memory::addressIsInActiveFastMemory):
        (JSC::Wasm::Memory::grow):
        * wasm/WasmMemory.h:
        (Memory::maxFastMemoryCount):
        (Memory::addressIsInActiveFastMemory):
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::finishCreation):
        (JSC::JSWebAssemblyInstance::visitChildren):
        (JSC::JSWebAssemblyInstance::globalMemoryByteSize):
        * wasm/js/JSWebAssemblyInstance.h:
        * wasm/js/JSWebAssemblyMemory.cpp:
        (JSC::JSWebAssemblyMemory::grow):
        (JSC::JSWebAssemblyMemory::finishCreation):
        (JSC::JSWebAssemblyMemory::visitChildren):

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

        [JSC] Use proper ifdef guard for code using MachineContext
        https://bugs.webkit.org/show_bug.cgi?id=170800

        Reviewed by Carlos Alberto Lopez Perez.

        This patch drops MachineContext use if it is not available.
        This situation can be considered like, building WebKit with musl.
        In that case, we simply disable features that rely on MachineContext.
        Examples are wasm fast memory, sampling profiler, and code profiling.

        * runtime/Options.cpp:
        (JSC::overrideDefaults):
        * tools/CodeProfiling.cpp:
        (JSC::CodeProfiling::begin):
        (JSC::CodeProfiling::end):
        Previously, PLATFORM(GTK) is excluded. But it is not obvious why it is excluded.
        This patch just includes such platforms.

        * wasm/WasmFaultSignalHandler.cpp:
        (JSC::Wasm::enableFastMemory):

2017-04-12  Dan Bernstein  <mitz@apple.com>

        [Mac] Future-proof .xcconfig files
        https://bugs.webkit.org/show_bug.cgi?id=170802

        Reviewed by Tim Horton.

        * Configurations/Base.xcconfig:
        * Configurations/DebugRelease.xcconfig:
        * Configurations/FeatureDefines.xcconfig:
        * Configurations/Version.xcconfig:

2017-04-12  Joseph Pecoraro  <pecoraro@apple.com>

        test262: test262/test/built-ins/NativeErrors/EvalError/proto.js
        https://bugs.webkit.org/show_bug.cgi?id=170668

        Reviewed by Keith Miller.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        The [[Prototype]] of NativeError Constructor's should be the %Error%.
        https://tc39.github.io/ecma262/#sec-properties-of-the-nativeerror-constructors

2017-04-12  Joseph Pecoraro  <pecoraro@apple.com>

        test262: test262/test/language/literals/regexp/u-dec-esc.js
        https://bugs.webkit.org/show_bug.cgi?id=170687

        Reviewed by Michael Saboff.

        * yarr/YarrParser.h:
        (JSC::Yarr::Parser::parseEscape):
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::YarrPattern::errorMessage):
        (JSC::Yarr::YarrPattern::compile):
        * yarr/YarrPattern.h:
        In unicoe patterns, invalid backreferences are an error.

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

        Move common stack allocation utilities out of AirAllocateStackByGraphColoring.cpp
        https://bugs.webkit.org/show_bug.cgi?id=170799

        Reviewed by Michael Saboff and Keith Miller.
        
        When I added stack allocation to allocateRegistersByLinearScan, I reused a handful of
        utility functions from AirAllocateStackByGraphColoring.cpp. I accomplished this by
        putting their declarations in AirAllocateStackByGraphColoring.h.
        
        That was pretty weird.
        
        This patch moves a family of stack allocation helper functions out of
        AirAllocateStackByGraphColoring.cpp and into the new AirStackAllocation.h|cpp. The
        linear scan stack allocator no longer has to include the other stack allocator's
        header, which addresses my OCD.
        
        I moved the functions transitively reachable from the two functions that the linear
        scan allocator needed. This forced me to give them better names (i.e. no "fooBarImpl")
        and short descriptive comments. I think that such comments are useful in code that is
        doing a convoluted version of some theoretical concept.
        
        No behavior change.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp:
        * b3/air/AirAllocateStackByGraphColoring.cpp:
        (JSC::B3::Air::allocateStackByGraphColoring):
        (JSC::B3::Air::allocateEscapedStackSlots): Deleted.
        (JSC::B3::Air::updateFrameSizeBasedOnStackSlots): Deleted.
        * b3/air/AirAllocateStackByGraphColoring.h:
        * b3/air/AirStackAllocation.cpp: Added.
        (JSC::B3::Air::attemptAssignment):
        (JSC::B3::Air::assign):
        (JSC::B3::Air::allocateAndGetEscapedStackSlotsWithoutChangingFrameSize):
        (JSC::B3::Air::allocateEscapedStackSlots):
        (JSC::B3::Air::updateFrameSizeBasedOnStackSlots):
        * b3/air/AirStackAllocation.h: Added.

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

        B3 -O1 should not allocateStackByGraphColoring
        https://bugs.webkit.org/show_bug.cgi?id=170742

        Reviewed by Keith Miller.
        
        One of B3 -O1's longest running phases is allocateStackByGraphColoring. One approach to
        this would be to make that phase cheaper. But it's weird that this phase reruns
        liveness after register allocation already ran liveness. If only it could reuse the
        liveness computed by register allocation then it would run a lot faster. At -O2, we do
        not want this, since we run phases between register allocation and stack allocation,
        and those phases are free to change the liveness of spill slots (in fact,
        fixObviousSpills will both shorten and lengthen live ranges because of load and store
        elimination, respectively). But at -O1, we don't really need to run any phases between
        register and stack allocation.
        
        This changes Air's backend in the following ways:
        
        - Linear scan does stack allocation. This means that we don't need to run
          allocateStackByGraphColoring at all. In reality, we reuse some of its innards, but
          we don't run the expensive part of it (liveness->interference->coalescing->coloring).
          This is a speed-up because we only run liveness once and reuse it for both register
          and stack allocation.
        
        - Phases that previously ran between register and stack allocation are taken care of,
          each in its own special way:
          
          -> handleCalleSaves: this is now a utility function called by both
             allocateStackByGraphColoring and allocateRegistersAndStackByLinearScan.
          
          -> fixObviousSpills: we didn't run this at -O1, so nothing needs to be done.
          
          -> lowerAfterRegAlloc: this needed to be able to run before stack allocation because
             it could change register usage (vis a vis callee saves) and it could introduce
             spill slots. I changed this phase to have a secondary mode for when it runs after
             stack allocation.
        
        - The part of allocateStackByGraphColoring that lowered stack addresses and took care
          of the call arg area is now a separate phase called lowerStackArgs. We run this phase
          regardless of optimization level. It's a cheap and general lowering.
        
        This also removes spillEverything, because we never use that phase, we never test it,
        and it got in the way in this refactoring.
        
        This is a 21% speed-up on wasm -O1 compile times. This does not significantly change
        -O1 throughput. We had already disabled allocateStack's most important optimization
        (spill coalescing). This probably regresses average stack frame size, but I didn't
        measure by how much. Stack frame size is really not that important. The algorithm in
        allocateStackByGraphColoring is about much more than optimal frame size; it also
        tries to avoid having to zero-extend 32-bit spills, it kills dead code, and of course
        it coalesces.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::calleeSaveRegisterAtOffsetList):
        (JSC::B3::Procedure::calleeSaveRegisters): Deleted.
        * b3/B3Procedure.h:
        * b3/B3StackmapGenerationParams.cpp:
        (JSC::B3::StackmapGenerationParams::unavailableRegisters):
        * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp: Copied from Source/JavaScriptCore/b3/air/AirAllocateRegistersByLinearScan.cpp.
        (JSC::B3::Air::allocateRegistersAndStackByLinearScan):
        (JSC::B3::Air::allocateRegistersByLinearScan): Deleted.
        * b3/air/AirAllocateRegistersAndStackByLinearScan.h: Copied from Source/JavaScriptCore/b3/air/AirAllocateRegistersByLinearScan.h.
        * b3/air/AirAllocateRegistersByLinearScan.cpp: Removed.
        * b3/air/AirAllocateRegistersByLinearScan.h: Removed.
        * b3/air/AirAllocateStackByGraphColoring.cpp:
        (JSC::B3::Air::allocateEscapedStackSlots):
        (JSC::B3::Air::updateFrameSizeBasedOnStackSlots):
        (JSC::B3::Air::allocateStackByGraphColoring):
        * b3/air/AirAllocateStackByGraphColoring.h:
        * b3/air/AirArg.cpp:
        (JSC::B3::Air::Arg::stackAddr):
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::stackAddr): Deleted.
        * b3/air/AirCode.cpp:
        (JSC::B3::Air::Code::addStackSlot):
        (JSC::B3::Air::Code::setCalleeSaveRegisterAtOffsetList):
        (JSC::B3::Air::Code::calleeSaveRegisterAtOffsetList):
        (JSC::B3::Air::Code::dump):
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::setStackIsAllocated):
        (JSC::B3::Air::Code::stackIsAllocated):
        (JSC::B3::Air::Code::calleeSaveRegisters):
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::prepareForGeneration):
        (JSC::B3::Air::generate):
        * b3/air/AirHandleCalleeSaves.cpp:
        (JSC::B3::Air::handleCalleeSaves):
        * b3/air/AirHandleCalleeSaves.h:
        * b3/air/AirLowerAfterRegAlloc.cpp:
        (JSC::B3::Air::lowerAfterRegAlloc):
        * b3/air/AirLowerStackArgs.cpp: Added.
        (JSC::B3::Air::lowerStackArgs):
        * b3/air/AirLowerStackArgs.h: Added.
        * b3/testb3.cpp:
        (JSC::B3::testPinRegisters):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):
        * jit/RegisterAtOffsetList.h:
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::parseAndCompile):

2017-04-12  Michael Saboff  <msaboff@apple.com>

        Implement Object.isFrozen() and Object.isSealed() per ECMA spec
        https://bugs.webkit.org/show_bug.cgi?id=170753

        Reviewed by Mark Lam.

        * runtime/ObjectConstructor.cpp:
        (JSC::testIntegrityLevel): Added local helper as described in the ECMA standard.

        (JSC::objectConstructorSeal):
        (JSC::objectConstructorFreeze):
        Eliminated incomplete special handling of JSFinalObjects.

        (JSC::objectConstructorIsSealed):
        (JSC::objectConstructorIsFrozen):
        Refactored to use the new testIntegrityLevel() helper.

2017-04-12  Yusuke Suzuki  <utatane.tea@gmail.com>

        Use HAVE(MACHINE_CONTEXT) instead of USE(MACHINE_CONTEXT)
        https://bugs.webkit.org/show_bug.cgi?id=170770

        Rubber stamped by Mark Lam.

        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::MachineThread::Registers::framePointer):
        (JSC::MachineThreads::MachineThread::Registers::instructionPointer):
        (JSC::MachineThreads::MachineThread::Registers::llintPC):
        * runtime/MachineContext.h:
        (JSC::MachineContext::stackPointer):
        (JSC::MachineContext::framePointer):
        (JSC::MachineContext::instructionPointer):
        (JSC::MachineContext::argumentPointer<1>):
        (JSC::MachineContext::llintInstructionPointer):

2017-04-12  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Clean up heap/MachineStackMarker by introducing USE(MACHINE_CONTEXT)
        https://bugs.webkit.org/show_bug.cgi?id=170770

        Reviewed by Mark Lam.

        We use USE(MACHINE_CONTEXT) to clean up runtime/MachineContext.h. And
        we clean up heap/MachineStackMarker.cpp by using MachineContext functions.

        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::MachineThread::Registers::stackPointer):
        (JSC::MachineThreads::MachineThread::Registers::framePointer):
        (JSC::MachineThreads::MachineThread::Registers::instructionPointer):
        (JSC::MachineThreads::MachineThread::Registers::llintPC):
        * heap/MachineStackMarker.h:
        * runtime/MachineContext.h:
        (JSC::MachineContext::stackPointer):
        (JSC::MachineContext::framePointer):
        (JSC::MachineContext::instructionPointer):
        (JSC::MachineContext::argumentPointer<1>):
        (JSC::MachineContext::llintInstructionPointer):

2017-04-12  Yusuke Suzuki  <utatane.tea@gmail.com>

        [WTF] Introduce Thread class and use RefPtr<Thread> and align Windows Threading implementation semantics to Pthread one
        https://bugs.webkit.org/show_bug.cgi?id=170502

        Reviewed by Mark Lam.

        * API/tests/CompareAndSwapTest.cpp:
        (testCompareAndSwap):
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/air/testair.cpp:
        * b3/testb3.cpp:
        (JSC::B3::run):
        * bytecode/SuperSampler.cpp:
        (JSC::initializeSuperSampler):
        * dfg/DFGWorklist.cpp:
        * disassembler/Disassembler.cpp:
        * heap/Heap.cpp:
        (JSC::Heap::lastChanceToFinalize):
        (JSC::Heap::notifyIsSafeToCollect):
        * heap/Heap.h:
        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::~MachineThreads):
        (JSC::MachineThreads::addCurrentThread):
        (JSC::MachineThreads::removeThread):
        (JSC::MachineThreads::removeThreadIfFound):
        (JSC::MachineThreads::MachineThread::MachineThread):
        (JSC::MachineThreads::MachineThread::getRegisters):
        (JSC::MachineThreads::MachineThread::Registers::stackPointer):
        (JSC::MachineThreads::MachineThread::Registers::framePointer):
        (JSC::MachineThreads::MachineThread::Registers::instructionPointer):
        (JSC::MachineThreads::MachineThread::Registers::llintPC):
        (JSC::MachineThreads::MachineThread::captureStack):
        (JSC::MachineThreads::tryCopyOtherThreadStack):
        (JSC::MachineThreads::tryCopyOtherThreadStacks):
        (pthreadSignalHandlerSuspendResume): Deleted.
        (JSC::threadData): Deleted.
        (JSC::MachineThreads::Thread::Thread): Deleted.
        (JSC::MachineThreads::Thread::createForCurrentThread): Deleted.
        (JSC::MachineThreads::Thread::operator==): Deleted.
        (JSC::MachineThreads::machineThreadForCurrentThread): Deleted.
        (JSC::MachineThreads::ThreadData::ThreadData): Deleted.
        (JSC::MachineThreads::ThreadData::~ThreadData): Deleted.
        (JSC::MachineThreads::ThreadData::suspend): Deleted.
        (JSC::MachineThreads::ThreadData::resume): Deleted.
        (JSC::MachineThreads::ThreadData::getRegisters): Deleted.
        (JSC::MachineThreads::ThreadData::Registers::stackPointer): Deleted.
        (JSC::MachineThreads::ThreadData::Registers::framePointer): Deleted.
        (JSC::MachineThreads::ThreadData::Registers::instructionPointer): Deleted.
        (JSC::MachineThreads::ThreadData::Registers::llintPC): Deleted.
        (JSC::MachineThreads::ThreadData::freeRegisters): Deleted.
        (JSC::MachineThreads::ThreadData::captureStack): Deleted.
        * heap/MachineStackMarker.h:
        (JSC::MachineThreads::MachineThread::suspend):
        (JSC::MachineThreads::MachineThread::resume):
        (JSC::MachineThreads::MachineThread::threadID):
        (JSC::MachineThreads::MachineThread::stackBase):
        (JSC::MachineThreads::MachineThread::stackEnd):
        (JSC::MachineThreads::threadsListHead):
        (JSC::MachineThreads::Thread::operator!=): Deleted.
        (JSC::MachineThreads::Thread::suspend): Deleted.
        (JSC::MachineThreads::Thread::resume): Deleted.
        (JSC::MachineThreads::Thread::getRegisters): Deleted.
        (JSC::MachineThreads::Thread::freeRegisters): Deleted.
        (JSC::MachineThreads::Thread::captureStack): Deleted.
        (JSC::MachineThreads::Thread::platformThread): Deleted.
        (JSC::MachineThreads::Thread::stackBase): Deleted.
        (JSC::MachineThreads::Thread::stackEnd): Deleted.
        * jit/ICStats.cpp:
        (JSC::ICStats::ICStats):
        (JSC::ICStats::~ICStats):
        * jit/ICStats.h:
        * jsc.cpp:
        (functionDollarAgentStart):
        (startTimeoutThreadIfNeeded):
        * runtime/JSLock.cpp:
        (JSC::JSLock::lock):
        * runtime/JSLock.h:
        (JSC::JSLock::ownerThread):
        (JSC::JSLock::currentThreadIsHoldingLock):
        * runtime/SamplingProfiler.cpp:
        (JSC::FrameWalker::isValidFramePointer):
        (JSC::SamplingProfiler::SamplingProfiler):
        (JSC::SamplingProfiler::createThreadIfNecessary):
        (JSC::SamplingProfiler::takeSample):
        * runtime/SamplingProfiler.h:
        * runtime/VM.h:
        (JSC::VM::ownerThread):
        * runtime/VMTraps.cpp:
        (JSC::findActiveVMAndStackBounds):
        (JSC::VMTraps::SignalSender::send):
        (JSC::VMTraps::fireTrap):

2017-04-11  Dean Jackson  <dino@apple.com>

        Disable outdated WritableStream API
        https://bugs.webkit.org/show_bug.cgi?id=170749
        <rdar://problem/31446233>

        Reviewed by Tim Horton.

        The API we implement is no longer accurate. Disable it until we
        are compatible with the new specification

        * Configurations/FeatureDefines.xcconfig:

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

        Unreviewed, build fix for CF ports after r215241
        https://bugs.webkit.org/show_bug.cgi?id=170725

        * heap/GCActivityCallback.cpp:
        (JSC::GCActivityCallback::nextFireTime):

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

        [WebCore][JSC] ResourceUsageData.{timeOfNextEdenCollection,timeOfNextFullCollection} should be MonotonicTime
        https://bugs.webkit.org/show_bug.cgi?id=170725

        Reviewed by Sam Weinig.

        This patch makes GCActivityCallback return MonotonicTime instead of raw double value.

        * heap/GCActivityCallback.cpp:
        (JSC::GCActivityCallback::nextFireTime):
        * heap/GCActivityCallback.h:

2017-04-11  Guillaume Emont  <guijemont@igalia.com>

        [jsc] Add missing MacroAssemblerMIPS::or32() implementation
        https://bugs.webkit.org/show_bug.cgi?id=169714

        Reviewed by Michael Catanzaro.

        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::or32):
        Added or32(TrustedImm32, Address).

2017-04-11  Joseph Pecoraro  <pecoraro@apple.com>

        test262: test262/test/annexB/language/comments/multi-line-html-close.js
        https://bugs.webkit.org/show_bug.cgi?id=170648

        Reviewed by Keith Miller.

        * parser/Lexer.cpp:
        (JSC::Lexer<T>::lex):
        A multi-line comment that contains a line terminator is itself treated
        like a line terminator. An HTML Close Comment that comes after it can
        therefore treat it like it is at the start of a line, because it was
        immediately preceeded by the equivalent of a line terminator.

2017-04-11  Joseph Pecoraro  <pecoraro@apple.com>

        test262: test262/test/built-ins/Array/S15.4.3_A2.2.js
        https://bugs.webkit.org/show_bug.cgi?id=170652

        Reviewed by Michael Saboff.

        * runtime/ArrayConstructor.cpp:
        (JSC::ArrayConstructor::finishCreation):
        * runtime/BooleanConstructor.cpp:
        (JSC::BooleanConstructor::finishCreation):
        * runtime/DateConstructor.cpp:
        (JSC::DateConstructor::finishCreation):
        * runtime/FunctionConstructor.cpp:
        (JSC::FunctionConstructor::finishCreation):
        * runtime/JSArrayBufferConstructor.cpp:
        (JSC::JSArrayBufferConstructor::finishCreation):
        * runtime/NumberConstructor.cpp:
        (JSC::NumberConstructor::finishCreation):
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructor::finishCreation):
        * runtime/RegExpConstructor.cpp:
        (JSC::RegExpConstructor::finishCreation):
        * runtime/StringConstructor.cpp:
        (JSC::StringConstructor::finishCreation):
        * runtime/SymbolConstructor.cpp:
        (JSC::SymbolConstructor::finishCreation):
        Ensure the "length" property on these native constructors is configurable (deletable).

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

        Unreviewed, build fix for Windows after r215228 part 2
        https://bugs.webkit.org/show_bug.cgi?id=170723

        Since GCActivityCallback class is annotated exported, we do not need to annotate each member.

        * heap/GCActivityCallback.h:

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

        [JSC][GTK] Use RunLoop::Timer in GTK port
        https://bugs.webkit.org/show_bug.cgi?id=170723

        Reviewed by Carlos Garcia Campos.

        This patch makes GTK port use RunLoop::Timer for JSRunLoopTimer.
        Only Cocoa-based ports use platform-specific Timer because it
        has additional feature that changes RunLoop to the WebThread one.

        And we enable Heap timers in all the ports including JSCOnly port.

        * heap/EdenGCActivityCallback.cpp:
        (JSC::EdenGCActivityCallback::lastGCLength):
        * heap/EdenGCActivityCallback.h:
        * heap/FullGCActivityCallback.cpp:
        (JSC::FullGCActivityCallback::lastGCLength):
        * heap/FullGCActivityCallback.h:
        * heap/GCActivityCallback.cpp:
        (JSC::GCActivityCallback::GCActivityCallback):
        (JSC::GCActivityCallback::doWork):
        (JSC::GCActivityCallback::scheduleTimer):
        (JSC::GCActivityCallback::cancelTimer):
        (JSC::GCActivityCallback::nextFireTime):
        (JSC::GCActivityCallback::didAllocate):
        * heap/GCActivityCallback.h:
        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::doWork):
        (JSC::IncrementalSweeper::doSweep):
        * heap/IncrementalSweeper.h:
        * heap/StopIfNecessaryTimer.cpp:
        (JSC::StopIfNecessaryTimer::scheduleSoon):
        * runtime/JSRunLoopTimer.cpp:
        (JSC::JSRunLoopTimer::setRunLoop):
        (JSC::JSRunLoopTimer::scheduleTimer):
        (JSC::JSRunLoopTimer::cancelTimer):
        (JSC::JSRunLoopTimer::JSRunLoopTimer):
        (JSC::JSRunLoopTimer::~JSRunLoopTimer):
        (JSC::JSRunLoopTimer::timerDidFireCallback):
        * runtime/JSRunLoopTimer.h:
        * runtime/PromiseDeferredTimer.cpp:
        (JSC::PromiseDeferredTimer::scheduleWorkSoon):

2017-04-11  Guillaume Emont  <guijemont@igalia.com>

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

        Reviewed by Yusuke Suzuki.

        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::loadFloat): Added.
        (JSC::MacroAssemblerMIPS::storeFloat): Added.

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

        [JSC] Enable JSRunLoopTimer for JSCOnly and Windows
        https://bugs.webkit.org/show_bug.cgi?id=170655

        Reviewed by Carlos Garcia Campos.

        * runtime/JSRunLoopTimer.cpp:
        (JSC::JSRunLoopTimer::JSRunLoopTimer):
        (JSC::JSRunLoopTimer::scheduleTimer):
        (JSC::JSRunLoopTimer::cancelTimer):
        * runtime/JSRunLoopTimer.h:

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

        Revert r215217
        https://bugs.webkit.org/show_bug.cgi?id=170703

        * Configurations/FeatureDefines.xcconfig:

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

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

        Reviewed by Youenn Fablet.

        * Configurations/FeatureDefines.xcconfig:

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

        Move ProbeContext and ProbeFunction out of AbstractMacroAssembler.
        https://bugs.webkit.org/show_bug.cgi?id=170681

        Reviewed by Michael Saboff.

        This is a refactoring step towards enabling custom probe printers the way printInternal() works for dataLog.

        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::ProbeContext::gpr): Deleted.
        (JSC::AbstractMacroAssembler::ProbeContext::fpr): Deleted.
        (JSC::AbstractMacroAssembler::ProbeContext::gprName): Deleted.
        (JSC::AbstractMacroAssembler::ProbeContext::fprName): Deleted.
        * assembler/MacroAssembler.cpp:
        (JSC::stdFunctionCallback):
        (JSC::MacroAssembler::probe):
        * assembler/MacroAssembler.h:
        (JSC::ProbeContext::gpr):
        (JSC::ProbeContext::fpr):
        (JSC::ProbeContext::gprName):
        (JSC::ProbeContext::fprName):
        * assembler/MacroAssemblerARM.cpp:
        (JSC::MacroAssemblerARM::probe):
        * assembler/MacroAssemblerARM64.cpp:
        (JSC::arm64ProbeTrampoline):
        (JSC::MacroAssemblerARM64::probe):
        * assembler/MacroAssemblerARMv7.cpp:
        (JSC::MacroAssemblerARMv7::probe):
        * assembler/MacroAssemblerPrinter.cpp:
        * assembler/MacroAssemblerPrinter.h:
        * assembler/MacroAssemblerX86Common.cpp:
        (JSC::MacroAssemblerX86Common::probe):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::abstractStructure):
        (JSC::FTL::DFG::LowerDFGToB3::probe): Deleted.
        - Deleted because this became a useless place-holder after the transition to B3.

2017-04-10  Keith Miller  <keith_miller@apple.com>

        WebAssembly: Fix B3IRGenerator for BrTable
        https://bugs.webkit.org/show_bug.cgi?id=170685

        Reviewed by JF Bastien.

        For some reason this didn't get included in r215141.

        This fixes an issue with BrTable and loops where we would use the loop's return type
        as the branch target type.

        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::ControlData::resultForBranch):
        (JSC::Wasm::B3IRGenerator::unifyValuesWithBlock):

2017-04-08  Oliver Hunt  <oliver@apple.com>

        Remove use of strcpy from JSC
        https://bugs.webkit.org/show_bug.cgi?id=170646

        Reviewed by Mark Lam.

        Replace the use of strcpy with memcpy as strcpy keeps
        on tripping various analyser warnings even though its
        trivially safe in this case.

        Essentially code hygiene, no change in behaviour, no
        perf impact.

        * dfg/DFGDisassembler.cpp:
        (JSC::DFG::Disassembler::dumpDisassembly):

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

        test262: test262/test/annexB/language/expressions/object/__proto__-fn-name.js
        https://bugs.webkit.org/show_bug.cgi?id=170650

        Reviewed by Saam Barati.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parseProperty):
        There needs to be special handling of:
        
          PropertyDefinition :  PropertyName ':' AssignmentExpression
         
        When the property name is __proto__. In this case the
        SetFunctionName path does not happen, so the name "__proto__"
        is not inferred on any anonymous function. See:
        https://tc39.github.io/ecma262/#sec-__proto__-property-names-in-object-initializers

        * parser/Parser.h:
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createProperty):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createProperty):
        Add an extra parameter to see if inferring / setting names are allowed.

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

        test262: test262/test/annexB/language/literals/regexp/identity-escape.js
        https://bugs.webkit.org/show_bug.cgi?id=170651

        Reviewed by Saam Barati.

        * yarr/YarrParser.h:
        (JSC::Yarr::Parser::parseEscape):
        For \8 and \9 match just the number "8" or "9" instead of both "\\" and the number.
        See: https://tc39.github.io/ecma262/#sec-decimalescape

2017-04-08  Youenn Fablet  <youenn@apple.com>

        WebRTC tests gardening
        https://bugs.webkit.org/show_bug.cgi?id=170508

        Reviewed by Eric Carlson.

        * Configurations/FeatureDefines.xcconfig:

2017-04-07  Keith Miller  <keith_miller@apple.com>

        WebAssembly: Fix issue with BrTable targeting a Loop
        https://bugs.webkit.org/show_bug.cgi?id=170638

        Reviewed by Saam Barati.

        This fixes the same issue V8 had in: https://github.com/WebAssembly/spec/pull/456#event-1033547537

        * wasm/WasmValidate.cpp:
        (JSC::Wasm::Validate::ControlData::branchTargetSignature):

2017-04-07  Keith Miller  <keith_miller@apple.com>

        Add a PriorityQueue class
        https://bugs.webkit.org/show_bug.cgi?id=170579

        Reviewed by Saam Barati.

        Update Wasm::Worklist to use WTF::PriorityQueue.

        * wasm/WasmWorklist.cpp:
        (JSC::Wasm::Worklist::enqueue):
        (JSC::Wasm::Worklist::completePlanSynchronously):
        (JSC::Wasm::Worklist::stopAllPlansForVM):
        (JSC::Wasm::Worklist::~Worklist):
        (JSC::Wasm::Worklist::iterate): Deleted.
        * wasm/WasmWorklist.h:
        (JSC::Wasm::Worklist::isHigherPriority):
        (JSC::Wasm::Worklist::Comparator::operator()): Deleted.

2017-04-07  Yuichiro Kikura  <y.kikura@gmail.com>

        WebGPU: implement ComputeCommandEncoder and related components
        https://bugs.webkit.org/show_bug.cgi?id=170444

        Reviewed by Alex Christensen.

        I added some identifiers related with WebGPUComputeCommandEncoder based on the proposal.
        https://webkit.org/wp-content/uploads/webgpu-api-proposal.html

        * runtime/CommonIdentifiers.h:

2017-04-07  Saam Barati  <sbarati@apple.com>

        WebAssembly: Module::getOrCreateCodeBlock is wrong
        https://bugs.webkit.org/show_bug.cgi?id=170612

        Reviewed by Keith Miller.

        When we were getting a module's CodeBlock, we were checking if !runnable(),
        and if !runnable(), we were re-creating the CodeBlock. This is wrong, since
        !runnable() is true while the CodeBlock is compiling. Instead, we should check
        if we've finished compiling, and if so, if that compilation failed.

        * wasm/WasmModule.cpp:
        (JSC::Wasm::Module::getOrCreateCodeBlock):

2017-04-07  Saam Barati  <sbarati@apple.com>

        WebAssembly: Make to a compilation API that allows for multi-VM concurrent compilations of Wasm Modules
        https://bugs.webkit.org/show_bug.cgi?id=170488

        Reviewed by JF Bastien.

        This patch adds a class called Wasm::Module. It contains the bits from
        JSWebAssemblyModule that were not VM specific. JSWebAssemblyModule
        now has a Ref<Wasm::Module>. Similarly, there is now a Wasm::CodeBlock,
        which owns the non-VM-specific bits that JSWebAssemblyCodeBlock used
        to own.
        
        This patch also simplifies how we verify and compile code. Wasm::Module
        now has an API for both sync/async validation and compilation. This
        API abstracts away how Wasm::Plan works.
        
        This is hopefully the last patch needed before we can implement
        window.postMessage for a JSWebAssemblyModule. I think all that's
        needed now to implement postMessage is simply creating a new
        JSWebAssemblyModule with the underlying Wasm::Module.
        
        This patch is neutral on WasmBench.
        
        Finally, this patch changes the promise deferred timer to
        allow for new tasks to be added while we're executing
        a task. Before, we'd deadlock if this happened.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * jsc.cpp:
        (functionTestWasmModuleFunctions):
        * runtime/PromiseDeferredTimer.cpp:
        (JSC::PromiseDeferredTimer::doWork):
        (JSC::PromiseDeferredTimer::scheduleWorkSoon):
        * runtime/PromiseDeferredTimer.h:
        * wasm/WasmB3IRGenerator.cpp:
        * wasm/WasmBinding.cpp:
        (JSC::Wasm::wasmToJs):
        (JSC::Wasm::wasmToWasm):
        (JSC::Wasm::exitStubGenerator): Deleted.
        * wasm/WasmBinding.h:
        * wasm/WasmCodeBlock.cpp: Added.
        (JSC::Wasm::CodeBlock::CodeBlock):
        (JSC::Wasm::CodeBlock::waitUntilFinished):
        (JSC::Wasm::CodeBlock::compileAsync):
        (JSC::Wasm::CodeBlock::isSafeToRun):
        * wasm/WasmCodeBlock.h: Added.
        (JSC::Wasm::CodeBlock::create):
        (JSC::Wasm::CodeBlock::compilationFinished):
        (JSC::Wasm::CodeBlock::runnable):
        (JSC::Wasm::CodeBlock::errorMessage):
        (JSC::Wasm::CodeBlock::functionImportCount):
        (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace):
        (JSC::Wasm::CodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace):
        * wasm/WasmModule.cpp: Added.
        (JSC::Wasm::Module::Module):
        (JSC::Wasm::makeValidationResult):
        (JSC::Wasm::Module::validateSyncImpl):
        (JSC::Wasm::Module::getOrCreateCodeBlock):
        (JSC::Wasm::Module::compileSync):
        (JSC::Wasm::Module::makeValidationCallback):
        (JSC::Wasm::Module::compileAsync):
        * wasm/WasmModule.h: Added.
        (JSC::Wasm::Module::create):
        (JSC::Wasm::Module::validateSync):
        (JSC::Wasm::Module::validateAsync):
        (JSC::Wasm::Module::signatureIndexFromFunctionIndexSpace):
        (JSC::Wasm::Module::moduleInformation):
        (JSC::Wasm::Module::nonNullCodeBlock):
        * wasm/WasmPlan.cpp:
        (JSC::Wasm::Plan::Plan):
        (JSC::Wasm::Plan::addCompletionTask):
        (JSC::Wasm::Plan::prepare):
        (JSC::Wasm::Plan::compileFunctions):
        (JSC::Wasm::Plan::complete):
        (JSC::Wasm::Plan::tryRemoveVMAndCancelIfLast):
        (JSC::Wasm::Plan::cancel): Deleted.
        * wasm/WasmPlan.h:
        (JSC::Wasm::Plan::dontFinalize):
        (JSC::Wasm::Plan::takeWasmToWasmExitStubs):
        (JSC::Wasm::Plan::mode):
        (JSC::Wasm::Plan::takeWasmExitStubs): Deleted.
        (JSC::Wasm::Plan::vm): Deleted.
        * wasm/WasmWorklist.cpp:
        (JSC::Wasm::Worklist::stopAllPlansForVM):
        * wasm/js/JSWebAssemblyCodeBlock.cpp:
        (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock):
        (JSC::JSWebAssemblyCodeBlock::isSafeToRun):
        (JSC::JSWebAssemblyCodeBlock::initialize): Deleted.
        * wasm/js/JSWebAssemblyCodeBlock.h:
        (JSC::JSWebAssemblyCodeBlock::create):
        (JSC::JSWebAssemblyCodeBlock::functionImportCount):
        (JSC::JSWebAssemblyCodeBlock::jsEntrypointCalleeFromFunctionIndexSpace):
        (JSC::JSWebAssemblyCodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace):
        (JSC::JSWebAssemblyCodeBlock::wasmToJsCallStubForImport):
        (JSC::JSWebAssemblyCodeBlock::mode): Deleted.
        (JSC::JSWebAssemblyCodeBlock::initialized): Deleted.
        (JSC::JSWebAssemblyCodeBlock::plan): Deleted.
        (JSC::JSWebAssemblyCodeBlock::runnable): Deleted.
        (JSC::JSWebAssemblyCodeBlock::errorMessage): Deleted.
        (JSC::JSWebAssemblyCodeBlock::setJSEntrypointCallee): Deleted.
        (JSC::JSWebAssemblyCodeBlock::setWasmEntrypointCallee): Deleted.
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::finalizeCreation):
        (JSC::JSWebAssemblyInstance::addUnitializedCodeBlock): Deleted.
        * wasm/js/JSWebAssemblyInstance.h:
        (JSC::JSWebAssemblyInstance::initialized): Deleted.
        * wasm/js/JSWebAssemblyModule.cpp:
        (JSC::JSWebAssemblyModule::createStub):
        (JSC::JSWebAssemblyModule::JSWebAssemblyModule):
        (JSC::JSWebAssemblyModule::finishCreation):
        * wasm/js/JSWebAssemblyModule.h:
        (JSC::JSWebAssemblyModule::moduleInformation):
        (JSC::JSWebAssemblyModule::signatureIndexFromFunctionIndexSpace):
        (JSC::JSWebAssemblyModule::module):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::WebAssemblyFunction::create):
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::constructJSWebAssemblyInstance):
        * wasm/js/WebAssemblyModuleConstructor.cpp:
        (JSC::WebAssemblyModuleConstructor::createModule):
        * wasm/js/WebAssemblyPrototype.cpp:
        (JSC::reject):
        (JSC::webAssemblyCompileFunc):
        (JSC::resolve):
        (JSC::instantiate):
        (JSC::compileAndInstantiate):
        (JSC::webAssemblyValidateFunc):

2017-04-07  Carlos Garcia Campos  <cgarcia@igalia.com>

        [GTK] Update the priorities used in glib main loop sources
        https://bugs.webkit.org/show_bug.cgi?id=170457

        Reviewed by Žan Doberšek.

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

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

        Rename allocateStack to allocateStackByGraphColoring.

        Rubber stamped by Saam Barati.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/air/AirAllocateStack.cpp: Removed.
        * b3/air/AirAllocateStack.h: Removed.
        * b3/air/AirAllocateStackByGraphColoring.cpp: Copied from Source/JavaScriptCore/b3/air/AirAllocateStack.cpp.
        (JSC::B3::Air::allocateStackByGraphColoring):
        (JSC::B3::Air::allocateStack): Deleted.
        * b3/air/AirAllocateStackByGraphColoring.h: Copied from Source/JavaScriptCore/b3/air/AirAllocateStack.h.
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::prepareForGeneration):

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

        Cannot Object.seal() or Object.freeze() global "this"
        https://bugs.webkit.org/show_bug.cgi?id=170549

        Reviewed by Mark Lam.

        Needed to implement JSProxy::isExtensible() which returns the results of calling
        the same on wrapped object.

        Implemented step 11 of Runtime Semantics: EvalDeclarationInstantiation from the ECMAScript
        spec to properly return a TypeError object when attempting to add properties to a
        non-extensible global object.

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        * runtime/JSProxy.cpp:
        (JSC::JSProxy::isExtensible):
        * runtime/JSProxy.h:

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

        Linear scan should run liveness only once
        https://bugs.webkit.org/show_bug.cgi?id=170569

        Reviewed by Keith Miller.
        
        Air has a longstanding design bug that Tmps from different banks are indexed independently. This
        means that all of our analyses over Tmps do separate GP and FP passes. This does have some
        marginal benefits (the rest of the algorithm is specialized for Bank) but it's probably net bad.
        However, I don't want to think about solving that general problem.
        
        Instead, this just makes linear scan use a UnifiedTmpLiveness that uses a single "linear"
        indexing for GP and FP. This lets me avoid the much larger refactoring (which would involve
        substantial changes in graph coloring) while getting the bulk of the benefit (liveness runs once,
        instead of twice, for linear scan).
        
        This patch implements a lot of plumbing to make it possible for Liveness<> to view Tmps as having
        a unified indexing scheme. Tmp calls this LinearlyIndexed (to match the naming convention of
        AbsolutelyIndexed and Indexed), while AirLiveness calls this UnifiedTmpLiveness. With this
        change, -O1 never does any liveness analysis that uses separate GP and FP passes. I think this
        eliminates any urgency from the larger Tmp indexing bug. We can probably live with graph coloring
        doing separate passes.
        
        This is a ~6% speed-up for wasm -O1 compile times. I think this means that linear scan is no
        longer the longest pole in the tent.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3VariableLiveness.h:
        (JSC::B3::VariableLivenessAdapter::prepareToCompute):
        * b3/air/AirAllocateRegistersByLinearScan.cpp:
        (JSC::B3::Air::allocateRegistersByLinearScan):
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::forEachTmp):
        * b3/air/AirLiveness.h:
        * b3/air/AirLivenessAdapter.h:
        (JSC::B3::Air::LivenessAdapter::Actions::Actions):
        (JSC::B3::Air::LivenessAdapter::LivenessAdapter):
        (JSC::B3::Air::LivenessAdapter::adapter):
        (JSC::B3::Air::LivenessAdapter::prepareToCompute):
        (JSC::B3::Air::LivenessAdapter::actionsAt):
        (JSC::B3::Air::LivenessAdapter::forEachUse):
        (JSC::B3::Air::LivenessAdapter::forEachDef):
        (JSC::B3::Air::TmpLivenessAdapter::numIndices):
        (JSC::B3::Air::UnifiedTmpLivenessAdapter::UnifiedTmpLivenessAdapter):
        (JSC::B3::Air::UnifiedTmpLivenessAdapter::numIndices):
        (JSC::B3::Air::UnifiedTmpLivenessAdapter::acceptsBank):
        (JSC::B3::Air::UnifiedTmpLivenessAdapter::acceptsRole):
        (JSC::B3::Air::UnifiedTmpLivenessAdapter::valueToIndex):
        (JSC::B3::Air::UnifiedTmpLivenessAdapter::indexToValue):
        * b3/air/AirLivenessConstraints.h: Removed.
        * b3/air/AirRegLiveness.h:
        (JSC::B3::Air::RegLiveness::LocalCalc::LocalCalc):
        * b3/air/AirTmp.cpp:
        * b3/air/AirTmp.h:
        * b3/air/AirTmpInlines.h:
        (JSC::B3::Air::Tmp::LinearlyIndexed::LinearlyIndexed):
        (JSC::B3::Air::Tmp::LinearlyIndexed::index):
        (JSC::B3::Air::Tmp::linearlyIndexed):
        (JSC::B3::Air::Tmp::indexEnd):
        (JSC::B3::Air::Tmp::absoluteIndexEnd):
        (JSC::B3::Air::Tmp::linearIndexEnd):
        (JSC::B3::Air::Tmp::tmpForAbsoluteIndex):
        (JSC::B3::Air::Tmp::tmpForLinearIndex):
        * b3/air/AirTmpMap.h: Added.
        (JSC::B3::Air::TmpMap::TmpMap):
        (JSC::B3::Air::TmpMap::resize):
        (JSC::B3::Air::TmpMap::clear):
        (JSC::B3::Air::TmpMap::operator[]):
        (JSC::B3::Air::TmpMap::append):

2017-04-06  Ryan Haddad  <ryanhaddad@apple.com>

        Unreviewed, rolling out r215046.

        This change broke internal builds.

        Reverted changeset:

        "WebRTC tests gardening"
        https://bugs.webkit.org/show_bug.cgi?id=170508
        http://trac.webkit.org/changeset/215046

2017-04-06  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Show all headers in the Request Headers section of the Resource details sidebar
        https://bugs.webkit.org/show_bug.cgi?id=16531
        <rdar://problem/5712895>

        Reviewed by Timothy Hatcher.

        * inspector/protocol/Network.json:
        Optional refined list of request headers in Metrics.

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

        B3 -O1 should generate better code than -O0
        https://bugs.webkit.org/show_bug.cgi?id=170563

        Reviewed by Michael Saboff.
        
        Prior to this change, code generated by -O1 ran slower than code generated by -O0. This turned
        out to be because of reduceStrength optimizations that increase live ranges and create register
        pressure, which then creates problems for linear scan.
        
        It seemed obvious that canonicalizations that help isel, constant folding, and one-for-one
        strength reductions should stay. It also seemed obvious that SSA and CFG simplification are fast
        and harmless. So, I focused on removing:
        
        - CSE, which increases live ranges. This is a risky optimization when we know that we've chosen
          to use a bad register allocator.
        
        - Sophisticated strength reductions that create more code, like the insane division optimization.
        
        - Anything that inserts basic blocks.
        
        CSE appeared to be the cause of half of the throughput regression of -O1 but none of the compile
        time. This change also reduces the running time of reduceStrength by making it not a fixpoint at
        optLevel<2.
        
        This makes wasm -O1 compile 17% faster. This makes wasm -O1 run 19% faster. This makes -O1 code
        run 3% faster than -O0, and compile about 4% slower than -O0. We may yet end up choosing to use
        -O0, but at least now -O1 isn't totally useless.

        * b3/B3ReduceStrength.cpp:

2017-04-06  Jon Davis  <jond@apple.com>

        Updates feature status for recently shipped features
        https://bugs.webkit.org/show_bug.cgi?id=170359

        Reviewed by Brian Burg.

        Changed "Done" status to "Supported".

        * features.json:

2017-04-06  Youenn Fablet  <youenn@apple.com>

        WebRTC tests gardening
        https://bugs.webkit.org/show_bug.cgi?id=170508

        Reviewed by Eric Carlson.

        * Configurations/FeatureDefines.xcconfig:

2017-04-06  Guillaume Emont  <guijemont@igalia.com>

        [JSC][MIPS][DFG] Use x86 generic HasOwnProperty
        https://bugs.webkit.org/show_bug.cgi?id=170222

        Reviewed by Yusuke Suzuki.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        use the X86 special version for HasOwnProperty on MIPS too.
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        use the X86 special version for HasOwnProperty on MIPS too.

2017-04-05  Saam Barati  <sbarati@apple.com>

        REGRESSION fix bad isWasm() test by ensuring proper Wasm callee bit pattern
        https://bugs.webkit.org/show_bug.cgi?id=170494
        <rdar://problem/31446485>

        Reviewed by Yusuke Suzuki and Mark Lam.

        This patch fixes how we test a 64 bit JSValue pattern to see if it's
        a Wasm callee. We now tag Wasm::Callee's with 0b011 in their lower 3 bits.
        The new test is for a Wasm Callee is as follows:
        isWasm(uint64_t x)
        {
            return x & 0xffff000000000007 == 3;
        }
        
        This test works because the lower 3 bits of the non-number immediate values are as follows:
        undefined: 0b010
        null:      0b010
        true:      0b111
        false:     0b110
        The test rejects all of these because none have just the value 3 in their lower 3 bits.
        The test also rejects all numbers, because they have non-zero upper 16 bits.
        The test also rejects normal cells because they won't have the number 3 as
        their lower 3 bits. Note, this bit pattern also allows the normal JSValue isCell(), etc,
        predicates to work on a Wasm::Callee because the various tests will fail if you
        bit casted a boxed Wasm::Callee* to a JSValue. isCell() would fail since it sees
        TagBitTypeOther. The other tests also trivially fail, since it won't be a number,
        and it won't be equal to null, undefined, true, or false. The isBoolean() predicate
        will fail because we won't have TagBitBool set.

        * interpreter/CallFrame.h:
        (JSC::ExecState::guaranteedJSValueCallee):
        (JSC::ExecState::calleeAsValue): Deleted.
        * interpreter/CalleeBits.h:
        (JSC::CalleeBits::boxWasm):
        (JSC::CalleeBits::isWasm):
        (JSC::CalleeBits::asWasmCallee):
        * jit/JITOperations.cpp:
        * runtime/JSCJSValue.h:

2017-04-05  Keith Miller  <keith_miller@apple.com>

        WebAssembly: Plans should be able to have more than one completion task.
        https://bugs.webkit.org/show_bug.cgi?id=170516

        Reviewed by Saam Barati.

        This patch also eliminates the need for blocked tasks on the
        PromiseDeferredTimer and pendingPromise on Wasm::Plan.

        * runtime/PromiseDeferredTimer.cpp:
        (JSC::PromiseDeferredTimer::doWork):
        (JSC::PromiseDeferredTimer::cancelPendingPromise):
        (JSC::PromiseDeferredTimer::scheduleBlockedTask): Deleted.
        * runtime/PromiseDeferredTimer.h:
        * wasm/WasmPlan.cpp:
        (JSC::Wasm::Plan::Plan):
        (JSC::Wasm::Plan::addCompletionTask):
        (JSC::Wasm::Plan::complete):
        * wasm/WasmPlan.h:
        (JSC::Wasm::Plan::setMode):
        (JSC::Wasm::Plan::mode):
        (JSC::Wasm::Plan::setModeAndPromise): Deleted.
        (JSC::Wasm::Plan::pendingPromise): Deleted.
        * wasm/WasmWorklist.cpp:
        (JSC::Wasm::Worklist::enqueue):
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::constructJSWebAssemblyInstance):
        * wasm/js/WebAssemblyPrototype.cpp:
        (JSC::instantiate):

2017-04-05  Guilherme Iscaro  <iscaro@profusion.mobi>

        Do not use BLX for immediates (ARM-32)

        https://bugs.webkit.org/show_bug.cgi?id=170351

        Reviewed by Mark Lam.

        Currently the offline asm generator for 32-bit ARM code translates the
        'call' meta-instruction (which may be found in LowLevelInterpreter.asm
        and friends) to the ARM's BLX instrunction. The BLX instruction may be
        used for labels (immediates) and registers and one side effect of BLX
        is that it may switch the processor's instruction set.
        A 'BLX register' instruction will change/remain the processor state to
        ARM if the  register_bit[0] is set to 0 or change/remain to Thumb if
        register_bit[0] is set to 1. However, a 'BLX label' instruction will
        always switch the processor state. It switches ARM to thumb and vice-versa.
        This behaviour is unwanted, since the C++ code and the offlineasm generated code
        are both compiled using the same instruction set, thus a instruction
        set change will likely produce a crash. In order to fix the problem the
        BL instruction can be used for labels. It will branch just like BLX,
        but it won't change the instruction set. It's important to note that
        Darwin is not affected by this problem, thus to minimize the impact of
        this change the BL instruction will only be used on non-darwin targets.

        BLX reference: http://infocenter.arm.com/help/topic/com.arm.doc.dui0489i/CIHBJCDC.html?resultof=%22%62%6c%78%22%20

        * offlineasm/arm.rb:

2017-04-05  Keith Miller  <keith_miller@apple.com>

        WebAssembly: We shouldn't need to pin size registers if we have a fast memory.
        https://bugs.webkit.org/show_bug.cgi?id=170504

        Reviewed by Mark Lam.

        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        (JSC::Wasm::createJSToWasmWrapper):
        (JSC::Wasm::parseAndCompile):
        * wasm/WasmMemoryInformation.h:
        (JSC::Wasm::PinnedRegisterInfo::toSave):

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

        [JSC] Suppress warnings in GCC
        https://bugs.webkit.org/show_bug.cgi?id=170501

        Reviewed by Keith Miller.

        Should use ASSERT_NOT_REACHED since return-type pragma is only
        enabled under ASSERT_DISABLED environment. We shoud use
        ASSERT_NOTREACHED to emit assertions in debug build. It effectively
        catches bugs while keeping performance in release build.

        * b3/B3Opcode.cpp:
        (JSC::B3::storeOpcode):
        * b3/B3Width.h:
        (JSC::B3::mask):
        * runtime/Options.cpp:
        (JSC::parse):
        * wasm/WasmSections.h:
        (JSC::Wasm::makeString):
        * wasm/WasmSignature.cpp:
        (JSC::Wasm::SignatureInformation::tryCleanup):
        * wasm/generateWasmValidateInlinesHeader.py:

2017-04-05  Carlos Garcia Campos  <cgarcia@igalia.com>

        Implement PromiseDeferredTimer for non CF based ports
        https://bugs.webkit.org/show_bug.cgi?id=170391

        Reviewed by Yusuke Suzuki.

        RunLoop handling is only implemented for CF causing several wasm tests to fail for other ports.

        * jsc.cpp:
        (runJSC): Remove CF ifdefs.
        * runtime/PromiseDeferredTimer.cpp:
        (JSC::PromiseDeferredTimer::doWork): Add non CF implementation using WTF RunLoop.
        (JSC::PromiseDeferredTimer::runRunLoop): Ditto.
        * runtime/PromiseDeferredTimer.h:

2017-04-05  Carlos Garcia Campos  <cgarcia@igalia.com>

        WebAssembly: several tests added in r214504 crash when building with GCC
        https://bugs.webkit.org/show_bug.cgi?id=170390

        Reviewed by Saam Barati.

        The pattern foo->bar([f = WTFMove(foo)]{}); crashes when building with GCC, I assume the move happens before the
        foo is used to invoke the function.

        * wasm/js/WebAssemblyPrototype.cpp:
        (JSC::webAssemblyCompileFunc): Use p.vm() instead of plan->vm(), because plan is moved by the lambda.
        (JSC::instantiate): Ditto.
        (JSC::compileAndInstantiate): Ditto.

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

        [JSC] Generate TemplateObjects at linking time
        https://bugs.webkit.org/show_bug.cgi?id=169743

        Reviewed by Keith Miller.

        Currently, the code calls getTemplateObject to get appropriate template objects at runtime.
        But this template object is constant value and never changed. So instead of creating it
        at runtime, we should create it at linking time and store it in the constant registers.

        * builtins/BuiltinNames.h:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::setConstantRegisters):
        * bytecode/CodeBlock.h:
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::shrinkToFit):
        * bytecode/UnlinkedCodeBlock.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::addTemplateRegistryKeyConstant):
        (JSC::BytecodeGenerator::emitGetTemplateObject):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::TaggedTemplateNode::emitBytecode):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::getTemplateObject): Deleted.
        * runtime/JSTemplateRegistryKey.cpp:
        * runtime/JSTemplateRegistryKey.h:
        (JSC::isTemplateRegistryKey):

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

        On ARM64, DFG::SpeculativeJIT::compileArithMod() failed to ensure result is of DataFormatInt32.
        https://bugs.webkit.org/show_bug.cgi?id=170473
        <rdar://problem/29912391>

        Reviewed by Saam Barati.

        In Unchecked mode, when DFG::SpeculativeJIT::compileArithMod() detects that the
        divisor is 0, we want it to return 0.  The result is expected to be of
        DataFormatIn32.

        The ARM implementation just returns the value in the divisor register.  However,
        the divisor in this case can be of DataFormatJSInt32.  On ARM64, returning the
        divisor register yields the wrong result format because the same register also
        holds the upper 32-bit of the JSValue encoding.  The fix is to return an
        immediate 0 instead.

        Also turned on the assertion in jitAssertIsInt32 for ARM64.  This assertion being
        disabled may have contributed to this bug going unnoticed all this time.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithMod):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::jitAssertIsInt32):

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

        Air::eliminateDeadCode should not repeatedly process the same live instructions
        https://bugs.webkit.org/show_bug.cgi?id=170490

        Reviewed by Keith Miller.
        
        This makes the eliminateDeadCode() fixpoint somewhat worklist-based: we track the set
        of Insts that might be dead. Every time we detect that one is live, we remove it from
        the set. This is a big (>2x) speed-up because lots of Insts are immediately found to
        be live.
        
        This is a ~1% wasm -O1 compile time progression.

        * b3/air/AirEliminateDeadCode.cpp:
        (JSC::B3::Air::eliminateDeadCode):

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

        Air::eliminateDeadCode() should not use a HashSet
        https://bugs.webkit.org/show_bug.cgi?id=170487

        Reviewed by Saam Barati.
        
        Introduce TmpSet, which is like a HashSet<Tmp>. Use this to make eliminateDeadCode()
        about 50% faster, resulting in a 1% wasm -O1 compile time progression.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/air/AirEliminateDeadCode.cpp:
        (JSC::B3::Air::eliminateDeadCode):
        * b3/air/AirTmpSet.h: Added.
        (JSC::B3::Air::TmpSet::TmpSet):
        (JSC::B3::Air::TmpSet::add):
        (JSC::B3::Air::TmpSet::remove):
        (JSC::B3::Air::TmpSet::contains):
        (JSC::B3::Air::TmpSet::size):
        (JSC::B3::Air::TmpSet::isEmpty):
        (JSC::B3::Air::TmpSet::iterator::iterator):
        (JSC::B3::Air::TmpSet::iterator::operator*):
        (JSC::B3::Air::TmpSet::iterator::operator++):
        (JSC::B3::Air::TmpSet::iterator::operator==):
        (JSC::B3::Air::TmpSet::iterator::operator!=):
        (JSC::B3::Air::TmpSet::begin):
        (JSC::B3::Air::TmpSet::end):

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

        WebAssembly: ModuleInformation should be a ref counted thing that can be shared across threads.
        https://bugs.webkit.org/show_bug.cgi?id=170478

        Reviewed by Saam Barati.

        ModuleInformation has been moved to its own file and is now
        ThreadSafeRefCounted.  All the Strings we used to keep in the
        ModuleInformation have been switched to Vector<LChar> this has the
        advantage that it can be passed across threads. However, this does
        mean that we need to decode the utf8 strings in each thread. This
        is likely not a problem because:

        1) most modules have few imports/exports/custom sections.
        2) most of the time they are ascii so the conversion is cheap.
        3) we only have to do it once per thread, and there shouldn't be too many.

        This patch also removes
        moduleSignatureIndicesToUniquedSignatureIndices since that
        information can already be recovered from the
        SignatureInformation.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * jsc.cpp:
        (functionTestWasmModuleFunctions):
        * runtime/Identifier.h:
        (JSC::Identifier::fromString):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::parseAndCompile):
        * wasm/WasmB3IRGenerator.h:
        * wasm/WasmFormat.cpp:
        (JSC::Wasm::makeString):
        (JSC::Wasm::ModuleInformation::~ModuleInformation): Deleted.
        * wasm/WasmFormat.h:
        (JSC::Wasm::makeString):
        (JSC::Wasm::ModuleInformation::functionIndexSpaceSize): Deleted.
        (JSC::Wasm::ModuleInformation::isImportedFunctionFromFunctionIndexSpace): Deleted.
        (JSC::Wasm::ModuleInformation::signatureIndexFromFunctionIndexSpace): Deleted.
        (JSC::Wasm::ModuleInformation::importFunctionCount): Deleted.
        (JSC::Wasm::ModuleInformation::internalFunctionCount): Deleted.
        * wasm/WasmFunctionParser.h:
        (JSC::Wasm::FunctionParser<Context>::FunctionParser):
        * wasm/WasmModuleInformation.cpp: Copied from Source/JavaScriptCore/wasm/WasmValidate.h.
        (JSC::Wasm::ModuleInformation::~ModuleInformation):
        * wasm/WasmModuleInformation.h: Added.
        (JSC::Wasm::ModuleInformation::functionIndexSpaceSize):
        (JSC::Wasm::ModuleInformation::isImportedFunctionFromFunctionIndexSpace):
        (JSC::Wasm::ModuleInformation::signatureIndexFromFunctionIndexSpace):
        (JSC::Wasm::ModuleInformation::importFunctionCount):
        (JSC::Wasm::ModuleInformation::internalFunctionCount):
        (JSC::Wasm::ModuleInformation::ModuleInformation):
        * wasm/WasmModuleParser.cpp:
        * wasm/WasmModuleParser.h:
        (JSC::Wasm::ModuleParser::ModuleParser):
        * wasm/WasmParser.h:
        (JSC::Wasm::Parser<SuccessType>::consumeUTF8String):
        * wasm/WasmPlan.cpp:
        (JSC::Wasm::Plan::Plan):
        (JSC::Wasm::Plan::parseAndValidateModule):
        (JSC::Wasm::Plan::prepare):
        (JSC::Wasm::Plan::compileFunctions):
        (JSC::Wasm::Plan::complete):
        (JSC::Wasm::Plan::cancel):
        * wasm/WasmPlan.h:
        (JSC::Wasm::Plan::internalFunctionCount):
        (JSC::Wasm::Plan::takeModuleInformation):
        * wasm/WasmSignature.cpp:
        (JSC::Wasm::SignatureInformation::get):
        * wasm/WasmSignature.h:
        * wasm/WasmValidate.cpp:
        (JSC::Wasm::validateFunction):
        * wasm/WasmValidate.h:
        * wasm/js/JSWebAssemblyHelpers.h:
        (JSC::createSourceBufferFromValue):
        * wasm/js/JSWebAssemblyModule.cpp:
        (JSC::JSWebAssemblyModule::createStub):
        (JSC::JSWebAssemblyModule::JSWebAssemblyModule):
        (JSC::JSWebAssemblyModule::finishCreation):
        * wasm/js/JSWebAssemblyModule.h:
        (JSC::JSWebAssemblyModule::moduleInformation):
        (JSC::JSWebAssemblyModule::source):
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::constructJSWebAssemblyInstance):
        * wasm/js/WebAssemblyModuleConstructor.cpp:
        (JSC::WebAssemblyModuleConstructor::createModule):
        * wasm/js/WebAssemblyModulePrototype.cpp:
        (JSC::webAssemblyModuleProtoCustomSections):
        (JSC::webAssemblyModuleProtoImports):
        (JSC::webAssemblyModuleProtoExports):
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::link):
        * wasm/js/WebAssemblyModuleRecord.h:
        * wasm/js/WebAssemblyPrototype.cpp:
        (JSC::webAssemblyCompileFunc):
        (JSC::instantiate):
        (JSC::compileAndInstantiate):

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

        B3::fixSSA() needs a tune-up
        https://bugs.webkit.org/show_bug.cgi?id=170485

        Reviewed by Saam Barati.
        
        After the various optimizations to liveness, register allocation, and other phases, the
        fixSSA() phase now looks like one of the top offenders. This includes a bunch of
        changes to make this phase run faster. This is a ~7% wasm -O1 compile time progression.
        
        Here's what I did:
        
        - We now use IndexSparseSet instead of IndexMap for tracking variable values. This
          makes it cheaper to chew through small blocks while there is a non-trivial number of
          total variables.
        
        - We now do a "local SSA conversion" pass before anything else. This eliminates
          obvious Get's. If we were using temporary Variables, it would eliminate many of
          those. That's useful for when we use demoteValues() and duplciateTails(). For wasm
          -O1, we mainly care about the fact that it makes a bunch of Set's dead.
        
        - We now do a Set DCE pass after the local SSA but before SSA conversion. This ensures
          that any block-local live intervals of Variables disappear and don't need further
          consideration.
        
        - We now cache the reaching defs calculation.
        
        - We now perform the reaching defs calculation lazily.

        * b3/B3FixSSA.cpp:
        (JSC::B3::demoteValues):
        (JSC::B3::fixSSA):
        * b3/B3SSACalculator.cpp:
        (JSC::B3::SSACalculator::reachingDefAtTail):
        * b3/B3VariableLiveness.cpp:
        (JSC::B3::VariableLiveness::VariableLiveness):
        * b3/air/AirLiveness.h:
        (JSC::B3::Air::Liveness::Liveness):
        * dfg/DFGLivenessAnalysisPhase.cpp:
        (JSC::DFG::LivenessAnalysisPhase::LivenessAnalysisPhase): Deleted.
        (JSC::DFG::LivenessAnalysisPhase::run): Deleted.
        (JSC::DFG::LivenessAnalysisPhase::processBlock): Deleted.

2017-04-04  Joseph Pecoraro  <pecoraro@apple.com>

        Remove stale LLVM Header Path includes from JavaScriptCore
        https://bugs.webkit.org/show_bug.cgi?id=170483

        Reviewed by Mark Lam.

        * Configurations/Base.xcconfig:

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

        B3::LowerToAir incorrectly selects BitXor(AtomicStrongCAS(...), $1)
        https://bugs.webkit.org/show_bug.cgi?id=169867

        Reviewed by Saam Barati.
        
        The BitXor(AtomicWeakCAS(...), $1) optimization makes a lot of sense because we an fold the
        BitXor into the CAS condition read-out. But there is no version of this that is profitable or
        correct for AtomicStrongCAS. The inversion case is handled by Equal(AtomicStrongCAS(...), ...)
        becoming NotEqual(AtomicStrongCAS(...), ...), and we alraedy handle that separately.
        
        So, the fix here is to make the BitXor CAS pattern only recognize AtomicWeakCAS.

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

2017-04-04  Saam Barati  <sbarati@apple.com>

        WebAssembly: JSWebAssemblyCallee should not be a JSCell
        https://bugs.webkit.org/show_bug.cgi?id=170135

        Reviewed by Michael Saboff.

        This patch is perhaps the last big change to the design of fundamental
        Wasm API to allow for PIC. It changes JSWebAssemblyCallee into a thing
        called Wasm::Callee. It serves the same purpose as before, except
        Wasm::Callee is not a JSCell. I had to refactor the various parts of the
        runtime that will see CallFrame's with Wasm::Callee's in the callee slot.
        Thankfully, the parts of the runtime that Wasm touches are limited. The
        main refactoring is changing the exception handling code, such as taking
        a stack trace, to be friendly to seeing a non JSCell callee.
        
        The callee() function on ExecState now returns a class I added in this
        patch called CalleeBits. CalleeBits will tell you if the callee is a
        JSCell or a Wasm::Callee. We tag Wasm::Callee's with a 1 in their lower
        bit so we can easily tell what is and isn't a Wasm::Callee.
        
        The stub that calls out from Wasm to JS still puts a JSCell callee
        into the call frame, even though the callee logically represents a
        Wasm frame. The reason for this is that we use the call IC infrastructure
        to make a call out to JS code, and the code that writes the IC expects
        a JSCell as the callee. This is knowingly part of our design. When we
        do structured cloning of Wasm Modules, we'll need to regenerate these
        JS call stubs.

        * API/JSContextRef.cpp:
        (BacktraceFunctor::operator()):
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * debugger/Debugger.cpp:
        (JSC::Debugger::pauseIfNeeded):
        (JSC::Debugger::currentDebuggerCallFrame):
        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::create):
        (JSC::DebuggerCallFrame::DebuggerCallFrame):
        (JSC::DebuggerCallFrame::currentPosition):
        (JSC::DebuggerCallFrame::positionForCallFrame):
        * debugger/DebuggerCallFrame.h:
        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::vmEntryGlobalObject):
        (JSC::CallFrame::wasmAwareLexicalGlobalObject):
        (JSC::CallFrame::isAnyWasmCallee):
        (JSC::CallFrame::callerSourceOrigin):
        * interpreter/CallFrame.h:
        (JSC::ExecState::calleeAsValue):
        (JSC::ExecState::jsCallee):
        (JSC::ExecState::callee):
        (JSC::ExecState::unsafeCallee):
        (JSC::ExecState::scope):
        (JSC::ExecState::iterate):
        * interpreter/CalleeBits.h: Added.
        (JSC::CalleeBits::CalleeBits):
        (JSC::CalleeBits::operator=):
        (JSC::CalleeBits::boxWasm):
        (JSC::CalleeBits::isWasm):
        (JSC::CalleeBits::isCell):
        (JSC::CalleeBits::asCell):
        (JSC::CalleeBits::asWasmCallee):
        (JSC::CalleeBits::rawPtr):
        * interpreter/Interpreter.cpp:
        (JSC::GetStackTraceFunctor::operator()):
        (JSC::Interpreter::getStackTrace):
        (JSC::notifyDebuggerOfUnwinding):
        (JSC::UnwindFunctor::UnwindFunctor):
        (JSC::UnwindFunctor::operator()):
        (JSC::UnwindFunctor::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
        (JSC::Interpreter::unwind):
        (JSC::Interpreter::notifyDebuggerOfExceptionToBeThrown):
        * interpreter/Interpreter.h:
        * interpreter/Register.h:
        (JSC::Register::pointer):
        * interpreter/ShadowChicken.cpp:
        (JSC::ShadowChicken::update):
        * interpreter/ShadowChickenInlines.h:
        (JSC::ShadowChicken::iterate):
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::StackVisitor):
        (JSC::StackVisitor::readFrame):
        (JSC::StackVisitor::readNonInlinedFrame):
        (JSC::StackVisitor::readInlinedFrame):
        (JSC::StackVisitor::Frame::calleeSaveRegisters):
        (JSC::StackVisitor::Frame::functionName):
        (JSC::StackVisitor::Frame::dump):
        * interpreter/StackVisitor.h:
        (JSC::StackVisitor::Frame::callee):
        (JSC::StackVisitor::visit):
        * jit/Repatch.cpp:
        (JSC::linkFor):
        (JSC::linkPolymorphicCall):
        * jsc.cpp:
        (callWasmFunction):
        (functionTestWasmModuleFunctions):
        * runtime/ArrayPrototype.cpp:
        * runtime/Error.cpp:
        (JSC::addErrorInfoAndGetBytecodeOffset):
        * runtime/ErrorInstance.cpp:
        (JSC::ErrorInstance::finishCreation):
        * runtime/JSCell.cpp:
        (JSC::JSCell::isAnyWasmCallee): Deleted.
        * runtime/JSCell.h:
        * runtime/JSCellInlines.h:
        (JSC::ExecState::vm):
        * runtime/JSFunction.cpp:
        (JSC::RetrieveArgumentsFunctor::operator()):
        (JSC::RetrieveCallerFunctionFunctor::operator()):
        * runtime/JSGlobalObject.cpp:
        * runtime/SamplingProfiler.cpp:
        (JSC::FrameWalker::recordJSFrame):
        (JSC::SamplingProfiler::processUnverifiedStackTraces):
        * runtime/SamplingProfiler.h:
        (JSC::SamplingProfiler::UnprocessedStackFrame::UnprocessedStackFrame):
        * runtime/StackFrame.cpp:
        (JSC::StackFrame::sourceURL):
        (JSC::StackFrame::functionName):
        * runtime/StackFrame.h:
        (JSC::StackFrame::wasm):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::throwException):
        * runtime/VM.h:
        * wasm/JSWebAssembly.h:
        * wasm/WasmB3IRGenerator.cpp:
        * wasm/WasmBinding.cpp:
        (JSC::Wasm::wasmToWasm):
        * wasm/WasmCallee.cpp: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyCallee.cpp.
        (JSC::Wasm::Callee::Callee):
        (JSC::JSWebAssemblyCallee::JSWebAssemblyCallee): Deleted.
        (JSC::JSWebAssemblyCallee::finishCreation): Deleted.
        (JSC::JSWebAssemblyCallee::destroy): Deleted.
        * wasm/WasmCallee.h: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyCallee.h.
        (JSC::Wasm::Callee::create):
        (JSC::JSWebAssemblyCallee::create): Deleted.
        (JSC::JSWebAssemblyCallee::createStructure): Deleted.
        (JSC::JSWebAssemblyCallee::entrypoint): Deleted.
        (JSC::JSWebAssemblyCallee::calleeSaveRegisters): Deleted.
        * wasm/WasmContext.h:
        * wasm/WasmPlan.cpp:
        * wasm/WasmPlan.h:
        * wasm/WasmPlanInlines.h:
        (JSC::Wasm::Plan::initializeCallees):
        * wasm/WasmThunks.cpp:
        (JSC::Wasm::throwExceptionFromWasmThunkGenerator):
        * wasm/js/JSWebAssemblyCallee.cpp: Removed.
        * wasm/js/JSWebAssemblyCallee.h: Removed.
        * wasm/js/JSWebAssemblyCodeBlock.cpp:
        (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock):
        (JSC::JSWebAssemblyCodeBlock::initialize):
        (JSC::JSWebAssemblyCodeBlock::visitChildren):
        * wasm/js/JSWebAssemblyCodeBlock.h:
        (JSC::JSWebAssemblyCodeBlock::create):
        (JSC::JSWebAssemblyCodeBlock::jsEntrypointCalleeFromFunctionIndexSpace):
        (JSC::JSWebAssemblyCodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace):
        (JSC::JSWebAssemblyCodeBlock::wasmToJsCallStubForImport):
        (JSC::JSWebAssemblyCodeBlock::offsetOfImportWasmToJSStub):
        (JSC::JSWebAssemblyCodeBlock::setJSEntrypointCallee):
        (JSC::JSWebAssemblyCodeBlock::setWasmEntrypointCallee):
        (JSC::JSWebAssemblyCodeBlock::offsetOfImportStubs):
        (JSC::JSWebAssemblyCodeBlock::allocationSize):
        (JSC::JSWebAssemblyCodeBlock::importWasmToJSStub):
        (JSC::JSWebAssemblyCodeBlock::callees): Deleted.
        (JSC::JSWebAssemblyCodeBlock::offsetOfCallees): Deleted.
        * wasm/js/JSWebAssemblyInstance.h:
        (JSC::JSWebAssemblyInstance::webAssemblyToJSCallee):
        * wasm/js/JSWebAssemblyModule.cpp:
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction):
        (JSC::WebAssemblyFunction::create):
        (JSC::WebAssemblyFunction::WebAssemblyFunction):
        (JSC::WebAssemblyFunction::visitChildren):
        (JSC::WebAssemblyFunction::finishCreation):
        * wasm/js/WebAssemblyFunction.h:
        (JSC::WebAssemblyFunction::wasmEntrypoint):
        (JSC::WebAssemblyFunction::jsEntrypoint):
        (JSC::WebAssemblyFunction::offsetOfWasmEntrypoint):
        (JSC::WebAssemblyFunction::offsetOfWasmEntryPointCode): Deleted.
        * wasm/js/WebAssemblyModuleConstructor.cpp:
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::link):
        (JSC::WebAssemblyModuleRecord::evaluate):

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

        WasmBench asserts in debug jsc
        https://bugs.webkit.org/show_bug.cgi?id=170462

        Reviewed by Saam Barati.

        The assertion should have been an if.

        * wasm/WasmWorklist.cpp:

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

        Air::lowerAfterRegAlloc should bail early if it finds no Shuffles or ColdCCalls
        https://bugs.webkit.org/show_bug.cgi?id=170305

        Reviewed by Saam Barati.
        
        This reduces and sometimes completely eliminates the need to run lowerAfterRegAlloc().
        
        This lowers the Shuffle for the arguments of a CCall before register allocation unless
        the CCall arguments require a real shuffle (like if the CCall arguments were argument
        registers). This lowers a ColdCCall like a CCall for optLevel<2.
        
        Finally, lowerAfterRegAlloc() now checks if there are any Shuffles or CCalls before it
        does anything else. For wasm at -O1, this means that the phase doesn't run at all. This
        is a ~3% wasm -O1 compile time progression.
        
        To make this easy, I changed optLevel into a property of Procedure and Code rather than
        an argument we thread through everything. I like how Procedure and Code are dumping
        ground classes. This does not bother me. Note that I cloned optLevel into Procedure and
        Code so that it's cheap to query inside Air phases.

        * b3/B3Compile.cpp:
        (JSC::B3::compile):
        * b3/B3Compile.h:
        * b3/B3Generate.cpp:
        (JSC::B3::prepareForGeneration):
        (JSC::B3::generateToAir):
        * b3/B3Generate.h:
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::setOptLevel):
        * b3/B3Procedure.h:
        (JSC::B3::Procedure::optLevel):
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::isPinned):
        (JSC::B3::Air::Code::setOptLevel):
        (JSC::B3::Air::Code::optLevel):
        * b3/air/AirEmitShuffle.cpp:
        (JSC::B3::Air::ShufflePair::bank):
        (JSC::B3::Air::ShufflePair::opcode):
        (JSC::B3::Air::ShufflePair::inst):
        (JSC::B3::Air::emitShuffle):
        * b3/air/AirEmitShuffle.h:
        (JSC::B3::Air::moveFor):
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::prepareForGeneration):
        * b3/air/AirGenerate.h:
        * b3/air/AirLowerAfterRegAlloc.cpp:
        (JSC::B3::Air::lowerAfterRegAlloc):
        * b3/air/AirLowerMacros.cpp:
        (JSC::B3::Air::lowerMacros):
        * b3/testb3.cpp:
        (JSC::B3::compileProc):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::parseAndCompile):

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

        Don't need to Air::reportUsedRegisters for wasm at -O1
        https://bugs.webkit.org/show_bug.cgi?id=170459

        Reviewed by Saam Barati.
        
        I did some refactorings to Liveness<> to try to understand its performance. Based on
        this I concluded that the bigger immediate issue is just removing unnecessary phases
        from -O1.
        
        This removes Air::reportUsedRegisters() from -O1 if the user has indicated that he is
        not interested in StackmapGenerationParams::usedRegisters(). The logic here is a bit
        weird because of how Air does spill code generation. The register allocator's spiller
        will emit spill code using identifiable spill slots, which allows subsequent phases to
        register-allocate the spill slots. We do this by a forward flow CSE phase called
        fixObviousSpills (which is a terrible name since there is no longer anything obvious
        about some of the spills that this phase can fix!). As is most natural for CSEs over
        3AC, it rewires the uses of redundant computations rather than removing the redundant
        computations. This means that if a spill got "fixed", there may be either or both of
        the following:
        
        - Dead loads from the stack.
        - Dead stores to the stack.
        
        We know that a load from the stack is dead if the register is dead at the point of the
        load. We know that a store to the stack is dead if the spill slot is dead at the point
        of the store.
        
        Unfortunately, liveness analysis - over either registers or spill slots - is expensive.
        
        Fortunately, allocateStack() already does liveness analysis over spill slots. So, we
        baked elimination of stores to the stack into that phase. That aspect of clean-up after
        the spill CSE comes for free.
        
        Also fortunately for the FTL, we have to do reportUsedRegisters() anyway. This is a
        phase that enables StackmapGenerationParams::usedRegisters() to work, which then
        enables the FTL's patchpoints to do crazy slow-path live range splitting. So, Air's
        strategy for the load fix-up after spill CSE is to do it as part of
        reportUsedRegisters().
        
        This patch introduces the Procedure::setNeedsUsedRegisters() API. But if you set
        needsUsedRegisters to false then we will still run reportUsedRegisters() at -O2 as an
        optimization - it removes dead loads from the stack that are left behind from
        fixObviousSpills().
        
        This is a ~6% compile time progression at -O1.

        * b3/B3Procedure.h:
        (JSC::B3::Procedure::setNeedsUsedRegisters):
        (JSC::B3::Procedure::needsUsedRegisters):
        * b3/B3StackmapGenerationParams.h:
        * b3/B3VariableLiveness.cpp:
        (JSC::B3::VariableLiveness::VariableLiveness):
        * b3/air/AirCode.cpp:
        (JSC::B3::Air::Code::needsUsedRegisters):
        * b3/air/AirCode.h:
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::prepareForGeneration):
        * b3/air/AirLiveness.h:
        (JSC::B3::Air::Liveness::Liveness):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::parseAndCompile):

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

        Air liveness should build constraints and solve them rather than repeatedly parsing IR
        https://bugs.webkit.org/show_bug.cgi?id=170421

        Reviewed by Saam Barati.
        
        Inst::forEach<> is expensive. The LivenessAdapter uses forEach with a particularly
        gnarly lambda that has many extra checks. Therefore, a lot of the time spent in
        liveness analysis is just recomputing forEach<> and that lambda to get uses and defs.
        
        This introduces LivenessConstraints<>, which is a liveness constraint system based on
        Adapter. It basically caches the results of doing forEach. It'll give you the uses and
        defs at each instruction boundary.
        
        This is a ~5% compile time progression at optLevel=1. It's also a ~3% compile time
        progression at optLevel=2.
        
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/air/AirLivenessAdapter.h:
        (JSC::B3::Air::LivenessAdapter::LivenessAdapter):
        (JSC::B3::Air::LivenessAdapter::forEachUse):
        (JSC::B3::Air::LivenessAdapter::forEachDef):
        * b3/air/AirLivenessConstraints.h: Added.
        (JSC::B3::Air::LivenessConstraints::Actions::Actions):
        (JSC::B3::Air::LivenessConstraints::LivenessConstraints):
        (JSC::B3::Air::LivenessConstraints::at):

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

        Fix incorrect capacity delta calculation reported in SparseArrayValueMap::add().
        https://bugs.webkit.org/show_bug.cgi?id=170412
        <rdar://problem/29697336>

        Reviewed by Filip Pizlo.

        Here's an example of code that will trigger underflow in the "deprecatedExtraMemory"
        reported by SparseArrayValueMap::add() that is added to Heap::m_deprecatedExtraMemorySize:
        
            arr = new Array;
            Object.defineProperty(arr, 18, ({writable: true, configurable: true}));
            for (var i = 0; i < 3; ++i) {
                Array.prototype.push.apply(arr, ["", () => {}, {}]);
                Array.prototype.sort.apply(arr, [() => {}, []]);
            }

        However, Heap::m_deprecatedExtraMemorySize is only 1 of 3 values that are added
        up to form the result of Heap::extraMemorySize().  Heap::m_extraMemorySize and
        Heap::m_arrayBuffers.size() are the other 2.

        While Heap::m_arrayBuffers.size() is bounded by actual allocated memory, both
        Heap::m_deprecatedExtraMemorySize and Heap::m_extraMemorySize are added to
        without any bounds checks, and they are only reset to 0 at the start of a full
        GC.  As a result, if we have a long sequence of eden GCs with a lot of additions
        to Heap::m_extraMemorySize and/or Heap::m_deprecatedExtraMemorySize, then these
        values could theoretically overflow.  Coupling this with the underflow from
        SparseArrayValueMap::add(), the result for Heap::extraMemorySize() can easily
        overflow.  Note: Heap::extraMemorySize() is used to compute the value
        currentHeapSize.

        If multiple conditions line up just right, the above overflows can result in this
        debug assertion failure during an eden GC:

            ASSERT(currentHeapSize >= m_sizeAfterLastCollect);

        Otherwise, the effects of the overflows will only result in the computed
        currentHeapSize not being representative of actual memory usage, and therefore,
        a full GC may be triggered earlier or later than is ideal.

        This patch ensures that SparseArrayValueMap::add() cannot underflow
        Heap::m_deprecatedExtraMemorySize.  It also adds overflows checks in the
        calculations of Heap::m_deprecatedExtraMemorySize, Heap::m_extraMemorySize, and
        Heap::extraMemorySize() so that their values are saturated appropriately to
        ensure that GC collections are triggered based on representative memory usage.

        * heap/Heap.cpp:
        (JSC::Heap::deprecatedReportExtraMemorySlowCase):
        (JSC::Heap::extraMemorySize):
        (JSC::Heap::updateAllocationLimits):
        (JSC::Heap::reportExtraMemoryVisited):
        * runtime/SparseArrayValueMap.cpp:
        (JSC::SparseArrayValueMap::add):

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

        Move the Liveness<> adapters from AirLiveness.h to AirLivenessAdapter.h.

        Rubber stamped by Keith Miller.
        
        This will make it easier to write other code that uses those adapters.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/air/AirLiveness.h:
        (JSC::B3::Air::LivenessAdapter::LivenessAdapter): Deleted.
        (JSC::B3::Air::LivenessAdapter::blockSize): Deleted.
        (JSC::B3::Air::LivenessAdapter::forEachUse): Deleted.
        (JSC::B3::Air::LivenessAdapter::forEachDef): Deleted.
        (JSC::B3::Air::TmpLivenessAdapter::TmpLivenessAdapter): Deleted.
        (JSC::B3::Air::TmpLivenessAdapter::numIndices): Deleted.
        (JSC::B3::Air::TmpLivenessAdapter::acceptsBank): Deleted.
        (JSC::B3::Air::TmpLivenessAdapter::acceptsRole): Deleted.
        (JSC::B3::Air::TmpLivenessAdapter::valueToIndex): Deleted.
        (JSC::B3::Air::TmpLivenessAdapter::indexToValue): Deleted.
        (JSC::B3::Air::StackSlotLivenessAdapter::StackSlotLivenessAdapter): Deleted.
        (JSC::B3::Air::StackSlotLivenessAdapter::numIndices): Deleted.
        (JSC::B3::Air::StackSlotLivenessAdapter::acceptsBank): Deleted.
        (JSC::B3::Air::StackSlotLivenessAdapter::acceptsRole): Deleted.
        (JSC::B3::Air::StackSlotLivenessAdapter::valueToIndex): Deleted.
        (JSC::B3::Air::StackSlotLivenessAdapter::indexToValue): Deleted.
        * b3/air/AirLivenessAdapter.h: Added.
        (JSC::B3::Air::LivenessAdapter::LivenessAdapter):
        (JSC::B3::Air::LivenessAdapter::blockSize):
        (JSC::B3::Air::LivenessAdapter::forEachUse):
        (JSC::B3::Air::LivenessAdapter::forEachDef):
        (JSC::B3::Air::TmpLivenessAdapter::TmpLivenessAdapter):
        (JSC::B3::Air::TmpLivenessAdapter::numIndices):
        (JSC::B3::Air::TmpLivenessAdapter::acceptsBank):
        (JSC::B3::Air::TmpLivenessAdapter::acceptsRole):
        (JSC::B3::Air::TmpLivenessAdapter::valueToIndex):
        (JSC::B3::Air::TmpLivenessAdapter::indexToValue):
        (JSC::B3::Air::StackSlotLivenessAdapter::StackSlotLivenessAdapter):
        (JSC::B3::Air::StackSlotLivenessAdapter::numIndices):
        (JSC::B3::Air::StackSlotLivenessAdapter::acceptsBank):
        (JSC::B3::Air::StackSlotLivenessAdapter::acceptsRole):
        (JSC::B3::Air::StackSlotLivenessAdapter::valueToIndex):
        (JSC::B3::Air::StackSlotLivenessAdapter::indexToValue):

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

        WTF::Liveness should have an API that focuses on actions at instruction boundaries
        https://bugs.webkit.org/show_bug.cgi?id=170407

        Reviewed by Keith Miller.
        
        Adopt changes to the WTF::Liveness<> API. Instead of having separate functions for the
        early/late versions of uses and defs, we now have just a use/def API. Those
        automatically take care of eary/late issues as needed.
        
        This reduces the API surface between WTF::Liveness<> and its clients, which makes it
        easier to implement some other optimizations I'm thinking about.

        * b3/B3VariableLiveness.h:
        (JSC::B3::VariableLivenessAdapter::forEachUse):
        (JSC::B3::VariableLivenessAdapter::forEachDef):
        (JSC::B3::VariableLivenessAdapter::forEachEarlyUse): Deleted.
        (JSC::B3::VariableLivenessAdapter::forEachLateUse): Deleted.
        (JSC::B3::VariableLivenessAdapter::forEachEarlyDef): Deleted.
        (JSC::B3::VariableLivenessAdapter::forEachLateDef): Deleted.
        * b3/air/AirLiveness.h:
        (JSC::B3::Air::LivenessAdapter::blockSize):
        (JSC::B3::Air::LivenessAdapter::forEachUse):
        (JSC::B3::Air::LivenessAdapter::forEachDef):
        (JSC::B3::Air::LivenessAdapter::forEachEarlyUse): Deleted.
        (JSC::B3::Air::LivenessAdapter::forEachLateUse): Deleted.
        (JSC::B3::Air::LivenessAdapter::forEachEarlyDef): Deleted.
        (JSC::B3::Air::LivenessAdapter::forEachLateDef): Deleted.

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

        Inst::forEachArg could compile to more compact code
        https://bugs.webkit.org/show_bug.cgi?id=170406

        Reviewed by Sam Weinig.
        
        Prior to this change, Inst::forEachArg compiled to a ginormous ALWAYS_INLINE switch statement.
        It had one case for each opcode, and then each of those cases would have a switch statement over
        the number of operands. Then the cases of that switch statement would have a sequence of calls to
        the passed lambda. This meant that every user of forEachArg would generate an insane amount of
        code. It also meant that the inlining achieved nothing, since the lambda would surely then not
        be inlined - and if it was, then the icache pressure due to code bloat would surely negate any
        benefits.
        
        This replaces that code with a loop over a compact look-up table. We use the opcode and number of
        operands as keys into that look-up table. The table only takes about 20KB. It has one byte for
        each argument in each overload of each opcode.
        
        I can't measure any reproducible change in performance, but the JavaScriptCore framework binary
        shrinks by 2.7 MB. This is a 15% reduction in JavaScriptCore binary size.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3Width.h:
        * b3/air/AirCustom.h:
        (JSC::B3::Air::PatchCustom::forEachArg):
        * b3/air/AirFormTable.h: Added.
        (JSC::B3::Air::decodeFormRole):
        (JSC::B3::Air::decodeFormBank):
        (JSC::B3::Air::decodeFormWidth):
        * b3/air/AirInst.h:
        * b3/air/opcode_generator.rb:

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

        WebAssembly: remove lastAllocatedMode from Memory
        https://bugs.webkit.org/show_bug.cgi?id=170405

        Reviewed by Mark Lam.

        It's not used anymore so there isn't any point in keeping it around.

        * wasm/WasmMemory.cpp:
        (JSC::Wasm::Memory::createImpl):
        (JSC::Wasm::Memory::lastAllocatedMode): Deleted.
        * wasm/WasmMemory.h:

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

        [jsc] Add patchableJumpSize() for MIPS
        https://bugs.webkit.org/show_bug.cgi?id=169716

        Reviewed by Yusuke Suzuki.

        * assembler/MIPSAssembler.h:
        (JSC::MIPSAssembler::patchableJumpSize): Added.
        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::patchableJumpSize): Added.

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

        [jsc] implement MIPSAssembler::relinkJumpToNop()
        https://bugs.webkit.org/show_bug.cgi?id=169720

        Reviewed by Yusuke Suzuki.

        * assembler/MIPSAssembler.h:
        (JSC::MIPSAssembler::relinkJumpToNop): Added.

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

        Share implementation of JSRunLoopTimer::timerDidFire
        https://bugs.webkit.org/show_bug.cgi?id=170392

        Reviewed by Michael Catanzaro.

        The code is cross-platform but it's duplicated in CF and GLib implementations, it could be shared instead.

        * runtime/JSRunLoopTimer.cpp:
        (JSC::JSRunLoopTimer::timerDidFire): Move common implementation here.
        (JSC::JSRunLoopTimer::setRunLoop): Use timerDidFireCallback.
        (JSC::JSRunLoopTimer::timerDidFireCallback): Call JSRunLoopTimer::timerDidFire().
        * runtime/JSRunLoopTimer.h:

2017-04-01  Oleksandr Skachkov  <gskachkov@gmail.com>

        Object with numerical keys with gaps gets filled by NaN values
        https://bugs.webkit.org/show_bug.cgi?id=164412

        Reviewed by Mark Lam.

        This patch fixes issue when object have two properties 
        with name as number. The issue appears when during invoking 
        convertDoubleToArrayStorage, array is filled by pNaN and 
        method converting it to real NaN. This happeneds because a 
        pNaN in a Double array is a hole, and Double arrays cannot 
        have NaN values. To fix issue we need to check value and 
        clear it if it pNaN.

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

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

        WebAssembly: Make our calls out to JS PIC friendly
        https://bugs.webkit.org/show_bug.cgi?id=170261

        Reviewed by Keith Miller.

        This patch removes a direct call from the module to the Wasm to JS stub.
        Instead, we do an indirect call to the stub by loading the stub's executable
        address off of the CodeBlock. This is to make the code we emit for comply with
        requirements needed for PIC.
        
        Adding this indirection is not ideal. Although this patch is neutral on
        WasmBench, we really want to get back to a world where we have an IC
        call infrastructure. This patch is obviously a regression on some
        types of programs. I've filed this bug to make sure we implement a
        PIC compliant Wasm to JS call IC:
        https://bugs.webkit.org/show_bug.cgi?id=170375

        * wasm/WasmB3IRGenerator.cpp:
        * wasm/WasmFormat.h:
        * wasm/WasmPlan.cpp:
        (JSC::Wasm::Plan::complete):
        * wasm/js/JSWebAssemblyCodeBlock.cpp:
        (JSC::JSWebAssemblyCodeBlock::initialize):
        * wasm/js/JSWebAssemblyCodeBlock.h:
        (JSC::JSWebAssemblyCodeBlock::create):
        (JSC::JSWebAssemblyCodeBlock::offsetOfImportWasmToJSStub):
        (JSC::JSWebAssemblyCodeBlock::offsetOfCallees):
        (JSC::JSWebAssemblyCodeBlock::allocationSize):
        (JSC::JSWebAssemblyCodeBlock::importWasmToJSStub):
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::addUnitializedCodeBlock):
        * wasm/js/JSWebAssemblyInstance.h:
        (JSC::JSWebAssemblyInstance::offsetOfCodeBlock):

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

        WebAssembly: webAssemblyB3OptimizationLevel should use defaultB3OptLevel by default
        https://bugs.webkit.org/show_bug.cgi?id=170378

        Reviewed by Saam Barati.

        * runtime/Options.h:
        * wasm/WasmB3IRGenerator.h:

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

        WebAssembly: Add compilation level option
        https://bugs.webkit.org/show_bug.cgi?id=170374

        Reviewed by Mark Lam.

        This patch adds an option, webAssemblyB3OptimizationLevel, which
        changes the optimization mode wasm passes to B3.

        * runtime/Options.h:
        * wasm/WasmPlan.cpp:
        (JSC::Wasm::Plan::compileFunctions):

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

        WebAssembly: Strip WasmParser and WasmFunctionParser from knowing about VM
        https://bugs.webkit.org/show_bug.cgi?id=170312

        Reviewed by Mark Lam.

        This is another step towards PIC-ifying Wasm. This patch removes
        the VM field that is no longer used.

        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::parseAndCompile):
        * wasm/WasmB3IRGenerator.h:
        * wasm/WasmFunctionParser.h:
        (JSC::Wasm::FunctionParser<Context>::FunctionParser):
        * 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::compileFunctions):
        * wasm/WasmValidate.cpp:
        (JSC::Wasm::validateFunction):
        * wasm/WasmValidate.h:

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

        WebAssembly: Ref count Signature and SignatureInformation should not care about VM
        https://bugs.webkit.org/show_bug.cgi?id=170316

        Reviewed by Keith Miller.

        This is yet again another step towards PIC-ifying Wasm.
        Signature should be ref counted so we can tell when
        no code is holding onto a Signature. This makes it easy
        to free unused Signatures. Also, this patch rids SignatureInfo
        of any VM knowledge. Now, there is just a single SignatureInfo that
        lives in a process.

        * runtime/VM.h:
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::createJSToWasmWrapper):
        (JSC::Wasm::parseAndCompile):
        * wasm/WasmB3IRGenerator.h:
        * wasm/WasmBinding.cpp:
        (JSC::Wasm::wasmToJs):
        * wasm/WasmCallingConvention.h:
        (JSC::Wasm::CallingConvention::loadArguments):
        * wasm/WasmFormat.h:
        * wasm/WasmFunctionParser.h:
        (JSC::Wasm::FunctionParser<Context>::FunctionParser):
        * wasm/WasmModuleParser.cpp:
        * wasm/WasmPlan.cpp:
        (JSC::Wasm::Plan::parseAndValidateModule):
        (JSC::Wasm::Plan::compileFunctions):
        (JSC::Wasm::Plan::complete):
        * wasm/WasmSignature.cpp:
        (JSC::Wasm::Signature::hash):
        (JSC::Wasm::Signature::tryCreate):
        (JSC::Wasm::SignatureInformation::SignatureInformation):
        (JSC::Wasm::SignatureInformation::singleton):
        (JSC::Wasm::SignatureInformation::adopt):
        (JSC::Wasm::SignatureInformation::get):
        (JSC::Wasm::SignatureInformation::tryCleanup):
        (JSC::Wasm::Signature::create): Deleted.
        (JSC::Wasm::Signature::createInvalid): Deleted.
        (JSC::Wasm::Signature::destroy): Deleted.
        (JSC::Wasm::SignatureInformation::~SignatureInformation): Deleted.
        * wasm/WasmSignature.h:
        (JSC::Wasm::Signature::allocatedSize):
        (JSC::Wasm::Signature::operator==):
        * wasm/WasmValidate.cpp:
        (JSC::Wasm::validateFunction):
        * wasm/WasmValidate.h:
        * wasm/js/JSWebAssemblyModule.cpp:
        (JSC::JSWebAssemblyModule::destroy):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction):
        * wasm/js/WebAssemblyFunction.h:
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::link):
        (JSC::WebAssemblyModuleRecord::evaluate):
        * wasm/js/WebAssemblyWrapperFunction.cpp:
        (JSC::WebAssemblyWrapperFunction::create):
        * wasm/js/WebAssemblyWrapperFunction.h:

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

        Array.prototype.splice() should not be using JSArray::tryCreateForInitializationPrivate().
        https://bugs.webkit.org/show_bug.cgi?id=170303
        <rdar://problem/31358281>

        Reviewed by Filip Pizlo.

        This is because it needs to call getProperty() later to get the values for
        initializing the array.  getProperty() can execute arbitrary code and potentially
        trigger the GC.  This is not allowed for clients of JSArray::tryCreateForInitializationPrivate().

        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncSplice):
        (JSC::copySplicedArrayElements): Deleted.

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

        String.prototype.replace incorrectly applies "special replacement parameters" when passed a function
        https://bugs.webkit.org/show_bug.cgi?id=170151

        Reviewed by Saam Barati.

        This patch fixes issue for String.prototype.replace when passed a function 
        with special symbols "$$". It happeneds because substituteBackreferences applies 
        unconditionally, but according to the spec it should be applied only for text 
        21.1.3.16.8 https://tc39.github.io/ecma262/#sec-string.prototype.replace

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

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

        WebAssembly: When Wasm calls to C, it should use Wasm::Context* instead of ExecState* to get VM
        https://bugs.webkit.org/show_bug.cgi?id=170185

        Reviewed by Michael Saboff.

        This is one more step in the direction of PIC-ified Wasm.
        When we lift WasmCallee above VM, we will no longer be
        able to get VM from ExecState*. This patch ensures that
        we don't do that from within the Wasm runtime. Instead,
        we use the Wasm::Context* to get the VM.

        This patch also adds a new class, Wasm::Thunks. There
        is a single Wasm::Thunks that lives in the process. It
        is responsible for generating a thunk that Wasm relies on.
        The only such thunk right now is the exception throwing
        thunk.

        This patch also rids WasmFaultSignalHandler from any knowledge
        of VM. Previously, it relied on VM to get the exception handling
        thunk.

        The only part of the Wasm runtime that will be allowed
        to get VM& from ExecState will be WasmBinding. In the
        future, we plan to keep the calls out to JS to keep
        a JSCell as the callee.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        * interpreter/Interpreter.cpp:
        (JSC::UnwindFunctor::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
        (JSC::AssemblyHelpers::copyCalleeSavesToVMEntryFrameCalleeSavesBufferImpl):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
        * jit/ThunkGenerators.cpp:
        (JSC::throwExceptionFromWasmThunkGenerator): Deleted.
        * jit/ThunkGenerators.h:
        * runtime/InitializeThreading.cpp:
        (JSC::initializeThreading):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::getAllCalleeSaveRegisterOffsets):
        * runtime/VM.h:
        (JSC::VM::topVMEntryFrameOffset):
        (JSC::VM::getAllCalleeSaveRegisterOffsets): Deleted.
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::emitExceptionCheck):
        * wasm/WasmFaultSignalHandler.cpp:
        (JSC::Wasm::trapHandler):
        * wasm/WasmMemory.cpp:
        (JSC::Wasm::tryGetFastMemory):
        * wasm/WasmThunks.cpp: Added.
        (JSC::Wasm::throwExceptionFromWasmThunkGenerator):
        (JSC::Wasm::Thunks::initialize):
        (JSC::Wasm::Thunks::singleton):
        (JSC::Wasm::Thunks::stub):
        (JSC::Wasm::Thunks::existingStub):
        * wasm/WasmThunks.h: Added.
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
        * wasm/js/JSWebAssemblyInstance.h:
        (JSC::JSWebAssemblyInstance::offsetOfVM):
        * wasm/js/JSWebAssemblyMemory.cpp:
        (JSC::JSWebAssemblyMemory::grow):
        * wasm/js/JSWebAssemblyMemory.h:
        * wasm/js/WebAssemblyMemoryPrototype.cpp:
        (JSC::webAssemblyMemoryProtoFuncGrow):

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

        IntlObject should not be using JSArray::initializeIndex().
        https://bugs.webkit.org/show_bug.cgi?id=170302
        <rdar://problem/31356918>

        Reviewed by Saam Barati.

        JSArray::initializeIndex() is only meant to be used with arrays created using
        JSArray::tryCreateForInitializationPrivate() under very constrained conditions.

        * runtime/IntlObject.cpp:
        (JSC::canonicalizeLocaleList):
        (JSC::intlObjectFuncGetCanonicalLocales):

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

        Air should support linear scan for optLevel<2
        https://bugs.webkit.org/show_bug.cgi?id=170161

        Reviewed by Saam Barati.
        
        This changes the default opt level of B3 to 2. It makes the other opt levels useful by adding a
        new register allocator. This new linear scan allocator will produce significantly worse code.
        But it will produce that code a lot faster than IRC or Briggs.
        
        The opt levels are:
            0: no optimizations, linear scan
            1: some optimizations, linear scan
            2: full optimizations, graph coloring (IRC or Briggs based on CPU)
        
        What we used to call optLevel=1 is not called optLevel=2, or better yet,
        optLevel=B3::defaultOptLevel(). We no longer have anything like the old optLevel=0 (which did no
        optimizations but ran graph coloring).
        
        allocateRegistersByLinearScan() faithfully implements Massimiliano Poletto and Vivek Sarkar's
        famous algorithm. It uses the variant that handles clobbered registers by avoiding assigning
        ranges to those registers if the range overlaps a clobber. It's engineered to allocate registers
        very quickly and generate inefficient code without falling off a cliff.
        
        The new optLevel=1 speeds up B3 by a factor of 2, and results in a 80% throughput regression.
        Linear scan runs 4.7x faster than graph coloring on average.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3BasicBlockUtils.h:
        (JSC::B3::blocksInPreOrder):
        (JSC::B3::blocksInPostOrder):
        * b3/B3BlockWorklist.h:
        * b3/B3CFG.h:
        (JSC::B3::CFG::newMap):
        * b3/B3Common.h:
        (JSC::B3::defaultOptLevel):
        * b3/B3Compile.h:
        * b3/B3DuplicateTails.cpp:
        * b3/B3EliminateCommonSubexpressions.cpp:
        * b3/B3FixSSA.cpp:
        (JSC::B3::demoteValues):
        (JSC::B3::fixSSA):
        * b3/B3FixSSA.h:
        * b3/B3Generate.cpp:
        (JSC::B3::prepareForGeneration):
        (JSC::B3::generateToAir):
        * b3/B3Generate.h:
        * b3/B3HeapRange.cpp: Removed.
        * b3/B3HeapRange.h:
        (JSC::B3::HeapRange::HeapRange): Deleted.
        (JSC::B3::HeapRange::top): Deleted.
        (JSC::B3::HeapRange::operator==): Deleted.
        (JSC::B3::HeapRange::operator!=): Deleted.
        (JSC::B3::HeapRange::operator|): Deleted.
        (JSC::B3::HeapRange::operator bool): Deleted.
        (JSC::B3::HeapRange::begin): Deleted.
        (JSC::B3::HeapRange::end): Deleted.
        (JSC::B3::HeapRange::overlaps): Deleted.
        * b3/B3LowerToAir.cpp:
        * b3/B3MoveConstants.cpp:
        * b3/B3PhiChildren.h:
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::dump):
        (JSC::B3::Procedure::deleteOrphans):
        (JSC::B3::Procedure::setBlockOrderImpl):
        * b3/B3ReduceDoubleToFloat.cpp:
        * b3/B3ReduceStrength.cpp:
        * b3/B3SSACalculator.h:
        * b3/B3UseCounts.h:
        * b3/air/AirAllocateRegistersByGraphColoring.cpp:
        * b3/air/AirAllocateRegistersByLinearScan.cpp: Added.
        (JSC::B3::Air::allocateRegistersByLinearScan):
        * b3/air/AirAllocateRegistersByLinearScan.h: Added.
        * b3/air/AirAllocateStack.cpp:
        (JSC::B3::Air::allocateStack):
        * b3/air/AirArg.cpp:
        (WTF::printInternal):
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::activeAt):
        (JSC::B3::Air::Arg::timing):
        (JSC::B3::Air::Arg::forEachPhase):
        * b3/air/AirBasicBlock.h:
        * b3/air/AirBlockWorklist.h:
        * b3/air/AirCFG.h:
        (JSC::B3::Air::CFG::newMap):
        * b3/air/AirEliminateDeadCode.cpp:
        (JSC::B3::Air::eliminateDeadCode):
        * b3/air/AirFixObviousSpills.cpp:
        * b3/air/AirFixPartialRegisterStalls.cpp:
        (JSC::B3::Air::fixPartialRegisterStalls):
        * b3/air/AirFixSpillsAfterTerminals.cpp: Added.
        (JSC::B3::Air::fixSpillsAfterTerminals):
        * b3/air/AirFixSpillsAfterTerminals.h: Added.
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::prepareForGeneration):
        (JSC::B3::Air::generate):
        * b3/air/AirGenerate.h:
        * b3/air/AirGenerationContext.h:
        * b3/air/AirInsertionSet.h:
        * b3/air/AirInst.cpp:
        (JSC::B3::Air::Inst::needsPadding):
        * b3/air/AirLowerAfterRegAlloc.cpp:
        (JSC::B3::Air::lowerAfterRegAlloc):
        * b3/air/AirLowerEntrySwitch.cpp:
        (JSC::B3::Air::lowerEntrySwitch):
        * b3/air/AirOpcode.opcodes:
        * b3/air/AirPhaseInsertionSet.cpp: Added.
        (JSC::B3::Air::PhaseInsertionSet::execute):
        * b3/air/AirPhaseInsertionSet.h: Added.
        (JSC::B3::Air::PhaseInsertion::PhaseInsertion):
        (JSC::B3::Air::PhaseInsertion::phase):
        (JSC::B3::Air::PhaseInsertion::operator<):
        (JSC::B3::Air::PhaseInsertionSet::PhaseInsertionSet):
        (JSC::B3::Air::PhaseInsertionSet::appendInsertion):
        (JSC::B3::Air::PhaseInsertionSet::insertInst):
        (JSC::B3::Air::PhaseInsertionSet::insert):
        * b3/air/AirRegLiveness.h:
        (JSC::B3::Air::RegLiveness::LocalCalc::LocalCalc):
        * b3/air/AirSpillEverything.cpp:
        (JSC::B3::Air::spillEverything):
        * b3/air/AirTmp.cpp:
        * b3/air/AirTmp.h:
        (JSC::B3::Air::Tmp::tmpForIndex):
        * b3/air/AirTmpInlines.h:
        (JSC::B3::Air::Tmp::Indexed::Indexed):
        (JSC::B3::Air::Tmp::Indexed::index):
        (JSC::B3::Air::Tmp::AbsolutelyIndexed::AbsolutelyIndexed):
        (JSC::B3::Air::Tmp::AbsolutelyIndexed::index):
        (JSC::B3::Air::Tmp::indexed):
        (JSC::B3::Air::Tmp::absolutelyIndexed):
        (JSC::B3::Air::Tmp::tmpForAbsoluteIndex):
        * b3/testb3.cpp:
        (JSC::B3::compile):
        (JSC::B3::testMulLoadTwice):
        * jit/RegisterSet.h:
        (JSC::RegisterSet::add):
        (JSC::RegisterSet::remove):
        * runtime/Options.h:
        * wasm/WasmB3IRGenerator.h:

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

        Clean up RTCDataChannel
        https://bugs.webkit.org/show_bug.cgi?id=169732

        Reviewed by Chris Dumez.

        * runtime/CommonIdentifiers.h: Adding RTCDataChannelEvent.

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

        WebAssembly: pass Wasm::Context* to vmEntryToWasm when not using fast TLS
        https://bugs.webkit.org/show_bug.cgi?id=170182

        Reviewed by Mark Lam.

        This is one more step in the direction of PIC-ified Wasm.
        I'm removing assumptions that a wasm callee is a cell. We used to use
        the callee to get the WasmContext off the callee's VM. Instead,
        this patch makes it so that we pass in the context as a parameter
        to the JS entrypoint.

        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::offsetOfVM): Deleted.
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::loadWasmContext):
        (JSC::AssemblyHelpers::storeWasmContext):
        (JSC::AssemblyHelpers::loadWasmContextNeedsMacroScratchRegister):
        (JSC::AssemblyHelpers::storeWasmContextNeedsMacroScratchRegister):
        * jsc.cpp:
        (functionTestWasmModuleFunctions):
        * runtime/VM.h:
        (JSC::VM::wasmContextOffset): Deleted.
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::materializeWasmContext):
        (JSC::Wasm::B3IRGenerator::restoreWasmContext):
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        (JSC::Wasm::createJSToWasmWrapper):
        * wasm/WasmContext.cpp:
        (JSC::Wasm::loadContext):
        (JSC::Wasm::storeContext):
        (JSC::loadWasmContext): Deleted.
        (JSC::storeWasmContext): Deleted.
        * wasm/WasmContext.h:
        (JSC::Wasm::useFastTLS):
        (JSC::Wasm::useFastTLSForContext):
        * wasm/WasmMemoryInformation.cpp:
        (JSC::Wasm::PinnedRegisterInfo::get):
        * wasm/WasmMemoryInformation.h:
        (JSC::Wasm::useFastTLS): Deleted.
        (JSC::Wasm::useFastTLSForWasmContext): Deleted.
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction):

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

        WebAssembly: fix misc JS API implementation inconsistencies
        https://bugs.webkit.org/show_bug.cgi?id=170187

        Reviewed by Keith Miller.

        Auto-generate lookup tables.
        Methods should be on prototype.
        Exception returns should be idiomatic.

        * wasm/JSWebAssembly.cpp: validate / compile / instantiate should
        be on the prototype
        (JSC::JSWebAssembly::create):
        (JSC::JSWebAssembly::finishCreation):
        (JSC::reject): Deleted.
        (JSC::webAssemblyCompileFunc): Deleted.
        (JSC::resolve): Deleted.
        (JSC::instantiate): Deleted.
        (JSC::compileAndInstantiate): Deleted.
        (JSC::webAssemblyInstantiateFunc): Deleted.
        (JSC::webAssemblyValidateFunc): Deleted.
        * wasm/JSWebAssembly.h:
        * wasm/js/WebAssemblyMemoryPrototype.cpp: move from JSWebAssembly.cpp
        (JSC::webAssemblyMemoryProtoFuncBuffer):
        (JSC::WebAssemblyMemoryPrototype::create):
        (JSC::WebAssemblyMemoryPrototype::finishCreation):
        * wasm/js/WebAssemblyMemoryPrototype.h:
        * wasm/js/WebAssemblyPrototype.cpp:
        (JSC::reject):
        (JSC::webAssemblyCompileFunc):
        (JSC::resolve):
        (JSC::instantiate):
        (JSC::compileAndInstantiate):
        (JSC::webAssemblyInstantiateFunc):
        (JSC::webAssemblyValidateFunc):
        (JSC::webAssemblyFunctionValidate): Deleted.
        (JSC::webAssemblyFunctionCompile): Deleted.
        * wasm/js/WebAssemblyTablePrototype.cpp:
        (JSC::webAssemblyTableProtoFuncGrow):
        (JSC::webAssemblyTableProtoFuncGet):
        (JSC::webAssemblyTableProtoFuncSet):
        (JSC::WebAssemblyTablePrototype::create):
        (JSC::WebAssemblyTablePrototype::finishCreation):
        * wasm/js/WebAssemblyTablePrototype.h:

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

        Unreviewed, fix the build, again. Hopefully for the last time, again!

        * runtime/Options.cpp:

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

        Unreviewed, fix the build, again. Hopefully for the last time!

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

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

        Unreviewed, windows build fix.

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

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

        WebAssembly: B3IRGenerator should pool constants
        https://bugs.webkit.org/show_bug.cgi?id=170266

        Reviewed by Filip Pizlo.

        This patch adds a HashMap to B3IRGenerator that contains all the constants used in a function.
        B3IRGenerator then uses an InsertionSet to add all those constants to the root BB. This doesn't
        appear to be a compile time improvement but it could be valuable in the future.

        * b3/B3Opcode.h:
        (JSC::B3::opcodeForConstant):
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::addConstant):
        * b3/B3Procedure.h:
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        (JSC::Wasm::B3IRGenerator::constant):
        (JSC::Wasm::B3IRGenerator::insertConstants):
        (JSC::Wasm::B3IRGenerator::addConstant):
        (JSC::Wasm::B3IRGenerator::dump):
        (JSC::Wasm::parseAndCompile):
        (JSC::Wasm::B3IRGenerator::emitChecksForModOrDiv):
        (JSC::Wasm::B3IRGenerator::zeroForType): Deleted.
        * wasm/generateWasmB3IRGeneratorInlinesHeader.py:
        (generateConstCode):

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

        LinkBuffer and ExecutableAllocator shouldn't have anything to do with VM
        https://bugs.webkit.org/show_bug.cgi?id=170210

        Reviewed by Mark Lam.

        This is one more step in the direction of PIC-ified Wasm.
        LinkBuffer and ExecutableAllocator have no business knowing about VM.

        * assembler/LinkBuffer.cpp:
        (JSC::LinkBuffer::allocate):
        * assembler/LinkBuffer.h:
        (JSC::LinkBuffer::LinkBuffer):
        (JSC::LinkBuffer::vm): Deleted.
        * b3/B3Compile.cpp:
        (JSC::B3::compile):
        * b3/B3Compile.h:
        * b3/air/testair.cpp:
        * b3/testb3.cpp:
        (JSC::B3::compileProc):
        (JSC::B3::compileAndRun):
        (JSC::B3::testLoadAcq42):
        (JSC::B3::testAddArgZeroImmZDef):
        (JSC::B3::testAddLoadTwice):
        (JSC::B3::testMulLoadTwice):
        (JSC::B3::testMulAddArgsLeft):
        (JSC::B3::testMulAddArgsRight):
        (JSC::B3::testMulAddArgsLeft32):
        (JSC::B3::testMulAddArgsRight32):
        (JSC::B3::testMulSubArgsLeft):
        (JSC::B3::testMulSubArgsRight):
        (JSC::B3::testMulSubArgsLeft32):
        (JSC::B3::testMulSubArgsRight32):
        (JSC::B3::testMulNegArgs):
        (JSC::B3::testMulNegArgs32):
        (JSC::B3::testCompareFloatToDoubleThroughPhi):
        (JSC::B3::testDoubleToFloatThroughPhi):
        (JSC::B3::testReduceFloatToDoubleValidates):
        (JSC::B3::testDoubleProducerPhiToFloatConversion):
        (JSC::B3::testDoubleProducerPhiToFloatConversionWithDoubleConsumer):
        (JSC::B3::testDoubleProducerPhiWithNonFloatConst):
        (JSC::B3::testIToD64Arg):
        (JSC::B3::testIToF64Arg):
        (JSC::B3::testIToD32Arg):
        (JSC::B3::testIToF32Arg):
        (JSC::B3::testIToD64Mem):
        (JSC::B3::testIToF64Mem):
        (JSC::B3::testIToD32Mem):
        (JSC::B3::testIToF32Mem):
        (JSC::B3::testIToDReducedToIToF64Arg):
        (JSC::B3::testIToDReducedToIToF32Arg):
        (JSC::B3::testStoreRelAddLoadAcq32):
        (JSC::B3::testStoreRelAddLoadAcq8):
        (JSC::B3::testStoreRelAddFenceLoadAcq8):
        (JSC::B3::testStoreRelAddLoadAcq16):
        (JSC::B3::testStoreRelAddLoadAcq64):
        (JSC::B3::testBranch):
        (JSC::B3::testBranchPtr):
        (JSC::B3::testDiamond):
        (JSC::B3::testBranchNotEqual):
        (JSC::B3::testBranchNotEqualCommute):
        (JSC::B3::testBranchNotEqualNotEqual):
        (JSC::B3::testBranchEqual):
        (JSC::B3::testBranchEqualEqual):
        (JSC::B3::testBranchEqualCommute):
        (JSC::B3::testBranchEqualEqual1):
        (JSC::B3::testBranchLoadPtr):
        (JSC::B3::testBranchLoad32):
        (JSC::B3::testBranchLoad8S):
        (JSC::B3::testBranchLoad8Z):
        (JSC::B3::testBranchLoad16S):
        (JSC::B3::testBranchLoad16Z):
        (JSC::B3::testBranch8WithLoad8ZIndex):
        (JSC::B3::testComplex):
        (JSC::B3::testSimpleCheck):
        (JSC::B3::testCheckFalse):
        (JSC::B3::testCheckTrue):
        (JSC::B3::testCheckLessThan):
        (JSC::B3::testCheckMegaCombo):
        (JSC::B3::testCheckTrickyMegaCombo):
        (JSC::B3::testCheckTwoMegaCombos):
        (JSC::B3::testCheckTwoNonRedundantMegaCombos):
        (JSC::B3::testCheckAddImm):
        (JSC::B3::testCheckAddImmCommute):
        (JSC::B3::testCheckAddImmSomeRegister):
        (JSC::B3::testCheckAdd):
        (JSC::B3::testCheckAdd64):
        (JSC::B3::testCheckAddFold):
        (JSC::B3::testCheckAddFoldFail):
        (JSC::B3::testCheckAddSelfOverflow64):
        (JSC::B3::testCheckAddSelfOverflow32):
        (JSC::B3::testCheckSubImm):
        (JSC::B3::testCheckSubBadImm):
        (JSC::B3::testCheckSub):
        (JSC::B3::testCheckSub64):
        (JSC::B3::testCheckSubFold):
        (JSC::B3::testCheckSubFoldFail):
        (JSC::B3::testCheckNeg):
        (JSC::B3::testCheckNeg64):
        (JSC::B3::testCheckMul):
        (JSC::B3::testCheckMulMemory):
        (JSC::B3::testCheckMul2):
        (JSC::B3::testCheckMul64):
        (JSC::B3::testCheckMulFold):
        (JSC::B3::testCheckMulFoldFail):
        (JSC::B3::testCheckMul64SShr):
        (JSC::B3::testSwitch):
        (JSC::B3::testSwitchChillDiv):
        (JSC::B3::testSwitchTargettingSameBlock):
        (JSC::B3::testSwitchTargettingSameBlockFoldPathConstant):
        (JSC::B3::testBasicSelect):
        (JSC::B3::testSelectTest):
        (JSC::B3::testSelectCompareDouble):
        (JSC::B3::testSelectDouble):
        (JSC::B3::testSelectDoubleTest):
        (JSC::B3::testSelectDoubleCompareDouble):
        (JSC::B3::testSelectFloatCompareFloat):
        (JSC::B3::testSelectFold):
        (JSC::B3::testSelectInvert):
        (JSC::B3::testCheckSelect):
        (JSC::B3::testCheckSelectCheckSelect):
        (JSC::B3::testCheckSelectAndCSE):
        (JSC::B3::testTrivialInfiniteLoop):
        (JSC::B3::testFoldPathEqual):
        (JSC::B3::testLShiftSelf32):
        (JSC::B3::testRShiftSelf32):
        (JSC::B3::testURShiftSelf32):
        (JSC::B3::testLShiftSelf64):
        (JSC::B3::testRShiftSelf64):
        (JSC::B3::testURShiftSelf64):
        (JSC::B3::testPatchpointDoubleRegs):
        (JSC::B3::testSpillDefSmallerThanUse):
        (JSC::B3::testSpillUseLargerThanDef):
        (JSC::B3::testLateRegister):
        (JSC::B3::testInterpreter):
        (JSC::B3::testEntrySwitchSimple):
        (JSC::B3::testEntrySwitchNoEntrySwitch):
        (JSC::B3::testEntrySwitchWithCommonPaths):
        (JSC::B3::testEntrySwitchWithCommonPathsAndNonTrivialEntrypoint):
        (JSC::B3::testEntrySwitchLoop):
        (JSC::B3::testSomeEarlyRegister):
        (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled):
        (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled2):
        (JSC::B3::testPatchpointTerminalReturnValue):
        (JSC::B3::testMemoryFence):
        (JSC::B3::testStoreFence):
        (JSC::B3::testLoadFence):
        (JSC::B3::testPCOriginMapDoesntInsertNops):
        (JSC::B3::testPinRegisters):
        (JSC::B3::testX86LeaAddAddShlLeft):
        (JSC::B3::testX86LeaAddAddShlRight):
        (JSC::B3::testX86LeaAddAdd):
        (JSC::B3::testX86LeaAddShlRight):
        (JSC::B3::testX86LeaAddShlLeftScale1):
        (JSC::B3::testX86LeaAddShlLeftScale2):
        (JSC::B3::testX86LeaAddShlLeftScale4):
        (JSC::B3::testX86LeaAddShlLeftScale8):
        (JSC::B3::testAddShl32):
        (JSC::B3::testAddShl64):
        (JSC::B3::testAddShl65):
        (JSC::B3::testLoadBaseIndexShift2):
        (JSC::B3::testLoadBaseIndexShift32):
        (JSC::B3::testOptimizeMaterialization):
        (JSC::B3::testAtomicWeakCAS):
        (JSC::B3::testAtomicStrongCAS):
        (JSC::B3::testAtomicXchg):
        (JSC::B3::testDepend32):
        (JSC::B3::testDepend64):
        (JSC::B3::testWasmBoundsCheck):
        (JSC::B3::testWasmAddress):
        (JSC::B3::run):
        (JSC::B3::compile): Deleted.
        * bytecode/PolymorphicAccess.cpp:
        (JSC::PolymorphicAccess::regenerate):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        * dfg/DFGLazyJSValue.cpp:
        (JSC::DFG::LazyJSValue::emit):
        * dfg/DFGOSRExitCompiler.cpp:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * dfg/DFGThunks.cpp:
        (JSC::DFG::osrExitGenerationThunkGenerator):
        (JSC::DFG::osrEntryThunkGenerator):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):
        * ftl/FTLLazySlowPath.cpp:
        (JSC::FTL::LazySlowPath::generate):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct):
        (JSC::FTL::DFG::LowerDFGToB3::compileTailCall):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallEval):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        * ftl/FTLOSRExitHandle.cpp:
        (JSC::FTL::OSRExitHandle::emitExitThunk):
        * ftl/FTLSlowPathCall.cpp:
        (JSC::FTL::SlowPathCallContext::makeCall):
        * ftl/FTLSlowPathCall.h:
        (JSC::FTL::callOperation):
        * ftl/FTLState.h:
        * ftl/FTLThunks.cpp:
        (JSC::FTL::genericGenerationThunkGenerator):
        (JSC::FTL::slowPathCallThunkGenerator):
        * ftl/FTLThunks.h:
        (JSC::FTL::generateIfNecessary):
        (JSC::FTL::Thunks::getSlowPathCallThunk):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::emitDumbVirtualCall):
        * jit/AssemblyHelpers.h:
        * jit/ExecutableAllocator.cpp:
        (JSC::ExecutableAllocator::initializeAllocator):
        (JSC::ExecutableAllocator::singleton):
        (JSC::ExecutableAllocator::ExecutableAllocator):
        (JSC::ExecutableAllocator::allocate):
        * jit/ExecutableAllocator.h:
        * jit/JIT.cpp:
        (JSC::JIT::compileWithoutLinking):
        * jit/JITCall.cpp:
        (JSC::JIT::compileCallEvalSlowCase):
        * jit/JITMathIC.h:
        (JSC::JITMathIC::generateOutOfLine):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::privateCompileHasIndexedProperty):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::privateCompileHasIndexedProperty):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::stringGetByValStubGenerator):
        (JSC::JIT::privateCompileGetByVal):
        (JSC::JIT::privateCompileGetByValWithCachedId):
        (JSC::JIT::privateCompilePutByVal):
        (JSC::JIT::privateCompilePutByValWithCachedId):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::stringGetByValStubGenerator):
        * jit/JITStubRoutine.h:
        * jit/Repatch.cpp:
        (JSC::ftlThunkAwareRepatchCall):
        (JSC::linkPolymorphicCall):
        * jit/SpecializedThunkJIT.h:
        (JSC::SpecializedThunkJIT::finalize):
        * jit/ThunkGenerators.cpp:
        (JSC::throwExceptionFromCallSlowPathGenerator):
        (JSC::linkCallThunkGenerator):
        (JSC::linkPolymorphicCallThunkGenerator):
        (JSC::virtualThunkFor):
        (JSC::nativeForGenerator):
        (JSC::arityFixupGenerator):
        (JSC::unreachableGenerator):
        (JSC::boundThisNoArgsFunctionCallGenerator):
        (JSC::throwExceptionFromWasmThunkGenerator):
        * llint/LLIntThunks.cpp:
        (JSC::LLInt::generateThunkWithJumpTo):
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::takeSample):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        * runtime/VMTraps.cpp:
        (JSC::VMTraps::tryInstallTrapBreakpoints):
        * tools/VMInspector.cpp:
        * wasm/WasmBinding.cpp:
        (JSC::Wasm::wasmToJs):
        (JSC::Wasm::wasmToWasm):
        (JSC::Wasm::exitStubGenerator):
        * wasm/WasmPlan.cpp:
        (JSC::Wasm::Plan::complete):
        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::compile):
        (JSC::Yarr::jitCompile):

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

        WebAssembly: Worklist should periodically check in to see if there are higher priority jobs to do.
        https://bugs.webkit.org/show_bug.cgi?id=170204

        Reviewed by Saam Barati.

        This patch makes it so that Wasm::Plan's compileFunctions method can return periodically
        to its caller. The main use for this is if a user asynchronously compiles a wasm module
        then later synchronously compiles another module. In this case we want to be able to pause
        compilation of other worklists.

        This patch also adds support for size_t Options.

        * runtime/Options.cpp:
        (JSC::parse):
        (JSC::Option::dump):
        (JSC::Option::operator==):
        * runtime/Options.h:
        * wasm/WasmPlan.cpp:
        (JSC::Wasm::Plan::moveToState):
        (JSC::Wasm::Plan::ThreadCountHolder::~ThreadCountHolder):
        (JSC::Wasm::Plan::compileFunctions):
        * wasm/WasmPlan.h:
        * wasm/WasmWorklist.cpp:

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

        Remove obsolete references to HeapTimer in JavaScriptCore.order.
        https://bugs.webkit.org/show_bug.cgi?id=170252

        Reviewed by Saam Barati.

        The HeapTimer was renamed to JSRunLoopTimer back in r214504.  These HeapTimer
        entries are now no longer meaningful.

        * JavaScriptCore.order:

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

        WebAssembly: add shell-only Memory mode helper
        https://bugs.webkit.org/show_bug.cgi?id=170227

        Reviewed by Mark Lam.

        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionWebAssemblyMemoryMode):
        * wasm/WasmMemory.h:
        * wasm/js/JSWebAssemblyInstance.h:
        * wasm/js/JSWebAssemblyMemory.h:

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

        WebAssembly: pack OpcodeOrigin to fit in a pointer
        https://bugs.webkit.org/show_bug.cgi?id=170244

        Reviewed by Michael Saboff.

        This patch makes it so we don't have to have allocate the OpcodeOrigin and can just
        pack all the data into the pointer B3::Origin already has.

        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::parseAndCompile):
        * wasm/WasmOpcodeOrigin.cpp:
        (JSC::Wasm::OpcodeOrigin::dump):
        * wasm/WasmOpcodeOrigin.h:
        (JSC::Wasm::OpcodeOrigin::OpcodeOrigin):
        (JSC::Wasm::OpcodeOrigin::opcode):
        (JSC::Wasm::OpcodeOrigin::location):

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

        WebAssembly: NFC s/goto/lambda/g
        https://bugs.webkit.org/show_bug.cgi?id=170242

        Reviewed by Mark Lam.

        Lambdas are more in-style than the goto I just used.

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

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

        AssemblyHelpers should not have a VM field
        https://bugs.webkit.org/show_bug.cgi?id=170207

        Reviewed by Yusuke Suzuki.

        APIs that need VM should take one as a parameter. When doing position
        independent code for Wasm, we can't tie code generation to a VM.

        * b3/B3Compile.cpp:
        (JSC::B3::compile):
        * b3/air/testair.cpp:
        * b3/testb3.cpp:
        (JSC::B3::testEntrySwitchSimple):
        (JSC::B3::testEntrySwitchNoEntrySwitch):
        (JSC::B3::testEntrySwitchWithCommonPaths):
        (JSC::B3::testEntrySwitchWithCommonPathsAndNonTrivialEntrypoint):
        (JSC::B3::testEntrySwitchLoop):
        * bytecode/AccessCase.cpp:
        (JSC::AccessCase::generateWithGuard):
        (JSC::AccessCase::generateImpl):
        * bytecode/DOMJITAccessCasePatchpointParams.cpp:
        (JSC::SlowPathCallGeneratorWithArguments::generateImpl):
        * bytecode/InlineAccess.cpp:
        (JSC::InlineAccess::dumpCacheSizesAndCrash):
        (JSC::InlineAccess::generateSelfPropertyAccess):
        (JSC::InlineAccess::generateSelfPropertyReplace):
        (JSC::InlineAccess::generateArrayLength):
        (JSC::InlineAccess::rewireStubAsJump):
        * bytecode/InlineAccess.h:
        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessGenerationState::emitExplicitExceptionHandler):
        (JSC::PolymorphicAccess::regenerate):
        * bytecode/PolymorphicAccess.h:
        (JSC::AccessGenerationState::AccessGenerationState):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::JITCompiler):
        (JSC::DFG::JITCompiler::compileExceptionHandlers):
        (JSC::DFG::JITCompiler::link):
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        (JSC::DFG::JITCompiler::exceptionCheck):
        * dfg/DFGJITCompiler.h:
        (JSC::DFG::JITCompiler::exceptionCheckWithCallFrameRollback):
        (JSC::DFG::JITCompiler::fastExceptionCheck):
        (JSC::DFG::JITCompiler::vm):
        * dfg/DFGOSRExitCompiler.cpp:
        * dfg/DFGOSRExitCompiler.h:
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::adjustAndJumpToTarget):
        * dfg/DFGOSRExitCompilerCommon.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
        (JSC::DFG::SpeculativeJIT::checkArray):
        (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
        (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
        (JSC::DFG::SpeculativeJIT::compileMakeRope):
        (JSC::DFG::SpeculativeJIT::compileGetGlobalObject):
        (JSC::DFG::SpeculativeJIT::compileNewFunctionCommon):
        (JSC::DFG::SpeculativeJIT::compileCreateActivation):
        (JSC::DFG::SpeculativeJIT::compileCreateDirectArguments):
        (JSC::DFG::SpeculativeJIT::compileSpread):
        (JSC::DFG::SpeculativeJIT::compileArraySlice):
        (JSC::DFG::SpeculativeJIT::compileNukeStructureAndSetButterfly):
        (JSC::DFG::SpeculativeJIT::compileNewStringObject):
        (JSC::DFG::SpeculativeJIT::compileNewTypedArray):
        (JSC::DFG::SpeculativeJIT::compileStoreBarrier):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::emitAllocateJSObjectWithKnownSize):
        (JSC::DFG::SpeculativeJIT::emitAllocateJSObject):
        (JSC::DFG::SpeculativeJIT::emitAllocateVariableSizedJSObject):
        (JSC::DFG::SpeculativeJIT::emitAllocateDestructibleObject):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compileLogicalNot):
        (JSC::DFG::SpeculativeJIT::emitBranch):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNullOrUndefined):
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
        (JSC::DFG::SpeculativeJIT::compileLogicalNot):
        (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
        (JSC::DFG::SpeculativeJIT::emitBranch):
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
        * dfg/DFGThunks.cpp:
        (JSC::DFG::osrEntryThunkGenerator):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):
        * ftl/FTLJITFinalizer.h:
        * ftl/FTLLazySlowPath.cpp:
        (JSC::FTL::LazySlowPath::generate):
        * ftl/FTLLazySlowPathCall.h:
        (JSC::FTL::createLazyCallGenerator):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::lower):
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateActivation):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateDirectArguments):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
        (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
        (JSC::FTL::DFG::LowerDFGToB3::compileNotifyWrite):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallEval):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsObjectOrNull):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsFunction):
        (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
        (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation):
        (JSC::FTL::DFG::LowerDFGToB3::compileCheckTraps):
        (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorageWithSizeImpl):
        (JSC::FTL::DFG::LowerDFGToB3::allocateObject):
        (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
        (JSC::FTL::DFG::LowerDFGToB3::buildTypeOf):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        * ftl/FTLSlowPathCall.h:
        (JSC::FTL::callOperation):
        * ftl/FTLState.h:
        (JSC::FTL::State::vm):
        * ftl/FTLThunks.cpp:
        (JSC::FTL::genericGenerationThunkGenerator):
        (JSC::FTL::slowPathCallThunkGenerator):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::jitReleaseAssertNoException):
        (JSC::AssemblyHelpers::callExceptionFuzz):
        (JSC::AssemblyHelpers::emitJumpIfException):
        (JSC::AssemblyHelpers::emitExceptionCheck):
        (JSC::AssemblyHelpers::emitNonPatchableExceptionCheck):
        (JSC::AssemblyHelpers::emitLoadStructure):
        (JSC::AssemblyHelpers::emitRandomThunk):
        (JSC::AssemblyHelpers::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
        (JSC::AssemblyHelpers::emitConvertValueToBoolean):
        (JSC::AssemblyHelpers::debugCall):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::AssemblyHelpers):
        (JSC::AssemblyHelpers::codeBlock):
        (JSC::AssemblyHelpers::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
        (JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToVMEntryFrameCalleeSavesBuffer):
        (JSC::AssemblyHelpers::barrierBranch):
        (JSC::AssemblyHelpers::barrierStoreLoadFence):
        (JSC::AssemblyHelpers::mutatorFence):
        (JSC::AssemblyHelpers::storeButterfly):
        (JSC::AssemblyHelpers::nukeStructureAndStoreButterfly):
        (JSC::AssemblyHelpers::jumpIfMutatorFenceNotNeeded):
        (JSC::AssemblyHelpers::emitAllocateJSObjectWithKnownSize):
        (JSC::AssemblyHelpers::emitAllocateJSObject):
        (JSC::AssemblyHelpers::emitAllocateVariableSizedCell):
        (JSC::AssemblyHelpers::emitAllocateVariableSizedJSObject):
        (JSC::AssemblyHelpers::emitAllocateDestructibleObject):
        (JSC::AssemblyHelpers::vm): Deleted.
        (JSC::AssemblyHelpers::debugCall): Deleted.
        * jit/CCallHelpers.cpp:
        (JSC::CCallHelpers::ensureShadowChickenPacket):
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::CCallHelpers):
        (JSC::CCallHelpers::jumpToExceptionHandler):
        * jit/JIT.cpp:
        (JSC::JIT::emitEnterOptimizationCheck):
        (JSC::JIT::privateCompileExceptionHandlers):
        * jit/JIT.h:
        (JSC::JIT::exceptionCheck):
        (JSC::JIT::exceptionCheckWithCallFrameRollback):
        * jit/JITMathIC.h:
        (JSC::JITMathIC::generateOutOfLine):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_instanceof):
        (JSC::JIT::emit_op_is_undefined):
        (JSC::JIT::emit_op_jfalse):
        (JSC::JIT::emit_op_jeq_null):
        (JSC::JIT::emit_op_jneq_null):
        (JSC::JIT::emit_op_jtrue):
        (JSC::JIT::emit_op_throw):
        (JSC::JIT::emit_op_catch):
        (JSC::JIT::emit_op_eq_null):
        (JSC::JIT::emit_op_neq_null):
        (JSC::JIT::emitSlow_op_loop_hint):
        (JSC::JIT::emit_op_log_shadow_chicken_prologue):
        (JSC::JIT::emit_op_log_shadow_chicken_tail):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::privateCompileCTINativeCall):
        (JSC::JIT::emit_op_new_object):
        (JSC::JIT::emit_op_jfalse):
        (JSC::JIT::emit_op_jtrue):
        (JSC::JIT::emit_op_throw):
        (JSC::JIT::emit_op_catch):
        (JSC::JIT::emit_op_create_this):
        (JSC::JIT::emit_op_log_shadow_chicken_prologue):
        (JSC::JIT::emit_op_log_shadow_chicken_tail):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitWriteBarrier):
        * jit/JSInterfaceJIT.h:
        (JSC::JSInterfaceJIT::JSInterfaceJIT):
        (JSC::JSInterfaceJIT::vm):
        * jit/Repatch.cpp:
        (JSC::tryCacheGetByID):
        (JSC::tryCachePutByID):
        (JSC::linkPolymorphicCall):
        (JSC::resetGetByID):
        (JSC::resetPutByID):
        * jit/SetupVarargsFrame.cpp:
        (JSC::emitSetupVarargsFrameFastCase):
        * jit/SetupVarargsFrame.h:
        * jit/SpecializedThunkJIT.h:
        (JSC::SpecializedThunkJIT::loadArgumentWithSpecificClass):
        * jit/ThunkGenerators.cpp:
        (JSC::throwExceptionFromCallSlowPathGenerator):
        (JSC::linkCallThunkGenerator):
        (JSC::linkPolymorphicCallThunkGenerator):
        (JSC::virtualThunkFor):
        (JSC::nativeForGenerator):
        (JSC::randomThunkGenerator):
        (JSC::boundThisNoArgsFunctionCallGenerator):
        (JSC::throwExceptionFromWasmThunkGenerator):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::parseAndCompile):
        * wasm/WasmBinding.cpp:
        (JSC::Wasm::wasmToJs):
        (JSC::Wasm::wasmToWasm):

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

        WebAssembly: We should have Origins
        https://bugs.webkit.org/show_bug.cgi?id=170217

        Reviewed by Mark Lam.

        This patch adds wasm origins for B3::Values, called OpcodeOrigin. Currently,
        OpcodeOrigin just tracks the original opcode and the location of that opcode.

        Here's a sample:

        BB#0: ; frequency = 1.000000
            Int64 @4 = Patchpoint(generator = 0x10f487fa8, earlyClobbered = [], lateClobbered = [], usedRegisters = [], resultConstraint = SomeRegister)
            Int64 @5 = FramePointer()
            Void @8 = Store(@4, @5, offset = 24, ControlDependent|Writes:Top)
            Int64 @10 = Const64(0)
            Void @12 = Store($0(@10), @5, offset = 16, ControlDependent|Writes:Top)
            Int64 @13 = Patchpoint(generator = 0x10f4be7f0, earlyClobbered = [], lateClobbered = [], usedRegisters = [], resultConstraint = SomeRegister, ExitsSideways|ControlDependent|WritesPinned|ReadsPinned|Fence|Writes:Top|Reads:Top)
            Int64 @16 = ArgumentReg(%rdi)
            Int64 @18 = ArgumentReg(%rsi)
            Int32 @22 = Trunc(@18, Wasm: {opcode: I64Rotl, location: 5})
            Int64 @23 = RotL(@16, @22, Wasm: {opcode: I64Rotl, location: 5})
            Void @27 = Return(@23, Terminal, Wasm: {opcode: End, location: 6})

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3Value.cpp:
        (JSC::B3::Value::deepDump):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::setParser):
        (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
        (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
        (JSC::Wasm::B3IRGenerator::emitLoadOp):
        (JSC::Wasm::B3IRGenerator::emitStoreOp):
        (JSC::Wasm::B3IRGenerator::addConstant):
        (JSC::Wasm::B3IRGenerator::addLoop):
        (JSC::Wasm::B3IRGenerator::unify):
        (JSC::Wasm::parseAndCompile):
        (JSC::Wasm::B3IRGenerator::emitChecksForModOrDiv):
        (JSC::Wasm::getMemoryBaseAndSize): Deleted.
        * wasm/WasmFunctionParser.h:
        (JSC::Wasm::FunctionParser::currentOpcode):
        (JSC::Wasm::FunctionParser::currentOpcodeStartingOffset):
        (JSC::Wasm::FunctionParser<Context>::FunctionParser):
        * wasm/WasmOpcodeOrigin.cpp: Added.
        (JSC::Wasm::OpcodeOrigin::dump):
        * wasm/WasmOpcodeOrigin.h: Added.
        (JSC::Wasm::OpcodeOrigin::OpcodeOrigin):
        * wasm/WasmValidate.cpp:
        (JSC::Wasm::Validate::setParser):
        * wasm/generateWasmB3IRGeneratorInlinesHeader.py:
        (CodeGenerator.generate):
        (generateB3OpCode):
        (generateConstCode):

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

        WebAssembly: option to crash if no fast memory is available
        https://bugs.webkit.org/show_bug.cgi?id=170219

        Reviewed by Mark Lam.

        * runtime/Options.h:
        * wasm/WasmMemory.cpp:
        (JSC::Wasm::webAssemblyCouldntGetFastMemory):
        (JSC::Wasm::tryGetFastMemory):

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

        The Mutator should not be able to steal the conn if the Collector hasn't reached the NotRunning phase yet.
        https://bugs.webkit.org/show_bug.cgi?id=170213
        <rdar://problem/30755345>

        Reviewed by Filip Pizlo.

        The current condition for stealing the conn isn't tight enough.  Restricting the
        stealing to when m_currentPhase == NotRunning ensures that the Collector is
        really done running.

        No test because this issue only manifests with a race condition that is difficult
        to reproduce on demand.

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

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

        WebAssembly: Make WebAssembly.instantiate/compile truly asynchronous
        https://bugs.webkit.org/show_bug.cgi?id=169187

        Reviewed by Saam Barati.

        This patch allows WebAssembly compilations to happen asynchronously.
        To do so, it refactors how much of the compilation happens and adds
        new infrastructure for async promises.

        First, there is a new class, PromiseDeferredTimer that lives on
        the VM.  PromiseDeferredTimer will manage the life-cycle of async
        pending promises and any dependencies that promise
        needs. PromiseDeferredTimer automagically releases the pending
        promise and dependencies once the JSPromiseDeferred is resolved or
        rejected. Additionally, PromiseDeferredTimer provides a mechanism
        to poll the run-loop whenever the async task needs to synchronize
        with the JS thread. Normally, that will be whenever the async task
        finishes. In the case of Web Assembly we also use this feature for
        the compile + instantiate case, where we might have more work
        after the first async task completes (more on that later).

        The next class is Wasm::Worklist, which is used to manage Wasm
        compilation tasks. The worklist class works similarly to the
        DFG/FTL Worklists. It has a pool of threads that it manages. One
        interesting aspect of Wasm Worklist is that it can synchronously
        compile a plan that is already potentially running
        asynchronously. This can occur if a user calls
        WebAssembly.instantiate() then new WebAssembly.instantiate() on
        the same module. In that case the Wasm Worklist will bump the
        priority of the running pending Plan and block the JS thread.

        This patch also makes some of the Wasm Plan code cleaner. Since we
        now defer all compilation to instantiation time, we no longer need
        to guess at which memory we are going to get. Also, Wasm Plans now
        track the work they have done with a state enum.

        Finally, this patch makes renamed HeapTimer to JSRunLoopTimer. It
        also adds changes test262AsyncTest to a more generic testing
        infrastructure. Now, in addition to the old functionality, you can
        call asyncTest() with the number of tests you expect. When the jsc
        CLI exits, it will guarantee that asyncTestPassed() is called that
        many times.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/GCActivityCallback.h:
        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::scheduleTimer):
        (JSC::IncrementalSweeper::IncrementalSweeper):
        * heap/IncrementalSweeper.h:
        * heap/StopIfNecessaryTimer.cpp:
        (JSC::StopIfNecessaryTimer::StopIfNecessaryTimer):
        * heap/StopIfNecessaryTimer.h:
        * heap/StrongInlines.h:
        * jsc.cpp:
        (GlobalObject::finishCreation):
        (printInternal):
        (functionAsyncTestStart):
        (functionAsyncTestPassed):
        (functionTestWasmModuleFunctions):
        (CommandLine::parseArguments):
        (runJSC):
        * runtime/JSPromiseDeferred.cpp:
        (JSC::JSPromiseDeferred::resolve):
        (JSC::JSPromiseDeferred::reject):
        * runtime/JSPromiseDeferred.h:
        (JSC::JSPromiseDeferred::promiseAsyncPending):
        * runtime/JSRunLoopTimer.cpp: Renamed from Source/JavaScriptCore/heap/HeapTimer.cpp.
        (JSC::JSRunLoopTimer::JSRunLoopTimer):
        (JSC::JSRunLoopTimer::setRunLoop):
        (JSC::JSRunLoopTimer::~JSRunLoopTimer):
        (JSC::JSRunLoopTimer::timerDidFire):
        (JSC::JSRunLoopTimer::scheduleTimer):
        (JSC::JSRunLoopTimer::cancelTimer):
        (JSC::JSRunLoopTimer::invalidate):
        * runtime/JSRunLoopTimer.h: Copied from Source/JavaScriptCore/heap/HeapTimer.h.
        * runtime/Options.h:
        * runtime/PromiseDeferredTimer.cpp: Added.
        (JSC::PromiseDeferredTimer::PromiseDeferredTimer):
        (JSC::PromiseDeferredTimer::doWork):
        (JSC::PromiseDeferredTimer::runRunLoop):
        (JSC::PromiseDeferredTimer::addPendingPromise):
        (JSC::PromiseDeferredTimer::cancelPendingPromise):
        (JSC::PromiseDeferredTimer::scheduleWorkSoon):
        (JSC::PromiseDeferredTimer::scheduleBlockedTask):
        * runtime/PromiseDeferredTimer.h: Renamed from Source/JavaScriptCore/heap/HeapTimer.h.
        (JSC::PromiseDeferredTimer::stopRunningTasks):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::~VM):
        * runtime/VM.h:
        * wasm/JSWebAssembly.cpp:
        (JSC::reject):
        (JSC::webAssemblyCompileFunc):
        (JSC::resolve):
        (JSC::instantiate):
        (JSC::compileAndInstantiate):
        (JSC::webAssemblyInstantiateFunc):
        (JSC::webAssemblyValidateFunc):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
        (JSC::Wasm::B3IRGenerator::memoryKind):
        (JSC::Wasm::parseAndCompile):
        * wasm/WasmB3IRGenerator.h:
        * wasm/WasmFormat.h:
        (JSC::Wasm::ModuleInformation::internalFunctionCount):
        * wasm/WasmFunctionParser.h:
        * wasm/WasmMemory.h:
        * wasm/WasmMemoryInformation.cpp:
        (JSC::Wasm::MemoryInformation::MemoryInformation):
        * wasm/WasmMemoryInformation.h:
        (JSC::Wasm::MemoryInformation::maximum):
        (JSC::Wasm::MemoryInformation::hasReservedMemory): Deleted.
        (JSC::Wasm::MemoryInformation::takeReservedMemory): Deleted.
        (JSC::Wasm::MemoryInformation::mode): Deleted.
        * wasm/WasmModuleParser.cpp:
        * wasm/WasmModuleParser.h:
        (JSC::Wasm::ModuleParser::ModuleParser):
        * wasm/WasmPlan.cpp:
        (JSC::Wasm::Plan::Plan):
        (JSC::Wasm::Plan::stateString):
        (JSC::Wasm::Plan::moveToState):
        (JSC::Wasm::Plan::fail):
        (JSC::Wasm::Plan::parseAndValidateModule):
        (JSC::Wasm::Plan::prepare):
        (JSC::Wasm::Plan::ThreadCountHolder::ThreadCountHolder):
        (JSC::Wasm::Plan::ThreadCountHolder::~ThreadCountHolder):
        (JSC::Wasm::Plan::compileFunctions):
        (JSC::Wasm::Plan::complete):
        (JSC::Wasm::Plan::waitForCompletion):
        (JSC::Wasm::Plan::cancel):
        (JSC::Wasm::Plan::run): Deleted.
        (JSC::Wasm::Plan::initializeCallees): Deleted.
        * wasm/WasmPlan.h:
        (JSC::Wasm::Plan::dontFinalize):
        (JSC::Wasm::Plan::exports):
        (JSC::Wasm::Plan::internalFunctionCount):
        (JSC::Wasm::Plan::takeModuleInformation):
        (JSC::Wasm::Plan::takeCallLinkInfos):
        (JSC::Wasm::Plan::takeWasmExitStubs):
        (JSC::Wasm::Plan::setModeAndPromise):
        (JSC::Wasm::Plan::mode):
        (JSC::Wasm::Plan::pendingPromise):
        (JSC::Wasm::Plan::vm):
        (JSC::Wasm::Plan::errorMessage):
        (JSC::Wasm::Plan::failed):
        (JSC::Wasm::Plan::hasWork):
        (JSC::Wasm::Plan::hasBeenPrepared):
        * wasm/WasmPlanInlines.h: Copied from Source/JavaScriptCore/wasm/WasmB3IRGenerator.h.
        (JSC::Wasm::Plan::initializeCallees):
        * wasm/WasmValidate.cpp:
        * wasm/WasmWorklist.cpp: Added.
        (JSC::Wasm::Worklist::priorityString):
        (JSC::Wasm::Worklist::QueueElement::setToNextPriority):
        (JSC::Wasm::Worklist::iterate):
        (JSC::Wasm::Worklist::enqueue):
        (JSC::Wasm::Worklist::completePlanSynchronously):
        (JSC::Wasm::Worklist::stopAllPlansForVM):
        (JSC::Wasm::Worklist::Worklist):
        (JSC::Wasm::Worklist::~Worklist):
        (JSC::Wasm::existingWorklistOrNull):
        (JSC::Wasm::ensureWorklist):
        * wasm/WasmWorklist.h: Added.
        (JSC::Wasm::Worklist::nextTicket):
        (JSC::Wasm::Worklist::Comparator::operator()):
        * wasm/js/JSWebAssemblyCallee.h:
        * wasm/js/JSWebAssemblyCodeBlock.cpp:
        (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock):
        (JSC::JSWebAssemblyCodeBlock::initialize):
        (JSC::JSWebAssemblyCodeBlock::isSafeToRun):
        * wasm/js/JSWebAssemblyCodeBlock.h:
        (JSC::JSWebAssemblyCodeBlock::create):
        (JSC::JSWebAssemblyCodeBlock::initialized):
        (JSC::JSWebAssemblyCodeBlock::plan):
        (JSC::JSWebAssemblyCodeBlock::runnable):
        (JSC::JSWebAssemblyCodeBlock::errorMessage):
        (JSC::JSWebAssemblyCodeBlock::callees):
        * wasm/js/JSWebAssemblyHelpers.h:
        (JSC::createSourceBufferFromValue):
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::finishCreation):
        (JSC::JSWebAssemblyInstance::visitChildren):
        (JSC::JSWebAssemblyInstance::addUnitializedCodeBlock):
        (JSC::JSWebAssemblyInstance::finalizeCreation):
        (JSC::JSWebAssemblyInstance::create):
        (JSC::JSWebAssemblyInstance::setMemory): Deleted.
        * wasm/js/JSWebAssemblyInstance.h:
        (JSC::JSWebAssemblyInstance::codeBlock):
        (JSC::JSWebAssemblyInstance::initialized):
        (JSC::JSWebAssemblyInstance::module):
        (JSC::JSWebAssemblyInstance::importFunction):
        (JSC::JSWebAssemblyInstance::setMemory):
        (JSC::JSWebAssemblyInstance::table):
        (JSC::JSWebAssemblyInstance::importFunctions):
        (JSC::JSWebAssemblyInstance::setImportFunction): Deleted.
        (JSC::JSWebAssemblyInstance::setTable): Deleted.
        * wasm/js/JSWebAssemblyModule.cpp:
        (JSC::JSWebAssemblyModule::createStub):
        (JSC::JSWebAssemblyModule::JSWebAssemblyModule):
        (JSC::JSWebAssemblyModule::finishCreation):
        (JSC::JSWebAssemblyModule::setCodeBlock):
        (JSC::JSWebAssemblyModule::buildCodeBlock): Deleted.
        (JSC::JSWebAssemblyModule::create): Deleted.
        (JSC::JSWebAssemblyModule::codeBlock): Deleted.
        * wasm/js/JSWebAssemblyModule.h:
        (JSC::JSWebAssemblyModule::moduleInformation):
        (JSC::JSWebAssemblyModule::codeBlock):
        (JSC::JSWebAssemblyModule::source):
        (JSC::JSWebAssemblyModule::takeReservedMemory): Deleted.
        (JSC::JSWebAssemblyModule::codeBlockFor): Deleted.
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::constructJSWebAssemblyInstance):
        (JSC::WebAssemblyInstanceConstructor::createInstance): Deleted.
        * wasm/js/WebAssemblyModuleConstructor.cpp:
        (JSC::WebAssemblyModuleConstructor::createModule):
        * wasm/js/WebAssemblyModulePrototype.cpp:
        (JSC::webAssemblyModuleProtoImports):
        (JSC::webAssemblyModuleProtoExports):
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::finishCreation):
        (JSC::WebAssemblyModuleRecord::link):
        (JSC::WebAssemblyModuleRecord::evaluate):
        * wasm/js/WebAssemblyModuleRecord.h:

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

        WebAssembly: add fallback to use pinned register to load/store state
        https://bugs.webkit.org/show_bug.cgi?id=169773

        Reviewed by Saam Barati.

        This patch adds a new pinned register to hold JSWebAssemblyInstance,
        which is used to represent the context of running Wasm code.
        While we use fast TLS to hold the context in macOS, we do not have
        any system reserved fast TLS slot in the other systems. This pinned
        register approach is used in these systems. These changes decouple
        VM from Wasm module to make Wasm module position independent code.

        While using fast TLS could be beneficial in x64 systems which number of
        registers is relatively small, pinned register approach could be
        beneficial in ARM64 which has plenty of registers. In macOS, we can
        switch the implementation with the runtime flag. Thus macOS port can
        compare the performance and decide which implementation is used after
        landing this patch.

        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::offsetOfVM):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::loadWasmContext):
        (JSC::AssemblyHelpers::storeWasmContext):
        (JSC::AssemblyHelpers::loadWasmContextNeedsMacroScratchRegister):
        (JSC::AssemblyHelpers::storeWasmContextNeedsMacroScratchRegister):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::loadWasmContext): Deleted.
        (JSC::AssemblyHelpers::storeWasmContext): Deleted.
        (JSC::AssemblyHelpers::loadWasmContextNeedsMacroScratchRegister): Deleted.
        (JSC::AssemblyHelpers::storeWasmContextNeedsMacroScratchRegister): Deleted.
        * jit/Repatch.cpp:
        (JSC::webAssemblyOwner):
        (JSC::linkFor):
        (JSC::linkPolymorphicCall):
        (JSC::isWebAssemblyToJSCallee): Deleted.
        * jit/ThunkGenerators.cpp:
        (JSC::throwExceptionFromWasmThunkGenerator):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LowLevelInterpreter.asm:
        * runtime/JSCell.cpp:
        (JSC::JSCell::isAnyWasmCallee):
        * runtime/JSCellInlines.h:
        (JSC::isWebAssemblyToJSCallee):
        * runtime/JSType.h:
        * runtime/StackFrame.cpp:
        (JSC::StackFrame::functionName):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        (JSC::VM::wasmContextOffset):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::materializeWasmContext):
        (JSC::Wasm::B3IRGenerator::restoreWasmContext):
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        (JSC::Wasm::getMemoryBaseAndSize):
        (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
        (JSC::Wasm::createJSToWasmWrapper):
        (JSC::Wasm::loadWasmContext): Deleted.
        (JSC::Wasm::storeWasmContext): Deleted.
        (JSC::Wasm::restoreWebAssemblyGlobalState): Deleted.
        * wasm/WasmBinding.cpp:
        (JSC::Wasm::wasmToJs):
        * wasm/WasmContext.cpp:
        (JSC::loadWasmContext):
        (JSC::storeWasmContext):
        * wasm/WasmContext.h:
        * wasm/WasmMemoryInformation.cpp:
        (JSC::Wasm::getPinnedRegisters):
        (JSC::Wasm::PinnedRegisterInfo::get):
        (JSC::Wasm::PinnedRegisterInfo::PinnedRegisterInfo):
        * wasm/WasmMemoryInformation.h:
        (JSC::Wasm::PinnedRegisterInfo::toSave):
        (JSC::Wasm::useFastTLS):
        (JSC::Wasm::useFastTLSForWasmContext):
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::finishCreation):
        (JSC::JSWebAssemblyInstance::visitChildren):
        * wasm/js/JSWebAssemblyInstance.h:
        (JSC::JSWebAssemblyInstance::offsetOfCallee):
        * wasm/js/JSWebAssemblyModule.cpp:
        (JSC::JSWebAssemblyModule::finishCreation):
        (JSC::JSWebAssemblyModule::visitChildren):
        * wasm/js/JSWebAssemblyModule.h:
        (JSC::JSWebAssemblyModule::callee):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction):
        (JSC::WebAssemblyFunction::create):
        * wasm/js/WebAssemblyToJSCallee.cpp:
        (JSC::WebAssemblyToJSCallee::create):
        (JSC::WebAssemblyToJSCallee::createStructure):
        (JSC::WebAssemblyToJSCallee::finishCreation):
        (JSC::WebAssemblyToJSCallee::visitChildren):
        (JSC::WebAssemblyToJSCallee::destroy): Deleted.
        * wasm/js/WebAssemblyToJSCallee.h:

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

        Web Inspector: Add "Disable Caches" option that only applies to the inspected page while Web Inspector is open
        https://bugs.webkit.org/show_bug.cgi?id=169865
        <rdar://problem/31250573>

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/Network.json:
        Rename the command for disabling resource caching to match the WebCore::Page
        flag. This also removes the possibility that this could be confused for the old,
        buggy command that this patch rips out.

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

        [JSC] Move platformThreadSignal to WTF
        https://bugs.webkit.org/show_bug.cgi?id=170097

        Reviewed by Mark Lam.

        It is a small clean up towards https://bugs.webkit.org/show_bug.cgi?id=170027.
        platformThreadSignal uses PlatformThread in JSC, but it can be implemented in
        WTF ThreadIdentifier.

        * runtime/JSLock.cpp:
        (JSC::JSLock::lock):
        * runtime/JSLock.h:
        (JSC::JSLock::ownerThread):
        (JSC::JSLock::currentThreadIsHoldingLock):
        * runtime/PlatformThread.h:
        (JSC::platformThreadSignal): Deleted.
        * runtime/VM.h:
        (JSC::VM::ownerThread):
        * runtime/VMTraps.cpp:
        (JSC::VMTraps::SignalSender::send):

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

        WebAssembly: implement Module imports/exports
        https://bugs.webkit.org/show_bug.cgi?id=166982

        Reviewed by Saam Barati.

        As defined in: https://github.com/WebAssembly/design/commit/18cbacb90cd3584dd5c9aa3d392e4e55f66af6ab

        * wasm/WasmFormat.h:
        (JSC::Wasm::makeString): use uppercase instead, it was only used
        for diagnostic but is now used for the expected JS property's
        capitalization
        * wasm/js/WebAssemblyModulePrototype.cpp:
        (JSC::webAssemblyModuleProtoImports):
        (JSC::webAssemblyModuleProtoExports):

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

        WebAssembly: JSWebAssemblyCodeBlock.h belongs in JavaScriptCore/wasm/js not JavaScriptCore/wasm
        https://bugs.webkit.org/show_bug.cgi?id=170160

        Reviewed by Mark Lam.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * wasm/js/JSWebAssemblyCodeBlock.h: Renamed from Source/JavaScriptCore/wasm/JSWebAssemblyCodeBlock.h.

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

        WebAssembly: misc memory testing
        https://bugs.webkit.org/show_bug.cgi?id=170137

        Reviewed by Keith Miller.

        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::WebAssemblyInstanceConstructor::createInstance): improve error messages

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

        Add ARM64 system instructions to disassembler
        https://bugs.webkit.org/show_bug.cgi?id=170084

        Reviewed by Saam Barati.

        This changes adds support for MRS and MSR instructions, and refactors the DMB
        disassembly to handle all of the barrier instructions.

        * disassembler/ARM64/A64DOpcode.cpp:
        (JSC::ARM64Disassembler::A64DOpcodeMSRImmediate::format):
        (JSC::ARM64Disassembler::A64DOpcodeMSROrMRSRegister::format):
        (JSC::ARM64Disassembler::A64DOpcodeSystemSync::format):
        (JSC::ARM64Disassembler::A64DOpcodeDmb::format): Deleted.
        * disassembler/ARM64/A64DOpcode.h:
        (JSC::ARM64Disassembler::A64DOpcodeSystem::lBit):
        (JSC::ARM64Disassembler::A64DOpcodeSystem::op0):
        (JSC::ARM64Disassembler::A64DOpcodeSystem::op1):
        (JSC::ARM64Disassembler::A64DOpcodeSystem::crN):
        (JSC::ARM64Disassembler::A64DOpcodeSystem::crM):
        (JSC::ARM64Disassembler::A64DOpcodeSystem::op2):
        (JSC::ARM64Disassembler::A64DOpcodeMSROrMRSRegister::opName):
        (JSC::ARM64Disassembler::A64DOpcodeMSROrMRSRegister::systemRegister):
        (JSC::ARM64Disassembler::A64DOpcodeSystemSync::opName):
        (JSC::ARM64Disassembler::A64DOpcodeSystemSync::option):
        (JSC::ARM64Disassembler::A64DOpcodeDmb::opName): Deleted.
        (JSC::ARM64Disassembler::A64DOpcodeDmb::option): Deleted.
        (JSC::ARM64Disassembler::A64DOpcodeDmb::crM): Deleted.

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

        B3::fixSSA should do liveness pruning
        https://bugs.webkit.org/show_bug.cgi?id=170111

        Reviewed by Saam Barati.
        
        This moves all of the logic of Air::Liveness<> to WTF::Liveness<> and then uses that to
        create B3::VariableLiveness. Then this uses VariableLiveness::LiveAtHead to prune Phi
        construction.
        
        This makes B3::fixSSA run twice as fast. This is a 13% progression on WasmBench compile
        times.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3BasicBlock.h:
        (JSC::B3::BasicBlock::get):
        * b3/B3FixSSA.cpp:
        (JSC::B3::fixSSA):
        * b3/B3VariableLiveness.cpp: Added.
        (JSC::B3::VariableLiveness::VariableLiveness):
        (JSC::B3::VariableLiveness::~VariableLiveness):
        * b3/B3VariableLiveness.h: Added.
        (JSC::B3::VariableLivenessAdapter::VariableLivenessAdapter):
        (JSC::B3::VariableLivenessAdapter::numIndices):
        (JSC::B3::VariableLivenessAdapter::valueToIndex):
        (JSC::B3::VariableLivenessAdapter::indexToValue):
        (JSC::B3::VariableLivenessAdapter::blockSize):
        (JSC::B3::VariableLivenessAdapter::forEachEarlyUse):
        (JSC::B3::VariableLivenessAdapter::forEachLateUse):
        (JSC::B3::VariableLivenessAdapter::forEachEarlyDef):
        (JSC::B3::VariableLivenessAdapter::forEachLateDef):
        * b3/air/AirCFG.h: Added.
        (JSC::B3::Air::CFG::CFG):
        (JSC::B3::Air::CFG::root):
        (JSC::B3::Air::CFG::newMap):
        (JSC::B3::Air::CFG::successors):
        (JSC::B3::Air::CFG::predecessors):
        (JSC::B3::Air::CFG::index):
        (JSC::B3::Air::CFG::node):
        (JSC::B3::Air::CFG::numNodes):
        (JSC::B3::Air::CFG::dump):
        * b3/air/AirCode.cpp:
        (JSC::B3::Air::Code::Code):
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::cfg):
        * b3/air/AirLiveness.h:
        (JSC::B3::Air::LivenessAdapter::LivenessAdapter):
        (JSC::B3::Air::LivenessAdapter::blockSize):
        (JSC::B3::Air::LivenessAdapter::forEachEarlyUse):
        (JSC::B3::Air::LivenessAdapter::forEachLateUse):
        (JSC::B3::Air::LivenessAdapter::forEachEarlyDef):
        (JSC::B3::Air::LivenessAdapter::forEachLateDef):
        (JSC::B3::Air::TmpLivenessAdapter::TmpLivenessAdapter):
        (JSC::B3::Air::TmpLivenessAdapter::numIndices):
        (JSC::B3::Air::StackSlotLivenessAdapter::StackSlotLivenessAdapter):
        (JSC::B3::Air::StackSlotLivenessAdapter::numIndices):
        (JSC::B3::Air::StackSlotLivenessAdapter::indexToValue):
        (JSC::B3::Air::Liveness::Liveness):
        (JSC::B3::Air::Liveness::LocalCalc::LocalCalc): Deleted.
        (JSC::B3::Air::Liveness::LocalCalc::Iterable::Iterable): Deleted.
        (JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::iterator): Deleted.
        (JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::operator++): Deleted.
        (JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::operator*): Deleted.
        (JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::operator==): Deleted.
        (JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::operator!=): Deleted.
        (JSC::B3::Air::Liveness::LocalCalc::Iterable::begin): Deleted.
        (JSC::B3::Air::Liveness::LocalCalc::Iterable::end): Deleted.
        (JSC::B3::Air::Liveness::LocalCalc::Iterable::contains): Deleted.
        (JSC::B3::Air::Liveness::LocalCalc::live): Deleted.
        (JSC::B3::Air::Liveness::LocalCalc::isLive): Deleted.
        (JSC::B3::Air::Liveness::LocalCalc::execute): Deleted.
        (JSC::B3::Air::Liveness::rawLiveAtHead): Deleted.
        (JSC::B3::Air::Liveness::Iterable::Iterable): Deleted.
        (JSC::B3::Air::Liveness::Iterable::iterator::iterator): Deleted.
        (JSC::B3::Air::Liveness::Iterable::iterator::operator*): Deleted.
        (JSC::B3::Air::Liveness::Iterable::iterator::operator++): Deleted.
        (JSC::B3::Air::Liveness::Iterable::iterator::operator==): Deleted.
        (JSC::B3::Air::Liveness::Iterable::iterator::operator!=): Deleted.
        (JSC::B3::Air::Liveness::Iterable::begin): Deleted.
        (JSC::B3::Air::Liveness::Iterable::end): Deleted.
        (JSC::B3::Air::Liveness::Iterable::contains): Deleted.
        (JSC::B3::Air::Liveness::liveAtHead): Deleted.
        (JSC::B3::Air::Liveness::liveAtTail): Deleted.
        (JSC::B3::Air::Liveness::workset): Deleted.

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

        Air::Liveness shouldn't need HashSets
        https://bugs.webkit.org/show_bug.cgi?id=170102

        Reviewed by Yusuke Suzuki.
        
        This converts Air::Liveness<> to no longer use HashSets or BitVectors. This turns out to be
        easy because it's cheap enough to do a sorted merge of the things being added to liveAtHead and
        the things in the predecessors' liveAtTail. This turns out to be faster - it's a 2% overall
        compile time progression on WasmBench.
        
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower): Add a FIXME unrelated to this patch.
        * b3/air/AirLiveness.h:
        (JSC::B3::Air::AbstractLiveness::AbstractLiveness):
        (JSC::B3::Air::AbstractLiveness::LocalCalc::LocalCalc):
        (JSC::B3::Air::AbstractLiveness::rawLiveAtHead):
        (JSC::B3::Air::AbstractLiveness::liveAtHead):
        (JSC::B3::Air::AbstractLiveness::liveAtTail):
        * b3/air/AirTmp.h:
        (JSC::B3::Air::Tmp::bank):
        (JSC::B3::Air::Tmp::tmpIndex):
        * dfg/DFGStoreBarrierClusteringPhase.cpp:

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

        Air should use RegisterSet for RegLiveness
        https://bugs.webkit.org/show_bug.cgi?id=170108

        Reviewed by Yusuke Suzuki.
        
        The biggest change here is the introduction of the new RegLiveness class. This is a
        drop-in replacement for the old RegLiveness, which was a specialization of
        AbstractLiveness<>, but it's about 30% faster. It gets its speed boost from just using
        sets everywhere, which is efficient for registers since RegisterSet is just two (on
        x86-64) or three 32-bit (on ARM64) statically allocated words. This looks like a 1%
        compile time progression on WasmBench.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3TimingScope.cpp: Records phase timing totals.
        (JSC::B3::TimingScope::TimingScope):
        (JSC::B3::TimingScope::~TimingScope):
        * b3/B3TimingScope.h:
        * b3/air/AirAllocateRegistersByGraphColoring.cpp:
        (JSC::B3::Air::allocateRegistersByGraphColoring):
        * b3/air/AirLiveness.h: Move code around and rename a bit to make it more like RegLiveness; in particular we want the `iterator` to be called `iterator` not `Iterator`, and we want it to be internal to its iterable. Also rename this template to Liveness, to match the header filename.
        (JSC::B3::Air::Liveness::Liveness):
        (JSC::B3::Air::Liveness::LocalCalc::LocalCalc):
        (JSC::B3::Air::Liveness::LocalCalc::Iterable::Iterable):
        (JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::iterator):
        (JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::operator++):
        (JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::operator*):
        (JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::operator==):
        (JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::operator!=):
        (JSC::B3::Air::Liveness::LocalCalc::Iterable::begin):
        (JSC::B3::Air::Liveness::LocalCalc::Iterable::end):
        (JSC::B3::Air::Liveness::Iterable::Iterable):
        (JSC::B3::Air::Liveness::Iterable::iterator::iterator):
        (JSC::B3::Air::RegLivenessAdapter::RegLivenessAdapter): Deleted.
        (JSC::B3::Air::RegLivenessAdapter::numIndices): Deleted.
        (JSC::B3::Air::RegLivenessAdapter::acceptsBank): Deleted.
        (JSC::B3::Air::RegLivenessAdapter::acceptsRole): Deleted.
        (JSC::B3::Air::RegLivenessAdapter::valueToIndex): Deleted.
        (JSC::B3::Air::RegLivenessAdapter::indexToValue): Deleted.
        (JSC::B3::Air::AbstractLiveness::AbstractLiveness): Deleted.
        (JSC::B3::Air::AbstractLiveness::LocalCalc::LocalCalc): Deleted.
        (JSC::B3::Air::AbstractLiveness::LocalCalc::Iterator::Iterator): Deleted.
        (JSC::B3::Air::AbstractLiveness::LocalCalc::Iterator::operator++): Deleted.
        (JSC::B3::Air::AbstractLiveness::LocalCalc::Iterator::operator*): Deleted.
        (JSC::B3::Air::AbstractLiveness::LocalCalc::Iterator::operator==): Deleted.
        (JSC::B3::Air::AbstractLiveness::LocalCalc::Iterator::operator!=): Deleted.
        (JSC::B3::Air::AbstractLiveness::LocalCalc::Iterable::Iterable): Deleted.
        (JSC::B3::Air::AbstractLiveness::LocalCalc::Iterable::begin): Deleted.
        (JSC::B3::Air::AbstractLiveness::LocalCalc::Iterable::end): Deleted.
        (JSC::B3::Air::AbstractLiveness::LocalCalc::Iterable::contains): Deleted.
        (JSC::B3::Air::AbstractLiveness::LocalCalc::live): Deleted.
        (JSC::B3::Air::AbstractLiveness::LocalCalc::isLive): Deleted.
        (JSC::B3::Air::AbstractLiveness::LocalCalc::execute): Deleted.
        (JSC::B3::Air::AbstractLiveness::rawLiveAtHead): Deleted.
        (JSC::B3::Air::AbstractLiveness::Iterable::Iterable): Deleted.
        (JSC::B3::Air::AbstractLiveness::Iterable::iterator::iterator): Deleted.
        (JSC::B3::Air::AbstractLiveness::Iterable::iterator::operator*): Deleted.
        (JSC::B3::Air::AbstractLiveness::Iterable::iterator::operator++): Deleted.
        (JSC::B3::Air::AbstractLiveness::Iterable::iterator::operator==): Deleted.
        (JSC::B3::Air::AbstractLiveness::Iterable::iterator::operator!=): Deleted.
        (JSC::B3::Air::AbstractLiveness::Iterable::begin): Deleted.
        (JSC::B3::Air::AbstractLiveness::Iterable::end): Deleted.
        (JSC::B3::Air::AbstractLiveness::Iterable::contains): Deleted.
        (JSC::B3::Air::AbstractLiveness::liveAtHead): Deleted.
        (JSC::B3::Air::AbstractLiveness::liveAtTail): Deleted.
        (JSC::B3::Air::AbstractLiveness::workset): Deleted.
        * b3/air/AirLogRegisterPressure.cpp:
        * b3/air/AirLowerAfterRegAlloc.cpp:
        * b3/air/AirRegLiveness.cpp: Added.
        (JSC::B3::Air::RegLiveness::RegLiveness):
        (JSC::B3::Air::RegLiveness::~RegLiveness):
        (JSC::B3::Air::RegLiveness::LocalCalc::execute):
        * b3/air/AirRegLiveness.h: Added.
        (JSC::B3::Air::RegLiveness::LocalCalc::LocalCalc):
        (JSC::B3::Air::RegLiveness::LocalCalc::live):
        (JSC::B3::Air::RegLiveness::LocalCalc::isLive):
        (JSC::B3::Air::RegLiveness::liveAtHead):
        (JSC::B3::Air::RegLiveness::liveAtTail):
        * b3/air/AirReportUsedRegisters.cpp:
        * jit/RegisterSet.h:
        (JSC::RegisterSet::add):
        (JSC::RegisterSet::remove):
        (JSC::RegisterSet::contains):
        (JSC::RegisterSet::subsumes):
        (JSC::RegisterSet::iterator::iterator):
        (JSC::RegisterSet::iterator::operator*):
        (JSC::RegisterSet::iterator::operator++):
        (JSC::RegisterSet::iterator::operator==):
        (JSC::RegisterSet::iterator::operator!=):
        (JSC::RegisterSet::begin):
        (JSC::RegisterSet::end):

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

        Fix wasm by returning after we do TLS.

        Rubber stamped by Keith Miller.

        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::storeWasmContext):

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

        Add some instrumentation in Heap::resumeThePeriphery() to help debug an issue.
        https://bugs.webkit.org/show_bug.cgi?id=170086
        <rdar://problem/31253673>

        Reviewed by Saam Barati.

        Adding some instrumentation in Heap::resumeThePeriphery() to dump some Heap state
        just before we RELEASE_ASSERT_NOT_REACHED.

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

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

        WebAssembly: store state in TLS instead of on VM
        https://bugs.webkit.org/show_bug.cgi?id=169611

        Reviewed by Filip Pizlo.

        Using thread-local storage instead of VM makes code more position
        independent. We used to store the WebAssembly top Instance (the
        latest one in the call stack) on VM, now we instead store it in
        TLS. This top Instance is used to access a bunch of state such as
        Memory location, size, table (for call_indirect), etc.

        Instead of calling it "top", which is confusing, we now just call
        it WasmContext.

        Making the code PIC means future patches will be able to
        postMessage and structured clone into IDB without having to
        recompile the code. This wasn't possible before because we
        hard-coded the address of VM at compilation time. That doesn't
        work between workers, and doesn't work across reloads (which IDB
        is intended to do).

        It'll also potentially make code faster once we start tuning
        what's in TLS, what's in which of the 4 free slots, and what's in
        pinned registers. I'm leaving this tuning for later because
        there's lower lying fruit for us to pick.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/AbstractMacroAssembler.h:
        * assembler/AllowMacroScratchRegisterUsageIf.h: Copied from assembler/AllowMacroScratchRegisterUsage.h.
        (JSC::AllowMacroScratchRegisterUsageIf::AllowMacroScratchRegisterUsageIf):
        (JSC::AllowMacroScratchRegisterUsageIf::~AllowMacroScratchRegisterUsageIf):
        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::storeToTLSPtr): we previously didn't have
        the code required to store to TLS, only to load
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::loadFromTLSPtrNeedsMacroScratchRegister):
        (JSC::MacroAssemblerARM64::storeToTLS32):
        (JSC::MacroAssemblerARM64::storeToTLS64):
        (JSC::MacroAssemblerARM64::storeToTLSPtrNeedsMacroScratchRegister):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::loadFromTLSPtrNeedsMacroScratchRegister):
        (JSC::MacroAssemblerX86Common::storeToTLS32):
        (JSC::MacroAssemblerX86Common::storeToTLSPtrNeedsMacroScratchRegister):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::loadFromTLS64): was loading 32-bit instead of 64-bit
        (JSC::MacroAssemblerX86_64::storeToTLS64):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::movl_rm):
        (JSC::X86Assembler::movq_rm):
        * b3/testb3.cpp:
        (JSC::B3::testFastTLSLoad):
        (JSC::B3::testFastTLSStore):
        (JSC::B3::run):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::loadWasmContext):
        (JSC::AssemblyHelpers::storeWasmContext):
        (JSC::AssemblyHelpers::loadWasmContextNeedsMacroScratchRegister):
        (JSC::AssemblyHelpers::storeWasmContextNeedsMacroScratchRegister):
        * jit/Repatch.cpp:
        (JSC::webAssemblyOwner):
        * jit/ThunkGenerators.cpp:
        (JSC::throwExceptionFromWasmThunkGenerator):
        * runtime/Options.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::loadWasmContext):
        (JSC::Wasm::storeWasmContext):
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        (JSC::Wasm::getMemoryBaseAndSize):
        (JSC::Wasm::restoreWebAssemblyGlobalState):
        (JSC::Wasm::createJSToWasmWrapper):
        (JSC::Wasm::parseAndCompile):
        * wasm/WasmBinding.cpp:
        (JSC::Wasm::materializeImportJSCell):
        (JSC::Wasm::wasmToJs):
        (JSC::Wasm::wasmToWasm):
        * wasm/WasmContext.cpp: Added.
        (JSC::loadWasmContext):
        (JSC::storeWasmContext):
        * wasm/WasmContext.h: Added. Replaces "top" JSWebAssemblyInstance.
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction):
        * wasm/js/WebAssemblyInstanceConstructor.h:

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

        WebAssembly: spec-tests/memory.wast.js fails in debug
        https://bugs.webkit.org/show_bug.cgi?id=169794

        Reviewed by Keith Miller.

        The failure was due to empty memories (with maximum size 0). Those
        only occur in tests and in code that's trying to trip us. This
        patch adds memory mode "none" which represents no memory. It can
        work with either bounds checked or signaling code because it never
        contains loads and stores.

        The spec tests which were failing did the following:
            > (module (memory (data)) (func (export "memsize") (result i32) (current_memory)))
            > (assert_return (invoke "memsize") (i32.const 0))
            > (module (memory (data "")) (func (export "memsize") (result i32) (current_memory)))
            > (assert_return (invoke "memsize") (i32.const 0))
            > (module (memory (data "x")) (func (export "memsize") (result i32) (current_memory)))
            > (assert_return (invoke "memsize") (i32.const 1))

        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::memoryKind):
        * wasm/WasmMemory.cpp:
        (JSC::Wasm::tryGetFastMemory):
        (JSC::Wasm::releaseFastMemory):
        (JSC::Wasm::Memory::Memory):
        (JSC::Wasm::Memory::createImpl):
        (JSC::Wasm::Memory::create):
        (JSC::Wasm::Memory::grow):
        (JSC::Wasm::Memory::makeString):
        * wasm/WasmMemory.h:
        * wasm/WasmMemoryInformation.cpp:
        (JSC::Wasm::MemoryInformation::MemoryInformation):
        * wasm/js/JSWebAssemblyCodeBlock.cpp:
        (JSC::JSWebAssemblyCodeBlock::isSafeToRun):
        * wasm/js/JSWebAssemblyModule.cpp:
        (JSC::JSWebAssemblyModule::codeBlock):
        (JSC::JSWebAssemblyModule::finishCreation):
        * wasm/js/JSWebAssemblyModule.h:
        (JSC::JSWebAssemblyModule::codeBlock):
        (JSC::JSWebAssemblyModule::codeBlockFor):

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

        Array memcpy'ing fast paths should check if we're having a bad time if they cannot handle it.
        https://bugs.webkit.org/show_bug.cgi?id=170064
        <rdar://problem/31246098>

        Reviewed by Geoffrey Garen.

        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoPrivateFuncConcatMemcpy):
        * runtime/JSArray.cpp:
        (JSC::JSArray::fastSlice):

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

        [JSC] Use jsNontrivialString agressively for ToString(Int52)
        https://bugs.webkit.org/show_bug.cgi?id=170002

        Reviewed by Sam Weinig.

        We use the same logic used for Int32 to use jsNontvirialString.
        After single character check, produced string is always longer than 1.
        Thus, we can use jsNontrivialString.

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

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

        [JSC] Use WeakRandom for SamplingProfiler interval fluctuation
        https://bugs.webkit.org/show_bug.cgi?id=170045

        Reviewed by Mark Lam.

        It is unnecessary to use cryptographicallyRandomNumber for SamplingProfiler
        interval fluctuation. Use WeakRandom instead.

        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::SamplingProfiler):
        (JSC::SamplingProfiler::timerLoop):
        * runtime/SamplingProfiler.h:

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

        Array.prototype.splice behaves incorrectly when the VM is "having a bad time".
        https://bugs.webkit.org/show_bug.cgi?id=170025
        <rdar://problem/31228679>

        Reviewed by Saam Barati.

        * runtime/ArrayPrototype.cpp:
        (JSC::copySplicedArrayElements):
        (JSC::arrayProtoFuncSplice):

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

        [JSC][DFG] Make addShouldSpeculateAnyInt more conservative to avoid regression caused by Double <-> Int52 conversions
        https://bugs.webkit.org/show_bug.cgi?id=169998

        Reviewed by Saam Barati.

        Double <-> Int52 and JSValue <-> Int52 conversions are not so cheap. Thus, Int52Rep is super carefully emitted.
        We make addShouldSpeculateAnyInt more conservative to avoid regressions caused by the above conversions.
        We select ArithAdd(Int52, Int52) only when this calculation is beneficial compared to added Int52Rep conversions.

        This patch tighten the conditions of addShouldSpeculateAnyInt.

        1. Honor DoubleConstant.

        When executing imaging-darkroom, we have a thing like that,

            132:< 2:loc36> DoubleConstant(Double|UseAsOther, AnyIntAsDouble, Double: 4607182418800017408, 1.000000, bc#114)
            1320:< 1:loc38>        Int52Rep(Check:Int32:@82, Int52|PureInt, Int32, Exits, bc#114)
            1321:< 1:loc39>        Int52Constant(Int52|PureInt, Boolint32Nonboolint32Int52, Double: 4607182418800017408, 1.000000, bc#114)
            133:<!3:loc39> ArithSub(Int52Rep:@1320<Int52>, Int52Rep:@1321<Int52>, Int52|MustGen, Int52, CheckOverflow, Exits, bc#114)

        The LHS of ArithSub says predicting Boolint32, and the rhs says AnyIntAsDouble. Thus we select ArithSub(Int52, Int52) instead
        of ArithSub(Double, Double). However, it soon causes OSR exits. In imaging-darkroom, LHS's Int32 prediction will be broken.
        While speculating Int32 in the above situation is reasonable approach since the given LHS says predicting Int32, this causes
        severe performance regression.

        Previously, we always select ArithSub(Double, Double). So accidentally, we do not encounter this misprediction issue.

        One thing can be found that we have DoubleConstant in the RHS. It means that we have `1.0` instead of `1` in the code.
        We can see the code like `lhs - 1.0` instead of `lhs - 1` in imaging-darkroom. It offers good information that lhs and
        the resulting value would be double. Handling the above ArithSub in double seems more appropriate rather than handling
        it in Int52.

        So, in this patch, we honor DoubleConstant. If we find DoubleConstant on one operand, we give up selecting
        Arith[Sub,Add](Int52, Int52). This change removes OSR exits occurr in imaging-darkroom right now.

        2. Two Int52Rep(Double) conversions are not desirable.

        We allow AnyInt ArithAdd only when the one operand of the binary operation should be speculated AnyInt. It is a bit conservative
        decision. This is because Double to Int52 conversion is not so cheap. Frequent back-and-forth conversions between Double and Int52
        rather hurt the performance. If the one operand of the operation is already Int52, the cost for constructing ArithAdd becomes
        cheap since only one Double to Int52 conversion could be required.
        This recovers some regression in assorted tests while keeping kraken crypto improvements.

        3. Avoid frequent Int52 to JSValue conversions.

        Int52 to JSValue conversion is not so cheap. Thus, we would like to avoid such situations. So, in this patch, we allow
        Arith(Int52, Int52) with AnyIntAsDouble operand only when the node is used as number. By doing so, we avoid the case like,
        converting Int52, performing ArithAdd, and soon converting back to JSValue.

        The above 3 changes recover the regression measured in microbenchmarks/int52-back-and-forth.js and assorted benchmarks.
        And still it keeps kraken crypto improvements.

                                                   baseline                  patched

        imaging-darkroom                       201.112+-3.192      ^     189.532+-2.883         ^ definitely 1.0611x faster
        stanford-crypto-pbkdf2                 103.953+-2.325            100.926+-2.396           might be 1.0300x faster
        stanford-crypto-sha256-iterative        35.103+-1.071      ?      36.049+-1.143         ? might be 1.0270x slower

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

== Rolled over to ChangeLog-2017-03-23 ==