ChangeLog-2018-01-01   [plain text]


2017-12-22  Jeff Miller  <jeffm@apple.com>

        Update user-visible copyright strings to include 2018
        https://bugs.webkit.org/show_bug.cgi?id=181141

        Reviewed by Dan Bernstein.

        * Info.plist:

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

        [JSC] Remove unused JSTypes
        https://bugs.webkit.org/show_bug.cgi?id=181184

        Reviewed by Saam Barati.

        JSType includes some unused types such as NullType. They are for
        primitive values in old days. But now JSType is only used for JSCells.

        * runtime/JSType.h:
        * runtime/TypedArrayType.cpp:
        (JSC::typeForTypedArrayType):

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

        Remove op_assert and make @assert in builtins a function call so we have DFG/FTL coverage for builtins that use @assert in debug builds
        https://bugs.webkit.org/show_bug.cgi?id=181176

        Reviewed by Yusuke Suzuki.

        Previously, op_assert was only implemented in the LLInt and baseline JIT. This
        meant that any builtin that used @assert was not tiering up to the DFG/FTL
        in debug builds. This patch changes @assert to just call a host function when
        !ASSERT_DISABLED. It's a no-op when ASSERT_DISABLED. Now, builtins that use @assert
        will tier up to the DFG/FTL on debug builds.

        * builtins/BuiltinNames.h:
        * bytecode/BytecodeDumper.cpp:
        (JSC::BytecodeDumper<Block>::dumpBytecode):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitAssert): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::FunctionCallResolveNode::emitBytecode):
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_assert): Deleted.
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * llint/LowLevelInterpreter.asm:
        * runtime/CommonSlowPaths.cpp:
        * runtime/CommonSlowPaths.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::assertCall):
        (JSC::JSGlobalObject::init):

2017-12-28  Fujii Hironori  <Hironori.Fujii@sony.com>

        [Win][CMake] Use add_custom_command to copy each forwarding header files
        https://bugs.webkit.org/show_bug.cgi?id=180921

        Reviewed by Brent Fulgham.

        * PlatformWin.cmake: Use WEBKIT_MAKE_FORWARDING_HEADERS.

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

        Assertion used to determine if something is an async generator is wrong
        https://bugs.webkit.org/show_bug.cgi?id=181168
        <rdar://problem/35640560>

        Reviewed by Yusuke Suzuki.

        Previous assertions were doing a get on the base value for @@asyncIterator.
        This symbol is defined on AsyncGeneratorPrototype. The base value may change
        its prototype, but it's still an async generator as far as our system is
        concerned. This patch updates the assertion to check for a private property
        on the base value.

        * builtins/AsyncGeneratorPrototype.js:
        (globalPrivate.asyncGeneratorReject):
        (globalPrivate.asyncGeneratorResolve):
        (globalPrivate.asyncGeneratorResumeNext):

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

        Build fix after r226299 (3)
        https://bugs.webkit.org/show_bug.cgi?id=181160

        Unreviewed build fix.

        * API/tests/TypedArrayCTest.cpp: fix typo in header name.

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

        Build fix after r226299 (2)
        https://bugs.webkit.org/show_bug.cgi?id=181160

        Unreviewed build fix.

        * API/tests/TypedArrayCTest.cpp: Add missing header include.

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

        Build fix after r226299
        https://bugs.webkit.org/show_bug.cgi?id=181160

        Unreviewed build fix.

        * API/tests/TypedArrayCTest.cpp:
        (assertEqualsAsNumber): Disambiguate usage of isnan.

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

        REGRESSION(r225769): Build error with constexpr std::max // std::min in libdstdc++4
        https://bugs.webkit.org/show_bug.cgi?id=181160

        Reviewed by Myles C. Maxfield.

        Disambiguate usage of min and max (Use the version from stdlib).

        * runtime/JSArray.cpp:
        (JSC::JSArray::unshiftCountSlowCase):
        (JSC::JSArray::setLengthWithArrayStorage):
        (JSC::JSArray::shiftCountWithArrayStorage):
        (JSC::JSArray::fillArgList):
        (JSC::JSArray::copyToArguments):

2017-12-27  Zan Dobersek  <zdobersek@igalia.com>

        REGRESSION(r225913): about 30 JSC test failures on ARMv7
        https://bugs.webkit.org/show_bug.cgi?id=181162

        Reviewed by Michael Catanzaro.

        Fast case in DFG::SpeculativeJIT::compileArraySlice() was enabled in
        r225913 on all but 32-bit x86 platform. Other 32-bit platforms have the
        same lack of GP registers, so the conditional is changed here to only
        enable this optimization explicitly on ARM64 and x86-64.

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

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

        [JSC] Remove std::chrono completely
        https://bugs.webkit.org/show_bug.cgi?id=181165

        Reviewed by Konstantin Tokarev.

        This patch removes std::chrono use completely from JSC.

        * API/JSContextRef.cpp:
        (JSContextGroupSetExecutionTimeLimit):
        * API/tests/ExecutionTimeLimitTest.cpp:
        (currentCPUTimeAsJSFunctionCallback):
        (testExecutionTimeLimit):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        (JSC::timeToLive):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::timeSinceCreation):
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::SamplingProfiler):
        (JSC::SamplingProfiler::timerLoop):
        (JSC::SamplingProfiler::takeSample):
        (JSC::SamplingProfiler::reportTopFunctions):
        (JSC::SamplingProfiler::reportTopBytecodes):
        * runtime/SamplingProfiler.h:
        (JSC::SamplingProfiler::setTimingInterval):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/Watchdog.cpp:
        (JSC::Watchdog::Watchdog):
        (JSC::Watchdog::setTimeLimit):
        (JSC::Watchdog::shouldTerminate):
        (JSC::Watchdog::startTimer):
        (JSC::currentWallClockTime): Deleted.
        * runtime/Watchdog.h:

2017-12-26  Zan Dobersek  <zdobersek@igalia.com>

        REGRESSION(r226269): 60 JSC test failures on ARMv7
        https://bugs.webkit.org/show_bug.cgi?id=181163

        Reviewed by Yusuke Suzuki.

        In r226269, DFG::SpeculativeJIT::compile() changed behavior for the
        GetDirectPname operation on non-x86 platforms, switching to using
        GPRFlushedCallResult registers for the payload and tag pair of the
        return value (through the JSValueRegsFlushedCallResult struct). This
        tripped about 60 test cases on ARMv7.

        As before this change, GPRTemporary registers should be used, but this
        can now be done through a JSValueRegsTemporary object.

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

2017-12-22  Caio Lima  <ticaiolima@gmail.com>

        [JSC] IntlCollator and IntlNumberFormat has static fields with same name
        https://bugs.webkit.org/show_bug.cgi?id=181128

        Reviewed by Yusuke Suzuki.

        Minor fixes into IntlNumberFormat::initializeNumberFormat and
        IntlCollator::initializeCollator that makes JSC unified sources
        compile. These files were generating compilation error when placed at
        the same UnifiedSource.cpp, because they had static variables with same name.

        * runtime/IntlCollator.cpp:
        (JSC::IntlCollator::initializeCollator):
        * runtime/IntlNumberFormat.cpp:
        (JSC::IntlNumberFormat::initializeNumberFormat):

2017-12-22  Michael Catanzaro  <mcatanzaro@igalia.com>

        generate_offset_extractor.rb should not print to stderr by default
        https://bugs.webkit.org/show_bug.cgi?id=181133

        Reviewed by Mark Lam.

        Remove unneeded print output.

        * offlineasm/generate_offset_extractor.rb:

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

        [DFG] Cleaning up and unifying 32bit code more
        https://bugs.webkit.org/show_bug.cgi?id=181124

        Reviewed by Mark Lam.

        This patch unifies DFG 32bit code into 64bit code more. In this patch, we move RegExp DFG nodes
        from 32bit / 64bit code to the common code. We change some RegExp operations to returning JSCell*
        instead of EncodedJSValue. This simplifies DFG implementation.

        And we also move HasGenericProperty since we now have JSValueRegsFlushedCallResult. ToPrimive,
        LogShadowChickenPrologue, and LogShadowChickenTail are almost the same in 32bit and 64bit.
        Thus, it is unified easily.

        And we also move some GPRFlushedCallResult from the original places to the places just after
        `flushRegisters()` not to spill unnecessary registers.

        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileRegExpExec):
        (JSC::DFG::SpeculativeJIT::compileRegExpTest):
        (JSC::DFG::SpeculativeJIT::compileStringReplace):
        (JSC::DFG::SpeculativeJIT::compileHasGenericProperty):
        (JSC::DFG::SpeculativeJIT::compileToPrimitive):
        (JSC::DFG::SpeculativeJIT::compileLogShadowChickenPrologue):
        (JSC::DFG::SpeculativeJIT::compileLogShadowChickenTail):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::speculateDoubleRepAnyInt):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileStringReplace):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * runtime/StringPrototype.cpp:
        (JSC::jsSpliceSubstrings):
        (JSC::jsSpliceSubstringsWithSeparators):
        (JSC::removeUsingRegExpSearch):
        (JSC::replaceUsingRegExpSearch):
        (JSC::operationStringProtoFuncReplaceRegExpEmptyStr):
        (JSC::operationStringProtoFuncReplaceRegExpString):
        (JSC::replaceUsingStringSearch):
        (JSC::replace):
        (JSC::stringProtoFuncReplaceUsingRegExp):
        (JSC::stringProtoFuncReplaceUsingStringSearch):
        (JSC::operationStringProtoFuncReplaceGeneric):
        * runtime/StringPrototype.h:

2017-12-22  Michael Catanzaro  <mcatanzaro@igalia.com>

        [GTK] Duplicated symbols in libjavascriptcoregtk and libwebkit2gtk can cause crashes in production builds
        https://bugs.webkit.org/show_bug.cgi?id=179914
        <rdar://problem/36196039>

        Unreviewed.

        * PlatformGTK.cmake:

2017-12-22  Michael Catanzaro  <mcatanzaro@igalia.com>

        [GTK] Duplicated symbols in libjavascriptcoregtk and libwebkit2gtk can cause crashes in production builds
        https://bugs.webkit.org/show_bug.cgi?id=179914

        Reviewed by Carlos Garcia Campos.

        Add a new JavaScriptCoreGTK build target, to build JSC as a shared library. Link the
        original JavaScriptCore build target, which is now a static library, to it. Use
        --whole-archive to prevent all the JavaScriptCore symbols from being dropped, since none are
        used directly by JavaScriptCoreGTK.

        The installed libjavascriptcoregtk-4.0 now corresponds to the JavaScriptCoreGTK target,
        instead of the JavaScriptCore target. There is almost no difference on the installed system,
        except that we now use a version script when linking, to hide private symbols, since they're
        no longer needed by libwebkit2gtk-4.0.so.

        Also, move the symbols map here.

        * PlatformGTK.cmake:
        * javascriptcoregtk-symbols.map: Added.

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

        [DFG] Unify bunch of DFG 32bit code into 64bit code
        https://bugs.webkit.org/show_bug.cgi?id=181083

        Reviewed by Mark Lam.

        There are bunch of the completely same code in 32bit and 64bit DFG.
        This is largely because of the old DFG code. At that time, we do not
        have enough abstraction to describe them in one code. But now, we have
        JSValueRegs, JSValueRegsTemporary etc. They allow DFG to write 32bit and
        64bit handling in one code.

        This patch unifies easy ones. This is nice since basically 32bit code is
        a bit old and not maintained so much compared to 64bit. If we can drop
        32bit specific code as much as possible, it would be nice. Furthermore,
        we can find various mistakes in 32bit: For example, NewObject does not have
        mutatorFence in 32bit while 64bit has it. This unification is a chance
        to fix miscellaneous bugs in 32bit while reducing maintenance burden.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize):
        (JSC::DFG::SpeculativeJIT::compileGetEnumerableLength):
        (JSC::DFG::SpeculativeJIT::compileToIndexString):
        (JSC::DFG::SpeculativeJIT::compilePutByIdWithThis):
        (JSC::DFG::SpeculativeJIT::compileHasStructureProperty):
        (JSC::DFG::SpeculativeJIT::compileGetPropertyEnumerator):
        (JSC::DFG::SpeculativeJIT::compileGetEnumeratorPname):
        (JSC::DFG::SpeculativeJIT::compileGetGetter):
        (JSC::DFG::SpeculativeJIT::compileGetSetter):
        (JSC::DFG::SpeculativeJIT::compileGetCallee):
        (JSC::DFG::SpeculativeJIT::compileGetArgumentCountIncludingThis):
        (JSC::DFG::SpeculativeJIT::compileStrCat):
        (JSC::DFG::SpeculativeJIT::compileNewArrayWithSize):
        (JSC::DFG::SpeculativeJIT::compileNewTypedArray):
        (JSC::DFG::SpeculativeJIT::compileCreateThis):
        (JSC::DFG::SpeculativeJIT::compileNewObject):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

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

        [DFG] Add JSValueRegsFlushedCallResult
        https://bugs.webkit.org/show_bug.cgi?id=181075

        Reviewed by Mark Lam.

        Add JSValueRegsFlushedCallResult, which is appropriate for the JSValueRegs result
        of the function call after flushing. We can remove bunch of `#if USE(JSVALUE32_64)`
        code and simplify them.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileFromCharCode):
        (JSC::DFG::SpeculativeJIT::compileGetByValForObjectWithString):
        (JSC::DFG::SpeculativeJIT::compileGetByValForObjectWithSymbol):
        (JSC::DFG::SpeculativeJIT::compileParseInt):
        (JSC::DFG::SpeculativeJIT::emitUntypedBitOp):
        (JSC::DFG::SpeculativeJIT::emitUntypedRightShiftBitOp):
        (JSC::DFG::SpeculativeJIT::compileValueAdd):
        (JSC::DFG::SpeculativeJIT::compileArithMul):
        (JSC::DFG::SpeculativeJIT::compileArithDiv):
        (JSC::DFG::SpeculativeJIT::compileArithRounding):
        (JSC::DFG::SpeculativeJIT::compileResolveScopeForHoistingFuncDeclInEval):
        (JSC::DFG::SpeculativeJIT::compileGetDynamicVar):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        (JSC::DFG::JSValueRegsFlushedCallResult::JSValueRegsFlushedCallResult):
        (JSC::DFG::JSValueRegsFlushedCallResult::regs):

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

        lowering get_by_val to GetById inside bytecode parser should check for BadType exit kind
        https://bugs.webkit.org/show_bug.cgi?id=181112

        Reviewed by Mark Lam.

        The React subtest in Speedometer has a get_by_val it always converts
        into a GetById in the DFG. This GetById always exits because of the incoming
        identifier is a rope. This patch fixes this infinite exit loop
        by only doing this transformation if we haven't exited due to BadType.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):

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

        Add WTF::PoisonedUniquePtr to replace std::unique_ptr when poisoning is desired.
        https://bugs.webkit.org/show_bug.cgi?id=181062
        <rdar://problem/36167040>

        Reviewed by Chris Dumez.

        * runtime/JSCPoisonedPtr.cpp:
        - Added a needed #include.

2017-12-21  Jeremy Jones  <jeremyj@apple.com>

        Update FULLSCREEN_API feature defines.
        https://bugs.webkit.org/show_bug.cgi?id=181015

        Reviewed by Tim Horton.

        Change enabled iphone sdk for FULLSCREEN_API.

        * Configurations/FeatureDefines.xcconfig:

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

        [JSC] Do not check isValid() in op_new_regexp
        https://bugs.webkit.org/show_bug.cgi?id=180970

        Reviewed by Saam Barati.

        We should not check `isValid()` inside op_new_regexp.
        This simplifies the semantics of NewRegexp node in DFG.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::RegExpNode::emitBytecode):
        * dfg/DFGMayExit.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNewRegexp):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp):
        * jit/JITOperations.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):

2017-12-20  Saam Barati  <sbarati@apple.com>

        GetPropertyEnumerator in DFG/FTL should not unconditionally speculate cell
        https://bugs.webkit.org/show_bug.cgi?id=181054

        Reviewed by Mark Lam.

        Speedometer's react subtest has a function that is in an OSR exit loop because
        we used to unconditionally speculate cell for the operand to GetPropertyEnumerator.
        This fix doesn't seem to speed up Speedometer at all, but it's good hygiene 
        for our compiler to not have this pathology. This patch adds a generic
        GetPropertyEnumerator to prevent the exit loop.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileGetPropertyEnumerator):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:

2017-12-20  Daniel Bates  <dabates@apple.com>

        Remove Alternative Presentation Button
        https://bugs.webkit.org/show_bug.cgi?id=180500
        <rdar://problem/35891047>

        Reviewed by Simon Fraser.

        We no longer need the alternative presentation button.

        * Configurations/FeatureDefines.xcconfig:

2017-12-19  Saam Barati  <sbarati@apple.com>

        We forgot to do index masking for in bounds int32 arrays in the FTL
        https://bugs.webkit.org/show_bug.cgi?id=180987

        Reviewed by Keith Miller.

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

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

        [DFG][FTL] NewRegexp shoud be fast
        https://bugs.webkit.org/show_bug.cgi?id=180960

        Reviewed by Michael Saboff.

        When we encounter RegExp literal like /AAA/g, we need to create a RegExp object.
        Typical idiom like `string.match(/regexp/)` requires RegExp object creation
        every time.

        As a first step, this patch accelerates RegExp object creation by handling it
        in DFG and FTL. In a subsequent patch, we would like to introduce PhantomNewRegexp
        to remove unnecessary RegExp object creations.

        This patch improves SixSpeed/regex-u.{es5,es6}.

                                     baseline                  patched

            regex-u.es5          69.6759+-3.1951     ^     53.1425+-2.0292        ^ definitely 1.3111x faster
            regex-u.es6         129.5413+-5.4437     ^    107.2105+-7.7775        ^ definitely 1.2083x faster

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNewRegexp):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp):
        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_new_regexp):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/RegExpObject.h:
        (JSC::RegExpObject::offsetOfRegExp):
        (JSC::RegExpObject::allocationSize):

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

        Unreviewed, include YarrErrorCode.h in Yarr.h
        https://bugs.webkit.org/show_bug.cgi?id=180966

        * yarr/Yarr.h:

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

        [YARR] Yarr should return ErrorCode instead of error messages (const char*)
        https://bugs.webkit.org/show_bug.cgi?id=180966

        Reviewed by Mark Lam.

        Currently, Yarr returns const char*` for an error message when needed.
        But it is easier to handle error status if Yarr returns an error code
        instead of `const char*`.

        In this patch, we introduce Yarr::ErrorCode. Yarr returns it instead of
        `const char*`. `std::expected<void, Yarr::ErrorCode>` would be appropriate
        for the Yarr API interface. But it requires substantial changes removing
        ErrorCode::NoError, so this patch just uses the current Yarr::ErrorCode as
        a first step.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * inspector/ContentSearchUtilities.cpp:
        (Inspector::ContentSearchUtilities::findMagicComment):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createRegExp):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createRegExp):
        * runtime/RegExp.cpp:
        (JSC::RegExp::RegExp):
        (JSC::RegExp::byteCodeCompileIfNecessary):
        (JSC::RegExp::compile):
        (JSC::RegExp::compileMatchOnly):
        * runtime/RegExp.h:
        * yarr/RegularExpression.cpp:
        (JSC::Yarr::RegularExpression::Private::Private):
        (JSC::Yarr::RegularExpression::Private::compile):
        * yarr/YarrErrorCode.cpp: Added.
        (JSC::Yarr::errorMessage):
        * yarr/YarrErrorCode.h: Copied from Source/JavaScriptCore/yarr/YarrSyntaxChecker.h.
        (JSC::Yarr::hasError):
        * yarr/YarrParser.h:
        (JSC::Yarr::Parser::CharacterClassParserDelegate::CharacterClassParserDelegate):
        (JSC::Yarr::Parser::CharacterClassParserDelegate::atomPatternCharacter):
        (JSC::Yarr::Parser::Parser):
        (JSC::Yarr::Parser::isIdentityEscapeAnError):
        (JSC::Yarr::Parser::parseEscape):
        (JSC::Yarr::Parser::parseCharacterClass):
        (JSC::Yarr::Parser::parseParenthesesBegin):
        (JSC::Yarr::Parser::parseParenthesesEnd):
        (JSC::Yarr::Parser::parseQuantifier):
        (JSC::Yarr::Parser::parseTokens):
        (JSC::Yarr::Parser::parse):
        (JSC::Yarr::Parser::tryConsumeUnicodeEscape):
        (JSC::Yarr::Parser::tryConsumeUnicodePropertyExpression):
        (JSC::Yarr::parse):
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::YarrPatternConstructor::YarrPatternConstructor):
        (JSC::Yarr::YarrPatternConstructor::setupDisjunctionOffsets):
        (JSC::Yarr::YarrPatternConstructor::setupOffsets):
        (JSC::Yarr::YarrPattern::compile):
        (JSC::Yarr::YarrPattern::YarrPattern):
        (JSC::Yarr::YarrPattern::errorMessage): Deleted.
        * yarr/YarrPattern.h:
        (JSC::Yarr::YarrPattern::reset):
        * yarr/YarrSyntaxChecker.cpp:
        (JSC::Yarr::checkSyntax):
        * yarr/YarrSyntaxChecker.h:

2017-12-18  Saam Barati  <sbarati@apple.com>

        Follow up to bug#179762. Fix PreciseLocalClobberize to handle Spread/PhantomSpread(PhantomNewArrayBuffer)

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

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

        Vector index masking
        https://bugs.webkit.org/show_bug.cgi?id=180909

        Reviewed by Keith Miller.
        
        Adopt index masking for strings.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetCharCodeAt):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
        (JSC::FTL::DFG::LowerDFGToB3::compileStringCharCodeAt):
        * jit/ThunkGenerators.cpp:
        (JSC::stringCharLoad):

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

        [FTL] NewArrayBuffer should be sinked if it is only used for spreading
        https://bugs.webkit.org/show_bug.cgi?id=179762

        Reviewed by Saam Barati.

        This patch extends arguments elimination phase to accept NewArrayBuffer.
        We can convert NewArrayBuffer to PhantomNewArrayBuffer if it is only
        used by spreading nodes.

        This improves SixSpeed spread.es6 by 3.5x.

            spread.es6           79.1496+-3.5665     ^     23.6204+-1.8526        ^ definitely 3.3509x faster

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasNewArrayBufferData):
        (JSC::DFG::Node::hasVectorLengthHint):
        (JSC::DFG::Node::hasIndexingType):
        (JSC::DFG::Node::indexingType):
        (JSC::DFG::Node::hasCellOperand):
        (JSC::DFG::Node::isPhantomAllocation):
        * dfg/DFGNodeType.h:
        * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
        (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGPromotedHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGPromotedHeapLocation.h:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGValidate.cpp:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread):
        (JSC::FTL::DFG::LowerDFGToB3::compileSpread):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
        (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs):
        (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargsWithSpread):
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationPopulateObjectInOSR):
        (JSC::FTL::operationMaterializeObjectInOSR):

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

        [JSC] Use IsoSpace for JSWeakMap and JSWeakSet to use finalizeUnconditionally
        https://bugs.webkit.org/show_bug.cgi?id=180916

        Reviewed by Darin Adler.

        This patch drops UnconditionalFinalizer for JSWeakMap and JSWeakSetby using IsoSpace.
        Since these cells always require calling finalizeUnconditionally, we do not need to
        track cells by using IsoCellSet.

        Currently we still have WeakReferenceHarvester in JSWeakMap and JSWeakSet. We should
        avoid using a global linked-list for this in the future.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/Heap.cpp:
        (JSC::Heap::finalizeUnconditionalFinalizersInIsoSubspace):
        (JSC::Heap::finalizeUnconditionalFinalizers):
        * heap/Heap.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        * runtime/WeakMapImpl.cpp:
        (JSC::WeakMapImpl<WeakMapBucket>::visitChildren):
        (JSC::WeakMapImpl<WeakMapBucket>::finalizeUnconditionally): Deleted.
        * runtime/WeakMapImpl.h:
        (JSC::WeakMapImpl::isWeakMap):
        (JSC::WeakMapImpl::isWeakSet):
        (JSC::WeakMapImpl::subspaceFor):
        * runtime/WeakMapImplInlines.h: Added.
        (JSC::WeakMapImpl<WeakMapBucket>::finalizeUnconditionally):

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

        Hollow out stub implementation of InspectorBackendDispatcher::sendResponse().
        https://bugs.webkit.org/show_bug.cgi?id=180901
        <rdar://problem/36087649>

        Reviewed by Darin Adler.

        We only need to keep a deprecated implementation of InspectorValues,
        InspectorObjects, and InspectorBackendDispatcher::sendResponse() around so that
        older versions of Safari can link against and run with a build of the latest code
        in WebKit trunk. Older versions of System Safari used InspectorValues (via
        WebInspector.framework) for two things:

        1. Augmented JSContexts SPIs (via WebInspector.framework).
        2. maybe WebDriver.

        Neither of these are used when running SafariForWebKitDevelopment.  Since neither
        are used, we can stub out the symbols (InspectorValues, InspectorObjects,
        InspectorBackendDispatcher::sendResponse) to do nothing, and
        SafariForWebKitDevelopment will still continue to launch with trunk WebKit, and
        run without any observable bad behavior.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * SourcesCocoa.txt:
        * inspector/InspectorBackendDispatcher.cpp:
        * inspector/InspectorBackendDispatcher.h:
        * inspector/cocoa/DeprecatedInspectorValues.cpp:
        (Inspector::InspectorValue::null):
        (Inspector::InspectorValue::create):
        (Inspector::InspectorValue::asValue):
        (Inspector::InspectorValue::asObject):
        (Inspector::InspectorValue::asArray):
        (Inspector::InspectorValue::parseJSON):
        (Inspector::InspectorValue::toJSONString const):
        (Inspector::InspectorValue::asBoolean const):
        (Inspector::InspectorValue::asDouble const):
        (Inspector::InspectorValue::asInteger const):
        (Inspector::InspectorValue::asString const):
        (Inspector::InspectorValue::writeJSON const):
        (Inspector::InspectorValue::memoryCost const):
        (Inspector::InspectorObjectBase::openAccessors):
        (Inspector::InspectorObjectBase::memoryCost const):
        (Inspector::InspectorObjectBase::getBoolean const):
        (Inspector::InspectorObjectBase::getString const):
        (Inspector::InspectorObjectBase::getObject const):
        (Inspector::InspectorObjectBase::getArray const):
        (Inspector::InspectorObjectBase::getValue const):
        (Inspector::InspectorObjectBase::remove):
        (Inspector::InspectorObject::create):
        (Inspector::InspectorArrayBase::get const):
        (Inspector::InspectorArrayBase::memoryCost const):
        (Inspector::InspectorArray::create):
        (Inspector::BackendDispatcher::sendResponse):
        (Inspector::InspectorObjectBase::~InspectorObjectBase): Deleted.
        (Inspector::InspectorObjectBase::asObject): Deleted.
        (Inspector::InspectorObjectBase::writeJSON const): Deleted.
        (Inspector::InspectorObjectBase::InspectorObjectBase): Deleted.
        (Inspector::InspectorArrayBase::~InspectorArrayBase): Deleted.
        (Inspector::InspectorArrayBase::asArray): Deleted.
        (Inspector::InspectorArrayBase::writeJSON const): Deleted.
        (Inspector::InspectorArrayBase::InspectorArrayBase): Deleted.
        * inspector/cocoa/DeprecatedInspectorValues.h: Removed.

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

        [JSC][WebCore][CSSJIT] Remove VM reference in CSSJIT
        https://bugs.webkit.org/show_bug.cgi?id=180917

        Reviewed by Sam Weinig.

        We do not need to hold JIT flags in VM. We add
        static VM::{canUseJIT,canUseAssembler,canUseRegExpJIT} functions.

        * interpreter/AbstractPC.cpp:
        (JSC::AbstractPC::AbstractPC):
        * jit/JITThunks.cpp:
        (JSC::JITThunks::ctiNativeCall):
        (JSC::JITThunks::ctiNativeConstruct):
        (JSC::JITThunks::ctiNativeTailCall):
        (JSC::JITThunks::ctiNativeTailCallWithoutSavedTags):
        (JSC::JITThunks::ctiInternalFunctionCall):
        (JSC::JITThunks::ctiInternalFunctionConstruct):
        (JSC::JITThunks::hostFunctionStub):
        * llint/LLIntEntrypoint.cpp:
        (JSC::LLInt::setFunctionEntrypoint):
        (JSC::LLInt::setEvalEntrypoint):
        (JSC::LLInt::setProgramEntrypoint):
        (JSC::LLInt::setModuleProgramEntrypoint):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::shouldJIT):
        (JSC::LLInt::entryOSR):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/RegExp.cpp:
        (JSC::RegExp::compile):
        (JSC::RegExp::compileMatchOnly):
        * runtime/VM.cpp:
        (JSC::VM::canUseAssembler):
        (JSC::VM::canUseJIT):
        (JSC::VM::canUseRegExpJIT):
        (JSC::VM::VM):
        * runtime/VM.h:
        (JSC::VM::canUseJIT): Deleted.
        (JSC::VM::canUseRegExpJIT): Deleted.

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

        [JSC] Number of SlotVisitors can increase after setting up m_visitCounters
        https://bugs.webkit.org/show_bug.cgi?id=180906

        Reviewed by Filip Pizlo.

        The number of SlotVisitors can increase after setting up m_visitCounters.
        If it happens, our m_visitCounters misses the visit count of newly added
        SlotVisitors. It accidentally decides that constraints are converged.
        This leads to random assertion hits in Linux environment.

        In this patch, we compare the number of SlotVisitors in didVisitSomething().
        If the number of SlotVisitors is changed, we conservatively say we did
        visit something.

        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::numberOfSlotVisitors):
        * heap/MarkingConstraintSet.h:
        * heap/MarkingConstraintSolver.cpp:
        (JSC::MarkingConstraintSolver::didVisitSomething const):

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

        Indexing should only be computed when the new structure has an indexing header.
        https://bugs.webkit.org/show_bug.cgi?id=180895

        Reviewed by Saam Barati.

        If we don't have an indexing header then we point the butterfly
        sizeof(IndexingHeader) past the end of the butterfly. This makes
        the computation of the offset simpler since it doesn't depend on
        the indexing headeriness of the butterfly.

        * jit/JITOperations.cpp:
        * runtime/JSObject.cpp:
        (JSC::JSObject::createInitialUndecided):
        (JSC::JSObject::createInitialInt32):
        (JSC::JSObject::createInitialDouble):
        (JSC::JSObject::createInitialContiguous):
        (JSC::JSObject::createArrayStorage):
        (JSC::JSObject::convertUndecidedToArrayStorage):
        (JSC::JSObject::convertInt32ToArrayStorage):
        (JSC::JSObject::convertDoubleToArrayStorage):
        * runtime/JSObject.h:
        (JSC::JSObject::setButterfly):
        (JSC::JSObject::nukeStructureAndSetButterfly):
        * runtime/JSObjectInlines.h:
        (JSC::JSObject::prepareToPutDirectWithoutTransition):
        (JSC::JSObject::putDirectInternal):

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

        Unreviewed, rolling out r225941.

        This change introduced LayoutTest crashes and assertion
        failures.

        Reverted changeset:

        "Web Inspector: replace HTMLCanvasElement with
        CanvasRenderingContext for instrumentation logic"
        https://bugs.webkit.org/show_bug.cgi?id=180770
        https://trac.webkit.org/changeset/225941

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

        Unreviewed, 32bit JSEmpty is not nullptr + CellTag
        https://bugs.webkit.org/show_bug.cgi?id=180804

        Add 32bit path for WeakMapGet.

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

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

        The CleanUp after LICM is erroneously removing a Check
        https://bugs.webkit.org/show_bug.cgi?id=180852
        <rdar://problem/36063494>

        Reviewed by Filip Pizlo.

        There was a bug where CleanUp phase relied on isProved() bits and LICM
        changed them in an invalid way. The bug is as follows:
        
        We have two loops, L1 and L2, and two preheaders, P1 and P2. L2 is nested
        inside of L1. We have a Check inside a node inside L1, say in basic block BB,
        and that Check dominates all of L2. This is also a hoisting candidate, so we
        hoist it outside of L1 and put it inside P1. Then, when we run AI, we look at
        the preheader for each loop inside L1, so P1 and P2. When considering P2,
        we execute the Check. Inside P2, before any hoisting is done, this Check
        is dead code, because BB dominates P2. When we use AI to "execute" the
        Check, it'll set its proof status to proved. This is because inside P2,
        in the program before LICM runs, the Check is indeed proven at P2. But
        it is not proven inside P1. This "execute" call will set our proof status
        for the node inside *P1*, hence, we crash.
        
        The fix here is to make LICM precise when updating the ProofStatus of an edge.
        It can trust the AI state at the preheader it hoists the node to, but it can't
        trust the state when executing effects inside inner loops's preheaders.

        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):

2017-12-14  David Kilzer  <ddkilzer@apple.com>

        Enable -Wstrict-prototypes for WebKit
        <https://webkit.org/b/180757>
        <rdar://problem/36024132>

        Rubber-stamped by Joseph Pecoraro.

        * API/tests/CompareAndSwapTest.h:
        (testCompareAndSwap): Add 'void' to C function declaration.
        * API/tests/ExecutionTimeLimitTest.h:
        (testExecutionTimeLimit): Ditto.
        * API/tests/FunctionOverridesTest.h:
        (testFunctionOverrides): Ditto.
        * API/tests/GlobalContextWithFinalizerTest.h:
        (testGlobalContextWithFinalizer): Ditto.
        * API/tests/JSONParseTest.h:
        (testJSONParse): Ditto.
        * API/tests/MultithreadedMultiVMExecutionTest.h:
        (startMultithreadedMultiVMExecutionTest): Ditto.
        (finalizeMultithreadedMultiVMExecutionTest): Ditto.
        * API/tests/PingPongStackOverflowTest.h:
        (testPingPongStackOverflow): Ditto.
        * Configurations/Base.xcconfig:
        (CLANG_WARN_STRICT_PROTOTYPES): Add. Set to YES.

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

        [DFG] Reduce register pressure of WeakMapGet to be used for 32bit
        https://bugs.webkit.org/show_bug.cgi?id=180804

        Reviewed by Saam Barati.

        This fixes 32bit failures of JSC by reducing register pressure of WeakMapGet.

        * dfg/DFGRegisterBank.h:
        (JSC::DFG::RegisterBank::lockedCount const):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileWeakMapGet):

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

        Unreviewed, forgot to add { }

        * runtime/JSObject.h:
        (JSC::JSObject::setButterfly):
        (JSC::JSObject::nukeStructureAndSetButterfly):

2017-12-14  Devin Rousso  <webkit@devinrousso.com>

        Web Inspector: replace HTMLCanvasElement with CanvasRenderingContext for instrumentation logic
        https://bugs.webkit.org/show_bug.cgi?id=180770

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/Canvas.json:

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

        Fix assertion in JSObject's structure setting methods
        https://bugs.webkit.org/show_bug.cgi?id=180840

        Reviewed by Mark Lam.

        I forgot that when Typed Arrays have non-indexed properties
        added to them, they call the generic code. The generic code
        in turn calls the regular structure setting methods. Thus,
        these assertions were invalid and we should just avoid setting
        the indexing mask if we have a Typed Array.

        * runtime/JSObject.h:
        (JSC::JSObject::setButterfly):
        (JSC::JSObject::nukeStructureAndSetButterfly):

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

        REGRESSION (r225695): Repro crash on yahoo login page
        https://bugs.webkit.org/show_bug.cgi?id=180761

        Reviewed by JF Bastien.

        Relanding r225695 with a fix.

        The fix is that we need to save the return address for a parentheses in
        the ParenContext because it is actually used by any immediately contained
        alternatives.

        Also did a little refactoring, changing occurances of PatternContext to
        ParenContext since that is the name of the structure.

        * runtime/RegExp.cpp:
        (JSC::byteCodeCompilePattern):
        (JSC::RegExp::byteCodeCompileIfNecessary):
        (JSC::RegExp::compile):
        (JSC::RegExp::compileMatchOnly):
        * runtime/RegExp.h:
        * runtime/RegExpInlines.h:
        (JSC::RegExp::matchInline):
        * testRegExp.cpp:
        (parseRegExpLine):
        (runFromFiles):
        * yarr/Yarr.h:
        * yarr/YarrInterpreter.cpp:
        (JSC::Yarr::ByteCompiler::compile):
        (JSC::Yarr::ByteCompiler::dumpDisjunction):
        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::ParenContextSizes::ParenContextSizes):
        (JSC::Yarr::YarrGenerator::ParenContextSizes::numSubpatterns):
        (JSC::Yarr::YarrGenerator::ParenContextSizes::frameSlots):
        (JSC::Yarr::YarrGenerator::ParenContext::sizeFor):
        (JSC::Yarr::YarrGenerator::ParenContext::nextOffset):
        (JSC::Yarr::YarrGenerator::ParenContext::beginOffset):
        (JSC::Yarr::YarrGenerator::ParenContext::matchAmountOffset):
        (JSC::Yarr::YarrGenerator::ParenContext::returnAddressOffset):
        (JSC::Yarr::YarrGenerator::ParenContext::subpatternOffset):
        (JSC::Yarr::YarrGenerator::ParenContext::savedFrameOffset):
        (JSC::Yarr::YarrGenerator::initParenContextFreeList):
        (JSC::Yarr::YarrGenerator::allocateParenContext):
        (JSC::Yarr::YarrGenerator::freeParenContext):
        (JSC::Yarr::YarrGenerator::saveParenContext):
        (JSC::Yarr::YarrGenerator::restoreParenContext):
        (JSC::Yarr::YarrGenerator::tryReadUnicodeCharImpl):
        (JSC::Yarr::YarrGenerator::storeToFrame):
        (JSC::Yarr::YarrGenerator::generateJITFailReturn):
        (JSC::Yarr::YarrGenerator::clearMatches):
        (JSC::Yarr::YarrGenerator::generate):
        (JSC::Yarr::YarrGenerator::backtrack):
        (JSC::Yarr::YarrGenerator::opCompileParenthesesSubpattern):
        (JSC::Yarr::YarrGenerator::generateEnter):
        (JSC::Yarr::YarrGenerator::generateReturn):
        (JSC::Yarr::YarrGenerator::YarrGenerator):
        (JSC::Yarr::YarrGenerator::compile):
        * yarr/YarrJIT.h:
        (JSC::Yarr::YarrCodeBlock::execute):
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::indentForNestingLevel):
        (JSC::Yarr::dumpUChar32):
        (JSC::Yarr::dumpCharacterClass):
        (JSC::Yarr::PatternTerm::dump):
        (JSC::Yarr::YarrPattern::dumpPattern):
        * yarr/YarrPattern.h:
        (JSC::Yarr::PatternTerm::containsAnyCaptures):
        (JSC::Yarr::BackTrackInfoParenthesesOnce::returnAddressIndex):
        (JSC::Yarr::BackTrackInfoParentheses::beginIndex):
        (JSC::Yarr::BackTrackInfoParentheses::returnAddressIndex):
        (JSC::Yarr::BackTrackInfoParentheses::matchAmountIndex):
        (JSC::Yarr::BackTrackInfoParentheses::parenContextHeadIndex):
        (JSC::Yarr::BackTrackInfoAlternative::offsetIndex): Deleted.

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

        JSObjects should have a mask for loading indexed properties
        https://bugs.webkit.org/show_bug.cgi?id=180768

        Reviewed by Mark Lam.

        This patch adds a new member to JSObject that holds an indexing
        mask.  The indexing mask is bitwise anded with the index used to
        load a property.  If for whatever reason an attacker is able to
        clobber the vectorLength of our butterfly they still won't be able
        to read substantially past the end of the buttefly. For
        performance reasons we don't use the indexing masking for
        TypedArrays. Since TypedArrays are already gigacaged the risk of
        wild reads is still restricted.

        This patch is a <1% regression on Speedometer and ~3% regression
        on JetStream in my testing.

        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::urshiftPtr):
        * bytecode/AccessCase.cpp:
        (JSC::AccessCase::generateImpl):
        * dfg/DFGAbstractHeap.h:
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
        (JSC::DFG::SpeculativeJIT::compileDoublePutByVal):
        (JSC::DFG::SpeculativeJIT::compileNewFunctionCommon):
        (JSC::DFG::SpeculativeJIT::compileCreateActivation):
        (JSC::DFG::SpeculativeJIT::compileCreateDirectArguments):
        (JSC::DFG::SpeculativeJIT::compileArraySlice):
        (JSC::DFG::SpeculativeJIT::compileNukeStructureAndSetButterfly):
        (JSC::DFG::SpeculativeJIT::compileNewStringObject):
        (JSC::DFG::SpeculativeJIT::compileNewTypedArray):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::emitAllocateJSObject):
        (JSC::DFG::SpeculativeJIT::emitAllocateJSObjectWithKnownSize):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
        * ftl/FTLAbstractHeap.cpp:
        (JSC::FTL::IndexedAbstractHeap::baseIndex):
        * ftl/FTLAbstractHeap.h:
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileAtomicsReadModifyWrite):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateActivation):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateDirectArguments):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewStringObject):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
        (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
        (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation):
        (JSC::FTL::DFG::LowerDFGToB3::maskedIndex):
        (JSC::FTL::DFG::LowerDFGToB3::computeButterflyIndexingMask):
        (JSC::FTL::DFG::LowerDFGToB3::allocateObject):
        (JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedObject):
        (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
        (JSC::FTL::DFG::LowerDFGToB3::pointerIntoTypedArray):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::baseIndex):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitComputeButterflyIndexingMask):
        (JSC::AssemblyHelpers::nukeStructureAndStoreButterfly):
        (JSC::AssemblyHelpers::emitAllocateJSObject):
        (JSC::AssemblyHelpers::emitAllocateJSObjectWithKnownSize):
        (JSC::AssemblyHelpers::emitAllocateVariableSizedJSObject):
        (JSC::AssemblyHelpers::emitAllocateDestructibleObject):
        (JSC::AssemblyHelpers::storeButterfly): Deleted.
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_new_object):
        (JSC::JIT::emit_op_create_this):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_new_object):
        (JSC::JIT::emit_op_create_this):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitDoubleLoad):
        (JSC::JIT::emitContiguousLoad):
        (JSC::JIT::emitArrayStorageLoad):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/ArrayStorage.h:
        (JSC::ArrayStorage::availableVectorLength):
        * runtime/Butterfly.h:
        (JSC::ContiguousData::ContiguousData):
        (JSC::ContiguousData::at const):
        (JSC::ContiguousData::at):
        (JSC::Butterfly::publicLength const):
        (JSC::Butterfly::vectorLength const):
        (JSC::Butterfly::computeIndexingMaskForVectorLength):
        (JSC::Butterfly::computeIndexingMask):
        (JSC::Butterfly::contiguousInt32):
        (JSC::ContiguousData::operator[] const): Deleted.
        (JSC::ContiguousData::operator[]): Deleted.
        (JSC::Butterfly::publicLength): Deleted.
        (JSC::Butterfly::vectorLength): Deleted.
        * runtime/ButterflyInlines.h:
        (JSC::ContiguousData<T>::at const):
        (JSC::ContiguousData<T>::at):
        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::createEmpty):
        * runtime/JSArray.cpp:
        (JSC::JSArray::tryCreateUninitializedRestricted):
        (JSC::JSArray::appendMemcpy):
        (JSC::JSArray::setLength):
        (JSC::JSArray::pop):
        (JSC::JSArray::fastSlice):
        (JSC::JSArray::shiftCountWithArrayStorage):
        (JSC::JSArray::shiftCountWithAnyIndexingType):
        (JSC::JSArray::unshiftCountWithAnyIndexingType):
        (JSC::JSArray::fillArgList):
        (JSC::JSArray::copyToArguments):
        * runtime/JSArrayBufferView.cpp:
        (JSC::JSArrayBufferView::JSArrayBufferView):
        * runtime/JSArrayInlines.h:
        (JSC::JSArray::pushInline):
        * runtime/JSFixedArray.h:
        (JSC::JSFixedArray::createFromArray):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::slowDownAndWasteMemory):
        * runtime/JSObject.cpp:
        (JSC::JSObject::getOwnPropertySlotByIndex):
        (JSC::JSObject::putByIndex):
        (JSC::JSObject::createInitialInt32):
        (JSC::JSObject::createInitialDouble):
        (JSC::JSObject::createInitialContiguous):
        (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::createInitialForValueAndSet):
        (JSC::JSObject::deletePropertyByIndex):
        (JSC::JSObject::getOwnPropertyNames):
        (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes):
        (JSC::JSObject::countElements):
        (JSC::JSObject::ensureLengthSlow):
        (JSC::JSObject::reallocateAndShrinkButterfly):
        (JSC::JSObject::getEnumerableLength):
        * runtime/JSObject.h:
        (JSC::JSObject::canGetIndexQuickly):
        (JSC::JSObject::getIndexQuickly):
        (JSC::JSObject::tryGetIndexQuickly const):
        (JSC::JSObject::setIndexQuickly):
        (JSC::JSObject::initializeIndex):
        (JSC::JSObject::initializeIndexWithoutBarrier):
        (JSC::JSObject::butterflyIndexingMaskOffset):
        (JSC::JSObject::butterflyIndexingMask const):
        (JSC::JSObject::setButterflyWithIndexingMask):
        (JSC::JSObject::setButterfly):
        (JSC::JSObject::nukeStructureAndSetButterfly):
        (JSC::JSObject::JSObject):
        * runtime/RegExpMatchesArray.h:
        (JSC::tryCreateUninitializedRegExpMatchesArray):
        * runtime/Structure.cpp:
        (JSC::Structure::flattenDictionaryStructure):

2017-12-14  David Kilzer  <ddkilzer@apple.com>

        REGRESSION (r225799/r225887): Remove duplicate entries for JSCPoisonedPtr.h in Xcode project

        Fixes the following warning during builds:

            Warning: Multiple build commands for output file WebKitBuild/Release/JavaScriptCore.framework/Versions/A/PrivateHeaders/JSCPoisonedPtr.h

        * JavaScriptCore.xcodeproj/project.pbxproj: Remove duplicate
        entries for JSCPoisonedPtr.h.

2017-12-14  David Kilzer  <ddkilzer@apple.com>

        REGRESSION (r225887): Build broke due to missing includes in InferredValue.h
        <https://bugs.webkit.org/show_bug.cgi?id=180738>

        * runtime/InferredValue.h: Attempt to fix build by adding
        missing #include statements.

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

        Octane/richards regressed by a whopping 20% because eliminateCommonSubexpressions has a weird fixpoint requirement
        https://bugs.webkit.org/show_bug.cgi?id=180783

        Reviewed by Saam Barati.
        
        This fixes the regression by fixpointing CSE. We need to fixpoint CSE because of this case:
        
            BB#1:
                a: Load(@x)
                b: Load(@x)
                c: Load(@b)
            BB#2:
                d: Load(@b)
            BB#3:
                e: Load(@b)
        
        Lets assume that #3 loops around to #2, so to eliminate @d, we need to prove that it's redundant
        with both @c and @e. The problem is that by the time we get to @d, the CSE state will look like
        this:

            BB#1:
                a: Load(@x)
                b: Load(@x)
                c: Load(@a)
                memoryAtTail: {@x=>@a, @a=>@c}
            BB#2:
                d: Load(@a) [sic]
                memoryAtTail: {@b=>@d}
            BB#3:
                e: Load(@b)
                memoryAtTail: {@b=>@e} [sic]
        
        Note that #3's atTail map is keyed on @b, which was the old (no longer canonical) version of @a.
        But @d's children were already substituted, so it refers to @a. Since @a is not in #3's atTail
        map, we don't find it and leave the redundancy.
        
        I think that the cleanest solution is to fixpoint. CSE is pretty cheap, so hopefully we can afford
        this. It fixes the richards regression, since richards is super dependent on B3 CSE.

        * b3/B3EliminateCommonSubexpressions.cpp: Logging.
        * b3/B3Generate.cpp:
        (JSC::B3::generateToAir): Fix the bug.
        * b3/air/AirReportUsedRegisters.cpp:
        (JSC::B3::Air::reportUsedRegisters): Logging.
        * dfg/DFGByteCodeParser.cpp:
        * dfg/DFGSSAConversionPhase.cpp:
        (JSC::DFG::SSAConversionPhase::run): Don't generate EntrySwitch if we don't need it (makes IR easier to read).
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::lower): Don't generate EntrySwitch if we don't need it (makes IR easier to read).

2017-12-13  Joseph Pecoraro  <pecoraro@apple.com>

        REGRESSION: Web Inspector: Opening inspector crashes page if there are empty resources
        https://bugs.webkit.org/show_bug.cgi?id=180787
        <rdar://problem/35934838>

        Reviewed by Brian Burg.

        * inspector/ContentSearchUtilities.cpp:
        (Inspector::ContentSearchUtilities::findMagicComment):
        For empty / null strings just return. There is no use
        trying to search them for a long common syntax.

2017-12-13  Saam Barati  <sbarati@apple.com>

        Arrow functions need their own structure because they have different properties than sloppy functions
        https://bugs.webkit.org/show_bug.cgi?id=180779
        <rdar://problem/35814591>

        Reviewed by Mark Lam.

        We were using the same structure for sloppy functions and
        arrow functions. This broke our IC caching machinery because
        these two types of functions actually have different properties.
        This patch gives them different structures.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNewFunction):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::selectStructureForNewFuncExp):
        (JSC::JSFunction::create):
        * runtime/JSFunction.h:
        * runtime/JSFunctionInlines.h:
        (JSC::JSFunction::createWithInvalidatedReallocationWatchpoint):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::arrowFunctionStructure const):

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

        InferredValue should use IsoSubspace
        https://bugs.webkit.org/show_bug.cgi?id=180738

        Reviewed by Keith Miller.
        
        This moves InferredValue into an IsoSubspace and then takes advantage of this to get rid of
        its UnconditionalFinalizer.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/Heap.cpp:
        (JSC::Heap::finalizeUnconditionalFinalizers):
        * runtime/InferredValue.cpp:
        (JSC::InferredValue::visitChildren):
        (JSC::InferredValue::ValueCleanup::ValueCleanup): Deleted.
        (JSC::InferredValue::ValueCleanup::~ValueCleanup): Deleted.
        (JSC::InferredValue::ValueCleanup::finalizeUnconditionally): Deleted.
        * runtime/InferredValue.h:
        (JSC::InferredValue::subspaceFor):
        * runtime/InferredValueInlines.h: Added.
        (JSC::InferredValue::finalizeUnconditionally):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

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

        Web Inspector: add instrumentation for ImageBitmapRenderingContext
        https://bugs.webkit.org/show_bug.cgi?id=180736

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/Canvas.json:
        * inspector/scripts/codegen/generator.py:

2017-12-13  Saam Barati  <sbarati@apple.com>

        Take a value driven approach to how we emit structure checks in TypeCheckHoistingPhase to obviate the need for static_assert guards
        https://bugs.webkit.org/show_bug.cgi?id=180771

        Reviewed by JF Bastien.

        * dfg/DFGTypeCheckHoistingPhase.cpp:
        (JSC::DFG::TypeCheckHoistingPhase::run):

2017-12-13  Saam Barati  <sbarati@apple.com>

        REGRESSION(r225844): Around 850 new JSC failures on 32-bit
        https://bugs.webkit.org/show_bug.cgi?id=180764

        Unreviewed. We should only emit CheckStructureOrEmpty on 64 bit platforms.

        * dfg/DFGTypeCheckHoistingPhase.cpp:
        (JSC::DFG::TypeCheckHoistingPhase::run):

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

        Unreviewed rollout of r225695. Caused a crash on yahoo login page.

        That bug tracked in https://bugs.webkit.org/show_bug.cgi?id=180761.

        * runtime/RegExp.cpp:
        (JSC::RegExp::compile):
        (JSC::RegExp::compileMatchOnly):
        (JSC::byteCodeCompilePattern): Deleted.
        (JSC::RegExp::byteCodeCompileIfNecessary): Deleted.
        * runtime/RegExp.h:
        * runtime/RegExpInlines.h:
        (JSC::RegExp::matchInline):
        * testRegExp.cpp:
        (parseRegExpLine):
        (runFromFiles):
        * yarr/Yarr.h:
        * yarr/YarrInterpreter.cpp:
        (JSC::Yarr::ByteCompiler::compile):
        (JSC::Yarr::ByteCompiler::dumpDisjunction):
        (JSC::Yarr::ByteCompiler::emitDisjunction):
        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::tryReadUnicodeCharImpl):
        (JSC::Yarr::YarrGenerator::generate):
        (JSC::Yarr::YarrGenerator::backtrack):
        (JSC::Yarr::YarrGenerator::opCompileParenthesesSubpattern):
        (JSC::Yarr::YarrGenerator::generateEnter):
        (JSC::Yarr::YarrGenerator::generateReturn):
        (JSC::Yarr::YarrGenerator::YarrGenerator):
        (JSC::Yarr::YarrGenerator::compile):
        (JSC::Yarr::YarrGenerator::ParenContextSizes::ParenContextSizes): Deleted.
        (JSC::Yarr::YarrGenerator::ParenContextSizes::numSubpatterns): Deleted.
        (JSC::Yarr::YarrGenerator::ParenContextSizes::frameSlots): Deleted.
        (JSC::Yarr::YarrGenerator::ParenContext::sizeFor): Deleted.
        (JSC::Yarr::YarrGenerator::ParenContext::nextOffset): Deleted.
        (JSC::Yarr::YarrGenerator::ParenContext::beginOffset): Deleted.
        (JSC::Yarr::YarrGenerator::ParenContext::matchAmountOffset): Deleted.
        (JSC::Yarr::YarrGenerator::ParenContext::subpatternOffset): Deleted.
        (JSC::Yarr::YarrGenerator::ParenContext::savedFrameOffset): Deleted.
        (JSC::Yarr::YarrGenerator::initParenContextFreeList): Deleted.
        (JSC::Yarr::YarrGenerator::allocatePatternContext): Deleted.
        (JSC::Yarr::YarrGenerator::freePatternContext): Deleted.
        (JSC::Yarr::YarrGenerator::savePatternContext): Deleted.
        (JSC::Yarr::YarrGenerator::restorePatternContext): Deleted.
        (JSC::Yarr::YarrGenerator::generateJITFailReturn): Deleted.
        (JSC::Yarr::YarrGenerator::clearMatches): Deleted.
        * yarr/YarrJIT.h:
        (JSC::Yarr::YarrCodeBlock::execute):
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::indentForNestingLevel):
        (JSC::Yarr::dumpUChar32):
        (JSC::Yarr::PatternTerm::dump):
        (JSC::Yarr::YarrPattern::dumpPattern):
        (JSC::Yarr::dumpCharacterClass): Deleted.
        * yarr/YarrPattern.h:
        (JSC::Yarr::BackTrackInfoAlternative::offsetIndex):
        (JSC::Yarr::BackTrackInfoParenthesesOnce::beginIndex):
        (JSC::Yarr::PatternTerm::containsAnyCaptures): Deleted.
        (JSC::Yarr::BackTrackInfoParenthesesOnce::returnAddressIndex): Deleted.
        (JSC::Yarr::BackTrackInfoParentheses::beginIndex): Deleted.
        (JSC::Yarr::BackTrackInfoParentheses::returnAddressIndex): Deleted.
        (JSC::Yarr::BackTrackInfoParentheses::matchAmountIndex): Deleted.
        (JSC::Yarr::BackTrackInfoParentheses::patternContextHeadIndex): Deleted.

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

        Fill out some Poisoned APIs, fix some bugs, and add some tests.
        https://bugs.webkit.org/show_bug.cgi?id=180724
        <rdar://problem/36006884>

        Reviewed by JF Bastien.

        * runtime/StructureTransitionTable.h:

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

        [ESNext][BigInt] Breking tests on Debug build and 32-bits due to missing Exception check
        https://bugs.webkit.org/show_bug.cgi?id=180746

        Reviewed by Saam Barati.

        We have some uncatched exceptions that could happen due to OOM into
        JSBigInt::allocateFor and JSBigInt::toStringGeneric. This patching is
        catching such exceptions properly.

        * runtime/JSBigInt.cpp:
        (JSC::JSBigInt::allocateFor):
        (JSC::JSBigInt::parseInt):
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::toStringSlowCase const):

2017-12-13  Saam Barati  <sbarati@apple.com>

        Fix how JSFunction handles "caller" and "arguments" for functions that don't have those properties
        https://bugs.webkit.org/show_bug.cgi?id=163579
        <rdar://problem/35455798>

        Reviewed by Mark Lam.

        Some functions in JavaScript do not have the "caller" and "arguments" properties.
        For example, strict functions do not. When reading our code that dealt with these
        types of functions, it was simply all wrong. We were doing weird things depending
        on the method table hook. This patch fixes this by doing what we should've been
        doing all along: when the JSFunction does not own the "caller"/"arguments" property,
        it should defer to its base class implementation for the various method table hooks.

        * runtime/JSFunction.cpp:
        (JSC::JSFunction::put):
        (JSC::JSFunction::deleteProperty):
        (JSC::JSFunction::defineOwnProperty):

2017-12-13  Saam Barati  <sbarati@apple.com>

        TypeCheckHoistingPhase needs to emit a CheckStructureOrEmpty if it's doing it for |this|
        https://bugs.webkit.org/show_bug.cgi?id=180734
        <rdar://problem/35640547>

        Reviewed by Yusuke Suzuki.

        The |this| value may be TDZ. If type check hoisting phase
        hoists a CheckStructure to it, it will crash. This patch
        makes it so we emit CheckStructureOrEmpty for |this|.

        * dfg/DFGTypeCheckHoistingPhase.cpp:
        (JSC::DFG::TypeCheckHoistingPhase::run):

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

        [JSC] Optimize Object.assign by single transition acceleration
        https://bugs.webkit.org/show_bug.cgi?id=180644

        Reviewed by Saam Barati.

        Handling single transition is critical. Since this get() function is only used
        in Structure.cpp's 2 functions and it is quite small, we can annotate `inline`
        to accelerate it.

        This improves SixSpeed/object-assign.es6 by 2.8%.

                                    baseline                  patched

        object-assign.es6      382.3548+-8.0461          371.6496+-5.7439          might be 1.0288x faster

        * runtime/Structure.cpp:
        (JSC::StructureTransitionTable::get const):

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

        Structure, StructureRareData, and PropertyTable should be in IsoSubspaces
        https://bugs.webkit.org/show_bug.cgi?id=180732

        Rubber stamped by Mark Lam.
        
        We should eventually move all fixed-size cells into IsoSubspaces. I don't know if they are
        scalable enough to support that, so we should do it carefully.

        * heap/MarkedSpace.cpp:
        * runtime/PropertyMapHashTable.h:
        * runtime/Structure.h:
        * runtime/StructureRareData.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2017-12-12  Saam Barati  <sbarati@apple.com>

        We need to model effects of Spread(@PhantomCreateRest) in Clobberize/PreciseLocalClobberize
        https://bugs.webkit.org/show_bug.cgi?id=180725
        <rdar://problem/35970511>

        Reviewed by Michael Saboff.

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

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

        [JSC] Implement optimized WeakMap and WeakSet
        https://bugs.webkit.org/show_bug.cgi?id=179929

        Reviewed by Saam Barati.

        This patch introduces WeakMapImpl to optimize WeakMap and WeakSet.
        This is similar to HashMapImpl. But,

        1. WeakMapImpl's bucket is not allocated in GC heap since WeakMap
        do not need to have iterators.

        2. WeakMapImpl's buffer is allocated in JSValue Gigacage instead
        of auxiliary buffer. This is because we would like to allocate buffer
        when finalizing GC. At that time, WeakMapImpl prunes dead entries and
        shrink it if necessary. However, allocating from the GC heap during
        finalization is not allowed.

        In particular, (2) is important since it ensures any WeakMap operations
        do not cause GC. Since GC may collect dead keys in WeakMap, rehash WeakMap,
        and reallocate/change WeakMap's buffer, ensuring that any WeakMap operations
        do not cause GC makes our implementation simple. To ensure this, we place
        DisallowGC for each WeakMap's interface.

        In DFG, we introduce WeakMapGet and ExtractValueFromWeakMapGet nodes.
        WeakMapGet looks up entry in WeakMapImpl and returns value. If it is
        WeakMap, it returns value. And it returns key if it is WeakSet. If it
        does not find a corresponding entry, it returns JSEmpty.
        ExtractValueFromWeakMapGet converts JSEmpty to JSUndefined.

        This patch improves WeakMap and WeakSet operations.

                                     baseline                  patched

            weak-set-key        240.6932+-10.4923    ^    148.7606+-6.1784        ^ definitely 1.6180x faster
            weak-map-key        174.3176+-8.2680     ^    151.7053+-6.8723        ^ definitely 1.1491x faster

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * dfg/DFGAbstractHeap.h:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasHeapPrediction):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileExtractValueFromWeakMapGet):
        (JSC::DFG::SpeculativeJIT::compileWeakMapGet):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (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::compileExtractValueFromWeakMapGet):
        (JSC::FTL::DFG::LowerDFGToB3::compileWeakMapGet):
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::weakMapEntries):
        (Inspector::JSInjectedScriptHost::weakSetEntries):
        Existing code is incorrect. They can run GC and break WeakMap's iterator.
        We introduce takeSnapshot function to WeakMapImpl, which retrieves live
        entries without causing any GC.

        * runtime/HashMapImpl.h:
        (JSC::shouldShrink):
        (JSC::shouldRehashAfterAdd):
        (JSC::nextCapacity):
        (JSC::HashMapImpl::shouldRehashAfterAdd const):
        (JSC::HashMapImpl::shouldShrink const):
        (JSC::HashMapImpl::rehash):
        (JSC::WeakMapHash::hash): Deleted.
        (JSC::WeakMapHash::equal): Deleted.
        * runtime/Intrinsic.cpp:
        (JSC::intrinsicName):
        * runtime/Intrinsic.h:
        * runtime/JSWeakMap.cpp:
        * runtime/JSWeakMap.h:
        * runtime/JSWeakSet.cpp:
        * runtime/JSWeakSet.h:
        * runtime/VM.cpp:
        * runtime/WeakGCMap.h:
        (JSC::WeakGCMap::forEach): Deleted.
        * runtime/WeakMapBase.cpp: Removed.
        * runtime/WeakMapBase.h: Removed.
        * runtime/WeakMapConstructor.cpp:
        (JSC::constructWeakMap):
        * runtime/WeakMapImpl.cpp: Added.
        (JSC::WeakMapImpl<WeakMapBucket>::destroy):
        (JSC::WeakMapImpl<WeakMapBucket>::visitChildren):
        (JSC::WeakMapImpl<WeakMapBucket>::estimatedSize):
        (JSC::WeakMapImpl<WeakMapBucket<WeakMapBucketDataKey>>::visitWeakReferences):
        (JSC::WeakMapImpl<WeakMapBucket<WeakMapBucketDataKeyValue>>::visitWeakReferences):
        (JSC::WeakMapImpl<WeakMapBucket>::finalizeUnconditionally):
        (JSC::WeakMapImpl<WeakMapBucket<WeakMapBucketDataKey>>::takeSnapshot):
        (JSC::WeakMapImpl<WeakMapBucket<WeakMapBucketDataKeyValue>>::takeSnapshot):
        * runtime/WeakMapImpl.h: Added.
        (JSC::jsWeakMapHash):
        (JSC::nextCapacityAfterRemoveBatching):
        (JSC::WeakMapBucket::setKey):
        (JSC::WeakMapBucket::setValue):
        (JSC::WeakMapBucket::key const):
        (JSC::WeakMapBucket::value const):
        (JSC::WeakMapBucket::copyFrom):
        (JSC::WeakMapBucket::offsetOfKey):
        (JSC::WeakMapBucket::offsetOfValue):
        (JSC::WeakMapBucket::extractValue):
        (JSC::WeakMapBucket::isEmpty):
        (JSC::WeakMapBucket::deletedKey):
        (JSC::WeakMapBucket::isDeleted):
        (JSC::WeakMapBucket::makeDeleted):
        (JSC::WeakMapBucket::visitAggregate):
        (JSC::WeakMapBucket::clearValue):
        (JSC::WeakMapBuffer::allocationSize):
        (JSC::WeakMapBuffer::buffer const):
        (JSC::WeakMapBuffer::create):
        (JSC::WeakMapBuffer::reset):
        (JSC::WeakMapImpl::WeakMapImpl):
        (JSC::WeakMapImpl::finishCreation):
        (JSC::WeakMapImpl::get):
        (JSC::WeakMapImpl::has):
        (JSC::WeakMapImpl::add):
        (JSC::WeakMapImpl::remove):
        (JSC::WeakMapImpl::size const):
        (JSC::WeakMapImpl::offsetOfBuffer):
        (JSC::WeakMapImpl::offsetOfCapacity):
        (JSC::WeakMapImpl::findBucket):
        (JSC::WeakMapImpl::buffer const):
        (JSC::WeakMapImpl::forEach):
        (JSC::WeakMapImpl::shouldRehashAfterAdd const):
        (JSC::WeakMapImpl::shouldShrink const):
        (JSC::WeakMapImpl::canUseBucket):
        (JSC::WeakMapImpl::addInternal):
        (JSC::WeakMapImpl::findBucketAlreadyHashed):
        (JSC::WeakMapImpl::rehash):
        (JSC::WeakMapImpl::checkConsistency const):
        (JSC::WeakMapImpl::makeAndSetNewBuffer):
        (JSC::WeakMapImpl::assertBufferIsEmpty const):
        (JSC::WeakMapImpl::DeadKeyCleaner::target):
        * runtime/WeakMapPrototype.cpp:
        (JSC::WeakMapPrototype::finishCreation):
        (JSC::protoFuncWeakMapGet):
        (JSC::protoFuncWeakMapHas):
        * runtime/WeakSetConstructor.cpp:
        (JSC::constructWeakSet):
        * runtime/WeakSetPrototype.cpp:
        (JSC::WeakSetPrototype::finishCreation):
        (JSC::protoFuncWeakSetHas):
        (JSC::protoFuncWeakSetAdd):

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

        It should be possible to flag a cell for unconditional finalization
        https://bugs.webkit.org/show_bug.cgi?id=180636

        Reviewed by Saam Barati.
        
        UnconditionalFinalizers were annoying - you had to allocate them and you had to manage a
        global linked list - but they had some nice properties:
        
        - You only did the hardest work (creating the UnconditionalFinalizer) on first GC where you
          survived and needed it.
            -> Just needing it wasn't enough.
            -> Just surviving wasn't enough.
        
        The new API based on IsoSubspaces meant that just surviving was enough to cause unconditional
        finalizer logic to be invoked. I think that's not great. InferredType got around this by
        making InferredStructure a cell, but this was a gross hack. For one, it meant that
        InferredStructure would survive during the GC in which its finalizer obviated the need for its
        existence. It's not really an idiom I want us to repeat because it sounds like the sort of
        thing that turns out to be subtly broken.
        
        We really need to have a way of indicating when you have entered into the state that requires
        your unconditional finalizer to be invoked. Basically, we want to be able to track the set of
        objects that need unconditional finalizers. Only the subset of that set that overlaps with the
        set of marked objects needs to be accurate. The easiest way to do this is a hierarchy of
        bitvectors: one to say which MarkedBlocks have objects that have unconditional finalizers, and
        another level to say which atoms within a MarkedBlock have unconditional finalizers.
        
        This change introduces IsoCellSet, which couples itself to the MarkedAllocator of some
        IsoSubspace to allow maintaining a set of objects (well, cells - you could do this with
        auxiliaries) that belong to that IsoSubspace. It'll have undefined behavior if you try to
        add/remove/contains an object that isn't in that IsoSubspace. For objects in that subspace,
        you can add/remove/contains and forEachMarkedCell. The cost of each IsoCellSet is at worst
        about 0.8% increase in size to every object in the subspace that the set is attached to. So,
        it makes sense to have a handful per subspace max. This change only needs one per subspace,
        but you could imagine more if we do this for WeakReferenceHarvester.
        
        To absolutely minimize the possibility that this incurs costs, the add/remove/contains
        functions can be used from any thread so long as forEachMarkedCell isn't running. This means
        that InferredType only needs to add itself to the set during visitChildren. Thus, it needs to
        both survive and need it for the hardest work to take place. The work of adding does involve
        a gnarly load chain that ends in a CAS: load block handle from block, load index, load
        segment, load bitvector, load bit -> if not set, then CAS. That's five dependent loads!
        However, it's perfect for running in parallel since the only write operations are to widely
        dispersed cache lines that contain the bits underlying the set.
        
        The best part is how forEachMarkedCell works. That skips blocks that don't have any objects
        that need unconditional finalizers, and only touches the memory of marked objects that have
        the unconditional finalizer bit set. It will walk those objects in roughly address order. I
        previously found that this speeds up walking over a lot of objects when I made similar changes
        for DOM GC (calling visitAdditionalChildren via forEachMarkedCell rather than by walking a
        HashSet).
        
        This change makes InferredStructure be a malloc object again, but now it's in an IsoHeap.
        
        My expectation for this change is that it's perf-neutral. Long-term, it gives us a path
        forward for eliminating UnconditionalFinalizer and WeakReferenceHarvester while using
        IsoSubspace in more places.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * heap/AtomIndices.h: Added.
        (JSC::AtomIndices::AtomIndices):
        * heap/Heap.cpp:
        (JSC::Heap::finalizeUnconditionalFinalizers):
        * heap/Heap.h:
        * heap/IsoCellSet.cpp: Added.
        (JSC::IsoCellSet::IsoCellSet):
        (JSC::IsoCellSet::~IsoCellSet):
        (JSC::IsoCellSet::addSlow):
        (JSC::IsoCellSet::didResizeBits):
        (JSC::IsoCellSet::didRemoveBlock):
        (JSC::IsoCellSet::sweepToFreeList):
        * heap/IsoCellSet.h: Added.
        * heap/IsoCellSetInlines.h: Added.
        (JSC::IsoCellSet::add):
        (JSC::IsoCellSet::remove):
        (JSC::IsoCellSet::contains const):
        (JSC::IsoCellSet::forEachMarkedCell):
        * heap/IsoSubspace.cpp:
        (JSC::IsoSubspace::didResizeBits):
        (JSC::IsoSubspace::didRemoveBlock):
        (JSC::IsoSubspace::didBeginSweepingToFreeList):
        * heap/IsoSubspace.h:
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::addBlock):
        (JSC::MarkedAllocator::removeBlock):
        * heap/MarkedAllocator.h:
        * heap/MarkedAllocatorInlines.h:
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::Handle::sweep):
        (JSC::MarkedBlock::Handle::isEmpty): Deleted.
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::marks const):
        (JSC::MarkedBlock::Handle::newlyAllocated const):
        * heap/MarkedBlockInlines.h:
        (JSC::MarkedBlock::Handle::isAllocated):
        (JSC::MarkedBlock::Handle::isEmpty):
        (JSC::MarkedBlock::Handle::emptyMode):
        (JSC::MarkedBlock::Handle::forEachMarkedCell):
        * heap/Subspace.cpp:
        (JSC::Subspace::didResizeBits):
        (JSC::Subspace::didRemoveBlock):
        (JSC::Subspace::didBeginSweepingToFreeList):
        * heap/Subspace.h:
        * heap/SubspaceInlines.h:
        (JSC::Subspace::forEachMarkedCell):
        * runtime/InferredStructure.cpp:
        (JSC::InferredStructure::InferredStructure):
        (JSC::InferredStructure::create): Deleted.
        (JSC::InferredStructure::destroy): Deleted.
        (JSC::InferredStructure::createStructure): Deleted.
        (JSC::InferredStructure::visitChildren): Deleted.
        (JSC::InferredStructure::finalizeUnconditionally): Deleted.
        (JSC::InferredStructure::finishCreation): Deleted.
        * runtime/InferredStructure.h:
        * runtime/InferredStructureWatchpoint.cpp:
        (JSC::InferredStructureWatchpoint::fireInternal):
        * runtime/InferredType.cpp:
        (JSC::InferredType::visitChildren):
        (JSC::InferredType::willStoreValueSlow):
        (JSC::InferredType::makeTopSlow):
        (JSC::InferredType::set):
        (JSC::InferredType::removeStructure):
        (JSC::InferredType::finalizeUnconditionally):
        * runtime/InferredType.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2017-12-12  Saam Barati  <sbarati@apple.com>

        ConstantFoldingPhase rule for GetMyArgumentByVal must check for negative indices
        https://bugs.webkit.org/show_bug.cgi?id=180723
        <rdar://problem/35859726>

        Reviewed by JF Bastien.

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

2017-12-04  Brian Burg  <bburg@apple.com>

        Web Inspector: modernize InjectedScript a bit
        https://bugs.webkit.org/show_bug.cgi?id=180367

        Reviewed by Timothy Hatcher.

        Stop using out parameters passed by pointer, use references instead.
        Stop using OptOutput<T> in favor of std::optional where possible.
        If there is only one out-parameter and a void return type, then return the value.

        * inspector/InjectedScript.h:
        * inspector/InjectedScript.cpp:
        (Inspector::InjectedScript::evaluate):
        (Inspector::InjectedScript::callFunctionOn):
        (Inspector::InjectedScript::evaluateOnCallFrame):
        (Inspector::InjectedScript::getFunctionDetails):
        (Inspector::InjectedScript::functionDetails):
        (Inspector::InjectedScript::getPreview):
        (Inspector::InjectedScript::getProperties):
        (Inspector::InjectedScript::getDisplayableProperties):
        (Inspector::InjectedScript::getInternalProperties):
        (Inspector::InjectedScript::getCollectionEntries):
        (Inspector::InjectedScript::saveResult):
        (Inspector::InjectedScript::setExceptionValue):
        (Inspector::InjectedScript::clearExceptionValue):
        (Inspector::InjectedScript::inspectObject):
        (Inspector::InjectedScript::releaseObject):

        * inspector/InjectedScriptBase.h:
        * inspector/InjectedScriptBase.cpp:
        (Inspector::InjectedScriptBase::InjectedScriptBase):
        Declare m_environment with a default initializer.

        (Inspector::InjectedScriptBase::makeCall):
        (Inspector::InjectedScriptBase::makeEvalCall):
        Just return the result, no need for an out-parameter.
        Rearrange some code paths now that we can just return a result.
        Return a Ref<JSON::Value> since it is either a result value or error value.
        Use out_ prefixes in a few places to improve readability.

        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::getFunctionDetails):
        (Inspector::InspectorDebuggerAgent::evaluateOnCallFrame):
        * inspector/agents/InspectorHeapAgent.cpp:
        (Inspector::InspectorHeapAgent::getPreview):
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::evaluate):
        (Inspector::InspectorRuntimeAgent::callFunctionOn):
        (Inspector::InspectorRuntimeAgent::getPreview):
        (Inspector::InspectorRuntimeAgent::getProperties):
        (Inspector::InspectorRuntimeAgent::getDisplayableProperties):
        (Inspector::InspectorRuntimeAgent::getCollectionEntries):
        (Inspector::InspectorRuntimeAgent::saveResult):
        Adapt to InjectedScript changes. In some cases we need to bridge OptOutput<T>
        and std::optional until the former is removed from generated method signatures.

2017-12-12  Caio Lima  <ticaiolima@gmail.com>

        [ESNext][BigInt] Implement BigInt literals and JSBigInt
        https://bugs.webkit.org/show_bug.cgi?id=179000

        Reviewed by Darin Adler and Yusuke Suzuki.

        This patch starts the implementation of BigInt primitive on
        JavaScriptCore. We are introducing BigInt primitive and
        implementing it on JSBigInt as a subclass of JSCell with [[BigIntData]]
        field implemented contiguosly on memory as inline storage of JSBigInt to
        take advantages on performance due to cache locality. The
        implementation allows 64 or 32 bitwise arithmetic operations.
        JSBigInt also has m_sign to store the sign of [[BigIntData]] and
        m_length that keeps track of BigInt length.
        The implementation is following the V8 one. [[BigIntData]] is manipulated
        by JSBigInt::setDigit(index, value) and JSBigInt::digit(index) operations.
        We also have some operations to support arithmetics over digits.

        It is important to notice that on our representation,
        JSBigInt::dataStorage()[0] represents the least significant digit and
        JSBigInt::dataStorage()[m_length - 1] represents the most siginificant digit.

        We are also introducing into this Patch the BigInt literals lexer and
        syntax parsing support. The operation Strict Equals on BigInts is also being
        implemented to enable tests.
        These features are being implemented behind a runtime flage "--useBigInt" and
        are disabled by default.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * bytecode/CodeBlock.cpp:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitEqualityOp):
        (JSC::BytecodeGenerator::addBigIntConstant):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::BigIntEntryHash::hash):
        (JSC::BytecodeGenerator::BigIntEntryHash::equal):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BigIntNode::jsValue const):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::isToThisAnIdentity):
        * interpreter/Interpreter.cpp:
        (JSC::sizeOfVarargs):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LowLevelInterpreter.asm:
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createBigInt):
        * parser/Lexer.cpp:
        (JSC::Lexer<T>::parseBinary):
        (JSC::Lexer<T>::parseOctal):
        (JSC::Lexer<T>::parseDecimal):
        (JSC::Lexer<T>::lex):
        (JSC::Lexer<T>::parseHex): Deleted.
        * parser/Lexer.h:
        * parser/NodeConstructors.h:
        (JSC::BigIntNode::BigIntNode):
        * parser/Nodes.h:
        (JSC::ExpressionNode::isBigInt const):
        (JSC::BigIntNode::value):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        * parser/ParserTokens.h:
        * parser/ResultType.h:
        (JSC::ResultType::definitelyIsBigInt const):
        (JSC::ResultType::mightBeBigInt const):
        (JSC::ResultType::isNotBigInt const):
        (JSC::ResultType::addResultType):
        (JSC::ResultType::bigIntType):
        (JSC::ResultType::forAdd):
        (JSC::ResultType::forLogicalOp):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createBigInt):
        * runtime/CommonIdentifiers.h:
        * runtime/JSBigInt.cpp: Added.
        (JSC::JSBigInt::visitChildren):
        (JSC::JSBigInt::JSBigInt):
        (JSC::JSBigInt::initialize):
        (JSC::JSBigInt::createStructure):
        (JSC::JSBigInt::createZero):
        (JSC::JSBigInt::allocationSize):
        (JSC::JSBigInt::createWithLength):
        (JSC::JSBigInt::finishCreation):
        (JSC::JSBigInt::toPrimitive const):
        (JSC::JSBigInt::singleDigitValueForString):
        (JSC::JSBigInt::parseInt):
        (JSC::JSBigInt::toString):
        (JSC::JSBigInt::isZero):
        (JSC::JSBigInt::inplaceMultiplyAdd):
        (JSC::JSBigInt::digitAdd):
        (JSC::JSBigInt::digitSub):
        (JSC::JSBigInt::digitMul):
        (JSC::JSBigInt::digitPow):
        (JSC::JSBigInt::digitDiv):
        (JSC::JSBigInt::internalMultiplyAdd):
        (JSC::JSBigInt::equalToBigInt):
        (JSC::JSBigInt::absoluteDivSmall):
        (JSC::JSBigInt::calculateMaximumCharactersRequired):
        (JSC::JSBigInt::toStringGeneric):
        (JSC::JSBigInt::rightTrim):
        (JSC::JSBigInt::allocateFor):
        (JSC::JSBigInt::estimatedSize):
        (JSC::JSBigInt::toNumber const):
        (JSC::JSBigInt::getPrimitiveNumber const):
        * runtime/JSBigInt.h: Added.
        (JSC::JSBigInt::setSign):
        (JSC::JSBigInt::sign const):
        (JSC::JSBigInt::setLength):
        (JSC::JSBigInt::length const):
        (JSC::JSBigInt::parseInt):
        (JSC::JSBigInt::offsetOfData):
        (JSC::JSBigInt::dataStorage):
        (JSC::JSBigInt::digit):
        (JSC::JSBigInt::setDigit):
        (JSC::asBigInt):
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::synthesizePrototype const):
        (JSC::JSValue::toStringSlowCase const):
        * runtime/JSCJSValue.h:
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::isBigInt const):
        (JSC::JSValue::strictEqualSlowCaseInline):
        * runtime/JSCell.cpp:
        (JSC::JSCell::put):
        (JSC::JSCell::putByIndex):
        (JSC::JSCell::toPrimitive const):
        (JSC::JSCell::getPrimitiveNumber const):
        (JSC::JSCell::toNumber const):
        (JSC::JSCell::toObjectSlow const):
        * runtime/JSCell.h:
        * runtime/JSCellInlines.h:
        (JSC::JSCell::isBigInt const):
        * runtime/JSType.h:
        * runtime/MathCommon.h:
        (JSC::clz64):
        * runtime/NumberPrototype.cpp:
        * runtime/Operations.cpp:
        (JSC::jsTypeStringForValue):
        (JSC::jsIsObjectTypeOrNull):
        * runtime/Options.h:
        * runtime/ParseInt.h:
        * runtime/SmallStrings.h:
        (JSC::SmallStrings::typeString const):
        * runtime/StructureInlines.h:
        (JSC::prototypeForLookupPrimitiveImpl):
        * runtime/TypeofType.cpp:
        (WTF::printInternal):
        * runtime/TypeofType.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2017-12-12  Guillaume Emont  <guijemont@igalia.com>

        LLInt: reserve 16 bytes of stack on MIPS for native calls
        https://bugs.webkit.org/show_bug.cgi?id=180653

        Reviewed by Carlos Alberto Lopez Perez.

        * llint/LowLevelInterpreter32_64.asm:
        On MIPS, substract 24 from the stack pointer (16 for calling
        convention + 8 to be 16-aligned) instead of the 8 on other platforms
        (for alignment).

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

        [WTF] Thread::create should have Thread::tryCreate
        https://bugs.webkit.org/show_bug.cgi?id=180333

        Reviewed by Darin Adler.

        * assembler/testmasm.cpp:
        (JSC::run):
        * b3/air/testair.cpp:
        * b3/testb3.cpp:
        (JSC::B3::run):
        * jsc.cpp:
        (functionDollarAgentStart):

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

        REGRESSION(r225683): Chakra test failure in es6/regex-unicode.js for 32bit builds
        https://bugs.webkit.org/show_bug.cgi?id=180685

        Reviewed by Saam Barati.

        The characterClass->m_anyCharacter check at the top of checkCharacterClass() caused
        the character class check to return true without reading the character.  Given that
        the character could be a surrogate pair, we need to read the character even if we
        don't have the check it.

        * yarr/YarrInterpreter.cpp:
        (JSC::Yarr::Interpreter::testCharacterClass):
        (JSC::Yarr::Interpreter::checkCharacterClass):

2017-12-11  Saam Barati  <sbarati@apple.com>

        We need to disableCaching() in ErrorInstance when we materialize properties
        https://bugs.webkit.org/show_bug.cgi?id=180343
        <rdar://problem/35833002>

        Reviewed by Mark Lam.

        This patch fixes a bug in ErrorInstance where we forgot to call PutPropertySlot::disableCaching
        on puts() to a property that we lazily materialized. Forgetting to do this goes against the
        PutPropertySlot's caching API. This lazy materialization caused the ErrorInstance to transition
        from a Structure A to a Structure B. However, we were telling the IC that we were caching an
        existing property only found on Structure B. This is obviously wrong as it would lead to an
        OOB store if we didn't already crash when generating the IC.

        * jit/Repatch.cpp:
        (JSC::tryCachePutByID):
        * runtime/ErrorInstance.cpp:
        (JSC::ErrorInstance::materializeErrorInfoIfNeeded):
        (JSC::ErrorInstance::put):
        * runtime/ErrorInstance.h:
        * runtime/Structure.cpp:
        (JSC::Structure::didCachePropertyReplacement):

2017-12-11  Fujii Hironori  <Hironori.Fujii@sony.com>

        [WinCairo] DLLLauncherMain should use SetDllDirectory
        https://bugs.webkit.org/show_bug.cgi?id=180642

        Reviewed by Alex Christensen.

        Windows have icuuc.dll in the system directory. WebKit should find
        one in WebKitLibraries directory, not one in the system directory.

        * shell/DLLLauncherMain.cpp:
        (modifyPath): Use SetDllDirectory for WebKitLibraries directory instead of modifying path.

2017-12-11  Eric Carlson  <eric.carlson@apple.com>

        Web Inspector: Optionally log WebKit log parameters as JSON
        https://bugs.webkit.org/show_bug.cgi?id=180529
        <rdar://problem/35909462>

        Reviewed by Joseph Pecoraro.

        * inspector/ConsoleMessage.cpp:
        (Inspector::ConsoleMessage::ConsoleMessage): New constructor that takes a vector of JSON log
        values. Concatenate all adjacent strings to make logging cleaner.
        (Inspector::ConsoleMessage::addToFrontend): Process WebKit logging arguments.
        (Inspector::ConsoleMessage::scriptState const):
        * inspector/ConsoleMessage.h:

        * inspector/InjectedScript.cpp:
        (Inspector::InjectedScript::wrapJSONString const): Wrap JSON string log arguments.
        * inspector/InjectedScript.h:
        * inspector/InjectedScriptSource.js:
        (let.InjectedScript.prototype.wrapJSONString):

2017-12-11  Joseph Pecoraro  <pecoraro@apple.com>

        Remove unused builtin names
        https://bugs.webkit.org/show_bug.cgi?id=180673

        Reviewed by Keith Miller.

        * builtins/BuiltinNames.h:

2017-12-11  David Quesada  <david_quesada@apple.com>

        Turn on ENABLE_APPLICATION_MANIFEST
        https://bugs.webkit.org/show_bug.cgi?id=180562
        rdar://problem/35924737

        Reviewed by Geoffrey Garen.

        * Configurations/FeatureDefines.xcconfig:

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

        Harden a few assertions in GC sweep
        https://bugs.webkit.org/show_bug.cgi?id=180634

        Reviewed by Saam Barati.
        
        This turns one dynamic check into a release assertion and upgrades another assertion to a release
        assertion.

        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::Handle::sweep):

2017-12-10  Konstantin Tokarev  <annulen@yandex.ru>

        [python] Modernize "except" usage for python3 compatibility
        https://bugs.webkit.org/show_bug.cgi?id=180612

        Reviewed by Michael Catanzaro.

        * inspector/scripts/generate-inspector-protocol-bindings.py:

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

        InferredType should not use UnconditionalFinalizer
        https://bugs.webkit.org/show_bug.cgi?id=180456

        Reviewed by Saam Barati.
        
        This turns InferredStructure into a cell so that we can unconditionally finalize them without
        having to add things to the UnconditionalFinalizer list. I'm removing all uses of
        UnconditionalFinalizers and WeakReferenceHarvesters because the data structures used to manage
        them are a top cause of lock contention in the parallel GC. Also, we don't need those data
        structures if we use IsoSubspaces, subspace iteration, and marking constraints.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * heap/Heap.cpp:
        (JSC::Heap::finalizeUnconditionalFinalizers):
        * heap/Heap.h:
        * runtime/InferredStructure.cpp: Added.
        (JSC::InferredStructure::create):
        (JSC::InferredStructure::destroy):
        (JSC::InferredStructure::createStructure):
        (JSC::InferredStructure::visitChildren):
        (JSC::InferredStructure::finalizeUnconditionally):
        (JSC::InferredStructure::InferredStructure):
        (JSC::InferredStructure::finishCreation):
        * runtime/InferredStructure.h: Added.
        * runtime/InferredStructureWatchpoint.cpp: Added.
        (JSC::InferredStructureWatchpoint::fireInternal):
        * runtime/InferredStructureWatchpoint.h: Added.
        * runtime/InferredType.cpp:
        (JSC::InferredType::visitChildren):
        (JSC::InferredType::willStoreValueSlow):
        (JSC::InferredType::makeTopSlow):
        (JSC::InferredType::set):
        (JSC::InferredType::removeStructure):
        (JSC::InferredType::InferredStructureWatchpoint::fireInternal): Deleted.
        (JSC::InferredType::InferredStructureFinalizer::finalizeUnconditionally): Deleted.
        (JSC::InferredType::InferredStructure::InferredStructure): Deleted.
        * runtime/InferredType.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2017-12-09  Konstantin Tokarev  <annulen@yandex.ru>

        [python] Replace print >> operator with print() function for python3 compatibility
        https://bugs.webkit.org/show_bug.cgi?id=180611

        Reviewed by Michael Catanzaro.

        * Scripts/make-js-file-arrays.py:
        (main):

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

        ServiceWorker Inspector: Various issues inspecting service worker on mobile.twitter.com
        https://bugs.webkit.org/show_bug.cgi?id=180520
        <rdar://problem/35900764>

        Reviewed by Brian Burg.

        * inspector/protocol/ServiceWorker.json:
        Include content script content in the initialization info.

2017-12-08  Konstantin Tokarev  <annulen@yandex.ru>

        [python] Replace print operator with print() function for python3 compatibility
        https://bugs.webkit.org/show_bug.cgi?id=180592

        Reviewed by Michael Catanzaro.

        * Scripts/generateYarrUnicodePropertyTables.py:
        (openOrExit):
        (verifyUCDFilesExist):
        (Aliases.parsePropertyAliasesFile):
        (Aliases.parsePropertyValueAliasesFile):
        * Scripts/make-js-file-arrays.py:
        (main):
        * generate-bytecode-files:

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

        Need to unpoison native function pointers for CLoop.
        https://bugs.webkit.org/show_bug.cgi?id=180601
        <rdar://problem/35942028>

        Reviewed by JF Bastien.

        * llint/LowLevelInterpreter64.asm:

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

        YARR: JIT RegExps with greedy parenthesized sub patterns
        https://bugs.webkit.org/show_bug.cgi?id=180538

        Reviewed by JF Bastien.

        This patch adds JIT support for regular expressions containing greedy counted
        parenthesis.  An example expression that couldn't be JIT'ed before is /q(a|b)*q/.

        Just like in the interpreter, expressions with nested parenthetical subpatterns
        require saving the results of previous matches of the parentheses contents along
        with any associated state.  This saved state is needed in the case that we need
        to backtrack.  This state is called ParenContext within the code space allocated
        for this ParenContext is managed using a simple block allocator within the JIT'ed
        code.  The raw space managed by this allocator is passed into the JIT'ed function.

        Since this fixed sized space may be exceeded, this patch adds a fallback mechanism.
        If the JIT'ed code exhausts all its ParenContext space, it returns a new error
        JSRegExpJITCodeFailure.  The caller will then bytecompile and interpret the
        expression.

        Due to increased register usage by the parenthesis handling code, the use of
        registers by the JIT engine was restructured, with registers used for Unicode
        pattern matching replaced with constants.

        Reworked some of the context structures that are used across the interpreter
        and JIT implementations to make them a little more uniform and to handle the
        needs of JIT'ing the new parentheses forms.

        To help with development and debugging of this code, compiled patterns dumping
        code was enhanced.  Also added the ability to also dump interpreter ByteCodes.

        * runtime/RegExp.cpp:
        (JSC::byteCodeCompilePattern):
        (JSC::RegExp::byteCodeCompileIfNecessary):
        (JSC::RegExp::compile):
        (JSC::RegExp::compileMatchOnly):
        * runtime/RegExp.h:
        * runtime/RegExpInlines.h:
        (JSC::RegExp::matchInline):
        * testRegExp.cpp:
        (parseRegExpLine):
        (runFromFiles):
        * yarr/Yarr.h:
        * yarr/YarrInterpreter.cpp:
        (JSC::Yarr::ByteCompiler::compile):
        (JSC::Yarr::ByteCompiler::dumpDisjunction):
        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::ParenContextSizes::ParenContextSizes):
        (JSC::Yarr::YarrGenerator::ParenContextSizes::numSubpatterns):
        (JSC::Yarr::YarrGenerator::ParenContextSizes::frameSlots):
        (JSC::Yarr::YarrGenerator::ParenContext::sizeFor):
        (JSC::Yarr::YarrGenerator::ParenContext::nextOffset):
        (JSC::Yarr::YarrGenerator::ParenContext::beginOffset):
        (JSC::Yarr::YarrGenerator::ParenContext::matchAmountOffset):
        (JSC::Yarr::YarrGenerator::ParenContext::subpatternOffset):
        (JSC::Yarr::YarrGenerator::ParenContext::savedFrameOffset):
        (JSC::Yarr::YarrGenerator::initParenContextFreeList):
        (JSC::Yarr::YarrGenerator::allocatePatternContext):
        (JSC::Yarr::YarrGenerator::freePatternContext):
        (JSC::Yarr::YarrGenerator::savePatternContext):
        (JSC::Yarr::YarrGenerator::restorePatternContext):
        (JSC::Yarr::YarrGenerator::tryReadUnicodeCharImpl):
        (JSC::Yarr::YarrGenerator::storeToFrame):
        (JSC::Yarr::YarrGenerator::generateJITFailReturn):
        (JSC::Yarr::YarrGenerator::clearMatches):
        (JSC::Yarr::YarrGenerator::generate):
        (JSC::Yarr::YarrGenerator::backtrack):
        (JSC::Yarr::YarrGenerator::opCompileParenthesesSubpattern):
        (JSC::Yarr::YarrGenerator::generateEnter):
        (JSC::Yarr::YarrGenerator::generateReturn):
        (JSC::Yarr::YarrGenerator::YarrGenerator):
        (JSC::Yarr::YarrGenerator::compile):
        * yarr/YarrJIT.h:
        (JSC::Yarr::YarrCodeBlock::execute):
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::indentForNestingLevel):
        (JSC::Yarr::dumpUChar32):
        (JSC::Yarr::dumpCharacterClass):
        (JSC::Yarr::PatternTerm::dump):
        (JSC::Yarr::YarrPattern::dumpPattern):
        * yarr/YarrPattern.h:
        (JSC::Yarr::PatternTerm::containsAnyCaptures):
        (JSC::Yarr::BackTrackInfoParenthesesOnce::returnAddressIndex):
        (JSC::Yarr::BackTrackInfoParentheses::beginIndex):
        (JSC::Yarr::BackTrackInfoParentheses::returnAddressIndex):
        (JSC::Yarr::BackTrackInfoParentheses::matchAmountIndex):
        (JSC::Yarr::BackTrackInfoParentheses::patternContextHeadIndex):
        (JSC::Yarr::BackTrackInfoAlternative::offsetIndex): Deleted.

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

        Web Inspector: CRASH at InspectorConsoleAgent::enable when iterating mutable list of buffered console messages
        https://bugs.webkit.org/show_bug.cgi?id=180590
        <rdar://problem/35882767>

        Reviewed by Mark Lam.

        * inspector/agents/InspectorConsoleAgent.cpp:
        (Inspector::InspectorConsoleAgent::enable):
        Swap the messages to a Vector that won't change during iteration.

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

        YARR: Coalesce constructed character classes
        https://bugs.webkit.org/show_bug.cgi?id=180537

        Reviewed by JF Bastien.

        When adding characters or character ranges to a character class being constructed,
        we now coalesce adjacent characters and character ranges.  When we create a
        character class after construction is complete, we do a final coalescing pass
        across the character list and ranges to catch any remaining coalescing
        opportunities.

        Added an optimization for character classes that will match any character.
        This is somewhat common in code created before the /s (dotAll) flag was added
        to the engine.

        * yarr/YarrInterpreter.cpp:
        (JSC::Yarr::Interpreter::checkCharacterClass):
        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::generateCharacterClassOnce):
        (JSC::Yarr::YarrGenerator::generateCharacterClassFixed):
        (JSC::Yarr::YarrGenerator::generateCharacterClassGreedy):
        (JSC::Yarr::YarrGenerator::backtrackCharacterClassNonGreedy):
        * 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::mergeRangesFrom):
        (JSC::Yarr::CharacterClassConstructor::coalesceTables):
        (JSC::Yarr::CharacterClassConstructor::anyCharacter):
        (JSC::Yarr::YarrPatternConstructor::atomCharacterClassEnd):
        (JSC::Yarr::PatternTerm::dump):
        (JSC::Yarr::anycharCreate):
        * yarr/YarrPattern.h:
        (JSC::Yarr::CharacterClass::CharacterClass):

2017-12-07  Saam Barati  <sbarati@apple.com>

        Modify our dollar VM clflush intrinsic to aid in some perf testing
        https://bugs.webkit.org/show_bug.cgi?id=180559

        Reviewed by Mark Lam.

        * tools/JSDollarVM.cpp:
        (JSC::functionCpuClflush):
        (JSC::functionDeltaBetweenButterflies):
        (JSC::JSDollarVM::finishCreation):

2017-12-07  Eric Carlson  <eric.carlson@apple.com>

        Simplify log channel configuration UI
        https://bugs.webkit.org/show_bug.cgi?id=180527
        <rdar://problem/35908382>

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/Console.json:

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

        Apply poisoning to some native code pointers.
        https://bugs.webkit.org/show_bug.cgi?id=180541
        <rdar://problem/35916875>

        Reviewed by Filip Pizlo.

        Renamed g_classInfoPoison to g_globalDataPoison.
        Renamed g_masmPoison to g_jitCodePoison.
        Introduced g_nativeCodePoison.
        Applied g_nativeCodePoison to poisoning some native code pointers.

        Introduced non-random Int32 poison values (in JSCPoison.h) for use with pointers
        to malloc allocated data structures (where needed).

        * API/JSCallbackFunction.h:
        (JSC::JSCallbackFunction::functionCallback):
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * jit/ThunkGenerators.cpp:
        (JSC::nativeForGenerator):
        * llint/LowLevelInterpreter64.asm:
        * runtime/CustomGetterSetter.h:
        (JSC::CustomGetterSetter::getter const):
        (JSC::CustomGetterSetter::setter const):
        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::getCallData):
        (JSC::InternalFunction::getConstructData):
        * runtime/InternalFunction.h:
        (JSC::InternalFunction::nativeFunctionFor):
        * runtime/JSCPoison.h: Added.
        * runtime/JSCPoisonedPtr.cpp:
        (JSC::initializePoison):
        * runtime/JSCPoisonedPtr.h:
        * runtime/Lookup.h:
        * runtime/NativeExecutable.cpp:
        (JSC::NativeExecutable::hashFor const):
        * runtime/NativeExecutable.h:
        * runtime/Structure.cpp:
        (JSC::StructureTransitionTable::setSingleTransition):
        * runtime/StructureTransitionTable.h:
        (JSC::StructureTransitionTable::StructureTransitionTable):
        (JSC::StructureTransitionTable::isUsingSingleSlot const):
        (JSC::StructureTransitionTable::map const):
        (JSC::StructureTransitionTable::weakImpl const):
        (JSC::StructureTransitionTable::setMap):

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

        Web Inspector: Fix style in remote inspector classes
        https://bugs.webkit.org/show_bug.cgi?id=180545

        Reviewed by Youenn Fablet.

        * inspector/remote/RemoteControllableTarget.h:
        * inspector/remote/RemoteInspectionTarget.h:
        * runtime/JSGlobalObjectDebuggable.h:

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

        Use fastAlignedFree to free aligned memory.
        https://bugs.webkit.org/show_bug.cgi?id=180540

        Reviewed by Saam Barati.

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

2017-12-07  Matt Lewis  <jlewis3@apple.com>

        Unreviewed, rolling out r225634.

        This caused layout tests to time out.

        Reverted changeset:

        "Simplify log channel configuration UI"
        https://bugs.webkit.org/show_bug.cgi?id=180527
        https://trac.webkit.org/changeset/225634

2017-12-07  Eric Carlson  <eric.carlson@apple.com>

        Simplify log channel configuration UI
        https://bugs.webkit.org/show_bug.cgi?id=180527
        <rdar://problem/35908382>

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/Console.json:

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

        [Re-landing r225620] Refactoring: Rename ScrambledPtr to Poisoned.
        https://bugs.webkit.org/show_bug.cgi?id=180514

        Reviewed by Saam Barati and JF Bastien.

        Re-landing r225620 with speculative build fix for GCC 7.

        * API/JSCallbackObject.h:
        * API/JSObjectRef.cpp:
        (classInfoPrivate):
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * assembler/MacroAssemblerCodeRef.h:
        (JSC::FunctionPtr::FunctionPtr):
        (JSC::FunctionPtr::value const):
        (JSC::FunctionPtr::executableAddress const):
        (JSC::ReturnAddressPtr::ReturnAddressPtr):
        (JSC::ReturnAddressPtr::value const):
        (JSC::MacroAssemblerCodePtr::MacroAssemblerCodePtr):
        (JSC::MacroAssemblerCodePtr::createFromExecutableAddress):
        (JSC::MacroAssemblerCodePtr::poisonedPtr const):
        (JSC::MacroAssemblerCodePtr:: const):
        (JSC::MacroAssemblerCodePtr::operator! const):
        (JSC::MacroAssemblerCodePtr::operator== const):
        (JSC::MacroAssemblerCodePtr::emptyValue):
        (JSC::MacroAssemblerCodePtr::deletedValue):
        (JSC::MacroAssemblerCodePtr::scrambledPtr const): Deleted.
        * b3/B3LowerMacros.cpp:
        * b3/testb3.cpp:
        (JSC::B3::testInterpreter):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::checkArray):
        (JSC::DFG::SpeculativeJIT::compileCheckSubClass):
        (JSC::DFG::SpeculativeJIT::compileNewStringObject):
        (JSC::DFG::SpeculativeJIT::emitSwitchIntJump):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNewStringObject):
        (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitAllocateDestructibleObject):
        * jit/SpecializedThunkJIT.h:
        (JSC::SpecializedThunkJIT::loadArgumentWithSpecificClass):
        * jit/ThunkGenerators.cpp:
        (JSC::virtualThunkFor):
        (JSC::boundThisNoArgsFunctionCallGenerator):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::handleHostCall):
        (JSC::LLInt::setUpCall):
        * llint/LowLevelInterpreter64.asm:
        * runtime/InitializeThreading.cpp:
        (JSC::initializeThreading):
        * runtime/JSCPoisonedPtr.cpp: Copied from Source/JavaScriptCore/runtime/JSCScrambledPtr.cpp.
        (JSC::initializePoison):
        (JSC::initializeScrambledPtrKeys): Deleted.
        * runtime/JSCPoisonedPtr.h: Copied from Source/JavaScriptCore/runtime/JSCScrambledPtr.h.
        * runtime/JSCScrambledPtr.cpp: Removed.
        * runtime/JSCScrambledPtr.h: Removed.
        * runtime/JSDestructibleObject.h:
        (JSC::JSDestructibleObject::classInfo const):
        * runtime/JSSegmentedVariableObject.h:
        (JSC::JSSegmentedVariableObject::classInfo const):
        * runtime/Structure.h:
        * runtime/VM.h:

2017-12-07  Michael Catanzaro  <mcatanzaro@igalia.com>

        Unreviewed, rolling out r225620
        https://bugs.webkit.org/show_bug.cgi?id=180514
        <rdar://problem/35901694>

        It broke the build with GCC 7, and I don't know how to fix it.

        * API/JSCallbackObject.h:
        * API/JSObjectRef.cpp:
        (classInfoPrivate):
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * assembler/MacroAssemblerCodeRef.h:
        (JSC::FunctionPtr::FunctionPtr):
        (JSC::FunctionPtr::value const):
        (JSC::FunctionPtr::executableAddress const):
        (JSC::ReturnAddressPtr::ReturnAddressPtr):
        (JSC::ReturnAddressPtr::value const):
        (JSC::MacroAssemblerCodePtr::MacroAssemblerCodePtr):
        (JSC::MacroAssemblerCodePtr::createFromExecutableAddress):
        (JSC::MacroAssemblerCodePtr::scrambledPtr const):
        (JSC::MacroAssemblerCodePtr:: const):
        (JSC::MacroAssemblerCodePtr::operator! const):
        (JSC::MacroAssemblerCodePtr::operator== const):
        (JSC::MacroAssemblerCodePtr::emptyValue):
        (JSC::MacroAssemblerCodePtr::deletedValue):
        (JSC::MacroAssemblerCodePtr::poisonedPtr const): Deleted.
        * b3/B3LowerMacros.cpp:
        * b3/testb3.cpp:
        (JSC::B3::testInterpreter):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::checkArray):
        (JSC::DFG::SpeculativeJIT::compileCheckSubClass):
        (JSC::DFG::SpeculativeJIT::compileNewStringObject):
        (JSC::DFG::SpeculativeJIT::emitSwitchIntJump):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNewStringObject):
        (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitAllocateDestructibleObject):
        * jit/SpecializedThunkJIT.h:
        (JSC::SpecializedThunkJIT::loadArgumentWithSpecificClass):
        * jit/ThunkGenerators.cpp:
        (JSC::virtualThunkFor):
        (JSC::boundThisNoArgsFunctionCallGenerator):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::handleHostCall):
        (JSC::LLInt::setUpCall):
        * llint/LowLevelInterpreter64.asm:
        * runtime/InitializeThreading.cpp:
        (JSC::initializeThreading):
        * runtime/JSCScrambledPtr.cpp: Renamed from Source/JavaScriptCore/runtime/JSCPoisonedPtr.cpp.
        (JSC::initializeScrambledPtrKeys):
        * runtime/JSCScrambledPtr.h: Renamed from Source/JavaScriptCore/runtime/JSCPoisonedPtr.h.
        * runtime/JSDestructibleObject.h:
        (JSC::JSDestructibleObject::classInfo const):
        * runtime/JSSegmentedVariableObject.h:
        (JSC::JSSegmentedVariableObject::classInfo const):
        * runtime/Structure.h:
        * runtime/VM.h:

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

        Refactoring: Rename ScrambledPtr to Poisoned.
        https://bugs.webkit.org/show_bug.cgi?id=180514

        Reviewed by Saam Barati.

        * API/JSCallbackObject.h:
        * API/JSObjectRef.cpp:
        (classInfoPrivate):
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * assembler/MacroAssemblerCodeRef.h:
        (JSC::FunctionPtr::FunctionPtr):
        (JSC::FunctionPtr::value const):
        (JSC::FunctionPtr::executableAddress const):
        (JSC::ReturnAddressPtr::ReturnAddressPtr):
        (JSC::ReturnAddressPtr::value const):
        (JSC::MacroAssemblerCodePtr::MacroAssemblerCodePtr):
        (JSC::MacroAssemblerCodePtr::createFromExecutableAddress):
        (JSC::MacroAssemblerCodePtr::poisonedPtr const):
        (JSC::MacroAssemblerCodePtr:: const):
        (JSC::MacroAssemblerCodePtr::operator! const):
        (JSC::MacroAssemblerCodePtr::operator== const):
        (JSC::MacroAssemblerCodePtr::emptyValue):
        (JSC::MacroAssemblerCodePtr::deletedValue):
        (JSC::MacroAssemblerCodePtr::scrambledPtr const): Deleted.
        * b3/B3LowerMacros.cpp:
        * b3/testb3.cpp:
        (JSC::B3::testInterpreter):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::checkArray):
        (JSC::DFG::SpeculativeJIT::compileCheckSubClass):
        (JSC::DFG::SpeculativeJIT::compileNewStringObject):
        (JSC::DFG::SpeculativeJIT::emitSwitchIntJump):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNewStringObject):
        (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitAllocateDestructibleObject):
        * jit/SpecializedThunkJIT.h:
        (JSC::SpecializedThunkJIT::loadArgumentWithSpecificClass):
        * jit/ThunkGenerators.cpp:
        (JSC::virtualThunkFor):
        (JSC::boundThisNoArgsFunctionCallGenerator):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::handleHostCall):
        (JSC::LLInt::setUpCall):
        * llint/LowLevelInterpreter64.asm:
        * runtime/InitializeThreading.cpp:
        (JSC::initializeThreading):
        * runtime/JSCPoisonedPtr.cpp: Copied from Source/JavaScriptCore/runtime/JSCScrambledPtr.cpp.
        (JSC::initializePoison):
        (JSC::initializeScrambledPtrKeys): Deleted.
        * runtime/JSCPoisonedPtr.h: Copied from Source/JavaScriptCore/runtime/JSCScrambledPtr.h.
        * runtime/JSCScrambledPtr.cpp: Removed.
        * runtime/JSCScrambledPtr.h: Removed.
        * runtime/JSDestructibleObject.h:
        (JSC::JSDestructibleObject::classInfo const):
        * runtime/JSSegmentedVariableObject.h:
        (JSC::JSSegmentedVariableObject::classInfo const):
        * runtime/Structure.h:
        * runtime/VM.h:

2017-12-02  Darin Adler  <darin@apple.com>

        Modernize some aspects of text codecs, eliminate WebKit use of strcasecmp
        https://bugs.webkit.org/show_bug.cgi?id=180009

        Reviewed by Alex Christensen.

        * bytecode/ArrayProfile.cpp: Removed include of StringExtras.h.
        * bytecode/CodeBlock.cpp: Ditto.
        * bytecode/ExecutionCounter.cpp: Ditto.
        * runtime/ConfigFile.cpp: Ditto.
        * runtime/DatePrototype.cpp: Ditto.
        * runtime/IndexingType.cpp: Ditto.
        * runtime/JSCJSValue.cpp: Ditto.
        * runtime/JSDateMath.cpp: Ditto.
        * runtime/JSGlobalObjectFunctions.cpp: Ditto.
        * runtime/Options.cpp: Ditto.
        (JSC::parse): Use equalLettersIgnoringASCIICase instead of strcasecmp.

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

        ASSERTION FAILED: vm->currentThreadIsHoldingAPILock() in void JSC::sanitizeStackForVM(JSC::VM *)
        https://bugs.webkit.org/show_bug.cgi?id=180438
        <rdar://problem/35862342>

        Reviewed by Yusuke Suzuki.

        A couple inspector methods that take stacktraces need
        to grab the JSLock.

        * inspector/ScriptCallStackFactory.cpp:
        (Inspector::createScriptCallStack):
        (Inspector::createScriptCallStackForConsole):

2017-12-05  Stephan Szabo  <stephan.szabo@sony.com>

        Switch windows build to Visual Studio 2017
        https://bugs.webkit.org/show_bug.cgi?id=172412

        Reviewed by Per Arne Vollan.

        * JavaScriptCore.vcxproj/JavaScriptCore.proj:

2017-12-05  JF Bastien  <jfbastien@apple.com>

        WebAssembly: don't eagerly checksum
        https://bugs.webkit.org/show_bug.cgi?id=180441
        <rdar://problem/35156628>

        Reviewed by Saam Barati.

        Make checksumming of module optional for now. The bots think the
        checksum hurt compile-time. I'd measured it and couldn't see a
        difference, and still can't at this point in time, but we'll see
        if disabling it fixes the bots. If so then I can make it lazy upon
        first backtrace construction, or I can try out MD5 instead of
        SHA1.

        * runtime/Options.h:
        * wasm/WasmModuleInformation.cpp:
        (JSC::Wasm::ModuleInformation::ModuleInformation):
        * wasm/WasmModuleInformation.h:
        * wasm/WasmNameSection.h:
        (JSC::Wasm::NameSection::NameSection):

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

        IsoAlignedMemoryAllocator needs to free all of its memory when the VM destructs
        https://bugs.webkit.org/show_bug.cgi?id=180425

        Reviewed by Saam Barati.
        
        Failure to do so causes leaks after starting workers.

        * heap/IsoAlignedMemoryAllocator.cpp:
        (JSC::IsoAlignedMemoryAllocator::~IsoAlignedMemoryAllocator):
        (JSC::IsoAlignedMemoryAllocator::tryAllocateAlignedMemory):

2017-12-05  Per Arne Vollan  <pvollan@apple.com>

        [Win64] Compile error in testmasm.cpp.
        https://bugs.webkit.org/show_bug.cgi?id=180436

        Reviewed by Mark Lam.

        Fix MSVC warning (32-bit shift implicitly converted to 64 bits).
        
        * assembler/testmasm.cpp:
        (JSC::testGetEffectiveAddress):

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

        GC constraint solving should be parallel
        https://bugs.webkit.org/show_bug.cgi?id=179934

        Reviewed by JF Bastien.
        
        This makes it possible to do constraint solving in parallel. This looks like a 1% Speedometer
        speed-up. It's more than 1% on trunk-Speedometer.
        
        The constraint solver supports running constraints in parallel in two different ways:
        
        - Run multiple constraints in parallel to each other. This only works for constraints that can
          tolerate other constraints running concurrently to them (constraint.concurrency() ==
          ConstraintConcurrency::Concurrent). This is the most basic kind of parallelism that the
          constraint solver supports. All constraints except the JSC SPI constraints are concurrent. We
          could probably make them concurrent, but I'm playing it safe for now.
        
        - A constraint can create parallel work for itself, which the constraint solver will interleave
          with other stuff. A constraint can report that it has parallel work by returning
          ConstraintParallelism::Parallel from its executeImpl() function. Then the solver will allow that
          constraint's doParallelWorkImpl() function to run on as many GC marker threads as are available,
          for as long as that function wants to run.
        
        It's not possible to have a non-concurrent constraint that creates parallel work.
        
        The parallelism is implemented in terms of the existing GC marker threads. This turns out to be
        most natural for two reasons:
        
        - No need to start any other threads.
        
        - The constraints all want to be passed a SlotVisitor. Running on the marker threads means having
          access to those threads' SlotVisitors. Also, it means less load balancing. The solver will
          create work on each marking thread's SlotVisitor. When the solver is done "stealing" a marker
          thread, that thread will have work it can start doing immediately. Before this change, we had to
          contribute the work found by the constraint solver to the global worklist so that it could be
          distributed to the marker threads by load balancing. This change probably helps to avoid that
          load balancing step.
        
        A lot of this change is about making it easy to iterate GC data structures in parallel. This
        change makes almost all constraints parallel-enabled, but only the DOM's output constraint uses
        the parallel work API. That constraint iterates the marked cells in two subspaces. This change
        makes it very easy to compose parallel iterators over subspaces, allocators, blocks, and cells.
        The marked cell parallel iterator is composed out of parallel iterators for the others. A parallel
        iterator is just an iterator that can do an atomic next() very quickly. We abstract them using
        RefPtr<SharedTask<...()>>, where ... is the type returned from the iterator. We know it's done
        when it returns a falsish version of ... (in the current code, that's always a pointer type, so
        done is indicated by null).
        
        * API/JSMarkingConstraintPrivate.cpp:
        (JSContextGroupAddMarkingConstraint):
        * API/JSVirtualMachine.mm:
        (scanExternalObjectGraph):
        (scanExternalRememberedSet):
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * bytecode/AccessCase.cpp:
        (JSC::AccessCase::propagateTransitions const):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::visitWeakly):
        (JSC::CodeBlock::shouldJettisonDueToOldAge):
        (JSC::shouldMarkTransition):
        (JSC::CodeBlock::propagateTransitions):
        (JSC::CodeBlock::determineLiveness):
        * dfg/DFGWorklist.cpp:
        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):
        * heap/ConstraintParallelism.h: Added.
        (WTF::printInternal):
        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::addToRememberedSet):
        (JSC::Heap::runFixpointPhase):
        (JSC::Heap::stopThePeriphery):
        (JSC::Heap::resumeThePeriphery):
        (JSC::Heap::addCoreConstraints):
        (JSC::Heap::setBonusVisitorTask):
        (JSC::Heap::runTaskInParallel):
        (JSC::Heap::forEachSlotVisitor): Deleted.
        * heap/Heap.h:
        (JSC::Heap::worldIsRunning const):
        (JSC::Heap::runFunctionInParallel):
        * heap/HeapInlines.h:
        (JSC::Heap::worldIsStopped const):
        (JSC::Heap::isMarked):
        (JSC::Heap::incrementDeferralDepth):
        (JSC::Heap::decrementDeferralDepth):
        (JSC::Heap::decrementDeferralDepthAndGCIfNeeded):
        (JSC::Heap::forEachSlotVisitor):
        (JSC::Heap::collectorBelievesThatTheWorldIsStopped const): Deleted.
        (JSC::Heap::isMarkedConcurrently): Deleted.
        * heap/HeapSnapshotBuilder.cpp:
        (JSC::HeapSnapshotBuilder::appendNode):
        * heap/LargeAllocation.h:
        (JSC::LargeAllocation::isMarked):
        (JSC::LargeAllocation::isMarkedConcurrently): Deleted.
        * heap/LockDuringMarking.h:
        (JSC::lockDuringMarking):
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::parallelNotEmptyBlockSource):
        * heap/MarkedAllocator.h:
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::aboutToMark):
        (JSC::MarkedBlock::isMarked):
        (JSC::MarkedBlock::areMarksStaleWithDependency): Deleted.
        (JSC::MarkedBlock::isMarkedConcurrently): Deleted.
        * heap/MarkedSpace.h:
        (JSC::MarkedSpace::activeWeakSetsBegin):
        (JSC::MarkedSpace::activeWeakSetsEnd):
        (JSC::MarkedSpace::newActiveWeakSetsBegin):
        (JSC::MarkedSpace::newActiveWeakSetsEnd):
        * heap/MarkingConstraint.cpp:
        (JSC::MarkingConstraint::MarkingConstraint):
        (JSC::MarkingConstraint::execute):
        (JSC::MarkingConstraint::quickWorkEstimate):
        (JSC::MarkingConstraint::workEstimate):
        (JSC::MarkingConstraint::doParallelWork):
        (JSC::MarkingConstraint::finishParallelWork):
        (JSC::MarkingConstraint::doParallelWorkImpl):
        (JSC::MarkingConstraint::finishParallelWorkImpl):
        * heap/MarkingConstraint.h:
        (JSC::MarkingConstraint::lastExecuteParallelism const):
        (JSC::MarkingConstraint::parallelism const):
        (JSC::MarkingConstraint::quickWorkEstimate): Deleted.
        (JSC::MarkingConstraint::workEstimate): Deleted.
        * heap/MarkingConstraintSet.cpp:
        (JSC::MarkingConstraintSet::MarkingConstraintSet):
        (JSC::MarkingConstraintSet::add):
        (JSC::MarkingConstraintSet::executeConvergence):
        (JSC::MarkingConstraintSet::executeConvergenceImpl):
        (JSC::MarkingConstraintSet::executeAll):
        (JSC::MarkingConstraintSet::ExecutionContext::ExecutionContext): Deleted.
        (JSC::MarkingConstraintSet::ExecutionContext::didVisitSomething const): Deleted.
        (JSC::MarkingConstraintSet::ExecutionContext::shouldTimeOut const): Deleted.
        (JSC::MarkingConstraintSet::ExecutionContext::drain): Deleted.
        (JSC::MarkingConstraintSet::ExecutionContext::didExecute const): Deleted.
        (JSC::MarkingConstraintSet::ExecutionContext::execute): Deleted.
        (): Deleted.
        * heap/MarkingConstraintSet.h:
        * heap/MarkingConstraintSolver.cpp: Added.
        (JSC::MarkingConstraintSolver::MarkingConstraintSolver):
        (JSC::MarkingConstraintSolver::~MarkingConstraintSolver):
        (JSC::MarkingConstraintSolver::didVisitSomething const):
        (JSC::MarkingConstraintSolver::execute):
        (JSC::MarkingConstraintSolver::drain):
        (JSC::MarkingConstraintSolver::converge):
        (JSC::MarkingConstraintSolver::runExecutionThread):
        (JSC::MarkingConstraintSolver::didExecute):
        * heap/MarkingConstraintSolver.h: Added.
        * heap/OpaqueRootSet.h: Removed.
        * heap/ParallelSourceAdapter.h: Added.
        (JSC::ParallelSourceAdapter::ParallelSourceAdapter):
        (JSC::createParallelSourceAdapter):
        * heap/SimpleMarkingConstraint.cpp: Added.
        (JSC::SimpleMarkingConstraint::SimpleMarkingConstraint):
        (JSC::SimpleMarkingConstraint::~SimpleMarkingConstraint):
        (JSC::SimpleMarkingConstraint::quickWorkEstimate):
        (JSC::SimpleMarkingConstraint::executeImpl):
        * heap/SimpleMarkingConstraint.h: Added.
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::didStartMarking):
        (JSC::SlotVisitor::reset):
        (JSC::SlotVisitor::appendToMarkStack):
        (JSC::SlotVisitor::visitChildren):
        (JSC::SlotVisitor::updateMutatorIsStopped):
        (JSC::SlotVisitor::mutatorIsStoppedIsUpToDate const):
        (JSC::SlotVisitor::drain):
        (JSC::SlotVisitor::performIncrementOfDraining):
        (JSC::SlotVisitor::didReachTermination):
        (JSC::SlotVisitor::hasWork):
        (JSC::SlotVisitor::drainFromShared):
        (JSC::SlotVisitor::drainInParallelPassively):
        (JSC::SlotVisitor::waitForTermination):
        (JSC::SlotVisitor::addOpaqueRoot): Deleted.
        (JSC::SlotVisitor::containsOpaqueRoot const): Deleted.
        (JSC::SlotVisitor::containsOpaqueRootTriState const): Deleted.
        (JSC::SlotVisitor::mergeIfNecessary): Deleted.
        (JSC::SlotVisitor::mergeOpaqueRootsIfProfitable): Deleted.
        (JSC::SlotVisitor::mergeOpaqueRoots): Deleted.
        * heap/SlotVisitor.h:
        * heap/SlotVisitorInlines.h:
        (JSC::SlotVisitor::addOpaqueRoot):
        (JSC::SlotVisitor::containsOpaqueRoot const):
        (JSC::SlotVisitor::vm):
        (JSC::SlotVisitor::vm const):
        * heap/Subspace.cpp:
        (JSC::Subspace::parallelAllocatorSource):
        (JSC::Subspace::parallelNotEmptyMarkedBlockSource):
        * heap/Subspace.h:
        * heap/SubspaceInlines.h:
        (JSC::Subspace::forEachMarkedCellInParallel):
        * heap/VisitCounter.h: Added.
        (JSC::VisitCounter::VisitCounter):
        (JSC::VisitCounter::visitCount const):
        * heap/VisitingTimeout.h: Removed.
        * heap/WeakBlock.cpp:
        (JSC::WeakBlock::specializedVisit):
        * runtime/Structure.cpp:
        (JSC::Structure::isCheapDuringGC):
        (JSC::Structure::markIfCheap):

2017-12-04  JF Bastien  <jfbastien@apple.com>

        Math: don't redundantly check for exceptions, just release scope
        https://bugs.webkit.org/show_bug.cgi?id=180395

        Rubber stamped by Mark Lam.

        Two of the exceptions checks could just have been exception scope
        releases before the return, which is ever-so-slightly more
        efficient. The same technically applies where we have loops over
        parameters, but doing the scope release there isn't really more
        efficient and is way harder to read.

        * runtime/MathObject.cpp:
        (JSC::mathProtoFuncATan2):
        (JSC::mathProtoFuncPow):

2017-12-04  David Quesada  <david_quesada@apple.com>

        Add a class for parsing application manifests
        https://bugs.webkit.org/show_bug.cgi?id=177973
        rdar://problem/34747949

        Reviewed by Geoffrey Garen.

        * Configurations/FeatureDefines.xcconfig: Add ENABLE_APPLICATION_MANIFEST feature flag.

2017-12-04  JF Bastien  <jfbastien@apple.com>

        Update std::expected to match libc++ coding style
        https://bugs.webkit.org/show_bug.cgi?id=180264

        Reviewed by Alex Christensen.

        Update various uses of Expected.

        * wasm/WasmModule.h:
        * wasm/WasmModuleParser.cpp:
        (JSC::Wasm::ModuleParser::parseImport):
        (JSC::Wasm::ModuleParser::parseTableHelper):
        (JSC::Wasm::ModuleParser::parseTable):
        (JSC::Wasm::ModuleParser::parseMemoryHelper):
        * wasm/WasmParser.h:
        * wasm/generateWasmValidateInlinesHeader.py:
        (loadMacro):
        (storeMacro):
        * wasm/js/JSWebAssemblyModule.cpp:
        (JSC::JSWebAssemblyModule::createStub):
        * wasm/js/JSWebAssemblyModule.h:

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

        We need to leave room on the top of the stack for the FTL TailCall slow path so it doesn't overwrite things we want to retrieve when doing a stack walk when throwing an exception
        https://bugs.webkit.org/show_bug.cgi?id=180366
        <rdar://problem/35685877>

        Reviewed by Michael Saboff.

        On the TailCall slow path, the CallFrameShuffler will build the frame with
        respect to SP instead of FP. However, this may overwrite slots on the stack
        that are needed if the slow path C call does a stack walk. The slow path
        C call does a stack walk when it throws an exception. This patch fixes
        this bug by ensuring that the top of the stack in the FTL always has enough
        space to allow CallFrameShuffler to build a frame without overwriting any
        items on the stack that are needed when doing a stack walk.

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

2017-12-04  Devin Rousso  <webkit@devinrousso.com>

        Web Inspector: provide method for recording CanvasRenderingContext2D from JavaScript
        https://bugs.webkit.org/show_bug.cgi?id=175166
        <rdar://problem/34040740>

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/Recording.json:
        Add optional `name` that will be used by the frontend for uniquely identifying the Recording.

        * inspector/JSGlobalObjectConsoleClient.h:
        * inspector/JSGlobalObjectConsoleClient.cpp:
        (Inspector::JSGlobalObjectConsoleClient::record):
        (Inspector::JSGlobalObjectConsoleClient::recordEnd):

        * runtime/ConsoleClient.h:
        * runtime/ConsoleObject.cpp:
        (JSC::ConsoleObject::finishCreation):
        (JSC::consoleProtoFuncRecord):
        (JSC::consoleProtoFuncRecordEnd):

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

        WTF shouldn't have both Thread and ThreadIdentifier
        https://bugs.webkit.org/show_bug.cgi?id=180308

        Reviewed by Darin Adler.

        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::tryCopyOtherThreadStacks):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::llint_trace_operand):
        (JSC::LLInt::llint_trace_value):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (JSC::LLInt::traceFunctionPrologue):
        * runtime/ExceptionScope.cpp:
        (JSC::ExceptionScope::unexpectedExceptionMessage):
        * runtime/JSLock.h:
        (JSC::JSLock::currentThreadIsHoldingLock):
        * runtime/VM.cpp:
        (JSC::VM::throwException):
        * runtime/VM.h:
        (JSC::VM::throwingThread const):
        (JSC::VM::clearException):
        * tools/HeapVerifier.cpp:
        (JSC::HeapVerifier::printVerificationHeader):

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

        Rename DestroyFunc to avoid redefinition on unified build
        https://bugs.webkit.org/show_bug.cgi?id=180335

        Reviewed by Filip Pizlo.

        Changing DestroyFunc structures to more specific names to avoid
        conflits on unified builds.

        * heap/HeapCellType.cpp:
        (JSC::HeapCellType::finishSweep):
        (JSC::HeapCellType::destroy):
        * runtime/JSDestructibleObjectHeapCellType.cpp:
        (JSC::JSDestructibleObjectHeapCellType::finishSweep):
        (JSC::JSDestructibleObjectHeapCellType::destroy):
        * runtime/JSSegmentedVariableObjectHeapCellType.cpp:
        (JSC::JSSegmentedVariableObjectHeapCellType::finishSweep):
        (JSC::JSSegmentedVariableObjectHeapCellType::destroy):
        * runtime/JSStringHeapCellType.cpp:
        (JSC::JSStringHeapCellType::finishSweep):
        (JSC::JSStringHeapCellType::destroy):
        * wasm/js/JSWebAssemblyCodeBlockHeapCellType.cpp:
        (JSC::JSWebAssemblyCodeBlockHeapCellType::finishSweep):
        (JSC::JSWebAssemblyCodeBlockHeapCellType::destroy):

2017-12-01  JF Bastien  <jfbastien@apple.com>

        JavaScriptCore: missing exception checks in Math functions that take more than one argument
        https://bugs.webkit.org/show_bug.cgi?id=180297
        <rdar://problem/35745556>

        Reviewed by Mark Lam.

        * runtime/MathObject.cpp:
        (JSC::mathProtoFuncATan2):
        (JSC::mathProtoFuncMax):
        (JSC::mathProtoFuncMin):
        (JSC::mathProtoFuncPow):

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

        Let's scramble ClassInfo pointers in cells.
        https://bugs.webkit.org/show_bug.cgi?id=180291
        <rdar://problem/35807620>

        Reviewed by JF Bastien.

        * API/JSCallbackObject.h:
        * API/JSObjectRef.cpp:
        (classInfoPrivate):
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * assembler/MacroAssemblerCodeRef.cpp:
        (JSC::MacroAssemblerCodePtr::initialize): Deleted.
        * assembler/MacroAssemblerCodeRef.h:
        (JSC::MacroAssemblerCodePtr:: const):
        (JSC::MacroAssemblerCodePtr::hash const):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::checkArray):
        (JSC::DFG::SpeculativeJIT::compileCheckSubClass):
        (JSC::DFG::SpeculativeJIT::compileNewStringObject):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNewStringObject):
        (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitAllocateDestructibleObject):
        * jit/SpecializedThunkJIT.h:
        (JSC::SpecializedThunkJIT::loadArgumentWithSpecificClass):
        * runtime/InitializeThreading.cpp:
        (JSC::initializeThreading):
        * runtime/JSCScrambledPtr.cpp: Added.
        (JSC::initializeScrambledPtrKeys):
        * runtime/JSCScrambledPtr.h: Added.
        * runtime/JSDestructibleObject.h:
        (JSC::JSDestructibleObject::classInfo const):
        * runtime/JSSegmentedVariableObject.h:
        (JSC::JSSegmentedVariableObject::classInfo const):
        * runtime/Structure.h:
        * runtime/VM.h:

2017-12-01  Brian Burg  <bburg@apple.com>

        Web Inspector: move Inspector::Protocol::Array<T> to JSON namespace
        https://bugs.webkit.org/show_bug.cgi?id=173662

        Reviewed by Joseph Pecoraro.

        Adopt new type names. Fix protocol generator to use correct type names.

        * inspector/ConsoleMessage.cpp:
        (Inspector::ConsoleMessage::addToFrontend):
        Improve namings and use 'auto' when the type is obvious and repeated.

        * inspector/ContentSearchUtilities.cpp:
        (Inspector::ContentSearchUtilities::searchInTextByLines):
        * inspector/ContentSearchUtilities.h:
        * inspector/InjectedScript.cpp:
        (Inspector::InjectedScript::getProperties):
        (Inspector::InjectedScript::getDisplayableProperties):
        (Inspector::InjectedScript::getInternalProperties):
        (Inspector::InjectedScript::getCollectionEntries):
        (Inspector::InjectedScript::wrapCallFrames const):
        * inspector/InjectedScript.h:
        * inspector/InspectorProtocolTypes.h:
        (Inspector::Protocol::BindingTraits<JSON::ArrayOf<T>>::runtimeCast):
        (Inspector::Protocol::Array::Array): Deleted.
        (Inspector::Protocol::Array::openAccessors): Deleted.
        (Inspector::Protocol::Array::addItem): Deleted.
        (Inspector::Protocol::Array::create): Deleted.
        (Inspector::Protocol::BindingTraits<Protocol::Array<T>>::runtimeCast): Deleted.
        (Inspector::Protocol::BindingTraits<Protocol::Array<T>>::assertValueHasExpectedType): Deleted.
        Move the implementation out of this file.

        * inspector/ScriptCallStack.cpp:
        (Inspector::ScriptCallStack::buildInspectorArray const):
        * inspector/ScriptCallStack.h:
        * inspector/agents/InspectorAgent.cpp:
        (Inspector::InspectorAgent::activateExtraDomain):
        (Inspector::InspectorAgent::activateExtraDomains):
        * inspector/agents/InspectorAgent.h:
        * inspector/agents/InspectorConsoleAgent.cpp:
        (Inspector::InspectorConsoleAgent::getLoggingChannels):
        * inspector/agents/InspectorConsoleAgent.h:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::setBreakpointByUrl):
        (Inspector::InspectorDebuggerAgent::searchInContent):
        (Inspector::InspectorDebuggerAgent::currentCallFrames):
        * inspector/agents/InspectorDebuggerAgent.h:
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::getProperties):
        (Inspector::InspectorRuntimeAgent::getDisplayableProperties):
        (Inspector::InspectorRuntimeAgent::getCollectionEntries):
        (Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets):
        (Inspector::InspectorRuntimeAgent::getBasicBlocks):
        * inspector/agents/InspectorRuntimeAgent.h:
        * inspector/agents/InspectorScriptProfilerAgent.cpp:
        (Inspector::buildSamples):
        Use more 'auto' and rename a variable.

        * inspector/scripts/codegen/cpp_generator.py:
        (CppGenerator.cpp_protocol_type_for_type):
        Adopt new type names. This exposed a latent bug where we should have been
        unwrapping an AliasedType prior to generating a C++ type for it. The aliased
        type may be an array, in which case we would have generated the wrong type.

        * inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
        (_generate_typedefs_for_domain.JSON):
        (_generate_typedefs_for_domain.Inspector): Deleted.
        * inspector/scripts/codegen/objc_generator.py:
        (ObjCGenerator.protocol_type_for_type):
        (ObjCGenerator.objc_protocol_export_expression_for_variable):
        * 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/events-with-optional-parameters.json-result:
        * inspector/scripts/tests/generic/expected/shadowed-optional-type-setters.json-result:
        * inspector/scripts/tests/generic/expected/type-declaration-array-type.json-result:
        * inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result:
        Rebaseline.

        * runtime/TypeSet.cpp:
        (JSC::TypeSet::allStructureRepresentations const):
        (JSC::StructureShape::inspectorRepresentation):
        * runtime/TypeSet.h:

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

        Having a bad time needs to handle ArrayClass indexing type as well
        https://bugs.webkit.org/show_bug.cgi?id=180274
        <rdar://problem/35667869>

        Reviewed by Keith Miller and Mark Lam.

        We need to make sure to transition ArrayClass to SlowPutArrayStorage as well.
        Otherwise, we'll end up with the wrong Structure, which will lead us to not
        adhere to the spec. The bug was that we were not considering ArrayClass inside 
        hasBrokenIndexing. This patch rewrites that function to automatically opt
        in non-empty indexing types as broken, instead of having to opt out all
        non-empty indexing types besides SlowPutArrayStorage.

        * runtime/IndexingType.h:
        (JSC::hasSlowPutArrayStorage):
        (JSC::shouldUseSlowPut):
        * runtime/JSGlobalObject.cpp:
        * runtime/JSObject.cpp:
        (JSC::JSObject::switchToSlowPutArrayStorage):

2017-12-01  JF Bastien  <jfbastien@apple.com>

        WebAssembly: stack trace improvement follow-ups
        https://bugs.webkit.org/show_bug.cgi?id=180273

        Reviewed by Saam Barati.

        * wasm/WasmIndexOrName.cpp:
        (JSC::Wasm::makeString):
        * wasm/WasmIndexOrName.h:
        (JSC::Wasm::IndexOrName::nameSection const):
        * wasm/WasmNameSection.h:
        (JSC::Wasm::NameSection::NameSection):
        (JSC::Wasm::NameSection::get):

2017-12-01  JF Bastien  <jfbastien@apple.com>

        WebAssembly: restore cached stack limit after out-call
        https://bugs.webkit.org/show_bug.cgi?id=179106
        <rdar://problem/35337525>

        Reviewed by Saam Barati.

        We cache the stack limit on the Instance so that we can do fast
        stack checks where required. In regular usage the stack limit
        never changes because we always run on the same thread, but in
        rare cases an API user can totally migrate which thread (and
        therefore stack) is used for execution between WebAssembly
        traces. For that reason we set the cached stack limit to
        UINTPTR_MAX on the outgoing Instance when transitioning back into
        a different Instance. We usually restore the cached stack limit in
        Context::store, but this wasn't called on all code paths. We had a
        bug where an Instance calling into itself indirectly would
        therefore fail to restore its cached stack limit properly.

        This patch therefore restores the cached stack limit after direct
        calls which could be to imports (both wasm->wasm and
        wasm->embedder). We have to do all of them because we have no way
        of knowing what imports will do (they're known at instantiation
        time, not compilation time, and different instances can have
        different imports). To make this efficient we also add a pointer
        to the canonical location of the stack limit (i.e. the extra
        indirection we're trying to save by caching the stack limit on the
        Instance in the first place). This is potentially a small perf hit
        on imported direct calls.

        It's hard to say what the performance cost will be because we
        haven't seen much code in the wild which does this. We're adding
        two dependent loads and a store of the loaded value, which is
        unlikely to get used soon after. It's more code, but on an
        out-of-order processor it doesn't contribute to the critical path.

        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
        (JSC::Wasm::B3IRGenerator::addGrowMemory):
        (JSC::Wasm::B3IRGenerator::addCall):
        (JSC::Wasm::B3IRGenerator::addCallIndirect):
        * wasm/WasmInstance.cpp:
        (JSC::Wasm::Instance::Instance):
        (JSC::Wasm::Instance::create):
        * wasm/WasmInstance.h:
        (JSC::Wasm::Instance::offsetOfPointerToActualStackLimit):
        (JSC::Wasm::Instance::cachedStackLimit const):
        (JSC::Wasm::Instance::setCachedStackLimit):
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::create):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction):

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

        [JSC] Use JSFixedArray for op_new_array_buffer
        https://bugs.webkit.org/show_bug.cgi?id=180084

        Reviewed by Saam Barati.

        For op_new_array_buffer, we have a special constant buffer in CodeBlock.
        But using JSFixedArray is better because,

        1. In DFG, we have special hashing mechanism to avoid duplicating constant buffer from the same CodeBlock.
           If we use JSFixedArray, this is unnecessary since JSFixedArray is handled just as JS constant.

        2. In a subsequent patch[1], we would like to support Spread(PhantomNewArrayBuffer). If NewArrayBuffer
           has JSFixedArray, we can just emit a held JSFixedArray.

        3. We can reduce length of op_new_array_buffer since JSFixedArray holds this.

        4. We can fold NewArrayBufferData into uint64_t. No need to maintain a bag of NewArrayBufferData in DFG.

        5. We do not need to look up constant buffer from CodeBlock if buffer data is necessary. Our NewArrayBuffer
           DFG node has JSFixedArray as its cellOperand. This makes materializing PhantomNewArrayBuffer easy, which
           will be introduced in [1].

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

        * bytecode/BytecodeDumper.cpp:
        (JSC::BytecodeDumper<Block>::dumpBytecode):
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::numberOfConstantBuffers const): Deleted.
        (JSC::CodeBlock::addConstantBuffer): Deleted.
        (JSC::CodeBlock::constantBufferAsVector): Deleted.
        (JSC::CodeBlock::constantBuffer): Deleted.
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::shrinkToFit):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::constantBufferCount): Deleted.
        (JSC::UnlinkedCodeBlock::addConstantBuffer): Deleted.
        (JSC::UnlinkedCodeBlock::constantBuffer const): Deleted.
        (JSC::UnlinkedCodeBlock::constantBuffer): Deleted.
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitNewArray):
        (JSC::BytecodeGenerator::addConstantBuffer): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        (JSC::DFG::ConstantBufferKey::ConstantBufferKey): Deleted.
        (JSC::DFG::ConstantBufferKey::operator== const): Deleted.
        (JSC::DFG::ConstantBufferKey::hash const): Deleted.
        (JSC::DFG::ConstantBufferKey::isHashTableDeletedValue const): Deleted.
        (JSC::DFG::ConstantBufferKey::codeBlock const): Deleted.
        (JSC::DFG::ConstantBufferKey::index const): Deleted.
        (JSC::DFG::ConstantBufferKeyHash::hash): Deleted.
        (JSC::DFG::ConstantBufferKeyHash::equal): Deleted.
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * dfg/DFGGraph.h:
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasNewArrayBufferData):
        (JSC::DFG::Node::newArrayBufferData):
        (JSC::DFG::Node::hasVectorLengthHint):
        (JSC::DFG::Node::vectorLengthHint):
        (JSC::DFG::Node::indexingType):
        (JSC::DFG::Node::hasCellOperand):
        (JSC::DFG::Node::OpInfoWrapper::operator=):
        (JSC::DFG::Node::OpInfoWrapper::asNewArrayBufferData const):
        (JSC::DFG::Node::hasConstantBuffer): Deleted.
        (JSC::DFG::Node::startConstant): Deleted.
        (JSC::DFG::Node::numConstants): Deleted.
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayBuffer):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_new_array_buffer): Deleted.
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * llint/LLIntSlowPaths.cpp:
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        * runtime/JSFixedArray.cpp:
        (JSC::JSFixedArray::dumpToStream):
        * runtime/JSFixedArray.h:
        (JSC::JSFixedArray::create):
        (JSC::JSFixedArray::get const):
        (JSC::JSFixedArray::set):
        (JSC::JSFixedArray::buffer const):
        (JSC::JSFixedArray::values const):
        (JSC::JSFixedArray::length const):
        (JSC::JSFixedArray::get): Deleted.

2017-11-30  JF Bastien  <jfbastien@apple.com>

        WebAssembly: improve stack trace
        https://bugs.webkit.org/show_bug.cgi?id=179343

        Reviewed by Saam Barati.

        Stack traces now include:

          - Module name, if provided by the name section.
          - Module SHA1 hash if no name was provided
          - Stub identification, to differentiate from user code
          - Slightly different naming to match design from:
              https://github.com/WebAssembly/design/blob/master/Web.md#developer-facing-display-conventions

        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::functionName const):
        * runtime/StackFrame.cpp:
        (JSC::StackFrame::functionName const):
        (JSC::StackFrame::visitChildren):
        * wasm/WasmIndexOrName.cpp:
        (JSC::Wasm::IndexOrName::IndexOrName):
        (JSC::Wasm::makeString):
        * wasm/WasmIndexOrName.h:
        (JSC::Wasm::IndexOrName::nameSection const):
        * wasm/WasmModuleInformation.cpp:
        (JSC::Wasm::ModuleInformation::ModuleInformation):
        * wasm/WasmModuleInformation.h:
        * wasm/WasmNameSection.h:
        (JSC::Wasm::NameSection::NameSection):
        (JSC::Wasm::NameSection::get):
        * wasm/WasmNameSectionParser.cpp:
        (JSC::Wasm::NameSectionParser::parse):

2017-11-30  Stephan Szabo  <stephan.szabo@sony.com>

        Make LegacyCustomProtocolManager optional for network process
        https://bugs.webkit.org/show_bug.cgi?id=176230

        Reviewed by Alex Christensen.

        * Configurations/FeatureDefines.xcconfig:

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

        [JSC] Remove easy toRemove & map.remove() use in OAS phase
        https://bugs.webkit.org/show_bug.cgi?id=180208

        Reviewed by Mark Lam.

        In this patch, we replace Vector<> toRemove & map.remove loop with removeIf,
        to optimize this common pattern. This patch only modifies apparent ones.
        But we can apply this refactoring further to OAS phase in the future.

        One thing we should care is that predicate of removeIf should not touch the
        removing set itself. In this patch, we apply this change to (1) apparently
        correct one and (2) things in DFG OAS phase since it is very slow.

        * b3/B3MoveConstants.cpp:
        * dfg/DFGObjectAllocationSinkingPhase.cpp:

2017-11-30  Commit Queue  <commit-queue@webkit.org>

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

        removeIf predicate function can touch remove target set
        (Requested by yusukesuzuki on #webkit).

        Reverted changeset:

        "[JSC] Remove easy toRemove & map.remove() use"
        https://bugs.webkit.org/show_bug.cgi?id=180208
        https://trac.webkit.org/changeset/225362

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

        [JSC] Use AllocatorIfExists for MaterializeNewObject
        https://bugs.webkit.org/show_bug.cgi?id=180189

        Reviewed by Filip Pizlo.

        I don't think anyone guarantees this allocator exists at this phase.
        And nullptr allocator just works here. We change AllocatorForMode
        to AllocatorIfExists to accept nullptr for allocator.

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

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

        Let's scramble MacroAssemblerCodePtr values.
        https://bugs.webkit.org/show_bug.cgi?id=180169
        <rdar://problem/35758340>

        Reviewed by Filip Pizlo, Saam Barati, and JF Bastien.

        1. MacroAssemblerCodePtr now stores a ScrambledPtr instead of a void*.

        2. MacroAssemblerCodePtr's executableAddress() and dataLocation() now take a
           template argument type that will be used to cast the result.  This makes the
           client code that uses these functions a little less verbose.

        3. Change the code base in general to minimize passing void* code pointers around.
           We now pass MacroAssemblerCodePtr as much as possible, and descramble it only
           at the last moment when we need the underlying code pointer.

        4. Added some MasmScrambledPtr paranoid asserts that are disabled (not built) by
           default.  I'm leaving them in because they are instrumental in finding bugs
           where not all MacroAssemblerCodePtr values were not scrambled as expected.
           I expect them to be useful in the near future as we add more scrambling.

        5. Also disable the casting operator on MacroAssemblerCodePtr (except for
           explicit casts to a boolean).  This ensures that clients will always explicitly
           use scrambledBits() or executableAddress() to get a value based on which value
           they actually need.

        5. Added currentThread() id to the logging in LLIntSlowPath trace functions.
           This was helpful when debugging tests that ran multiple VMs concurrently on
           different threads.

        MacroAssemblerCodePtr is currently supported on 64-bit builds (including the
        CLoop).  It is not yet supported in 32-bit and Windows because we don't
        currently have a way to read a global variable from their LLInt code.

        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::differenceBetweenCodePtr):
        (JSC::AbstractMacroAssembler::linkPointer):
        * assembler/CodeLocation.h:
        (JSC::CodeLocationCommon::instructionAtOffset):
        (JSC::CodeLocationCommon::labelAtOffset):
        (JSC::CodeLocationCommon::jumpAtOffset):
        (JSC::CodeLocationCommon::callAtOffset):
        (JSC::CodeLocationCommon::nearCallAtOffset):
        (JSC::CodeLocationCommon::dataLabelPtrAtOffset):
        (JSC::CodeLocationCommon::dataLabel32AtOffset):
        (JSC::CodeLocationCommon::dataLabelCompactAtOffset):
        (JSC::CodeLocationCommon::convertibleLoadAtOffset):
        * assembler/LinkBuffer.cpp:
        (JSC::LinkBuffer::finalizeCodeWithDisassembly):
        * assembler/LinkBuffer.h:
        (JSC::LinkBuffer::link):
        (JSC::LinkBuffer::patch):
        * assembler/MacroAssemblerCodeRef.cpp:
        (JSC::MacroAssemblerCodePtr::initialize):
        * assembler/MacroAssemblerCodeRef.h:
        (JSC::FunctionPtr::FunctionPtr):
        (JSC::FunctionPtr::value const):
        (JSC::FunctionPtr::executableAddress const):
        (JSC::ReturnAddressPtr::ReturnAddressPtr):
        (JSC::ReturnAddressPtr::value const):
        (JSC::MacroAssemblerCodePtr::MacroAssemblerCodePtr):
        (JSC::MacroAssemblerCodePtr::createFromExecutableAddress):
        (JSC::MacroAssemblerCodePtr::scrambledPtr const):
        (JSC::MacroAssemblerCodePtr:: const):
        (JSC::MacroAssemblerCodePtr::operator! const):
        (JSC::MacroAssemblerCodePtr::operator bool const):
        (JSC::MacroAssemblerCodePtr::operator== const):
        (JSC::MacroAssemblerCodePtr::hash const):
        (JSC::MacroAssemblerCodePtr::emptyValue):
        (JSC::MacroAssemblerCodePtr::deletedValue):
        (JSC::MacroAssemblerCodePtr::executableAddress const): Deleted.
        (JSC::MacroAssemblerCodePtr::dataLocation const): Deleted.
        * b3/B3LowerMacros.cpp:
        * b3/testb3.cpp:
        (JSC::B3::testInterpreter):
        * dfg/DFGDisassembler.cpp:
        (JSC::DFG::Disassembler::dumpDisassembly):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::link):
        (JSC::DFG::JITCompiler::compileFunction):
        * dfg/DFGOperations.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitSwitchIntJump):
        (JSC::DFG::SpeculativeJIT::emitSwitchImm):
        (JSC::DFG::SpeculativeJIT::emitSwitchCharStringJump):
        (JSC::DFG::SpeculativeJIT::emitSwitchChar):
        * dfg/DFGSpeculativeJIT.h:
        * disassembler/Disassembler.cpp:
        (JSC::disassemble):
        * disassembler/UDis86Disassembler.cpp:
        (JSC::tryToDisassembleWithUDis86):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):
        * ftl/FTLJITCode.cpp:
        (JSC::FTL::JITCode::executableAddressAtOffset):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileMathIC):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct):
        (JSC::FTL::DFG::LowerDFGToB3::compileTailCall):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
        * interpreter/InterpreterInlines.h:
        (JSC::Interpreter::getOpcodeID):
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emitMathICFast):
        (JSC::JIT::emitMathICSlow):
        * jit/JITCode.cpp:
        (JSC::JITCodeWithCodeRef::executableAddressAtOffset):
        (JSC::JITCodeWithCodeRef::dataAddressAtOffset):
        (JSC::JITCodeWithCodeRef::offsetOf):
        * jit/JITDisassembler.cpp:
        (JSC::JITDisassembler::dumpDisassembly):
        * jit/PCToCodeOriginMap.cpp:
        (JSC::PCToCodeOriginMap::PCToCodeOriginMap):
        * jit/Repatch.cpp:
        (JSC::ftlThunkAwareRepatchCall):
        * jit/ThunkGenerators.cpp:
        (JSC::virtualThunkFor):
        (JSC::boundThisNoArgsFunctionCallGenerator):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::llint_trace_operand):
        (JSC::LLInt::llint_trace_value):
        (JSC::LLInt::handleHostCall):
        (JSC::LLInt::setUpCall):
        * llint/LowLevelInterpreter64.asm:
        * offlineasm/cloop.rb:
        * runtime/InitializeThreading.cpp:
        (JSC::initializeThreading):
        * wasm/WasmBBQPlan.cpp:
        (JSC::Wasm::BBQPlan::complete):
        * wasm/WasmCallee.h:
        (JSC::Wasm::Callee::entrypoint const):
        * wasm/WasmCodeBlock.cpp:
        (JSC::Wasm::CodeBlock::CodeBlock):
        * wasm/WasmOMGPlan.cpp:
        (JSC::Wasm::OMGPlan::work):
        * wasm/js/WasmToJS.cpp:
        (JSC::Wasm::wasmToJS):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction):
        * wasm/js/WebAssemblyFunction.h:
        * wasm/js/WebAssemblyWrapperFunction.cpp:
        (JSC::WebAssemblyWrapperFunction::create):

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

        [JSC] Remove easy toRemove & map.remove() use
        https://bugs.webkit.org/show_bug.cgi?id=180208

        Reviewed by Mark Lam.

        In this patch, we replace Vector<> toRemove & map.remove loop with removeIf,
        to optimize this common pattern. This patch only modifies apparent ones.
        But we can apply this refactoring further to OAS phase in the future.

        * b3/B3MoveConstants.cpp:
        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        * wasm/WasmSignature.cpp:
        (JSC::Wasm::SignatureInformation::tryCleanup):

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

        [JSC] Use getEffectiveAddress more in JSC
        https://bugs.webkit.org/show_bug.cgi?id=180154

        Reviewed by Mark Lam.

        We can use MacroAssembler::getEffectiveAddress for stack height calculation.
        And we also add MacroAssembler::negPtr(src, dest) variation.

        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::negPtr):
        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::neg32):
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::neg32):
        (JSC::MacroAssemblerARM64::neg64):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::neg32):
        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::neg32):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::neg32):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::neg64):
        * dfg/DFGThunks.cpp:
        (JSC::DFG::osrEntryThunkGenerator):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
        * jit/SetupVarargsFrame.cpp:
        (JSC::emitSetVarargsFrame):

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

        jsc shell's flashHeapAccess() should not do JS work after releasing access to the heap.
        https://bugs.webkit.org/show_bug.cgi?id=180219
        <rdar://problem/35696536>

        Reviewed by Filip Pizlo.

        * jsc.cpp:
        (functionFlashHeapAccess):

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

        [DFG][FTL] operationHasIndexedProperty does not consider negative int32_t
        https://bugs.webkit.org/show_bug.cgi?id=180190

        Reviewed by Mark Lam.

        If DFG HasIndexedProperty node observes negative index, it goes to a slow
        path by calling operationHasIndexedProperty. The problem is that
        operationHasIndexedProperty does not account negative index. Negative index
        was used as uint32 array index.

        In this patch we add a path for negative index in operationHasIndexedProperty.
        And rename it to operationHasIndexedPropertyByInt to make intension clear.
        We also move operationHasIndexedPropertyByInt from JITOperations to DFGOperations
        since it is only used in DFG and FTL.

        While fixing this bug, we found that our op_in does not record OutOfBound feedback.
        This causes repeated OSR exit and significantly regresses the performance. We opened
        a bug to track this issue[1].

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

        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileHasIndexedProperty):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:

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

        Allow JSC command line tool to accept UTF8
        https://bugs.webkit.org/show_bug.cgi?id=180205

        Reviewed by Keith Miller.

        This unifies the UTF8 handling of interactive mode with that of source files.

        * jsc.cpp:
        (runInteractive):

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

        REGRESSION(r225314): [Linux] More than 2000 jsc tests are failing after r225314
        https://bugs.webkit.org/show_bug.cgi?id=180185

        Reviewed by Carlos Garcia Campos.

        After r225314, we start using AllocatorForMode::MustAlreadyHaveAllocator for JSRopeString's allocatorFor.
        But it is different from the original code used before r225314. Since DFGSpeculativeJIT::emitAllocateJSCell
        can accept nullptr allocator, the behavior of the original code is AllocatorForMode::AllocatorIfExists.
        And JSRopeString's allocator may not exist at this point if any JSRopeString is not allocated. But MakeRope
        DFG node can be emitted if we see untaken path includes String + String code.

        This patch fixes Linux JSC crashes by changing JSRopeString's AllocatorForMode to AllocatorIfExists.
        As a result, only one user of AllocatorForMode::MustAlreadyHaveAllocator is MaterializeNewObject in FTL.
        I'm not sure why this condition (MustAlreadyHaveAllocator) is ensured. But this code is the same to the
        original code used before r225314.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileMakeRope):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):

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

        CodeBlockSet::deleteUnmarkedAndUnreferenced can be a little more efficient
        https://bugs.webkit.org/show_bug.cgi?id=180108

        Reviewed by Saam Barati.
        
        This was creating a vector of things to remove and then removing them. I think I remember writing
        this code, and I did that because at the time we did not have removeAllMatching, which is
        definitely better. This is a minuscule optimization for Speedometer. I wanted to land this
        obvious improvement before I did more fundamental things to this code.

        * heap/CodeBlockSet.cpp:
        (JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):

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

        GC should support isoheaps
        https://bugs.webkit.org/show_bug.cgi?id=179288

        Reviewed by Saam Barati.
        
        This expands the power of the Subspace API in JSC:
        
        - Everything associated with describing the types of objects is now part of the HeapCellType class.
          We have different HeapCellTypes for different destruction strategies. Any Subspace can use any
          HeapCellType; these are orthogonal things.
        
        - There are now two variants of Subspace: CompleteSubspace, which can allocate any size objects using
          any AlignedMemoryAllocator; and IsoSubspace, which can allocate just one size of object and uses a
          special virtual memory pool for that purpose. Like bmalloc's IsoHeap, IsoSubspace hoards virtual
          pages but releases the physical pages as part of the respective allocator's scavenging policy
          (the Scavenger in bmalloc for IsoHeap and the incremental sweep and full sweep in Riptide for
          IsoSubspace).
        
        So far, this patch just puts subtypes of ExecutableBase in IsoSubspaces. If it works, we can use it
        for more things.
        
        This does not have any effect on JetStream (0.18% faster with p = 0.69).

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * bytecode/AccessCase.cpp:
        (JSC::AccessCase::generateImpl):
        * bytecode/ObjectAllocationProfileInlines.h:
        (JSC::ObjectAllocationProfile::initializeProfile):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
        (JSC::DFG::SpeculativeJIT::compileMakeRope):
        (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
        (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
        (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
        (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorageWithSizeImpl):
        (JSC::FTL::DFG::LowerDFGToB3::allocateObject):
        (JSC::FTL::DFG::LowerDFGToB3::allocatorForSize):
        * heap/AlignedMemoryAllocator.cpp:
        (JSC::AlignedMemoryAllocator::registerAllocator):
        (JSC::AlignedMemoryAllocator::registerSubspace):
        * heap/AlignedMemoryAllocator.h:
        (JSC::AlignedMemoryAllocator::firstAllocator const):
        * heap/AllocationFailureMode.h: Added.
        * heap/CompleteSubspace.cpp: Added.
        (JSC::CompleteSubspace::CompleteSubspace):
        (JSC::CompleteSubspace::~CompleteSubspace):
        (JSC::CompleteSubspace::allocatorFor):
        (JSC::CompleteSubspace::allocate):
        (JSC::CompleteSubspace::allocateNonVirtual):
        (JSC::CompleteSubspace::allocatorForSlow):
        (JSC::CompleteSubspace::allocateSlow):
        (JSC::CompleteSubspace::tryAllocateSlow):
        * heap/CompleteSubspace.h: Added.
        (JSC::CompleteSubspace::offsetOfAllocatorForSizeStep):
        (JSC::CompleteSubspace::allocatorForSizeStep):
        (JSC::CompleteSubspace::allocatorForNonVirtual):
        * heap/HeapCellType.cpp: Added.
        (JSC::HeapCellType::HeapCellType):
        (JSC::HeapCellType::~HeapCellType):
        (JSC::HeapCellType::finishSweep):
        (JSC::HeapCellType::destroy):
        * heap/HeapCellType.h: Added.
        (JSC::HeapCellType::attributes const):
        * heap/IsoAlignedMemoryAllocator.cpp: Added.
        (JSC::IsoAlignedMemoryAllocator::IsoAlignedMemoryAllocator):
        (JSC::IsoAlignedMemoryAllocator::~IsoAlignedMemoryAllocator):
        (JSC::IsoAlignedMemoryAllocator::tryAllocateAlignedMemory):
        (JSC::IsoAlignedMemoryAllocator::freeAlignedMemory):
        (JSC::IsoAlignedMemoryAllocator::dump const):
        * heap/IsoAlignedMemoryAllocator.h: Added.
        * heap/IsoSubspace.cpp: Added.
        (JSC::IsoSubspace::IsoSubspace):
        (JSC::IsoSubspace::~IsoSubspace):
        (JSC::IsoSubspace::allocatorFor):
        (JSC::IsoSubspace::allocatorForNonVirtual):
        (JSC::IsoSubspace::allocate):
        (JSC::IsoSubspace::allocateNonVirtual):
        * heap/IsoSubspace.h: Added.
        (JSC::IsoSubspace::size const):
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::MarkedAllocator):
        (JSC::MarkedAllocator::setSubspace):
        (JSC::MarkedAllocator::allocateSlowCase):
        (JSC::MarkedAllocator::tryAllocateSlowCase): Deleted.
        (JSC::MarkedAllocator::allocateSlowCaseImpl): Deleted.
        * heap/MarkedAllocator.h:
        (JSC::MarkedAllocator::nextAllocatorInAlignedMemoryAllocator const):
        (JSC::MarkedAllocator::setNextAllocatorInAlignedMemoryAllocator):
        * heap/MarkedAllocatorInlines.h:
        (JSC::MarkedAllocator::allocate):
        (JSC::MarkedAllocator::tryAllocate): Deleted.
        * heap/MarkedBlock.h:
        * heap/MarkedBlockInlines.h:
        (JSC::MarkedBlock::Handle::finishSweepKnowingHeapCellType):
        (JSC::MarkedBlock::Handle::finishSweepKnowingSubspace): Deleted.
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::addMarkedAllocator):
        * heap/MarkedSpace.h:
        * heap/Subspace.cpp:
        (JSC::Subspace::Subspace):
        (JSC::Subspace::initialize):
        (JSC::Subspace::finishSweep):
        (JSC::Subspace::destroy):
        (JSC::Subspace::prepareForAllocation):
        (JSC::Subspace::findEmptyBlockToSteal):
        (): Deleted.
        (JSC::Subspace::allocate): Deleted.
        (JSC::Subspace::tryAllocate): Deleted.
        (JSC::Subspace::allocatorForSlow): Deleted.
        (JSC::Subspace::allocateSlow): Deleted.
        (JSC::Subspace::tryAllocateSlow): Deleted.
        (JSC::Subspace::didAllocate): Deleted.
        * heap/Subspace.h:
        (JSC::Subspace::heapCellType const):
        (JSC::Subspace::nextSubspaceInAlignedMemoryAllocator const):
        (JSC::Subspace::setNextSubspaceInAlignedMemoryAllocator):
        (JSC::Subspace::offsetOfAllocatorForSizeStep): Deleted.
        (JSC::Subspace::allocatorForSizeStep): Deleted.
        (JSC::Subspace::tryAllocatorFor): Deleted.
        (JSC::Subspace::allocatorFor): Deleted.
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitAllocateJSObjectWithKnownSize):
        (JSC::AssemblyHelpers::emitAllocateVariableSized):
        (JSC::AssemblyHelpers::emitAllocateVariableSizedCell):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_new_object):
        * runtime/ButterflyInlines.h:
        (JSC::Butterfly::createUninitialized):
        (JSC::Butterfly::tryCreate):
        (JSC::Butterfly::growArrayRight):
        * runtime/DirectArguments.cpp:
        (JSC::DirectArguments::overrideThings):
        * runtime/DirectArguments.h:
        (JSC::DirectArguments::subspaceFor):
        * runtime/DirectEvalExecutable.h:
        * runtime/EvalExecutable.h:
        * runtime/ExecutableBase.h:
        (JSC::ExecutableBase::subspaceFor):
        * runtime/FunctionExecutable.h:
        * runtime/GenericArgumentsInlines.h:
        (JSC::GenericArguments<Type>::initModifiedArgumentsDescriptor):
        * runtime/HashMapImpl.h:
        (JSC::HashMapBuffer::create):
        * runtime/IndirectEvalExecutable.h:
        * runtime/JSArray.cpp:
        (JSC::JSArray::tryCreateUninitializedRestricted):
        (JSC::JSArray::unshiftCountSlowCase):
        * runtime/JSArray.h:
        (JSC::JSArray::tryCreate):
        * runtime/JSArrayBufferView.cpp:
        (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
        * runtime/JSCell.h:
        (JSC::subspaceFor):
        * runtime/JSCellInlines.h:
        (JSC::JSCell::subspaceFor):
        (JSC::tryAllocateCellHelper):
        (JSC::allocateCell):
        (JSC::tryAllocateCell):
        * runtime/JSDestructibleObject.h:
        (JSC::JSDestructibleObject::subspaceFor):
        * runtime/JSDestructibleObjectHeapCellType.cpp: Copied from Source/JavaScriptCore/runtime/JSDestructibleObjectSubspace.cpp.
        (JSC::JSDestructibleObjectHeapCellType::JSDestructibleObjectHeapCellType):
        (JSC::JSDestructibleObjectHeapCellType::~JSDestructibleObjectHeapCellType):
        (JSC::JSDestructibleObjectHeapCellType::finishSweep):
        (JSC::JSDestructibleObjectHeapCellType::destroy):
        (JSC::JSDestructibleObjectSubspace::JSDestructibleObjectSubspace): Deleted.
        (JSC::JSDestructibleObjectSubspace::~JSDestructibleObjectSubspace): Deleted.
        (JSC::JSDestructibleObjectSubspace::finishSweep): Deleted.
        (JSC::JSDestructibleObjectSubspace::destroy): Deleted.
        * runtime/JSDestructibleObjectHeapCellType.h: Copied from Source/JavaScriptCore/runtime/JSDestructibleObjectSubspace.h.
        * runtime/JSDestructibleObjectSubspace.cpp: Removed.
        * runtime/JSDestructibleObjectSubspace.h: Removed.
        * runtime/JSLexicalEnvironment.h:
        (JSC::JSLexicalEnvironment::subspaceFor):
        * runtime/JSSegmentedVariableObject.h:
        (JSC::JSSegmentedVariableObject::subspaceFor):
        * runtime/JSSegmentedVariableObjectHeapCellType.cpp: Copied from Source/JavaScriptCore/runtime/JSSegmentedVariableObjectSubspace.cpp.
        (JSC::JSSegmentedVariableObjectHeapCellType::JSSegmentedVariableObjectHeapCellType):
        (JSC::JSSegmentedVariableObjectHeapCellType::~JSSegmentedVariableObjectHeapCellType):
        (JSC::JSSegmentedVariableObjectHeapCellType::finishSweep):
        (JSC::JSSegmentedVariableObjectHeapCellType::destroy):
        (JSC::JSSegmentedVariableObjectSubspace::JSSegmentedVariableObjectSubspace): Deleted.
        (JSC::JSSegmentedVariableObjectSubspace::~JSSegmentedVariableObjectSubspace): Deleted.
        (JSC::JSSegmentedVariableObjectSubspace::finishSweep): Deleted.
        (JSC::JSSegmentedVariableObjectSubspace::destroy): Deleted.
        * runtime/JSSegmentedVariableObjectHeapCellType.h: Copied from Source/JavaScriptCore/runtime/JSSegmentedVariableObjectSubspace.h.
        * runtime/JSSegmentedVariableObjectSubspace.cpp: Removed.
        * runtime/JSSegmentedVariableObjectSubspace.h: Removed.
        * runtime/JSString.h:
        (JSC::JSString::subspaceFor):
        * runtime/JSStringHeapCellType.cpp: Copied from Source/JavaScriptCore/runtime/JSStringSubspace.cpp.
        (JSC::JSStringHeapCellType::JSStringHeapCellType):
        (JSC::JSStringHeapCellType::~JSStringHeapCellType):
        (JSC::JSStringHeapCellType::finishSweep):
        (JSC::JSStringHeapCellType::destroy):
        (JSC::JSStringSubspace::JSStringSubspace): Deleted.
        (JSC::JSStringSubspace::~JSStringSubspace): Deleted.
        (JSC::JSStringSubspace::finishSweep): Deleted.
        (JSC::JSStringSubspace::destroy): Deleted.
        * runtime/JSStringHeapCellType.h: Copied from Source/JavaScriptCore/runtime/JSStringSubspace.h.
        * runtime/JSStringSubspace.cpp: Removed.
        * runtime/JSStringSubspace.h: Removed.
        * runtime/ModuleProgramExecutable.h:
        * runtime/NativeExecutable.h:
        * runtime/ProgramExecutable.h:
        * runtime/RegExpMatchesArray.h:
        (JSC::tryCreateUninitializedRegExpMatchesArray):
        * runtime/ScopedArguments.h:
        (JSC::ScopedArguments::subspaceFor):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        (JSC::VM::gigacageAuxiliarySpace):
        * wasm/js/JSWebAssemblyCodeBlock.h:
        * wasm/js/JSWebAssemblyCodeBlockHeapCellType.cpp: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyCodeBlockSubspace.cpp.
        (JSC::JSWebAssemblyCodeBlockHeapCellType::JSWebAssemblyCodeBlockHeapCellType):
        (JSC::JSWebAssemblyCodeBlockHeapCellType::~JSWebAssemblyCodeBlockHeapCellType):
        (JSC::JSWebAssemblyCodeBlockHeapCellType::finishSweep):
        (JSC::JSWebAssemblyCodeBlockHeapCellType::destroy):
        (JSC::JSWebAssemblyCodeBlockSubspace::JSWebAssemblyCodeBlockSubspace): Deleted.
        (JSC::JSWebAssemblyCodeBlockSubspace::~JSWebAssemblyCodeBlockSubspace): Deleted.
        (JSC::JSWebAssemblyCodeBlockSubspace::finishSweep): Deleted.
        (JSC::JSWebAssemblyCodeBlockSubspace::destroy): Deleted.
        * wasm/js/JSWebAssemblyCodeBlockHeapCellType.h: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyCodeBlockSubspace.h.
        * wasm/js/JSWebAssemblyCodeBlockSubspace.cpp: Removed.
        * wasm/js/JSWebAssemblyCodeBlockSubspace.h: Removed.
        * wasm/js/JSWebAssemblyMemory.h:
        (JSC::JSWebAssemblyMemory::subspaceFor):

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

        Remove pointer caging for double arrays
        https://bugs.webkit.org/show_bug.cgi?id=180163

        Reviewed by Mark Lam.

        This patch removes pointer caging from double arrays. Like
        my previous removals of pointer caging, this is a security vs
        performance tradeoff. We believe that butterflies being allocated
        in the cage and with a 32GB runway gives us enough security that
        pointer caging the butterfly just for double arrays does not add
        enough security benefit for the performance hit it incurs.
        
        This patch also removes the GetButterflyWithoutCaging node and
        the FixedButterflyAccessUncaging phase. The node is no longer needed
        because now all GetButterfly nodes are not caged. The phase is removed
        since we no longer have two nodes.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixedButterflyAccessUncagingPhase.cpp: Removed.
        * dfg/DFGFixedButterflyAccessUncagingPhase.h: Removed.
        * 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::compileSpread):
        (JSC::DFG::SpeculativeJIT::compileArraySlice):
        (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):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitDoubleLoad):
        (JSC::JIT::emitGenericContiguousPutByVal):
        * runtime/Butterfly.h:
        (JSC::Butterfly::pointer):
        (JSC::Butterfly::contiguousDouble):
        (JSC::Butterfly::caged): Deleted.
        * runtime/ButterflyInlines.h:
        (JSC::Butterfly::createOrGrowPropertyStorage):
        * runtime/JSObject.cpp:
        (JSC::JSObject::ensureLengthSlow):
        (JSC::JSObject::reallocateAndShrinkButterfly):

2017-11-29  Stanislav Ocovaj  <stanislav.ocovaj@rt-rk.com>

        [MIPS][JSC] Implement MacroAssembler::probe support on MIPS
        https://bugs.webkit.org/show_bug.cgi?id=175447

        Reviewed by Carlos Alberto Lopez Perez.

        This patch allows DFG JIT to be enabled on MIPS platforms.

        * Sources.txt:
        * assembler/MIPSAssembler.h:
        (JSC::MIPSAssembler::lastSPRegister):
        (JSC::MIPSAssembler::numberOfSPRegisters):
        (JSC::MIPSAssembler::sprName):
        * assembler/MacroAssemblerMIPS.cpp: Added.
        (JSC::MacroAssembler::probe):
        * assembler/ProbeContext.cpp:
        (JSC::Probe::executeProbe):
        * assembler/ProbeContext.h:
        (JSC::Probe::CPUState::pc):
        * assembler/testmasm.cpp:
        (JSC::isSpecialGPR):
        (JSC::testProbePreservesGPRS):
        (JSC::testProbeModifiesStackPointer):
        (JSC::testProbeModifiesStackValues):

2017-11-29  Matt Lewis  <jlewis3@apple.com>

        Unreviewed, rolling out r225286.

        The source files within this patch have been marked as
        executable.

        Reverted changeset:

        "[MIPS][JSC] Implement MacroAssembler::probe support on MIPS"
        https://bugs.webkit.org/show_bug.cgi?id=175447
        https://trac.webkit.org/changeset/225286

2017-11-29  Alex Christensen  <achristensen@webkit.org>

        Fix Mac CMake build.

        * PlatformMac.cmake:

2017-11-29  Stanislav Ocovaj  <stanislav.ocovaj@rt-rk.com>

        [MIPS][JSC] Implement MacroAssembler::probe support on MIPS
        https://bugs.webkit.org/show_bug.cgi?id=175447

        Reviewed by Carlos Alberto Lopez Perez.

        This patch allows DFG JIT to be enabled on MIPS platforms.

        * Sources.txt:
        * assembler/MIPSAssembler.h:
        (JSC::MIPSAssembler::lastSPRegister):
        (JSC::MIPSAssembler::numberOfSPRegisters):
        (JSC::MIPSAssembler::sprName):
        * assembler/MacroAssemblerMIPS.cpp: Added.
        (JSC::MacroAssembler::probe):
        * assembler/ProbeContext.cpp:
        (JSC::Probe::executeProbe):
        * assembler/ProbeContext.h:
        (JSC::Probe::CPUState::pc):
        * assembler/testmasm.cpp:
        (JSC::isSpecialGPR):
        (JSC::testProbePreservesGPRS):
        (JSC::testProbeModifiesStackPointer):
        (JSC::testProbeModifiesStackValues):

2017-11-28  JF Bastien  <jfbastien@apple.com>

        Strict and sloppy functions shouldn't share structure
        https://bugs.webkit.org/show_bug.cgi?id=180103
        <rdar://problem/35667847>

        Reviewed by Saam Barati.

        Sloppy and strict functions don't act the same when it comes to
        arguments, caller, and callee. Sharing a structure means that
        anything that is cached gets shared, and that's incorrect.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNewFunction):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::create): the second ::create is always strict
        because it applies to native functions.
        * runtime/JSFunctionInlines.h:
        (JSC::JSFunction::createWithInvalidatedReallocationWatchpoint):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::strictFunctionStructure const):
        (JSC::JSGlobalObject::sloppyFunctionStructure const):
        (JSC::JSGlobalObject::nativeStdFunctionStructure const):
        (JSC::JSGlobalObject::functionStructure const): Deleted. Renamed.
        (JSC::JSGlobalObject::namedFunctionStructure const): Deleted. Drive-by, unused.

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

        [JSC] Add MacroAssembler::getEffectiveAddress in all platforms
        https://bugs.webkit.org/show_bug.cgi?id=180070

        Reviewed by Saam Barati.

        This patch adds getEffectiveAddress in all JIT platforms.
        This is abstracted version of x86 lea.

        We also fix a bug in Yarr that uses branch32 instead of branchPtr for addresses.

        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::getEffectiveAddress):
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::getEffectiveAddress):
        (JSC::MacroAssemblerARM64::getEffectiveAddress64): Deleted.
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::getEffectiveAddress):
        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::getEffectiveAddress):
        * assembler/MacroAssemblerX86.h:
        (JSC::MacroAssemblerX86::getEffectiveAddress):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::getEffectiveAddress):
        (JSC::MacroAssemblerX86_64::getEffectiveAddress64): Deleted.
        * assembler/testmasm.cpp:
        (JSC::testGetEffectiveAddress):
        (JSC::run):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArrayPush):
        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::tryReadUnicodeCharImpl):
        (JSC::Yarr::YarrGenerator::tryReadUnicodeChar):

2017-11-29  Robin Morisset  <rmorisset@apple.com>

        The recursive tail call optimisation is wrong on closures
        https://bugs.webkit.org/show_bug.cgi?id=179835

        Reviewed by Saam Barati.

        The problem is that we only check the executable of the callee, not whatever variables might have been captured.
        As a stopgap measure this patch just does not do the optimisation for closures.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):

2017-11-28  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Cleanup Inspector classes be more consistent about using fast malloc / noncopyable
        https://bugs.webkit.org/show_bug.cgi?id=180119

        Reviewed by Devin Rousso.

        * inspector/InjectedScriptManager.h:
        * inspector/JSGlobalObjectScriptDebugServer.h:
        * inspector/agents/InspectorHeapAgent.h:
        * inspector/agents/InspectorRuntimeAgent.h:
        * inspector/agents/InspectorScriptProfilerAgent.h:
        * inspector/agents/JSGlobalObjectRuntimeAgent.h:

2017-11-28  Joseph Pecoraro  <pecoraro@apple.com>

        ServiceWorker Inspector: Frontend changes to support Network tab and sub resources
        https://bugs.webkit.org/show_bug.cgi?id=179642
        <rdar://problem/35517704>

        Reviewed by Brian Burg.

        * inspector/protocol/Network.json:
        Expose the NetworkAgent for a Service Worker inspector.

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

        [Cocoa] Clean up names of conversion methods after renaming InspectorValue to JSON::Value
        https://bugs.webkit.org/show_bug.cgi?id=179696

        Reviewed by Timothy Hatcher.

        * inspector/scripts/codegen/generate_objc_header.py:
        (ObjCHeaderGenerator._generate_type_interface):
        * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
        (ObjCProtocolTypesImplementationGenerator.generate_type_implementation):
        (ObjCProtocolTypesImplementationGenerator._generate_init_method_for_protocol_object):
        (ObjCProtocolTypesImplementationGenerator._generate_init_method_for_json_object): Deleted.
        * inspector/scripts/codegen/objc_generator.py:
        (ObjCGenerator.protocol_type_for_raw_name):
        (ObjCGenerator.objc_protocol_export_expression_for_variable):
        (ObjCGenerator.objc_protocol_export_expression_for_variable.is):
        (ObjCGenerator.objc_protocol_import_expression_for_variable):
        (ObjCGenerator.objc_protocol_import_expression_for_variable.is):
        (ObjCGenerator.objc_to_protocol_expression_for_member.is):
        (ObjCGenerator.objc_to_protocol_expression_for_member):
        (ObjCGenerator.protocol_to_objc_expression_for_member.is):
        (ObjCGenerator.protocol_to_objc_expression_for_member):
        (ObjCGenerator.protocol_to_objc_code_block_for_object_member):
        (ObjCGenerator.objc_setter_method_for_member_internal):
        (ObjCGenerator.objc_getter_method_for_member_internal):
        * 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/events-with-optional-parameters.json-result:
        * inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result:
        * inspector/scripts/tests/generic/expected/shadowed-optional-type-setters.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/mac/expected/definitions-with-mac-platform.json-result:

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

        JavaScript rest function parameter with negative index leads to bad DFG abstract interpretation
        https://bugs.webkit.org/show_bug.cgi?id=180051
        <rdar://problem/35614371>

        Reviewed by Saam Barati.

        Checking for int32 isn't sufficient when uint32 is expected
        afterwards. While we're here, also use Checked<>.

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

2017-11-14  Carlos Garcia Campos  <cgarcia@igalia.com>

        Move JSONValues to WTF and convert uses of InspectorValues.h to JSONValues.h
        https://bugs.webkit.org/show_bug.cgi?id=173793

        Reviewed by Joseph Pecoraro.

        Based on patch by Brian Burg.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * bindings/ScriptValue.cpp:
        (Inspector::jsToInspectorValue):
        (Inspector::toInspectorValue):
        (Deprecated::ScriptValue::toInspectorValue const):
        * bindings/ScriptValue.h:
        * inspector/AsyncStackTrace.cpp:
        * inspector/ConsoleMessage.cpp:
        * inspector/ContentSearchUtilities.cpp:
        * inspector/DeprecatedInspectorValues.cpp: Added.
        * inspector/DeprecatedInspectorValues.h: Added.
        Keep the old symbols around in JavaScriptCore so that builds with the
        public iOS SDK continue to work. These older SDKs include a version of
        WebInspector.framework that expects to find InspectorArray and other
        symbols in JavaScriptCore.framework.

        * inspector/InjectedScript.cpp:
        (Inspector::InjectedScript::getFunctionDetails):
        (Inspector::InjectedScript::functionDetails):
        (Inspector::InjectedScript::getPreview):
        (Inspector::InjectedScript::getProperties):
        (Inspector::InjectedScript::getDisplayableProperties):
        (Inspector::InjectedScript::getInternalProperties):
        (Inspector::InjectedScript::getCollectionEntries):
        (Inspector::InjectedScript::saveResult):
        (Inspector::InjectedScript::wrapCallFrames const):
        (Inspector::InjectedScript::wrapObject const):
        (Inspector::InjectedScript::wrapTable const):
        (Inspector::InjectedScript::previewValue const):
        (Inspector::InjectedScript::setExceptionValue):
        (Inspector::InjectedScript::clearExceptionValue):
        (Inspector::InjectedScript::inspectObject):
        (Inspector::InjectedScript::releaseObject):
        * inspector/InjectedScriptBase.cpp:
        (Inspector::InjectedScriptBase::makeCall):
        (Inspector::InjectedScriptBase::makeEvalCall):
        * inspector/InjectedScriptBase.h:
        * inspector/InjectedScriptManager.cpp:
        (Inspector::InjectedScriptManager::injectedScriptForObjectId):
        * inspector/InspectorBackendDispatcher.cpp:
        (Inspector::BackendDispatcher::CallbackBase::sendSuccess):
        (Inspector::BackendDispatcher::dispatch):
        (Inspector::BackendDispatcher::sendResponse):
        (Inspector::BackendDispatcher::sendPendingErrors):
        (Inspector::BackendDispatcher::getPropertyValue):
        (Inspector::castToInteger):
        (Inspector::castToNumber):
        (Inspector::BackendDispatcher::getInteger):
        (Inspector::BackendDispatcher::getDouble):
        (Inspector::BackendDispatcher::getString):
        (Inspector::BackendDispatcher::getBoolean):
        (Inspector::BackendDispatcher::getObject):
        (Inspector::BackendDispatcher::getArray):
        (Inspector::BackendDispatcher::getValue):
        * inspector/InspectorBackendDispatcher.h:
        We need to keep around the sendResponse() variant with a parameter that
        has the InspectorObject type, as older WebInspector.framework versions
        expect this symbol to exist. Introduce a variant with arity 3 that can
        be used in TOT so as to avoid having two methods with the same name, arity, and
        different parameter types.

        When system WebInspector.framework is updated, we can remove the legacy
        method variant that uses the InspectorObject type. At that point, we can
        transition TOT to use the 2-arity variant, and delete the 3-arity variant
        when system WebInspector.framework is updated once more to use the 2-arity one.

        * inspector/InspectorProtocolTypes.h:
        (Inspector::Protocol::Array::openAccessors):
        (Inspector::Protocol::PrimitiveBindingTraits::assertValueHasExpectedType):
        (Inspector::Protocol::BindingTraits<Protocol::Array<T>>::runtimeCast):
        (Inspector::Protocol::BindingTraits<Protocol::Array<T>>::assertValueHasExpectedType):
        (Inspector::Protocol::BindingTraits<JSON::Value>::assertValueHasExpectedType):
        * inspector/ScriptCallFrame.cpp:
        * inspector/ScriptCallStack.cpp:
        * inspector/agents/InspectorAgent.cpp:
        (Inspector::InspectorAgent::inspect):
        * inspector/agents/InspectorAgent.h:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::buildAssertPauseReason):
        (Inspector::buildCSPViolationPauseReason):
        (Inspector::InspectorDebuggerAgent::buildBreakpointPauseReason):
        (Inspector::InspectorDebuggerAgent::buildExceptionPauseReason):
        (Inspector::buildObjectForBreakpointCookie):
        (Inspector::InspectorDebuggerAgent::breakpointActionsFromProtocol):
        (Inspector::parseLocation):
        (Inspector::InspectorDebuggerAgent::setBreakpointByUrl):
        (Inspector::InspectorDebuggerAgent::setBreakpoint):
        (Inspector::InspectorDebuggerAgent::continueToLocation):
        (Inspector::InspectorDebuggerAgent::schedulePauseOnNextStatement):
        (Inspector::InspectorDebuggerAgent::didParseSource):
        (Inspector::InspectorDebuggerAgent::breakProgram):
        * inspector/agents/InspectorDebuggerAgent.h:
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::callFunctionOn):
        (Inspector::InspectorRuntimeAgent::saveResult):
        (Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets):
        * inspector/agents/InspectorRuntimeAgent.h:
        * inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py:
        (CppBackendDispatcherHeaderGenerator._generate_dispatcher_declaration_for_command):
        * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
        (CppBackendDispatcherImplementationGenerator.generate_output):
        (CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command):
        * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_header.py:
        (CppFrontendDispatcherHeaderGenerator.generate_output):
        * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
        (CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_event):
        * inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
        (_generate_unchecked_setter_for_member):
        * inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py:
        (CppProtocolTypesImplementationGenerator):
        * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
        (ObjCBackendDispatcherImplementationGenerator.generate_output):
        (ObjCBackendDispatcherImplementationGenerator._generate_success_block_for_command):
        * inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
        (ObjCFrontendDispatcherImplementationGenerator.generate_output):
        (ObjCFrontendDispatcherImplementationGenerator._generate_event):
        (ObjCFrontendDispatcherImplementationGenerator._generate_event_out_parameters):
        * inspector/scripts/codegen/generate_objc_internal_header.py:
        (ObjCInternalHeaderGenerator.generate_output):
        * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
        (ObjCProtocolTypesImplementationGenerator.generate_output):
        * inspector/scripts/codegen/generator.py:
        * 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:

2017-11-28  Robin Morisset  <rmorisset@apple.com>

        Support recursive tail call optimization for polymorphic calls
        https://bugs.webkit.org/show_bug.cgi?id=178390

        Reviewed by Saam Barati.

        Comes with a large but fairly simple refactoring: the inlining path for varargs and non-varargs calls now converge a lot later,
        eliminating some redundant checks, and simplifying a few parts of the inlining pipeline.

        Also removes some dead code from inlineCall(): there was a special path for when m_continuationBlock is null, but it should never be (now checked with RELEASE_ASSERT).

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleCall):
        (JSC::DFG::ByteCodeParser::handleVarargsCall):
        (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
        (JSC::DFG::ByteCodeParser::inlineCall):
        (JSC::DFG::ByteCodeParser::handleCallVariant):
        (JSC::DFG::ByteCodeParser::handleVarargsInlining):
        (JSC::DFG::ByteCodeParser::getInliningBalance):
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::attemptToInlineCall): Deleted.

2017-11-27  Saam Barati  <sbarati@apple.com>

        Spread can escape when CreateRest does not
        https://bugs.webkit.org/show_bug.cgi?id=180057
        <rdar://problem/35676119>

        Reviewed by JF Bastien.

        We previously did not handle Spread(PhantomCreateRest) only because I did not
        think it was possible to generate this IR. I was wrong. We can generate
        such IR when we have a PutStack(Spread) but nothing escapes the CreateRest.
        This IR is rare to generate since we normally don't PutStack(Spread) because
        the SetLocal almost always gets eliminated because of how our bytecode generates
        op_spread. However, there exists a test case showing it is possible. Supporting
        this IR pattern in FTLLower is trivial. This patch implements it and rewrites
        the Validation rule for Spread.

        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGValidate.cpp:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileSpread):
        * runtime/JSFixedArray.h:
        (JSC::JSFixedArray::tryCreate):

2017-11-27  Don Olmstead  <don.olmstead@sony.com>

        [CMake][Win] Conditionally select DLL CRT or static CRT
        https://bugs.webkit.org/show_bug.cgi?id=170594

        Reviewed by Alex Christensen.

        * shell/PlatformWin.cmake:

2017-11-27  Saam Barati  <sbarati@apple.com>

        Having a bad time watchpoint firing during compilation revealed a racy assertion
        https://bugs.webkit.org/show_bug.cgi?id=180048
        <rdar://problem/35700009>

        Reviewed by Mark Lam.

        While a DFG compilation is watching the having a bad time watchpoint, it was
        asserting that the rest parameter structure has indexing type ArrayWithContiguous.
        However, if the having a bad time watchpoint fires during the compilation,
        this particular structure will no longer have ArrayWithContiguous indexing type.
        This patch fixes this racy assertion to be aware that the watchpoint may fire
        during compilation.

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

2017-11-27  Tim Horton  <timothy_horton@apple.com>

        One too many zeroes in macOS version number in FeatureDefines
        https://bugs.webkit.org/show_bug.cgi?id=180011

        Reviewed by Dan Bernstein.

        * Configurations/FeatureDefines.xcconfig:

2017-11-27  Robin Morisset  <rmorisset@apple.com>

        Update DFGSafeToExecute to be aware that ArrayPush is now a varargs node
        https://bugs.webkit.org/show_bug.cgi?id=179821

        Reviewed by Saam Barati.

        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):

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

        [DFG] Add NormalizeMapKey DFG IR
        https://bugs.webkit.org/show_bug.cgi?id=179912

        Reviewed by Saam Barati.

        This patch introduces NormalizeMapKey DFG node. It executes what normalizeMapKey does in inlined manner.
        By separating this from MapHash and Map/Set related operations, we can perform CSE onto that, and we
        do not need to call normalizeMapKey conservatively in DFG operations.
        This can reduce slow path case in Untyped GetMapBucket since we can normalize keys in DFG/FTL.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::fixupNormalizeMapKey):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNormalizeMapKey):
        * 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::compileMapHash):
        (JSC::FTL::DFG::LowerDFGToB3::compileNormalizeMapKey):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucket):
        * runtime/HashMapImpl.h:

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

        [FTL] Support DeleteById and DeleteByVal
        https://bugs.webkit.org/show_bug.cgi?id=180022

        Reviewed by Saam Barati.

        We should increase the coverage of FTL. Even if the code includes DeleteById,
        it does not mean that remaining part of the code should not be optimized in FTL.
        Right now, even CallEval and `with` scope are handled in FTL.

        This patch just adds DeleteById and DeleteByVal handling to FTL to allow optimizing
        code including them.

        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileDeleteById):
        (JSC::FTL::DFG::LowerDFGToB3::compileDeleteByVal):

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

        [DFG] Introduce {Set,Map,WeakMap}Fields
        https://bugs.webkit.org/show_bug.cgi?id=179925

        Reviewed by Saam Barati.

        SetAdd and MapSet uses `write(MiscFields)`, but it is not correct. It accidentally
        writes readonly MiscFields which is used by various nodes and make optimization
        conservative.

        We introduce JSSetFields, JSMapFields, and JSWeakMapFields to precisely model clobberizing of Map, Set, and WeakMap.

        * dfg/DFGAbstractHeap.h:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGHeapLocation.h:
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasBucketOwnerType):

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

        [JSC] Remove JSStringBuilder
        https://bugs.webkit.org/show_bug.cgi?id=180016

        Reviewed by Saam Barati.

        JSStringBuilder is replaced with WTF::StringBuilder.
        This patch removes remaning uses and drop JSStringBuilder.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/ArrayPrototype.cpp:
        * runtime/AsyncFunctionPrototype.cpp:
        * runtime/AsyncGeneratorFunctionPrototype.cpp:
        * runtime/ErrorPrototype.cpp:
        * runtime/FunctionPrototype.cpp:
        * runtime/GeneratorFunctionPrototype.cpp:
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::decode):
        (JSC::globalFuncEscape):
        * runtime/JSStringBuilder.h: Removed.
        * runtime/JSStringInlines.h:
        (JSC::jsMakeNontrivialString):
        * runtime/RegExpPrototype.cpp:
        * runtime/StringPrototype.cpp:

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

        [DFG] Remove GetLocalUnlinked
        https://bugs.webkit.org/show_bug.cgi?id=180017

        Reviewed by Saam Barati.

        Since DFGArgumentsSimplificationPhase is removed 2 years ago, GetLocalUnlinked is no longer used in DFG.
        This patch just removes it.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGCommon.h:
        * 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::hasUnlinkedLocal):
        (JSC::DFG::Node::convertToGetLocalUnlinked): Deleted.
        (JSC::DFG::Node::convertToGetLocal): Deleted.
        (JSC::DFG::Node::hasUnlinkedMachineLocal): Deleted.
        (JSC::DFG::Node::setUnlinkedMachineLocal): Deleted.
        (JSC::DFG::Node::unlinkedMachineLocal): Deleted.
        * 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/DFGStackLayoutPhase.cpp:
        (JSC::DFG::StackLayoutPhase::run):
        * dfg/DFGValidate.cpp:

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

        Make ArgList::data() private again when we can remove callWasmFunction().
        https://bugs.webkit.org/show_bug.cgi?id=168582

        Reviewed by JF Bastien.

        Make ArgList::data() private since we already removed callWasmFunction.

        * runtime/ArgList.h:

2016-08-05  Darin Adler  <darin@apple.com>

        Fix some minor problems in the StringImpl header
        https://bugs.webkit.org/show_bug.cgi?id=160630

        Reviewed by Brent Fulgham.

        * inspector/ContentSearchUtilities.cpp: Removed a lot of unneeded explicit
        Yarr namespacing since we use "using namespace" in this file.

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

        Fix CLoop::sanitizeStack() bug where it was clearing part of the JS stack in use.
        https://bugs.webkit.org/show_bug.cgi?id=179936
        <rdar://problem/35623998>

        Reviewed by Saam Barati.

        This issue was uncovered when we enabled --useDollarVM=true on the JSC tests.
        See https://bugs.webkit.org/show_bug.cgi?id=179684.

        Basically, in the case of the failing test we observed, op_tail_call_forward_arguments
        was allocating stack space to stash arguments (to be forwarded) and new frame
        info.  The location of this new stash space happens to lie beyond the top of frame
        of the tail call caller frame.  After stashing the arguments, the code proceeded
        to load the callee codeBlock.  This triggered an allocation, which in turn,
        triggered stack sanitization.  The CLoop stack sanitizer was relying on
        frame->topOfFrame() to tell it where the top of the used stack is.  In this case,
        that turned out to be inadequate.  As a result, part of the stashed data was
        zeroed out, and subsequently led to a crash.

        This bug does not affect JIT builds (i.e. the ASM LLint) for 2 reasons:
        1. JIT builds do stack sanitization in the LLInt code itself (different from the
           CLoop implementation), and the sanitizer there is aware of the true top of
           stack value (i.e. the stack pointer).
        2. JIT builds don't use a parallel stack like the CLoop.  The presence of the
           parallel stack is one condition necessary for reproducing this issue.

        The fix is to make the CLoop record the stack pointer in CLoopStack::m_currentStackPointer
        every time before it calls out to native C++ code.  This also brings the CLoop's
        behavior closer to hardware behavior where we can know where the stack pointer
        is after calling from JS back into native C++ code, which makes it easier to
        reason about correctness.       

        Also simplified the various stack boundary calculations (removed the +1 and -1
        adjustments).  The CLoopStack bounds are now:

            reservationTop(): the lowest reserved address that can be within stack bounds.
            m_commitTop: the lowest address within stack bounds that has been committed.
            lowAddress() aka m_end: the lowest stack address that JS code can use.
            m_lastStackPointer: cache of the last m_currentStackPointer value.
            m_currentStackPointer: the CLoopStack stack pointer value when calling from JS into C++ code.
            highAddress(): the highest address just beyond the bounds of the stack.

        Also deleted some unneeded code.

        * interpreter/CLoopStack.cpp:
        (JSC::CLoopStack::CLoopStack):
        (JSC::CLoopStack::gatherConservativeRoots):
        (JSC::CLoopStack::sanitizeStack):
        (JSC::CLoopStack::setSoftReservedZoneSize):
        * interpreter/CLoopStack.h:
        (JSC::CLoopStack::setCurrentStackPointer):
        (JSC::CLoopStack::lowAddress const):

        (JSC::CLoopStack::baseOfStack const): Deleted.
        - Not needed after we simplified the code and removed all the +1/-1 adjustments.
          Now, it has the exact same value as highAddress() and can be removed.

        * interpreter/CLoopStackInlines.h:
        (JSC::CLoopStack::ensureCapacityFor):
        (JSC::CLoopStack::currentStackPointer):
        (JSC::CLoopStack::setCLoopStackLimit):

        (JSC::CLoopStack::topOfFrameFor): Deleted.
        - Not needed.

        (JSC::CLoopStack::topOfStack): Deleted.
        - Supplanted by currentStackPointer().

        (JSC::CLoopStack::shrink): Deleted.
        - This is unused.

        * llint/LowLevelInterpreter.cpp:
        (JSC::CLoop::execute):
        - Introduce a StackPointerScope to restore the original CLoopStack::m_currentStackPointer
          upon exitting the interpreter loop.

        * offlineasm/cloop.rb:
        - Added setting of CLoopStack::m_currentStackPointer at boundary points where we
          call from JS into C++ code.

        * tools/VMInspector.h:
        - Added some default argument values. These were being used while debugging this
          issue.

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

        [JSC] Make empty key as deleted mark in HashMapBucket and drop m_deleted field
        https://bugs.webkit.org/show_bug.cgi?id=179923

        Reviewed by Darin Adler.

        We do not set empty as a key in HashMapBucket since JSMap / JSSet can expose it to users.
        So we can use it as a marker of deleted bucket.

        This patch uses empty key as a deleted flag, and drop m_deleted field of HashMapBucket.
        It shrinks the size of HashMapBucket much.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetMapBucketNext):
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucketNext):
        * runtime/HashMapImpl.h:
        (JSC::HashMapBucket::createSentinel):
        We make sentinel bucket as (undefined, undefined) since DFG/FTL can load a value from sentinels.
        While the sentinel's deleted flag becomes false since key is set, it is not a problem since deleted
        flag of sentinel bucket is not used.

        (JSC::HashMapBucket::HashMapBucket):
        (JSC::HashMapBucket::deleted const):
        (JSC::HashMapBucket::makeDeleted):
        (JSC::HashMapImpl::remove):
        (JSC::HashMapImpl::clear):
        (JSC::HashMapImpl::setUpHeadAndTail):
        (JSC::HashMapImpl::addNormalizedInternal):
        (JSC::HashMapBucket::setDeleted): Deleted.
        (JSC::HashMapBucket::offsetOfDeleted): Deleted.
        (): Deleted.

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

        Move unsafe jsc shell test functions to the $vm object.
        https://bugs.webkit.org/show_bug.cgi?id=179980

        Reviewed by Yusuke Suzuki.

        Also removed setElementRoot() which was not used.

        * jsc.cpp:
        (GlobalObject::finishCreation):
        (WTF::Element::Element): Deleted.
        (WTF::Element::root const): Deleted.
        (WTF::Element::setRoot): Deleted.
        (WTF::Element::create): Deleted.
        (WTF::Element::visitChildren): Deleted.
        (WTF::Element::createStructure): Deleted.
        (WTF::Root::Root): Deleted.
        (WTF::Root::element): Deleted.
        (WTF::Root::setElement): Deleted.
        (WTF::Root::create): Deleted.
        (WTF::Root::createStructure): Deleted.
        (WTF::Root::visitChildren): Deleted.
        (WTF::ImpureGetter::ImpureGetter): Deleted.
        (WTF::ImpureGetter::createStructure): Deleted.
        (WTF::ImpureGetter::create): Deleted.
        (WTF::ImpureGetter::finishCreation): Deleted.
        (WTF::ImpureGetter::getOwnPropertySlot): Deleted.
        (WTF::ImpureGetter::visitChildren): Deleted.
        (WTF::ImpureGetter::setDelegate): Deleted.
        (WTF::CustomGetter::CustomGetter): Deleted.
        (WTF::CustomGetter::createStructure): Deleted.
        (WTF::CustomGetter::create): Deleted.
        (WTF::CustomGetter::getOwnPropertySlot): Deleted.
        (WTF::CustomGetter::customGetter): Deleted.
        (WTF::CustomGetter::customGetterAcessor): Deleted.
        (WTF::RuntimeArray::create): Deleted.
        (WTF::RuntimeArray::~RuntimeArray): Deleted.
        (WTF::RuntimeArray::destroy): Deleted.
        (WTF::RuntimeArray::getOwnPropertySlot): Deleted.
        (WTF::RuntimeArray::getOwnPropertySlotByIndex): Deleted.
        (WTF::RuntimeArray::put): Deleted.
        (WTF::RuntimeArray::deleteProperty): Deleted.
        (WTF::RuntimeArray::getLength const): Deleted.
        (WTF::RuntimeArray::createPrototype): Deleted.
        (WTF::RuntimeArray::createStructure): Deleted.
        (WTF::RuntimeArray::finishCreation): Deleted.
        (WTF::RuntimeArray::RuntimeArray): Deleted.
        (WTF::RuntimeArray::lengthGetter): Deleted.
        (WTF::SimpleObject::SimpleObject): Deleted.
        (WTF::SimpleObject::create): Deleted.
        (WTF::SimpleObject::visitChildren): Deleted.
        (WTF::SimpleObject::createStructure): Deleted.
        (WTF::SimpleObject::hiddenValue): Deleted.
        (WTF::SimpleObject::setHiddenValue): Deleted.
        (WTF::DOMJITNode::DOMJITNode): Deleted.
        (WTF::DOMJITNode::createStructure): Deleted.
        (WTF::DOMJITNode::checkSubClassSnippet): Deleted.
        (WTF::DOMJITNode::create): Deleted.
        (WTF::DOMJITNode::value const): Deleted.
        (WTF::DOMJITNode::offsetOfValue): Deleted.
        (WTF::DOMJITGetter::DOMJITGetter): Deleted.
        (WTF::DOMJITGetter::createStructure): Deleted.
        (WTF::DOMJITGetter::create): Deleted.
        (WTF::DOMJITGetter::DOMJITAttribute::DOMJITAttribute): Deleted.
        (WTF::DOMJITGetter::DOMJITAttribute::slowCall): Deleted.
        (WTF::DOMJITGetter::DOMJITAttribute::callDOMGetter): Deleted.
        (WTF::DOMJITGetter::customGetter): Deleted.
        (WTF::DOMJITGetter::finishCreation): Deleted.
        (WTF::DOMJITGetterComplex::DOMJITGetterComplex): Deleted.
        (WTF::DOMJITGetterComplex::createStructure): Deleted.
        (WTF::DOMJITGetterComplex::create): Deleted.
        (WTF::DOMJITGetterComplex::DOMJITAttribute::DOMJITAttribute): Deleted.
        (WTF::DOMJITGetterComplex::DOMJITAttribute::slowCall): Deleted.
        (WTF::DOMJITGetterComplex::DOMJITAttribute::callDOMGetter): Deleted.
        (WTF::DOMJITGetterComplex::functionEnableException): Deleted.
        (WTF::DOMJITGetterComplex::customGetter): Deleted.
        (WTF::DOMJITGetterComplex::finishCreation): Deleted.
        (WTF::DOMJITFunctionObject::DOMJITFunctionObject): Deleted.
        (WTF::DOMJITFunctionObject::createStructure): Deleted.
        (WTF::DOMJITFunctionObject::create): Deleted.
        (WTF::DOMJITFunctionObject::safeFunction): Deleted.
        (WTF::DOMJITFunctionObject::unsafeFunction): Deleted.
        (WTF::DOMJITFunctionObject::checkSubClassSnippet): Deleted.
        (WTF::DOMJITFunctionObject::finishCreation): Deleted.
        (WTF::DOMJITCheckSubClassObject::DOMJITCheckSubClassObject): Deleted.
        (WTF::DOMJITCheckSubClassObject::createStructure): Deleted.
        (WTF::DOMJITCheckSubClassObject::create): Deleted.
        (WTF::DOMJITCheckSubClassObject::safeFunction): Deleted.
        (WTF::DOMJITCheckSubClassObject::unsafeFunction): Deleted.
        (WTF::DOMJITCheckSubClassObject::finishCreation): Deleted.
        (WTF::DOMJITGetterBaseJSObject::DOMJITGetterBaseJSObject): Deleted.
        (WTF::DOMJITGetterBaseJSObject::createStructure): Deleted.
        (WTF::DOMJITGetterBaseJSObject::create): Deleted.
        (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::DOMJITAttribute): Deleted.
        (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::slowCall): Deleted.
        (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::callDOMGetter): Deleted.
        (WTF::DOMJITGetterBaseJSObject::customGetter): Deleted.
        (WTF::DOMJITGetterBaseJSObject::finishCreation): Deleted.
        (WTF::Element::handleOwner): Deleted.
        (WTF::Element::finishCreation): Deleted.
        (JSTestCustomGetterSetter::JSTestCustomGetterSetter): Deleted.
        (JSTestCustomGetterSetter::create): Deleted.
        (JSTestCustomGetterSetter::createStructure): Deleted.
        (customGetAccessor): Deleted.
        (customGetValue): Deleted.
        (customSetAccessor): Deleted.
        (customSetValue): Deleted.
        (JSTestCustomGetterSetter::finishCreation): Deleted.
        (GlobalObject::addConstructableFunction): Deleted.
        (functionCreateRoot): Deleted.
        (functionCreateElement): Deleted.
        (functionGetElement): Deleted.
        (functionSetElementRoot): Deleted.
        (functionCreateSimpleObject): Deleted.
        (functionGetHiddenValue): Deleted.
        (functionSetHiddenValue): Deleted.
        (functionCreateProxy): Deleted.
        (functionCreateRuntimeArray): Deleted.
        (functionCreateImpureGetter): Deleted.
        (functionCreateCustomGetterObject): Deleted.
        (functionCreateDOMJITNodeObject): Deleted.
        (functionCreateDOMJITGetterObject): Deleted.
        (functionCreateDOMJITGetterComplexObject): Deleted.
        (functionCreateDOMJITFunctionObject): Deleted.
        (functionCreateDOMJITCheckSubClassObject): Deleted.
        (functionCreateDOMJITGetterBaseJSObject): Deleted.
        (functionSetImpureGetterDelegate): Deleted.
        (functionGetGetterSetter): Deleted.
        (functionShadowChickenFunctionsOnStack): Deleted.
        (functionSetGlobalConstRedeclarationShouldNotThrow): Deleted.
        (functionGlobalObjectForObject): Deleted.
        (functionLoadGetterFromGetterSetter): Deleted.
        (functionCreateCustomTestGetterSetter): Deleted.
        (functionAbort): Deleted.
        (functionFindTypeForExpression): Deleted.
        (functionReturnTypeFor): Deleted.
        (functionDumpBasicBlockExecutionRanges): Deleted.
        (functionHasBasicBlockExecuted): Deleted.
        (functionBasicBlockExecutionCount): Deleted.
        (functionEnableExceptionFuzz): Deleted.
        (functionCreateBuiltin): Deleted.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * tools/JSDollarVM.cpp:
        (WTF::Element::Element):
        (WTF::Element::root const):
        (WTF::Element::setRoot):
        (WTF::Element::create):
        (WTF::Element::visitChildren):
        (WTF::Element::createStructure):
        (WTF::Root::Root):
        (WTF::Root::element):
        (WTF::Root::setElement):
        (WTF::Root::create):
        (WTF::Root::createStructure):
        (WTF::Root::visitChildren):
        (WTF::SimpleObject::SimpleObject):
        (WTF::SimpleObject::create):
        (WTF::SimpleObject::visitChildren):
        (WTF::SimpleObject::createStructure):
        (WTF::SimpleObject::hiddenValue):
        (WTF::SimpleObject::setHiddenValue):
        (WTF::ImpureGetter::ImpureGetter):
        (WTF::ImpureGetter::createStructure):
        (WTF::ImpureGetter::create):
        (WTF::ImpureGetter::finishCreation):
        (WTF::ImpureGetter::getOwnPropertySlot):
        (WTF::ImpureGetter::visitChildren):
        (WTF::ImpureGetter::setDelegate):
        (WTF::CustomGetter::CustomGetter):
        (WTF::CustomGetter::createStructure):
        (WTF::CustomGetter::create):
        (WTF::CustomGetter::getOwnPropertySlot):
        (WTF::CustomGetter::customGetter):
        (WTF::CustomGetter::customGetterAcessor):
        (WTF::RuntimeArray::create):
        (WTF::RuntimeArray::~RuntimeArray):
        (WTF::RuntimeArray::destroy):
        (WTF::RuntimeArray::getOwnPropertySlot):
        (WTF::RuntimeArray::getOwnPropertySlotByIndex):
        (WTF::RuntimeArray::put):
        (WTF::RuntimeArray::deleteProperty):
        (WTF::RuntimeArray::getLength const):
        (WTF::RuntimeArray::createPrototype):
        (WTF::RuntimeArray::createStructure):
        (WTF::RuntimeArray::finishCreation):
        (WTF::RuntimeArray::RuntimeArray):
        (WTF::RuntimeArray::lengthGetter):
        (WTF::DOMJITNode::DOMJITNode):
        (WTF::DOMJITNode::createStructure):
        (WTF::DOMJITNode::checkSubClassSnippet):
        (WTF::DOMJITNode::create):
        (WTF::DOMJITNode::value const):
        (WTF::DOMJITNode::offsetOfValue):
        (WTF::DOMJITGetter::DOMJITGetter):
        (WTF::DOMJITGetter::createStructure):
        (WTF::DOMJITGetter::create):
        (WTF::DOMJITGetter::DOMJITAttribute::DOMJITAttribute):
        (WTF::DOMJITGetter::DOMJITAttribute::slowCall):
        (WTF::DOMJITGetter::DOMJITAttribute::callDOMGetter):
        (WTF::DOMJITGetter::customGetter):
        (WTF::DOMJITGetter::finishCreation):
        (WTF::DOMJITGetterComplex::DOMJITGetterComplex):
        (WTF::DOMJITGetterComplex::createStructure):
        (WTF::DOMJITGetterComplex::create):
        (WTF::DOMJITGetterComplex::DOMJITAttribute::DOMJITAttribute):
        (WTF::DOMJITGetterComplex::DOMJITAttribute::slowCall):
        (WTF::DOMJITGetterComplex::DOMJITAttribute::callDOMGetter):
        (WTF::DOMJITGetterComplex::functionEnableException):
        (WTF::DOMJITGetterComplex::customGetter):
        (WTF::DOMJITGetterComplex::finishCreation):
        (WTF::DOMJITFunctionObject::DOMJITFunctionObject):
        (WTF::DOMJITFunctionObject::createStructure):
        (WTF::DOMJITFunctionObject::create):
        (WTF::DOMJITFunctionObject::safeFunction):
        (WTF::DOMJITFunctionObject::unsafeFunction):
        (WTF::DOMJITFunctionObject::checkSubClassSnippet):
        (WTF::DOMJITFunctionObject::finishCreation):
        (WTF::DOMJITCheckSubClassObject::DOMJITCheckSubClassObject):
        (WTF::DOMJITCheckSubClassObject::createStructure):
        (WTF::DOMJITCheckSubClassObject::create):
        (WTF::DOMJITCheckSubClassObject::safeFunction):
        (WTF::DOMJITCheckSubClassObject::unsafeFunction):
        (WTF::DOMJITCheckSubClassObject::finishCreation):
        (WTF::DOMJITGetterBaseJSObject::DOMJITGetterBaseJSObject):
        (WTF::DOMJITGetterBaseJSObject::createStructure):
        (WTF::DOMJITGetterBaseJSObject::create):
        (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::DOMJITAttribute):
        (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::slowCall):
        (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::callDOMGetter):
        (WTF::DOMJITGetterBaseJSObject::customGetter):
        (WTF::DOMJITGetterBaseJSObject::finishCreation):
        (WTF::Message::releaseContents):
        (WTF::Message::index const):
        (WTF::JSTestCustomGetterSetter::JSTestCustomGetterSetter):
        (WTF::JSTestCustomGetterSetter::create):
        (WTF::JSTestCustomGetterSetter::createStructure):
        (WTF::customGetAccessor):
        (WTF::customGetValue):
        (WTF::customSetAccessor):
        (WTF::customSetValue):
        (WTF::JSTestCustomGetterSetter::finishCreation):
        (WTF::Element::handleOwner):
        (WTF::Element::finishCreation):
        (JSC::functionCrash):
        (JSC::functionCreateProxy):
        (JSC::functionCreateRuntimeArray):
        (JSC::functionCreateImpureGetter):
        (JSC::functionCreateCustomGetterObject):
        (JSC::functionCreateDOMJITNodeObject):
        (JSC::functionCreateDOMJITGetterObject):
        (JSC::functionCreateDOMJITGetterComplexObject):
        (JSC::functionCreateDOMJITFunctionObject):
        (JSC::functionCreateDOMJITCheckSubClassObject):
        (JSC::functionCreateDOMJITGetterBaseJSObject):
        (JSC::functionSetImpureGetterDelegate):
        (JSC::functionCreateBuiltin):
        (JSC::functionCreateRoot):
        (JSC::functionCreateElement):
        (JSC::functionGetElement):
        (JSC::functionCreateSimpleObject):
        (JSC::functionGetHiddenValue):
        (JSC::functionSetHiddenValue):
        (JSC::functionShadowChickenFunctionsOnStack):
        (JSC::functionSetGlobalConstRedeclarationShouldNotThrow):
        (JSC::functionFindTypeForExpression):
        (JSC::functionReturnTypeFor):
        (JSC::functionDumpBasicBlockExecutionRanges):
        (JSC::functionHasBasicBlockExecuted):
        (JSC::functionBasicBlockExecutionCount):
        (JSC::functionEnableExceptionFuzz):
        (JSC::functionGlobalObjectForObject):
        (JSC::functionGetGetterSetter):
        (JSC::functionLoadGetterFromGetterSetter):
        (JSC::functionCreateCustomTestGetterSetter):
        (JSC::JSDollarVM::finishCreation):
        (JSC::JSDollarVM::addFunction):
        (JSC::JSDollarVM::addConstructibleFunction):
        * tools/JSDollarVM.h:
        (JSC::JSDollarVM::create):

2017-11-23  Simon Fraser  <simon.fraser@apple.com>

        Minor ArrayBufferView cleanup
        https://bugs.webkit.org/show_bug.cgi?id=179966

        Reviewed by Darin Adler.
        
        Use void* for data pointers when we don't need to do offset math. Use const for
        source pointers.
        
        Prefer uint8_t* to char*.
        
        Add comments noting that the assertions should not be made release assertions
        as recommended by the style checker, since the point is to avoid the virtual byteLength()
        call in release.

        * runtime/ArrayBufferView.h:
        (JSC::ArrayBufferView::setImpl):
        (JSC::ArrayBufferView::setRangeImpl):
        (JSC::ArrayBufferView::getRangeImpl):
        (JSC::ArrayBufferView::zeroRangeImpl):

2017-11-23  Darin Adler  <darin@apple.com>

        Reduce WTF::String operations that do unnecessary Unicode operations instead of ASCII
        https://bugs.webkit.org/show_bug.cgi?id=179907

        Reviewed by Sam Weinig.

        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::matches): Removed explicit TextCaseSensitive because RegularExpression now
        defaults to that.

        * runtime/StringPrototype.cpp:
        (JSC::stringIncludesImpl): Use String::find since there is no overload of
        String::contains that takes a start offset now that we removed the one that took a
        caseSensitive boolean. We can add one later if we like, but this should do for now.

        * yarr/RegularExpression.h: Moved the TextCaseSensitivity enumeration here from
        the StringImpl.h header because it is only used here.

2017-11-22  Simon Fraser  <simon.fraser@apple.com>

        Followup after r225084: if anyone called GenericTypedArrayView() it didn't compile,
        because of a getRangeUnchecked/getRangeImpl name mismatch; fixed to use getRangeImpl().
        
        Also name the argument to zeroRange() to 'count' since it's an item count.

        * runtime/GenericTypedArrayView.h:
        (JSC::GenericTypedArrayView::zeroRange):
        (JSC::GenericTypedArrayView::getRange):

2017-11-21  Simon Fraser  <simon.fraser@apple.com>

        Allow for more efficient use of GenericTypedArrayView
        https://bugs.webkit.org/show_bug.cgi?id=179899

        Reviewed by Sam Weinig.
        
        Fix ArrayBufferView::setRange() to not make two virtual function calls to byteLength()
        under setRangeImpl(). There is only one caller in GenericTypedArrayView, and it can pass
        in a length.

        Add GenericTypedArrayView::getRange() to fetch a range of elements, also without virtual
        byteLength() calls.
        
        Renamed 'dataLength' to 'count' in setRange() to be clearer.
        
        Added setNative() for callers who don't need clamping of doubles.

        * runtime/ArrayBufferView.h:
        (JSC::ArrayBufferView::setRangeImpl):
        (JSC::ArrayBufferView::getRangeImpl):
        * runtime/GenericTypedArrayView.h:
        (JSC::GenericTypedArrayView::setRange):
        (JSC::GenericTypedArrayView::setNative const):
        (JSC::GenericTypedArrayView::getRange):
        (JSC::GenericTypedArrayView::checkInboundData const):
        (JSC::GenericTypedArrayView::internalByteLength const):

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

        [DFG][FTL] Support MapSet / SetAdd intrinsics
        https://bugs.webkit.org/show_bug.cgi?id=179858

        Reviewed by Saam Barati.

        Map.prototype.set and Set.prototype.add uses MapHash value anyway.
        By handling them as MapSet and SetAdd DFG nodes and decoupling
        MapSet and SetAdd nodes from MapHash DFG node, we have a chance to
        remove duplicate MapHash calculation for the same key.

        One story is *set-if-not-exists*.

            if (!map.has(key))
                map.set(key, value);

        In the above code, both `has` and `set` require hash value for `key`.
        If we can change `set` to the series of DFG nodes:

            1: MapHash(key)
            2: MapSet(MapObjectUse:map, Untyped:key, Untyped:value, Int32Use:@1)

        we can remove duplicate @1 produced by `has` operation.

        This patch improves SixSpeed map-set.es6 and map-set-object.es6 by 20.5% and 20.4% respectively,

                                         baseline                  patched

            map-set.es6             246.2413+-15.2084    ^    204.3679+-11.2408       ^ definitely 1.2049x faster
            map-set-object.es6      266.5075+-17.2289    ^    221.2792+-12.2948       ^ definitely 1.2044x faster

        Microbenchmarks

            map-has-and-set         148.1522+-7.6665     ^    131.4552+-7.8846        ^ definitely 1.1270x 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/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileSetAdd):
        (JSC::DFG::SpeculativeJIT::compileMapSet):
        * 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::compileSetAdd):
        (JSC::FTL::DFG::LowerDFGToB3::compileMapSet):
        * jit/JITOperations.h:
        * runtime/HashMapImpl.h:
        (JSC::HashMapImpl::addNormalized):
        (JSC::HashMapImpl::addNormalizedInternal):
        * runtime/Intrinsic.cpp:
        (JSC::intrinsicName):
        * runtime/Intrinsic.h:
        * runtime/MapPrototype.cpp:
        (JSC::MapPrototype::finishCreation):
        * runtime/SetPrototype.cpp:
        (JSC::SetPrototype::finishCreation):

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

        [JSC] Allow poly proto for intrinsic getters
        https://bugs.webkit.org/show_bug.cgi?id=179550

        Reviewed by Saam Barati.

        This patch allows intrinsic getters to accept poly proto.
        We propagate PolyProtoAccessChain in IntrinsicGetterAccessCase to perform
        poly proto checks. And we extend UnderscoreProtoIntrinsic to emit
        code for poly proto case.

        * bytecode/IntrinsicGetterAccessCase.cpp:
        (JSC::IntrinsicGetterAccessCase::IntrinsicGetterAccessCase):
        (JSC::IntrinsicGetterAccessCase::create):
        * bytecode/IntrinsicGetterAccessCase.h:
        * jit/IntrinsicEmitter.cpp:
        (JSC::IntrinsicGetterAccessCase::canEmitIntrinsicGetter):
        (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
        * jit/Repatch.cpp:
        (JSC::tryCacheGetByID):

2017-11-20  Don Olmstead  <don.olmstead@sony.com>

        Detect __declspec within JSBase.h
        https://bugs.webkit.org/show_bug.cgi?id=179892

        Reviewed by Darin Adler.

        * API/JSBase.h:

2017-11-19  Tim Horton  <timothy_horton@apple.com>

        Remove unused TOUCH_ICON_LOADING feature flag
        https://bugs.webkit.org/show_bug.cgi?id=179873

        Reviewed by Simon Fraser.

        * Configurations/FeatureDefines.xcconfig:

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

        Add CPU(UNKNOWN) to cover all the unknown CPU types
        https://bugs.webkit.org/show_bug.cgi?id=179243

        Reviewed by JF Bastien.

        * CMakeLists.txt:

2017-11-19  Tim Horton  <timothy_horton@apple.com>

        Remove unused LEGACY_VENDOR_PREFIXES feature flag
        https://bugs.webkit.org/show_bug.cgi?id=179872

        Reviewed by Darin Adler.

        * Configurations/FeatureDefines.xcconfig:

2017-11-18  Tim Horton  <timothy_horton@apple.com>

        Fix typos in closing ENABLE() comments
        https://bugs.webkit.org/show_bug.cgi?id=179869

        Unreviewed.

        * wasm/WasmMemory.h:
        * wasm/WasmMemoryMode.h:

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

        NFC update ClassInfo to C++14
        https://bugs.webkit.org/show_bug.cgi?id=179783

        Reviewed by Mark Lam.

        Forked from #179734, use `using` instead of `typedef`. It's easier
        to read.

        * runtime/ClassInfo.h:

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

        WebAssembly JS API: throw when a promise can't be created
        https://bugs.webkit.org/show_bug.cgi?id=179826
        <rdar://problem/35455813>

        Reviewed by Mark Lam.

        Failure *in* a promise causes rejection, but failure to create a
        promise (because of stack overflow) isn't really spec'd (as all
        stack things JS). This applies to WebAssembly.compile and
        WebAssembly.instantiate.

        Dan's current proposal says:

            https://littledan.github.io/spec/document/js-api/index.html#stack-overflow

            Whenever a stack overflow occurs in WebAssembly code, the same
            class of exception is thrown as for a stack overflow in
            JavaScript. The particular exception here is
            implementation-defined in both cases.

            Note: ECMAScript doesn’t specify any sort of behavior on stack
            overflow; implementations have been observed to throw RangeError,
            InternalError or Error. Any is valid here.

        This is for general stack overflow within WebAssembly, not
        specifically for promise creation within JavaScript, but it seems
        like a stack overflow in promise creation should follow the same
        rule instead of, say, swallowing the overflow and returning
        undefined.

        * wasm/js/WebAssemblyPrototype.cpp:
        (JSC::webAssemblyCompileFunc):
        (JSC::webAssemblyInstantiateFunc):

2017-11-16  Daniel Bates  <dabates@apple.com>

        Add feature define for alternative presentation button element
        https://bugs.webkit.org/show_bug.cgi?id=179692
        Part of <rdar://problem/34917108>

        Reviewed by Andy Estes.

        Only enabled on Cocoa platforms by default.

        * Configurations/FeatureDefines.xcconfig:

2017-11-16  Saam Barati  <sbarati@apple.com>

        Fix a bug with cpuid in the FTL.

        Rubber stamped by Mark Lam.

        Before uploading the previous patch, I tried to condense the code. I
        accidentally removed a crucial line saying that CPUID clobbers various
        registers.

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

2017-11-16  Saam Barati  <sbarati@apple.com>

        Add some X86 intrinsics to $vm to help with some perf testing
        https://bugs.webkit.org/show_bug.cgi?id=179693

        Reviewed by Mark Lam.

        I've been doing some local perf testing of various ideas and have
        had these come in handy. I'm going to land them to dollarVM to prevent
        having to add them to my local build every time I do perf testing.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::mfence):
        (JSC::MacroAssemblerX86Common::rdtsc):
        (JSC::MacroAssemblerX86Common::pause):
        (JSC::MacroAssemblerX86Common::cpuid):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::rdtsc):
        (JSC::X86Assembler::pause):
        (JSC::X86Assembler::cpuid):
        * 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/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::intrinsic):
        * 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:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileCPUIntrinsic):
        * runtime/Intrinsic.cpp:
        (JSC::intrinsicName):
        * runtime/Intrinsic.h:
        * tools/JSDollarVM.cpp:
        (JSC::functionCpuMfence):
        (JSC::functionCpuRdtsc):
        (JSC::functionCpuCpuid):
        (JSC::functionCpuPause):
        (JSC::functionCpuClflush):
        (JSC::JSDollarVM::finishCreation):

2017-11-16  JF Bastien  <jfbastien@apple.com>

        It should be easier to reify lazy property names
        https://bugs.webkit.org/show_bug.cgi?id=179734
        <rdar://problem/35492521>

        Reviewed by Keith Miller.

        We reify lazy property names in a few different ways, each
        specific to the JSCell implementation, in put() instead of having
        a special function to do reification. Let's make that simpler.

        This patch makes it easier to reify property names in a uniform
        manner, and does so in JSFunction. As a follow up I'll use the
        same mechanics for:

        ClonedArguments   callee, iteratorSymbol (Symbol.iterator)
        ErrorConstructor  stackTraceLimit
        ErrorInstance     line, column, sourceURL, stack
        GenericArguments  length, callee, iteratorSymbol (Symbol.iterator)
        GetterSetter      RELEASE_ASSERT_NOT_REACHED()
        JSArray           length
        RegExpObject      lastIndex
        StringObject      length

        * runtime/ClassInfo.h: Add reifyPropertyNameIfNeeded to method table.
        * runtime/JSCell.cpp:
        (JSC::JSCell::reifyPropertyNameIfNeeded): by default, don't reify.
        * runtime/JSCell.h:
        * runtime/JSFunction.cpp: `name` and `length` can be reified.
        (JSC::JSFunction::reifyPropertyNameIfNeeded):
        (JSC::JSFunction::put):
        (JSC::JSFunction::reifyLength):
        (JSC::JSFunction::reifyName):
        (JSC::JSFunction::reifyLazyPropertyIfNeeded):
        (JSC::JSFunction::reifyLazyPropertyForHostOrBuiltinIfNeeded):
        (JSC::JSFunction::reifyLazyLengthIfNeeded):
        (JSC::JSFunction::reifyLazyNameIfNeeded):
        (JSC::JSFunction::reifyLazyBoundNameIfNeeded):
        * runtime/JSFunction.h:
        (JSC::JSFunction::isLazy):
        (JSC::JSFunction::isReified):
        * runtime/JSObjectInlines.h:
        (JSC::JSObject::putDirectInternal): do the reification here.

2017-11-16  Robin Morisset  <rmorisset@apple.com>

        Provide a runtime option for disabling the optimization of recursive tail calls
        https://bugs.webkit.org/show_bug.cgi?id=179765

        Reviewed by Mark Lam.

        * bytecode/PreciseJumpTargets.cpp:
        (JSC::getJumpTargetsForBytecodeOffset):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitEnter):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
        * runtime/Options.h:

2017-11-16  Robin Morisset  <rmorisset@apple.com>

        Fix null pointer dereference in bytecodeDumper
        https://bugs.webkit.org/show_bug.cgi?id=179764

        Reviewed by Mark Lam.

        The problem was just a call to lastSeenCallee() that was unguarded by haveLastSeenCallee().

        * bytecode/BytecodeDumper.cpp:
        (JSC::BytecodeDumper<Block>::printCallOp):

2017-11-16  Robin Morisset  <rmorisset@apple.com>

        REGRESSION (r224592): oss-fuzz: jsc: Null-dereference READ in JSC::JSCell::isObject (4216)
        https://bugs.webkit.org/show_bug.cgi?id=179763
        <rdar://problem/35550513>

        Reviewed by Keith Miller.

        Fix null pointer dereference caused by an eliminated tdz_check

        The problem was when doing an OSR entry in DFG while |this| was null
        (because super() had not yet been called in the constructor of this
        subclass), it would be marked as non-null, and the tdz_check eliminated.

        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::InPlaceAbstractState::initialize):

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

        Unreviewed, rolling out r224863.

        Introduced LayoutTest crashes on iOS Simulator.

        Reverted changeset:

        "Move JSONValues to WTF and convert uses of InspectorValues.h
        to JSONValues.h"
        https://bugs.webkit.org/show_bug.cgi?id=173793
        https://trac.webkit.org/changeset/224863

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

        Gardening: CLoop build fix after r224862.
        https://bugs.webkit.org/show_bug.cgi?id=179699

        Not reviewed..

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::calleeSaveSpaceAsVirtualRegisters):

2017-11-14  Carlos Garcia Campos  <cgarcia@igalia.com>

        Move JSONValues to WTF and convert uses of InspectorValues.h to JSONValues.h
        https://bugs.webkit.org/show_bug.cgi?id=173793

        Reviewed by Brian Burg.

        Based on patch by Brian Burg.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * bindings/ScriptValue.cpp:
        (Inspector::jsToInspectorValue):
        (Inspector::toInspectorValue):
        (Deprecated::ScriptValue::toInspectorValue const):
        * bindings/ScriptValue.h:
        * inspector/AsyncStackTrace.cpp:
        * inspector/ConsoleMessage.cpp:
        * inspector/ContentSearchUtilities.cpp:
        * inspector/InjectedScript.cpp:
        (Inspector::InjectedScript::getFunctionDetails):
        (Inspector::InjectedScript::functionDetails):
        (Inspector::InjectedScript::getPreview):
        (Inspector::InjectedScript::getProperties):
        (Inspector::InjectedScript::getDisplayableProperties):
        (Inspector::InjectedScript::getInternalProperties):
        (Inspector::InjectedScript::getCollectionEntries):
        (Inspector::InjectedScript::saveResult):
        (Inspector::InjectedScript::wrapCallFrames const):
        (Inspector::InjectedScript::wrapObject const):
        (Inspector::InjectedScript::wrapTable const):
        (Inspector::InjectedScript::previewValue const):
        (Inspector::InjectedScript::setExceptionValue):
        (Inspector::InjectedScript::clearExceptionValue):
        (Inspector::InjectedScript::inspectObject):
        (Inspector::InjectedScript::releaseObject):
        * inspector/InjectedScriptBase.cpp:
        (Inspector::InjectedScriptBase::makeCall):
        (Inspector::InjectedScriptBase::makeEvalCall):
        * inspector/InjectedScriptBase.h:
        * inspector/InjectedScriptManager.cpp:
        (Inspector::InjectedScriptManager::injectedScriptForObjectId):
        * inspector/InspectorBackendDispatcher.cpp:
        (Inspector::BackendDispatcher::CallbackBase::sendSuccess):
        (Inspector::BackendDispatcher::dispatch):
        (Inspector::BackendDispatcher::sendResponse):
        (Inspector::BackendDispatcher::sendPendingErrors):
        (Inspector::BackendDispatcher::getPropertyValue):
        (Inspector::castToInteger):
        (Inspector::castToNumber):
        (Inspector::BackendDispatcher::getInteger):
        (Inspector::BackendDispatcher::getDouble):
        (Inspector::BackendDispatcher::getString):
        (Inspector::BackendDispatcher::getBoolean):
        (Inspector::BackendDispatcher::getObject):
        (Inspector::BackendDispatcher::getArray):
        (Inspector::BackendDispatcher::getValue):
        * inspector/InspectorBackendDispatcher.h:
        * inspector/InspectorProtocolTypes.h:
        (Inspector::Protocol::Array::openAccessors):
        (Inspector::Protocol::PrimitiveBindingTraits::assertValueHasExpectedType):
        (Inspector::Protocol::BindingTraits<Protocol::Array<T>>::runtimeCast):
        (Inspector::Protocol::BindingTraits<Protocol::Array<T>>::assertValueHasExpectedType):
        (Inspector::Protocol::BindingTraits<JSON::Value>::assertValueHasExpectedType):
        * inspector/ScriptCallFrame.cpp:
        * inspector/ScriptCallStack.cpp:
        * inspector/agents/InspectorAgent.cpp:
        (Inspector::InspectorAgent::inspect):
        * inspector/agents/InspectorAgent.h:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::buildAssertPauseReason):
        (Inspector::buildCSPViolationPauseReason):
        (Inspector::InspectorDebuggerAgent::buildBreakpointPauseReason):
        (Inspector::InspectorDebuggerAgent::buildExceptionPauseReason):
        (Inspector::buildObjectForBreakpointCookie):
        (Inspector::InspectorDebuggerAgent::breakpointActionsFromProtocol):
        (Inspector::parseLocation):
        (Inspector::InspectorDebuggerAgent::setBreakpointByUrl):
        (Inspector::InspectorDebuggerAgent::setBreakpoint):
        (Inspector::InspectorDebuggerAgent::continueToLocation):
        (Inspector::InspectorDebuggerAgent::schedulePauseOnNextStatement):
        (Inspector::InspectorDebuggerAgent::didParseSource):
        (Inspector::InspectorDebuggerAgent::breakProgram):
        * inspector/agents/InspectorDebuggerAgent.h:
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::callFunctionOn):
        (Inspector::InspectorRuntimeAgent::saveResult):
        (Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets):
        * inspector/agents/InspectorRuntimeAgent.h:
        * inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py:
        (CppBackendDispatcherHeaderGenerator._generate_dispatcher_declaration_for_command):
        * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
        (CppBackendDispatcherImplementationGenerator.generate_output):
        (CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command):
        * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_header.py:
        (CppFrontendDispatcherHeaderGenerator.generate_output):
        * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
        (CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_event):
        * inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
        (_generate_unchecked_setter_for_member):
        * inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py:
        (CppProtocolTypesImplementationGenerator):
        * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
        (ObjCBackendDispatcherImplementationGenerator.generate_output):
        (ObjCBackendDispatcherImplementationGenerator._generate_success_block_for_command):
        * inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
        (ObjCFrontendDispatcherImplementationGenerator.generate_output):
        (ObjCFrontendDispatcherImplementationGenerator._generate_event):
        (ObjCFrontendDispatcherImplementationGenerator._generate_event_out_parameters):
        * inspector/scripts/codegen/generate_objc_internal_header.py:
        (ObjCInternalHeaderGenerator.generate_output):
        * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
        (ObjCProtocolTypesImplementationGenerator.generate_output):
        * inspector/scripts/codegen/generator.py:
        * 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:

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

        Fix a bit-rotted Interpreter::dumpRegisters() and make it more robust.
        https://bugs.webkit.org/show_bug.cgi?id=179699
        <rdar://problem/35462346>

        Reviewed by Michael Saboff.

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::dumpRegisters):
        - Need to skip the callee saved registers

2017-11-14  Guillaume Emont  <guijemont@igalia.com>

        REGRESSION(r224623) [MIPS] branchTruncateDoubleToInt32() doesn't set return register when branching
        https://bugs.webkit.org/show_bug.cgi?id=179563

        Reviewed by Carlos Alberto Lopez Perez.

        When run with BranchIfTruncateSuccessful,
        branchTruncateDoubleToInt32() should set the destination register
        before branching.
        This change also removes branchTruncateDoubleToUInt32() as it is
        deprecated (see r160205), merges branchOnTruncateResult() into
        branchTruncateDoubleToInt32() and adds test cases in testmasm.

        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::branchOnTruncateResult): Deleted.
        (JSC::MacroAssemblerMIPS::branchTruncateDoubleToInt32):
        Properly set dest before branching.
        (JSC::MacroAssemblerMIPS::branchTruncateDoubleToUInt32): Deleted.
        * assembler/testmasm.cpp:
        (JSC::testBranchTruncateDoubleToInt32):
        (JSC::run):
        Add tests for branchTruncateDoubleToInt32().

2017-11-14  Daniel Bates  <dabates@apple.com>

        Update comment in FeatureDefines.xcconfig to reflect location of Visual Studio property files
        for feature defines

        Following r195498 and r201917 the Visual Studio property files for feature defines have
        moved from directory WebKitLibraries/win/tools/vsprops to directory Source/cmake/tools/vsprops.
        Update the comment in FeatureDefines.xcconfig to reflect the new location and names of these
        files.

        * Configurations/FeatureDefines.xcconfig:

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

        Remove JSDollarVMPrototype.
        https://bugs.webkit.org/show_bug.cgi?id=179685

        Reviewed by Saam Barati.

        1. Move the JSDollarVMPrototype C++ utility functions into VMInspector.cpp.

           This allows us to call these functions during lldb debugging sessions using
           VMInspector::foo() instead of JSDollarVMPrototype::foo().  It makes sense that
           VMInspector provides VM debugging utility methods.  It doesn't make sense to
           have a JSDollarVMPrototype object provide these methods.

           Plus, it's shorter to type VMInspector than JSDollarVMPrototype.

        2. Move the JSDollarVMPrototype JS functions into JSDollarVM.cpp.

           JSDollarVM is a special object used only for debugging purposes.  There's no
           gain in requiring its methods to be stored in a prototype object other than to
           conform to typical JS convention.  We can remove this complexity.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * tools/JSDollarVM.cpp:
        (JSC::JSDollarVM::addFunction):
        (JSC::functionCrash):
        (JSC::functionDFGTrue):
        (JSC::CallerFrameJITTypeFunctor::CallerFrameJITTypeFunctor):
        (JSC::CallerFrameJITTypeFunctor::operator() const):
        (JSC::CallerFrameJITTypeFunctor::jitType):
        (JSC::functionLLintTrue):
        (JSC::functionJITTrue):
        (JSC::functionGC):
        (JSC::functionEdenGC):
        (JSC::functionCodeBlockForFrame):
        (JSC::codeBlockFromArg):
        (JSC::functionCodeBlockFor):
        (JSC::functionPrintSourceFor):
        (JSC::functionPrintBytecodeFor):
        (JSC::functionPrint):
        (JSC::functionPrintCallFrame):
        (JSC::functionPrintStack):
        (JSC::functionValue):
        (JSC::functionGetPID):
        (JSC::JSDollarVM::finishCreation):
        * tools/JSDollarVM.h:
        (JSC::JSDollarVM::create):
        * tools/JSDollarVMPrototype.cpp: Removed.
        * tools/JSDollarVMPrototype.h: Removed.
        * tools/VMInspector.cpp:
        (JSC::VMInspector::currentThreadOwnsJSLock):
        (JSC::ensureCurrentThreadOwnsJSLock):
        (JSC::VMInspector::gc):
        (JSC::VMInspector::edenGC):
        (JSC::VMInspector::isInHeap):
        (JSC::CellAddressCheckFunctor::CellAddressCheckFunctor):
        (JSC::CellAddressCheckFunctor::operator() const):
        (JSC::VMInspector::isValidCell):
        (JSC::VMInspector::isValidCodeBlock):
        (JSC::VMInspector::codeBlockForFrame):
        (JSC::PrintFrameFunctor::PrintFrameFunctor):
        (JSC::PrintFrameFunctor::operator() const):
        (JSC::VMInspector::printCallFrame):
        (JSC::VMInspector::printStack):
        (JSC::VMInspector::printValue):
        * tools/VMInspector.h:

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

        Web Inspector: Add a ServiceWorker domain to get information about an inspected ServiceWorker
        https://bugs.webkit.org/show_bug.cgi?id=179640
        <rdar://problem/35517361>

        Reviewed by Devin Rousso.

        * CMakeLists.txt:
        * DerivedSources.make:
        Gate the ServiceWorker domain on the ENABLE feature flag.

        * inspector/protocol/ServiceWorker.json: Added.
        New domain to be made available inside of a ServiceWorker target.

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

        [DFG][FTL] Support Array::DirectArguments with OutOfBounds
        https://bugs.webkit.org/show_bug.cgi?id=179594

        Reviewed by Saam Barati.

        Currently we handle OOB access to DirectArguments as GetByVal(Array::Generic).
        If we can handle it as GetByVal(Array::DirectArguments+OutOfBounds), we can (1) optimize
        `arguments[i]` accesses if i is in bound, and (2) encourage arguments elimination phase
        to convert CreateDirectArguments and GetByVal(Array::DirectArguments+OutOfBounds) to
        PhantomDirectArguments and GetMyArgumentOutOfBounds respectively.

        This patch introduces Array::DirectArguments+OutOfBounds array mode. GetByVal can
        accept this type, and emit optimized code compared to Array::Generic case.

        We make OOB check failures in GetByVal(Array::DirectArguments+InBounds) as OutOfBounds
        exit instead of ExoticObjectMode.

        This change significantly improves SixSpeed rest.es5 since it uses OOB access.
        Our arguments elimination phase can change CreateDirectArguments to PhantomDirectArguments.

            rest.es5                       59.6719+-2.2440     ^      3.1634+-0.5507        ^ definitely 18.8635x faster

        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::refine const):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnDirectArguments):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetMyArgumentByVal):

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

        We need to set topCallFrame when calling Wasm::Memory::grow from the JIT
        https://bugs.webkit.org/show_bug.cgi?id=179639
        <rdar://problem/35513018>

        Reviewed by JF Bastien.

        Calling Wasm::Memory::grow from the JIT may cause us to GC. When we GC, we will
        walk the stack for ShadowChicken (and maybe other things). We weren't updating
        topCallFrame when calling grow from the Wasm JIT. This would cause the GC to
        use stale topCallFrame bits in VM, often leading to crashes. This patch fixes
        this bug by giving Wasm::Instance a lambda that is called when we need to store
        the topCallFrame. Users of Wasm::Instance can provide a function to do this action.
        Currently, JSWebAssemblyInstance passes in a lambda that stores to
        VM.topCallFrame.

        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::addGrowMemory):
        * wasm/WasmInstance.cpp:
        (JSC::Wasm::Instance::Instance):
        (JSC::Wasm::Instance::create):
        * wasm/WasmInstance.h:
        (JSC::Wasm::Instance::storeTopCallFrame):
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::create):
        * wasm/js/JSWebAssemblyInstance.h:
        * wasm/js/WasmToJS.cpp:
        (JSC::Wasm::wasmToJSException):
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::constructJSWebAssemblyInstance):
        * wasm/js/WebAssemblyPrototype.cpp:
        (JSC::instantiate):

2017-11-13  Saam Barati  <sbarati@apple.com>

        Remove pointer caging for HashMapImpl, JSLexicalEnvironment, DirectArguments, ScopedArguments, and ScopedArgumentsTable
        https://bugs.webkit.org/show_bug.cgi?id=179203

        Reviewed by Yusuke Suzuki.

        This patch only removes the pointer caging for the described types in the title.
        These types still allocate out of the gigacage. This is a just a cost vs benefit
        tradeoff of performance vs security.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnDirectArguments):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitDirectArgumentsGetByVal):
        (JSC::JIT::emitScopedArgumentsGetByVal):
        * runtime/DirectArguments.h:
        (JSC::DirectArguments::storage):
        * runtime/HashMapImpl.cpp:
        (JSC::HashMapImpl<HashMapBucket>::visitChildren):
        * runtime/HashMapImpl.h:
        * runtime/JSLexicalEnvironment.h:
        (JSC::JSLexicalEnvironment::variables):
        * runtime/ScopedArguments.h:
        (JSC::ScopedArguments::overflowStorage const):

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

        Async iteration should only fetch the next method once and add feature flag
        https://bugs.webkit.org/show_bug.cgi?id=179451

        Reviewed by Geoffrey Garen.

        Add feature flag for Async iteration. Also, change async iteration to match
        the expected behavior of the proposal.

        * Configurations/FeatureDefines.xcconfig:
        * builtins/AsyncFromSyncIteratorPrototype.js:
        (globalPrivate.createAsyncFromSyncIterator):
        (globalPrivate.AsyncFromSyncIteratorConstructor):
        * builtins/BuiltinNames.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitGetAsyncIterator):
        * runtime/Options.h:

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

        Add more overflow check book-keeping for MarkedArgumentBuffer.
        https://bugs.webkit.org/show_bug.cgi?id=179634
        <rdar://problem/35492517>

        Reviewed by Saam Barati.

        * runtime/ArgList.h:
        (JSC::MarkedArgumentBuffer::overflowCheckNotNeeded):
        * runtime/JSJob.cpp:
        (JSC::JSJobMicrotask::run):
        * runtime/ObjectConstructor.cpp:
        (JSC::defineProperties):
        * runtime/ReflectObject.cpp:
        (JSC::reflectObjectConstruct):

2017-11-13  Guillaume Emont  <guijemont@igalia.com>

        [JSC] Remove ARM implementation of branchTruncateDoubleToUInt32
        https://bugs.webkit.org/show_bug.cgi?id=179542

        Reviewed by Alex Christensen.

        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::branchTruncateDoubleToUint32): Removed.

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

        Make the jsc shell loadGetterFromGetterSetter() function more robust.
        https://bugs.webkit.org/show_bug.cgi?id=179619
        <rdar://problem/35492518>

        Reviewed by Saam Barati.

        * jsc.cpp:
        (functionLoadGetterFromGetterSetter):

2017-11-12  Darin Adler  <darin@apple.com>

        More is<> and downcast<>, less static_cast<>
        https://bugs.webkit.org/show_bug.cgi?id=179600

        Reviewed by Chris Dumez.

        * runtime/JSString.h:
        (JSC::jsSubstring): Removed unneeded static_cast; length already returns unsigned.
        (JSC::jsSubstringOfResolved): Ditto.

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

        We should ensure that operationStrCat2 and operationStrCat3 are never passed Symbols as arguments.
        https://bugs.webkit.org/show_bug.cgi?id=179562
        <rdar://problem/35467022>

        Reviewed by Saam Barati.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGOperations.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::SafeToExecuteEdge::operator()):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::speculateNotSymbol):
        (JSC::DFG::SpeculativeJIT::speculate):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGUseKind.cpp:
        (WTF::printInternal):
        * dfg/DFGUseKind.h:
        (JSC::DFG::typeFilterFor):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::speculate):
        (JSC::FTL::DFG::LowerDFGToB3::speculateNotSymbol):

2017-11-11  Devin Rousso  <webkit@devinrousso.com>

        Web Inspector: Canvas tab: show detailed status during canvas recording
        https://bugs.webkit.org/show_bug.cgi?id=178185
        <rdar://problem/34939862>

        Reviewed by Brian Burg.

        * inspector/protocol/Canvas.json:
        Add a `recordingProgress` event that is sent to the frontend that contains all the frame
        payloads since the last Canvas.recordingProgress event and the current buffer usage.

        * inspector/protocol/Recording.json:
        Remove the required `frames` parameter from the Recording protocol object, as they will be
        sent in batches via the Canvas.recordingProgress event.

2017-11-10  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Make http status codes be "integer" instead of "number" in protocol
        https://bugs.webkit.org/show_bug.cgi?id=179543

        Reviewed by Antoine Quint.

        * inspector/protocol/Network.json:
        Use a better type for the status code.

2017-11-10  Robin Morisset  <rmorisset@apple.com>

        The memory consumption of DFG::BasicBlock can be easily reduced a bit
        https://bugs.webkit.org/show_bug.cgi?id=179528

        Reviewed by Saam Barati.

        A few changes here:
        - Reordering some fields of DFG::BasicBlock to reduce padding
        - Making the enum fields that are glorified booleans fit into a u8
        - Make each Operands object have a single vector that holds all arguments followed by all locals, instead of two vectors.
          This change works because we never increase the number of arguments after allocating an Operands object.
          It lets us avoid one extra capacity field and one extra pointer field per Operands,
          and more importantly one allocation per Operands whenever both vectors would have overflowed their inlined buffer.
          Additionally, if a single vector would have overflowed its inline buffer, while the other would have had some free space,
          we have a chance to avoid an allocation.
        - Finally, the three methods argumentForIndex, variableForIndex and indexForOperand were deleted since they were dead code.

        * bytecode/Operands.h:
        (JSC::Operands::Operands):
        (JSC::Operands::numberOfArguments const):
        (JSC::Operands::numberOfLocals const):
        (JSC::Operands::argument):
        (JSC::Operands::argument const):
        (JSC::Operands::local):
        (JSC::Operands::local const):
        (JSC::Operands::ensureLocals):
        (JSC::Operands::setLocal):
        (JSC::Operands::getLocal):
        (JSC::Operands::setArgumentFirstTime):
        (JSC::Operands::setLocalFirstTime):
        (JSC::Operands::operand):
        (JSC::Operands::setOperand):
        (JSC::Operands::size const):
        (JSC::Operands::at const):
        (JSC::Operands::at):
        (JSC::Operands::isArgument const):
        (JSC::Operands::isVariable const):
        (JSC::Operands::virtualRegisterForIndex const):
        (JSC::Operands::fill):
        (JSC::Operands::operator== const):
        (JSC::Operands::argumentForIndex const): Deleted.
        (JSC::Operands::variableForIndex const): Deleted.
        (JSC::Operands::indexForOperand const): Deleted.
        * dfg/DFGBasicBlock.cpp:
        (JSC::DFG::BasicBlock::BasicBlock):
        * dfg/DFGBasicBlock.h:
        * dfg/DFGBranchDirection.h:
        * dfg/DFGStructureClobberState.h:

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

        [JSC] Retry module fetching if previous request fails
        https://bugs.webkit.org/show_bug.cgi?id=178168

        Reviewed by Saam Barati.

        According to the latest spec, the failed fetching operation can be retried if it is requested again.
        For example,

            <script type="module" integrity="shaXXX-bad" src="./A.js"></script>
            <script type="module" integrity="shaXXX-correct" src="./A.js"></script>

        When performing the first module fetching, integrity check fails, and the load of this module becomes failed.
        But when loading the second module, we do not use the cached failure result in the first module loading.
        We retry fetching for "./A.js". In this case, we have a correct integrity and module fetching succeeds.
        This is specified in whatwg/HTML[1]. If the fetching fails, we do not cache it.

        Interestingly, fetching result and instantiation result will be cached if they succeeds. This is because we would
        like to cache modules based on their URLs. As a result,

            <script type="module" integrity="shaXXX-correct" src="./A.js"></script>
            <script type="module" integrity="shaXXX-bad" src="./A.js"></script>

        In the above case, the first loading succeeds. And the second loading also succeeds since the succeeded fetching and
        instantiation are cached in the module pipeline.

        This patch implements the above semantics. Previously, our module pipeline always caches the result. If the fetching
        failed, all the subsequent fetching for the same URL fails even if we have different integrity values. We retry fetching
        if the previous one fails. As an overview of our change,

        1. Fetching result should be cached only if it succeeds. Two or more on-the-fly fetching requests to the same URLs should
           be unified. But if currently executing one fails, other attempts should retry fetching.

        2. Instantiation should be cached if fetching succeeds.

        3. Satisfying should be cached if it succeeds.

        [1]: https://html.spec.whatwg.org/#fetch-a-single-module-script

        * builtins/ModuleLoaderPrototype.js:
        (requestFetch):
        (requestInstantiate):
        (requestSatisfy):
        (link):
        (loadModule):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):

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

        Web Inspector: support undo/redo of insertAdjacentHTML
        https://bugs.webkit.org/show_bug.cgi?id=179283

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/DOM.json:
        Add `insertAdjacentHTML` command that executes an undoable version of `insertAdjacentHTML`
        on the given node.

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

        Web Inspector: Make domain availability a list of types instead of a single type
        https://bugs.webkit.org/show_bug.cgi?id=179457

        Reviewed by Brian Burg.

        * inspector/scripts/codegen/generate_js_backend_commands.py:
        (JSBackendCommandsGenerator.generate_domain):
        Update output of `InspectorBackend.activateDomain` to include the list.

        * inspector/scripts/codegen/models.py:
        (Protocol.parse_domain):
        Parse `availability` as a list and include a new supported value of "service-worker".

        * inspector/protocol/ApplicationCache.json:
        * inspector/protocol/CSS.json:
        * inspector/protocol/Canvas.json:
        * inspector/protocol/DOM.json:
        * inspector/protocol/DOMDebugger.json:
        * inspector/protocol/DOMStorage.json:
        * inspector/protocol/Database.json:
        * inspector/protocol/IndexedDB.json:
        * inspector/protocol/LayerTree.json:
        * inspector/protocol/Memory.json:
        * inspector/protocol/Network.json:
        * inspector/protocol/Page.json:
        * inspector/protocol/Timeline.json:
        * inspector/protocol/Worker.json:
        Update `availability` to be a list.

        * inspector/scripts/tests/generic/domain-availability.json:
        * inspector/scripts/tests/generic/expected/domain-availability.json-result:
        * inspector/scripts/tests/generic/expected/fail-on-domain-availability-type.json-error: Added.
        * inspector/scripts/tests/generic/expected/fail-on-domain-availability-value.json-error: Added.
        * inspector/scripts/tests/generic/expected/fail-on-domain-availability.json-error:
        * inspector/scripts/tests/generic/fail-on-domain-availability-type.json: Copied from Source/JavaScriptCore/inspector/scripts/tests/generic/fail-on-domain-availability.json.
        * inspector/scripts/tests/generic/fail-on-domain-availability-value.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/fail-on-domain-availability.json.
        Update tests to include a test for the type and an invalid value.

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

        [JSC][JIT] Clean up SlowPathCall stubs
        https://bugs.webkit.org/show_bug.cgi?id=179247

        Reviewed by Saam Barati.

        We have bunch of duplicate functions that just call a slow path function.
        This patch cleans up the above duplication.

        * jit/JIT.cpp:
        (JSC::JIT::emitSlowCaseCall):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emitSlow_op_unsigned): Deleted.
        (JSC::JIT::emitSlow_op_inc): Deleted.
        (JSC::JIT::emitSlow_op_dec): Deleted.
        (JSC::JIT::emitSlow_op_bitand): Deleted.
        (JSC::JIT::emitSlow_op_bitor): Deleted.
        (JSC::JIT::emitSlow_op_bitxor): Deleted.
        (JSC::JIT::emitSlow_op_lshift): Deleted.
        (JSC::JIT::emitSlow_op_rshift): Deleted.
        (JSC::JIT::emitSlow_op_urshift): Deleted.
        (JSC::JIT::emitSlow_op_div): Deleted.
        * jit/JITArithmetic32_64.cpp:
        (JSC::JIT::emitSlow_op_unsigned): Deleted.
        (JSC::JIT::emitSlow_op_inc): Deleted.
        (JSC::JIT::emitSlow_op_dec): Deleted.
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emitSlow_op_create_this): Deleted.
        (JSC::JIT::emitSlow_op_check_tdz): Deleted.
        (JSC::JIT::emitSlow_op_to_this): Deleted.
        (JSC::JIT::emitSlow_op_to_primitive): Deleted.
        (JSC::JIT::emitSlow_op_not): Deleted.
        (JSC::JIT::emitSlow_op_stricteq): Deleted.
        (JSC::JIT::emitSlow_op_nstricteq): Deleted.
        (JSC::JIT::emitSlow_op_to_number): Deleted.
        (JSC::JIT::emitSlow_op_to_string): Deleted.
        (JSC::JIT::emitSlow_op_to_object): Deleted.
        (JSC::JIT::emitSlow_op_get_direct_pname): Deleted.
        (JSC::JIT::emitSlow_op_has_structure_property): Deleted.
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emitSlow_op_to_primitive): Deleted.
        (JSC::JIT::emitSlow_op_not): Deleted.
        (JSC::JIT::emitSlow_op_stricteq): Deleted.
        (JSC::JIT::emitSlow_op_nstricteq): Deleted.
        (JSC::JIT::emitSlow_op_to_number): Deleted.
        (JSC::JIT::emitSlow_op_to_string): Deleted.
        (JSC::JIT::emitSlow_op_to_object): Deleted.
        (JSC::JIT::emitSlow_op_create_this): Deleted.
        (JSC::JIT::emitSlow_op_to_this): Deleted.
        (JSC::JIT::emitSlow_op_check_tdz): Deleted.
        (JSC::JIT::emitSlow_op_get_direct_pname): Deleted.
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitSlow_op_resolve_scope): Deleted.
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_resolve_scope):
        (JSC::JIT::emitSlow_op_resolve_scope): Deleted.
        * jit/SlowPathCall.h:
        (JSC::JITSlowPathCall::JITSlowPathCall):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:

2017-11-09  Guillaume Emont  <guijemont@igalia.com>

        [JSC][MIPS] Use fcsr to check the validity of the result of trunc.w.d
        https://bugs.webkit.org/show_bug.cgi?id=179446

        Reviewed by Žan Doberšek.

        The trunc.w.d mips instruction should give a 0x7fffffff result when
        the source value is Infinity, NaN, or rounds to an integer outside the
        range -2^31 to 2^31 -1. This is what branchTruncateDoubleToInt32() and
        branchTruncateDoubleToUInt32() have been relying on. It turns out that
        this assumption is not true on some CPUs, including on the ci20 on
        which we run the testbot (we get 0x80000000 instead). We should the
        invalid operation cause bit instead to check whether the source value
        could be properly truncated. This requires the addition of the cfc1
        instruction, as well as the special registers that can be used with it
        (control registers of CP1).

        * assembler/MIPSAssembler.h:
        (JSC::MIPSAssembler::firstSPRegister):
        (JSC::MIPSAssembler::lastSPRegister):
        (JSC::MIPSAssembler::numberOfSPRegisters):
        (JSC::MIPSAssembler::sprName):
        Added control registers of CP1.
        (JSC::MIPSAssembler::cfc1):
        Added.
        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::branchOnTruncateResult):
        (JSC::MacroAssemblerMIPS::branchTruncateDoubleToInt32):
        (JSC::MacroAssemblerMIPS::branchTruncateDoubleToUint32):
        Use fcsr to check if the value could be properly truncated.

2017-11-08  Jeremy Jones  <jeremyj@apple.com>

        HTMLMediaElement should not use element fullscreen on iOS
        https://bugs.webkit.org/show_bug.cgi?id=179418
        rdar://problem/35409277

        Reviewed by Eric Carlson.

        Add ENABLE_VIDEO_USES_ELEMENT_FULLSCREEN to determine if HTMLMediaElement should use element full screen or not.

        * Configurations/FeatureDefines.xcconfig:

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

        Web Inspector: Show Internal properties of PaymentRequest in Web Inspector Console
        https://bugs.webkit.org/show_bug.cgi?id=179276

        Reviewed by Andy Estes.

        * inspector/InjectedScriptHost.h:
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::getInternalProperties):
        Call through to virtual implementation so that WebCore can provide custom
        internal properties for Web / DOM objects.

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

        A JSFunction's ObjectAllocationProfile should watch the poly prototype watchpoint so it can clear its object allocation profile
        https://bugs.webkit.org/show_bug.cgi?id=177792

        Reviewed by Yusuke Suzuki.

        Before this patch, if a JSFunction's rare data initialized its allocation profile
        before its backing Executable's poly proto watchpoint was invalidated, that
        JSFunction would continue to allocate non-poly proto objects until its allocation
        profile was cleared (which essentially never happens in practice). This patch
        improves on this pathology. A JSFunction's rare data will now watch the poly
        proto watchpoint if it's still valid and clear its allocation profile when we
        detect that we should go poly proto.

        * bytecode/ObjectAllocationProfile.h:
        * bytecode/ObjectAllocationProfileInlines.h:
        (JSC::ObjectAllocationProfile::initializeProfile):
        * runtime/FunctionRareData.cpp:
        (JSC::FunctionRareData::initializeObjectAllocationProfile):
        (JSC::FunctionRareData::AllocationProfileClearingWatchpoint::fireInternal):
        * runtime/FunctionRareData.h:
        (JSC::FunctionRareData::hasAllocationProfileClearingWatchpoint const):
        (JSC::FunctionRareData::createAllocationProfileClearingWatchpoint):
        (JSC::FunctionRareData::AllocationProfileClearingWatchpoint::AllocationProfileClearingWatchpoint):

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

        Add super sampler begin and end bytecodes.
        https://bugs.webkit.org/show_bug.cgi?id=179376

        Reviewed by Filip Pizlo.

        This patch adds a way to measure a narrow range of bytecodes for
        performance. This is done using the same infrastructure as the
        super sampler. I also added a class that helps do the bytecode
        checking with RAII. One problem with the current way this is done
        is that we don't handle decrementing early exits, either from
        branches or exceptions. So, when using this API users need to
        ensure that there are no early exits or that those exits don't
        occur on the measure code.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/BytecodeDumper.cpp:
        (JSC::BytecodeDumper<Block>::dumpBytecode):
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitSuperSamplerBegin):
        (JSC::BytecodeGenerator::emitSuperSamplerEnd):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/SuperSamplerBytecodeScope.h: Added.
        (JSC::SuperSamplerBytecodeScope::SuperSamplerBytecodeScope):
        (JSC::SuperSamplerBytecodeScope::~SuperSamplerBytecodeScope):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * 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/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        * 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::compileSuperSamplerBegin):
        (JSC::FTL::DFG::LowerDFGToB3::compileSuperSamplerEnd):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_super_sampler_begin):
        (JSC::JIT::emit_op_super_sampler_end):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:

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

        Turn recursive tail calls into loops
        https://bugs.webkit.org/show_bug.cgi?id=176601

        Reviewed by Saam Barati.

        Relanding after https://bugs.webkit.org/show_bug.cgi?id=178834.

        We want to turn recursive tail calls into loops early in the pipeline, so that the loops can then be optimized.
        One difficulty is that we need to split the entry block of the function we are jumping to in order to have somewhere to jump to.
        Worse: it is not necessarily the first block of the codeBlock, because of inlining! So we must do the splitting in the DFGByteCodeParser, at the same time as inlining.
        We do this part through modifying the computation of the jump targets.
        Importantly, we only do this splitting for functions that have tail calls.
        It is the only case where the optimisation is sound, and doing the splitting unconditionnaly destroys performance on Octane/raytrace.

        We must then do the actual transformation also in DFGByteCodeParser, to avoid code motion moving code out of the body of what will become a loop.
        The transformation is entirely contained in handleRecursiveTailCall, which is hooked to the inlining machinery.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::hasTailCalls const):
        * bytecode/PreciseJumpTargets.cpp:
        (JSC::getJumpTargetsForBytecodeOffset):
        (JSC::computePreciseJumpTargetsInternal):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::hasTailCalls const):
        (JSC::UnlinkedCodeBlock::setHasTailCalls):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitEnter):
        (JSC::BytecodeGenerator::emitCallInTailPosition):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::allocateTargetableBlock):
        (JSC::DFG::ByteCodeParser::makeBlockTargetable):
        (JSC::DFG::ByteCodeParser::handleCall):
        (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::parse):

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

        Web Inspector: Remove unused Page.ScriptIdentifier protocol type
        https://bugs.webkit.org/show_bug.cgi?id=179407

        Reviewed by Matt Baker.

        * inspector/protocol/Page.json:
        Remove unused protocol type.

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

        Web Inspector: use JSON::{Array,Object,Value} instead of Inspector{Array,Object,Value}
        https://bugs.webkit.org/show_bug.cgi?id=173619

        Reviewed by Alex Christensen and Brian Burg.

        Eventually all classes used for our JSON-RPC message passing should be outside
        of the Inspector namespace since the protocol is used outside of Inspector code.
        This will also allow us to unify the primitive JSON types with parameteric types
        like Inspector::Protocol::Array<T> and other protocol-related types which don't
        need to be in the Inspector namespace.

        Start this refactoring off by making JSON::Value a typedef for InspectorValue. In following
        patches, other clients will move to use JSON::Value and friends. When all uses are
        changed, the actual implementation will be renamed. This patch just focuses on the typedef
        and making changes in generated protocol code.

        Original patch by Brian Burg, rebased and updated by me.

        * inspector/InspectorValues.cpp:
        * inspector/InspectorValues.h:
        * inspector/scripts/codegen/cpp_generator.py:
        (CppGenerator.cpp_protocol_type_for_type):
        (CppGenerator.cpp_type_for_unchecked_formal_in_parameter):
        (CppGenerator.cpp_type_for_type_with_name):
        (CppGenerator.cpp_type_for_stack_in_parameter):
        * inspector/scripts/codegen/cpp_generator_templates.py:
        (void):
        * inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
        (_generate_class_for_object_declaration):
        (_generate_forward_declarations_for_binding_traits):
        * inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py:
        (CppProtocolTypesImplementationGenerator._generate_assertion_for_object_declaration):
        (CppProtocolTypesImplementationGenerator._generate_assertion_for_enum):
        * 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/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/shadowed-optional-type-setters.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/mac/expected/definitions-with-mac-platform.json-result:

2017-11-07  Maciej Stachowiak  <mjs@apple.com>

        Get rid of unsightly hex numbers from unified build object files
        https://bugs.webkit.org/show_bug.cgi?id=179410

        Reviewed by Saam Barati.

        * JavaScriptCore.xcodeproj/project.pbxproj: Rename UnifiedSource*.mm to UnifiedSource*-mm.mm for more readable build output.

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

        Only cage double butterfly accesses
        https://bugs.webkit.org/show_bug.cgi?id=179202

        Reviewed by Mark Lam.

        This patch removes caging from all butterfly accesses except double loads/stores.
        This is a performance vs security tradeoff. Double loads/stores are the only butterfly
        loads/stores that can write arbitrary bit patterns, so we choose to keep them safe
        by caging. The other load/stores we are no longer caging to get back performance on
        various benchmarks.

        * bytecode/AccessCase.cpp:
        (JSC::AccessCase::generateImpl):
        * bytecode/InlineAccess.cpp:
        (JSC::InlineAccess::dumpCacheSizesAndCrash):
        (JSC::InlineAccess::generateSelfPropertyAccess):
        (JSC::InlineAccess::generateSelfPropertyReplace):
        (JSC::InlineAccess::generateArrayLength):
        * dfg/DFGFixedButterflyAccessUncagingPhase.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCreateRest):
        (JSC::DFG::SpeculativeJIT::compileSpread):
        (JSC::DFG::SpeculativeJIT::compileNewArrayWithSpread):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileGetDirectPname):
        * jit/JITPropertyAccess.cpp:
        (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):
        * llint/LowLevelInterpreter64.asm:
        * runtime/AuxiliaryBarrier.h:
        (JSC::AuxiliaryBarrier::operator-> const):
        * runtime/Butterfly.h:
        (JSC::Butterfly::caged):
        (JSC::Butterfly::contiguousDouble):
        * runtime/JSArray.cpp:
        (JSC::JSArray::setLength):
        (JSC::JSArray::pop):
        (JSC::JSArray::shiftCountWithAnyIndexingType):
        (JSC::JSArray::unshiftCountWithAnyIndexingType):
        (JSC::JSArray::fillArgList):
        (JSC::JSArray::copyToArguments):
        * runtime/JSArrayInlines.h:
        (JSC::JSArray::pushInline):
        * runtime/JSObject.cpp:
        (JSC::JSObject::heapSnapshot):
        (JSC::JSObject::createInitialIndexedStorage):
        (JSC::JSObject::createArrayStorage):
        (JSC::JSObject::convertUndecidedToInt32):
        (JSC::JSObject::ensureLengthSlow):
        (JSC::JSObject::reallocateAndShrinkButterfly):
        (JSC::JSObject::allocateMoreOutOfLineStorage):
        * runtime/JSObject.h:
        (JSC::JSObject::canGetIndexQuickly):
        (JSC::JSObject::getIndexQuickly):
        (JSC::JSObject::tryGetIndexQuickly const):
        (JSC::JSObject::canSetIndexQuickly):
        (JSC::JSObject::butterfly const):
        (JSC::JSObject::butterfly):

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

        Introduce a default RegisterSet constructor so that we can use { } notation.
        https://bugs.webkit.org/show_bug.cgi?id=179389

        Reviewed by Saam Barati.

        I also replaced uses of "RegisterSet()" with "{ }" where the use of "RegisterSet()"
        does not add any code documentation value.

        * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp:
        * b3/air/AirCode.cpp:
        (JSC::B3::Air::Code::setRegsInPriorityOrder):
        * b3/air/AirPrintSpecial.cpp:
        (JSC::B3::Air::PrintSpecial::extraEarlyClobberedRegs):
        (JSC::B3::Air::PrintSpecial::extraClobberedRegs):
        * b3/air/testair.cpp:
        * bytecode/PolymorphicAccess.h:
        (JSC::AccessGenerationState::preserveLiveRegistersToStackForCall):
        (JSC::AccessGenerationState::restoreLiveRegistersFromStackForCall):
        * dfg/DFGJITCode.cpp:
        (JSC::DFG::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
        * ftl/FTLJITCode.cpp:
        (JSC::FTL::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
        * jit/JITCode.cpp:
        (JSC::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
        * jit/RegisterSet.cpp:
        (JSC::RegisterSet::reservedHardwareRegisters):
        (JSC::RegisterSet::runtimeRegisters):
        (JSC::RegisterSet::macroScratchRegisters):
        * jit/RegisterSet.h:
        (JSC::RegisterSet::RegisterSet):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::emitTierUpCheck):

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

        AccessCase::generateImpl() should exclude the result register when restoring registers after a call.
        https://bugs.webkit.org/show_bug.cgi?id=179355
        <rdar://problem/35263053>

        Reviewed by Saam Barati.

        In the Transition case in AccessCase::generateImpl(), we were restoring registers
        using restoreLiveRegistersFromStackForCall() without excluding the scratchGPR
        where we previously stashed the reallocated butterfly.  If the generated code is
        under heavy register pressure, scratchGPR could have been from the set of preserved
        registers, and hence, would be restored by restoreLiveRegistersFromStackForCall().
        As a result, the restoration would trash the butterfly result we stored there.
        This patch fixes the issue by excluding the scratchGPR in the restoration.

        * bytecode/AccessCase.cpp:
        (JSC::AccessCase::generateImpl):

2017-11-06  Robin Morisset  <rmorisset@apple.com>

        CodeBlock::usesOpcode() is dead code
        https://bugs.webkit.org/show_bug.cgi?id=179316

        Reviewed by Yusuke Suzuki.

        Remove CodeBlock::usesOpcode which is dead code

        * bytecode/CodeBlock.cpp:
        * bytecode/CodeBlock.h:

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

        JIT call inline caches should cache calls to objects with getCallData/getConstructData traps
        https://bugs.webkit.org/show_bug.cgi?id=144458

        Reviewed by Saam Barati.

        Previously only JSFunction is handled by CallLinkInfo's caching mechanism. This means that
        InternalFunction calls are not cached and they always go to the slow path. This is not good because

        1. We need to query getCallData/getConstructData every time in the slow path.
        2. CallLinkInfo tells nothing in the higher tier JITs.

        This patch starts handling InternalFunction in CallLinkInfo's caching mechanism. We change InternalFunction
        to hold pointers to the functions for call and construct. We have new stubs that can call/construct
        InternalFunction. And we return this code pointer as a result of setup call to use CallLinkInfo mechanism.

        This patch is critical to optimizing derived Array construction[1] since it starts using CallLinkInfo
        for InternalFunction. Previously we did not record any information to CallLinkInfo. Except for the
        case that DFGByteCodeParser figures out InternalFunction constant, we cannot attempt to emit DFG
        nodes for these InternalFunctions since CallLinkInfo tells us nothing.

        Attached microbenchmarks show performance improvement.

                                                           baseline                  patched

        dfg-internal-function-construct                 1.6439+-0.0826     ^      1.2829+-0.0727        ^ definitely 1.2813x faster
        dfg-internal-function-not-handled-construct     2.1862+-0.1361            2.0696+-0.1201          might be 1.0564x faster
        dfg-internal-function-not-handled-call         20.7592+-0.9085           19.7369+-0.7921          might be 1.0518x faster
        dfg-internal-function-call                      1.6856+-0.0967     ^      1.2771+-0.0744        ^ definitely 1.3198x faster

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

        * API/JSCallbackFunction.cpp:
        (JSC::JSCallbackFunction::JSCallbackFunction):
        (JSC::JSCallbackFunction::getCallData): Deleted.
        * API/JSCallbackFunction.h:
        (JSC::JSCallbackFunction::createStructure):
        * API/ObjCCallbackFunction.h:
        (JSC::ObjCCallbackFunction::createStructure):
        * API/ObjCCallbackFunction.mm:
        (JSC::ObjCCallbackFunction::ObjCCallbackFunction):
        (JSC::ObjCCallbackFunction::getCallData): Deleted.
        (JSC::ObjCCallbackFunction::getConstructData): Deleted.
        * bytecode/BytecodeDumper.cpp:
        (JSC::BytecodeDumper<Block>::printCallOp):
        * bytecode/BytecodeList.json:
        * bytecode/CallLinkInfo.cpp:
        (JSC::CallLinkInfo::setCallee):
        (JSC::CallLinkInfo::callee):
        (JSC::CallLinkInfo::setLastSeenCallee):
        (JSC::CallLinkInfo::lastSeenCallee):
        (JSC::CallLinkInfo::visitWeak):
        * bytecode/CallLinkInfo.h:
        * bytecode/CallLinkStatus.cpp:
        (JSC::CallLinkStatus::computeFromCallLinkInfo):
        * bytecode/LLIntCallLinkInfo.h:
        * jit/JITOperations.cpp:
        * jit/JITThunks.cpp:
        (JSC::JITThunks::ctiInternalFunctionCall):
        (JSC::JITThunks::ctiInternalFunctionConstruct):
        * jit/JITThunks.h:
        * jit/Repatch.cpp:
        (JSC::linkFor):
        (JSC::linkPolymorphicCall):
        * jit/Repatch.h:
        * jit/ThunkGenerators.cpp:
        (JSC::virtualThunkFor):
        (JSC::nativeForGenerator):
        (JSC::nativeCallGenerator):
        (JSC::nativeTailCallGenerator):
        (JSC::nativeTailCallWithoutSavedTagsGenerator):
        (JSC::nativeConstructGenerator):
        (JSC::internalFunctionCallGenerator):
        (JSC::internalFunctionConstructGenerator):
        * jit/ThunkGenerators.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::setUpCall):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/ArrayConstructor.cpp:
        (JSC::ArrayConstructor::ArrayConstructor):
        (JSC::ArrayConstructor::getConstructData): Deleted.
        (JSC::ArrayConstructor::getCallData): Deleted.
        * runtime/ArrayConstructor.h:
        (JSC::ArrayConstructor::createStructure):
        * runtime/AsyncFunctionConstructor.cpp:
        (JSC::AsyncFunctionConstructor::AsyncFunctionConstructor):
        (JSC::AsyncFunctionConstructor::finishCreation):
        (JSC::AsyncFunctionConstructor::getCallData): Deleted.
        (JSC::AsyncFunctionConstructor::getConstructData): Deleted.
        * runtime/AsyncFunctionConstructor.h:
        (JSC::AsyncFunctionConstructor::createStructure):
        * runtime/AsyncGeneratorFunctionConstructor.cpp:
        (JSC::AsyncGeneratorFunctionConstructor::AsyncGeneratorFunctionConstructor):
        (JSC::AsyncGeneratorFunctionConstructor::finishCreation):
        (JSC::AsyncGeneratorFunctionConstructor::getCallData): Deleted.
        (JSC::AsyncGeneratorFunctionConstructor::getConstructData): Deleted.
        * runtime/AsyncGeneratorFunctionConstructor.h:
        (JSC::AsyncGeneratorFunctionConstructor::createStructure):
        * runtime/BooleanConstructor.cpp:
        (JSC::callBooleanConstructor):
        (JSC::BooleanConstructor::BooleanConstructor):
        (JSC::BooleanConstructor::finishCreation):
        (JSC::BooleanConstructor::getConstructData): Deleted.
        (JSC::BooleanConstructor::getCallData): Deleted.
        * runtime/BooleanConstructor.h:
        (JSC::BooleanConstructor::createStructure):
        * runtime/DateConstructor.cpp:
        (JSC::DateConstructor::DateConstructor):
        (JSC::DateConstructor::getConstructData): Deleted.
        (JSC::DateConstructor::getCallData): Deleted.
        * runtime/DateConstructor.h:
        (JSC::DateConstructor::createStructure):
        * runtime/Error.h:
        (JSC::StrictModeTypeErrorFunction::StrictModeTypeErrorFunction):
        (JSC::StrictModeTypeErrorFunction::createStructure):
        (JSC::StrictModeTypeErrorFunction::getConstructData): Deleted.
        (JSC::StrictModeTypeErrorFunction::getCallData): Deleted.
        * runtime/ErrorConstructor.cpp:
        (JSC::ErrorConstructor::ErrorConstructor):
        (JSC::ErrorConstructor::getConstructData): Deleted.
        (JSC::ErrorConstructor::getCallData): Deleted.
        * runtime/ErrorConstructor.h:
        (JSC::ErrorConstructor::createStructure):
        * runtime/FunctionConstructor.cpp:
        (JSC::FunctionConstructor::FunctionConstructor):
        (JSC::FunctionConstructor::finishCreation):
        (JSC::FunctionConstructor::getConstructData): Deleted.
        (JSC::FunctionConstructor::getCallData): Deleted.
        * runtime/FunctionConstructor.h:
        (JSC::FunctionConstructor::createStructure):
        * runtime/FunctionPrototype.cpp:
        (JSC::callFunctionPrototype):
        (JSC::FunctionPrototype::FunctionPrototype):
        (JSC::FunctionPrototype::getCallData): Deleted.
        * runtime/FunctionPrototype.h:
        (JSC::FunctionPrototype::createStructure):
        * runtime/GeneratorFunctionConstructor.cpp:
        (JSC::GeneratorFunctionConstructor::GeneratorFunctionConstructor):
        (JSC::GeneratorFunctionConstructor::finishCreation):
        (JSC::GeneratorFunctionConstructor::getCallData): Deleted.
        (JSC::GeneratorFunctionConstructor::getConstructData): Deleted.
        * runtime/GeneratorFunctionConstructor.h:
        (JSC::GeneratorFunctionConstructor::createStructure):
        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::InternalFunction):
        (JSC::InternalFunction::finishCreation):
        (JSC::InternalFunction::getCallData):
        (JSC::InternalFunction::getConstructData):
        * runtime/InternalFunction.h:
        (JSC::InternalFunction::createStructure):
        (JSC::InternalFunction::nativeFunctionFor):
        (JSC::InternalFunction::offsetOfNativeFunctionFor):
        * runtime/IntlCollatorConstructor.cpp:
        (JSC::IntlCollatorConstructor::createStructure):
        (JSC::IntlCollatorConstructor::IntlCollatorConstructor):
        (JSC::IntlCollatorConstructor::getConstructData): Deleted.
        (JSC::IntlCollatorConstructor::getCallData): Deleted.
        * runtime/IntlCollatorConstructor.h:
        * runtime/IntlDateTimeFormatConstructor.cpp:
        (JSC::IntlDateTimeFormatConstructor::createStructure):
        (JSC::IntlDateTimeFormatConstructor::IntlDateTimeFormatConstructor):
        (JSC::IntlDateTimeFormatConstructor::getConstructData): Deleted.
        (JSC::IntlDateTimeFormatConstructor::getCallData): Deleted.
        * runtime/IntlDateTimeFormatConstructor.h:
        * runtime/IntlNumberFormatConstructor.cpp:
        (JSC::IntlNumberFormatConstructor::createStructure):
        (JSC::IntlNumberFormatConstructor::IntlNumberFormatConstructor):
        (JSC::IntlNumberFormatConstructor::getConstructData): Deleted.
        (JSC::IntlNumberFormatConstructor::getCallData): Deleted.
        * runtime/IntlNumberFormatConstructor.h:
        * runtime/JSArrayBufferConstructor.cpp:
        (JSC::JSArrayBufferConstructor::JSArrayBufferConstructor):
        (JSC::JSArrayBufferConstructor::createStructure):
        (JSC::JSArrayBufferConstructor::getConstructData): Deleted.
        (JSC::JSArrayBufferConstructor::getCallData): Deleted.
        * runtime/JSArrayBufferConstructor.h:
        * runtime/JSGenericTypedArrayViewConstructor.h:
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::JSGenericTypedArrayViewConstructor):
        (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::createStructure):
        (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::getConstructData): Deleted.
        (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::getCallData): Deleted.
        * runtime/JSInternalPromiseConstructor.cpp:
        (JSC::JSInternalPromiseConstructor::createStructure):
        (JSC::JSInternalPromiseConstructor::JSInternalPromiseConstructor):
        (JSC::JSInternalPromiseConstructor::getConstructData): Deleted.
        (JSC::JSInternalPromiseConstructor::getCallData): Deleted.
        * runtime/JSInternalPromiseConstructor.h:
        * runtime/JSPromiseConstructor.cpp:
        (JSC::JSPromiseConstructor::createStructure):
        (JSC::JSPromiseConstructor::JSPromiseConstructor):
        (JSC::JSPromiseConstructor::getConstructData): Deleted.
        (JSC::JSPromiseConstructor::getCallData): Deleted.
        * runtime/JSPromiseConstructor.h:
        * runtime/JSType.h:
        * runtime/JSTypedArrayViewConstructor.cpp:
        (JSC::JSTypedArrayViewConstructor::JSTypedArrayViewConstructor):
        (JSC::JSTypedArrayViewConstructor::createStructure):
        (JSC::JSTypedArrayViewConstructor::getConstructData): Deleted.
        (JSC::JSTypedArrayViewConstructor::getCallData): Deleted.
        * runtime/JSTypedArrayViewConstructor.h:
        * runtime/MapConstructor.cpp:
        (JSC::MapConstructor::MapConstructor):
        (JSC::MapConstructor::getConstructData): Deleted.
        (JSC::MapConstructor::getCallData): Deleted.
        * runtime/MapConstructor.h:
        (JSC::MapConstructor::createStructure):
        (JSC::MapConstructor::MapConstructor): Deleted.
        * runtime/NativeErrorConstructor.cpp:
        (JSC::NativeErrorConstructor::NativeErrorConstructor):
        (JSC::NativeErrorConstructor::getConstructData): Deleted.
        (JSC::NativeErrorConstructor::getCallData): Deleted.
        * runtime/NativeErrorConstructor.h:
        (JSC::NativeErrorConstructor::createStructure):
        * runtime/NullGetterFunction.cpp:
        (JSC::NullGetterFunction::NullGetterFunction):
        (JSC::NullGetterFunction::getCallData): Deleted.
        (JSC::NullGetterFunction::getConstructData): Deleted.
        * runtime/NullGetterFunction.h:
        (JSC::NullGetterFunction::createStructure):
        (JSC::NullGetterFunction::NullGetterFunction): Deleted.
        * runtime/NullSetterFunction.cpp:
        (JSC::NullSetterFunction::NullSetterFunction):
        (JSC::NullSetterFunction::getCallData): Deleted.
        (JSC::NullSetterFunction::getConstructData): Deleted.
        * runtime/NullSetterFunction.h:
        (JSC::NullSetterFunction::createStructure):
        (JSC::NullSetterFunction::NullSetterFunction): Deleted.
        * runtime/NumberConstructor.cpp:
        (JSC::NumberConstructor::NumberConstructor):
        (JSC::constructNumberConstructor):
        (JSC::constructWithNumberConstructor): Deleted.
        (JSC::NumberConstructor::getConstructData): Deleted.
        (JSC::NumberConstructor::getCallData): Deleted.
        * runtime/NumberConstructor.h:
        (JSC::NumberConstructor::createStructure):
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructor::ObjectConstructor):
        (JSC::ObjectConstructor::getConstructData): Deleted.
        (JSC::ObjectConstructor::getCallData): Deleted.
        * runtime/ObjectConstructor.h:
        (JSC::ObjectConstructor::createStructure):
        * runtime/ProxyConstructor.cpp:
        (JSC::ProxyConstructor::ProxyConstructor):
        (JSC::ProxyConstructor::getConstructData): Deleted.
        (JSC::ProxyConstructor::getCallData): Deleted.
        * runtime/ProxyConstructor.h:
        (JSC::ProxyConstructor::createStructure):
        * runtime/ProxyRevoke.cpp:
        (JSC::ProxyRevoke::ProxyRevoke):
        (JSC::ProxyRevoke::getCallData): Deleted.
        * runtime/ProxyRevoke.h:
        (JSC::ProxyRevoke::createStructure):
        * runtime/RegExpConstructor.cpp:
        (JSC::RegExpConstructor::RegExpConstructor):
        (JSC::RegExpConstructor::getConstructData): Deleted.
        (JSC::RegExpConstructor::getCallData): Deleted.
        * runtime/RegExpConstructor.h:
        (JSC::RegExpConstructor::createStructure):
        * runtime/SetConstructor.cpp:
        (JSC::SetConstructor::SetConstructor):
        (JSC::SetConstructor::getConstructData): Deleted.
        (JSC::SetConstructor::getCallData): Deleted.
        * runtime/SetConstructor.h:
        (JSC::SetConstructor::createStructure):
        (JSC::SetConstructor::SetConstructor): Deleted.
        * runtime/StringConstructor.cpp:
        (JSC::StringConstructor::StringConstructor):
        (JSC::StringConstructor::getConstructData): Deleted.
        (JSC::StringConstructor::getCallData): Deleted.
        * runtime/StringConstructor.h:
        (JSC::StringConstructor::createStructure):
        * runtime/SymbolConstructor.cpp:
        (JSC::SymbolConstructor::SymbolConstructor):
        (JSC::SymbolConstructor::getConstructData): Deleted.
        (JSC::SymbolConstructor::getCallData): Deleted.
        * runtime/SymbolConstructor.h:
        (JSC::SymbolConstructor::createStructure):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::getCTIInternalFunctionTrampolineFor):
        * runtime/VM.h:
        * runtime/WeakMapConstructor.cpp:
        (JSC::WeakMapConstructor::WeakMapConstructor):
        (JSC::WeakMapConstructor::getConstructData): Deleted.
        (JSC::WeakMapConstructor::getCallData): Deleted.
        * runtime/WeakMapConstructor.h:
        (JSC::WeakMapConstructor::createStructure):
        (JSC::WeakMapConstructor::WeakMapConstructor): Deleted.
        * runtime/WeakSetConstructor.cpp:
        (JSC::WeakSetConstructor::WeakSetConstructor):
        (JSC::WeakSetConstructor::getConstructData): Deleted.
        (JSC::WeakSetConstructor::getCallData): Deleted.
        * runtime/WeakSetConstructor.h:
        (JSC::WeakSetConstructor::createStructure):
        (JSC::WeakSetConstructor::WeakSetConstructor): Deleted.
        * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
        (JSC::WebAssemblyCompileErrorConstructor::createStructure):
        (JSC::WebAssemblyCompileErrorConstructor::WebAssemblyCompileErrorConstructor):
        (JSC::WebAssemblyCompileErrorConstructor::getConstructData): Deleted.
        (JSC::WebAssemblyCompileErrorConstructor::getCallData): Deleted.
        * wasm/js/WebAssemblyCompileErrorConstructor.h:
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::WebAssemblyInstanceConstructor::createStructure):
        (JSC::WebAssemblyInstanceConstructor::WebAssemblyInstanceConstructor):
        (JSC::WebAssemblyInstanceConstructor::getConstructData): Deleted.
        (JSC::WebAssemblyInstanceConstructor::getCallData): Deleted.
        * wasm/js/WebAssemblyInstanceConstructor.h:
        * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
        (JSC::WebAssemblyLinkErrorConstructor::createStructure):
        (JSC::WebAssemblyLinkErrorConstructor::WebAssemblyLinkErrorConstructor):
        (JSC::WebAssemblyLinkErrorConstructor::getConstructData): Deleted.
        (JSC::WebAssemblyLinkErrorConstructor::getCallData): Deleted.
        * wasm/js/WebAssemblyLinkErrorConstructor.h:
        * wasm/js/WebAssemblyMemoryConstructor.cpp:
        (JSC::WebAssemblyMemoryConstructor::createStructure):
        (JSC::WebAssemblyMemoryConstructor::WebAssemblyMemoryConstructor):
        (JSC::WebAssemblyMemoryConstructor::getConstructData): Deleted.
        (JSC::WebAssemblyMemoryConstructor::getCallData): Deleted.
        * wasm/js/WebAssemblyMemoryConstructor.h:
        * wasm/js/WebAssemblyModuleConstructor.cpp:
        (JSC::WebAssemblyModuleConstructor::createStructure):
        (JSC::WebAssemblyModuleConstructor::WebAssemblyModuleConstructor):
        (JSC::WebAssemblyModuleConstructor::getConstructData): Deleted.
        (JSC::WebAssemblyModuleConstructor::getCallData): Deleted.
        * wasm/js/WebAssemblyModuleConstructor.h:
        * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
        (JSC::WebAssemblyRuntimeErrorConstructor::createStructure):
        (JSC::WebAssemblyRuntimeErrorConstructor::WebAssemblyRuntimeErrorConstructor):
        (JSC::WebAssemblyRuntimeErrorConstructor::getConstructData): Deleted.
        (JSC::WebAssemblyRuntimeErrorConstructor::getCallData): Deleted.
        * wasm/js/WebAssemblyRuntimeErrorConstructor.h:
        * wasm/js/WebAssemblyTableConstructor.cpp:
        (JSC::WebAssemblyTableConstructor::createStructure):
        (JSC::WebAssemblyTableConstructor::WebAssemblyTableConstructor):
        (JSC::WebAssemblyTableConstructor::getConstructData): Deleted.
        (JSC::WebAssemblyTableConstructor::getCallData): Deleted.
        * wasm/js/WebAssemblyTableConstructor.h:

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

        The Abstract Interpreter needs to change similar to clobberize() in r224366
        https://bugs.webkit.org/show_bug.cgi?id=179267

        Reviewed by Saam Barati.

        Add clobberWorld() to HasGenericProperty, HasStructureProperty & GetPropertyEnumerator
        cases in the abstract interpreter to match what was done for r224366.

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

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

        PutProperytSlot should inform the IC about the property before effects.
        https://bugs.webkit.org/show_bug.cgi?id=179262

        Reviewed by Mark Lam.

        This patch fixes an issue where we choose to cache setters based on
        incorrect information. If we did so we might end up OSR exiting
        more than we would otherwise need to. The new model is that the
        PutPropertySlot should inform the IC of what the property looked
        like before any potential side effects might have occurred.

        * runtime/JSObject.cpp:
        (JSC::JSObject::putInlineSlow):
        * runtime/Lookup.h:
        (JSC::putEntry):

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

        CachedCall (and its clients) needs overflow checks.
        https://bugs.webkit.org/show_bug.cgi?id=179185

        Reviewed by JF Bastien.

        * interpreter/CachedCall.h:
        (JSC::CachedCall::CachedCall):
        (JSC::CachedCall::hasOverflowedArguments):
        * runtime/ArgList.h:
        (JSC::MarkedArgumentBuffer::clear):
        * runtime/StringPrototype.cpp:
        (JSC::replaceUsingRegExpSearch):

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

        Web Inspector: Canvas2D Profiling: highlight expensive context commands in the captured command log
        https://bugs.webkit.org/show_bug.cgi?id=178302
        <rdar://problem/33158849>

        Reviewed by Brian Burg.

        * inspector/protocol/Recording.json:
        Add `duration` to each Frame that represents the total time of all the recorded actions.

2017-11-02  Devin Rousso  <webkit@devinrousso.com>

        Web Inspector: Canvas Tab: show supported GL extensions for selected canvas
        https://bugs.webkit.org/show_bug.cgi?id=179070
        <rdar://problem/35278276>

        Reviewed by Brian Burg.

        * inspector/protocol/Canvas.json:
        Add `extensionEnabled` event that is fired each time `getExtension` is called with a
        different string on a WebGL context.

2017-11-02  Joseph Pecoraro  <pecoraro@apple.com>

        Make ServiceWorker a Remote Inspector debuggable target
        https://bugs.webkit.org/show_bug.cgi?id=179043
        <rdar://problem/34126008>

        Reviewed by Brian Burg.

        * inspector/remote/RemoteControllableTarget.h:
        * inspector/remote/RemoteInspectionTarget.h:
        * inspector/remote/RemoteInspectorConstants.h:
        Include a new ServiceWorker remote inspector target type.

        * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
        (Inspector::RemoteInspector::listingForInspectionTarget const):
        Implement listing for a ServiceWorker to include a URL like a page.

        * inspector/remote/glib/RemoteInspectorGlib.cpp:
        (Inspector::RemoteInspector::listingForInspectionTarget const):
        Bail for ServiceWorker support in glib. They will need to implement their support.

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

        DFG needs to handle code motion of code in for..in loop bodies
        https://bugs.webkit.org/show_bug.cgi?id=179212

        Reviewed by Keith Miller.

        The processing of the DFG nodes HasGenericProperty, HasStructureProperty & GetPropertyEnumerator
        make calls with side effects.  Updated clobberize() for those nodes to take that into account.

        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):

2017-11-02  Joseph Pecoraro  <pecoraro@apple.com>

        Inspector should display service worker served responses properly
        https://bugs.webkit.org/show_bug.cgi?id=178597
        <rdar://problem/35186111>

        Reviewed by Brian Burg.

        * inspector/protocol/Network.json:
        Expose a new "service-worker" response source.

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

        AI does not correctly model the clobber case of ArithClz32
        https://bugs.webkit.org/show_bug.cgi?id=179188

        Reviewed by Michael Saboff.

        The non-Int32 case clobbers the world because it may call valueOf.

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

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

        Unreviewed, release throw scope
        https://bugs.webkit.org/show_bug.cgi?id=178726

        * dfg/DFGOperations.cpp:

2017-11-02  Frederic Wang  <fwang@igalia.com>

        Add references to bug 179167 in FIXME comments
        https://bugs.webkit.org/show_bug.cgi?id=179168

        Reviewed by Daniel Bates.

        * Configurations/FeatureDefines.xcconfig:

2017-11-01  Jeremy Jones  <jeremyj@apple.com>

        Implement WKFullscreenWindowController for iOS.
        https://bugs.webkit.org/show_bug.cgi?id=178924
        rdar://problem/34697120

        Reviewed by Simon Fraser.

        Enable ENABLE_FULLSCREEN_API for iOS.

        * Configurations/FeatureDefines.xcconfig:

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

        Add support to throw OOM if MarkedArgumentBuffer may overflow.
        https://bugs.webkit.org/show_bug.cgi?id=179092
        <rdar://problem/35116160>

        Reviewed by Saam Barati.

        The test for overflowing a MarkedArgumentBuffer will run for a ridiculously long
        time, which renders it unsuitable for automated tests.  Instead, I've run a
        test manually to verify that an OutOfMemoryError will be thrown when an overflow
        occurs.

        The MarkedArgumentBuffer's destructor will now assert that the client has indeed
        checked for an overflow after invoking methods that may result in an overflow i.e.
        the destructor checks that MarkedArgumentBuffer::hasOverflowed() has been called.
        This is only done on debug builds.

        * API/JSObjectRef.cpp:
        (JSObjectMakeFunction):
        (JSObjectMakeArray):
        (JSObjectMakeDate):
        (JSObjectMakeRegExp):
        (JSObjectCallAsFunction):
        (JSObjectCallAsConstructor):
        * dfg/DFGOperations.cpp:
        * inspector/InjectedScriptManager.cpp:
        (Inspector::InjectedScriptManager::createInjectedScript):
        * inspector/JSJavaScriptCallFrame.cpp:
        (Inspector::JSJavaScriptCallFrame::scopeChain const):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::executeProgram):
        * jsc.cpp:
        (functionDollarAgentReceiveBroadcast):
        * runtime/ArgList.cpp:
        (JSC::MarkedArgumentBuffer::slowEnsureCapacity):
        (JSC::MarkedArgumentBuffer::expandCapacity):
        (JSC::MarkedArgumentBuffer::slowAppend):
        * runtime/ArgList.h:
        (JSC::MarkedArgumentBuffer::~MarkedArgumentBuffer):
        (JSC::MarkedArgumentBuffer::appendWithAction):
        (JSC::MarkedArgumentBuffer::append):
        (JSC::MarkedArgumentBuffer::appendWithCrashOnOverflow):
        (JSC::MarkedArgumentBuffer::hasOverflowed):
        (JSC::MarkedArgumentBuffer::setNeedsOverflowCheck):
        (JSC::MarkedArgumentBuffer::clearNeedsOverflowCheck):
        * runtime/ArrayPrototype.cpp:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/GetterSetter.cpp:
        (JSC::callSetter):
        * runtime/IteratorOperations.cpp:
        (JSC::iteratorNext):
        (JSC::iteratorClose):
        * runtime/JSBoundFunction.cpp:
        (JSC::boundThisNoArgsFunctionCall):
        (JSC::boundFunctionCall):
        (JSC::boundThisNoArgsFunctionConstruct):
        (JSC::boundFunctionConstruct):
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::constructGenericTypedArrayViewFromIterator):
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewProtoFuncSlice):
        (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::haveABadTime):
        * runtime/JSInternalPromise.cpp:
        (JSC::JSInternalPromise::then):
        * runtime/JSJob.cpp:
        (JSC::JSJobMicrotask::run):
        * runtime/JSMapIterator.cpp:
        (JSC::JSMapIterator::createPair):
        * runtime/JSModuleLoader.cpp:
        (JSC::JSModuleLoader::provideFetch):
        (JSC::JSModuleLoader::loadAndEvaluateModule):
        (JSC::JSModuleLoader::loadModule):
        (JSC::JSModuleLoader::linkAndEvaluateModule):
        (JSC::JSModuleLoader::requestImportModule):
        * runtime/JSONObject.cpp:
        (JSC::Stringifier::toJSONImpl):
        (JSC::Stringifier::appendStringifiedValue):
        (JSC::Walker::callReviver):
        * runtime/JSObject.cpp:
        (JSC::ordinarySetSlow):
        (JSC::callToPrimitiveFunction):
        (JSC::JSObject::hasInstance):
        * runtime/JSPromise.cpp:
        (JSC::JSPromise::initialize):
        (JSC::JSPromise::resolve):
        * runtime/JSPromiseDeferred.cpp:
        (JSC::newPromiseCapability):
        (JSC::callFunction):
        * runtime/JSSetIterator.cpp:
        (JSC::JSSetIterator::createPair):
        * runtime/LiteralParser.cpp:
        (JSC::LiteralParser<CharType>::parse):
        * runtime/MapConstructor.cpp:
        (JSC::constructMap):
        * runtime/ObjectConstructor.cpp:
        (JSC::defineProperties):
        * runtime/ProxyObject.cpp:
        (JSC::performProxyGet):
        (JSC::ProxyObject::performInternalMethodGetOwnProperty):
        (JSC::ProxyObject::performHasProperty):
        (JSC::ProxyObject::performPut):
        (JSC::performProxyCall):
        (JSC::performProxyConstruct):
        (JSC::ProxyObject::performDelete):
        (JSC::ProxyObject::performPreventExtensions):
        (JSC::ProxyObject::performIsExtensible):
        (JSC::ProxyObject::performDefineOwnProperty):
        (JSC::ProxyObject::performGetOwnPropertyNames):
        (JSC::ProxyObject::performSetPrototype):
        (JSC::ProxyObject::performGetPrototype):
        * runtime/ReflectObject.cpp:
        (JSC::reflectObjectConstruct):
        * runtime/SetConstructor.cpp:
        (JSC::constructSet):
        * runtime/StringPrototype.cpp:
        (JSC::replaceUsingRegExpSearch):
        (JSC::replaceUsingStringSearch):
        * runtime/WeakMapConstructor.cpp:
        (JSC::constructWeakMap):
        * runtime/WeakSetConstructor.cpp:
        (JSC::constructWeakSet):
        * wasm/js/WasmToJS.cpp:
        (JSC::Wasm::wasmToJS):

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

        Integer overflow in code generated by LoadVarargs processing in DFG and FTL.
        https://bugs.webkit.org/show_bug.cgi?id=179140

        Reviewed by Saam Barati.

        Added overflow checks to computation of arg count plus this.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileLoadVarargs):

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

        Unreviewed, use weakPointer instead of FTLOutput::weakPointer
        https://bugs.webkit.org/show_bug.cgi?id=178934

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

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

        [JSC] Introduce @toObject
        https://bugs.webkit.org/show_bug.cgi?id=178726

        Reviewed by Saam Barati.

        This patch introduces @toObject intrinsic. And we introduce op_to_object bytecode and DFG ToObject node.
        Previously we emulated @toObject behavior in builtin JS. But it consumes much bytecode size while @toObject
        is frequently seen and defined clearly in the spec. Furthermore, the emulated @toObject always calls
        ObjectConstructor in LLInt and Baseline.

        We add a new intrinsic `@toObject(target, "error message")`. It takes an error message string constant to
        offer understandable messages in builtin JS. We can change the frequently seen "emulated ToObject" operation

            if (this === @undefined || this === null)
                @throwTypeError("error message");
            var object = @Object(this);

        with

            var object = @toObject(this, "error message");

        And we handle op_to_object in DFG as ToObject node. While CallObjectConstructor does not throw an error for null/undefined,
        ToObject needs to throw an error for null/undefined. So it is marked as MustGenerate and it clobbers the world.
        In fixup phase, we attempt to convert ToObject to CallObjectConstructor with edge filters to relax its side effect.

        It also fixes a bug that CallObjectConstructor DFG node uses Node's semantic GlobalObject instead of function's one.

        * builtins/ArrayConstructor.js:
        (from):
        * builtins/ArrayPrototype.js:
        (values):
        (keys):
        (entries):
        (reduce):
        (reduceRight):
        (every):
        (forEach):
        (filter):
        (map):
        (some):
        (fill):
        (find):
        (findIndex):
        (includes):
        (sort):
        (globalPrivate.concatSlowPath):
        (copyWithin):
        * builtins/DatePrototype.js:
        (toLocaleString.toDateTimeOptionsAnyAll):
        (toLocaleString):
        (toLocaleDateString.toDateTimeOptionsDateDate):
        (toLocaleDateString):
        (toLocaleTimeString.toDateTimeOptionsTimeTime):
        (toLocaleTimeString):
        * builtins/GlobalOperations.js:
        (globalPrivate.copyDataProperties):
        (globalPrivate.copyDataPropertiesNoExclusions):
        * builtins/ObjectConstructor.js:
        (entries):
        * builtins/StringConstructor.js:
        (raw):
        * builtins/TypedArrayConstructor.js:
        (from):
        * builtins/TypedArrayPrototype.js:
        (map):
        (filter):
        * bytecode/BytecodeDumper.cpp:
        (JSC::BytecodeDumper<Block>::dumpBytecode):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitToObject):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_toObject):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::fixupToObject):
        (JSC::DFG::FixupPhase::fixupCallObjectConstructor):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToCallObjectConstructor):
        (JSC::DFG::Node::convertToNewStringObject):
        (JSC::DFG::Node::convertToNewObject):
        (JSC::DFG::Node::hasIdentifier):
        (JSC::DFG::Node::hasHeapPrediction):
        (JSC::DFG::Node::hasCellOperand):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileToObjectOrCallObjectConstructor):
        (JSC::DFG::SpeculativeJIT::compileCallObjectConstructor): Deleted.
        * 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::compileToObjectOrCallObjectConstructor):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor): Deleted.
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_to_object):
        (JSC::JIT::emitSlow_op_to_object):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_to_object):
        (JSC::JIT::emitSlow_op_to_object):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:

2017-11-01  Fujii Hironori  <Hironori.Fujii@sony.com>

        Use LazyNeverDestroyed instead of DEFINE_GLOBAL
        https://bugs.webkit.org/show_bug.cgi?id=174979

        Reviewed by Yusuke Suzuki.

        * config.h: Removed definitions of SKIP_STATIC_CONSTRUCTORS_ON_MSVC and SKIP_STATIC_CONSTRUCTORS_ON_GCC.

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

        [DFG][FTL] Introduce StringSlice
        https://bugs.webkit.org/show_bug.cgi?id=178934

        Reviewed by Saam Barati.

        String.prototype.slice is one of the most frequently called function in ARES-6/Babylon.
        This patch introduces StringSlice DFG node to optimize it in DFG and FTL.

        This patch's StringSlice node optimizes the following things.

        1. Empty string generation is accelerated. It is fully executed inline.
        2. One char string generation is accelerated. `< 0x100` character is supported right now.
        It is the same to charAt acceleration.
        3. We calculate start and end index in DFG/FTL with Int32Use information and call optimized
        operation.

        We do not inline (3)'s operation right now since we do not have a way to call bmalloc allocation from DFG / FTL.
        And we do not optimize String.prototype.{substring,substr} right now. But they can be optimized based on this change
        in subsequent changes.

        This patch improves ARES-6/Babylon performance by 3% in steady state.

        Baseline:
            Running... Babylon ( 1  to go)
            firstIteration:     50.05 +- 13.68 ms
            averageWorstCase:   16.80 +- 1.27 ms
            steadyState:        7.53 +- 0.22 ms

        Patched:
            Running... Babylon ( 1  to go)
            firstIteration:     50.91 +- 13.41 ms
            averageWorstCase:   16.12 +- 0.99 ms
            steadyState:        7.30 +- 0.29 ms

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * 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/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileStringSlice):
        (JSC::DFG::SpeculativeJIT::emitPopulateSliceIndex):
        (JSC::DFG::SpeculativeJIT::compileArraySlice):
        (JSC::DFG::SpeculativeJIT::compileArrayIndexOf):
        * 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::populateSliceRange):
        (JSC::FTL::DFG::LowerDFGToB3::compileArraySlice):
        (JSC::FTL::DFG::LowerDFGToB3::compileStringSlice):
        * jit/JITOperations.h:
        * runtime/Intrinsic.cpp:
        (JSC::intrinsicName):
        * runtime/Intrinsic.h:
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):

2017-10-31  JF Bastien  <jfbastien@apple.com>

        WebAssembly: Wasm::IndexOrName has a raw pointer to Name
        https://bugs.webkit.org/show_bug.cgi?id=176644

        Reviewed by Michael Saboff.

        IndexOrName now keeps a RefPtr to its original NameSection, which
        holds the Name (or references nullptr if Index). Holding onto the
        entire section seems like the better thing to do, since backtraces
        probably contain multiple names from the same Module.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * interpreter/Interpreter.cpp:
        (JSC::GetStackTraceFunctor::operator() const):
        * interpreter/StackVisitor.h: Frame is no longer POD because of the
        RefPtr.
        * runtime/StackFrame.cpp:
        (JSC::StackFrame::StackFrame):
        * runtime/StackFrame.h: Drop the union, size is now 40 bytes.
        (JSC::StackFrame::StackFrame): Deleted. Initialized in class instead.
        (JSC::StackFrame::wasm): Deleted. Make it a ctor instead.
        * wasm/WasmBBQPlanInlines.h:
        (JSC::Wasm::BBQPlan::initializeCallees):
        * wasm/WasmCallee.cpp:
        (JSC::Wasm::Callee::Callee):
        * wasm/WasmCallee.h:
        (JSC::Wasm::Callee::create):
        * wasm/WasmFormat.h: Move NameSection to its own header.
        (JSC::Wasm::isValidNameType):
        (JSC::Wasm::NameSection::get): Deleted.
        * wasm/WasmIndexOrName.cpp:
        (JSC::Wasm::IndexOrName::IndexOrName):
        (JSC::Wasm::makeString):
        * wasm/WasmIndexOrName.h:
        (JSC::Wasm::IndexOrName::IndexOrName):
        (JSC::Wasm::IndexOrName::isEmpty const):
        (JSC::Wasm::IndexOrName::isIndex const):
        * wasm/WasmModuleInformation.cpp:
        (JSC::Wasm::ModuleInformation::ModuleInformation):
        * wasm/WasmModuleInformation.h:
        (JSC::Wasm::ModuleInformation::ModuleInformation): Deleted.
        * wasm/WasmNameSection.h:
        (JSC::Wasm::NameSection::get):
        (JSC::Wasm::NameSection::create): Deleted.
        * wasm/WasmNameSectionParser.cpp:
        (JSC::Wasm::NameSectionParser::parse):
        * wasm/WasmNameSectionParser.h:
        * wasm/WasmOMGPlan.cpp:
        (JSC::Wasm::OMGPlan::work):

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

        Clean up some drag and drop feature flags
        https://bugs.webkit.org/show_bug.cgi?id=179082

        Reviewed by Simon Fraser.

        * Configurations/FeatureDefines.xcconfig:

2017-10-31  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r224243, r224246, and r224248.
        https://bugs.webkit.org/show_bug.cgi?id=179083

        The patch and fix broke the Windows build. (Requested by
        mlewis13 on #webkit).

        Reverted changesets:

        "StructureStubInfo should have GPRReg members not int8_ts"
        https://bugs.webkit.org/show_bug.cgi?id=179071
        https://trac.webkit.org/changeset/224243

        "Make all register enums be backed by uint8_t."
        https://bugs.webkit.org/show_bug.cgi?id=179074
        https://trac.webkit.org/changeset/224246

        "Unreviewed, windows build fix."
        https://trac.webkit.org/changeset/224248

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

        Fix up some content filtering feature flags
        https://bugs.webkit.org/show_bug.cgi?id=179079

        Reviewed by Simon Fraser.

        * Configurations/FeatureDefines.xcconfig:

2017-10-31  Keith Miller  <keith_miller@apple.com>

        Unreviewed, windows build fix.

        * assembler/X86Assembler.h:
        (JSC::X86Assembler::numberOfRegisters):
        (JSC::X86Assembler::numberOfSPRegisters):
        (JSC::X86Assembler::numberOfFPRegisters):

2017-10-31  Keith Miller  <keith_miller@apple.com>

        Make all register enums be backed by uint8_t.
        https://bugs.webkit.org/show_bug.cgi?id=179074

        Reviewed by Mark Lam.

        * assembler/ARM64Assembler.h:
        * assembler/ARMAssembler.h:
        * assembler/ARMv7Assembler.h:
        * assembler/MIPSAssembler.h:
        * assembler/MacroAssembler.h:
        * assembler/X86Assembler.h:

2017-10-31  Keith Miller  <keith_miller@apple.com>

        StructureStubInfo should have GPRReg members not int8_ts
        https://bugs.webkit.org/show_bug.cgi?id=179071

        Reviewed by Michael Saboff.

        This patch makes the various RegisterID enums be backed by
        uint8_t. This means that we can remove the old int8_t members in
        StructureStubInfo and replace them with the correct enum types.

        Also, this fixes an indentation issue in ARMv7Assembler.h.

        * assembler/ARM64Assembler.h:
        * assembler/ARMAssembler.h:
        * assembler/ARMv7Assembler.h:
        (JSC::ARMRegisters::asSingle):
        (JSC::ARMRegisters::asDouble):
        * assembler/MIPSAssembler.h:
        * assembler/X86Assembler.h:
        * bytecode/InlineAccess.cpp:
        (JSC::InlineAccess::generateSelfPropertyAccess):
        (JSC::getScratchRegister):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::PolymorphicAccess::regenerate):
        * bytecode/StructureStubInfo.h:
        (JSC::StructureStubInfo::valueRegs const):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileIn):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileIn):
        * jit/JITInlineCacheGenerator.cpp:
        (JSC::JITByIdGenerator::JITByIdGenerator):
        (JSC::JITGetByIdWithThisGenerator::JITGetByIdWithThisGenerator):

2017-10-31  Devin Rousso  <webkit@devinrousso.com>

        Web Inspector: make ScriptCallStack::maxCallStackSizeToCapture the default value when capturing backtraces
        https://bugs.webkit.org/show_bug.cgi?id=179048

        Reviewed by Mark Lam.

        * inspector/ScriptCallStackFactory.h:
        * inspector/ScriptCallStackFactory.cpp:
        (createScriptCallStack):
        (createScriptCallStackForConsole):
        (createScriptCallStackFromException):

        * inspector/ConsoleMessage.cpp:
        (Inspector::ConsoleMessage::autogenerateMetadata):
        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::reportAPIException):
        * inspector/agents/InspectorConsoleAgent.cpp:
        (Inspector::InspectorConsoleAgent::count):
        * inspector/agents/JSGlobalObjectDebuggerAgent.cpp:
        (Inspector::JSGlobalObjectDebuggerAgent::breakpointActionLog):

2017-10-31  Carlos Garcia Campos  <cgarcia@igalia.com>

        Unreviewed. Fix GTK+ make distcheck.

        Ensure DERIVED_SOURCES_JAVASCRIPTCORE_DIR/yarr is created before scripts generating files there are run.

        * CMakeLists.txt:

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

        We need a storeStoreFence before storing to the instruction stream's live variable catch data
        https://bugs.webkit.org/show_bug.cgi?id=178649

        Reviewed by Keith Miller.

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

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

        [WPE] Fix build warnings
        https://bugs.webkit.org/show_bug.cgi?id=178899

        Reviewed by Carlos Alberto Lopez Perez.

        * PlatformWPE.cmake:

2017-10-30  Zan Dobersek  <zdobersek@igalia.com>

        [ARMv7] Fix initial start register support in YarrJIT
        https://bugs.webkit.org/show_bug.cgi?id=178641

        Reviewed by Saam Barati.

        * yarr/YarrJIT.cpp: On ARMv7, use r8 as the initialStart register in the
        YarrGenerator class. r6 should be avoided since it's already used inside
        MacroAssemblerARMv7 as addressTempRegister. r7 isn't picked because it
        can be used as the frame pointer register when targetting ARM Thumb2.

2017-10-30  Zan Dobersek  <zdobersek@igalia.com>

        [ARM64][Linux] Re-enable Gigacage
        https://bugs.webkit.org/show_bug.cgi?id=178130

        Reviewed by Michael Catanzaro.

        Guard the current globaladdr opcode implementation for ARM64 with
        OS(DARWIN) as it's only usable for Mach-O.

        For OS(LINUX), ELF-supported :got: and :got_lo12: relocation specifiers
        have to be used. The .loh directive can't be used as it's not supported
        in GCC or the ld linker.

        On every other OS target, a compilation error is thrown.

        * offlineasm/arm64.rb:

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

        Web Inspector: Canvas Tab: no way to see backtrace of where a canvas context was created
        https://bugs.webkit.org/show_bug.cgi?id=178799
        <rdar://problem/35175805>

        Reviewed by Brian Burg.

        * inspector/protocol/Canvas.json:
        Add optional `backtrace` to Canvas type that is an array of Console.CallFrame.

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

        [JSC] Tweak ES6 generator function to allow inlining
        https://bugs.webkit.org/show_bug.cgi?id=178935

        Reviewed by Saam Barati.

        We optimize builtins' generator helper functions to allow them inlined in the caller side.
        This patch adjust the layer between @generatorResume, next(), throw(), and return() to allow
        them inlined in DFG.

                                       baseline                  patched

        spread-generator.es6      301.2637+-11.1011    ^    260.5905+-14.2258       ^ definitely 1.1561x faster
        generator.es6             269.6030+-13.2435    ^    148.8840+-6.7614        ^ definitely 1.8108x faster

        * builtins/GeneratorPrototype.js:
        (globalPrivate.generatorResume):
        (next):
        (return):
        (throw):

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

        Bytecode liveness should live on UnlinkedCodeBlock so it can be shared amongst CodeBlocks
        https://bugs.webkit.org/show_bug.cgi?id=178949

        Reviewed by Keith Miller.

        This patch stores BytecodeLiveness on UnlinkedCodeBlock instead of CodeBlock
        so that we don't need to recompute liveness for the same UnlinkedCodeBlock
        more than once. To do this, this patch solidifies the invariant that CodeBlock
        linking can't do anything that would change the result of liveness. For example,
        it can't introduce new locals. This invariant was met my JSC before, because we
        didn't do anything in bytecode linking that would change liveness. However, it is
        now a correctness requirement that we don't do anything that would change the
        result of running liveness. To support this change, I've refactored BytecodeGraph
        to not be tied to a CodeBlockType*. Things that perform liveness will pass in
        CodeBlockType* and the instruction stream as needed. This means that we may
        compute liveness with one CodeBlock*'s instruction stream, and then perform
        queries on that analysis with a different CodeBlock*'s instruction stream.

        This seems to be a 2% JSBench progression.

        * bytecode/BytecodeGeneratorification.cpp:
        (JSC::BytecodeGeneratorification::BytecodeGeneratorification):
        (JSC::BytecodeGeneratorification::graph):
        (JSC::BytecodeGeneratorification::storageForGeneratorLocal):
        (JSC::GeneratorLivenessAnalysis::run):
        (JSC::BytecodeGeneratorification::run):
        * bytecode/BytecodeGraph.h:
        (JSC::BytecodeGraph::BytecodeGraph):
        (JSC::BytecodeGraph::codeBlock const): Deleted.
        (JSC::BytecodeGraph::instructions): Deleted.
        (JSC::BytecodeGraph<Block>::BytecodeGraph): Deleted.
        * bytecode/BytecodeLivenessAnalysis.cpp:
        (JSC::BytecodeLivenessAnalysis::BytecodeLivenessAnalysis):
        (JSC::BytecodeLivenessAnalysis::getLivenessInfoAtBytecodeOffset):
        (JSC::BytecodeLivenessAnalysis::computeFullLiveness):
        (JSC::BytecodeLivenessAnalysis::computeKills):
        (JSC::BytecodeLivenessAnalysis::dumpResults):
        (JSC::BytecodeLivenessAnalysis::operandIsLiveAtBytecodeOffset): Deleted.
        (JSC::BytecodeLivenessAnalysis::compute): Deleted.
        * bytecode/BytecodeLivenessAnalysis.h:
        * bytecode/BytecodeLivenessAnalysisInlines.h:
        (JSC::BytecodeLivenessPropagation::stepOverInstruction):
        (JSC::BytecodeLivenessPropagation::computeLocalLivenessForBytecodeOffset):
        (JSC::BytecodeLivenessPropagation::computeLocalLivenessForBlock):
        (JSC::BytecodeLivenessPropagation::getLivenessInfoAtBytecodeOffset):
        (JSC::BytecodeLivenessPropagation::runLivenessFixpoint):
        * bytecode/BytecodeRewriter.cpp:
        (JSC::BytecodeRewriter::applyModification):
        (JSC::BytecodeRewriter::execute):
        (JSC::BytecodeRewriter::adjustJumpTargetsInFragment):
        * bytecode/BytecodeRewriter.h:
        (JSC::BytecodeRewriter::BytecodeRewriter):
        (JSC::BytecodeRewriter::removeBytecode):
        (JSC::BytecodeRewriter::graph):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffsetSlow):
        (JSC::CodeBlock::validate):
        (JSC::CodeBlock::livenessAnalysisSlow): Deleted.
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::livenessAnalysis):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::applyModification):
        (JSC::UnlinkedCodeBlock::livenessAnalysisSlow):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::livenessAnalysis):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::livenessFor):
        (JSC::DFG::Graph::killsFor):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::cleanMustHandleValuesIfNecessary):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):

2017-10-27  Keith Miller  <keith_miller@apple.com>

        Add unified source list files and build scripts to Xcode project navigator
        https://bugs.webkit.org/show_bug.cgi?id=178959

        Reviewed by Andy Estes.

        Also, Add some extra source files for so new .cpp/.mm files don't cause the build
        to fail right away. We already do this in WebCore.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * PlatformMac.cmake:
        * SourcesCocoa.txt: Renamed from Source/JavaScriptCore/SourcesMac.txt.

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

        WebAssembly: update arbitrary limits to what browsers use
        https://bugs.webkit.org/show_bug.cgi?id=178946
        <rdar://problem/34257412>
        <rdar://problem/34501154>

        Reviewed by Saam Barati.

        https://github.com/WebAssembly/design/issues/1138 discusses the
        arbitrary function size limit, which it turns out Chrome and
        Firefox didn't enforce. We didn't use it because it was
        ridiculously low and actual programs ran into that limit (bummer
        for Edge which just shipped it...). Now that we agree on a high
        arbitrary program limit, let's update it! While I'm doing this
        there are a few other spots that I polished to use Checked or
        better check limits overall.

        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::addLocal):
        * wasm/WasmFormat.cpp:
        (JSC::Wasm::Segment::create):
        * wasm/WasmFunctionParser.h:
        (JSC::Wasm::FunctionParser<Context>::parse):
        * wasm/WasmInstance.cpp:
        * wasm/WasmLimits.h:
        * wasm/WasmModuleParser.cpp:
        (JSC::Wasm::ModuleParser::parseGlobal):
        (JSC::Wasm::ModuleParser::parseCode):
        (JSC::Wasm::ModuleParser::parseData):
        * wasm/WasmSignature.h:
        (JSC::Wasm::Signature::allocatedSize):
        * wasm/WasmTable.cpp:
        (JSC::Wasm::Table::Table):
        * wasm/js/JSWebAssemblyTable.cpp:
        (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
        (JSC::JSWebAssemblyTable::grow):

2017-10-26  Michael Saboff  <msaboff@apple.com>

        REGRESSION(r222601): We fail to properly backtrack into a sub pattern of a parenthesis with non-zero minimum
        https://bugs.webkit.org/show_bug.cgi?id=178890

        Reviewed by Keith Miller.

        We need to let a contained subpattern backtrack before declaring that the containing
        parenthesis doesn't match.  If the subpattern fails to match backtracking, then we
        can check to see if we trying to backtrack below the minimum match count.
        
        * yarr/YarrInterpreter.cpp:
        (JSC::Yarr::Interpreter::backtrackParentheses):

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

        JSRopeString::RopeBuilder::append() should check for overflows.
        https://bugs.webkit.org/show_bug.cgi?id=178385
        <rdar://problem/35027468>

        Reviewed by Saam Barati.

        1. Made RopeString check for overflow like the Checked class does.
        2. Added a missing overflow check in objectProtoFuncToString().

        * runtime/JSString.cpp:
        (JSC::JSRopeString::RopeBuilder<RecordOverflow>::expand):
        (JSC::JSRopeString::RopeBuilder::expand): Deleted.
        * runtime/JSString.h:
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncToString):
        * runtime/Operations.h:
        (JSC::jsStringFromRegisterArray):
        (JSC::jsStringFromArguments):

2017-10-26  JF Bastien  <jfbastien@apple.com>

        WebAssembly: no VM / JS version of our implementation
        https://bugs.webkit.org/show_bug.cgi?id=177472

        Reviewed by Michael Saboff.

        This patch removes all appearances of "JS" and "VM" in the wasm
        directory. These now only appear in the wasm/js directory, which
        is only used in a JS embedding of wasm. It should therefore now be
        possible to create non-JS embeddings of wasm through JSC, though
        it'll still require:

          - Mild codegen for wasm<->embedder calls;
          - A strategy for trap handling (no need for full unwind! Could kill).
          - Creation of the Wasm::* objects.
          - Calling convention handling to call the embedder.
          - Handling of multiple embedders (see #177475, this is optional).

        Most of the patch consists in renaming JSWebAssemblyInstance to
        Instance, and removing temporary copies which I'd added to make
        this specific patch very simple.

        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::wasmAwareLexicalGlobalObject): this one place
        which needs to know about who "owns" the Wasm::Instance. In a JS
        embedding it's the JSWebAssemblyInstance.
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
        (JSC::Wasm::B3IRGenerator::addGrowMemory):
        (JSC::Wasm::B3IRGenerator::addCurrentMemory):
        (JSC::Wasm::B3IRGenerator::getGlobal):
        (JSC::Wasm::B3IRGenerator::setGlobal):
        (JSC::Wasm::B3IRGenerator::addCall):
        (JSC::Wasm::B3IRGenerator::addCallIndirect):
        * wasm/WasmBinding.cpp:
        (JSC::Wasm::wasmToWasm):
        * wasm/WasmContext.cpp:
        (JSC::Wasm::Context::load const):
        (JSC::Wasm::Context::store):
        * wasm/WasmContext.h:
        * wasm/WasmEmbedder.h:
        * wasm/WasmInstance.cpp:
        (JSC::Wasm::Instance::Instance):
        (JSC::Wasm::Instance::create):
        (JSC::Wasm::Instance::extraMemoryAllocated const):
        * wasm/WasmInstance.h: add an "owner", the Wasm::Context, move the
        "tail" import information from JSWebAssemblyInstance over to here.
        (JSC::Wasm::Instance::finalizeCreation):
        (JSC::Wasm::Instance::owner const):
        (JSC::Wasm::Instance::offsetOfOwner):
        (JSC::Wasm::Instance::context const):
        (JSC::Wasm::Instance::setMemory):
        (JSC::Wasm::Instance::setTable):
        (JSC::Wasm::Instance::offsetOfMemory):
        (JSC::Wasm::Instance::offsetOfGlobals):
        (JSC::Wasm::Instance::offsetOfTable):
        (JSC::Wasm::Instance::offsetOfTail):
        (JSC::Wasm::Instance::numImportFunctions const):
        (JSC::Wasm::Instance::importFunctionInfo):
        (JSC::Wasm::Instance::offsetOfTargetInstance):
        (JSC::Wasm::Instance::offsetOfWasmEntrypoint):
        (JSC::Wasm::Instance::offsetOfWasmToEmbedderStubExecutableAddress):
        (JSC::Wasm::Instance::offsetOfImportFunction):
        (JSC::Wasm::Instance::importFunction):
        (JSC::Wasm::Instance::allocationSize):
        (JSC::Wasm::Instance::create): Deleted.
        * wasm/WasmOMGPlan.cpp:
        (JSC::Wasm::OMGPlan::runForIndex):
        * wasm/WasmOMGPlan.h:
        * wasm/WasmTable.cpp:
        (JSC::Wasm::Table::Table):
        (JSC::Wasm::Table::setFunction):
        * wasm/WasmTable.h:
        * wasm/WasmThunks.cpp:
        (JSC::Wasm::throwExceptionFromWasmThunkGenerator):
        (JSC::Wasm::triggerOMGTierUpThunkGenerator):
        * wasm/js/JSToWasm.cpp:
        (JSC::Wasm::createJSToWasmWrapper):
        * wasm/js/JSWebAssemblyInstance.cpp: delete code that is now on Wasm::Instance
        (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance): The embedder
        decides what the import function is. Here we must properly
        placement-new it to what we've elected (and initialize it later).
        (JSC::JSWebAssemblyInstance::visitChildren):
        (JSC::JSWebAssemblyInstance::finalizeCreation):
        (JSC::JSWebAssemblyInstance::create):
        * wasm/js/JSWebAssemblyInstance.h: delete code that is now on Wasm::Instance
        (JSC::JSWebAssemblyInstance::instance):
        (JSC::JSWebAssemblyInstance::moduleNamespaceObject):
        (JSC::JSWebAssemblyInstance::setMemory):
        (JSC::JSWebAssemblyInstance::table):
        (JSC::JSWebAssemblyInstance::setTable):
        (JSC::JSWebAssemblyInstance::offsetOfInstance):
        (JSC::JSWebAssemblyInstance::offsetOfCallee):
        (JSC::JSWebAssemblyInstance::context const): Deleted.
        (JSC::JSWebAssemblyInstance::offsetOfTail): Deleted.
        (): Deleted.
        (JSC::JSWebAssemblyInstance::importFunctionInfo): Deleted.
        (JSC::JSWebAssemblyInstance::offsetOfTargetInstance): Deleted.
        (JSC::JSWebAssemblyInstance::offsetOfWasmEntrypoint): Deleted.
        (JSC::JSWebAssemblyInstance::offsetOfWasmToEmbedderStubExecutableAddress): Deleted.
        (JSC::JSWebAssemblyInstance::offsetOfImportFunction): Deleted.
        (JSC::JSWebAssemblyInstance::importFunction): Deleted.
        (JSC::JSWebAssemblyInstance::internalMemory): Deleted.
        (JSC::JSWebAssemblyInstance::wasmCodeBlock const): Deleted.
        (JSC::JSWebAssemblyInstance::offsetOfWasmTable): Deleted.
        (JSC::JSWebAssemblyInstance::offsetOfGlobals): Deleted.
        (JSC::JSWebAssemblyInstance::offsetOfCodeBlock): Deleted.
        (JSC::JSWebAssemblyInstance::offsetOfWasmCodeBlock): Deleted.
        (JSC::JSWebAssemblyInstance::offsetOfCachedStackLimit): Deleted.
        (JSC::JSWebAssemblyInstance::offsetOfWasmMemory): Deleted.
        (JSC::JSWebAssemblyInstance::offsetOfTopEntryFramePointer): Deleted.
        (JSC::JSWebAssemblyInstance::cachedStackLimit const): Deleted.
        (JSC::JSWebAssemblyInstance::setCachedStackLimit): Deleted.
        (JSC::JSWebAssemblyInstance::wasmMemory): Deleted.
        (JSC::JSWebAssemblyInstance::wasmModule): Deleted.
        (JSC::JSWebAssemblyInstance::allocationSize): Deleted.
        * wasm/js/JSWebAssemblyTable.cpp:
        (JSC::JSWebAssemblyTable::setFunction):
        * wasm/js/WasmToJS.cpp: One extra indirection to find the JSWebAssemblyInstance.
        (JSC::Wasm::materializeImportJSCell):
        (JSC::Wasm::handleBadI64Use):
        (JSC::Wasm::wasmToJS):
        (JSC::Wasm::wasmToJSException):
        * wasm/js/WasmToJS.h:
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction):
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::constructJSWebAssemblyInstance):
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::link):
        (JSC::WebAssemblyModuleRecord::evaluate):
        * wasm/js/WebAssemblyPrototype.cpp:
        (JSC::instantiate):
        * wasm/js/WebAssemblyWrapperFunction.cpp:
        (JSC::WebAssemblyWrapperFunction::create):

2017-10-25  Devin Rousso  <webkit@devinrousso.com>

        Web Inspector: provide a way to enable/disable event listeners
        https://bugs.webkit.org/show_bug.cgi?id=177451
        <rdar://problem/34994925>

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/DOM.json:
        Add `setEventListenerDisabled` command that enables/disables a specific event listener
        during event dispatch. When a disabled event listener is fired, the listener's callback will
        not be called.

2017-10-25  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r223691 and r223729.
        https://bugs.webkit.org/show_bug.cgi?id=178834

        Broke Speedometer 2 React-Redux-TodoMVC test case (Requested
        by rniwa on #webkit).

        Reverted changesets:

        "Turn recursive tail calls into loops"
        https://bugs.webkit.org/show_bug.cgi?id=176601
        https://trac.webkit.org/changeset/223691

        "REGRESSION(r223691): DFGByteCodeParser.cpp:1483:83: warning:
        comparison is always false due to limited range of data type
        [-Wtype-limits]"
        https://bugs.webkit.org/show_bug.cgi?id=178543
        https://trac.webkit.org/changeset/223729

2017-10-25  Michael Saboff  <msaboff@apple.com>

        REGRESSION(r223937): Use of -fobjc-weak causes build failures with older compilers
        https://bugs.webkit.org/show_bug.cgi?id=178825

        Reviewed by Mark Lam.

        Enable ARC for ARM64_32.  This eliminate the need for setting CLANG_ENABLE_OBJC_WEAK.

        * Configurations/ToolExecutable.xcconfig:

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

        Fix implicit cast of enum, which seems to break the windows build of unified sources.
        https://bugs.webkit.org/show_bug.cgi?id=178822

        Reviewed by Saam Barati.

        * bytecode/DFGExitProfile.h:
        (JSC::DFG::FrequentExitSite::hash const):

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

        Allow OjbC Weak References when building TestAPI
        https://bugs.webkit.org/show_bug.cgi?id=178748

        Reviewed by Dan Bernstein.

        Set TestAPI build flag Weak References in Manual Retain Release to true.

        * JavaScriptCore.xcodeproj/project.pbxproj: Reverted.
        * Configurations/ToolExecutable.xcconfig: Changed the flag here instead.

2017-10-24  Eric Carlson  <eric.carlson@apple.com>

        Web Inspector: Enable WebKit logging configuration and display
        https://bugs.webkit.org/show_bug.cgi?id=177027
        <rdar://problem/33964767>

        Reviewed by Joseph Pecoraro.

        * inspector/ConsoleMessage.cpp:
        (Inspector::messageSourceValue): Inspector::Protocol::Console::ConsoleMessage -> 
            Inspector::Protocol::Console::ChannelSource.
        * inspector/agents/JSGlobalObjectConsoleAgent.cpp:
        (Inspector::JSGlobalObjectConsoleAgent::getLoggingChannels): There are no logging channels
            specific to a JSContext yet, so return an empty channel array.
        (Inspector::JSGlobalObjectConsoleAgent::setLoggingChannelLevel): No channels, return an error.
        * inspector/agents/JSGlobalObjectConsoleAgent.h:

        * inspector/protocol/Console.json: Add ChannelSource, ChannelLevel, and Channel. Add getLoggingChannels
            and setLoggingChannelLevel.

        * inspector/scripts/codegen/generator.py: Special case "webrtc"-> "WebRTC".
        * inspector/scripts/tests/generic/expected/enum-values.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:

        * runtime/ConsoleTypes.h: Add Media and WebRTC.

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

        Allow OjbC Weak References when building TestAPI
        https://bugs.webkit.org/show_bug.cgi?id=178748

        Reviewed by Saam Barati.

        Set TestAPI build flag Weak References in Manual Retain Release to true.

        * JavaScriptCore.xcodeproj/project.pbxproj:

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

        [FTL] Support NewStringObject
        https://bugs.webkit.org/show_bug.cgi?id=178737

        Reviewed by Saam Barati.

        FTL should support NewStringObject and encourage use of NewStringObject in DFG pipeline.
        After this change, we can convert `CallObjectConstructor(String)` to `NewStringObject(String)`.

        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewStringObject):

2017-10-24  Guillaume Emont  <guijemont@igalia.com>

        [mips] fix offsets of branches that have to go over a jump
        https://bugs.webkit.org/show_bug.cgi?id=153464

        The jump() function creates 8 instructions, but the offsets of branches
        meant to go over them only account for 6. In most cases, this is not an
        issue as the last two instructions of jump() would be nops, but in the
        rarer case where the jump destination is in a different 256 MB segment,
        MIPSAssembler::linkWithOffset() will rewrite the code in a way in which
        the last 4 instructions would be a 2 instruction load (lui/ori) into
        $t9, a "j $t9" and then a nop. The wrong offset will mean that the
        previous branches meant to go over the whole jump will branch to the
        "j $t9" instruction, which would jump to whatever is currently in $t9
        (since lui/ori would not be executed).

        Reviewed by Michael Catanzaro.

        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::branchAdd32):
        (JSC::MacroAssemblerMIPS::branchMul32):
        (JSC::MacroAssemblerMIPS::branchSub32):
        Fix the offsets of branches meant to go over code generated by jump().

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

        WebAssembly: NFC renames of things that aren't JS-specific
        https://bugs.webkit.org/show_bug.cgi?id=178738

        Reviewed by Saam Barati.

        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::parseAndCompile):
        * wasm/WasmB3IRGenerator.h:
        * wasm/WasmBBQPlan.cpp:
        (JSC::Wasm::BBQPlan::complete):
        * wasm/WasmCodeBlock.cpp:
        (JSC::Wasm::CodeBlock::CodeBlock):
        * wasm/WasmCodeBlock.h:
        (JSC::Wasm::CodeBlock::embedderEntrypointCalleeFromFunctionIndexSpace):
        (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace): Deleted.
        * wasm/WasmFormat.h:
        * wasm/js/JSToWasm.cpp:
        (JSC::Wasm::createJSToWasmWrapper):
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::link):
        (JSC::WebAssemblyModuleRecord::evaluate):

2017-10-24  Stephan Szabo  <stephan.szabo@sony.com>

        [Win][JSCOnly] Make jsconly build testapi and dlls and copy dlls when running tests
        https://bugs.webkit.org/show_bug.cgi?id=177279

        Reviewed by Yusuke Suzuki.

        * shell/PlatformJSCOnly.cmake: Added.

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

        [JSC] modules can be visited more than once when resolving bindings through "star" exports as long as the exportName is different each time
        https://bugs.webkit.org/show_bug.cgi?id=178308

        Reviewed by Mark Lam.

        With the change of the spec[1], we now do not need to remember star resolution modules.
        We reflect this change to our implementation. Since this change is covered by test262,
        this patch improves the score of test262.

        We also add logging to ResolveExport to debug it easily.

        [1]: https://github.com/tc39/ecma262/commit/a865e778ff0fc60e26e3e1c589635103710766a1

        * runtime/AbstractModuleRecord.cpp:
        (JSC::AbstractModuleRecord::ResolveQuery::dump const):
        (JSC::AbstractModuleRecord::resolveExportImpl):

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

        [JSC] Use emitDumbVirtualCall in 32bit JIT
        https://bugs.webkit.org/show_bug.cgi?id=178644

        Reviewed by Mark Lam.

        This patch aligns 32bit JIT op_call_eval slow case to 64bit version by using emitDumbVirtualCall.

        * jit/JITCall32_64.cpp:
        (JSC::JIT::compileCallEvalSlowCase):

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

        [JSC] Drop ArityCheckData
        https://bugs.webkit.org/show_bug.cgi?id=178648

        Reviewed by Mark Lam.

        ArityCheckData is used to return a pair of `slotsToAdd` and `thunkToCall`.
        However, use of `thunkToCall` is removed in 64bit environment at r189575.

        We remove `thunkToCall` and align 32bit implementation to 64bit implementation.
        Since we no longer need to have the above pair, we can remove ArityCheckData too.

        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        (JSC::setupArityCheckData): Deleted.
        * runtime/CommonSlowPaths.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

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

        Unreviewed, reland r223866

        Didn't break the windows build...

        Restored changeset:

        "WebAssembly: topEntryFrame on Wasm::Instance"
        https://bugs.webkit.org/show_bug.cgi?id=178690
        https://trac.webkit.org/changeset/223866


2017-10-23  Commit Queue  <commit-queue@webkit.org>

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

        Probably broke the windows build (Requested by keith_miller on
        #webkit).

        Reverted changeset:

        "WebAssembly: topEntryFrame on Wasm::Instance"
        https://bugs.webkit.org/show_bug.cgi?id=178690
        https://trac.webkit.org/changeset/223866

2017-10-23  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Remove unused Console.setMonitoringXHREnabled
        https://bugs.webkit.org/show_bug.cgi?id=178617

        Reviewed by Sam Weinig.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * inspector/agents/InspectorConsoleAgent.h:
        * inspector/agents/JSGlobalObjectConsoleAgent.cpp: Removed.
        * inspector/agents/JSGlobalObjectConsoleAgent.h: Removed.
        * inspector/protocol/Console.json:
        Removed files and method.

        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
        This can use the base ConsoleAgent now.

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

        WebAssembly: topEntryFrame on Wasm::Instance
        https://bugs.webkit.org/show_bug.cgi?id=178690

        Reviewed by Saam Barati.

        topEntryFrame is usually on VM, but for a no-VM WebAssembly we
        need to hold topEntryFrame elsewhere, and generated code cannot
        hard-code where topEntryFrame live. Do this at creation time of
        Wasm::Instance, and then generated code will just load from
        wherever Wasm::Instance was told topEntryFrame is. In a JavaScript
        embedding this is still from VM, so all of the unwinding machinery
        stays the same.

        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
        (JSC::DFG::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        * interpreter/Interpreter.cpp:
        (JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::restoreCalleeSavesFromEntryFrameCalleeSavesBuffer):
        (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBufferImpl):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBuffer):
        The default parameter was never non-defaulted from any of the
        callers. The new version calls the impl directly because it
        doesn't have VM and doesn't hard-code the address of
        topEntryFrame.
        * jit/RegisterSet.cpp:
        (JSC::RegisterSet::vmCalleeSaveRegisterOffsets): This was weird on
        VM because it's not really VM-specific.
        * jit/RegisterSet.h:
        * runtime/VM.cpp:
        (JSC::VM::getAllCalleeSaveRegisterOffsets): Deleted.
        * runtime/VM.h:
        (JSC::VM::getCTIStub):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        (JSC::Wasm::B3IRGenerator::addCall):
        (JSC::Wasm::B3IRGenerator::addCallIndirect):
        * wasm/WasmInstance.cpp:
        (JSC::Wasm::Instance::Instance):
        * wasm/WasmInstance.h: topEntryFramePointer will eventually live
        here for real. Right now it's mirrored in JSWebAssemblyInstance
        because that's the acting Context.
        (JSC::Wasm::Instance::create):
        (JSC::Wasm::Instance::offsetOfTopEntryFramePointer):
        * wasm/WasmThunks.cpp:
        (JSC::Wasm::throwExceptionFromWasmThunkGenerator):
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
        * wasm/js/JSWebAssemblyInstance.h: Mirror Wasm::Instance temporarily.
        (JSC::JSWebAssemblyInstance::offsetOfCallee):
        (JSC::JSWebAssemblyInstance::offsetOfTopEntryFramePointer):
        (JSC::JSWebAssemblyInstance::offsetOfVM): Deleted.
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::constructJSWebAssemblyInstance):
        * wasm/js/WebAssemblyPrototype.cpp:
        (JSC::instantiate):

2017-10-23  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Please support HAR Export for network traffic
        https://bugs.webkit.org/show_bug.cgi?id=146692
        <rdar://problem/7463672>

        Reviewed by Brian Burg.

        * inspector/protocol/Network.json:
        Add a walltime to each send request.

2017-10-23  Matt Lewis  <jlewis3@apple.com>

        Unreviewed, rolling out r223820.

        This caused a build break on Windows.

        Reverted changeset:

        "Web Inspector: Remove unused Console.setMonitoringXHREnabled"
        https://bugs.webkit.org/show_bug.cgi?id=178617
        https://trac.webkit.org/changeset/223820

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

        [JSC] Use fastJoin in Array#toString
        https://bugs.webkit.org/show_bug.cgi?id=178062

        Reviewed by Darin Adler.

        Array#toString()'s fast path uses original join operation.
        But this should use fastJoin if possible.
        This patch adds a fast path using fastJoin in Array#toString.
        And we also extend fastJoin to perform fast joining for int32
        arrays.

                                             baseline                  patched

        double-array-to-string          126.6157+-5.8625     ^    103.7343+-4.4968        ^ definitely 1.2206x faster
        int32-array-to-string            64.7792+-2.6524           61.2390+-2.1749          might be 1.0578x faster
        contiguous-array-to-string       62.6224+-2.6388     ^     56.9899+-2.0852        ^ definitely 1.0988x faster


        * runtime/ArrayPrototype.cpp:
        (JSC::fastJoin):
        (JSC::arrayProtoFuncToString):
        (JSC::arrayProtoFuncToLocaleString):
        * runtime/JSStringJoiner.h:
        (JSC::JSStringJoiner::appendWithoutSideEffects):
        (JSC::JSStringJoiner::appendInt32):
        (JSC::JSStringJoiner::appendDouble):

2017-10-22  Zan Dobersek  <zdobersek@igalia.com>

        [JSC] Remove !(OS(LINUX) && CPU(ARM64)) guards in RegisterState.h
        https://bugs.webkit.org/show_bug.cgi?id=178452

        Reviewed by Yusuke Suzuki.

        * heap/RegisterState.h: Re-enable the custom RegisterState and
        ALLOCATE_AND_GET_REGISTER_STATE definitions on ARM64 Linux. These don't
        cause any crashes nowadays.

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

        [JSC][Baseline] Use linkAllSlowCasesForBytecodeOffset as much as possible to simplify slow cases handling
        https://bugs.webkit.org/show_bug.cgi?id=178647

        Reviewed by Saam Barati.

        There is much code counting slow cases in fast paths to call `linkSlowCase` carefully. This is really error-prone
        since the number of slow cases depends on values of instruction's metadata. We have linkAllSlowCasesForBytecodeOffset,
        which drains all slow cases for a specified bytecode offset. In typical cases like just calling a slow path function,
        this is enough. We use linkAllSlowCasesForBytecodeOffset as much as possible. It significantly simplifies the code.

        * jit/JIT.h:
        (JSC::JIT::linkAllSlowCases):
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emitSlow_op_unsigned):
        (JSC::JIT::emit_compareAndJump):
        (JSC::JIT::emit_compareAndJumpSlow):
        (JSC::JIT::emitSlow_op_inc):
        (JSC::JIT::emitSlow_op_dec):
        (JSC::JIT::emitSlow_op_mod):
        (JSC::JIT::emitSlow_op_negate):
        (JSC::JIT::emitSlow_op_bitand):
        (JSC::JIT::emitSlow_op_bitor):
        (JSC::JIT::emitSlow_op_bitxor):
        (JSC::JIT::emitSlow_op_lshift):
        (JSC::JIT::emitSlow_op_rshift):
        (JSC::JIT::emitSlow_op_urshift):
        (JSC::JIT::emitSlow_op_add):
        (JSC::JIT::emitSlow_op_div):
        (JSC::JIT::emitSlow_op_mul):
        (JSC::JIT::emitSlow_op_sub):
        * jit/JITArithmetic32_64.cpp:
        (JSC::JIT::emit_compareAndJumpSlow):
        (JSC::JIT::emitSlow_op_unsigned):
        (JSC::JIT::emitSlow_op_inc):
        (JSC::JIT::emitSlow_op_dec):
        (JSC::JIT::emitSlow_op_mod):
        * jit/JITCall.cpp:
        (JSC::JIT::compileCallEvalSlowCase):
        (JSC::JIT::compileOpCallSlowCase):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::compileCallEvalSlowCase):
        (JSC::JIT::compileOpCallSlowCase):
        * jit/JITInlines.h:
        (JSC::JIT::linkAllSlowCasesForBytecodeOffset):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emitSlow_op_new_object):
        (JSC::JIT::emitSlow_op_create_this):
        (JSC::JIT::emitSlow_op_check_tdz):
        (JSC::JIT::emitSlow_op_to_this):
        (JSC::JIT::emitSlow_op_to_primitive):
        (JSC::JIT::emitSlow_op_not):
        (JSC::JIT::emitSlow_op_eq):
        (JSC::JIT::emitSlow_op_neq):
        (JSC::JIT::emitSlow_op_stricteq):
        (JSC::JIT::emitSlow_op_nstricteq):
        (JSC::JIT::emitSlow_op_instanceof):
        (JSC::JIT::emitSlow_op_instanceof_custom):
        (JSC::JIT::emitSlow_op_to_number):
        (JSC::JIT::emitSlow_op_to_string):
        (JSC::JIT::emitSlow_op_loop_hint):
        (JSC::JIT::emitSlow_op_check_traps):
        (JSC::JIT::emitSlow_op_has_indexed_property):
        (JSC::JIT::emitSlow_op_get_direct_pname):
        (JSC::JIT::emitSlow_op_has_structure_property):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emitSlow_op_new_object):
        (JSC::JIT::emitSlow_op_instanceof):
        (JSC::JIT::emitSlow_op_instanceof_custom):
        (JSC::JIT::emitSlow_op_to_primitive):
        (JSC::JIT::emitSlow_op_not):
        (JSC::JIT::emitSlow_op_stricteq):
        (JSC::JIT::emitSlow_op_nstricteq):
        (JSC::JIT::emitSlow_op_to_number):
        (JSC::JIT::emitSlow_op_to_string):
        (JSC::JIT::emitSlow_op_create_this):
        (JSC::JIT::emitSlow_op_to_this):
        (JSC::JIT::emitSlow_op_check_tdz):
        (JSC::JIT::emitSlow_op_has_indexed_property):
        (JSC::JIT::emitSlow_op_get_direct_pname):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitSlow_op_try_get_by_id):
        (JSC::JIT::emitSlow_op_get_by_id):
        (JSC::JIT::emitSlow_op_get_by_id_with_this):
        (JSC::JIT::emitSlow_op_put_by_id):
        (JSC::JIT::emitSlow_op_resolve_scope):
        (JSC::JIT::emitSlow_op_get_from_scope):
        (JSC::JIT::emitSlow_op_put_to_scope):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emitSlow_op_try_get_by_id):
        (JSC::JIT::emitSlow_op_get_by_id):
        (JSC::JIT::emitSlow_op_get_by_id_with_this):
        (JSC::JIT::emitSlow_op_put_by_id):
        (JSC::JIT::emitSlow_op_resolve_scope):
        (JSC::JIT::emitSlow_op_get_from_scope):
        (JSC::JIT::emitSlow_op_put_to_scope):

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

        [JSC] Clean up baseline slow path
        https://bugs.webkit.org/show_bug.cgi?id=178646

        Reviewed by Saam Barati.

        If the given op is just calling a slow path function, we should use DEFINE_SLOW_OP instead.
        It is good since (1) we can reduce the manual emitting code and (2) it can clarify which
        function is implemented as a slow path call. This patch is an attempt to reduce 32bit specific
        code in baseline JIT.

        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_pow): Deleted.
        * jit/JITArithmetic32_64.cpp:
        (JSC::JIT::emitSlow_op_mod):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_strcat): Deleted.
        (JSC::JIT::emit_op_push_with_scope): Deleted.
        (JSC::JIT::emit_op_assert): Deleted.
        (JSC::JIT::emit_op_create_lexical_environment): Deleted.
        (JSC::JIT::emit_op_throw_static_error): Deleted.
        (JSC::JIT::emit_op_new_array_with_spread): Deleted.
        (JSC::JIT::emit_op_spread): Deleted.
        (JSC::JIT::emit_op_get_enumerable_length): Deleted.
        (JSC::JIT::emit_op_has_generic_property): Deleted.
        (JSC::JIT::emit_op_get_property_enumerator): Deleted.
        (JSC::JIT::emit_op_to_index_string): Deleted.
        (JSC::JIT::emit_op_create_direct_arguments): Deleted.
        (JSC::JIT::emit_op_create_scoped_arguments): Deleted.
        (JSC::JIT::emit_op_create_cloned_arguments): Deleted.
        (JSC::JIT::emit_op_create_rest): Deleted.
        (JSC::JIT::emit_op_unreachable): Deleted.
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_strcat): Deleted.
        (JSC::JIT::emit_op_push_with_scope): Deleted.
        (JSC::JIT::emit_op_assert): Deleted.
        (JSC::JIT::emit_op_create_lexical_environment): Deleted.
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_put_by_val_with_this): Deleted.
        (JSC::JIT::emit_op_get_by_val_with_this): Deleted.
        (JSC::JIT::emit_op_put_by_id_with_this): Deleted.
        (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval): Deleted.
        (JSC::JIT::emit_op_define_data_property): Deleted.
        (JSC::JIT::emit_op_define_accessor_property): Deleted.
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval): Deleted.
        (JSC::JIT::emit_op_get_by_val_with_this): Deleted.
        (JSC::JIT::emit_op_put_by_id_with_this): Deleted.
        (JSC::JIT::emit_op_put_by_val_with_this): Deleted.

2017-10-21  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Remove unused Console.setMonitoringXHREnabled
        https://bugs.webkit.org/show_bug.cgi?id=178617

        Reviewed by Sam Weinig.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * inspector/agents/InspectorConsoleAgent.h:
        * inspector/agents/JSGlobalObjectConsoleAgent.cpp: Removed.
        * inspector/agents/JSGlobalObjectConsoleAgent.h: Removed.
        * inspector/protocol/Console.json:
        Removed files and method.

        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
        This can use the base ConsoleAgent now.

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

        [JSC] Remove per-host-function CTI stub in 32bit environment
        https://bugs.webkit.org/show_bug.cgi?id=178581

        Reviewed by Saam Barati.

        JIT::privateCompileCTINativeCall only exists in 32bit environment and it is almost the same to native call CTI stub.
        The only difference is that it embed the address of the host function directly in the generated stub. This means
        that we have per-host-function CTI stub only in 32bit environment.

        This patch just removes it and use one CTI stub instead. This design is the same to the current 64bit implementation.

        * jit/JIT.cpp:
        (JSC::JIT::compileCTINativeCall): Deleted.
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::privateCompileCTINativeCall): Deleted.
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::privateCompileCTINativeCall): Deleted.
        * jit/JITThunks.cpp:
        (JSC::JITThunks::hostFunctionStub):

2017-10-20  Antoine Quint  <graouts@apple.com>

        [Web Animations] Provide basic timeline and animation interfaces
        https://bugs.webkit.org/show_bug.cgi?id=178526

        Reviewed by Dean Jackson.

        Remove the WEB_ANIMATIONS compile-time flag.

        * Configurations/FeatureDefines.xcconfig:

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

        Unreviewed, rolling out r223744, r223750, and r223751.
        https://bugs.webkit.org/show_bug.cgi?id=178594

        These caused consistent failures in test that existed and were
        added in the patches. (Requested by mlewis13 on #webkit).

        Reverted changesets:

        "[JSC] ScriptFetcher should be notified directly from module
        pipeline"
        https://bugs.webkit.org/show_bug.cgi?id=178340
        https://trac.webkit.org/changeset/223744

        "Unreviewed, fix changed line number in test expect files"
        https://bugs.webkit.org/show_bug.cgi?id=178340
        https://trac.webkit.org/changeset/223750

        "Unreviewed, follow up to reflect comments"
        https://bugs.webkit.org/show_bug.cgi?id=178340
        https://trac.webkit.org/changeset/223751

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

        Unreviewed, follow up to reflect comments
        https://bugs.webkit.org/show_bug.cgi?id=178340

        * runtime/JSModuleLoader.cpp:
        (JSC::JSModuleLoader::notifyCompleted):

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

        Optimize accesses to how we get the direct prototype
        https://bugs.webkit.org/show_bug.cgi?id=178548

        Reviewed by Yusuke Suzuki.

        This patch makes JSObject::getPrototypeDirect take VM& as a parameter
        so it can use the faster version of the structure accessor function.
        The reason for making this change is that JSObjet::getPrototypeDirect
        is called on the hot path in property lookup.

        * API/JSObjectRef.cpp:
        (JSObjectGetPrototype):
        * jsc.cpp:
        (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::slowCall):
        (WTF::DOMJITGetterBaseJSObject::customGetter):
        (functionCreateProxy):
        * runtime/ArrayPrototype.cpp:
        (JSC::speciesWatchpointIsValid):
        * runtime/ErrorInstance.cpp:
        (JSC::ErrorInstance::sanitizedToString):
        * runtime/JSArray.cpp:
        (JSC::JSArray::isIteratorProtocolFastAndNonObservable):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::lastInPrototypeChain):
        (JSC::JSGlobalObject::resetPrototype):
        (JSC::JSGlobalObject::finishCreation):
        * runtime/JSGlobalObjectInlines.h:
        (JSC::JSGlobalObject::objectPrototypeIsSane):
        (JSC::JSGlobalObject::arrayPrototypeChainIsSane):
        (JSC::JSGlobalObject::stringPrototypeChainIsSane):
        * runtime/JSLexicalEnvironment.cpp:
        (JSC::JSLexicalEnvironment::getOwnPropertySlot):
        * runtime/JSMap.cpp:
        (JSC::JSMap::isIteratorProtocolFastAndNonObservable):
        * runtime/JSObject.cpp:
        (JSC::JSObject::calculatedClassName):
        (JSC::JSObject::setPrototypeWithCycleCheck):
        (JSC::JSObject::getPrototype):
        (JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype):
        (JSC::JSObject::attemptToInterceptPutByIndexOnHole):
        (JSC::JSObject::anyObjectInChainMayInterceptIndexedAccesses const):
        (JSC::JSObject::prototypeChainMayInterceptStoreTo):
        * runtime/JSObject.h:
        (JSC::JSObject::finishCreation):
        (JSC::JSObject::getPrototypeDirect const):
        (JSC::JSObject::getPrototype):
        * runtime/JSObjectInlines.h:
        (JSC::JSObject::canPerformFastPutInline):
        (JSC::JSObject::getPropertySlot):
        (JSC::JSObject::getNonIndexPropertySlot):
        * runtime/JSProxy.cpp:
        (JSC::JSProxy::setTarget):
        * runtime/JSSet.cpp:
        (JSC::JSSet::isIteratorProtocolFastAndNonObservable):
        * runtime/ProgramExecutable.cpp:
        (JSC::ProgramExecutable::initializeGlobalProperties):
        * runtime/StructureInlines.h:
        (JSC::Structure::isValid const):

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

        [ARM64] static_cast<int32_t>() in BinaryOpNode::emitBytecode() prevents op_unsigned emission
        https://bugs.webkit.org/show_bug.cgi?id=178379

        Reviewed by Saam Barati.

        We reuse jsNumber's checking mechanism here to precisely check the generated number is within uint32_t
        in bytecode compiler. This is reasonable since the NumberNode will generate the exact this JSValue.

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

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

        [JSC] ScriptFetcher should be notified directly from module pipeline
        https://bugs.webkit.org/show_bug.cgi?id=178340

        Reviewed by Sam Weinig.

        Previously, we use JSStdFunction to let WebCore inform the module pipeline results.
        We setup JSStdFunction to the resulted promise of the module pipeline. It is super
        ad-hoc since JSStdFunction's lambda need extra-careful to make it non-cyclic-referenced.
        JSStdFunction's lambda can capture variables, but they are not able to be marked by GC.

        But now, we have ScriptFetcher. It is introduced after we implemented the module pipeline
        notification mechanism by using JSStdFunction. But it is appropriate one to receive notification
        from the module pipeline by observer style.

        This patch removes the above ad-hoc JSStdFunction use. And now ScriptFetcher receives
        completion/failure notifications from the module pipeline.

        * builtins/ModuleLoaderPrototype.js:
        (loadModule):
        (loadAndEvaluateModule):
        * runtime/Completion.cpp:
        (JSC::loadModule):
        * runtime/Completion.h:
        * runtime/JSModuleLoader.cpp:
        (JSC::jsValueToModuleKey):
        (JSC::JSModuleLoader::notifyCompleted):
        (JSC::JSModuleLoader::notifyFailed):
        * runtime/JSModuleLoader.h:
        * runtime/ModuleLoaderPrototype.cpp:
        (JSC::moduleLoaderPrototypeNotifyCompleted):
        (JSC::moduleLoaderPrototypeNotifyFailed):
        * runtime/ScriptFetcher.h:
        (JSC::ScriptFetcher::notifyLoadCompleted):
        (JSC::ScriptFetcher::notifyLoadFailed):

2017-10-19  JF Bastien  <jfbastien@apple.com>

        WebAssembly: no VM / JS version of everything but Instance
        https://bugs.webkit.org/show_bug.cgi?id=177473

        Reviewed by Filip Pizlo, Saam Barati.

        This change entails cleaning up and splitting a bunch of code which we had
        intertwined between C++ classes which represent JS objects, and pure C++
        implementation objects. This specific change goes most of the way towards
        allowing JSC's WebAssembly to work without VM / JS, up to but excluding
        JSWebAssemblyInstance (there's Wasm::Instance, but it's not *the* thing
        yet). Because of this we still have a few FIXME identifying places that need to
        change. A follow-up change will go the rest of the way.

        I went about this change in the simplest way possible: grep the
        JavaScriptCore/wasm directory for "JS[^C_]" as well as "VM" and exclude the /js/
        sub-directory (which contains the JS implementation of WebAssembly).

        None of this change removes the need for a JIT entitlement to be able to use
        WebAssembly. We don't have an interpreter, the process therefore still needs to
        be allowed to JIT to use these pure-C++ APIs.

        Interesting things to note:

          - Remove VM from Plan and associated places. It can just live as a capture in
            the callback lambda if it's needed.
          - Wasm::Memory shouldn't require a VM. It was only used to ask the GC to
            collect. We now instead pass two lambdas at construction time for this
            purpose: one to notify of memory pressure, and the other to ask for
            syncrhonous memory reclamation. This allows whoever creates the memory to
            dictate how to react to both these cases, and for a JS embedding that's to
            call the GC (async or sync, respectively).
          - Move grow logic from JSWebAssemblyMemory to Wasm::Memory::grow. Use Expected
            there, with an enum class for failure types.
          - Exceeding max on memory growth now returns a range error as per spec. This
            is a (very minor) breaking change: it used to throw OOM error. Update the
            corresponding test.
          - When generating the grow_memory opcode, no need to get the VM. Instead,
            reach directly for Wasm::Memory and grow it.
          - JSWebAssemblyMemory::grow can now always throw on failure, because it's only
            ever called from JS (not from grow_memory as before).
          - Wasm::Memory now takes a callback for successful growth. This allows JS
            wrappers to register themselves when growth succeeds without Wasm::Memory
            knowning anything about JS. It'll also allow creating a list of callbacks
            for when we add thread support (we'll want to notify many wrappers, all
            under a lock).
          - Wasm::Memory is now back to being the source of truth about address / size,
            used directly by generated code instead of JSWebAssemblyMemory.
          - Move wasmToJS from the general WasmBinding header to its own header under
            wasm/js. It's only used by wasm/js/JSWebAssemblyCodeBlock.cpp, and uses VM,
            and therefore isn't general WebAssembly.
          - Make Wasm::Context an actual type (just a struct holding a
            JSWebAssemlyInstance for now) instead of an alias for that. Notably this
            doesn't add anything to the Context and doesn't change what actually gets
            passed around in JIT code (fast TLS or registers) because these changes
            potentially impact performance. The entire purpose of this change is to
            allow passing Wasm::Context around without having to know about VM. Since VM
            contains a Wasm::Context the JS embedding is effectively the same, but with
            this setup a non-JS embedding is much better off.
          - Move JSWebAssembly into the JS folder.
          - OMGPlan: use Wasm::CodeBlock directly instead of JSWebAssemblyCodeBlock.
          - wasm->JS stubs are now on the instance's tail as raw pointers, instead of
            being on JSWebAssemblyCodeBlock, and are now called wasm->Embedder
            stubs. The owned reference is still on JSWebAssemblyCodeBlock, and is still
            called wasm->JS stub. This move means that the embedder must, after creating
            a Wasm::CodeBlock, somehow create the stubs to call back into the
            embedder. This removes an indirection in the generated code because
            the B3 IR generator now reaches into the instance instead of
            JSWebAssemblyCodeBlock.
          - Move more CodeBlock things. Compilation completion is now marked by its own
            atomic<bool> flag instead of a nullptr plan: that required using a lock, and
            was causing a deadlock in stack-trace.js because before my changes
            JSWebAssemblyCodeBlock did its own completion checking separately from
            Wasm::CodeBlock, without getting the lock. Now that everything points to
            Wasm::CodeBlock and there's no cached completion marker, the lock was being
            acquired in a sanity-check assertion.
          - Embedder -> Wasm wrappers are now generated through a function that's passed
            in at compilation time, instead of being hard-coded as a JS -> Wasm wrapper.
          - WasmMemory doens't need to know about fault handling thunks. Only the IR
            generator should know, and should make sure that the exception throwing
            thunk is generated if any memory is present (note: with signal handling not
            all of them generate an exception check).
          - Make exception throwing pluggable: instead of having a hard-coded
            JS-specific lambda we now have a regular C++ function being called from JIT
            code when a WebAssembly exception is thrown. This allows any embedder to get
            called as they wish. For now a process can only have a single of these
            functions (i.e. only one embedder per process) because the trap handler is a
            singleton. That can be fixed in in #177475.
          - Create WasmEmbedder.h where all embedder plugging will live.
          - Split up JSWebAssemblyTable into Wasm::Table which is
            refcounted. JSWebAssemblyTable now only contains the JS functions in the
            table, and Wasm::Table is what's used by the JIT code to lookup where to
            call and do the instance check (for context switch). Note that this creates
            an extra allocation for all the instances in Wasm::Table, and in exchange
            removes an indirection in JIT code because the instance used to be obtained
            off of the JS function. Also note that it's the embedder than keeps the
            instances alive, not Wasm::Table (which holds a dumb pointer to the
            instance), because doing otherwise would cause reference cycles.
           - Add WasmInstance. It doesn't do much for now, owns globals.
           - JSWebAssembly instance now doesn't just contain the imported functions as
             JSObjects, it also has the corresponding import's instance and wasm
             entrypoint. This triples the space allocated per instance's imported
             function, but there shouldn't be that many imports. This has two upsides: it
             creates smaller and faster code, and makes is easier to disassociate
             embedder-specific things from embedder-neutral things. The small / faster
             win is in two places: B3 IR generator only needs offsetOfImportFunction for
             the call opcode (when the called index is an import) to know whether the
             import is wasm->wasm or wasm->embedder (this isn't known at compile-time
             because it's dependent on the import object), this is now done by seeing if
             that import function has an associated target instance (only wasm->wasm
             does); the other place is wasmBinding which uses offsetOfImportFunction to
             figure out the wasm->wasm target instance, and then gets
             WebAssemblyFunction::offsetOfWasmEntrypointLoadLocation to do a tail
             call. The disassociation comes because the target instance can be
             Wasm::Instance once we change what the Context is, and
             WasmEntrypointLoadLocation is already embedder-independent. As a next step I
             can move this tail allocation from JSWebAssemblyInstance to Wasm::Instance,
             and leave importFunction in as an opaque pointer which is embedder-specific,
             and in JS will remain WriteBarrier<JSObject>.
           - Rename VMEntryFrame to EntryFrame, and in many places pass a pointer to it
             around instead of VM. This is a first step in allowing entry frames which
             aren't stored on VM, but which are instead stored in an embedder-specific
             location. That change won't really affect JS except through code churn, but
             will allow WebAssembly to use some machinery in a generic manner without
             having a VM.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessGenerationState::emitExplicitExceptionHandler):
        * debugger/Debugger.cpp:
        (JSC::Debugger::stepOutOfFunction):
        (JSC::Debugger::returnEvent):
        (JSC::Debugger::unwindEvent):
        (JSC::Debugger::didExecuteProgram):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compileExceptionHandlers):
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::compileOSRExit):
        (JSC::DFG::OSRExit::compileExit):
        * dfg/DFGThunks.cpp:
        (JSC::DFG::osrEntryThunkGenerator):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::lower):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::wasmAwareLexicalGlobalObject):
        (JSC::CallFrame::callerFrame):
        (JSC::CallFrame::unsafeCallerFrame):
        * interpreter/CallFrame.h:
        (JSC::ExecState::callerFrame const):
        (JSC::ExecState::callerFrameOrEntryFrame const):
        (JSC::ExecState::unsafeCallerFrameOrEntryFrame const):
        * interpreter/FrameTracers.h:
        (JSC::NativeCallFrameTracer::NativeCallFrameTracer):
        (JSC::NativeCallFrameTracerWithRestore::NativeCallFrameTracerWithRestore):
        (JSC::NativeCallFrameTracerWithRestore::~NativeCallFrameTracerWithRestore):
        * interpreter/Interpreter.cpp:
        (JSC::UnwindFunctor::operator() const):
        (JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
        (JSC::Interpreter::unwind):
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::StackVisitor):
        (JSC::StackVisitor::gotoNextFrame):
        (JSC::StackVisitor::readNonInlinedFrame):
        (JSC::StackVisitor::Frame::dump const):
        * interpreter/StackVisitor.h:
        (JSC::StackVisitor::Frame::callerIsEntryFrame const):
        * interpreter/VMEntryRecord.h:
        (JSC::VMEntryRecord::prevTopEntryFrame):
        (JSC::VMEntryRecord::unsafePrevTopEntryFrame):
        (JSC::EntryFrame::vmEntryRecordOffset):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::restoreCalleeSavesFromEntryFrameCalleeSavesBuffer):
        (JSC::AssemblyHelpers::loadWasmContextInstance):
        (JSC::AssemblyHelpers::storeWasmContextInstance):
        (JSC::AssemblyHelpers::loadWasmContextInstanceNeedsMacroScratchRegister):
        (JSC::AssemblyHelpers::storeWasmContextInstanceNeedsMacroScratchRegister):
        (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBufferImpl):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
        (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBuffer):
        (JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToEntryFrameCalleeSavesBuffer):
        * jit/JIT.cpp:
        (JSC::JIT::emitEnterOptimizationCheck):
        (JSC::JIT::privateCompileExceptionHandlers):
        * jit/JITExceptions.cpp:
        (JSC::genericUnwind):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_throw):
        (JSC::JIT::emit_op_catch):
        (JSC::JIT::emitSlow_op_loop_hint):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_throw):
        (JSC::JIT::emit_op_catch):
        * jit/JITOperations.cpp:
        * jit/ThunkGenerators.cpp:
        (JSC::throwExceptionFromCallSlowPathGenerator):
        (JSC::nativeForGenerator):
        * jsc.cpp:
        (functionDumpCallFrame):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntThunks.cpp:
        (JSC::vmEntryRecord):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):
        * runtime/Options.h:
        * runtime/SamplingProfiler.cpp:
        (JSC::FrameWalker::FrameWalker):
        (JSC::FrameWalker::advanceToParentFrame):
        (JSC::SamplingProfiler::processUnverifiedStackTraces):
        * runtime/ThrowScope.cpp:
        (JSC::ThrowScope::~ThrowScope):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::~VM):
        * runtime/VM.h:
        (JSC::VM::topEntryFrameOffset):
        * runtime/VMTraps.cpp:
        (JSC::isSaneFrame):
        (JSC::VMTraps::tryInstallTrapBreakpoints):
        (JSC::VMTraps::invalidateCodeBlocksOnStack):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::restoreWasmContextInstance):
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
        (JSC::Wasm::B3IRGenerator::addGrowMemory):
        (JSC::Wasm::B3IRGenerator::addCurrentMemory):
        (JSC::Wasm::B3IRGenerator::addCall):
        (JSC::Wasm::B3IRGenerator::addCallIndirect):
        (JSC::Wasm::parseAndCompile):
        * wasm/WasmB3IRGenerator.h:
        * wasm/WasmBBQPlan.cpp:
        (JSC::Wasm::BBQPlan::BBQPlan):
        (JSC::Wasm::BBQPlan::compileFunctions):
        (JSC::Wasm::BBQPlan::complete):
        * wasm/WasmBBQPlan.h:
        * wasm/WasmBBQPlanInlines.h:
        (JSC::Wasm::BBQPlan::initializeCallees):
        * wasm/WasmBinding.cpp:
        (JSC::Wasm::wasmToWasm):
        * wasm/WasmBinding.h:
        * wasm/WasmCodeBlock.cpp:
        (JSC::Wasm::CodeBlock::create):
        (JSC::Wasm::CodeBlock::CodeBlock):
        (JSC::Wasm::CodeBlock::compileAsync):
        (JSC::Wasm::CodeBlock::setCompilationFinished):
        * wasm/WasmCodeBlock.h:
        (JSC::Wasm::CodeBlock::offsetOfImportStubs):
        (JSC::Wasm::CodeBlock::allocationSize):
        (JSC::Wasm::CodeBlock::importWasmToEmbedderStub):
        (JSC::Wasm::CodeBlock::offsetOfImportWasmToEmbedderStub):
        (JSC::Wasm::CodeBlock::wasmToJSCallStubForImport):
        (JSC::Wasm::CodeBlock::compilationFinished):
        (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace):
        (JSC::Wasm::CodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace):
        * wasm/WasmContext.cpp:
        (JSC::Wasm::Context::useFastTLS):
        (JSC::Wasm::Context::load const):
        (JSC::Wasm::Context::store):
        * wasm/WasmContext.h:
        * wasm/WasmEmbedder.h: Copied from Source/JavaScriptCore/wasm/WasmContext.h.
        * wasm/WasmFaultSignalHandler.cpp:
        * wasm/WasmFaultSignalHandler.h:
        * wasm/WasmFormat.h:
        * wasm/WasmInstance.cpp: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
        (JSC::Wasm::Instance::Instance):
        (JSC::Wasm::Instance::~Instance):
        (JSC::Wasm::Instance::extraMemoryAllocated const):
        * wasm/WasmInstance.h: Added.
        (JSC::Wasm::Instance::create):
        (JSC::Wasm::Instance::finalizeCreation):
        (JSC::Wasm::Instance::module):
        (JSC::Wasm::Instance::codeBlock):
        (JSC::Wasm::Instance::memory):
        (JSC::Wasm::Instance::table):
        (JSC::Wasm::Instance::loadI32Global const):
        (JSC::Wasm::Instance::loadI64Global const):
        (JSC::Wasm::Instance::loadF32Global const):
        (JSC::Wasm::Instance::loadF64Global const):
        (JSC::Wasm::Instance::setGlobal):
        (JSC::Wasm::Instance::offsetOfCachedStackLimit):
        (JSC::Wasm::Instance::cachedStackLimit const):
        (JSC::Wasm::Instance::setCachedStackLimit):
        * wasm/WasmMemory.cpp:
        (JSC::Wasm::Memory::Memory):
        (JSC::Wasm::Memory::create):
        (JSC::Wasm::Memory::~Memory):
        (JSC::Wasm::Memory::grow):
        * wasm/WasmMemory.h:
        (JSC::Wasm::Memory::offsetOfMemory):
        (JSC::Wasm::Memory::offsetOfSize):
        * wasm/WasmMemoryInformation.cpp:
        (JSC::Wasm::PinnedRegisterInfo::get):
        (JSC::Wasm::PinnedRegisterInfo::PinnedRegisterInfo):
        * wasm/WasmMemoryInformation.h:
        (JSC::Wasm::PinnedRegisterInfo::toSave const):
        * wasm/WasmMemoryMode.cpp: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
        (JSC::Wasm::makeString):
        * wasm/WasmMemoryMode.h: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
        * 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/WasmModuleParser.cpp:
        (JSC::Wasm::ModuleParser::parseTableHelper):
        * wasm/WasmOMGPlan.cpp:
        (JSC::Wasm::OMGPlan::OMGPlan):
        (JSC::Wasm::OMGPlan::runForIndex):
        * wasm/WasmOMGPlan.h:
        * wasm/WasmPageCount.h:
        (JSC::Wasm::PageCount::isValid const):
        * wasm/WasmPlan.cpp:
        (JSC::Wasm::Plan::Plan):
        (JSC::Wasm::Plan::runCompletionTasks):
        (JSC::Wasm::Plan::addCompletionTask):
        (JSC::Wasm::Plan::tryRemoveContextAndCancelIfLast):
        * wasm/WasmPlan.h:
        (JSC::Wasm::Plan::dontFinalize):
        * wasm/WasmSignature.cpp:
        * wasm/WasmSignature.h:
        * wasm/WasmTable.cpp: Added.
        (JSC::Wasm::Table::create):
        (JSC::Wasm::Table::~Table):
        (JSC::Wasm::Table::Table):
        (JSC::Wasm::Table::grow):
        (JSC::Wasm::Table::clearFunction):
        (JSC::Wasm::Table::setFunction):
        * wasm/WasmTable.h: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyTable.h.
        (JSC::Wasm::Table::maximum const):
        (JSC::Wasm::Table::size const):
        (JSC::Wasm::Table::offsetOfSize):
        (JSC::Wasm::Table::offsetOfFunctions):
        (JSC::Wasm::Table::offsetOfInstances):
        (JSC::Wasm::Table::isValidSize):
        * wasm/WasmThunks.cpp:
        (JSC::Wasm::throwExceptionFromWasmThunkGenerator):
        (JSC::Wasm::triggerOMGTierUpThunkGenerator):
        (JSC::Wasm::Thunks::setThrowWasmException):
        (JSC::Wasm::Thunks::throwWasmException):
        * wasm/WasmThunks.h:
        * wasm/WasmWorklist.cpp:
        (JSC::Wasm::Worklist::stopAllPlansForContext):
        * wasm/WasmWorklist.h:
        * wasm/js/JSToWasm.cpp: Added.
        (JSC::Wasm::createJSToWasmWrapper):
        * wasm/js/JSToWasm.h: Copied from Source/JavaScriptCore/wasm/WasmBinding.h.
        * wasm/js/JSWebAssembly.cpp: Renamed from Source/JavaScriptCore/wasm/JSWebAssembly.cpp.
        * wasm/js/JSWebAssembly.h: Renamed from Source/JavaScriptCore/wasm/JSWebAssembly.h.
        * wasm/js/JSWebAssemblyCodeBlock.cpp:
        (JSC::JSWebAssemblyCodeBlock::create):
        (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock):
        * wasm/js/JSWebAssemblyCodeBlock.h:
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
        (JSC::JSWebAssemblyInstance::finishCreation):
        (JSC::JSWebAssemblyInstance::visitChildren):
        (JSC::JSWebAssemblyInstance::finalizeCreation):
        (JSC::JSWebAssemblyInstance::create):
        * wasm/js/JSWebAssemblyInstance.h:
        (JSC::JSWebAssemblyInstance::instance):
        (JSC::JSWebAssemblyInstance::context const):
        (JSC::JSWebAssemblyInstance::table):
        (JSC::JSWebAssemblyInstance::webAssemblyToJSCallee):
        (JSC::JSWebAssemblyInstance::setMemory):
        (JSC::JSWebAssemblyInstance::offsetOfTail):
        (JSC::JSWebAssemblyInstance::importFunctionInfo):
        (JSC::JSWebAssemblyInstance::offsetOfTargetInstance):
        (JSC::JSWebAssemblyInstance::offsetOfWasmEntrypoint):
        (JSC::JSWebAssemblyInstance::offsetOfImportFunction):
        (JSC::JSWebAssemblyInstance::importFunction):
        (JSC::JSWebAssemblyInstance::internalMemory):
        (JSC::JSWebAssemblyInstance::wasmCodeBlock const):
        (JSC::JSWebAssemblyInstance::offsetOfWasmTable):
        (JSC::JSWebAssemblyInstance::offsetOfCallee):
        (JSC::JSWebAssemblyInstance::offsetOfGlobals):
        (JSC::JSWebAssemblyInstance::offsetOfWasmCodeBlock):
        (JSC::JSWebAssemblyInstance::offsetOfWasmMemory):
        (JSC::JSWebAssemblyInstance::cachedStackLimit const):
        (JSC::JSWebAssemblyInstance::setCachedStackLimit):
        (JSC::JSWebAssemblyInstance::wasmMemory):
        (JSC::JSWebAssemblyInstance::wasmModule):
        (JSC::JSWebAssemblyInstance::allocationSize):
        (JSC::JSWebAssemblyInstance::module const):
        * wasm/js/JSWebAssemblyMemory.cpp:
        (JSC::JSWebAssemblyMemory::create):
        (JSC::JSWebAssemblyMemory::adopt):
        (JSC::JSWebAssemblyMemory::JSWebAssemblyMemory):
        (JSC::JSWebAssemblyMemory::grow):
        (JSC::JSWebAssemblyMemory::growSuccessCallback):
        * wasm/js/JSWebAssemblyMemory.h:
        * wasm/js/JSWebAssemblyModule.cpp:
        (JSC::JSWebAssemblyModule::moduleInformation const):
        (JSC::JSWebAssemblyModule::exportSymbolTable const):
        (JSC::JSWebAssemblyModule::signatureIndexFromFunctionIndexSpace const):
        (JSC::JSWebAssemblyModule::callee const):
        (JSC::JSWebAssemblyModule::codeBlock):
        (JSC::JSWebAssemblyModule::module):
        * wasm/js/JSWebAssemblyModule.h:
        * wasm/js/JSWebAssemblyTable.cpp:
        (JSC::JSWebAssemblyTable::create):
        (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
        (JSC::JSWebAssemblyTable::visitChildren):
        (JSC::JSWebAssemblyTable::grow):
        (JSC::JSWebAssemblyTable::getFunction):
        (JSC::JSWebAssemblyTable::clearFunction):
        (JSC::JSWebAssemblyTable::setFunction):
        * wasm/js/JSWebAssemblyTable.h:
        (JSC::JSWebAssemblyTable::isValidSize):
        (JSC::JSWebAssemblyTable::maximum const):
        (JSC::JSWebAssemblyTable::size const):
        (JSC::JSWebAssemblyTable::table):
        * wasm/js/WasmToJS.cpp: Copied from Source/JavaScriptCore/wasm/WasmBinding.cpp.
        (JSC::Wasm::materializeImportJSCell):
        (JSC::Wasm::wasmToJS):
        (JSC::Wasm::wasmToJSException):
        * wasm/js/WasmToJS.h: Copied from Source/JavaScriptCore/wasm/WasmBinding.h.
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction):
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::constructJSWebAssemblyInstance):
        * wasm/js/WebAssemblyMemoryConstructor.cpp:
        (JSC::constructJSWebAssemblyMemory):
        * wasm/js/WebAssemblyMemoryPrototype.cpp:
        (JSC::webAssemblyMemoryProtoFuncGrow):
        * wasm/js/WebAssemblyModuleConstructor.cpp:
        (JSC::constructJSWebAssemblyModule):
        (JSC::WebAssemblyModuleConstructor::createModule):
        * wasm/js/WebAssemblyModuleConstructor.h:
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::link):
        (JSC::WebAssemblyModuleRecord::evaluate):
        * wasm/js/WebAssemblyPrototype.cpp:
        (JSC::webAssemblyCompileFunc):
        (JSC::instantiate):
        (JSC::compileAndInstantiate):
        (JSC::webAssemblyValidateFunc):
        * wasm/js/WebAssemblyTableConstructor.cpp:
        (JSC::constructJSWebAssemblyTable):
        * wasm/js/WebAssemblyWrapperFunction.cpp:
        (JSC::WebAssemblyWrapperFunction::create):

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

        Stringifier::appendStringifiedValue() is missing an exception check.
        https://bugs.webkit.org/show_bug.cgi?id=178386
        <rdar://problem/35027610>

        Reviewed by Saam Barati.

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

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

        REGRESSION(r223691): DFGByteCodeParser.cpp:1483:83: warning: comparison is always false due to limited range of data type [-Wtype-limits]
        https://bugs.webkit.org/show_bug.cgi?id=178543

        Reviewed by Filip Pizlo.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):

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

        re-inline ObjectAllocationProfile::initializeProfile
        https://bugs.webkit.org/show_bug.cgi?id=178532

        Rubber stamped by Michael Saboff.

        I un-inlined this function when implementing poly proto.
        This patch re-inlines it. In my testing, it looks like it
        might be a 0.5% speedometer progression to inline it.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * bytecode/CodeBlock.cpp:
        * bytecode/ObjectAllocationProfile.cpp: Removed.
        * bytecode/ObjectAllocationProfileInlines.h: Copied from Source/JavaScriptCore/bytecode/ObjectAllocationProfile.cpp.
        (JSC::ObjectAllocationProfile::initializeProfile):
        (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount):
        * runtime/FunctionRareData.cpp:

2017-10-19  Michael Saboff  <msaboff@apple.com>

        Test262: RegExp/property-escapes/generated/Emoji_Component.js fails with current RegExp Unicode Properties implementation
        https://bugs.webkit.org/show_bug.cgi?id=178521

        Reviewed by JF Bastien.

        * ucd/emoji-data.txt: Replaced with the Unicode Emoji 5.0 version of the file as that is the most recent
        standard version.  The prior version was the draft 6.0 version.

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

        We should hard code the poly proto offset
        https://bugs.webkit.org/show_bug.cgi?id=178531

        Reviewed by Filip Pizlo.

        This patch embraces that the poly proto offset is always zero. It's already
        the case that we would always get the inline offset zero for poly proto just
        by construction. This just hardcodes this assumption throughout the codebase.
        This appears to be a 1% speedometer progression in my testing.
        
        The downside of this patch is that it may require changing how we do
        things when we implement poly proto when inheriting from builtin
        types. I think we can face this problem when we decide to implement
        that.

        * bytecode/AccessCase.cpp:
        (JSC::AccessCase::generateWithGuard):
        * dfg/DFGOperations.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
        (JSC::DFG::SpeculativeJIT::compileGetPrototypeOf):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileGetPrototypeOf):
        (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_instanceof):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_instanceof):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/JSObject.cpp:
        (JSC::JSObject::setPrototypeDirect):
        * runtime/JSObject.h:
        (JSC::JSObject::locationForOffset const):
        (JSC::JSObject::locationForOffset):
        (JSC::JSObject::getDirect const):
        * runtime/PropertyOffset.h:
        * runtime/Structure.cpp:
        (JSC::Structure::create):
        (JSC::Structure::dump const):
        * runtime/Structure.h:
        * runtime/StructureInlines.h:
        (JSC::Structure::storedPrototype const):
        (JSC::Structure::storedPrototypeObject const):

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

        Turn various poly proto RELEASE_ASSERTs into ASSERTs because they're on the hot path in speedometer
        https://bugs.webkit.org/show_bug.cgi?id=178529

        Reviewed by Mark Lam.

        * runtime/Structure.h:
        * runtime/StructureInlines.h:
        (JSC::Structure::storedPrototypeObject const):
        (JSC::Structure::storedPrototypeStructure const):
        (JSC::Structure::storedPrototype const):
        (JSC::Structure::prototypeForLookup const):
        (JSC::Structure::prototypeChain const):

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

        Turn poly proto back on by default and remove the option
        https://bugs.webkit.org/show_bug.cgi?id=178525

        Reviewed by Mark Lam.

        I added this option because I thought it'd speed speedometer up because the
        original poly proto patch slowed speedometer down. It turns out that
        allocating poly proto objects is not what slows speedometer down. It's
        other code I added in the runtime that needs to be poly proto aware. I'll
        be addressing these in follow up patches.

        * runtime/Options.h:
        * runtime/StructureInlines.h:
        (JSC::Structure::shouldConvertToPolyProto):

2017-10-19  Robin Morisset  <rmorisset@apple.com>

        Turn recursive tail calls into loops
        https://bugs.webkit.org/show_bug.cgi?id=176601

        Reviewed by Saam Barati.

        We want to turn recursive tail calls into loops early in the pipeline, so that the loops can then be optimized.
        One difficulty is that we need to split the entry block of the function we are jumping to in order to have somewhere to jump to.
        Worse: it is not necessarily the first block of the codeBlock, because of inlining! So we must do the splitting in the DFGByteCodeParser, at the same time as inlining.
        We do this part through modifying the computation of the jump targets.
        Importantly, we only do this splitting for functions that have tail calls.
        It is the only case where the optimisation is sound, and doing the splitting unconditionnaly destroys performance on Octane/raytrace.

        We must then do the actual transformation also in DFGByteCodeParser, to avoid code motion moving code out of the body of what will become a loop.
        The transformation is entirely contained in handleRecursiveTailCall, which is hooked to the inlining machinery.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::hasTailCalls const):
        * bytecode/PreciseJumpTargets.cpp:
        (JSC::getJumpTargetsForBytecodeOffset):
        (JSC::computePreciseJumpTargetsInternal):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::hasTailCalls const):
        (JSC::UnlinkedCodeBlock::setHasTailCalls):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitEnter):
        (JSC::BytecodeGenerator::emitCallInTailPosition):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::allocateTargetableBlock):
        (JSC::DFG::ByteCodeParser::makeBlockTargetable):
        (JSC::DFG::ByteCodeParser::handleCall):
        (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::parse):

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

        RegExpObject::defineOwnProperty() does not need to compare values if no descriptor value is specified.
        https://bugs.webkit.org/show_bug.cgi?id=177600
        <rdar://problem/34710985>

        Reviewed by Saam Barati.

        According to http://www.ecma-international.org/ecma-262/8.0/#sec-validateandapplypropertydescriptor,
        section 9.1.6.3-7.a.ii, we should only check if the value is the same if the
        descriptor value is present.

        * runtime/RegExpObject.cpp:
        (JSC::RegExpObject::defineOwnProperty):

2017-10-18  Keith Miller  <keith_miller@apple.com>

        Setup WebCore build to start using unified sources.
        https://bugs.webkit.org/show_bug.cgi?id=178362

        Reviewed by Tim Horton.

        Change comments in source list files. Also, pass explicit names for build files.

        * CMakeLists.txt:
        * PlatformGTK.cmake:
        * PlatformMac.cmake:
        * Sources.txt:
        * SourcesGTK.txt:
        * SourcesMac.txt:

2017-10-18  Commit Queue  <commit-queue@webkit.org>

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

        This protocol change broke some internal builds (Requested by
        brrian__ on #webkit).

        Reverted changeset:

        "Web Inspector: provide a way to enable/disable event
        listeners"
        https://bugs.webkit.org/show_bug.cgi?id=177451
        https://trac.webkit.org/changeset/223321

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

        The compiler should always register a structure when it adds its transitionWatchPointSet.
        https://bugs.webkit.org/show_bug.cgi?id=178420
        <rdar://problem/34814024>

        Reviewed by Saam Barati and Filip Pizlo.

        Instead of invoking addLazily() to add a structure's transitionWatchpointSet, we
        now invoke Graph::registerAndWatchStructureTransition() on the structure.
        registerAndWatchStructureTransition() both registers the structure and add its
        transitionWatchpointSet to the plan desired watchpoints.

        Graph::registerAndWatchStructureTransition() is based on Graph::registerStructure()
        except registerAndWatchStructureTransition() adds the structure's
        transitionWatchpointSet unconditionally.

        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::refine const):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):

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

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
        - The second set of addLazily()s is redundant.  This set is executed only when
          prototypeChainIsSane is true, and prototypeChainIsSane can only be true if and
          only if we've executed the if statement above it.  That preceding if statement
          already registerAndWatchStructureTransition() the same 2 structures.  Hence,
          this second set can be deleted.

        * dfg/DFGWatchpointCollectionPhase.cpp:
        (JSC::DFG::WatchpointCollectionPhase::addLazily):
        - Deleted an unused function.

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

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

        [JSC] Remove unused private name structure
        https://bugs.webkit.org/show_bug.cgi?id=178436

        Reviewed by Sam Weinig.

        It is no longer used. This patch just removes it.

        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::numberObjectStructure const):
        (JSC::JSGlobalObject::privateNameStructure const): Deleted.

2017-10-18  Ryosuke Niwa  <rniwa@webkit.org>

        Fix macOS and iOS builds after r223594.

        * JavaScriptCore.xcodeproj/project.pbxproj:

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

        [JSC] __proto__ getter should be fast
        https://bugs.webkit.org/show_bug.cgi?id=178067

        Reviewed by Saam Barati.

        In our ES6 class implementation, we access __proto__ field to retrieve super constructor.
        Currently, it is handled as an usual getter call to a generic function. And DFG just emits
        Call node for this. It is inefficient since typically we know the `prototype` of the given
        object when accessing `object.__proto__` since we emit CheckStructure for this `object`.
        If Structure has mono proto, we can immediately fold it to constant value. If it is poly proto,
        we can still change this to efficient access to poly proto slot.

        This patch implements GetPrototypeOf DFG node. This node efficiently accesses to prototype of
        the given object. And in AI and ByteCodeParser phase, we attempt to fold it to constant.
        ByteCodeParser's folding is a bit important since we have `callee.__proto__` code to get super
        constructor. If we can change this to constant, we can reify CallLinkInfo with this constant.
        This paves the way to optimizing ArrayConstructor super calls[1], which is particularly important
        for ARES-6 ML.

        And we also optimize Reflect.getPrototypeOf and Object.getPrototypeOf with this GetPrototypeOf node.

        Currently, __proto__ access for poly proto object is not handled well in IC. But we add code handling
        poly proto in GetPrototypeOf since Reflect.getPrototypeOf and Object.getPrototypeOf can use it.
        Once IC starts handling poly proto & intrinsic getter well, this code will be used for that too.

        This patch improves SixSpeed super.es6 by 3.42x.

                                 baseline                  patched

        super.es6           123.6666+-3.9917     ^     36.1684+-1.0351        ^ definitely 3.4192x faster

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

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        (JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
        (JSC::DFG::ByteCodeParser::handleGetById):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::fixupGetPrototypeOf):
        * dfg/DFGHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGHeapLocation.h:
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasHeapPrediction):
        (JSC::DFG::Node::shouldSpeculateFunction):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::speculateFunction):
        (JSC::DFG::SpeculativeJIT::speculateFinalObject):
        (JSC::DFG::SpeculativeJIT::compileGetPrototypeOf):
        * 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::compileGetPrototypeOf):
        (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
        * jit/IntrinsicEmitter.cpp:
        (JSC::IntrinsicGetterAccessCase::canEmitIntrinsicGetter):
        (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
        * jit/JITOperations.h:
        * runtime/Intrinsic.cpp:
        (JSC::intrinsicName):
        * runtime/Intrinsic.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::booleanPrototype const):
        (JSC::JSGlobalObject::numberPrototype const):
        (JSC::JSGlobalObject::booleanObjectStructure const):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncProtoGetter):
        * runtime/JSGlobalObjectFunctions.h:
        * runtime/ObjectConstructor.cpp:
        * runtime/ReflectObject.cpp:

2017-10-17  Ryan Haddad  <ryanhaddad@apple.com>

        Unreviewed, rolling out r223523.

        A test for this change is failing on debug JSC bots.

        Reverted changeset:

        "[JSC] __proto__ getter should be fast"
        https://bugs.webkit.org/show_bug.cgi?id=178067
        https://trac.webkit.org/changeset/223523

2017-10-17  Youenn Fablet  <youenn@apple.com>

        Add preliminary support for fetch event
        https://bugs.webkit.org/show_bug.cgi?id=178171

        Reviewed by Chris Dumez.

        Adding events

        * runtime/JSPromise.h:

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

        [JSC] __proto__ getter should be fast
        https://bugs.webkit.org/show_bug.cgi?id=178067

        Reviewed by Saam Barati.

        In our ES6 class implementation, we access __proto__ field to retrieve super constructor.
        Currently, it is handled as an usual getter call to a generic function. And DFG just emits
        Call node for this. It is inefficient since typically we know the `prototype` of the given
        object when accessing `object.__proto__` since we emit CheckStructure for this `object`.
        If Structure has mono proto, we can immediately fold it to constant value. If it is poly proto,
        we can still change this to efficient access to poly proto slot.

        This patch implements GetPrototypeOf DFG node. This node efficiently accesses to prototype of
        the given object. And in AI and ByteCodeParser phase, we attempt to fold it to constant.
        ByteCodeParser's folding is a bit important since we have `callee.__proto__` code to get super
        constructor. If we can change this to constant, we can reify CallLinkInfo with this constant.
        This paves the way to optimizing ArrayConstructor super calls[1], which is particularly important
        for ARES-6 ML.

        And we also optimize Reflect.getPrototypeOf and Object.getPrototypeOf with this GetPrototypeOf node.

        Currently, __proto__ access for poly proto object is not handled well in IC. But we add code handling
        poly proto in GetPrototypeOf since Reflect.getPrototypeOf and Object.getPrototypeOf can use it.
        Once IC starts handling poly proto & intrinsic getter well, this code will be used for that too.

        This patch improves SixSpeed super.es6 by 3.42x.

                                 baseline                  patched

        super.es6           123.6666+-3.9917     ^     36.1684+-1.0351        ^ definitely 3.4192x faster

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

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        (JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
        (JSC::DFG::ByteCodeParser::handleGetById):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::fixupGetPrototypeOf):
        * dfg/DFGHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGHeapLocation.h:
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasHeapPrediction):
        (JSC::DFG::Node::shouldSpeculateFunction):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::speculateFunction):
        (JSC::DFG::SpeculativeJIT::speculateFinalObject):
        (JSC::DFG::SpeculativeJIT::compileGetPrototypeOf):
        * 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::compileGetPrototypeOf):
        (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
        * jit/IntrinsicEmitter.cpp:
        (JSC::IntrinsicGetterAccessCase::canEmitIntrinsicGetter):
        (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
        * runtime/Intrinsic.cpp:
        (JSC::intrinsicName):
        * runtime/Intrinsic.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncProtoGetter):
        * runtime/JSGlobalObjectFunctions.h:
        * runtime/ObjectConstructor.cpp:
        * runtime/ReflectObject.cpp:

2017-10-17  Keith Miller  <keith_miller@apple.com>

        Change WebCore sources to work with unified source builds
        https://bugs.webkit.org/show_bug.cgi?id=178229

        Rubber stamped by Tim Horton.

        * Configurations/FeatureDefines.xcconfig:

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

        Make some asserts into release asserts
        https://bugs.webkit.org/show_bug.cgi?id=178324

        Reviewed by Saam Barati.
        
        These asserts are not on perf critical paths, so they might as well be release asserts.

        * runtime/DataView.h:
        (JSC::DataView::get):
        (JSC::DataView::set):

2017-10-16  JF Bastien  <jfbastien@apple.com>

        JSRunLoopTimer: reduce likely race when used improperly
        https://bugs.webkit.org/show_bug.cgi?id=178298
        <rdar://problem/32899816>

        Reviewed by Saam Barati.

        If an API user sets a timer on JSRunLoopTimer, and then racily
        destroys the JSRunLoopTimer while the timer is firing then it's
        possible for timerDidFire to cause a use-after-free and / or crash
        because e.g. m_apiLock becomes a nullptr while timerDidFire is
        executing. That results from an invalid use of JSRunLoopTimer, but
        we should try to be more resilient for that type of misuse because
        it's not necessarily easy to catch by inspection.

        With this change the only remaining race is if the timer fires,
        and then only timerDidFire's prologue executes, but not the load
        of the m_apiLock pointer from `this`. It's a much smaller race.

        Separately, I'll reach out to API users who are seemingly misusing
        the API.

        * runtime/JSRunLoopTimer.cpp:
        (JSC::JSRunLoopTimer::timerDidFire): put m_apiLock on the stack,
        and checks for nullptr. This prevents loading it twice off of
        `this` and turns a nullptr deref into "just" a use-after-free.
        (JSC::JSRunLoopTimer::~JSRunLoopTimer): acquire m_apiLock before
        calling m_vm->unregisterRunLoopTimer(this), which in turn does
        CFRunLoopRemoveTimer / CFRunLoopTimerInvalidate. This prevents
        timerDidFire from doing much while the timers are un-registered.
        ~JSRunLoopTimer also needs to set m_apiLock to nullptr before
        releasing the lock, so it needs its own local copy.

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

        [JSC] Perform module specifier validation at parsing time
        https://bugs.webkit.org/show_bug.cgi?id=178256

        Reviewed by Darin Adler.

        This patch make module loader's `resolve` operation synchronous. And we validate
        module's requested module names when instantiating the module instead of satisfying
        module's dependencies. This change is not observable to users. But this is precise
        to the spec and this optimizes & simplifies the current module loader a bit by
        reducing object allocations.

        Previously, we have an object called pair in the module loader. This is pair of
        module's name and module's record. And we use it to link one module to dependent
        modules. Now, it is replaced with module's registry entry.

        We also change our loader functions to take a registry entry instead of a module key.
        Previous design is due to the consideration that these APIs may be exposed to users
        in whatwg/loader spec. However, this won't happen. This change removes unnecessary
        repeatedly hash map lookups.

        * builtins/ModuleLoaderPrototype.js:
        (globalPrivate.newRegistryEntry):
        (requestFetch):
        (requestInstantiate):
        (requestSatisfy):
        (link):
        (moduleEvaluation):
        (loadModule):
        * jsc.cpp:
        (GlobalObject::moduleLoaderResolve):
        * runtime/AbstractModuleRecord.cpp:
        (JSC::AbstractModuleRecord::finishCreation):
        (JSC::AbstractModuleRecord::hostResolveImportedModule):
        * runtime/JSGlobalObject.h:
        * runtime/JSModuleLoader.cpp:
        (JSC::JSModuleLoader::resolveSync):
        (JSC::JSModuleLoader::resolve):
        * runtime/JSModuleLoader.h:
        * runtime/ModuleLoaderPrototype.cpp:
        (JSC::moduleLoaderPrototypeResolveSync):

2017-10-14  Devin Rousso  <webkit@devinrousso.com>

        Web Inspector: provide a way to enable/disable event listeners
        https://bugs.webkit.org/show_bug.cgi?id=177451

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/DOM.json:
        Add `setEventListenerDisabled` command that enables/disables a specific event listener
        during event dispatch. When a disabled event listener is fired, the listener's callback will
        not be called.

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

        Reland "Add Above/Below comparisons for UInt32 patterns"
        https://bugs.webkit.org/show_bug.cgi?id=177281

        Reviewed by Saam Barati.

        We reland this patch without DFGStrengthReduction change to see what causes
        regression in the iOS bot.

        Sometimes, we would like to have UInt32 operations in JS. While VM does
        not support UInt32 nicely, VM supports efficient Int32 operations. As long
        as signedness does not matter, we can just perform Int32 operations instead
        and recognize its bit pattern as UInt32.

        But of course, some operations respect signedness. The most frequently
        used one is comparison. Octane/zlib performs UInt32 comparison by performing
        `val >>> 0`. It emits op_urshift and op_unsigned. op_urshift produces
        UInt32 in Int32 form. And op_unsigned will generate Double value if
        the generated Int32 is < 0 (which should be UInt32).

        There is a chance for optimization. The given code pattern is the following.

            op_unsigned(op_urshift(@1)) lessThan:< op_unsigned(op_urshift(@2))

        This can be converted to the following.

            op_urshift(@1) below:< op_urshift(@2)

        The above conversion is nice since

        1. We can avoid op_unsigned. This could be unsignedness check in DFG. Since
        this check depends on the value of Int32, dropping this check is not as easy as
        removing Int32 edge filters.

        2. We can perform unsigned comparison in Int32 form. We do not need to convert
        them to DoubleRep.

        Since the above comparison exists in Octane/zlib's *super* hot path, dropping
        op_unsigned offers huge win.

        At first, my patch attempts to convert the above thing in DFG pipeline.
        However it poses several problems.

        1. MovHint is not well removed. It makes UInt32ToNumber (which is for op_unsigned) live.
        2. UInt32ToNumber could cause an OSR exit. So if we have the following nodes,

            2: UInt32ToNumber(@0)
            3: MovHint(@2, xxx)
            4: UInt32ToNumber(@1)
            5: MovHint(@1, xxx)

        we could drop @5's MovHint. But @3 is difficult since @4 can exit.

        So, instead, we start introducing a simple optimization in the bytecode compiler.
        It performs pattern matching for op_urshift and comparison to drop op_unsigned.
        We adds op_below and op_above families to bytecodes. They only accept Int32 and
        perform unsigned comparison.

        This offers 4% performance improvement in Octane/zlib.

                                    baseline                  patched

        zlib           x2     431.07483+-16.28434       414.33407+-9.38375         might be 1.0404x faster

        * bytecode/BytecodeDumper.cpp:
        (JSC::BytecodeDumper<Block>::printCompareJump):
        (JSC::BytecodeDumper<Block>::dumpBytecode):
        * bytecode/BytecodeDumper.h:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/Opcode.h:
        (JSC::isBranch):
        * bytecode/PreciseJumpTargetsInlines.h:
        (JSC::extractStoredJumpTargetsForBytecodeOffset):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitJumpIfTrue):
        (JSC::BytecodeGenerator::emitJumpIfFalse):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BinaryOpNode::emitBytecode):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGIntegerRangeOptimizationPhase.cpp:
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCompareUnsigned):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGValidate.cpp:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareBelow):
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareBelowEq):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_below):
        (JSC::JIT::emit_op_beloweq):
        (JSC::JIT::emit_op_jbelow):
        (JSC::JIT::emit_op_jbeloweq):
        (JSC::JIT::emit_compareUnsignedAndJump):
        (JSC::JIT::emit_compareUnsigned):
        * jit/JITArithmetic32_64.cpp:
        (JSC::JIT::emit_compareUnsignedAndJump):
        (JSC::JIT::emit_compareUnsigned):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * parser/Nodes.h:
        (JSC::ExpressionNode::isBinaryOpNode const):

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

        WebAssembly: Wasm functions should have either JSFunctionType or TypeOfShouldCallGetCallData
        https://bugs.webkit.org/show_bug.cgi?id=178210

        Reviewed by Saam Barati.

        In Wasm, we have two JS functions exposed to users: WebAssemblyFunction and WebAssemblyWrapperFunction.
        The former is an exported wasm function and the latter is an imported & exported function. Since they
        have [[Call]], they should be categorized into "function" in typeof operation.

        However, these functions do not implement our function protocol correctly. They inherit JSFunction.
        But JSType of WebAssemblyFunction is WebAssemblyFunctionType, and one of WebAssemblyWrapperFunction is
        ObjectType. Since both do not have TypeOfShouldCallGetCallData, they return "object" when performing
        typeof operation.

        In this patch, we address the above issue by the following 2 fixes.

        1. We add TypeOfShouldCallGetCallData to WebAssemblyFunction. This is the same way how we implement
        InternalFunction. Since WebAssemblyFunction requires WebAssemblyFunctionType for fast checking in Wasm
        implementation, we cannot make this JSFunctionType.

        2. On the other hand, WebAssemblyWrapperFunction does not require a specific JSType. So this patch
        changes JSType of WebAssemblyWrapperFunction to JSFunctionType. JSFunctionType can be usable for derived
        classes of JSFunction (e.g. JSCustomGetterSetterFunction).

        * wasm/js/WebAssemblyFunction.h:
        (JSC::WebAssemblyFunction::signatureIndex const): Deleted.
        (JSC::WebAssemblyFunction::wasmEntrypointLoadLocation const): Deleted.
        (JSC::WebAssemblyFunction::callableFunction const): Deleted.
        (JSC::WebAssemblyFunction::jsEntrypoint): Deleted.
        (JSC::WebAssemblyFunction::offsetOfWasmEntrypointLoadLocation): Deleted.
        * wasm/js/WebAssemblyWrapperFunction.cpp:
        (JSC::WebAssemblyWrapperFunction::createStructure):
        * wasm/js/WebAssemblyWrapperFunction.h:
        (JSC::WebAssemblyWrapperFunction::signatureIndex const): Deleted.
        (JSC::WebAssemblyWrapperFunction::wasmEntrypointLoadLocation const): Deleted.
        (JSC::WebAssemblyWrapperFunction::callableFunction const): Deleted.
        (JSC::WebAssemblyWrapperFunction::function): Deleted.

2017-10-12  Per Arne Vollan  <pvollan@apple.com>

        [Win64] JSC compile error.
        https://bugs.webkit.org/show_bug.cgi?id=178213

        Reviewed by Alex Christensen.

        Add static cast from int64 to uintptr_t.

        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::executeOSRExit):

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

        Enable gigacage on iOS
        https://bugs.webkit.org/show_bug.cgi?id=177586

        Reviewed by JF Bastien.

        The hardest part of enabling Gigacage on iOS is that it requires loading global variables while
        executing JS, so the LLInt needs to know how to load from global variables on all platforms that
        have Gigacage. So, this teaches ARM64 how to load from global variables.
        
        Also, this makes the code handle disabling the gigacage a bit better.

        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::caged):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::cage):
        (JSC::AssemblyHelpers::cageConditionally):
        * offlineasm/arm64.rb:
        * offlineasm/asm.rb:
        * offlineasm/instructions.rb:

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

        Remove out-parameter variants of copyToVector
        https://bugs.webkit.org/show_bug.cgi?id=178155

        Reviewed by Tim Horton.

        * inspector/ScriptDebugServer.cpp:
        (Inspector::ScriptDebugServer::dispatchBreakpointActionLog):
        (Inspector::ScriptDebugServer::dispatchBreakpointActionSound):
        (Inspector::ScriptDebugServer::dispatchBreakpointActionProbe):
        (Inspector::ScriptDebugServer::dispatchDidParseSource):
        (Inspector::ScriptDebugServer::dispatchFailedToParseSource):
        (Inspector::ScriptDebugServer::dispatchFunctionToListeners):
            
            Replace out-parameter based copyToVector, with one that returns a Vector.

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

        Support integrity="" on module scripts
        https://bugs.webkit.org/show_bug.cgi?id=177959

        Reviewed by Sam Weinig.

        This patch adds Subresource Integrity check for module scripts. Currently,
        only top-level module can be verified with integrity parameter since there
        is no way to perform integrity check onto the imported modules.

        In JSC side, we add `parameters` to the entry point of the module loader
        pipeline. This is fetching parameters and used when fetching modules.

        We separately pass this parameters to the pipeline along with the script fetcher.
        The script fetcher is only one for module graph since this is the initiator of
        this module graph loading. On the other hand, this parameters is for each
        module fetching. While setting "integrity" parameters to this script fetcher is
        sufficient to pass parameters to top-level-module's fetching, it is not enough
        for the future extension.

        In the future, we will investigate a way to pass parameters to each non-top-level
        module. At that time, this `parameters` should be per-module. This is because
        "integrity" value should be different for each module. For example, we will accept
        some form of syntax to add parameters to `import`. Some proposed syntax is like
        https://discourse.wicg.io/t/specifying-nonce-or-integrity-when-importing-modules/1861

        import "./xxx.js" integrity "xxxxxxx"

        In this case, this `parameters` will be passed to "./xxx.js" module fetching. This
        `parameters` should be different from the one of top-level-module's one. That's why
        we need per-module `parameters` and why this patch adds `parameters` to the module pipeline.

        On the other hand, we also want to keep script fetcher. This `per-module-graph` thing
        is important to offer module-graph-wide information. For example, import.meta would
        have `import.meta.scriptElement`, which is the script element fetching the module graph
        including this. So, we keep the both, script fetcher and parameters.
        https://github.com/tc39/proposal-import-meta

        This parameters will be finally used by pipeline's fetch hook, and WebCore side
        can use this parameters to fetch modules.

        We also further clean up the module pipeline by dropping unnecessary features.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * builtins/ModuleLoaderPrototype.js:
        (requestFetch):
        (requestInstantiate):
        (requestSatisfy):
        (loadModule):
        (loadAndEvaluateModule):
        This loadAndEvaluateModule should be implemented by just calling loadModule and
        linkAndEvaluateModule. We can drop requestReady and requestLink.

        (requestLink): Deleted.
        (requestImportModule): Deleted.
        * jsc.cpp:
        (GlobalObject::moduleLoaderImportModule):
        (GlobalObject::moduleLoaderFetch):
        import and fetch hook takes parameters. Currently, we always pass `undefined` for
        import hook. When dynamic `import()` is extended to accept additional parameters
        like integrity, this parameters will be replaced with the actual value.

        (functionLoadModule):
        (runWithOptions):
        * runtime/Completion.cpp:
        (JSC::loadAndEvaluateModule):
        (JSC::loadModule):
        (JSC::importModule):
        * runtime/Completion.h:
        * runtime/JSGlobalObject.h:
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncImportModule):
        * runtime/JSModuleLoader.cpp:
        (JSC::JSModuleLoader::loadAndEvaluateModule):
        (JSC::JSModuleLoader::loadModule):
        (JSC::JSModuleLoader::requestImportModule):
        (JSC::JSModuleLoader::importModule):
        (JSC::JSModuleLoader::fetch):
        * runtime/JSModuleLoader.h:
        * runtime/JSScriptFetchParameters.cpp: Added.
        (JSC::JSScriptFetchParameters::destroy):
        * runtime/JSScriptFetchParameters.h: Added.
        (JSC::JSScriptFetchParameters::createStructure):
        (JSC::JSScriptFetchParameters::create):
        (JSC::JSScriptFetchParameters::parameters const):
        (JSC::JSScriptFetchParameters::JSScriptFetchParameters):
        Add ScriptFetchParameters' JSCell wrapper, JSScriptFetchParameters.
        It is used in the module pipeline.

        * runtime/JSType.h:
        * runtime/ModuleLoaderPrototype.cpp:
        (JSC::moduleLoaderPrototypeFetch):
        * runtime/ScriptFetchParameters.h: Added.
        (JSC::ScriptFetchParameters::~ScriptFetchParameters):
        Add ScriptFetchParameters. We can define our own custom ScriptFetchParameters
        by inheriting this class. WebCore creates ModuleFetchParameters by inheriting
        this.

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

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

        import.meta should not be assignable
        https://bugs.webkit.org/show_bug.cgi?id=178202

        Reviewed by Saam Barati.

        `import.meta` cannot be used for LHS. This patch adds MetaPropertyNode
        and make NewTargetNode and ImportMetaNode as derived classes of MetaPropertyNode.
        We change the parser not to allow assignments for MetaPropertyNode.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::ImportMetaNode::emitBytecode):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createImportMetaExpr):
        (JSC::ASTBuilder::isMetaProperty):
        (JSC::ASTBuilder::isImportMeta):
        * parser/NodeConstructors.h:
        (JSC::MetaPropertyNode::MetaPropertyNode):
        (JSC::NewTargetNode::NewTargetNode):
        (JSC::ImportMetaNode::ImportMetaNode):
        * parser/Nodes.h:
        (JSC::ExpressionNode::isMetaProperty const):
        (JSC::ExpressionNode::isImportMeta const):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::metaPropertyName):
        (JSC::Parser<LexerType>::parseAssignmentExpression):
        (JSC::Parser<LexerType>::parseMemberExpression):
        (JSC::Parser<LexerType>::parseUnaryExpression):
        * parser/Parser.h:
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createImportMetaExpr):
        (JSC::SyntaxChecker::isMetaProperty):
        (JSC::SyntaxChecker::isImportMeta):

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

        Runtime disable poly proto because it may be a 3-4% Speedometer regression
        https://bugs.webkit.org/show_bug.cgi?id=178192

        Reviewed by JF Bastien.

        * runtime/Options.h:
        * runtime/StructureInlines.h:
        (JSC::Structure::shouldConvertToPolyProto):

2017-10-11  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r223113 and r223121.
        https://bugs.webkit.org/show_bug.cgi?id=178182

        Reintroduced 20% regression on Kraken (Requested by rniwa on
        #webkit).

        Reverted changesets:

        "Enable gigacage on iOS"
        https://bugs.webkit.org/show_bug.cgi?id=177586
        https://trac.webkit.org/changeset/223113

        "Use one virtual allocation for all gigacages and their
        runways"
        https://bugs.webkit.org/show_bug.cgi?id=178050
        https://trac.webkit.org/changeset/223121

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

        Update JavaScriptCore/ucd/CaseFolding.txt to Unicode database 10.0
        https://bugs.webkit.org/show_bug.cgi?id=178106

        Reviewed by Keith Miller.

        * ucd/CaseFolding.txt:

2017-10-11  Caio Lima  <ticaiolima@gmail.com>

        Object properties are undefined in super.call() but not in this.call()
        https://bugs.webkit.org/show_bug.cgi?id=177230

        Reviewed by Saam Barati.

        Bytecode generation for "super.call(...)" or "super.apply(...)"
        shouldn't be considered as CallFunctionCallDotNode or
        ApplyFunctionCallDotNode because they should be considered as common
        super property access as any other function. According to spec[1],
        "super" is not refering to parent constructor.

        [1] - https://tc39.github.io/ecma262/#sec-super-keyword-runtime-semantics-evaluation

        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::makeFunctionCallNode):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseMemberExpression):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::makeFunctionCallNode):

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

        [JSC] Drop Instantiate hook in ES6 module loader
        https://bugs.webkit.org/show_bug.cgi?id=178162

        Reviewed by Sam Weinig.

        This patch is a part of patch series for module loader refactoring to adopt
        integrity="" parameters and introduce new whatwg module import mechanism.

        In this patch, we drop instantiate hook in module loader. This hook is originally
        introduced because it is defined in whatwg/loader spec. But this hook is not
        used in our implementation, and this hook won't be used since (1) whatwg/loader
        spec is abandoned, and (2) this type of hooks should be done in Service Workers.

        In addition, this patch applies some cleaning up of our module loader JS code
        to simplify things. This change paves the way to more efficient loader implementation
        with great flexibility to adopt integrity="" parameters.

        * builtins/ModuleLoaderPrototype.js:
        (requestInstantiate):
        (provideFetch):
        provide is changed to provideFetch since we only used this function with Fetch stage parameter.

        (fulfillInstantiate): Deleted.
        (commitInstantiated): Deleted.
        (instantiation): Deleted.
        They are merged into requestInstantiate code. This is simpler.

        (provide): Deleted.
        * jsc.cpp:
        * runtime/Completion.cpp:
        (JSC::loadAndEvaluateModule):
        (JSC::loadModule):
        * runtime/JSGlobalObject.cpp:
        * runtime/JSGlobalObject.h:
        * runtime/JSModuleLoader.cpp:
        (JSC::JSModuleLoader::provideFetch):
        (JSC::JSModuleLoader::provide): Deleted.
        Changed to provideFetch.

        (JSC::JSModuleLoader::instantiate): Deleted.
        Drop this hook.

        * runtime/JSModuleLoader.h:
        * runtime/ModuleLoaderPrototype.cpp:
        (JSC::moduleLoaderPrototypeInstantiate): Deleted.
        Drop this hook.

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

        Prototype structure transition should be a deferred transition
        https://bugs.webkit.org/show_bug.cgi?id=177734

        Reviewed by Keith Miller.

        Absence ObjectPropertyConditions work by verifying both that the Structure 
        does not have a particular property and that its prototype has
        remained constant. However, the prototype transition was firing
        the transition watchpoint before setting the object's structure.
        This meant that isValid for Absence would never return false because
        the prototype changed. Clearly this is wrong. The reason this didn't
        break OPCs in general is that we'd also check if we could still watch
        the OPC. In this case, we can't still watch it because we're inspecting
        a structure with an invalidated transition watchpoint. To fix
        this weird quirk of the code, I'm making it so that doing a prototype
        transition uses the DeferredStructureTransitionWatchpointFire machinery.
        
        This patch also fixes some dead code that I left in regarding
        poly proto in OPC.

        * bytecode/PropertyCondition.cpp:
        (JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint const):
        * runtime/JSObject.cpp:
        (JSC::JSObject::setPrototypeDirect):
        * runtime/Structure.cpp:
        (JSC::Structure::changePrototypeTransition):
        * runtime/Structure.h:

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

        Avoid allocating useless landingBlocks in DFGByteCodeParser::handleInlining()
        https://bugs.webkit.org/show_bug.cgi?id=177926

        Reviewed by Saam Barati.

        When doing polyvariant inlining, there used to be a landing block for each callee, each of which was then linked to a continuation block.
        With this change, we allocate the continuation block first, and pass it to the inlining routine so that op_ret in the callee link directly to it.
        The only subtlety is that when inlining an intrinsic we must do the jump by hand, and also remember to call processSetLocalQueue with nextOffset before it.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::inlineCall):
        (JSC::DFG::ByteCodeParser::attemptToInlineCall):
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        (JSC::DFG::ByteCodeParser::parse):

2017-10-10  Guillaume Emont  <guijemont@igalia.com>

        Fix compilation when MASM_PROBE (and therefore DFG) are disabled
        https://bugs.webkit.org/show_bug.cgi?id=178134

        Reviewed by Saam Barati.

        * bytecode/CodeBlock.cpp:
        * bytecode/CodeBlock.h:
        Disable some code when building without DFG_JIT.

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

        Replace copyKeysToVector/copyValuesToVector with copyToVector(map.keys())/copyToVector(map.values())
        https://bugs.webkit.org/show_bug.cgi?id=178102

        Reviewed by Tim Horton.

        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::clearInspectorBreakpointState):

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

        Unreviewed build fix.

        Removed unused lambda capture.

        * yarr/YarrPattern.cpp:
        (JSC::Yarr::CharacterClassConstructor::appendInverted):

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

        The prototype cache should be aware of the Executable it generates a Structure for
        https://bugs.webkit.org/show_bug.cgi?id=177907

        Reviewed by Filip Pizlo.

        This patch renames PrototypeMap to StructureCache because
        it is no longer a map of the prototypes in the VM. It's
        only used to cache Structures during object construction.
        
        The main change of this patch is to guarantee that Structures generated
        by the create_this originating from different two different Executables'
        bytecode won't hash-cons to the same thing. Previously, we could hash-cons
        them depending on the JSObject* prototype pointer. This would cause the last
        thing that hash-consed to overwrite the Structure's poly proto watchpoint. This
        happened because when we initialize a JSFunction's ObjectAllocationProfile,
        we set the resulting Structure's poly proto watchpoint. This could cause a Structure
        generating from some Executable e1 to end up with the poly proto watchpoint
        for another Executable e2 simply because JSFunctions backed by e1 and e2
        shared the same prototype. Then, based on profiling information, we may fire the
        wrong Executable's poly proto watchpoint. This patch fixes this bug by
        guaranteeing that Structures generating from create_this for different
        Executables are unique even if they share the same prototype by adding
        the FunctionExecutable* as another field in PrototypeKey.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * bytecode/InternalFunctionAllocationProfile.h:
        (JSC::InternalFunctionAllocationProfile::createAllocationStructureFromBase):
        * bytecode/ObjectAllocationProfile.cpp:
        (JSC::ObjectAllocationProfile::initializeProfile):
        * dfg/DFGOperations.cpp:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::createSubclassStructureSlow):
        * runtime/IteratorOperations.cpp:
        (JSC::createIteratorResultObjectStructure):
        * runtime/JSBoundFunction.cpp:
        (JSC::getBoundFunctionStructure):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/ObjectConstructor.h:
        (JSC::constructEmptyObject):
        * runtime/PrototypeKey.h:
        (JSC::PrototypeKey::PrototypeKey):
        (JSC::PrototypeKey::executable const):
        (JSC::PrototypeKey::operator== const):
        (JSC::PrototypeKey::hash const):
        * runtime/PrototypeMap.cpp: Removed.
        * runtime/PrototypeMap.h: Removed.
        * runtime/StructureCache.cpp: Copied from Source/JavaScriptCore/runtime/PrototypeMap.cpp.
        (JSC::StructureCache::createEmptyStructure):
        (JSC::StructureCache::emptyStructureForPrototypeFromBaseStructure):
        (JSC::StructureCache::emptyObjectStructureForPrototype):
        (JSC::PrototypeMap::createEmptyStructure): Deleted.
        (JSC::PrototypeMap::emptyStructureForPrototypeFromBaseStructure): Deleted.
        (JSC::PrototypeMap::emptyObjectStructureForPrototype): Deleted.
        * runtime/StructureCache.h: Copied from Source/JavaScriptCore/runtime/PrototypeMap.h.
        (JSC::StructureCache::StructureCache):
        (JSC::PrototypeMap::PrototypeMap): Deleted.
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

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

        `async` should be able to be used as an imported binding name
        https://bugs.webkit.org/show_bug.cgi?id=176573

        Reviewed by Saam Barati.

        Previously, we have ASYNC keyword in the parser. This is introduced only for performance,
        and ECMA262 spec does not categorize "async" to keyword. This makes parser code complicated,
        since ASYNC should be handled as IDENT. If we missed this ASYNC keyword, we cause a bug.
        For example, import declaration failed to bind imported binding to the name "async" because
        the parser considered ASYNC as keyword.

        This patch removes ASYNC keyword from the parser. By carefully handling ASYNC, we can keep
        the current performance without using this ASYNC keyword.

        We also add `escaped` field to token data since contextual keyword is valid only if it does
        not contain any escape sequences. We fix bunch of contextual keyword use with this fix too
        e.g. `of in for-of`. This improves test262 score.

        * parser/Keywords.table:
        * parser/Lexer.cpp:
        (JSC::Lexer<LChar>::parseIdentifier):
        (JSC::Lexer<UChar>::parseIdentifier):
        (JSC::Lexer<CharacterType>::parseIdentifierSlowCase):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseStatementListItem):
        (JSC::Parser<LexerType>::parseForStatement):
        (JSC::Parser<LexerType>::parseStatement):
        (JSC::Parser<LexerType>::maybeParseAsyncFunctionDeclarationStatement):
        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parseExportDeclaration):
        (JSC::Parser<LexerType>::parseAssignmentExpression):
        (JSC::Parser<LexerType>::parseProperty):
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        (JSC::Parser<LexerType>::parseMemberExpression):
        (JSC::Parser<LexerType>::printUnexpectedTokenText):
        * parser/Parser.h:
        (JSC::Parser::matchContextualKeyword):
        * parser/ParserTokens.h:
        * runtime/CommonIdentifiers.h:

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

        We don't need to clearEmptyObjectStructureForPrototype because JSGlobalObject* is part of the cache's key
        https://bugs.webkit.org/show_bug.cgi?id=177987

        Reviewed by Filip Pizlo.

        * runtime/JSProxy.cpp:
        (JSC::JSProxy::setTarget):
        * runtime/PrototypeMap.cpp:
        (JSC::PrototypeMap::clearEmptyObjectStructureForPrototype): Deleted.
        * runtime/PrototypeMap.h:

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

        JSCell::didBecomePrototype is racy
        https://bugs.webkit.org/show_bug.cgi?id=178110

        Reviewed by Saam Barati.
        
        The indexing type can be modified by any thread using CAS. So, we need to use atomics when
        modifying it. We don't need to use atomics when reading it though (since it's just one field).

        * runtime/JSCellInlines.h:
        (JSC::JSCell::didBecomePrototype):

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

        Enable gigacage on iOS
        https://bugs.webkit.org/show_bug.cgi?id=177586

        Reviewed by JF Bastien.

        The hardest part of enabling Gigacage on iOS is that it requires loading global variables while
        executing JS, so the LLInt needs to know how to load from global variables on all platforms that
        have Gigacage. So, this teaches ARM64 how to load from global variables.
        
        Also, this makes the code handle disabling the gigacage a bit better.

        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::caged):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::cage):
        (JSC::AssemblyHelpers::cageConditionally):
        * offlineasm/arm64.rb:
        * offlineasm/asm.rb:
        * offlineasm/instructions.rb:

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

        Evaluate the benefit of skipping dead code in the DFGByteCodeParser when a function returns in its first block
        https://bugs.webkit.org/show_bug.cgi?id=177925

        Reviewed by Saam Barati.

        We used to do a rather weird "optimisation" in the bytecode parser: when a function would return in its first block,
        the rest of the function was skipped. Since it has no actual impact on any benchmarks from what I could see, I removed
        that code. It allows some changes to parseBlock(), since it now returns void and no-longer bool (it was returning a boolean that said whether that case happened or not).

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::parseCodeBlock):

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

        Refactor the inliner to simplify block linking
        https://bugs.webkit.org/show_bug.cgi?id=177922

        Reviewed by Saam Barati.

        The biggest refactor changes the way blocks are linked. In DFGByteCodeParser, most terminals (such as Jump or Branch) jump to nullptr initially, and have
        some metadata indicating the bytecode index corresponding to their targets. They are later linked to the right basic block using two fields of InlineStackEntry:
        - m_unlinkedBlocks is just a worklist of blocks with a terminal that needs to be linked
        - m_linkingTargets is a dictionary from bytecode indices to BasicBlock*
        Before refactoring, every block was automatically added to both of these fields, for the InlineStackEntry of whatever function allocated it.
        This created a significant number of corner cases, such as blocks allocated in a caller, with a terminal written by an inlined callee and pointing to a block in the callee,
        or blocks allocated in an inline callee, with a terminal written by the caller after it returns and pointing to a block in the caller, or blocks with a manually linked
        terminal that needs to be taken off m_unlinkedBlocks.
        I changed things so that blocks are only added to m_unlinkedBlocks when their terminal gets written (see the LAST_OPCODE macro) making it a lot easier to be in the "right" InlineStackEntry,
        that is the one that holds their target in its m_linkingTargets field.

        There are a few much smaller refactors in this patch:
        - parse() is now of type void insted of bool (it was always returning true)
        - The 7 and 8 arguments of handleCall were inlined in its 3 arguments version for readability
        - The 9 argument version was cleaned up and simplified
        - I made separate allocateBlock routines because the little dance with adoptRef(* new BasicBlock(...)) was being repeated in lots of places, and typos in that were a major source of bugs during other refactorings
        - Jumps are now created with explicit addJumpTo() functions, providing some sanity checking through asserts and didLink()
        - Blocks are only added to m_unlinkedBlocks if they end in a terminal that linkBlock works with (see LAST_OPCODE)

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::addToGraph):
        (JSC::DFG::ByteCodeParser::handleCall):
        (JSC::DFG::ByteCodeParser::refineStatically):
        (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
        (JSC::DFG::ByteCodeParser::handleVarargsCall):
        (JSC::DFG::ByteCodeParser::inlineCall):
        (JSC::DFG::ByteCodeParser::attemptToInlineCall):
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::parseCodeBlock):
        (JSC::DFG::ByteCodeParser::parse):
        (JSC::DFG::parse):
        (JSC::DFG::ByteCodeParser::cancelLinkingForBlock): Deleted.
        * dfg/DFGByteCodeParser.h:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):

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

        Implement RegExp Unicode property escapes
        https://bugs.webkit.org/show_bug.cgi?id=172069

        Reviewed by JF Bastien.

        Added Unicode Properties by extending the existing CharacterClass processing.

        Introduced a new Python script, generateYarrUnicodePropertyTables.py, that parses
        Unicode Database files to create character class data.  The result is a set of functions
        that return character classes, one for each of the required Unicode properties.
        There are many cases where many properties are handled by one function, primarily due to
        property aliases, but also due to Script_Extension properties that are the same as the
        Script property for the same script value.

        Extended the BuiltInCharacterClassID enum so it can be used also for Unicode property
        character classes.  Unicode properties are the enum value BaseUnicodePropertyID plus a
        zero based value, that value being the index to the corrensponding character class
        function.  The generation script also creates static hashing tables similar to what we
        use for the generated .lut.h lookup table files.  These hashing tables map property
        names to the function index.  Using these hashing tables, we can lookup a property
        name and if present convert it to a function index.  We add that index to
        BaseUnicodePropertyID to create a BuiltInCharacterClassID.

        When we do syntax parsing, we convert the property to its corresponding BuiltInCharacterClassID.
        When doing real parsing we takes the returned BuiltInCharacterClassID and use it to get
        the actual character class by calling the corresponding generated function.

        Added a new CharacterClass constructor that can take literal arrays for ranges and matches
        to make the creation of large static character classes more efficent.

        Since the Unicode character classes typically have more matches and ranges, the character
        class matching in the interpreter has been updated to use binary searching for matches and
        ranges with more than 6 entries.

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Scripts/generateYarrUnicodePropertyTables.py: Added.
        (openOrExit):
        (openUCDFileOrExit):
        (verifyUCDFilesExist):
        (ceilingToPowerOf2):
        (Aliases):
        (Aliases.__init__):
        (Aliases.parsePropertyAliasesFile):
        (Aliases.parsePropertyValueAliasesFile):
        (Aliases.globalAliasesFor):
        (Aliases.generalCategoryAliasesFor):
        (Aliases.generalCategoryForAlias):
        (Aliases.scriptAliasesFor):
        (Aliases.scriptNameForAlias):
        (PropertyData):
        (PropertyData.__init__):
        (PropertyData.setAliases):
        (PropertyData.makeCopy):
        (PropertyData.getIndex):
        (PropertyData.getCreateFuncName):
        (PropertyData.addMatch):
        (PropertyData.addRange):
        (PropertyData.addMatchUnorderedForMatchesAndRanges):
        (PropertyData.addRangeUnorderedForMatchesAndRanges):
        (PropertyData.addMatchUnordered):
        (PropertyData.addRangeUnordered):
        (PropertyData.removeMatchFromRanges):
        (PropertyData.removeMatch):
        (PropertyData.dumpMatchData):
        (PropertyData.dump):
        (PropertyData.dumpAll):
        (PropertyData.dumpAll.std):
        (PropertyData.createAndDumpHashTable):
        (Scripts):
        (Scripts.__init__):
        (Scripts.parseScriptsFile):
        (Scripts.parseScriptExtensionsFile):
        (Scripts.dump):
        (GeneralCategory):
        (GeneralCategory.__init__):
        (GeneralCategory.createSpecialPropertyData):
        (GeneralCategory.findPropertyGroupFor):
        (GeneralCategory.addNextCodePoints):
        (GeneralCategory.parse):
        (GeneralCategory.dump):
        (BinaryProperty):
        (BinaryProperty.__init__):
        (BinaryProperty.parsePropertyFile):
        (BinaryProperty.dump):
        * Scripts/hasher.py: Added.
        (stringHash):
        * Sources.txt:
        * ucd/DerivedBinaryProperties.txt: Added.
        * ucd/DerivedCoreProperties.txt: Added.
        * ucd/DerivedNormalizationProps.txt: Added.
        * ucd/PropList.txt: Added.
        * ucd/PropertyAliases.txt: Added.
        * ucd/PropertyValueAliases.txt: Added.
        * ucd/ScriptExtensions.txt: Added.
        * ucd/Scripts.txt: Added.
        * ucd/UnicodeData.txt: Added.
        * ucd/emoji-data.txt: Added.
        * yarr/Yarr.h:
        * yarr/YarrInterpreter.cpp:
        (JSC::Yarr::Interpreter::testCharacterClass):
        * yarr/YarrParser.h:
        (JSC::Yarr::Parser::parseEscape):
        (JSC::Yarr::Parser::parseTokens):
        (JSC::Yarr::Parser::isUnicodePropertyValueExpressionChar):
        (JSC::Yarr::Parser::tryConsumeUnicodePropertyExpression):
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::CharacterClassConstructor::appendInverted):
        (JSC::Yarr::YarrPatternConstructor::atomBuiltInCharacterClass):
        (JSC::Yarr::YarrPatternConstructor::atomCharacterClassBuiltIn):
        (JSC::Yarr::YarrPattern::errorMessage):
        (JSC::Yarr::PatternTerm::dump):
        * yarr/YarrPattern.h:
        (JSC::Yarr::CharacterRange::CharacterRange):
        (JSC::Yarr::CharacterClass::CharacterClass):
        (JSC::Yarr::YarrPattern::reset):
        (JSC::Yarr::YarrPattern::unicodeCharacterClassFor):
        * yarr/YarrUnicodeProperties.cpp: Added.
        (JSC::Yarr::HashTable::entry const):
        (JSC::Yarr::unicodeMatchPropertyValue):
        (JSC::Yarr::unicodeMatchProperty):
        (JSC::Yarr::createUnicodeCharacterClassFor):
        * yarr/YarrUnicodeProperties.h: Added.

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

        Unreviewed, rolling out r223015 and r223025.
        https://bugs.webkit.org/show_bug.cgi?id=178093

        Regressed Kraken on iOS by 20% (Requested by keith_mi_ on
        #webkit).

        Reverted changesets:

        "Enable gigacage on iOS"
        https://bugs.webkit.org/show_bug.cgi?id=177586
        http://trac.webkit.org/changeset/223015

        "Unreviewed, disable Gigacage on ARM64 Linux"
        https://bugs.webkit.org/show_bug.cgi?id=177586
        http://trac.webkit.org/changeset/223025

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

        Unreviewed, sort unified sources again now that they are numbered numerically rather than lexicographically.

        * JavaScriptCore.xcodeproj/project.pbxproj:

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

        Unreviewed, rolling out r223022.

        This change introduced 18 test262 failures.

        Reverted changeset:

        "`async` should be able to be used as an imported binding
        name"
        https://bugs.webkit.org/show_bug.cgi?id=176573
        http://trac.webkit.org/changeset/223022

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

        Make the names of the options consistent
        https://bugs.webkit.org/show_bug.cgi?id=177933

        Reviewed by Saam Barati.

        I added an alias so the old spelling still works.
        I also fixed a bunch of typos in comments all around the codebase.

        * b3/B3LowerToAir.cpp:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGIntegerRangeOptimizationPhase.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSSAConversionPhase.h:
        * dfg/DFGSpeculativeJIT.h:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::lower):
        * ftl/FTLOSREntry.cpp:
        (JSC::FTL::prepareOSREntry):
        * jit/CallFrameShuffler.cpp:
        (JSC::CallFrameShuffler::prepareForTailCall):
        * parser/Nodes.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseExportDeclaration):
        * runtime/Options.h:

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

        Safari 10 /11 problem with if (!await get(something)).
        https://bugs.webkit.org/show_bug.cgi?id=176685

        Reviewed by Saam Barati.

        Using unary operator before `await` lead to count it as identifier.
        According to spec https://tc39.github.io/ecma262/#sec-async-function-definitions
        and Note 1 `await` is as AwaitExpression and it is allowed to use unary operator

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

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

        direct-construct-arity-mismatch.js can have GCs that take ~70ms if you force poly proto and disable generational GC
        https://bugs.webkit.org/show_bug.cgi?id=178051

        Reviewed by Saam Barati.
        
        After I studied the profile of this test, I found two pathologies in our code relating to
        prototypes. I think that now that we support poly proto, it's more likely for these pathologies to
        happen. Also, the fact that we force poly proto in some tests, it's possible for one of our tests
        to trigger these pathologies.
        
        - WeakGCMap::m_prototoypes is the set of all prototypes. That's super dangerous. This patch turns
          this into a bit in the JSCell header. It uses the last spare bit in indexingTypeAndMisc. Note
          that we still have 6 spare bits in cellState, but those are a bit more annoying to get at.
        
        - WeakGCMap registers itself with GC using a std::function. That means allocating things in the
          malloc heap. This changes it to a virtual method on WeakGCMap. I don't know for sure that this is
          a problem area, but there are places where we could allocate a lot of WeakGCMaps, like if we have
          a lot of transition tables. It's good to reduce the amount of memory those require.
        
        Also, I saw a FIXME about turning the std::tuple in PrototypeMap into a struct, so I did that while
        I was at it. I initially thought that this would have to be part of my solution, but it turned out
        not to be. I think it's worth landing anyway since it makes the code a lot more clear.
        
        This fixes the timeout in that test and probably reduces memory consumption.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGOperations.cpp:
        * heap/Heap.cpp:
        (JSC::Heap::pruneStaleEntriesFromWeakGCMaps):
        (JSC::Heap::registerWeakGCMap):
        (JSC::Heap::unregisterWeakGCMap):
        * heap/Heap.h:
        * inspector/JSInjectedScriptHostPrototype.cpp:
        (Inspector::JSInjectedScriptHostPrototype::finishCreation):
        * inspector/JSJavaScriptCallFramePrototype.cpp:
        (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
        * runtime/ArrayIteratorPrototype.cpp:
        (JSC::ArrayIteratorPrototype::finishCreation):
        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation):
        * runtime/AsyncFromSyncIteratorPrototype.cpp:
        (JSC::AsyncFromSyncIteratorPrototype::finishCreation):
        * runtime/AsyncFunctionPrototype.cpp:
        (JSC::AsyncFunctionPrototype::finishCreation):
        * runtime/AsyncGeneratorFunctionPrototype.cpp:
        (JSC::AsyncGeneratorFunctionPrototype::finishCreation):
        * runtime/AsyncGeneratorPrototype.cpp:
        (JSC::AsyncGeneratorPrototype::finishCreation):
        * runtime/AsyncIteratorPrototype.cpp:
        (JSC::AsyncIteratorPrototype::finishCreation):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/GeneratorFunctionPrototype.cpp:
        (JSC::GeneratorFunctionPrototype::finishCreation):
        * runtime/GeneratorPrototype.cpp:
        (JSC::GeneratorPrototype::finishCreation):
        * runtime/IndexingType.h:
        * runtime/IteratorPrototype.cpp:
        (JSC::IteratorPrototype::finishCreation):
        * runtime/JSCInlines.h:
        * runtime/JSCell.h:
        * runtime/JSCellInlines.h:
        (JSC::JSCell::mayBePrototype const):
        (JSC::JSCell::didBecomePrototype):
        * runtime/JSObject.cpp:
        (JSC::JSObject::notifyPresenceOfIndexedAccessors):
        (JSC::JSObject::setPrototypeDirect):
        * runtime/JSProxy.cpp:
        (JSC::JSProxy::setTarget):
        * runtime/MapIteratorPrototype.cpp:
        (JSC::MapIteratorPrototype::finishCreation):
        * runtime/MapPrototype.cpp:
        (JSC::MapPrototype::finishCreation):
        * runtime/ObjectPrototype.cpp:
        (JSC::ObjectPrototype::finishCreation):
        * runtime/PrototypeKey.h: Added.
        (JSC::PrototypeKey::PrototypeKey):
        (JSC::PrototypeKey::prototype const):
        (JSC::PrototypeKey::inlineCapacity const):
        (JSC::PrototypeKey::classInfo const):
        (JSC::PrototypeKey::globalObject const):
        (JSC::PrototypeKey::operator== const):
        (JSC::PrototypeKey::operator!= const):
        (JSC::PrototypeKey::operator bool const):
        (JSC::PrototypeKey::isHashTableDeletedValue const):
        (JSC::PrototypeKey::hash const):
        (JSC::PrototypeKeyHash::hash):
        (JSC::PrototypeKeyHash::equal):
        * runtime/PrototypeMap.cpp:
        (JSC::PrototypeMap::createEmptyStructure):
        (JSC::PrototypeMap::clearEmptyObjectStructureForPrototype):
        * runtime/PrototypeMap.h:
        (JSC::PrototypeMap::PrototypeMap):
        * runtime/PrototypeMapInlines.h: Removed.
        * runtime/SetIteratorPrototype.cpp:
        (JSC::SetIteratorPrototype::finishCreation):
        * runtime/SetPrototype.cpp:
        (JSC::SetPrototype::finishCreation):
        * runtime/StringIteratorPrototype.cpp:
        (JSC::StringIteratorPrototype::finishCreation):
        * runtime/WeakGCMap.h:
        (JSC::WeakGCMapBase::~WeakGCMapBase):
        * runtime/WeakGCMapInlines.h:
        (JSC::KeyTraitsArg>::WeakGCMap):
        * runtime/WeakMapPrototype.cpp:
        (JSC::WeakMapPrototype::finishCreation):
        * runtime/WeakSetPrototype.cpp:
        (JSC::WeakSetPrototype::finishCreation):

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

        Octane/splay can leak memory due to stray pointers on the stack when run from the command line
        https://bugs.webkit.org/show_bug.cgi?id=178054

        Reviewed by Saam Barati.
        
        This throws in a bunch of sanitize calls. It fixes the problem. It's also performance-neutral. In
        most cases, calling the sanitize function is O(1), because it doesn't have anything to do if the stack
        height stays relatively constant.

        * dfg/DFGOperations.cpp:
        * dfg/DFGTierUpCheckInjectionPhase.cpp:
        (JSC::DFG::TierUpCheckInjectionPhase::run):
        * ftl/FTLOSREntry.cpp:
        * heap/Heap.cpp:
        (JSC::Heap::runCurrentPhase):
        * heap/MarkedAllocatorInlines.h:
        (JSC::MarkedAllocator::tryAllocate):
        (JSC::MarkedAllocator::allocate):
        * heap/Subspace.cpp:
        (JSC::Subspace::tryAllocateSlow):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::sanitizeStackInline):
        * jit/ThunkGenerators.cpp:
        (JSC::slowPathFor):
        * runtime/VM.h:
        (JSC::VM::addressOfLastStackTop):

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

        `async` should be able to be used as an imported binding name
        https://bugs.webkit.org/show_bug.cgi?id=176573

        Reviewed by Darin Adler.

        Previously, we have ASYNC keyword in the parser. This is introduced only for performance,
        and ECMA262 spec does not categorize "async" to keyword. This makes parser code complicated,
        since ASYNC should be handled as IDENT. If we missed this ASYNC keyword, we cause a bug.
        For example, import declaration failed to bind imported binding to the name "async" because
        the parser considered ASYNC as keyword.

        This patch removes ASYNC keyword from the parser. By carefully handling ASYNC, we can keep
        the current performance without using this ASYNC keyword.

        * parser/Keywords.table:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseStatementListItem):
        (JSC::Parser<LexerType>::parseStatement):
        (JSC::Parser<LexerType>::maybeParseAsyncFunctionDeclarationStatement):
        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parseExportDeclaration):
        (JSC::Parser<LexerType>::parseAssignmentExpression):
        (JSC::Parser<LexerType>::parseProperty):
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        (JSC::Parser<LexerType>::parseMemberExpression):
        (JSC::Parser<LexerType>::printUnexpectedTokenText):
        * parser/ParserTokens.h:
        * runtime/CommonIdentifiers.h:

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

        Enable gigacage on iOS
        https://bugs.webkit.org/show_bug.cgi?id=177586

        Reviewed by JF Bastien.

        The hardest part of enabling Gigacage on iOS is that it requires loading global variables while
        executing JS, so the LLInt needs to know how to load from global variables on all platforms that
        have Gigacage. So, this teaches ARM64 how to load from global variables.
        
        Also, this makes the code handle disabling the gigacage a bit better.

        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::caged):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::cage):
        (JSC::AssemblyHelpers::cageConditionally):
        * offlineasm/arm64.rb:
        * offlineasm/asm.rb:
        * offlineasm/instructions.rb:

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

        Enable RegExp JIT for match only Unicode RegExp's
        https://bugs.webkit.org/show_bug.cgi?id=178033

        Reviewed by JF Bastien.

        I forgot to turn on JIT'ing for match-only Unicode RegExp's in r221052.  Do it now.

        * runtime/RegExp.cpp:
        (JSC::RegExp::compileMatchOnly):

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

        Build fix after r223002.

        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
        (JSC::DFG::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):

2017-10-06  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r222791 and r222873.
        https://bugs.webkit.org/show_bug.cgi?id=178031

        Caused crashes with workers/wasm LayoutTests (Requested by
        ryanhaddad on #webkit).

        Reverted changesets:

        "WebAssembly: no VM / JS version of everything but Instance"
        https://bugs.webkit.org/show_bug.cgi?id=177473
        http://trac.webkit.org/changeset/222791

        "WebAssembly: address no VM / JS follow-ups"
        https://bugs.webkit.org/show_bug.cgi?id=177887
        http://trac.webkit.org/changeset/222873

2017-10-06  Robin Morisset  <rmorisset@apple.com>

        Avoid integer overflow in DFGStrengthReduction.cpp
        https://bugs.webkit.org/show_bug.cgi?id=177944

        Reviewed by Saam Barati.

        The check that we won't do integer overflow by negating INT32_MIN was itself an integer overflow.
        I think that signed integer overflow is undefined behaviour in C, so I replace it by an explicit check that value != INT32_MIN instead.

        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):

2017-10-05  Keith Miller  <keith_miller@apple.com>

        JSC generate unified sources doesn't need to run during installhdrs.
        https://bugs.webkit.org/show_bug.cgi?id=177640

        Reviewed by Dan Bernstein.

        generate unified sources doesn't need to have a xcconfig file
        since we don't have any feature defines. Also, remove the plist
        because there's no plist for this...

        * JavaScriptCore.xcodeproj/project.pbxproj:

2017-10-05  Jer Noble  <jer.noble@apple.com>

        [Cocoa] Enable ENABLE_ENCRYPTED_MEDIA build-time setting
        https://bugs.webkit.org/show_bug.cgi?id=177261

        Reviewed by Eric Carlson.

        * Configurations/FeatureDefines.xcconfig:

2017-10-05  Ryan Haddad  <ryanhaddad@apple.com>

        Unreviewed, rolling out r222929.

        Caused assertion failures during LayoutTests.

        Reverted changeset:

        "Only add prototypes to the PrototypeMap if they're not
        already present"
        https://bugs.webkit.org/show_bug.cgi?id=177952
        http://trac.webkit.org/changeset/222929

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

        Generate a compile error if release is built without compiler optimizations
        https://bugs.webkit.org/show_bug.cgi?id=177665

        Reviewed by Brian Burg.

        Pass -DRELEASE_WITHOUT_OPTIMIZATIONS to testair.cpp and testb3.cpp because
        this files are compiled with -O0 for build speed reasons after r195639.

        * JavaScriptCore.xcodeproj/project.pbxproj:

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

        Only add prototypes to the PrototypeMap if they're not already present
        https://bugs.webkit.org/show_bug.cgi?id=177952

        Reviewed by Michael Saboff and JF Bastien.

        With poly proto, we need to call PrototypeMap::add more frequently since we don't
        know if the prototype is already in the map or not based solely on Structure.
        PrototypeMap::add was calling WeakMap::set unconditionally, which would unconditionally
        allocate a Weak handle. Allocating a Weak handle is expensive. It's at least 8x more
        expensive than just checking if the prototype is in the map prior to adding it. This
        patch makes the change to only add the prototype if it's not already in the map. To
        do this, I've added a WeakMap::add API that just forwards into HashMap's add API.
        This allows us to both only do a single hash table lookup and also to allocate only
        a single Weak handle when necessary.

        * runtime/PrototypeMapInlines.h:
        (JSC::PrototypeMap::addPrototype):
        * runtime/WeakGCMap.h:
        (JSC::WeakGCMap::add):

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

        Unreviewed. Disable probe OSR exit on 32-bit until it's fixed.

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

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

        Make sure all prototypes under poly proto get added into the VM's prototype map
        https://bugs.webkit.org/show_bug.cgi?id=177909

        Reviewed by Keith Miller.

        This is an invariant of prototypes that I broke when doing poly proto. This patch fixes it.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/BytecodeList.json:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGOperations.cpp:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/JSCInlines.h:
        * runtime/PrototypeMap.cpp:
        (JSC::PrototypeMap::addPrototype): Deleted.
        * runtime/PrototypeMap.h:
        * runtime/PrototypeMapInlines.h:
        (JSC::PrototypeMap::isPrototype const):
        (JSC::PrototypeMap::addPrototype):

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

        [JSC] Introduce import.meta
        https://bugs.webkit.org/show_bug.cgi?id=177703

        Reviewed by Filip Pizlo.

        This patch adds stage 3 `import.meta`[1].
        We add a new hook function moduleLoaderCreateImportMetaProperties, which creates
        import meta properties object to this module. And we set this object as @meta
        private variable in module environments. So module code can access this by accessing
        @meta private variable.

        [1]: https://github.com/tc39/proposal-import-meta

        * builtins/BuiltinNames.h:
        * builtins/ModuleLoaderPrototype.js:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * jsc.cpp:
        (GlobalObject::moduleLoaderCreateImportMetaProperties):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseModuleSourceElements):
        (JSC::Parser<LexerType>::parseMemberExpression):
        * runtime/JSGlobalObject.cpp:
        * runtime/JSGlobalObject.h:
        * runtime/JSModuleLoader.cpp:
        (JSC::JSModuleLoader::createImportMetaProperties):
        * runtime/JSModuleLoader.h:
        * runtime/JSModuleRecord.cpp:
        (JSC::JSModuleRecord::link):
        (JSC::JSModuleRecord::instantiateDeclarations):
        * runtime/JSModuleRecord.h:
        * runtime/ModuleLoaderPrototype.cpp:
        (JSC::moduleLoaderPrototypeModuleDeclarationInstantiation):

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

        Make pertinent AccessCases watch the poly proto watchpoint
        https://bugs.webkit.org/show_bug.cgi?id=177765

        Reviewed by Keith Miller.

        This patch makes it so that stubs that encounter a structure with a
        valid poly proto watchpoint will watch the poly proto watchpoint. This
        ensures that if the watchpoint is fired, the stub will be cleared
        and have a chance to regenerate. In an ideal world, this will lead
        to the stub generating better code since it may never encounter the
        non-poly proto structure again.
        
        This patch also fixes a bug in the original poly proto code where
        I accidentally had a condition inverted. The bad code caused a
        stub that continually cached two structures which are structurally
        equivalent but with different prototype objects to always clear itself.
        The code should have been written differently. It should have only
        cleared if the poly proto watchpoint *was not* fired. The code
        accidentally cleared only if stub *was* fired.

        * bytecode/AccessCase.cpp:
        (JSC::AccessCase::commit):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::PolymorphicAccess::addCases):
        (WTF::printInternal):
        * bytecode/PolymorphicAccess.h:
        (JSC::AccessGenerationResult::shouldResetStubAndFireWatchpoints const):
        (JSC::AccessGenerationResult::addWatchpointToFire):
        (JSC::AccessGenerationResult::fireWatchpoints):
        (JSC::AccessGenerationResult::shouldResetStub const): Deleted.
        * bytecode/StructureStubInfo.cpp:
        (JSC::StructureStubInfo::addAccessCase):
        (JSC::StructureStubInfo::reset):
        * bytecode/Watchpoint.h:
        (JSC::InlineWatchpointSet::inflate):
        * jit/Repatch.cpp:
        (JSC::fireWatchpointsAndClearStubIfNeeded):
        (JSC::tryCacheGetByID):
        (JSC::repatchGetByID):
        (JSC::tryCachePutByID):
        (JSC::repatchPutByID):
        (JSC::tryCacheIn):
        (JSC::repatchIn):
        (JSC::tryRepatchIn): Deleted.

2017-10-04  Matt Baker  <mattbaker@apple.com>

        Web Inspector: Improve CanvasManager recording events
        https://bugs.webkit.org/show_bug.cgi?id=177762

        Reviewed by Devin Rousso.

        * inspector/protocol/Canvas.json:
        Renamed events for clarity and consistency; made recording data optional.

2017-10-04  JF Bastien  <jfbastien@apple.com>

        WTF: Update std::expected to match current proposal
        https://bugs.webkit.org/show_bug.cgi?id=177881

        Reviewed by Mark Lam.

        Update API.

        * wasm/WasmB3IRGenerator.cpp:
        * wasm/WasmModule.cpp:
        (JSC::Wasm::makeValidationResult):
        * wasm/WasmParser.h:
        * wasm/WasmValidate.cpp:
        * wasm/generateWasmValidateInlinesHeader.py:
        (loadMacro):
        (storeMacro):

2017-10-04  JF Bastien  <jfbastien@apple.com>

        WebAssembly: address no VM / JS follow-ups
        https://bugs.webkit.org/show_bug.cgi?id=177887

        Reviewed by Saam Barati.

        All minor fixes, no functional changes.

        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
        (JSC::Wasm::B3IRGenerator::addCurrentMemory):
        (JSC::Wasm::B3IRGenerator::addCall):
        (JSC::Wasm::B3IRGenerator::addCallIndirect):
        * wasm/WasmContext.cpp:
        (JSC::Wasm::Context::store):
        * wasm/WasmMemoryMode.h:
        * wasm/WasmTable.h:
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
        * wasm/js/JSWebAssemblyTable.cpp:
        (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
        (JSC::JSWebAssemblyTable::grow):

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

        Add support for using Probe DFG OSR Exit behind a runtime flag.
        https://bugs.webkit.org/show_bug.cgi?id=177844
        <rdar://problem/34801425>

        Reviewed by Saam Barati.

        This is based on the code originally posted in https://bugs.webkit.org/show_bug.cgi?id=175144
        (in r221774 and r221832) with some optimizations and bug fixes added.  The probe
        based DFG OSR Exit is only enabled if Options::useProbeOSRExit() is true.  We're
        landing this behind an option switch to make it easier to tune performance using
        the probe based OSR exit.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/MacroAssembler.cpp:
        (JSC::stdFunctionCallback):
        * assembler/MacroAssemblerPrinter.cpp:
        (JSC::Printer::printCallback):
        * assembler/ProbeContext.cpp:
        (JSC::Probe::executeProbe):
        (JSC::Probe::flushDirtyStackPages):
        * assembler/ProbeContext.h:
        (JSC::Probe::Context::Context):
        (JSC::Probe::Context::arg):
        * assembler/ProbeFrame.h: Added.
        (JSC::Probe::Frame::Frame):
        (JSC::Probe::Frame::argument):
        (JSC::Probe::Frame::operand):
        (JSC::Probe::Frame::setArgument):
        (JSC::Probe::Frame::setOperand):
        (JSC::Probe::Frame::get):
        (JSC::Probe::Frame::set):
        * assembler/ProbeStack.cpp:
        (JSC::Probe::Page::lowWatermarkFromVisitingDirtyChunks):
        (JSC::Probe::Stack::Stack):
        (JSC::Probe::Stack::lowWatermarkFromVisitingDirtyPages):
        * assembler/ProbeStack.h:
        (JSC::Probe::Stack::Stack):
        (JSC::Probe::Stack::lowWatermark):
        (JSC::Probe::Stack::set):
        (JSC::Probe::Stack::savedStackPointer const):
        (JSC::Probe::Stack::setSavedStackPointer):
        (JSC::Probe::Stack::newStackPointer const): Deleted.
        (JSC::Probe::Stack::setNewStackPointer): Deleted.
        * 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/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::emitRestoreArguments):
        (JSC::DFG::OSRExit::executeOSRExit):
        (JSC::DFG::reifyInlinedCallFrames):
        (JSC::DFG::adjustAndJumpToTarget):
        (JSC::DFG::printOSRExit):
        * dfg/DFGOSRExit.h:
        (JSC::DFG::OSRExitState::OSRExitState):
        * dfg/DFGThunks.cpp:
        (JSC::DFG::osrExitThunkGenerator):
        * dfg/DFGThunks.h:
        * dfg/DFGVariableEventStream.cpp:
        (JSC::DFG::tryToSetConstantRecovery):
        (JSC::DFG::VariableEventStream::reconstruct const):
        (JSC::DFG::VariableEventStream::tryToSetConstantRecovery const): Deleted.
        * dfg/DFGVariableEventStream.h:
        * profiler/ProfilerOSRExit.h:
        (JSC::Profiler::OSRExit::incCount):
        * runtime/JSCJSValue.h:
        * runtime/JSCJSValueInlines.h:
        * runtime/Options.h:

2017-10-04  Ryan Haddad  <ryanhaddad@apple.com>

        Unreviewed, rolling out r222840.

        This change breaks internal builds.

        Reverted changeset:

        "Generate a compile error if release is built without compiler
        optimizations"
        https://bugs.webkit.org/show_bug.cgi?id=177665
        http://trac.webkit.org/changeset/222840

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

        Generate a compile error if release is built without compiler optimizations
        https://bugs.webkit.org/show_bug.cgi?id=177665

        Reviewed by Michael Catanzaro.

        Pass -DRELEASE_WITHOUT_OPTIMIZATIONS to testair.cpp and testb3.cpp because
        this files are compiled with -O0 for build speed reasons after r195639.

        * JavaScriptCore.xcodeproj/project.pbxproj:

2017-10-03  Jon Davis  <jond@apple.com>

        Update WebAssembly to "Supported"
        https://bugs.webkit.org/show_bug.cgi?id=177831

        Reviewed by Alexey Proskuryakov.
        
        Cleaned up Async Iteration and Object rest/spread to use "In Development" 
        instead of "In development". 

        * features.json: 

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

        Implement polymorphic prototypes
        https://bugs.webkit.org/show_bug.cgi?id=176391

        Reviewed by Filip Pizlo.

        This patch changes JSC's object model with respect to where the prototype
        of an object is stored. Previously, it was always stored as
        a constant value inside Structure. So an object's structure used to
        always tell you what its prototype is. Anytime an object changed
        its prototype, it would do a structure transition. This enables
        a large class of optimizations: just by doing a structure check,
        we know what the prototype is.
        
        However, this design falls down when you have many objects that
        have the same shape, but only differ in what their prototype value
        is. This arises in many JS programs. A simple, and probably common, example
        is when the program has a constructor inside of a function:
        ```
        function foo() {
            class C {
                constructor() { this.field1 = 42; ...; this.fieldN = 42; }
                method1() { doStuffWith(this.field); }
                method2() { doStuffWith(this.field); }
            }
            let c = new C;
            do things with c;
            }
        repeatedly call foo() here.
        ```
        
        Before this patch, in the above program, each time `new C` created an
        object, it would create an object with a different structure. The
        reason for this is that each time foo is called, there is a new
        instance of C.prototype. However, each `new C` that was created
        with have identical shape sans its prototype value. This would
        cause all ICs that used `c` to quickly give up on any form of caching
        because they would see too many structures and give up and permanently
        divert control flow to the slow path.
        
        This patch fixes this issue by expanding the notion of where the prototype
        of an object is stored. There are now two notions of where the prototype
        is stored. A Structure can now be in two modes:
        1. Mono proto mode. This is the same mode as we used to have. It means
        the structure itself has a constant prototype value.
        2. Poly proto mode. This means the structure knows nothing about the
        prototype value itself. Objects with this structure store their prototype
        in normal object field storage. The structure will tell you the offset of
        this prototype inside the object's storage. As of today, we only reserve
        inline slots for the prototype field because poly proto only occurs
        for JSFinalObject. However, this will be expanded to support out of line
        offsets in a future patch when we extend poly proto to work when we inherit
        from builtin types like Map and Array.
        
        In this initial patch, we do poly proto style inline caching whenever
        we see an object that is poly proto or if an object in its prototype lookup
        chain is poly proto. Poly proto ICs work by verifying the lookup chain
        at runtime. This essentially boils down to performing structure checks
        up the prototype chain. In a future patch, we're going to extend object
        property condition set to work with objects that don't have poly proto bases.
        
        Initially, accesses that have poly proto access chains will always turn
        into GetById/PutById in the DFG. In a future patch, I'm going to teach
        the DFG how to inline certain accesses that have poly proto in the access
        chain.
        
        One of most interesting parts about this patch is how we decide when to go
        poly proto. This patch uses a profiling based approach. An IC will inform
        a watchpoint that it sees an opportunity when two Structure's are structurally
        the same, sans the base object's prototype. This means that two structures
        have equivalent shapes all the way up the prototype chain. To support fast
        structural comparison, we compute a hash for a structure based on the properties
        it has. We compute this hash as we add properties to the structure. This
        computation is nearly free since we always add UniquedStringImpl*'s which
        already have their hashes computed. To compare structural equivalence, we
        just compare hash values all the way up the prototype chain. This means we
        can get hash conflicts between two structures, but it's extremely rare. First,
        it'll be rare for two structures to have the same hash. Secondly, we only
        consider structures originating from the same executable.
        
        How we set up this poly proto watchpoint is crucial to its design. When we create_this
        an object originating from some executable, that executable will create a Box<InlineWatchpointSet>.
        Each structure that originates from this executable will get a copy of that
        Box<InlineWatchpointSet>. As that structure transitions to new structures,
        they too will get a copy of that Box<InilneWatchpointSet>. Therefore, when
        invalidating an arbitrary structure's poly proto watchpoint, we will know
        the next time we create_this from that executable that it had been
        invalidated, and that we should create an object with a poly proto
        structure. We also use the pointer value of this Box<InlineWatchpointSet>
        to determine if two structures originated from the same executable. This
        pruning will severely limit the chances of getting a hash conflict in practice.
        
        This patch is neutral on my MBP on traditional JS benchmarks like Octane/Kraken/Sunspider.
        It may be a 1-2% ARES-6 progression.
        
        This patch is between neutral and a 9x progression on the various tests
        I added. Most of the microbenchmarks are progressed by at least 50%.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * builtins/BuiltinNames.cpp:
        * builtins/BuiltinNames.h:
        (JSC::BuiltinNames::BuiltinNames):
        (JSC::BuiltinNames::underscoreProtoPrivateName const):
        * bytecode/AccessCase.cpp:
        (JSC::AccessCase::AccessCase):
        (JSC::AccessCase::create):
        (JSC::AccessCase::commit):
        (JSC::AccessCase::guardedByStructureCheck const):
        (JSC::AccessCase::canReplace const):
        (JSC::AccessCase::dump const):
        (JSC::AccessCase::visitWeak const):
        (JSC::AccessCase::propagateTransitions const):
        (JSC::AccessCase::generateWithGuard):
        (JSC::AccessCase::generateImpl):
        * bytecode/AccessCase.h:
        (JSC::AccessCase::usesPolyProto const):
        (JSC::AccessCase::AccessCase):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
        * bytecode/GetterSetterAccessCase.cpp:
        (JSC::GetterSetterAccessCase::GetterSetterAccessCase):
        (JSC::GetterSetterAccessCase::create):
        * bytecode/GetterSetterAccessCase.h:
        * bytecode/InternalFunctionAllocationProfile.h:
        (JSC::InternalFunctionAllocationProfile::createAllocationStructureFromBase):
        * bytecode/IntrinsicGetterAccessCase.cpp:
        (JSC::IntrinsicGetterAccessCase::IntrinsicGetterAccessCase):
        * bytecode/IntrinsicGetterAccessCase.h:
        * bytecode/ModuleNamespaceAccessCase.cpp:
        (JSC::ModuleNamespaceAccessCase::ModuleNamespaceAccessCase):
        * bytecode/ObjectAllocationProfile.cpp: Added.
        (JSC::ObjectAllocationProfile::initializeProfile):
        (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount):
        * bytecode/ObjectAllocationProfile.h:
        (JSC::ObjectAllocationProfile::clear):
        (JSC::ObjectAllocationProfile::initialize): Deleted.
        (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount): Deleted.
        * bytecode/ObjectPropertyConditionSet.cpp:
        * bytecode/PolyProtoAccessChain.cpp: Added.
        (JSC::PolyProtoAccessChain::create):
        (JSC::PolyProtoAccessChain::needImpurePropertyWatchpoint const):
        (JSC::PolyProtoAccessChain::operator== const):
        (JSC::PolyProtoAccessChain::dump const):
        * bytecode/PolyProtoAccessChain.h: Added.
        (JSC::PolyProtoAccessChain::clone):
        (JSC::PolyProtoAccessChain:: const):
        (JSC::PolyProtoAccessChain::operator!= const):
        (JSC::PolyProtoAccessChain::forEach const):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::PolymorphicAccess::addCases):
        (JSC::PolymorphicAccess::regenerate):
        (WTF::printInternal):
        * bytecode/PolymorphicAccess.h:
        (JSC::AccessGenerationResult::shouldResetStub const):
        (JSC::AccessGenerationState::AccessGenerationState):
        * bytecode/PropertyCondition.cpp:
        (JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint const):
        * bytecode/ProxyableAccessCase.cpp:
        (JSC::ProxyableAccessCase::ProxyableAccessCase):
        (JSC::ProxyableAccessCase::create):
        * bytecode/ProxyableAccessCase.h:
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeForStubInfo):
        * bytecode/StructureStubInfo.cpp:
        (JSC::StructureStubInfo::addAccessCase):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::load):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::canDoFastSpread):
        * dfg/DFGOperations.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
        (JSC::DFG::SpeculativeJIT::compileInstanceOf):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_instanceof):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_instanceof):
        * jit/Repatch.cpp:
        (JSC::tryCacheGetByID):
        (JSC::tryCachePutByID):
        (JSC::tryRepatchIn):
        * jsc.cpp:
        (WTF::DOMJITGetterBaseJSObject::DOMJITGetterBaseJSObject):
        (WTF::DOMJITGetterBaseJSObject::createStructure):
        (WTF::DOMJITGetterBaseJSObject::create):
        (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::DOMJITAttribute):
        (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::slowCall):
        (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::callDOMGetter):
        (WTF::DOMJITGetterBaseJSObject::customGetter):
        (WTF::DOMJITGetterBaseJSObject::finishCreation):
        (GlobalObject::finishCreation):
        (functionCreateDOMJITGetterBaseJSObject):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/ArrayPrototype.cpp:
        (JSC::holesMustForwardToPrototype):
        (JSC::fastJoin):
        (JSC::arrayProtoFuncReverse):
        (JSC::moveElements):
        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::createEmpty):
        (JSC::ClonedArguments::createWithInlineFrame):
        (JSC::ClonedArguments::createWithMachineFrame):
        (JSC::ClonedArguments::createByCopyingFrom):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/FunctionExecutable.cpp:
        (JSC::FunctionExecutable::visitChildren):
        * runtime/FunctionExecutable.h:
        * runtime/FunctionRareData.cpp:
        (JSC::FunctionRareData::initializeObjectAllocationProfile):
        * runtime/FunctionRareData.h:
        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::createSubclassStructureSlow):
        * runtime/JSArray.cpp:
        (JSC::JSArray::fastSlice):
        (JSC::JSArray::shiftCountWithArrayStorage):
        (JSC::JSArray::shiftCountWithAnyIndexingType):
        (JSC::JSArray::isIteratorProtocolFastAndNonObservable):
        * runtime/JSArrayInlines.h:
        (JSC::JSArray::canFastCopy):
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::dumpInContextAssumingStructure const):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::prototypeForConstruction):
        (JSC::JSFunction::allocateAndInitializeRareData):
        (JSC::JSFunction::initializeRareData):
        (JSC::JSFunction::getOwnPropertySlot):
        * runtime/JSFunction.h:
        * runtime/JSMap.cpp:
        (JSC::JSMap::isIteratorProtocolFastAndNonObservable):
        (JSC::JSMap::canCloneFastAndNonObservable):
        * runtime/JSObject.cpp:
        (JSC::JSObject::putInlineSlow):
        (JSC::JSObject::createInitialIndexedStorage):
        (JSC::JSObject::createArrayStorage):
        (JSC::JSObject::convertUndecidedToArrayStorage):
        (JSC::JSObject::convertInt32ToArrayStorage):
        (JSC::JSObject::convertDoubleToArrayStorage):
        (JSC::JSObject::convertContiguousToArrayStorage):
        (JSC::JSObject::ensureInt32Slow):
        (JSC::JSObject::ensureDoubleSlow):
        (JSC::JSObject::ensureContiguousSlow):
        (JSC::JSObject::ensureArrayStorageSlow):
        (JSC::JSObject::setPrototypeDirect):
        (JSC::JSObject::ordinaryToPrimitive const):
        (JSC::JSObject::putByIndexBeyondVectorLength):
        (JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength):
        (JSC::JSObject::getEnumerableLength):
        (JSC::JSObject::anyObjectInChainMayInterceptIndexedAccesses const):
        (JSC::JSObject::prototypeChainMayInterceptStoreTo):
        (JSC::JSObject::needsSlowPutIndexing const):
        (JSC::JSObject::suggestedArrayStorageTransition const):
        * runtime/JSObject.h:
        (JSC::JSObject::finishCreation):
        (JSC::JSObject::getPrototypeDirect const):
        (JSC::JSObject::getPropertySlot):
        * runtime/JSObjectInlines.h:
        (JSC::JSObject::getPropertySlot):
        (JSC::JSObject::getNonIndexPropertySlot):
        (JSC::JSObject::putInlineForJSObject):
        * runtime/JSPropertyNameEnumerator.h:
        (JSC::propertyNameEnumerator):
        * runtime/JSSet.cpp:
        (JSC::JSSet::isIteratorProtocolFastAndNonObservable):
        (JSC::JSSet::canCloneFastAndNonObservable):
        * runtime/LazyClassStructure.h:
        (JSC::LazyClassStructure::prototypeConcurrently const): Deleted.
        * runtime/Operations.cpp:
        (JSC::normalizePrototypeChain):
        * runtime/Operations.h:
        * runtime/Options.h:
        * runtime/PrototypeMap.cpp:
        (JSC::PrototypeMap::createEmptyStructure):
        (JSC::PrototypeMap::emptyStructureForPrototypeFromBaseStructure):
        (JSC::PrototypeMap::emptyObjectStructureForPrototype):
        (JSC::PrototypeMap::clearEmptyObjectStructureForPrototype):
        * runtime/PrototypeMap.h:
        * runtime/Structure.cpp:
        (JSC::Structure::Structure):
        (JSC::Structure::create):
        (JSC::Structure::holesMustForwardToPrototype const):
        (JSC::Structure::changePrototypeTransition):
        (JSC::Structure::isCheapDuringGC):
        (JSC::Structure::toStructureShape):
        (JSC::Structure::dump const):
        (JSC::Structure::canCachePropertyNameEnumerator const):
        (JSC::Structure::anyObjectInChainMayInterceptIndexedAccesses const): Deleted.
        (JSC::Structure::needsSlowPutIndexing const): Deleted.
        (JSC::Structure::suggestedArrayStorageTransition const): Deleted.
        (JSC::Structure::prototypeForLookup const): Deleted.
        (JSC::Structure::prototypeChainMayInterceptStoreTo): Deleted.
        (JSC::Structure::canUseForAllocationsOf): Deleted.
        * runtime/Structure.h:
        * runtime/StructureChain.h:
        * runtime/StructureInlines.h:
        (JSC::Structure::create):
        (JSC::Structure::storedPrototypeObject const):
        (JSC::Structure::storedPrototypeStructure const):
        (JSC::Structure::storedPrototype const):
        (JSC::prototypeForLookupPrimitiveImpl):
        (JSC::Structure::prototypeForLookup const):
        (JSC::Structure::prototypeChain const):
        (JSC::Structure::isValid const):
        (JSC::Structure::add):
        (JSC::Structure::setPropertyTable):
        (JSC::Structure::shouldConvertToPolyProto):
        * runtime/StructureRareData.h:
        * runtime/TypeProfilerLog.cpp:
        (JSC::TypeProfilerLog::processLogEntries):
        * runtime/TypeSet.cpp:
        (JSC::TypeSet::addTypeInformation):
        * runtime/TypeSet.h:
        * runtime/WriteBarrier.h:
        (JSC::WriteBarrierBase<Unknown>::isInt32 const):

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

        WebAssembly: no VM / JS version of everything but Instance
        https://bugs.webkit.org/show_bug.cgi?id=177473

        Reviewed by Filip Pizlo.

        This change entails cleaning up and splitting a bunch of code which we had
        intertwined between C++ classes which represent JS objects, and pure C++
        implementation objects. This specific change goes most of the way towards
        allowing JSC's WebAssembly to work without VM / JS, up to but excluding
        JSWebAssemblyInstance (there's Wasm::Instance, but it's not *the* thing
        yet). Because of this we still have a few FIXME identifying places that need to
        change. A follow-up change will go the rest of the way.

        I went about this change in the simplest way possible: grep the
        JavaScriptCore/wasm directory for "JS[^C_]" as well as "VM" and exclude the /js/
        sub-directory (which contains the JS implementation of WebAssembly).

        None of this change removes the need for a JIT entitlement to be able to use
        WebAssembly. We don't have an interpreter, the process therefore still needs to
        be allowed to JIT to use these pure-C++ APIs.

        Interesting things to note:

          - Remove VM from Plan and associated places. It can just live as a capture in
            the callback lambda if it's needed.
          - Wasm::Memory shouldn't require a VM. It was only used to ask the GC to
            collect. We now instead pass two lambdas at construction time for this
            purpose: one to notify of memory pressure, and the other to ask for
            syncrhonous memory reclamation. This allows whoever creates the memory to
            dictate how to react to both these cases, and for a JS embedding that's to
            call the GC (async or sync, respectively).
          - Move grow logic from JSWebAssemblyMemory to Wasm::Memory::grow. Use Expected
            there, with an enum class for failure types.
          - Exceeding max on memory growth now returns a range error as per spec. This
            is a (very minor) breaking change: it used to throw OOM error. Update the
            corresponding test.
          - When generating the grow_memory opcode, no need to get the VM. Instead,
            reach directly for Wasm::Memory and grow it.
          - JSWebAssemblyMemory::grow can now always throw on failure, because it's only
            ever called from JS (not from grow_memory as before).
          - Wasm::Memory now takes a callback for successful growth. This allows JS
            wrappers to register themselves when growth succeeds without Wasm::Memory
            knowning anything about JS. It'll also allow creating a list of callbacks
            for when we add thread support (we'll want to notify many wrappers, all
            under a lock).
          - Wasm::Memory is now back to being the source of truth about address / size,
            used directly by generated code instead of JSWebAssemblyMemory.
          - Move wasmToJS from the general WasmBinding header to its own header under
            wasm/js. It's only used by wasm/js/JSWebAssemblyCodeBlock.cpp, and uses VM,
            and therefore isn't general WebAssembly.
          - Make Wasm::Context an actual type (just a struct holding a
            JSWebAssemlyInstance for now) instead of an alias for that. Notably this
            doesn't add anything to the Context and doesn't change what actually gets
            passed around in JIT code (fast TLS or registers) because these changes
            potentially impact performance. The entire purpose of this change is to
            allow passing Wasm::Context around without having to know about VM. Since VM
            contains a Wasm::Context the JS embedding is effectively the same, but with
            this setup a non-JS embedding is much better off.
          - Move JSWebAssembly into the JS folder.
          - OMGPlan: use Wasm::CodeBlock directly instead of JSWebAssemblyCodeBlock.
          - wasm->JS stubs are now on Wasm::CodeBlock's tail as raw pointers, instead of
            being on JSWebAssemblyCodeBlock, and are now called wasm->Embedder
            stubs. The owned reference is still on JSWebAssemblyCodeBlock, and is still
            called wasm->JS stub. This move means that the embedder must, after creating
            a Wasm::CodeBlock, somehow create the stubs to call back into the
            embedder. This isn't adding any indirection to the generated code because
            the B3 IR generator now reaches for Wasm::CodeBlock instead of
            JSWebAssemblyCodeBlock.
          - Move more CodeBlock things. Compilation completion is now marked by its own
            atomic<bool> flag instead of a nullptr plan: that required using a lock, and
            was causing a deadlock in stack-trace.js because before my changes
            JSWebAssemblyCodeBlock did its own completion checking separately from
            Wasm::CodeBlock, without getting the lock. Now that everything points to
            Wasm::CodeBlock and there's no cached completion marker, the lock was being
            acquired in a sanity-check assertion.
          - Embedder -> Wasm wrappers are now generated through a function that's passed
            in at compilation time, instead of being hard-coded as a JS -> Wasm wrapper.
          - WasmMemory doens't need to know about fault handling thunks. Only the IR
            generator should know, and should make sure that the exception throwing
            thunk is generated if any memory is present (note: with signal handling not
            all of them generate an exception check).
          - Make exception throwing pluggable: instead of having a hard-coded
            JS-specific lambda we now have a regular C++ function being called from JIT
            code when a WebAssembly exception is thrown. This allows any embedder to get
            called as they wish. For now a process can only have a single of these
            functions (i.e. only one embedder per process) because the trap handler is a
            singleton. That can be fixed in in #177475.
          - Create WasmEmbedder.h where all embedder plugging will live.
          - Split up JSWebAssemblyTable into Wasm::Table which is
            refcounted. JSWebAssemblyTable now only contains the JS functions in the
            table, and Wasm::Table is what's used by the JIT code to lookup where to
            call and do the instance check (for context switch). Note that this creates
            an extra allocation for all the instances in Wasm::Table, and in exchange
            removes an indirection in JIT code because the instance used to be obtained
            off of the JS function. Also note that it's the embedder than keeps the
            instances alive, not Wasm::Table (which holds a dumb pointer to the
            instance), because doing otherwise would cause reference cycles.
          - Add WasmInstance. It doesn't do much for now, owns globals.
          - JSWebAssembly instance now doesn't just contain the imported functions as
            JSObjects, it also has the corresponding import's instance and wasm
            entrypoint. This triples the space allocated per instance's imported
            function, but there shouldn't be that many imports. This has two upsides: it
            creates smaller and faster code, and makes is easier to disassociate
            embedder-specific things from embedder-neutral things. The small / faster
            win is in two places: B3 IR generator only needs offsetOfImportFunction for
            the call opcode (when the called index is an import) to know whether the
            import is wasm->wasm or wasm->embedder (this isn't known at compile-time
            because it's dependent on the import object), this is now done by seeing if
            that import function has an associated target instance (only wasm->wasm
            does); the other place is wasmBinding which uses offsetOfImportFunction to
            figure out the wasm->wasm target instance, and then gets
            WebAssemblyFunction::offsetOfWasmEntrypointLoadLocation to do a tail
            call. The disassociation comes because the target instance can be
            Wasm::Instance once we change what the Context is, and
            WasmEntrypointLoadLocation is already embedder-independent. As a next step I
            can move this tail allocation from JSWebAssemblyInstance to Wasm::Instance,
            and leave importFunction in as an opaque pointer which is embedder-specific,
            and in JS will remain WriteBarrier<JSObject>.
          - Rename VMEntryFrame to EntryFrame, and in many places pass a pointer to it
            around instead of VM. This is a first step in allowing entry frames which
            aren't stored on VM, but which are instead stored in an embedder-specific
            location. That change won't really affect JS except through code churn, but
            will allow WebAssembly to use some machinery in a generic manner without
            having a VM.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessGenerationState::emitExplicitExceptionHandler):
        * debugger/Debugger.cpp:
        (JSC::Debugger::stepOutOfFunction):
        (JSC::Debugger::returnEvent):
        (JSC::Debugger::unwindEvent):
        (JSC::Debugger::didExecuteProgram):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compileExceptionHandlers):
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::compileOSRExit):
        (JSC::DFG::OSRExit::compileExit):
        * dfg/DFGThunks.cpp:
        (JSC::DFG::osrEntryThunkGenerator):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::lower):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::wasmAwareLexicalGlobalObject):
        (JSC::CallFrame::callerFrame):
        (JSC::CallFrame::unsafeCallerFrame):
        * interpreter/CallFrame.h:
        (JSC::ExecState::callerFrame const):
        (JSC::ExecState::callerFrameOrEntryFrame const):
        (JSC::ExecState::unsafeCallerFrameOrEntryFrame const):
        * interpreter/FrameTracers.h:
        (JSC::NativeCallFrameTracer::NativeCallFrameTracer):
        (JSC::NativeCallFrameTracerWithRestore::NativeCallFrameTracerWithRestore):
        (JSC::NativeCallFrameTracerWithRestore::~NativeCallFrameTracerWithRestore):
        * interpreter/Interpreter.cpp:
        (JSC::UnwindFunctor::operator() const):
        (JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
        (JSC::Interpreter::unwind):
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::StackVisitor):
        (JSC::StackVisitor::gotoNextFrame):
        (JSC::StackVisitor::readNonInlinedFrame):
        (JSC::StackVisitor::Frame::dump const):
        * interpreter/StackVisitor.h:
        (JSC::StackVisitor::Frame::callerIsEntryFrame const):
        * interpreter/VMEntryRecord.h:
        (JSC::VMEntryRecord::prevTopEntryFrame):
        (JSC::VMEntryRecord::unsafePrevTopEntryFrame):
        (JSC::EntryFrame::vmEntryRecordOffset):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::restoreCalleeSavesFromEntryFrameCalleeSavesBuffer):
        (JSC::AssemblyHelpers::loadWasmContextInstance):
        (JSC::AssemblyHelpers::storeWasmContextInstance):
        (JSC::AssemblyHelpers::loadWasmContextInstanceNeedsMacroScratchRegister):
        (JSC::AssemblyHelpers::storeWasmContextInstanceNeedsMacroScratchRegister):
        (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBufferImpl):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
        (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBuffer):
        (JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToEntryFrameCalleeSavesBuffer):
        * jit/JIT.cpp:
        (JSC::JIT::emitEnterOptimizationCheck):
        (JSC::JIT::privateCompileExceptionHandlers):
        * jit/JITExceptions.cpp:
        (JSC::genericUnwind):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_throw):
        (JSC::JIT::emit_op_catch):
        (JSC::JIT::emitSlow_op_loop_hint):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_throw):
        (JSC::JIT::emit_op_catch):
        * jit/JITOperations.cpp:
        * jit/ThunkGenerators.cpp:
        (JSC::throwExceptionFromCallSlowPathGenerator):
        (JSC::nativeForGenerator):
        * jsc.cpp:
        (functionDumpCallFrame):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntThunks.cpp:
        (JSC::vmEntryRecord):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):
        * runtime/Options.h:
        * runtime/SamplingProfiler.cpp:
        (JSC::FrameWalker::FrameWalker):
        (JSC::FrameWalker::advanceToParentFrame):
        (JSC::SamplingProfiler::processUnverifiedStackTraces):
        * runtime/ThrowScope.cpp:
        (JSC::ThrowScope::~ThrowScope):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::~VM):
        * runtime/VM.h:
        (JSC::VM::topEntryFrameOffset):
        * runtime/VMTraps.cpp:
        (JSC::isSaneFrame):
        (JSC::VMTraps::tryInstallTrapBreakpoints):
        (JSC::VMTraps::invalidateCodeBlocksOnStack):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::restoreWasmContextInstance):
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
        (JSC::Wasm::B3IRGenerator::addGrowMemory):
        (JSC::Wasm::B3IRGenerator::addCurrentMemory):
        (JSC::Wasm::B3IRGenerator::addCall):
        (JSC::Wasm::B3IRGenerator::addCallIndirect):
        (JSC::Wasm::parseAndCompile):
        * wasm/WasmB3IRGenerator.h:
        * wasm/WasmBBQPlan.cpp:
        (JSC::Wasm::BBQPlan::BBQPlan):
        (JSC::Wasm::BBQPlan::compileFunctions):
        (JSC::Wasm::BBQPlan::complete):
        * wasm/WasmBBQPlan.h:
        * wasm/WasmBBQPlanInlines.h:
        (JSC::Wasm::BBQPlan::initializeCallees):
        * wasm/WasmBinding.cpp:
        (JSC::Wasm::wasmToWasm):
        * wasm/WasmBinding.h:
        * wasm/WasmCodeBlock.cpp:
        (JSC::Wasm::CodeBlock::create):
        (JSC::Wasm::CodeBlock::CodeBlock):
        (JSC::Wasm::CodeBlock::compileAsync):
        (JSC::Wasm::CodeBlock::setCompilationFinished):
        * wasm/WasmCodeBlock.h:
        (JSC::Wasm::CodeBlock::offsetOfImportStubs):
        (JSC::Wasm::CodeBlock::allocationSize):
        (JSC::Wasm::CodeBlock::importWasmToEmbedderStub):
        (JSC::Wasm::CodeBlock::offsetOfImportWasmToEmbedderStub):
        (JSC::Wasm::CodeBlock::wasmToJSCallStubForImport):
        (JSC::Wasm::CodeBlock::compilationFinished):
        (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace):
        (JSC::Wasm::CodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace):
        * wasm/WasmContext.cpp:
        (JSC::Wasm::Context::useFastTLS):
        (JSC::Wasm::Context::load const):
        (JSC::Wasm::Context::store):
        * wasm/WasmContext.h:
        * wasm/WasmEmbedder.h: Copied from Source/JavaScriptCore/wasm/WasmContext.h.
        * wasm/WasmFaultSignalHandler.cpp:
        * wasm/WasmFaultSignalHandler.h:
        * wasm/WasmFormat.h:
        * wasm/WasmInstance.cpp: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
        (JSC::Wasm::Instance::Instance):
        (JSC::Wasm::Instance::~Instance):
        (JSC::Wasm::Instance::extraMemoryAllocated const):
        * wasm/WasmInstance.h: Added.
        (JSC::Wasm::Instance::create):
        (JSC::Wasm::Instance::finalizeCreation):
        (JSC::Wasm::Instance::module):
        (JSC::Wasm::Instance::codeBlock):
        (JSC::Wasm::Instance::memory):
        (JSC::Wasm::Instance::table):
        (JSC::Wasm::Instance::loadI32Global const):
        (JSC::Wasm::Instance::loadI64Global const):
        (JSC::Wasm::Instance::loadF32Global const):
        (JSC::Wasm::Instance::loadF64Global const):
        (JSC::Wasm::Instance::setGlobal):
        (JSC::Wasm::Instance::offsetOfCachedStackLimit):
        (JSC::Wasm::Instance::cachedStackLimit const):
        (JSC::Wasm::Instance::setCachedStackLimit):
        * wasm/WasmMemory.cpp:
        (JSC::Wasm::Memory::Memory):
        (JSC::Wasm::Memory::create):
        (JSC::Wasm::Memory::~Memory):
        (JSC::Wasm::Memory::grow):
        * wasm/WasmMemory.h:
        (JSC::Wasm::Memory::offsetOfMemory):
        (JSC::Wasm::Memory::offsetOfSize):
        * wasm/WasmMemoryInformation.cpp:
        (JSC::Wasm::PinnedRegisterInfo::get):
        (JSC::Wasm::PinnedRegisterInfo::PinnedRegisterInfo):
        * wasm/WasmMemoryInformation.h:
        (JSC::Wasm::PinnedRegisterInfo::toSave const):
        * wasm/WasmMemoryMode.cpp: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
        (JSC::Wasm::makeString):
        * wasm/WasmMemoryMode.h: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
        * 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/WasmModuleParser.cpp:
        (JSC::Wasm::ModuleParser::parseTableHelper):
        * wasm/WasmOMGPlan.cpp:
        (JSC::Wasm::OMGPlan::OMGPlan):
        (JSC::Wasm::OMGPlan::runForIndex):
        * wasm/WasmOMGPlan.h:
        * wasm/WasmPageCount.h:
        (JSC::Wasm::PageCount::isValid const):
        * wasm/WasmPlan.cpp:
        (JSC::Wasm::Plan::Plan):
        (JSC::Wasm::Plan::runCompletionTasks):
        (JSC::Wasm::Plan::addCompletionTask):
        (JSC::Wasm::Plan::tryRemoveContextAndCancelIfLast):
        * wasm/WasmPlan.h:
        (JSC::Wasm::Plan::dontFinalize):
        * wasm/WasmSignature.cpp:
        * wasm/WasmSignature.h:
        * wasm/WasmTable.cpp: Added.
        (JSC::Wasm::Table::create):
        (JSC::Wasm::Table::~Table):
        (JSC::Wasm::Table::Table):
        (JSC::Wasm::Table::grow):
        (JSC::Wasm::Table::clearFunction):
        (JSC::Wasm::Table::setFunction):
        * wasm/WasmTable.h: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyTable.h.
        (JSC::Wasm::Table::maximum const):
        (JSC::Wasm::Table::size const):
        (JSC::Wasm::Table::offsetOfSize):
        (JSC::Wasm::Table::offsetOfFunctions):
        (JSC::Wasm::Table::offsetOfInstances):
        (JSC::Wasm::Table::isValidSize):
        * wasm/WasmThunks.cpp:
        (JSC::Wasm::throwExceptionFromWasmThunkGenerator):
        (JSC::Wasm::triggerOMGTierUpThunkGenerator):
        (JSC::Wasm::Thunks::setThrowWasmException):
        (JSC::Wasm::Thunks::throwWasmException):
        * wasm/WasmThunks.h:
        * wasm/WasmWorklist.cpp:
        (JSC::Wasm::Worklist::stopAllPlansForContext):
        * wasm/WasmWorklist.h:
        * wasm/js/JSToWasm.cpp: Added.
        (JSC::Wasm::createJSToWasmWrapper):
        * wasm/js/JSToWasm.h: Copied from Source/JavaScriptCore/wasm/WasmBinding.h.
        * wasm/js/JSWebAssembly.cpp: Renamed from Source/JavaScriptCore/wasm/JSWebAssembly.cpp.
        * wasm/js/JSWebAssembly.h: Renamed from Source/JavaScriptCore/wasm/JSWebAssembly.h.
        * wasm/js/JSWebAssemblyCodeBlock.cpp:
        (JSC::JSWebAssemblyCodeBlock::create):
        (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock):
        * wasm/js/JSWebAssemblyCodeBlock.h:
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
        (JSC::JSWebAssemblyInstance::finishCreation):
        (JSC::JSWebAssemblyInstance::visitChildren):
        (JSC::JSWebAssemblyInstance::finalizeCreation):
        (JSC::JSWebAssemblyInstance::create):
        * wasm/js/JSWebAssemblyInstance.h:
        (JSC::JSWebAssemblyInstance::instance):
        (JSC::JSWebAssemblyInstance::context const):
        (JSC::JSWebAssemblyInstance::table):
        (JSC::JSWebAssemblyInstance::webAssemblyToJSCallee):
        (JSC::JSWebAssemblyInstance::setMemory):
        (JSC::JSWebAssemblyInstance::offsetOfTail):
        (JSC::JSWebAssemblyInstance::importFunctionInfo):
        (JSC::JSWebAssemblyInstance::offsetOfTargetInstance):
        (JSC::JSWebAssemblyInstance::offsetOfWasmEntrypoint):
        (JSC::JSWebAssemblyInstance::offsetOfImportFunction):
        (JSC::JSWebAssemblyInstance::importFunction):
        (JSC::JSWebAssemblyInstance::internalMemory):
        (JSC::JSWebAssemblyInstance::wasmCodeBlock const):
        (JSC::JSWebAssemblyInstance::offsetOfWasmTable):
        (JSC::JSWebAssemblyInstance::offsetOfCallee):
        (JSC::JSWebAssemblyInstance::offsetOfGlobals):
        (JSC::JSWebAssemblyInstance::offsetOfWasmCodeBlock):
        (JSC::JSWebAssemblyInstance::offsetOfWasmMemory):
        (JSC::JSWebAssemblyInstance::cachedStackLimit const):
        (JSC::JSWebAssemblyInstance::setCachedStackLimit):
        (JSC::JSWebAssemblyInstance::wasmMemory):
        (JSC::JSWebAssemblyInstance::wasmModule):
        (JSC::JSWebAssemblyInstance::allocationSize):
        (JSC::JSWebAssemblyInstance::module const):
        * wasm/js/JSWebAssemblyMemory.cpp:
        (JSC::JSWebAssemblyMemory::create):
        (JSC::JSWebAssemblyMemory::adopt):
        (JSC::JSWebAssemblyMemory::JSWebAssemblyMemory):
        (JSC::JSWebAssemblyMemory::grow):
        (JSC::JSWebAssemblyMemory::growSuccessCallback):
        * wasm/js/JSWebAssemblyMemory.h:
        * wasm/js/JSWebAssemblyModule.cpp:
        (JSC::JSWebAssemblyModule::moduleInformation const):
        (JSC::JSWebAssemblyModule::exportSymbolTable const):
        (JSC::JSWebAssemblyModule::signatureIndexFromFunctionIndexSpace const):
        (JSC::JSWebAssemblyModule::callee const):
        (JSC::JSWebAssemblyModule::codeBlock):
        (JSC::JSWebAssemblyModule::module):
        * wasm/js/JSWebAssemblyModule.h:
        * wasm/js/JSWebAssemblyTable.cpp:
        (JSC::JSWebAssemblyTable::create):
        (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
        (JSC::JSWebAssemblyTable::visitChildren):
        (JSC::JSWebAssemblyTable::grow):
        (JSC::JSWebAssemblyTable::getFunction):
        (JSC::JSWebAssemblyTable::clearFunction):
        (JSC::JSWebAssemblyTable::setFunction):
        * wasm/js/JSWebAssemblyTable.h:
        (JSC::JSWebAssemblyTable::isValidSize):
        (JSC::JSWebAssemblyTable::maximum const):
        (JSC::JSWebAssemblyTable::size const):
        (JSC::JSWebAssemblyTable::table):
        * wasm/js/WasmToJS.cpp: Copied from Source/JavaScriptCore/wasm/WasmBinding.cpp.
        (JSC::Wasm::materializeImportJSCell):
        (JSC::Wasm::wasmToJS):
        (JSC::Wasm::wasmToJSException):
        * wasm/js/WasmToJS.h: Copied from Source/JavaScriptCore/wasm/WasmBinding.h.
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction):
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::constructJSWebAssemblyInstance):
        * wasm/js/WebAssemblyMemoryConstructor.cpp:
        (JSC::constructJSWebAssemblyMemory):
        * wasm/js/WebAssemblyMemoryPrototype.cpp:
        (JSC::webAssemblyMemoryProtoFuncGrow):
        * wasm/js/WebAssemblyModuleConstructor.cpp:
        (JSC::constructJSWebAssemblyModule):
        (JSC::WebAssemblyModuleConstructor::createModule):
        * wasm/js/WebAssemblyModuleConstructor.h:
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::link):
        (JSC::WebAssemblyModuleRecord::evaluate):
        * wasm/js/WebAssemblyPrototype.cpp:
        (JSC::webAssemblyCompileFunc):
        (JSC::instantiate):
        (JSC::compileAndInstantiate):
        (JSC::webAssemblyValidateFunc):
        * wasm/js/WebAssemblyTableConstructor.cpp:
        (JSC::constructJSWebAssemblyTable):
        * wasm/js/WebAssemblyWrapperFunction.cpp:
        (JSC::WebAssemblyWrapperFunction::create):

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

        VMTraps shouldn't crash if it sees an exception it doesn't understand.
        https://bugs.webkit.org/show_bug.cgi?id=177780

        Reviewed by Mark Lam.

        VMTraps could see a JIT breakpoint (SegV) for any number of
        reasons it doesn't understand. e.g.  a bug in JIT code, Wasm OOB,
        etc. This patch makes it handle that case gracefully. It's worth
        noting that this means there's no way to know if, due to a bug, we
        didn't accurately track all the VMTraps we installed. I'm not sure
        if there is a good solution to that problem though.

        * runtime/VMTraps.cpp:

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

        Unreviewed. Add missing exception check for the custom-get-set-inline-caching-one-level-up-proto-chain.js
        test that I added. It uncovered a pre-existing missing exception check.

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

2017-10-02  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Include Beacon and Ping requests in Network tab
        https://bugs.webkit.org/show_bug.cgi?id=177641
        <rdar://problem/33086839>

        Reviewed by Chris Dumez.

        * inspector/protocol/Page.json:
        Include new "Beacon" and "Ping" resource types.

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

        ChakraCore/test/Function/apply3.js is resulting wrong result in x86_64
        https://bugs.webkit.org/show_bug.cgi?id=175642

        Reviewed by Darin Adler.

        According JS spec, the ToLength operation[1] has a range of 0..(2^53)
        - 1. In Interpreter.cpp::sizeFrameForVarargs, the call to
        sizeOfVarargs() was being assigned to "unsigned length", forcing a
        type cast that results in different value among architectures JSC supports.
        For instance, in x86_64 "4294967295 + 1" results in 0, while in ARMv6 it
        results 4294967295. This patch is changing "sizeOfVarargs" to clamp the
        result from "toLength" to unsigned and then get desired behavior for
        all supported platforms.

        [1] - https://tc39.github.io/ecma262/#sec-tolength

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

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

        Unreviewed. Fix debug assertion after r222671. 

        JSTestCustomGetterSetter::finishCreation needs to call its base's finishCreation implementation.

        * jsc.cpp:
        (JSTestCustomGetterSetter::finishCreation):

2017-10-01  Commit Queue  <commit-queue@webkit.org>

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

        "It regressed JetStream by 2% on iOS caused by a 50%
        regression on the bigfib subtest" (Requested by saamyjoon on
        #webkit).

        Reverted changeset:

        "Add Above/Below comparisons for UInt32 patterns"
        https://bugs.webkit.org/show_bug.cgi?id=177281
        http://trac.webkit.org/changeset/222564

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

        [DFG] Support ArrayPush with multiple args
        https://bugs.webkit.org/show_bug.cgi?id=175823

        Reviewed by Saam Barati.

        Reviewed by Saam Barati.

        This patch implements ArrayPush(with multiple arguments) in DFG and FTL. Previously, they are not handled
        by ArrayPush. Then they go to generic direct call to Array#push and it does in slow path. This patch
        extends ArrayPush to push multiple arguments in a bulk push manner.

        The problem of ArrayPush is that we need to perform ArrayPush atomically: If OSR exit occurs in the middle
        of ArrayPush, we incorrectly push pushed elements twice. Once we start pushing values, we should not exit.
        But we do not want to iterate elements twice, once for type checks and once for actually pushing it. It
        could move elements between registers and memory back and forth.

        This patch achieves the above goal by separating type checks from ArrayPush. When starting ArrayPush, type
        checks for elements are already done by separately emitted Check nodes.

        We also add JSArray::pushInline for DFG operations just calling JSArray::push. And we also use it in
        arrayProtoFuncPush's fast path.

        This patch significantly improves performance of `push(multiple args)`.

                                            baseline                  patched
            Microbenchmarks:
                array-push-0            461.8455+-28.9995    ^    151.3438+-6.5653        ^ definitely 3.0516x faster
                array-push-1            133.8845+-7.0349     ?    136.1775+-5.8327        ? might be 1.0171x slower
                array-push-2            675.6555+-13.4645    ^    145.8747+-6.4621        ^ definitely 4.6318x faster
                array-push-3            849.5284+-15.2540    ^    253.4421+-9.1249        ^ definitely 3.3520x faster

                                            baseline                  patched
            SixSpeed:
                spread-literal.es5       90.3482+-6.6514     ^     24.8123+-2.3304        ^ definitely 3.6413x faster

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArrayPush):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStoreBarrierInsertionPhase.cpp:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileArrayPush):
        * jit/JITOperations.h:
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncPush):
        * runtime/JSArray.cpp:
        (JSC::JSArray::push):
        * runtime/JSArray.h:
        * runtime/JSArrayInlines.h:
        (JSC::JSArray::pushInline):

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

        Custom GetterSetterAccessCase does not use the correct slotBase when making call
        https://bugs.webkit.org/show_bug.cgi?id=177639

        Reviewed by Geoffrey Garen.

        The bug occurred when you had a custom set value. Custom set/get
        values are passed the property holder, not the base of the access.
        If we had an object chain like this:
        o = {__proto__: thingWithCustomSetValue}
        
        We would end up not providing thingWithCustomSetValue as the argument
        to the PutValueFunc. The reason is, we would use generateConditionsForPrototypePropertyHitCustom
        for custom sets. This would return to us an empty ConditionSet, because
        the property holder was only one level up the prototype chain. The reason
        is, it didn't generate a condition for the slot holder, because the
        protocol for custom set/get is that if an object responds to a custom
        setter/getter, it will continue to respond to that getter/setter for
        the lifetime of that object. Therefore, it's not strictly necessary to
        generate an OPC for the slot base for custom accesses. However, AccessCase
        uses !m_conditionSet.isEmtpy() to indicate that the IC is doing a prototype
        access. With the above object "o", we were doing a prototype access, but we
        had an empty condition set. This lead us to passing the base instead of
        the property holder to the custom set value function, which is incorrect.
        
        With custom getters, we never called to into the generateConditionsForPrototypePropertyHitCustom
        API. Gets would always call into generateConditionsForPrototypePropertyHit, which
        will generate an OPC on the slot base, even if it isn't strictly necessary for custom accessors.
        This patch simply removes generateConditionsForPrototypePropertyHitCustom
        and aligns the set case with the get case. It makes us properly detect
        when we're doing a prototype access with the above object "o". If we find
        that generateConditionsForPrototypePropertyHitCustom was a worthwhile
        optimization to have, we can re-introduce it. We'll just need to pipe through
        a new notion of when we're doing prototype accesses that doesn't rely solely
        on !m_conditionSet.isEmpty().

        * bytecode/ObjectPropertyConditionSet.cpp:
        (JSC::generateConditionsForPrototypePropertyHitCustom): Deleted.
        * bytecode/ObjectPropertyConditionSet.h:
        * jit/Repatch.cpp:
        (JSC::tryCachePutByID):
        * jsc.cpp:
        (JSTestCustomGetterSetter::JSTestCustomGetterSetter):
        (JSTestCustomGetterSetter::create):
        (JSTestCustomGetterSetter::createStructure):
        (customGetAccessor):
        (customGetValue):
        (customSetAccessor):
        (customSetValue):
        (JSTestCustomGetterSetter::finishCreation):
        (GlobalObject::finishCreation):
        (functionLoadGetterFromGetterSetter):
        (functionCreateCustomTestGetterSetter):
        * runtime/PropertySlot.h:
        (JSC::PropertySlot::setCustomGetterSetter):

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

        Unreviewed, rolling out r222563, r222565, and r222581.
        https://bugs.webkit.org/show_bug.cgi?id=177675

        "It causes a crash when playing youtube videos" (Requested by
        saamyjoon on #webkit).

        Reverted changesets:

        "[DFG] Support ArrayPush with multiple args"
        https://bugs.webkit.org/show_bug.cgi?id=175823
        http://trac.webkit.org/changeset/222563

        "Unreviewed, build fix after r222563"
        https://bugs.webkit.org/show_bug.cgi?id=175823
        http://trac.webkit.org/changeset/222565

        "Unreviewed, fix x86 breaking due to exhausted registers"
        https://bugs.webkit.org/show_bug.cgi?id=175823
        http://trac.webkit.org/changeset/222581

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

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

        causes crashes on iOS (Requested by pizlo-mbp on #webkit).

        Reverted changeset:

        "Enable gigacage on iOS"
        https://bugs.webkit.org/show_bug.cgi?id=177586
        http://trac.webkit.org/changeset/222625

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

        test262: Unexpected passes after r222617 and r222618.
        https://bugs.webkit.org/show_bug.cgi?id=177622
        <rdar://problem/34725960>

        Reviewed by Saam Barati.

        Now that these tests are marked as "normal", we will run them and discover a few
        missing exception checks.  This patch also adds those missing exception checks.

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

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

        Add missing exception checks and book-keeping for exception check validation.
        https://bugs.webkit.org/show_bug.cgi?id=177609
        <rdar://problem/34717972>

        Reviewed by Keith Miller.

        This resolves exception check validation failures when running test262 tests and
        a few other tests.

        * API/APIUtils.h:
        (handleExceptionIfNeeded):
        * API/JSObjectRef.cpp:
        (JSObjectMakeFunction):
        (JSObjectMakeArray):
        (JSObjectMakeDate):
        (JSObjectMakeError):
        (JSObjectMakeRegExp):
        (JSObjectSetPrototype):
        (JSObjectGetProperty):
        (JSObjectSetProperty):
        (JSObjectGetPropertyAtIndex):
        (JSObjectSetPropertyAtIndex):
        (JSObjectDeleteProperty):
        (JSObjectCallAsFunction):
        (JSObjectCallAsConstructor):
        * API/JSTypedArray.cpp:
        (JSObjectMakeTypedArray):
        (JSObjectMakeTypedArrayWithBytesNoCopy):
        (JSObjectMakeTypedArrayWithArrayBuffer):
        (JSObjectMakeTypedArrayWithArrayBufferAndOffset):
        (JSObjectMakeArrayBufferWithBytesNoCopy):
        * API/JSValueRef.cpp:
        (JSValueIsEqual):
        (JSValueIsInstanceOfConstructor):
        (JSValueCreateJSONString):
        (JSValueToNumber):
        (JSValueToStringCopy):
        (JSValueToObject):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::executeProgram):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncIndexOf):
        (JSC::arrayProtoFuncLastIndexOf):
        * runtime/DatePrototype.cpp:
        (JSC::fillStructuresUsingTimeArgs):
        (JSC::setNewValueFromDateArgs):
        (JSC::dateProtoFuncSetYear):
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::constructGenericTypedArrayViewWithArguments):
        * runtime/JSModuleEnvironment.cpp:
        (JSC::JSModuleEnvironment::put):
        * runtime/ProgramExecutable.cpp:
        (JSC::ProgramExecutable::initializeGlobalProperties):
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::toStringName):
        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncCharAt):
        (JSC::stringProtoFuncCharCodeAt):
        (JSC::stringProtoFuncIndexOf):
        (JSC::stringProtoFuncLastIndexOf):
        (JSC::stringProtoFuncSlice):
        (JSC::stringProtoFuncSplitFast):
        (JSC::stringProtoFuncSubstr):

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

        REGRESSION(210837): RegExp containing failed non-zero minimum greedy groups incorrectly match
        https://bugs.webkit.org/show_bug.cgi?id=177570

        Reviewed by Filip Pizlo.

        The change in r210837 neglected to change the check in Interpreter::backtrackParentheses() that
        greedy parenthesis have backtracked as far as possible.  Prior to r210837, non-zero minimum greedy
        parenthesis were factored into a fixed component and a zero-based variable component.  After
        r210837, the variable component is not zero based and the check needs to compare the
        backTrack->matchAmount with the quantity iminimum count.

        * yarr/YarrInterpreter.cpp:
        (JSC::Yarr::Interpreter::backtrackParentheses):

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

        Heap out of bounds read in JSC::Yarr::Parser<JSC::Yarr::SyntaxChecker, unsigned char>::peek()
        https://bugs.webkit.org/show_bug.cgi?id=177423

        Reviewed by Mark Lam.

        Updated fix that restructures that changes the do ... while to a while and adds another
        atEndOfPattern() check before looking for the first named group identifier character.

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

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

        JSArray::canFastCopy() should fail if the source and destination arrays are the same.
        https://bugs.webkit.org/show_bug.cgi?id=177584
        <rdar://problem/34463903>

        Reviewed by Saam Barati.

        If the source and destination arrays are the same, we may be copying overlapping
        regions.  Hence, we need to take the slow path.

        * runtime/JSArrayInlines.h:
        (JSC::JSArray::canFastCopy):

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

        Propagate hasBeenFlattenedBefore in Structure's transition constructor and fix our for-in caching to fail when the prototype chain has an object with a dictionary structure
        https://bugs.webkit.org/show_bug.cgi?id=177523

        Reviewed by Mark Lam.

        There was a bug in Structure's transition constructor where it didn't
        propagate forward the hasBeenFlattenedBefore bit. In practice, this meant
        that every time we asked a dictionary structure if it has been flattened
        before, it would return false. This patch fixes this bug. It also fixes
        a bug that this uncovers in our for-in implementation. Our implementation
        would cache the property name enumerator even when the prototype chain
        included a structure that is as dictionary. This is wrong because that
        prototype object may add properties without transitioning, and the for-in
        loop would vend a stale set of prototype properties.

        * jit/JITOperations.cpp:
        * runtime/JSPropertyNameEnumerator.h:
        (JSC::propertyNameEnumerator):
        * runtime/Structure.cpp:
        (JSC::Structure::Structure):
        (JSC::Structure::canCachePropertyNameEnumerator const):

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

        Yarr::Parser::tryConsumeGroupName() should check for the end of the pattern.
        https://bugs.webkit.org/show_bug.cgi?id=177423
        <rdar://problem/34621320>

        Reviewed by Keith Miller.

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

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

        Unreviewed, fix x86 breaking due to exhausted registers
        https://bugs.webkit.org/show_bug.cgi?id=175823

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):

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

        Unreviewed, build fix after r222563
        https://bugs.webkit.org/show_bug.cgi?id=175823

        * runtime/JSArrayInlines.h:

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

        Add Above/Below comparisons for UInt32 patterns
        https://bugs.webkit.org/show_bug.cgi?id=177281

        Reviewed by Saam Barati.

        Sometimes, we would like to have UInt32 operations in JS. While VM does
        not support UInt32 nicely, VM supports efficient Int32 operations. As long
        as signedness does not matter, we can just perform Int32 operations instead
        and recognize its bit pattern as UInt32.

        But of course, some operations respect signedness. The most frequently
        used one is comparison. Octane/zlib performs UInt32 comparison by performing
        `val >>> 0`. It emits op_urshift and op_unsigned. op_urshift produces
        UInt32 in Int32 form. And op_unsigned will generate Double value if
        the generated Int32 is < 0 (which should be UInt32).

        There is a chance for optimization. The given code pattern is the following.

            op_unsigned(op_urshift(@1)) lessThan:< op_unsigned(op_urshift(@2))

        This can be converted to the following.

            op_urshift(@1) below:< op_urshift(@2)

        The above conversion is nice since

        1. We can avoid op_unsigned. This could be unsignedness check in DFG. Since
        this check depends on the value of Int32, dropping this check is not as easy as
        removing Int32 edge filters.

        2. We can perform unsigned comparison in Int32 form. We do not need to convert
        them to DoubleRep.

        Since the above comparison exists in Octane/zlib's *super* hot path, dropping
        op_unsigned offers huge win.

        At first, my patch attempts to convert the above thing in DFG pipeline.
        However it poses several problems.

        1. MovHint is not well removed. It makes UInt32ToNumber (which is for op_unsigned) live.
        2. UInt32ToNumber could cause an OSR exit. So if we have the following nodes,

            2: UInt32ToNumber(@0)
            3: MovHint(@2, xxx)
            4: UInt32ToNumber(@1)
            5: MovHint(@1, xxx)

        we could drop @5's MovHint. But @3 is difficult since @4 can exit.

        So, instead, we start introducing a simple optimization in the bytecode compiler.
        It performs pattern matching for op_urshift and comparison to drop op_unsigned.
        We adds op_below and op_above families to bytecodes. They only accept Int32 and
        perform unsigned comparison.

        This offers 4% performance improvement in Octane/zlib.

                                    baseline                  patched

        zlib           x2     431.07483+-16.28434       414.33407+-9.38375         might be 1.0404x faster

        * bytecode/BytecodeDumper.cpp:
        (JSC::BytecodeDumper<Block>::printCompareJump):
        (JSC::BytecodeDumper<Block>::dumpBytecode):
        * bytecode/BytecodeDumper.h:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/Opcode.h:
        (JSC::isBranch):
        * bytecode/PreciseJumpTargetsInlines.h:
        (JSC::extractStoredJumpTargetsForBytecodeOffset):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitJumpIfTrue):
        (JSC::BytecodeGenerator::emitJumpIfFalse):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BinaryOpNode::emitBytecode):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGIntegerRangeOptimizationPhase.cpp:
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCompareUnsigned):
        * 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):
        * dfg/DFGValidate.cpp:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareBelow):
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareBelowEq):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_below):
        (JSC::JIT::emit_op_beloweq):
        (JSC::JIT::emit_op_jbelow):
        (JSC::JIT::emit_op_jbeloweq):
        (JSC::JIT::emit_compareUnsignedAndJump):
        (JSC::JIT::emit_compareUnsigned):
        * jit/JITArithmetic32_64.cpp:
        (JSC::JIT::emit_compareUnsignedAndJump):
        (JSC::JIT::emit_compareUnsigned):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * parser/Nodes.h:
        (JSC::ExpressionNode::isBinaryOpNode const):

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

        [DFG] Support ArrayPush with multiple args
        https://bugs.webkit.org/show_bug.cgi?id=175823

        Reviewed by Saam Barati.

        This patch implements ArrayPush(with multiple arguments) in DFG and FTL. Previously, they are not handled
        by ArrayPush. Then they go to generic direct call to Array#push and it does in slow path. This patch
        extends ArrayPush to push multiple arguments in a bulk push manner.

        The problem of ArrayPush is that we need to perform ArrayPush atomically: If OSR exit occurs in the middle
        of ArrayPush, we incorrectly push pushed elements twice. Once we start pushing values, we should not exit.
        But we do not want to iterate elements twice, once for type checks and once for actually pushing it. It
        could move elements between registers and memory back and forth.

        This patch achieves the above goal by separating type checks from ArrayPush. When starting ArrayPush, type
        checks for elements are already done by separately emitted Check nodes.

        We also add JSArray::pushInline for DFG operations just calling JSArray::push. And we also use it in
        arrayProtoFuncPush's fast path.

        This patch significantly improves performance of `push(multiple args)`.

                                            baseline                  patched
            Microbenchmarks:
                array-push-0            461.8455+-28.9995    ^    151.3438+-6.5653        ^ definitely 3.0516x faster
                array-push-1            133.8845+-7.0349     ?    136.1775+-5.8327        ? might be 1.0171x slower
                array-push-2            675.6555+-13.4645    ^    145.8747+-6.4621        ^ definitely 4.6318x faster
                array-push-3            849.5284+-15.2540    ^    253.4421+-9.1249        ^ definitely 3.3520x faster

                                            baseline                  patched
            SixSpeed:
                spread-literal.es5       90.3482+-6.6514     ^     24.8123+-2.3304        ^ definitely 3.6413x faster

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArrayPush):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStoreBarrierInsertionPhase.cpp:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileArrayPush):
        * jit/JITOperations.h:
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncPush):
        * runtime/JSArray.cpp:
        (JSC::JSArray::push):
        * runtime/JSArray.h:
        * runtime/JSArrayInlines.h:
        (JSC::JSArray::pushInline):

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

        Web Inspector: Remove unused parameter of Page.reload
        https://bugs.webkit.org/show_bug.cgi?id=177522

        Reviewed by Matt Baker.

        * inspector/protocol/Page.json:

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

        Put g_gigacageBasePtr into its own page and make it read-only
        https://bugs.webkit.org/show_bug.cgi?id=174972

        Reviewed by Michael Saboff.
        
        C++ code doesn't have to know about this change. That includes C++ code that generates JIT code.
        
        But the offline assembler now needs to know about how to load from offsets of global variables.
        This turned out to be easy to support by extending the existing expression support.

        * llint/LowLevelInterpreter64.asm:
        * offlineasm/ast.rb:
        * offlineasm/parser.rb:
        * offlineasm/transform.rb:
        * offlineasm/x86.rb:

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

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

        Break the High Sierra build (Requested by yusukesuzuki on
        #webkit).

        Reverted changeset:

        "Add Above/Below comparisons for UInt32 patterns"
        https://bugs.webkit.org/show_bug.cgi?id=177281
        http://trac.webkit.org/changeset/222518

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

        Add Above/Below comparisons for UInt32 patterns
        https://bugs.webkit.org/show_bug.cgi?id=177281

        Reviewed by Saam Barati.

        Sometimes, we would like to have UInt32 operations in JS. While VM does
        not support UInt32 nicely, VM supports efficient Int32 operations. As long
        as signedness does not matter, we can just perform Int32 operations instead
        and recognize its bit pattern as UInt32.

        But of course, some operations respect signedness. The most frequently
        used one is comparison. Octane/zlib performs UInt32 comparison by performing
        `val >>> 0`. It emits op_urshift and op_unsigned. op_urshift produces
        UInt32 in Int32 form. And op_unsigned will generate Double value if
        the generated Int32 is < 0 (which should be UInt32).

        There is a chance for optimization. The given code pattern is the following.

            op_unsigned(op_urshift(@1)) lessThan:< op_unsigned(op_urshift(@2))

        This can be converted to the following.

            op_urshift(@1) below:< op_urshift(@2)

        The above conversion is nice since

        1. We can avoid op_unsigned. This could be unsignedness check in DFG. Since
        this check depends on the value of Int32, dropping this check is not as easy as
        removing Int32 edge filters.

        2. We can perform unsigned comparison in Int32 form. We do not need to convert
        them to DoubleRep.

        Since the above comparison exists in Octane/zlib's *super* hot path, dropping
        op_unsigned offers huge win.

        At first, my patch attempts to convert the above thing in DFG pipeline.
        However it poses several problems.

        1. MovHint is not well removed. It makes UInt32ToNumber (which is for op_unsigned) live.
        2. UInt32ToNumber could cause an OSR exit. So if we have the following nodes,

            2: UInt32ToNumber(@0)
            3: MovHint(@2, xxx)
            4: UInt32ToNumber(@1)
            5: MovHint(@1, xxx)

        we could drop @5's MovHint. But @3 is difficult since @4 can exit.

        So, instead, we start introducing a simple optimization in the bytecode compiler.
        It performs pattern matching for op_urshift and comparison to drop op_unsigned.
        We adds op_below and op_above families to bytecodes. They only accept Int32 and
        perform unsigned comparison.

        This offers 4% performance improvement in Octane/zlib.

                                    baseline                  patched

        zlib           x2     431.07483+-16.28434       414.33407+-9.38375         might be 1.0404x faster

        * bytecode/BytecodeDumper.cpp:
        (JSC::BytecodeDumper<Block>::printCompareJump):
        (JSC::BytecodeDumper<Block>::dumpBytecode):
        * bytecode/BytecodeDumper.h:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/Opcode.h:
        (JSC::isBranch):
        * bytecode/PreciseJumpTargetsInlines.h:
        (JSC::extractStoredJumpTargetsForBytecodeOffset):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitJumpIfTrue):
        (JSC::BytecodeGenerator::emitJumpIfFalse):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BinaryOpNode::emitBytecode):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGIntegerRangeOptimizationPhase.cpp:
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCompareUnsigned):
        * 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):
        * dfg/DFGValidate.cpp:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareBelow):
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareBelowEq):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_below):
        (JSC::JIT::emit_op_beloweq):
        (JSC::JIT::emit_op_jbelow):
        (JSC::JIT::emit_op_jbeloweq):
        (JSC::JIT::emit_compareUnsignedAndJump):
        (JSC::JIT::emit_compareUnsigned):
        * jit/JITArithmetic32_64.cpp:
        (JSC::JIT::emit_compareUnsignedAndJump):
        (JSC::JIT::emit_compareUnsigned):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * parser/Nodes.h:
        (JSC::ExpressionNode::isBinaryOpNode const):

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

        JSC build should use unified sources for derived sources
        https://bugs.webkit.org/show_bug.cgi?id=177421

        Reviewed by JF Bastien.

        This patch make a couple of changes:

        1) Make derived sources added to relevant bundles. I was going to add JSCBuiltins.cpp
        to runtime but that kept breaking the windows build. I'll get back to it later
        2) Move the derived location of some sources both for clarity and for ease of use.
        3) Make auto generator scripts able to create directories if needed.
        4) Move some scripts from the top level of the JavaScriptCore directory to a
        more appropriate directory.
        5) Move some CMake generation commands around for clarity.

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Scripts/lazywriter.py:
        (LazyFileWriter.close):
        * Sources.txt:
        * inspector/scripts/generate-inspector-protocol-bindings.py:
        (IncrementalFileWriter.close):
        * yarr/create_regex_tables: Renamed from Source/JavaScriptCore/create_regex_tables.
        * yarr/generateYarrCanonicalizeUnicode: Renamed from Source/JavaScriptCore/generateYarrCanonicalizeUnicode.

2017-09-26  Zan Dobersek  <zdobersek@igalia.com>

        Support building JavaScriptCore with the Bionic C library
        https://bugs.webkit.org/show_bug.cgi?id=177427

        Reviewed by Michael Catanzaro.

        When compiling with the Bionic C library, the MachineContext.h header
        should enable the same code paths that are enabled for the GNU C library.

        The Bionic C library defines the __BIONIC__ macro, but unlike other C
        libraries that mimic the GNU one, it doesn't define __GLIBC__. So the
        __BIONIC__ macro checks have to match the __GLIBC__ ones.

        * runtime/MachineContext.h:
        (JSC::MachineContext::stackPointer):
        (JSC::MachineContext::framePointer):
        (JSC::MachineContext::instructionPointer):
        (JSC::MachineContext::argumentPointer<1>):
        (JSC::MachineContext::llintInstructionPointer):

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

        Web Inspector: move Console.addInspectedNode to DOM.setInspectedNode
        https://bugs.webkit.org/show_bug.cgi?id=176827

        Reviewed by Joseph Pecoraro.

        * inspector/agents/InspectorConsoleAgent.h:

        * inspector/agents/JSGlobalObjectConsoleAgent.h:
        * inspector/agents/JSGlobalObjectConsoleAgent.cpp:
        (Inspector::JSGlobalObjectConsoleAgent::addInspectedNode): Deleted.

        * inspector/protocol/Console.json:
        * inspector/protocol/DOM.json:

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

        Unreviewed, rebaseline builtins generator tests after r222473.

        * Scripts/tests/builtins/expected/WebCoreJSBuiltins.h-result:

2017-09-25  Alex Christensen  <achristensen@webkit.org>

        Make Attribute an enum class
        https://bugs.webkit.org/show_bug.cgi?id=177414

        Reviewed by Yusuke Suzuki.

        I've had enough of these naming collisions.  This is what enum classes are for.
        Unfortunately a lot of static_cast<unsigned> is necessary until those functions take
        an OptionSet<Attribute> instead of an unsigned parameter, but this is a big step
        towards where we ought to be.

        * API/JSCallbackObjectFunctions.h:
        (JSC::JSCallbackObject<Parent>::getOwnPropertySlot):
        * API/JSObjectRef.cpp:
        (JSObjectMakeConstructor):
        * Scripts/builtins/builtins_generate_internals_wrapper_implementation.py:
        (BuiltinsInternalsWrapperImplementationGenerator.property_macro):
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFromLLInt):
        (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
        (JSC::GetByIdStatus::computeFor):
        * bytecode/PropertyCondition.cpp:
        (JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint const):
        (JSC::PropertyCondition::isValidValueForAttributes):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFor):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::instantiateLexicalVariables):
        (JSC::BytecodeGenerator::variable):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::Variable::isReadOnly const):
        (JSC::Variable::setIsReadOnly):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::PropertyListNode::emitBytecode):
        * create_hash_table:
        * debugger/DebuggerScope.cpp:
        (JSC::DebuggerScope::getOwnPropertySlot):
        * dfg/DFGOperations.cpp:
        * inspector/JSInjectedScriptHostPrototype.cpp:
        (Inspector::JSInjectedScriptHostPrototype::finishCreation):
        * inspector/JSJavaScriptCallFramePrototype.cpp:
        (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
        * jit/Repatch.cpp:
        (JSC::tryCacheGetByID):
        * jsc.cpp:
        (WTF::CustomGetter::getOwnPropertySlot):
        (WTF::RuntimeArray::getOwnPropertySlot):
        (WTF::RuntimeArray::getOwnPropertySlotByIndex):
        (WTF::DOMJITGetter::finishCreation):
        (WTF::DOMJITGetterComplex::finishCreation):
        (WTF::DOMJITFunctionObject::finishCreation):
        (WTF::DOMJITCheckSubClassObject::finishCreation):
        (GlobalObject::finishCreation):
        * runtime/ArrayConstructor.cpp:
        (JSC::ArrayConstructor::finishCreation):
        * runtime/ArrayIteratorPrototype.cpp:
        (JSC::ArrayIteratorPrototype::finishCreation):
        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation):
        * runtime/AsyncFromSyncIteratorPrototype.cpp:
        (JSC::AsyncFromSyncIteratorPrototype::finishCreation):
        * runtime/AsyncFunctionConstructor.cpp:
        (JSC::AsyncFunctionConstructor::finishCreation):
        * runtime/AsyncFunctionPrototype.cpp:
        (JSC::AsyncFunctionPrototype::finishCreation):
        * runtime/AsyncGeneratorFunctionConstructor.cpp:
        (JSC::AsyncGeneratorFunctionConstructor::finishCreation):
        * runtime/AsyncGeneratorFunctionPrototype.cpp:
        (JSC::AsyncGeneratorFunctionPrototype::finishCreation):
        * runtime/AsyncGeneratorPrototype.cpp:
        (JSC::AsyncGeneratorPrototype::finishCreation):
        * runtime/AsyncIteratorPrototype.cpp:
        (JSC::AsyncIteratorPrototype::finishCreation):
        * runtime/AtomicsObject.cpp:
        (JSC::AtomicsObject::finishCreation):
        * runtime/BooleanConstructor.cpp:
        (JSC::BooleanConstructor::finishCreation):
        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::createStructure):
        (JSC::ClonedArguments::getOwnPropertySlot):
        (JSC::ClonedArguments::materializeSpecials):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/ConsoleObject.cpp:
        (JSC::ConsoleObject::finishCreation):
        * runtime/DateConstructor.cpp:
        (JSC::DateConstructor::finishCreation):
        * runtime/DatePrototype.cpp:
        (JSC::DatePrototype::finishCreation):
        * runtime/DirectArguments.cpp:
        (JSC::DirectArguments::overrideThings):
        * runtime/Error.cpp:
        (JSC::addErrorInfo):
        * runtime/ErrorConstructor.cpp:
        (JSC::ErrorConstructor::finishCreation):
        * runtime/ErrorInstance.cpp:
        (JSC::ErrorInstance::finishCreation):
        * runtime/ErrorPrototype.cpp:
        (JSC::ErrorPrototype::finishCreation):
        * runtime/FunctionConstructor.cpp:
        (JSC::FunctionConstructor::finishCreation):
        * runtime/FunctionPrototype.cpp:
        (JSC::FunctionPrototype::finishCreation):
        (JSC::FunctionPrototype::addFunctionProperties):
        (JSC::FunctionPrototype::initRestrictedProperties):
        * runtime/GeneratorFunctionConstructor.cpp:
        (JSC::GeneratorFunctionConstructor::finishCreation):
        * runtime/GeneratorFunctionPrototype.cpp:
        (JSC::GeneratorFunctionPrototype::finishCreation):
        * runtime/GeneratorPrototype.cpp:
        (JSC::GeneratorPrototype::finishCreation):
        * runtime/GenericArgumentsInlines.h:
        (JSC::GenericArguments<Type>::getOwnPropertySlot):
        (JSC::GenericArguments<Type>::getOwnPropertySlotByIndex):
        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::finishCreation):
        * runtime/IntlCollatorConstructor.cpp:
        (JSC::IntlCollatorConstructor::finishCreation):
        * runtime/IntlDateTimeFormatConstructor.cpp:
        (JSC::IntlDateTimeFormatConstructor::finishCreation):
        * runtime/IntlDateTimeFormatPrototype.cpp:
        (JSC::IntlDateTimeFormatPrototype::finishCreation):
        * runtime/IntlNumberFormatConstructor.cpp:
        (JSC::IntlNumberFormatConstructor::finishCreation):
        * runtime/IntlObject.cpp:
        (JSC::IntlObject::finishCreation):
        * runtime/IteratorPrototype.cpp:
        (JSC::IteratorPrototype::finishCreation):
        * runtime/JSArray.cpp:
        (JSC::JSArray::getOwnPropertySlot):
        (JSC::JSArray::setLengthWithArrayStorage):
        * runtime/JSArrayBufferConstructor.cpp:
        (JSC::JSArrayBufferConstructor::finishCreation):
        * runtime/JSArrayBufferPrototype.cpp:
        (JSC::JSArrayBufferPrototype::finishCreation):
        * runtime/JSBoundFunction.cpp:
        (JSC::JSBoundFunction::finishCreation):
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::putToPrimitive):
        * runtime/JSDataView.cpp:
        (JSC::JSDataView::getOwnPropertySlot):
        * runtime/JSDataViewPrototype.cpp:
        (JSC::JSDataViewPrototype::finishCreation):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::finishCreation):
        (JSC::JSFunction::getOwnPropertySlot):
        (JSC::JSFunction::defineOwnProperty):
        (JSC::JSFunction::reifyLength):
        (JSC::JSFunction::reifyName):
        (JSC::JSFunction::reifyLazyBoundNameIfNeeded):
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
        (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlotByIndex):
        * runtime/JSGenericTypedArrayViewPrototypeInlines.h:
        (JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::addStaticGlobals):
        * runtime/JSLexicalEnvironment.cpp:
        (JSC::JSLexicalEnvironment::getOwnNonIndexPropertyNames):
        * runtime/JSModuleNamespaceObject.cpp:
        (JSC::JSModuleNamespaceObject::finishCreation):
        (JSC::JSModuleNamespaceObject::getOwnPropertySlotCommon):
        * runtime/JSONObject.cpp:
        (JSC::JSONObject::finishCreation):
        * runtime/JSObject.cpp:
        (JSC::getClassPropertyNames):
        (JSC::JSObject::getOwnPropertySlotByIndex):
        (JSC::ordinarySetSlow):
        (JSC::JSObject::putInlineSlow):
        (JSC::JSObject::putGetter):
        (JSC::JSObject::putSetter):
        (JSC::JSObject::putDirectAccessor):
        (JSC::JSObject::putDirectCustomAccessor):
        (JSC::JSObject::putDirectNonIndexAccessor):
        (JSC::JSObject::deleteProperty):
        (JSC::JSObject::deletePropertyByIndex):
        (JSC::JSObject::getOwnPropertyNames):
        (JSC::JSObject::putIndexedDescriptor):
        (JSC::JSObject::defineOwnIndexedProperty):
        (JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype):
        (JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength):
        (JSC::JSObject::getOwnPropertyDescriptor):
        (JSC::putDescriptor):
        (JSC::validateAndApplyPropertyDescriptor):
        * runtime/JSObject.h:
        (JSC::JSObject::putDirect):
        * runtime/JSObjectInlines.h:
        (JSC::JSObject::putDirectWithoutTransition):
        (JSC::JSObject::putDirectInternal):
        * runtime/JSPromiseConstructor.cpp:
        (JSC::JSPromiseConstructor::finishCreation):
        (JSC::JSPromiseConstructor::addOwnInternalSlots):
        * runtime/JSPromisePrototype.cpp:
        (JSC::JSPromisePrototype::finishCreation):
        (JSC::JSPromisePrototype::addOwnInternalSlots):
        * runtime/JSString.cpp:
        (JSC::JSString::getStringPropertyDescriptor):
        * runtime/JSString.h:
        (JSC::JSString::getStringPropertySlot):
        * runtime/JSSymbolTableObject.cpp:
        (JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames):
        * runtime/JSSymbolTableObject.h:
        (JSC::symbolTableGet):
        * runtime/JSTypedArrayViewConstructor.cpp:
        (JSC::JSTypedArrayViewConstructor::finishCreation):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::JSTypedArrayViewPrototype::finishCreation):
        * runtime/LazyClassStructure.cpp:
        (JSC::LazyClassStructure::Initializer::setConstructor):
        * runtime/Lookup.cpp:
        (JSC::reifyStaticAccessor):
        (JSC::setUpStaticFunctionSlot):
        * runtime/Lookup.h:
        (JSC::HashTableValue::intrinsic const):
        (JSC::HashTableValue::builtinGenerator const):
        (JSC::HashTableValue::function const):
        (JSC::HashTableValue::functionLength const):
        (JSC::HashTableValue::propertyGetter const):
        (JSC::HashTableValue::propertyPutter const):
        (JSC::HashTableValue::domJIT const):
        (JSC::HashTableValue::signature const):
        (JSC::HashTableValue::accessorGetter const):
        (JSC::HashTableValue::accessorSetter const):
        (JSC::HashTableValue::constantInteger const):
        (JSC::HashTableValue::lazyCellPropertyOffset const):
        (JSC::HashTableValue::lazyClassStructureOffset const):
        (JSC::HashTableValue::lazyPropertyCallback const):
        (JSC::HashTableValue::builtinAccessorGetterGenerator const):
        (JSC::HashTableValue::builtinAccessorSetterGenerator const):
        (JSC::getStaticPropertySlotFromTable):
        (JSC::putEntry):
        (JSC::reifyStaticProperty):
        * runtime/MapConstructor.cpp:
        (JSC::MapConstructor::finishCreation):
        * runtime/MapIteratorPrototype.cpp:
        (JSC::MapIteratorPrototype::finishCreation):
        * runtime/MapPrototype.cpp:
        (JSC::MapPrototype::finishCreation):
        * runtime/MathObject.cpp:
        (JSC::MathObject::finishCreation):
        * runtime/NativeErrorConstructor.cpp:
        (JSC::NativeErrorConstructor::finishCreation):
        * runtime/NativeErrorPrototype.cpp:
        (JSC::NativeErrorPrototype::finishCreation):
        * runtime/NumberConstructor.cpp:
        (JSC::NumberConstructor::finishCreation):
        * runtime/NumberPrototype.cpp:
        (JSC::NumberPrototype::finishCreation):
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructor::finishCreation):
        (JSC::objectConstructorAssign):
        (JSC::objectConstructorValues):
        (JSC::objectConstructorDefineProperty):
        * runtime/ObjectPrototype.cpp:
        (JSC::ObjectPrototype::finishCreation):
        (JSC::objectProtoFuncLookupGetter):
        (JSC::objectProtoFuncLookupSetter):
        * runtime/ProgramExecutable.cpp:
        (JSC::ProgramExecutable::initializeGlobalProperties):
        * runtime/PropertyDescriptor.cpp:
        (JSC::PropertyDescriptor::writable const):
        (JSC::PropertyDescriptor::enumerable const):
        (JSC::PropertyDescriptor::configurable const):
        (JSC::PropertyDescriptor::setUndefined):
        (JSC::PropertyDescriptor::setDescriptor):
        (JSC::PropertyDescriptor::setCustomDescriptor):
        (JSC::PropertyDescriptor::setAccessorDescriptor):
        (JSC::PropertyDescriptor::setWritable):
        (JSC::PropertyDescriptor::setEnumerable):
        (JSC::PropertyDescriptor::setConfigurable):
        (JSC::PropertyDescriptor::setSetter):
        (JSC::PropertyDescriptor::setGetter):
        (JSC::PropertyDescriptor::attributesEqual const):
        (JSC::PropertyDescriptor::attributesOverridingCurrent const):
        * runtime/PropertySlot.cpp:
        (JSC::PropertySlot::customGetter const):
        * runtime/PropertySlot.h:
        (JSC::operator| ):
        (JSC::operator&):
        (JSC::operator<):
        (JSC::operator~):
        (JSC::operator|=):
        (JSC::PropertySlot::setUndefined):
        * runtime/ProxyConstructor.cpp:
        (JSC::makeRevocableProxy):
        (JSC::ProxyConstructor::finishCreation):
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::performHasProperty):
        * runtime/ProxyRevoke.cpp:
        (JSC::ProxyRevoke::finishCreation):
        * runtime/ReflectObject.cpp:
        (JSC::ReflectObject::finishCreation):
        (JSC::reflectObjectDefineProperty):
        * runtime/RegExpConstructor.cpp:
        (JSC::RegExpConstructor::finishCreation):
        * runtime/RegExpObject.cpp:
        (JSC::RegExpObject::getOwnPropertySlot):
        * runtime/RegExpPrototype.cpp:
        (JSC::RegExpPrototype::finishCreation):
        * runtime/ScopedArguments.cpp:
        (JSC::ScopedArguments::overrideThings):
        * runtime/SetConstructor.cpp:
        (JSC::SetConstructor::finishCreation):
        * runtime/SetIteratorPrototype.cpp:
        (JSC::SetIteratorPrototype::finishCreation):
        * runtime/SetPrototype.cpp:
        (JSC::SetPrototype::finishCreation):
        * runtime/SparseArrayValueMap.cpp:
        (JSC::SparseArrayValueMap::putDirect):
        (JSC::SparseArrayEntry::put):
        * runtime/StringConstructor.cpp:
        (JSC::StringConstructor::finishCreation):
        * runtime/StringIteratorPrototype.cpp:
        (JSC::StringIteratorPrototype::finishCreation):
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        * runtime/Structure.cpp:
        (JSC::Structure::nonPropertyTransition):
        (JSC::Structure::isSealed):
        (JSC::Structure::isFrozen):
        (JSC::Structure::getPropertyNamesFromStructure):
        (JSC::Structure::prototypeChainMayInterceptStoreTo):
        * runtime/StructureInlines.h:
        (JSC::Structure::add):
        * runtime/SymbolConstructor.cpp:
        (JSC::SymbolConstructor::finishCreation):
        * runtime/SymbolPrototype.cpp:
        (JSC::SymbolPrototype::finishCreation):
        * runtime/SymbolTable.h:
        (JSC::SymbolTableEntry::Fast::getAttributes const):
        (JSC::SymbolTableEntry::SymbolTableEntry):
        (JSC::SymbolTableEntry::setAttributes):
        * runtime/TemplateRegistry.cpp:
        (JSC::TemplateRegistry::getTemplateObject):
        * runtime/WeakMapConstructor.cpp:
        (JSC::WeakMapConstructor::finishCreation):
        * runtime/WeakMapPrototype.cpp:
        (JSC::WeakMapPrototype::finishCreation):
        * runtime/WeakSetConstructor.cpp:
        (JSC::WeakSetConstructor::finishCreation):
        * runtime/WeakSetPrototype.cpp:
        (JSC::WeakSetPrototype::finishCreation):
        * tools/JSDollarVMPrototype.cpp:
        (JSC::JSDollarVMPrototype::finishCreation):
        * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
        (JSC::WebAssemblyCompileErrorConstructor::finishCreation):
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::WebAssemblyInstanceConstructor::finishCreation):
        * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
        (JSC::WebAssemblyLinkErrorConstructor::finishCreation):
        * wasm/js/WebAssemblyMemoryConstructor.cpp:
        (JSC::WebAssemblyMemoryConstructor::finishCreation):
        * wasm/js/WebAssemblyMemoryPrototype.cpp:
        * wasm/js/WebAssemblyModuleConstructor.cpp:
        (JSC::WebAssemblyModuleConstructor::finishCreation):
        * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
        (JSC::WebAssemblyRuntimeErrorConstructor::finishCreation):
        * wasm/js/WebAssemblyTableConstructor.cpp:
        (JSC::WebAssemblyTableConstructor::finishCreation):

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

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

        Reviewed by Yusuke Suzuki.

        Add small optimization for async generators:
        1. merging async generator queue to async generator itself
        generator.@first / generator.@last is enough, by doing so,
          we remove one unnecessary object alloc.
        2. merging request with queue.

        * builtins/AsyncGeneratorPrototype.js:
        (globalPrivate.asyncGeneratorQueueIsEmpty):
        (globalPrivate.asyncGeneratorQueueCreateItem):
        (globalPrivate.asyncGeneratorQueueEnqueue):
        (globalPrivate.asyncGeneratorQueueDequeue):
        (globalPrivate.asyncGeneratorDequeue):
        (globalPrivate.isSuspendYieldState):
        (globalPrivate.asyncGeneratorEnqueue):
        * builtins/BuiltinNames.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitPutAsyncGeneratorFields):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::FunctionNode::emitBytecode):

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

        test262: $.agent became $262.agent in test262 update
        https://bugs.webkit.org/show_bug.cgi?id=177407

        Reviewed by Yusuke Suzuki.

        * jsc.cpp:
        (GlobalObject::finishCreation):
        Alias `$` and `$262` for now.

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

        Speculatively change iteration protocall to use the same next function
        https://bugs.webkit.org/show_bug.cgi?id=175653

        Reviewed by Saam Barati.

        This patch speculatively makes a change to the iteration protocall to fetch the next
        property immediately after calling the Symbol.iterator function. This is, in theory,
        a breaking change, so we will see if this breaks things (most likely it won't as this
        is a relatively subtle point).

        See: https://github.com/tc39/ecma262/issues/976

        * builtins/IteratorHelpers.js:
        (performIteration):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitEnumeration):
        (JSC::BytecodeGenerator::emitIteratorNext):
        (JSC::BytecodeGenerator::emitIteratorNextWithValue):
        (JSC::BytecodeGenerator::emitDelegateYield):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ArrayPatternNode::bindValue const):
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::iteratorEntries):
        * runtime/IteratorOperations.cpp:
        (JSC::iteratorNext):
        (JSC::iteratorStep):
        (JSC::iteratorClose):
        (JSC::iteratorForIterable):
        * runtime/IteratorOperations.h:
        (JSC::forEachInIterable):
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::constructGenericTypedArrayViewFromIterator):
        (JSC::constructGenericTypedArrayViewWithArguments):

2017-09-22  Fujii Hironori  <Hironori.Fujii@sony.com>

        [Win64] Crashes in Yarr JIT compiled code
        https://bugs.webkit.org/show_bug.cgi?id=177293

        Reviewed by Yusuke Suzuki.

        In x64 Windows, rcx register is used for the address of allocated
        space for the return value. But, rcx is used for regT1 since
        r221052. Save rcx in the stack.

        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::generateEnter): Push ecx.
        (JSC::Yarr::YarrGenerator::generateReturn): Pop ecx.

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

        Usage of ErrorInstance::m_stackTrace on the mutator is racy with the collector
        https://bugs.webkit.org/show_bug.cgi?id=177368

        Reviewed by Keith Miller.

        * runtime/ErrorInstance.cpp:
        (JSC::ErrorInstance::finishCreation):
        (JSC::ErrorInstance::materializeErrorInfoIfNeeded):
        (JSC::ErrorInstance::visitChildren):

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

        [DFG][FTL] Profile array vector length for array allocation
        https://bugs.webkit.org/show_bug.cgi?id=177051

        Reviewed by Saam Barati.

        Currently, NewArrayBuffer allocation is penalized by JSC: While empty array gets 25 vector size (BASE_CONTIGUOUS_VECTOR_LEN),
        new_array_buffer case gets 3 vector size (BASE_CONTIGUOUS_VECTOR_LEN). Surely, new_array_buffer can get larger vector size
        if the number of its constant elements is larger than 3. But these created array may be grown by `push()` operation after
        the allocation. In this case, new_array_buffer is penalized compared to empty array allocation.

            empty array allocation,

            var array = [];
            array.push(0);
            array.push(1);
            array.push(2);
            array.push(3);
            array.push(4);

            v.s. new_array_buffer case,

            var array = [0];
            array.push(1);
            array.push(2);
            array.push(3);
            array.push(4);

        In this case, the latter becomes slow. While we have a chance to reduce memory usage if new_array_buffer is not grown (and a bit likely),
        we should allocate 3 to 25 vector size if it is likely grown. So we should get profile on the resulted array.

        We select 25 to make it fit to one of size classes.

        In this patch, we extend ArrayAllocationProfile to record vector length. And use this information when allocating array for new_array_buffer.
        If the number of new_array_buffer constants is <= 25, array vector size would become 3 to 25 based on profiling. If the number of its constants
        is larger than 25, we just use it for allocation as before.

        Added microbenchmark and SixSpeed spread-literal.es5 shows improvement.

            new-array-buffer-vector-profile       67.4706+-3.7625     ^     28.4249+-1.9025        ^ definitely 2.3736x faster
            spread-literal.es5                   133.1443+-9.2253     ^     95.2667+-0.5740        ^ definitely 1.3976x faster

        * bytecode/ArrayAllocationProfile.cpp:
        (JSC::ArrayAllocationProfile::updateProfile):
        (JSC::ArrayAllocationProfile::updateIndexingType): Deleted.
        * bytecode/ArrayAllocationProfile.h:
        (JSC::ArrayAllocationProfile::selectIndexingType):
        (JSC::ArrayAllocationProfile::vectorLengthHint):
        (JSC::ArrayAllocationProfile::ArrayAllocationProfile): Deleted.
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::updateAllArrayPredictions):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::vectorLengthHint):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileArraySlice):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayBuffer):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize):
        (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
        (JSC::FTL::DFG::LowerDFGToB3::allocateUninitializedContiguousJSArrayInternal):
        (JSC::FTL::DFG::LowerDFGToB3::allocateUninitializedContiguousJSArray):
        * runtime/ArrayConventions.h:
        * runtime/JSArray.h:
        (JSC::JSArray::tryCreate):

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

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

        Octane/box2d shows 8% regression (Requested by yusukesuzuki on
        #webkit).

        Reverted changeset:

        "[DFG][FTL] Profile array vector length for array allocation"
        https://bugs.webkit.org/show_bug.cgi?id=177051
        http://trac.webkit.org/changeset/222380

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

        [DFG][FTL] Profile array vector length for array allocation
        https://bugs.webkit.org/show_bug.cgi?id=177051

        Reviewed by Saam Barati.

        Currently, NewArrayBuffer allocation is penalized by JSC: While empty array gets 25 vector size (BASE_CONTIGUOUS_VECTOR_LEN),
        new_array_buffer case gets 3 vector size (BASE_CONTIGUOUS_VECTOR_LEN). Surely, new_array_buffer can get larger vector size
        if the number of its constant elements is larger than 3. But these created array may be grown by `push()` operation after
        the allocation. In this case, new_array_buffer is penalized compared to empty array allocation.

            empty array allocation,

            var array = [];
            array.push(0);
            array.push(1);
            array.push(2);
            array.push(3);
            array.push(4);

            v.s. new_array_buffer case,

            var array = [0];
            array.push(1);
            array.push(2);
            array.push(3);
            array.push(4);

        In this case, the latter becomes slow. While we have a chance to reduce memory usage if new_array_buffer is not grown (and a bit likely),
        we should allocate 3 to 25 vector size if it is likely grown. So we should get profile on the resulted array.

        We select 25 to make it fit to one of size classes.

        In this patch, we extend ArrayAllocationProfile to record vector length. And use this information when allocating array for new_array_buffer.
        If the number of new_array_buffer constants is <= 25, array vector size would become 3 to 25 based on profiling. If the number of its constants
        is larger than 25, we just use it for allocation as before.

        Added microbenchmark and SixSpeed spread-literal.es5 shows improvement.

            new-array-buffer-vector-profile       67.4706+-3.7625     ^     28.4249+-1.9025        ^ definitely 2.3736x faster
            spread-literal.es5                   133.1443+-9.2253     ^     95.2667+-0.5740        ^ definitely 1.3976x faster

        * bytecode/ArrayAllocationProfile.cpp:
        (JSC::ArrayAllocationProfile::updateProfile):
        (JSC::ArrayAllocationProfile::updateIndexingType): Deleted.
        * bytecode/ArrayAllocationProfile.h:
        (JSC::ArrayAllocationProfile::selectIndexingType):
        (JSC::ArrayAllocationProfile::vectorLengthHint):
        (JSC::ArrayAllocationProfile::ArrayAllocationProfile): Deleted.
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::updateAllArrayPredictions):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::vectorLengthHint):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileArraySlice):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayBuffer):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize):
        (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
        (JSC::FTL::DFG::LowerDFGToB3::allocateUninitializedContiguousJSArrayInternal):
        (JSC::FTL::DFG::LowerDFGToB3::allocateUninitializedContiguousJSArray):
        * runtime/ArrayConventions.h:
        * runtime/JSArray.h:
        (JSC::JSArray::tryCreate):

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

        Web Inspector: Remove support for CSS Regions
        https://bugs.webkit.org/show_bug.cgi?id=177287

        Reviewed by Matt Baker.

        * inspector/protocol/CSS.json:
        * inspector/protocol/OverlayTypes.json:

2017-09-21  Brian Burg  <bburg@apple.com>

        Web Inspector: keyboard shortcut for "Reload page from origin" doesn't match Safari, and doesn't work
        https://bugs.webkit.org/show_bug.cgi?id=177010
        <rdar://problem/33134548>

        Reviewed by Joseph Pecoraro.

        Use "reload from origin" nomenclature instead of "reload ignoring cache".

        * inspector/protocol/Page.json: Improve the comment, but don't change the
        parameter name since this would be a divergence from legacy protocols.

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

        test262: test262/test/annexB/built-ins/RegExp/prototype/flags/order-after-compile.js ASSERTs
        https://bugs.webkit.org/show_bug.cgi?id=177307

        Reviewed by Michael Saboff.

        * runtime/RegExpPrototype.cpp:
        In r221160 we added support for the new RegExp flag (dotAll).
        We needed to make space for it in FlagsString.

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

        JSC should use unified sources for platform specific files.
        https://bugs.webkit.org/show_bug.cgi?id=177290

        Reviewed by Michael Saboff.

        Add a list of platform specific source files and update the
        Generate Unified Sources phase of the Xcode build. I skipped WPE
        since that seems to have failed for some reason that I didn't
        fully understand. See:
        https://webkit-queues.webkit.org/results/4611260

        Also, fix duplicate symbols in Glib remote inspector files.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * PlatformGTK.cmake:
        * PlatformMac.cmake:
        * SourcesGTK.txt: Added.
        * SourcesMac.txt: Added.
        * inspector/remote/glib/RemoteInspectorServer.cpp:
        (Inspector::RemoteInspectorServer::interfaceInfo):
        (Inspector::RemoteInspectorServer::setTargetList):
        (Inspector::RemoteInspectorServer::setupInspectorClient):
        (Inspector::RemoteInspectorServer::setup):
        (Inspector::RemoteInspectorServer::close):
        (Inspector::RemoteInspectorServer::connectionClosed):
        (Inspector::RemoteInspectorServer::sendMessageToBackend):
        (Inspector::RemoteInspectorServer::sendMessageToFrontend):
        (Inspector::dbusConnectionCallAsyncReadyCallback): Deleted.

2017-09-20  Stephan Szabo  <stephan.szabo@sony.com>

        [Win] WTF: Add alias for process id to use in place of direct uses of pid_t
        https://bugs.webkit.org/show_bug.cgi?id=177017

        Reviewed by Alex Christensen.

        * API/JSRemoteInspector.cpp:
        (JSRemoteInspectorSetParentProcessInformation):
        * API/JSRemoteInspector.h:
        * inspector/remote/RemoteInspector.h:

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

        Rename source list file to Sources.txt
        https://bugs.webkit.org/show_bug.cgi?id=177283

        Reviewed by Saam Barati.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt: Renamed from Source/JavaScriptCore/sources.txt.

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

        Unreviewed, fix string capitalization

        * JavaScriptCore.xcodeproj/project.pbxproj:

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

        JSC Xcode build should use unified sources for platform independent files
        https://bugs.webkit.org/show_bug.cgi?id=177190

        Reviewed by Saam Barati.

        This patch changes the Xcode build to use unified sources. The
        main difference from a development perspective is that instead of
        added source files to Xcode they need to be added to the shared
        sources.txt. For now, platform specific files are still added
        to the JavaScriptCore target.

        Because Xcode needs to know about all the files before we generate
        them all the unified source files need to be added to the
        JavaScriptCore framework target. As a result, if we run out of
        bundle files more will need to be added to the project. Currently,
        there are no spare files. If adding more bundle files becomes
        problematic we can change this.

        LowLevelInterpreter.cpp can't be added to the unified source list yet
        due to a clang bug.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * sources.txt: Added.

2017-09-20  Per Arne Vollan  <pvollan@apple.com>

        [Win] Cannot find script to generate unified sources.
        https://bugs.webkit.org/show_bug.cgi?id=177014

        Reviewed by Keith Miller.

        The ruby script can now be found in WTF/Scripts in the forwarding headers folder.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.proj:

2017-09-20  Alberto Garcia  <berto@igalia.com>

        Fix HPPA and Alpha builds
        https://bugs.webkit.org/show_bug.cgi?id=177224

        Reviewed by Alex Christensen.

        * CMakeLists.txt:

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

        ErrorInstance and Exception need destroy methods
        https://bugs.webkit.org/show_bug.cgi?id=177095

        Reviewed by Saam Barati.
        
        When I made ErrorInstance and Exception into JSDestructibleObjects, I forgot to make them
        follow that type's protocol.

        * runtime/ErrorInstance.cpp:
        (JSC::ErrorInstance::destroy): Implement this to fix leaks.
        * runtime/ErrorInstance.h:
        * runtime/Exception.h: Change how this is declared now that this is a DestructibleObject.

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

        [JSC] Consider dropping JSObjectSetPrototype feature for JSGlobalObject
        https://bugs.webkit.org/show_bug.cgi?id=177070

        Reviewed by Saam Barati.

        Due to the security reason, our global object is immutable prototype exotic object.
        It prevents users from injecting proxies into the prototype chain of the global object[1].
        But our JSC API does not respect this attribute, and allows users to change [[Prototype]]
        of the global object after instantiating it.

        This patch removes this feature. Once global object is instantiated, we cannot change [[Prototype]]
        of the global object. It drops JSGlobalObject::resetPrototype use, which involves GlobalThis
        edge cases.

        [1]: https://github.com/tc39/ecma262/commit/935dad4283d045bc09c67a259279772d01b3d33d

        * API/JSObjectRef.cpp:
        (JSObjectSetPrototype):
        * API/tests/CustomGlobalObjectClassTest.c:
        (globalObjectSetPrototypeTest):

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

        [DFG] Remove ToThis more aggressively
        https://bugs.webkit.org/show_bug.cgi?id=177056

        Reviewed by Saam Barati.

        The variation of toThis() implementation is limited. So, we attempts to implement common toThis operation in AI.
        We move scope related toThis to JSScope::toThis. And AI investigates proven value/structure's toThis methods
        and attempts to fold/convert to efficient nodes.

        We introduces GetGlobalThis, which just loads globalThis from semantic origin's globalObject. Using this,
        we can implement JSScope::toThis in DFG. This can avoid costly toThis indirect function pointer call.

        Currently, we just emit GetGlobalThis if necessary. We can further convert it to constant if we can put
        watchpoint to JSGlobalObject's globalThis change. But we leave it for a future patch for now.

        This removes GetGlobalThis from ES6 generators in common cases.

        spread-generator.es6      303.1550+-9.5037          290.9337+-8.3487          might be 1.0420x faster

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::isToThisAnIdentity):
        (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/DFGNode.h:
        (JSC::DFG::Node::convertToGetGlobalThis):
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetGlobalThis):
        * 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::compileGetGlobalThis):
        * runtime/JSGlobalLexicalEnvironment.cpp:
        (JSC::JSGlobalLexicalEnvironment::toThis): Deleted.
        * runtime/JSGlobalLexicalEnvironment.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::toThis): Deleted.
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::addressOfGlobalThis):
        * runtime/JSLexicalEnvironment.cpp:
        (JSC::JSLexicalEnvironment::toThis): Deleted.
        * runtime/JSLexicalEnvironment.h:
        * runtime/JSScope.cpp:
        (JSC::JSScope::toThis):
        * runtime/JSScope.h:
        * runtime/StrictEvalActivation.cpp:
        (JSC::StrictEvalActivation::toThis): Deleted.
        * runtime/StrictEvalActivation.h:

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

        Merge JSLexicalEnvironment and JSEnvironmentRecord
        https://bugs.webkit.org/show_bug.cgi?id=175492

        Reviewed by Saam Barati.

        JSEnvironmentRecord is only inherited by JSLexicalEnvironment.
        We can merge JSEnvironmentRecord and JSLexicalEnvironment.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateActivation):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetClosureVar):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutClosureVar):
        (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitGetClosureVar):
        (JSC::JIT::emitPutClosureVar):
        (JSC::JIT::emitScopedArgumentsGetByVal):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emitGetClosureVar):
        (JSC::JIT::emitPutClosureVar):
        * llint/LLIntOffsetsExtractor.cpp:
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/JSEnvironmentRecord.cpp: Removed.
        * runtime/JSEnvironmentRecord.h: Removed.
        * runtime/JSLexicalEnvironment.cpp:
        (JSC::JSLexicalEnvironment::visitChildren):
        (JSC::JSLexicalEnvironment::heapSnapshot):
        (JSC::JSLexicalEnvironment::getOwnNonIndexPropertyNames):
        * runtime/JSLexicalEnvironment.h:
        (JSC::JSLexicalEnvironment::subspaceFor):
        (JSC::JSLexicalEnvironment::variables):
        (JSC::JSLexicalEnvironment::isValidScopeOffset):
        (JSC::JSLexicalEnvironment::variableAt):
        (JSC::JSLexicalEnvironment::offsetOfVariables):
        (JSC::JSLexicalEnvironment::offsetOfVariable):
        (JSC::JSLexicalEnvironment::allocationSizeForScopeSize):
        (JSC::JSLexicalEnvironment::allocationSize):
        (JSC::JSLexicalEnvironment::finishCreationUninitialized):
        (JSC::JSLexicalEnvironment::finishCreation):
        * runtime/JSModuleEnvironment.cpp:
        (JSC::JSModuleEnvironment::create):
        * runtime/JSObject.h:
        (JSC::JSObject::isEnvironment const):
        (JSC::JSObject::isEnvironmentRecord const): Deleted.
        * runtime/JSSegmentedVariableObject.h:
        * runtime/StringPrototype.cpp:
        (JSC::checkObjectCoercible):

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):