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

        A Possible Issue of Object.create method
        https://bugs.webkit.org/show_bug.cgi?id=199744

        Reviewed by Yusuke Suzuki.

        We should call toObject on the properties argument if it was not undefined.
        See: https://tc39.es/ecma262/#sec-object.create

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

2019-07-15  Saagar Jha  <saagarjha@apple.com>

        Keyword lookup can use memcmp to get around unaligned load undefined behavior
        https://bugs.webkit.org/show_bug.cgi?id=199650

        Reviewed by Yusuke Suzuki.

        Replace KeywordLookup's hand-rolled "memcmp" with the standard version, which reduces the need to deal with
        endianness and unaligned loads.

        * KeywordLookupGenerator.py:
        (Trie.printSubTreeAsC): Use memcmp instead of macros to test for matches.
        (Trie.printAsC): Unspecialize Lexer::parseKeyword as templating over the character type reduces the amount of
        code we need to generate and moves this task out of the Python script and into the C++ compiler.

2019-07-15  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Improve wasm wpt test results by fixing miscellaneous issues
        https://bugs.webkit.org/show_bug.cgi?id=199783

        Reviewed by Mark Lam.

        This patch fixes miscellaneous issues in our Wasm JS API implementation to improve WPT score.
        I picked trivial ones in this patch to make this easily reviewable.

        1. Remove WebAssemblyPrototype. It does not exist in the spec. Merging WebAssemblyPrototype into JSWebAssembly.
        2. Fix various attributes. It does not match to the usual JSC builtin's convention. But this change
           is correct because they are changed to be matched against WebIDL definition, and WebAssembly implementation
           follows WebIDL. In the future, we could move WebCore WebIDL things into WTF layer and even use (or leverage
           some of utility functions) in our WebAssembly JS API implementation.
        3. Fix how we interpret "present" in WebAssembly spec. This does not mean [[HasProperty]] result. It follows to
           WebIDL spec, and it means that [[Get]] result is not undefined.
        4. Add argument count check to Module.customSections, which is required because the method is defined in WebIDL.
        5. Fix toNonWrappingUint32 to match it to WebIDL's conversion rule.

        * CMakeLists.txt:
        * DerivedSources-input.xcfilelist:
        * DerivedSources-output.xcfilelist:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * builtins/WebAssembly.js: Renamed from Source/JavaScriptCore/builtins/WebAssemblyPrototype.js.
        * jit/Repatch.cpp:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSModuleLoader.cpp:
        (JSC::moduleLoaderParseModule):
        * wasm/js/JSWebAssembly.cpp:
        (JSC::JSWebAssembly::create):
        (JSC::JSWebAssembly::finishCreation):
        (JSC::reject):
        (JSC::webAssemblyModuleValidateAsyncInternal):
        (JSC::webAssemblyCompileFunc):
        (JSC::resolve):
        (JSC::JSWebAssembly::webAssemblyModuleValidateAsync):
        (JSC::instantiate):
        (JSC::compileAndInstantiate):
        (JSC::JSWebAssembly::instantiate):
        (JSC::webAssemblyModuleInstantinateAsyncInternal):
        (JSC::JSWebAssembly::webAssemblyModuleInstantinateAsync):
        (JSC::webAssemblyInstantiateFunc):
        (JSC::webAssemblyValidateFunc):
        (JSC::webAssemblyCompileStreamingInternal):
        (JSC::webAssemblyInstantiateStreamingInternal):
        * wasm/js/JSWebAssembly.h:
        * wasm/js/JSWebAssemblyHelpers.h:
        (JSC::toNonWrappingUint32):
        * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
        (JSC::WebAssemblyCompileErrorConstructor::finishCreation):
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::WebAssemblyInstanceConstructor::finishCreation):
        * wasm/js/WebAssemblyInstancePrototype.cpp:
        * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
        (JSC::WebAssemblyLinkErrorConstructor::finishCreation):
        * wasm/js/WebAssemblyMemoryConstructor.cpp:
        (JSC::constructJSWebAssemblyMemory):
        (JSC::WebAssemblyMemoryConstructor::finishCreation):
        * wasm/js/WebAssemblyMemoryPrototype.cpp:
        * wasm/js/WebAssemblyModuleConstructor.cpp:
        (JSC::webAssemblyModuleCustomSections):
        (JSC::WebAssemblyModuleConstructor::finishCreation):
        * wasm/js/WebAssemblyPrototype.cpp: Removed.
        * wasm/js/WebAssemblyPrototype.h: Removed.
        * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
        (JSC::WebAssemblyRuntimeErrorConstructor::finishCreation):
        * wasm/js/WebAssemblyTableConstructor.cpp:
        (JSC::constructJSWebAssemblyTable):
        (JSC::WebAssemblyTableConstructor::finishCreation):
        * wasm/js/WebAssemblyTablePrototype.cpp:

2019-07-15  Michael Catanzaro  <mcatanzaro@igalia.com>

        Unreviewed, rolling out r247440.

        Broke builds

        Reverted changeset:

        "[JSC] Improve wasm wpt test results by fixing miscellaneous
        issues"
        https://bugs.webkit.org/show_bug.cgi?id=199783
        https://trac.webkit.org/changeset/247440

2019-07-15  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Improve wasm wpt test results by fixing miscellaneous issues
        https://bugs.webkit.org/show_bug.cgi?id=199783

        Reviewed by Mark Lam.

        This patch fixes miscellaneous issues in our Wasm JS API implementation to improve WPT score.
        I picked trivial ones in this patch to make this easily reviewable.

        1. Remove WebAssemblyPrototype. It does not exist in the spec. Merging WebAssemblyPrototype into JSWebAssembly.
        2. Fix various attributes. It does not match to the usual JSC builtin's convention. But this change
           is correct because they are changed to be matched against WebIDL definition, and WebAssembly implementation
           follows WebIDL. In the future, we could move WebCore WebIDL things into WTF layer and even use (or leverage
           some of utility functions) in our WebAssembly JS API implementation.
        3. Fix how we interpret "present" in WebAssembly spec. This does not mean [[HasProperty]] result. It follows to
           WebIDL spec, and it means that [[Get]] result is not undefined.
        4. Add argument count check to Module.customSections, which is required because the method is defined in WebIDL.
        5. Fix toNonWrappingUint32 to match it to WebIDL's conversion rule.

        * CMakeLists.txt:
        * DerivedSources-input.xcfilelist:
        * DerivedSources-output.xcfilelist:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * builtins/WebAssembly.js: Renamed from Source/JavaScriptCore/builtins/WebAssemblyPrototype.js.
        * jit/Repatch.cpp:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSModuleLoader.cpp:
        (JSC::moduleLoaderParseModule):
        * wasm/js/JSWebAssembly.cpp:
        (JSC::JSWebAssembly::create):
        (JSC::JSWebAssembly::finishCreation):
        (JSC::reject):
        (JSC::webAssemblyModuleValidateAsyncInternal):
        (JSC::webAssemblyCompileFunc):
        (JSC::resolve):
        (JSC::JSWebAssembly::webAssemblyModuleValidateAsync):
        (JSC::instantiate):
        (JSC::compileAndInstantiate):
        (JSC::JSWebAssembly::instantiate):
        (JSC::webAssemblyModuleInstantinateAsyncInternal):
        (JSC::JSWebAssembly::webAssemblyModuleInstantinateAsync):
        (JSC::webAssemblyInstantiateFunc):
        (JSC::webAssemblyValidateFunc):
        (JSC::webAssemblyCompileStreamingInternal):
        (JSC::webAssemblyInstantiateStreamingInternal):
        * wasm/js/JSWebAssembly.h:
        * wasm/js/JSWebAssemblyHelpers.h:
        (JSC::toNonWrappingUint32):
        * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
        (JSC::WebAssemblyCompileErrorConstructor::finishCreation):
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::WebAssemblyInstanceConstructor::finishCreation):
        * wasm/js/WebAssemblyInstancePrototype.cpp:
        * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
        (JSC::WebAssemblyLinkErrorConstructor::finishCreation):
        * wasm/js/WebAssemblyMemoryConstructor.cpp:
        (JSC::constructJSWebAssemblyMemory):
        (JSC::WebAssemblyMemoryConstructor::finishCreation):
        * wasm/js/WebAssemblyMemoryPrototype.cpp:
        * wasm/js/WebAssemblyModuleConstructor.cpp:
        (JSC::webAssemblyModuleCustomSections):
        (JSC::WebAssemblyModuleConstructor::finishCreation):
        * wasm/js/WebAssemblyPrototype.cpp: Removed.
        * wasm/js/WebAssemblyPrototype.h: Removed.
        * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
        (JSC::WebAssemblyRuntimeErrorConstructor::finishCreation):
        * wasm/js/WebAssemblyTableConstructor.cpp:
        (JSC::constructJSWebAssemblyTable):
        (JSC::WebAssemblyTableConstructor::finishCreation):
        * wasm/js/WebAssemblyTablePrototype.cpp:

2019-07-15  Youenn Fablet  <youenn@apple.com>

        Enable a debug WebRTC mode without any encryption
        https://bugs.webkit.org/show_bug.cgi?id=199177
        <rdar://problem/52074986>

        Reviewed by Eric Carlson.

        * inspector/protocol/Page.json:

2019-07-15  Ryan Haddad  <ryanhaddad@apple.com>

        Unreviewed, attempt to fix production builds after r247403.

        * JavaScriptCore.xcodeproj/project.pbxproj:

2019-07-15  Tadeu Zagallo  <tzagallo@apple.com>

        Concurrent GC should not rely on current phase to determine if it's safe to steal conn
        https://bugs.webkit.org/show_bug.cgi?id=199786
        <rdar://problem/52505197>

        Reviewed by Saam Barati.

        In r246507, we fixed a race condition in the concurrent GC where the mutator might steal
        the conn from the collector thread while it transitions from the End phase to NotRunning.
        However, that fix was not sufficient. In the case that the mutator steals the conn, and the
        execution interleaves long enough for the mutator to progress to a different collection phase,
        the collector will resume in a phase other than NotRunning, and hence the check added to
        NotRunning will not suffice. To fix that, we add a new variable to track whether the collector
        thread is running (m_collectorThreadIsRunning) and use it to determine whether it's safe to
        steal the conn, rather than relying on m_currentPhase.

        * heap/Heap.cpp:
        (JSC::Heap::runNotRunningPhase):
        (JSC::Heap::requestCollection):
        * heap/Heap.h:

2019-07-12  Keith Miller  <keith_miller@apple.com>

        Add API to get all the dependencies of a given JSScript
        https://bugs.webkit.org/show_bug.cgi?id=199746

        Reviewed by Saam Barati.

        The method only returns the dependencies if the module was
        actually evaluated. Technically, we know what the dependencies are
        at the satisfy phase but for API simplicity we only provide that
        information if the module graph was complete enough to at least
        run.

        This patch also fixes an issue where we would allow import
        specifiers that didn't start "./" or "/". For reference, We have
        this restriction to be consistent with the web/node. The
        restriction exists in order to preserve namespace for
        builtin-modules.

        Lastly, this patch makes it so that we copy all scripts in the
        API/tests/testapiScripts directory so they don't have to be
        individually added to the xcode project.

        * API/JSAPIGlobalObject.mm:
        (JSC::computeValidImportSpecifier):
        (JSC::JSAPIGlobalObject::moduleLoaderResolve):
        (JSC::JSAPIGlobalObject::moduleLoaderImportModule):
        * API/JSContext.mm:
        (-[JSContext dependencyIdentifiersForModuleJSScript:]):
        * API/JSContextPrivate.h:
        * API/JSScript.h:
        * API/tests/testapi.mm:
        (testFetchWithTwoCycle):
        (testFetchWithThreeCycle):
        (testModuleBytecodeCache):
        (+[JSContextFileLoaderDelegate newContext]):
        (-[JSContextFileLoaderDelegate fetchModuleScript:]):
        (-[JSContextFileLoaderDelegate findScriptForKey:]):
        (-[JSContextFileLoaderDelegate context:fetchModuleForIdentifier:withResolveHandler:andRejectHandler:]):
        (testDependenciesArray):
        (testDependenciesEvaluationError):
        (testDependenciesSyntaxError):
        (testDependenciesBadImportId):
        (testDependenciesMissingImport):
        (testObjectiveCAPI):
        * API/tests/testapiScripts/dependencyListTests/badModuleImportId.js: Added.
        * API/tests/testapiScripts/dependencyListTests/bar.js: Added.
        * API/tests/testapiScripts/dependencyListTests/dependenciesEntry.js: Added.
        * API/tests/testapiScripts/dependencyListTests/foo.js: Added.
        * API/tests/testapiScripts/dependencyListTests/missingImport.js: Added.
        * API/tests/testapiScripts/dependencyListTests/referenceError.js: Added.
        * API/tests/testapiScripts/dependencyListTests/syntaxError.js: Added.
        * API/tests/testapiScripts/testapi-function-overrides.js: Renamed from Source/JavaScriptCore/API/tests/testapi-function-overrides.js.
        * API/tests/testapiScripts/testapi.js: Renamed from Source/JavaScriptCore/API/tests/testapi.js.
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/ModuleLoader.js:
        (dependencyKeysIfEvaluated):
        * runtime/JSModuleLoader.cpp:
        (JSC::JSModuleLoader::dependencyKeysIfEvaluated):
        * runtime/JSModuleLoader.h:
        * shell/CMakeLists.txt:

2019-07-12  Justin Michaud  <justin_michaud@apple.com>

        B3 should reduce (integer) Sub(Neg(x), y) to Neg(Add(x, y))
        https://bugs.webkit.org/show_bug.cgi?id=196371

        Reviewed by Keith Miller.

        Adding these strength reductions gives 2x a (x86) and 3x (arm64) performance improvement
        on the microbenchmark.

        * b3/B3ReduceStrength.cpp:
        * b3/testb3.cpp:
        (JSC::B3::testSubSub):
        (JSC::B3::testSubSub2):
        (JSC::B3::testSubAdd):
        (JSC::B3::testSubFirstNeg):
        (JSC::B3::run):

2019-07-12  Caio Lima  <ticaiolima@gmail.com>

        [BigInt] Add ValueBitLShift into DFG
        https://bugs.webkit.org/show_bug.cgi?id=192664

        Reviewed by Saam Barati.

        This patch is splitting the `BitLShift` into `ArithBitLShift` and
        `ValueBitLShift` to handle BigInt speculation more efficiently during
        DFG and FTL layers. Following the same approach of other `ValueBitOps`,
        `ValueBitLShift` handles Untyped and BigInt speculations, while
        `ArithBitLShift` handles number and boolean operands and always results into
        Int32. 

        * bytecode/BytecodeList.rb:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        * bytecode/Opcode.h:
        * dfg/DFGAbstractInterpreter.h:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::handleConstantBinaryBitwiseOp):
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):

        We moved `BitLShift` constant fold rules to a new method
        `handleConstantBinaryBitwiseOp` to be reused by `ArithBitLShift` and
        `ValueBitLShift`. This also enables support of constant folding on other
        bitwise operations like `ValueBitAnd`, `ValueBitOr` and `ValueBitXor`, when
        their binary use kind is UntypedUse. Such cases can happen on those
        nodes because fixup phase is conservative.

        * dfg/DFGBackwardsPropagationPhase.cpp:
        (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwo):
        (JSC::DFG::BackwardsPropagationPhase::propagate):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
        (JSC::DFG::ByteCodeParser::parseBlock):

        We parse `op_lshift` as `ArithBitLShift` when its operands are numbers.
        Otherwise, we fallback to `ValueBitLShift` and rely on fixup phase to
        convert `ValueBitLShift` into `ArithBitLShift` when possible.

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

        `ArithBitLShift` has the same clobberize rules as former `BitLShift`.
        `ValueBitLShift` only clobberize world when it is UntypedUse.

        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):

        `ValueBitLShift` can GC when `BigIntUse` because it allocates new
        JSBigInts to perform this operation. It also can GC on UntypedUse
        because of observable user code.

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

        `ValueBitLShift` and `ArithBitLShift` has the same fixup rules of
        other binary bitwise operations. In the case of `ValueBitLShift`
        We check if we should speculate on BigInt or Untyped and fallback to
        `ArithBitLShift` when both cheks fail.

        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasHeapPrediction):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:

        We updated `operationValueBitLShift` to handle BigInt cases. Also, we
        added `operationBitLShiftBigInt` that is used when we compile
        `ValueBitLValueBitLShift(BigIntUse)`.

        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:

        `ValueBitLShift`'s prediction propagation rules differs from other
        bitwise operations, because using only heap prediction for this node causes
        significant performance regression on Octane's zlib and mandreel.
        The reason is because of cases where a function is compiled but the
        instruction `op_lshift` was never executed before. If we use
        `getPrediction()` we will emit a `ForceOSRExit`, resulting in more OSR
        than desired. To solve such issue, we are then using
        `getPredictionWithoutOSR()` and falling back to `getHeapPrediction()`
        only on cases where we can't rely on node's input types.

        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileValueLShiftOp):
        (JSC::DFG::SpeculativeJIT::compileShiftOp):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::shiftOp):
        * 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::compileArithBitLShift):
        (JSC::FTL::DFG::LowerDFGToB3::compileValueBitLShift):
        (JSC::FTL::DFG::LowerDFGToB3::compileBitLShift): Deleted.
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):

2019-07-12  Keith Miller  <keith_miller@apple.com>

        getIndexQuickly should be const
        https://bugs.webkit.org/show_bug.cgi?id=199747

        Reviewed by Yusuke Suzuki.

        * runtime/Butterfly.h:
        (JSC::Butterfly::indexingPayload const):
        (JSC::Butterfly::arrayStorage const):
        (JSC::Butterfly::contiguousInt32 const):
        (JSC::Butterfly::contiguousDouble const):
        (JSC::Butterfly::contiguous const):
        * runtime/JSObject.h:
        (JSC::JSObject::canGetIndexQuickly const):
        (JSC::JSObject::getIndexQuickly const):
        (JSC::JSObject::tryGetIndexQuickly const):
        (JSC::JSObject::canGetIndexQuickly): Deleted.
        (JSC::JSObject::getIndexQuickly): Deleted.

2019-07-11  Justin Michaud  <justin_michaud@apple.com>

        Add b3 macro lowering for CheckMul on arm64
        https://bugs.webkit.org/show_bug.cgi?id=199251

        Reviewed by Robin Morisset.

        - Lower CheckMul for 32-bit arguments on arm64 into a mul and then an overflow check.
        - Add a new opcode to air on arm64 for smull (multiplySignExtend32).
        - Fuse sign extend 32 + mul into smull (taking two 32-bit arguments and producing 64 bits). 
        - 1.25x speedup on power of two microbenchmark, 1.15x speedup on normal constant microbenchmark, 
          and no change on the no-constant benchmark.
        Also, skip some of the b3 tests that were failing before this patch so that the new tests can run
        to completion.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::multiplySignExtend32):
        * assembler/testmasm.cpp:
        (JSC::testMul32SignExtend):
        (JSC::run):
        * b3/B3LowerMacros.cpp:
        * b3/B3LowerToAir.cpp:
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::testMulArgs32SignExtend):
        (JSC::B3::testMulImm32SignExtend):
        (JSC::B3::testMemoryFence):
        (JSC::B3::testStoreFence):
        (JSC::B3::testLoadFence):
        (JSC::B3::testPinRegisters):
        (JSC::B3::run):

2019-07-11  Yusuke Suzuki  <ysuzuki@apple.com>

        Unreviewed, revert r243617.
        https://bugs.webkit.org/show_bug.cgi?id=196341

        Mark pointed out that JSVirtualMachine can be gone in the other thread while we are executing GC constraint-solving.
        This patch does not account that JavaScriptCore.framework is multi-thread safe: JSVirtualMachine wrapper can be destroyed,
        and [JSVirtualMachine dealloc] can be executed in any threads while the VM is retained and used in the other thread (e.g.
        destroyed from AutoReleasePool in some thread).

        * API/JSContext.mm:
        (-[JSContext initWithVirtualMachine:]):
        (-[JSContext dealloc]):
        (-[JSContext initWithGlobalContextRef:]):
        (-[JSContext wrapperMap]):
        (+[JSContext contextWithJSGlobalContextRef:]):
        * API/JSVirtualMachine.mm:
        (initWrapperCache):
        (wrapperCache):
        (+[JSVMWrapperCache addWrapper:forJSContextGroupRef:]):
        (+[JSVMWrapperCache wrapperForJSContextGroupRef:]):
        (-[JSVirtualMachine initWithContextGroupRef:]):
        (-[JSVirtualMachine dealloc]):
        (+[JSVirtualMachine virtualMachineWithContextGroupRef:]):
        (-[JSVirtualMachine contextForGlobalContextRef:]):
        (-[JSVirtualMachine addContext:forGlobalContextRef:]):
        (scanExternalObjectGraph):
        (scanExternalRememberedSet):
        * API/JSVirtualMachineInternal.h:
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::setWrapperMap):
        (JSC::JSGlobalObject::setAPIWrapper): Deleted.
        (JSC::JSGlobalObject::apiWrapper const): Deleted.
        * runtime/VM.h:

2019-07-10  Tadeu Zagallo  <tzagallo@apple.com>

        Optimize join of large empty arrays
        https://bugs.webkit.org/show_bug.cgi?id=199636

        Reviewed by Mark Lam.

        Replicate the behavior of `str.repeat(count)` when performing `new Array(count + 1).join(str)`.
        I added two new microbenchmarks:
        - large-empty-array-join, which does not use the result of the join and runs ~44x faster and uses ~18x less memory.
        - large-empty-array-join-resolve-rope, which uses the result of the join and runs 2x faster.

                                                    baseline                    diff
        large-empty-array-join                2713.9698+-72.7621    ^     61.2335+-10.4836       ^ definitely 44.3217x faster
        large-empty-array-join-resolve-string   26.5517+-0.3995     ^     12.9309+-0.5516        ^ definitely 2.0533x faster

        large-empty-array-join memory usage with baseline (dirty):
            733012 kB current_mem
            756824 kB lifetime_peak

        large-empty-array-join memory usage with diff (dirty):
            41904 kB current_mem
            41972 kB lifetime_peak

        Additionally, I ran JetStream2, sunspider and v8-spider and all were neutral.

        * runtime/ArrayPrototype.cpp:
        (JSC::fastJoin):

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

        Enable Intl.PluralRules and Intl.NumberFormatToParts by default
        https://bugs.webkit.org/show_bug.cgi?id=199288

        Reviewed by Yusuke Suzuki.

        These features have been around for a while. We should turn them on by default.

        * runtime/IntlNumberFormatPrototype.cpp:
        (JSC::IntlNumberFormatPrototype::finishCreation):
        * runtime/IntlObject.cpp:
        (JSC::IntlObject::finishCreation): Deleted.
        * runtime/IntlObject.h:
        * runtime/Options.h:

2019-07-08  Antoine Quint  <graouts@apple.com>

        [Pointer Events] Enable only on the most recent version of the supported iOS family
        https://bugs.webkit.org/show_bug.cgi?id=199562
        <rdar://problem/52766511>

        Reviewed by Dean Jackson.

        * Configurations/FeatureDefines.xcconfig:

2019-07-06  Michael Saboff  <msaboff@apple.com>

        switch(String) needs to check for exceptions when resolving the string
        https://bugs.webkit.org/show_bug.cgi?id=199541

        Reviewed by Mark Lam.

        Added exception checks for resolved Strings in switch processing for all tiers.

        * dfg/DFGOperations.cpp:
        * jit/JITOperations.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):

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

        ArgumentsEliminationPhase::eliminateCandidatesThatInterfere() should not decrement nodeIndex pass zero.
        https://bugs.webkit.org/show_bug.cgi?id=199533
        <rdar://problem/52669111>

        Reviewed by Filip Pizlo.

        * dfg/DFGArgumentsEliminationPhase.cpp:

2019-07-05  Yusuke Suzuki  <ysuzuki@apple.com>

        Unreviewed, fix build failure on ARM64_32
        https://bugs.webkit.org/show_bug.cgi?id=182434

        Implicit narrowing from uint64_t to uint32_t happens. We should explicitly narrow it because we already checked
        the `length` is <= UINT32_MAX.

        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncSpeciesCreate):

2019-07-05  Alexey Shvayka  <shvaikalesh@gmail.com>

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

        Reviewed by Yusuke Suzuki.

        We have duplicate code in arraySpeciesCreate, filter, map, concatSlowPath of ArrayPrototype.js
        and speciesConstructArray of ArrayPrototype.cpp. This patch fixes cross-realm Array constructor
        detection in native speciesConstructArray, upgrades `length` type to correctly handle large integers,
        and exposes it as @arraySpeciesCreate. Also removes now unused @isArrayConstructor private function.
        Native speciesConstructArray is preferred because it has fast path via speciesWatchpointIsValid.

        Thoroughly benchmarked: this change progresses ARES-6 by 0-1%.

        * builtins/ArrayPrototype.js:
        (filter):
        (map):
        (globalPrivate.concatSlowPath):
        (globalPrivate.arraySpeciesCreate): Deleted.
        * builtins/BuiltinNames.h:
        * runtime/ArrayConstructor.cpp:
        (JSC::arrayConstructorPrivateFuncIsArrayConstructor): Deleted.
        * runtime/ArrayConstructor.h:
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncSpeciesCreate):
        * runtime/ArrayPrototype.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):

2019-07-05  Tadeu Zagallo  <tzagallo@apple.com>

        Unreviewed, change the value used to scribble Heap::m_worldState
        https://bugs.webkit.org/show_bug.cgi?id=199498

        Follow-up after r247160. The value used to scribble should have the
        conn bit set.

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

2019-07-05  Ryan Haddad  <ryanhaddad@apple.com>

        Unreviewed, rolling out r247115.

        Breaks lldbWebKitTester (and by extension, test-webkitpy)

        Reverted changeset:

        "[WHLSL] Standard library is too big to directly include in
        WebCore"
        https://bugs.webkit.org/show_bug.cgi?id=198186
        https://trac.webkit.org/changeset/247115

2019-07-05  Tadeu Zagallo  <tzagallo@apple.com>

        Scribble Heap::m_worldState on destructor
        https://bugs.webkit.org/show_bug.cgi?id=199498

        Reviewed by Sam Weinig.

        The worldState is dumped when we crash due to a failed checkConn, and
        this will make it clear if the heap has already been destroyed.

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

2019-07-03  Sam Weinig  <weinig@apple.com>

        Adopt simple structured bindings in more places
        https://bugs.webkit.org/show_bug.cgi?id=199247

        Reviewed by Alex Christensen.

        Replaces simple uses of std::tie() with structured bindings. Does not touch
        uses of std::tie() that are not initial declarations, use std::ignore or in
        case where the binding is captured by a lambda, as structured bindings don't
        work for those cases yet.

        * runtime/PromiseDeferredTimer.cpp:
        (JSC::PromiseDeferredTimer::doWork):
        * wasm/WasmFaultSignalHandler.cpp:
        (JSC::Wasm::trapHandler):
        * wasm/js/JSWebAssemblyHelpers.h:
        (JSC::createSourceBufferFromValue):
        * wasm/js/WebAssemblyPrototype.cpp:
        (JSC::webAssemblyValidateFunc):

2019-07-03  Keith Miller  <keith_miller@apple.com>

        PACCage should first cage leaving PAC bits intact then authenticate
        https://bugs.webkit.org/show_bug.cgi?id=199372

        Reviewed by Saam Barati.

        This ordering prevents someone from taking a signed pointer from
        outside the gigacage and using it in a struct that expects a caged
        pointer. Previously, the PACCaging just double checked that the PAC
        bits were valid for the original pointer.


               +---------------------------+
               |       |        |          |
               | "PAC" | "base" | "offset" +----+
               |       |        |          |    |
               +---------------------------+    | Caging
                |                               |
                |                               |
                |                               v
                |                +---------------------------+
                |                |       |        |          |
                | Bit Merge      | 00000 |  base  | "offset" |
                |                |       |        |          |
                |                +---------------------------+
                |                               |
                |                               |
                v                               |  Bit Merge
          +---------------------------+         |
          |       |        |          |         |
          | "PAC" |  base  | "offset" +<--------+
          |       |        |          |
          +---------------------------+
                      |
                      |
                      | Authenticate
                      |
                      v
          +---------------------------+
          |       |        |          |
          | Auth  |  base  | "offset" |
          |       |        |          |
          +---------------------------+

        The above ascii art graph shows how the PACCage system works. The
        key take away is that even if someone passes in a valid, signed
        pointer outside the cage it will still fail to authenticate as the
        "base" bits will change before authentication.


        * assembler/MacroAssemblerARM64E.h:
        * assembler/testmasm.cpp:
        (JSC::testCagePreservesPACFailureBit):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::caged):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::cageConditionally):
        * llint/LowLevelInterpreter64.asm:

2019-07-03  Paulo Matos  <pmatos@igalia.com>

        Refactoring of architectural Register Information
        https://bugs.webkit.org/show_bug.cgi?id=198604

        Reviewed by Keith Miller.

        The goal of this patch is to centralize the register information per platform
        but access it in a platform independent way. The patch as been implemented for all
        known platforms: ARM64, ARMv7, MIPS, X86 and X86_64. Register information has
        been centralized in an architecture per-file: each file is called assembler/<arch>Registers.h.

        RegisterInfo.h is used as a forwarding header to choose which register information to load.
        assembler/<arch>Assembler.h and jit/RegisterSet.cpp use this information in a platform
        independent way.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/ARM64Assembler.h:
        (JSC::ARM64Assembler::gprName): Use register names from register info file.
        (JSC::ARM64Assembler::sprName): likewise.
        (JSC::ARM64Assembler::fprName): likewise.
        * assembler/ARM64Registers.h: Added.
        * assembler/ARMv7Assembler.h:
        (JSC::ARMv7Assembler::gprName): Use register names from register info file.
        (JSC::ARMv7Assembler::sprName): likewise.
        (JSC::ARMv7Assembler::fprName): likewise.
        * assembler/ARMv7Registers.h: Added.
        * assembler/MIPSAssembler.h:
        (JSC::MIPSAssembler::gprName): Use register names from register info file.
        (JSC::MIPSAssembler::sprName): likewise.
        (JSC::MIPSAssembler::fprName): likewise.
        * assembler/MIPSRegisters.h: Added.
        * assembler/RegisterInfo.h: Added.
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::gprName): Use register names from register info file.
        (JSC::X86Assembler::sprName): likewise.
        (JSC::X86Assembler::fprName): likewise.
        * assembler/X86Registers.h: Added.
        * assembler/X86_64Registers.h: Added.
        * jit/GPRInfo.h: Fix typo in comment (s/basline/baseline).
        * jit/RegisterSet.cpp:
        (JSC::RegisterSet::reservedHardwareRegisters): Use register properties from register info file.
        (JSC::RegisterSet::calleeSaveRegisters): likewise.

2019-07-02  Michael Saboff  <msaboff@apple.com>

        Exception from For..of loop destructured assignment eliminates TDZ checks in subsequent code
        https://bugs.webkit.org/show_bug.cgi?id=199395

        Reviewed by Filip Pizlo.

        For destructuring assignmests, the assignment might throw a reference error if
        the RHS cannot be coerced.  The current bytecode generated for such assignments
        optimizes out the TDZ check after the coercible check.

        By saving the current state of the TDZ stack before processing the setting of 
        target destructured values and then restoring afterwards, we won't optimize out
        later TDZ check(s).

        A similar change of saving / restoring the TDZ stack where exceptions might
        happen was done for for..in loops in change set r232219.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::ObjectPatternNode::bindValue const):

2019-07-02  Commit Queue  <commit-queue@webkit.org>

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

        broke some iOS arm64e tests (Requested by keith_miller on
        #webkit).

        Reverted changeset:

        "PACCage should first cage leaving PAC bits intact then
        authenticate"
        https://bugs.webkit.org/show_bug.cgi?id=199372
        https://trac.webkit.org/changeset/247041

2019-07-02  Keith Miller  <keith_miller@apple.com>

        Frozen Arrays length assignment should throw in strict mode
        https://bugs.webkit.org/show_bug.cgi?id=199365

        Reviewed by Yusuke Suzuki.

        * runtime/JSArray.cpp:
        (JSC::JSArray::put):

2019-07-02  Paulo Matos  <pmatos@linki.tools>

        Fix typo in if/else block and remove dead assignment
        https://bugs.webkit.org/show_bug.cgi?id=199352

        Reviewed by Alexey Proskuryakov.

        * yarr/YarrPattern.cpp:
        (JSC::Yarr::YarrPattern::dumpPattern): Fix typo in if/else block and remove dead assignment

2019-07-02  Keith Miller  <keith_miller@apple.com>

        PACCage should first cage leaving PAC bits intact then authenticate
        https://bugs.webkit.org/show_bug.cgi?id=199372

        Reviewed by Saam Barati.

        This ordering prevents someone from taking a signed pointer from
        outside the gigacage and using it in a struct that expects a caged
        pointer. Previously, the PACCaging just double checked that the PAC
        bits were valid for the original pointer.


               +---------------------------+
               |       |        |          |
               | "PAC" | "base" | "offset" +----+
               |       |        |          |    |
               +---------------------------+    | Caging
                |                               |
                |                               |
                |                               v
                |                +---------------------------+
                |                |       |        |          |
                | Bit Merge      | 00000 |  base  | "offset" |
                |                |       |        |          |
                |                +---------------------------+
                |                               |
                |                               |
                v                               |  Bit Merge
          +---------------------------+         |
          |       |        |          |         |
          | "PAC" |  base  | "offset" +<--------+
          |       |        |          |
          +---------------------------+
                      |
                      |
                      | Authenticate
                      |
                      v
          +---------------------------+
          |       |        |          |
          | Auth  |  base  | "offset" |
          |       |        |          |
          +---------------------------+

        The above ascii art graph shows how the PACCage system works. The
        key take away is that even if someone passes in a valid, signed
        pointer outside the cage it will still fail to authenticate as the
        "base" bits will change before authentication.


        * assembler/MacroAssemblerARM64E.h:
        * assembler/testmasm.cpp:
        (JSC::testCagePreservesPACFailureBit):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::caged):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::cageConditionally):
        * llint/LowLevelInterpreter64.asm:

2019-07-01  Justin Michaud  <justin_michaud@apple.com>

        [Wasm-References] Disable references by default
        https://bugs.webkit.org/show_bug.cgi?id=199390

        Reviewed by Saam Barati.

        * runtime/Options.h:

2019-07-01  Ryan Haddad  <ryanhaddad@apple.com>

        Unreviewed, rolling out r246946.

        Caused JSC test crashes on arm64

        Reverted changeset:

        "Add b3 macro lowering for CheckMul on arm64"
        https://bugs.webkit.org/show_bug.cgi?id=199251
        https://trac.webkit.org/changeset/246946

2019-06-28  Justin Michaud  <justin_michaud@apple.com>

        Add b3 macro lowering for CheckMul on arm64
        https://bugs.webkit.org/show_bug.cgi?id=199251

        Reviewed by Robin Morisset.

        - Lower CheckMul for 32-bit arguments on arm64 into a mul and then an overflow check.
        - Add a new opcode to air on arm64 for smull (multiplySignExtend32).
        - Fuse sign extend 32 + mul into smull (taking two 32-bit arguments and producing 64 bits). 
        - 1.25x speedup on power of two microbenchmark, 1.15x speedup on normal constant microbenchmark, 
          and no change on the no-constant benchmark.
        Also, skip some of the b3 tests that were failing before this patch so that the new tests can run
        to completion.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::multiplySignExtend32):
        * assembler/testmasm.cpp:
        (JSC::testMul32SignExtend):
        (JSC::run):
        * b3/B3LowerMacros.cpp:
        * b3/B3LowerToAir.cpp:
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::testMulArgs32SignExtend):
        (JSC::B3::testMulImm32SignExtend):
        (JSC::B3::testMemoryFence):
        (JSC::B3::testStoreFence):
        (JSC::B3::testLoadFence):
        (JSC::B3::testPinRegisters):
        (JSC::B3::run):

2019-06-28  Konstantin Tokarev  <annulen@yandex.ru>

        Remove traces of ENABLE_ICONDATABASE remaining after its removal in 219733
        https://bugs.webkit.org/show_bug.cgi?id=199317

        Reviewed by Michael Catanzaro.

        While IconDatabase and all code using it was removed,
        ENABLE_ICONDATABASE still exists as build option and C++ macro.

        * Configurations/FeatureDefines.xcconfig:

2019-06-27  Mark Lam  <mark.lam@apple.com>

        FTL keepAlive()'s patchpoint should also declare that it reads HeapRange::top().
        https://bugs.webkit.org/show_bug.cgi?id=199291

        Reviewed by Yusuke Suzuki and Filip Pizlo.

        The sole purpose of keepAlive() is to communicate to B3 that an LValue
        needs to be kept alive past the last opportunity for a GC.  The only way
        we can get a GC is via a function call.  Hence, what keepAlive() really
        needs to communicate is that the LValue needs to be kept alive past the
        last function call.  Function calls read and write HeapRange::top().
        Currently, B3 does not shuffle writes.  Hence, simply inserting the
        keepAlive() after the calls that can GC is sufficient.

        But to be strictly correct, keepAlive() should also declare that it reads
        HeapRange::top().  This will guarantee that the keepAlive patchpoint won't
        ever be moved before the function call should B3 gain the ability to shuffle
        writes in the future.

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

2019-06-27  Beth Dakin  <bdakin@apple.com>

        Upstream use of MACCATALYST
        https://bugs.webkit.org/show_bug.cgi?id=199245
        rdar://problem/51687723

        Reviewed by Tim Horton.

        * Configurations/Base.xcconfig:
        * Configurations/FeatureDefines.xcconfig:
        * Configurations/JavaScriptCore.xcconfig:
        * Configurations/SDKVariant.xcconfig:

2019-06-27  Saam Barati  <sbarati@apple.com>

        Make WEBGPU enabled only on Mojave and later.

        Rubber-stamped by Myles C. Maxfield.

        * Configurations/FeatureDefines.xcconfig:

2019-06-27  Don Olmstead  <don.olmstead@sony.com>

        [FTW] Build JavaScriptCore
        https://bugs.webkit.org/show_bug.cgi?id=199254

        Reviewed by Brent Fulgham.

        * PlatformFTW.cmake: Added.

2019-06-27  Konstantin Tokarev  <annulen@yandex.ru>

        Use JSC_GLIB_API_ENABLED instead of USE(GLIB) as a compile-time check for GLib JSC API
        https://bugs.webkit.org/show_bug.cgi?id=199270

        Reviewed by Michael Catanzaro.

        This change allows building code with enabled USE(GLIB) but without
        GLib JSC API.

        * heap/Heap.cpp:
        (JSC::Heap::releaseDelayedReleasedObjects):
        * heap/Heap.h:
        * heap/HeapInlines.h:

2019-06-27  Devin Rousso  <drousso@apple.com>

        Web Inspector: throw an error if console.count/console.countReset is called with an object that throws an error from toString
        https://bugs.webkit.org/show_bug.cgi?id=199252

        Reviewed by Joseph Pecoraro.

        Parse the arguments passed to `console.count` and `console.countReset` before sending it to
        the `ConsoleClient` so that an error can be thrown if the first argument doesn't `toString`
        nicely (e.g. without throwing an error).

        Generate call stacks for `console.countReset` to match other `console` methods. Also do this
        for `console.time`, `console.timeLog`, and `console.timeEnd`. Limit the call stack to only
        have the top frame, so no unnecessary/extra data is sent to the frontend (right now, only
        the call location is displayed).

        Rename `title` to `label` for `console.time`, `console.timeLog`, and `console.timeEnd` to
        better match the spec.

        * runtime/ConsoleClient.h:
        * runtime/ConsoleObject.cpp:
        (JSC::valueOrDefaultLabelString):
        (JSC::consoleProtoFuncCount):
        (JSC::consoleProtoFuncCountReset):
        (JSC::consoleProtoFuncTime):
        (JSC::consoleProtoFuncTimeLog):
        (JSC::consoleProtoFuncTimeEnd):

        * inspector/JSGlobalObjectConsoleClient.h:
        * inspector/JSGlobalObjectConsoleClient.cpp:
        (Inspector::JSGlobalObjectConsoleClient::count):
        (Inspector::JSGlobalObjectConsoleClient::countReset):
        (Inspector::JSGlobalObjectConsoleClient::time):
        (Inspector::JSGlobalObjectConsoleClient::timeLog):
        (Inspector::JSGlobalObjectConsoleClient::timeEnd):

        * inspector/agents/InspectorConsoleAgent.h:
        * inspector/agents/InspectorConsoleAgent.cpp:
        (Inspector::InspectorConsoleAgent::startTiming):
        (Inspector::InspectorConsoleAgent::logTiming):
        (Inspector::InspectorConsoleAgent::stopTiming):
        (Inspector::InspectorConsoleAgent::count):
        (Inspector::InspectorConsoleAgent::countReset):
        (Inspector::InspectorConsoleAgent::getCounterLabel): Deleted.

        * inspector/ConsoleMessage.h:
        * inspector/ConsoleMessage.cpp:
        (Inspector::ConsoleMessage::ConsoleMessage):
        Allow `ConsoleMessage`s to be created with both `ScriptArguments` and a `ScriptCallStack`.

2019-06-27  Fujii Hironori  <Hironori.Fujii@sony.com>

        [CMake] Bump cmake_minimum_required version to 3.10
        https://bugs.webkit.org/show_bug.cgi?id=199181

        Reviewed by Don Olmstead.

        * CMakeLists.txt:

2019-06-26  Basuke Suzuki  <Basuke.Suzuki@sony.com>

        [RemoteInspector] Add address argument to listen for RemoteInspectorServer Socket implementation.
        https://bugs.webkit.org/show_bug.cgi?id=199035

        Reviewed by Ross Kirsling.

        Added new argument `address` to start listening. 

        * inspector/remote/socket/RemoteInspectorServer.cpp:
        (Inspector::RemoteInspectorServer::start):
        * inspector/remote/socket/RemoteInspectorServer.h:
        * inspector/remote/socket/posix/RemoteInspectorSocketPOSIX.cpp:
        (Inspector::Socket::listen):
        * inspector/remote/socket/win/RemoteInspectorSocketWin.cpp:
        (Inspector::Socket::listen):

2019-06-26  Keith Miller  <keith_miller@apple.com>

        speciesConstruct needs to throw if the result is a DataView
        https://bugs.webkit.org/show_bug.cgi?id=199231

        Reviewed by Mark Lam.

        Previously, we only checked that the result was a
        JSArrayBufferView, which can include DataViews. This is incorrect
        as the result should be only be a TypedArray.

        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::speciesConstruct):

2019-06-26  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Implement console.countReset
        https://bugs.webkit.org/show_bug.cgi?id=199200

        Reviewed by Devin Rousso.

        * inspector/JSGlobalObjectConsoleClient.cpp:
        (Inspector::JSGlobalObjectConsoleClient::countReset):
        * inspector/JSGlobalObjectConsoleClient.h:
        * inspector/agents/InspectorConsoleAgent.cpp:
        (Inspector::InspectorConsoleAgent::getCounterLabel):
        (Inspector::InspectorConsoleAgent::count):
        (Inspector::InspectorConsoleAgent::countReset):
        * inspector/agents/InspectorConsoleAgent.h:
        * runtime/ConsoleClient.h:
        * runtime/ConsoleObject.cpp:
        (JSC::ConsoleObject::finishCreation):
        (JSC::consoleProtoFuncCountReset):

2019-06-26  Keith Miller  <keith_miller@apple.com>

        remove unneeded didBecomePrototype() calls
        https://bugs.webkit.org/show_bug.cgi?id=199221

        Reviewed by Saam Barati.

        Since we now set didBecomePrototype in Structure::create we don't
        need to set it expliticly in most of our finishCreation
        methods. The only exception to this is object prototype, which we
        set as the prototype of function prototype late (via
        setPrototypeWithoutTransition).

        * 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/GeneratorFunctionPrototype.cpp:
        (JSC::GeneratorFunctionPrototype::finishCreation):
        * runtime/GeneratorPrototype.cpp:
        (JSC::GeneratorPrototype::finishCreation):
        * runtime/IteratorPrototype.cpp:
        (JSC::IteratorPrototype::finishCreation):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/MapIteratorPrototype.cpp:
        (JSC::MapIteratorPrototype::finishCreation):
        * runtime/MapPrototype.cpp:
        (JSC::MapPrototype::finishCreation):
        * runtime/ObjectPrototype.cpp:
        (JSC::ObjectPrototype::finishCreation):
        * runtime/RegExpStringIteratorPrototype.cpp:
        (JSC::RegExpStringIteratorPrototype::finishCreation):
        * runtime/SetIteratorPrototype.cpp:
        (JSC::SetIteratorPrototype::finishCreation):
        * runtime/SetPrototype.cpp:
        (JSC::SetPrototype::finishCreation):
        * runtime/StringIteratorPrototype.cpp:
        (JSC::StringIteratorPrototype::finishCreation):
        * runtime/WeakMapPrototype.cpp:
        (JSC::WeakMapPrototype::finishCreation):
        * runtime/WeakObjectRefPrototype.cpp:
        (JSC::WeakObjectRefPrototype::finishCreation):
        * runtime/WeakSetPrototype.cpp:
        (JSC::WeakSetPrototype::finishCreation):

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

        Structure::create should call didBecomePrototype()
        https://bugs.webkit.org/show_bug.cgi?id=196315

        Reviewed by Filip Pizlo.

        Structure::create should also assert that the indexing type makes sense
        for the prototype being used.

        * runtime/JSObject.h:
        * runtime/Structure.cpp:
        (JSC::Structure::isValidPrototype):
        (JSC::Structure::changePrototypeTransition):
        * runtime/Structure.h:
        (JSC::Structure::create): Deleted.
        * runtime/StructureInlines.h:
        (JSC::Structure::create):
        (JSC::Structure::setPrototypeWithoutTransition):

2019-06-25  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Implement console.timeLog
        https://bugs.webkit.org/show_bug.cgi?id=199184

        Reviewed by Devin Rousso.

        * inspector/JSGlobalObjectConsoleClient.cpp:
        (Inspector::JSGlobalObjectConsoleClient::timeLog):
        * inspector/JSGlobalObjectConsoleClient.h:
        * inspector/agents/InspectorConsoleAgent.cpp:
        (Inspector::InspectorConsoleAgent::logTiming):
        (Inspector::InspectorConsoleAgent::stopTiming):
        * inspector/agents/InspectorConsoleAgent.h:
        * runtime/ConsoleClient.h:
        * runtime/ConsoleObject.cpp:
        (JSC::ConsoleObject::finishCreation):
        (JSC::consoleProtoFuncTimeLog):

2019-06-25  Michael Catanzaro  <mcatanzaro@igalia.com>

        REGRESSION(r245586): static assertion failed: Match result and EncodedMatchResult should be the same size
        https://bugs.webkit.org/show_bug.cgi?id=198518

        Reviewed by Keith Miller.

        r245586 made some bad assumptions about the size of size_t, which we can solve using the
        CPU(ADDRESS32) guard that I didn't know about.

        This solution was developed by Mark Lam and Keith Miller. I'm just preparing the patch.

        * runtime/MatchResult.h:

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

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

        revert to do patch in a different way. (Requested by keith_mi_
        on #webkit).

        Reverted changeset:

        "All prototypes should call didBecomePrototype()"
        https://bugs.webkit.org/show_bug.cgi?id=196315
        https://trac.webkit.org/changeset/246714

2019-06-24  Alexey Shvayka  <shvaikalesh@gmail.com>

        Add Array.prototype.{flat,flatMap} to unscopables
        https://bugs.webkit.org/show_bug.cgi?id=194322

        Reviewed by Keith Miller.

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

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

        ArraySlice needs to keep the source array alive.
        https://bugs.webkit.org/show_bug.cgi?id=197374
        <rdar://problem/50304429>

        Reviewed by Michael Saboff and Filip Pizlo.

        The implementation of the FTL ArraySlice intrinsics may GC while allocating the
        result array and its butterfly.  Previously, ArraySlice already keeps the source
        butterfly alive in order to copy from it to the new butterfly after the allocation.
        Unfortunately, this is not enough.  We also need to keep the source array alive
        so that GC will scan the values in the butterfly as well.  Note: the butterfly
        does not have a visitChildren() method to do this scan.  It's the parent object's
        responsibility to do the scanning.

        This patch fixes this by introducing a keepAlive() utility method, and we use it
        to keep the source array alive while allocating the result array and butterfly.

        keepAlive() works by using a patchpoint to communicate to B3 that a value (the
        source array in this case) is still in use.  It also uses a fence to keep B3 from
        relocating the patchpoint, which may defeat the fix.

        For the DFG's SpeculativeJIT::compileArraySlice(), we may have lucked out and the
        source array cell is kept alive.  This patch makes it explicit that we should
        keep its cell alive till after the result array has been allocated.

        For the Baseline JIT and LLInt, we use the arrayProtoFuncSlice() runtime function
        and there is no issue because the source array (in "thisObj") is in the element
        copying loop that follows the allocation of the result array.  However, for
        documentation purposes, this patch adds a call to HeapCell::use() to indicate that
        the source array need to kept alive at least until after the allocation of the
        result array.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArraySlice):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileArraySlice):
        (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
        (JSC::FTL::DFG::LowerDFGToB3::keepAlive):
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncSlice):

2019-06-22  Robin Morisset  <rmorisset@apple.com> and Yusuke Suzuki  <ysuzuki@apple.com>

        All prototypes should call didBecomePrototype()
        https://bugs.webkit.org/show_bug.cgi?id=196315

        Reviewed by Saam Barati.

        Otherwise we won't remember to run haveABadTime() when someone adds to them an indexed accessor.

        I added a check used in both Structure::finishCreation() and Structure::changePrototypeTransition to make sure we don't
        create structures with invalid prototypes.
        It found a lot of objects that are used as prototypes in JSGlobalObject and yet were missing didBecomePrototype() in their finishCreation().
        Somewhat surprisingly, some of them have names like FunctionConstructor and not only FooPrototype.

        * runtime/BigIntPrototype.cpp:
        (JSC::BigIntPrototype::finishCreation):
        * runtime/BooleanPrototype.cpp:
        (JSC::BooleanPrototype::finishCreation):
        * runtime/DatePrototype.cpp:
        (JSC::DatePrototype::finishCreation):
        * runtime/ErrorConstructor.cpp:
        (JSC::ErrorConstructor::finishCreation):
        * runtime/ErrorPrototype.cpp:
        (JSC::ErrorPrototype::finishCreation):
        * runtime/FunctionConstructor.cpp:
        (JSC::FunctionConstructor::finishCreation):
        * runtime/FunctionPrototype.cpp:
        (JSC::FunctionPrototype::finishCreation):
        * runtime/IntlCollatorPrototype.cpp:
        (JSC::IntlCollatorPrototype::finishCreation):
        * runtime/IntlDateTimeFormatPrototype.cpp:
        (JSC::IntlDateTimeFormatPrototype::finishCreation):
        * runtime/IntlNumberFormatPrototype.cpp:
        (JSC::IntlNumberFormatPrototype::finishCreation):
        * runtime/IntlPluralRulesPrototype.cpp:
        (JSC::IntlPluralRulesPrototype::finishCreation):
        * runtime/JSArrayBufferPrototype.cpp:
        (JSC::JSArrayBufferPrototype::finishCreation):
        * runtime/JSDataViewPrototype.cpp:
        (JSC::JSDataViewPrototype::finishCreation):
        * runtime/JSGenericTypedArrayViewPrototypeInlines.h:
        (JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
        * runtime/JSGlobalObject.cpp:
        (JSC::createConsoleProperty):
        * runtime/JSPromisePrototype.cpp:
        (JSC::JSPromisePrototype::finishCreation):
        * runtime/JSTypedArrayViewConstructor.cpp:
        (JSC::JSTypedArrayViewConstructor::finishCreation):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::JSTypedArrayViewPrototype::finishCreation):
        * runtime/NumberPrototype.cpp:
        (JSC::NumberPrototype::finishCreation):
        * runtime/RegExpPrototype.cpp:
        (JSC::RegExpPrototype::finishCreation):
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        * runtime/Structure.cpp:
        (JSC::Structure::isValidPrototype):
        (JSC::Structure::changePrototypeTransition):
        * runtime/Structure.h:
        * runtime/StructureInlines.h:
        (JSC::Structure::setPrototypeWithoutTransition):
        * runtime/SymbolPrototype.cpp:
        (JSC::SymbolPrototype::finishCreation):
        * wasm/js/WebAssemblyCompileErrorPrototype.cpp:
        (JSC::WebAssemblyCompileErrorPrototype::finishCreation):
        * wasm/js/WebAssemblyInstancePrototype.cpp:
        (JSC::WebAssemblyInstancePrototype::finishCreation):
        * wasm/js/WebAssemblyLinkErrorPrototype.cpp:
        (JSC::WebAssemblyLinkErrorPrototype::finishCreation):
        * wasm/js/WebAssemblyMemoryPrototype.cpp:
        (JSC::WebAssemblyMemoryPrototype::finishCreation):
        * wasm/js/WebAssemblyModulePrototype.cpp:
        (JSC::WebAssemblyModulePrototype::finishCreation):
        * wasm/js/WebAssemblyPrototype.cpp:
        (JSC::WebAssemblyPrototype::finishCreation):
        * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
        (JSC::WebAssemblyRuntimeErrorPrototype::finishCreation):
        * wasm/js/WebAssemblyTablePrototype.cpp:
        (JSC::WebAssemblyTablePrototype::finishCreation):

2019-06-22  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Strict, Sloppy and Arrow functions should have different classInfo
        https://bugs.webkit.org/show_bug.cgi?id=197631

        Reviewed by Saam Barati.

        If a constructor inherits a builtin class, it creates a Structure which is subclassing the builtin class.
        This is done by using InternalFunction::createSubclassStructure. But to accelerate the common cases, we
        cache the created structure in InternalFunctionAllocationProfile. Whether the cache is valid is checked
        by comparing classInfo of the cached structure and the given base structure. This implicitly assume that
        each builtin class's InternalFunction creates an instance based on one structure.

        However, Function constructor is an exception: Function constructor creates an instance which has different
        structures based on a parameter. If a strict code is given (e.g. "'use strict'"), it creates a function
        instance with strict function structure.

        As a result, InternalFunctionAllocationProfile incorrectly caches the structure. Consider the following code.

            class A extends Function { };
            let a = new A("'use strict'");
            let b = new A("");

        While `a` and `b` should have different structures, `A` caches the structure for `a`, and reuse it even the given
        code is not a strict code. This is problematic: We are separating structures of strict, sloppy, and arrow functions
        because they have different properties. However, in the above case, a and b have the same structure while they have
        different properties. So it causes incorrect structure-based caching in JSC. One of the example is HasOwnPropertyCache.

        In this patch, we introduce JSStrictFunction, JSSloppyFunction, and JSArrowFunction classes and classInfos. This design
        works well and already partially accepted for JSGeneratorFunction, JSAsyncGeneratorFunction, and JSAsyncFunction. Each
        structure now has a different classInfo so that InternalFunctionAllocationProfile correctly caches and invalidates the
        cached one based on the classInfo. Since we already have different structures for these instances, and DFG and FTL
        optimizations are based on JSFunctionType (not classInfo), introducing these three classInfo do not break the optimization.

        Note that structures on ArrayConstructor does not cause the same problem. It only uses Undecided indexing typed array
        structure in InternalFunctionAllocationProfile, and once haveABadTime happens, it clears InternalFunctionAllocationProfile.

        * runtime/JSAsyncFunction.h: This subspaceFor is not necessary since it is defined in JSFunction. And we already ensure that
        sizeof(JSAsyncFunction) == sizeof(JSFunction).
        * runtime/JSAsyncGeneratorFunction.cpp:
        * runtime/JSAsyncGeneratorFunction.h: Ditto.
        * runtime/JSFunction.cpp:
        * runtime/JSFunction.h:
        * runtime/JSGeneratorFunction.h: Ditto.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):

2019-06-22  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] ClassExpr should not store result in the middle of evaluation
        https://bugs.webkit.org/show_bug.cgi?id=199106

        Reviewed by Tadeu Zagallo.

        Let's consider the case,

            let a = class A {
                static get[a=0x12345678]() {
                }
            };

        When evaluating `class A` expression, we should not use the local register for `let a`
        until we finally store it to that register. Otherwise, `a=0x12345678` will override it.
        Out BytecodeGenerator does that this by using tempDestination and finalDestination, but
        we did not do that in ClassExprNode.

        This patch leverages tempDestination and finalDestination to store `class A` result finally,
        while we attempt to reduce mov.

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

2019-06-21  Sihui Liu  <sihui_liu@apple.com>

        openDatabase should return an empty object when WebSQL is disabled
        https://bugs.webkit.org/show_bug.cgi?id=198805

        Reviewed by Geoffrey Garen.

        * runtime/JSFunction.cpp:
        (JSC::JSFunction::createFunctionThatMasqueradesAsUndefined):
        * runtime/JSFunction.h:

2019-06-21  Alexey Shvayka  <shvaikalesh@gmail.com>

        Remove extra check in RegExp @matchSlow
        https://bugs.webkit.org/show_bug.cgi?id=198846

        Reviewed by Joseph Pecoraro.

        Type of RegExp `exec` result is already asserted in @regExpExec.

        * builtins/RegExpPrototype.js:
        (globalPrivate.matchSlow): Remove isObject check.

2019-06-20  Justin Michaud  <justin_michaud@apple.com>

        [WASM-References] Add extra tests for Wasm references + fix element parsing and subtyping bugs
        https://bugs.webkit.org/show_bug.cgi?id=199044

        Reviewed by Saam Barati.

        Fix parsing table indices from the element section. The byte that we previously read as the table index actually tells us how to parse the table index.
        Fix some areas where we got the isSubtype check wrong, causing funcrefs to not be considred anyrefs.

        * wasm/WasmAirIRGenerator.cpp:
        (JSC::Wasm::AirIRGenerator::unify):
        * wasm/WasmSectionParser.cpp:
        (JSC::Wasm::SectionParser::parseElement):
        * wasm/WasmValidate.cpp:
        (JSC::Wasm::Validate::unify):

2019-06-18  Darin Adler  <darin@apple.com>

        Tidy up the remaining bits of the AtomicString to AtomString rename
        https://bugs.webkit.org/show_bug.cgi?id=198990

        Reviewed by Michael Catanzaro.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::speculateStringIdentAndLoadStorage): Use flagIsAtom.
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): Ditto.
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): Ditto.
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileHasOwnProperty): Ditto.
        (JSC::FTL::DFG::LowerDFGToB3::speculateStringIdent): Ditto.

2019-06-19  Alexey Shvayka  <shvaikalesh@gmail.com>

        Optimize `resolve` method lookup in Promise static methods
        https://bugs.webkit.org/show_bug.cgi?id=198864

        Reviewed by Yusuke Suzuki.

        Lookup `resolve` method only once in Promise.{all,allSettled,race}.
        (https://github.com/tc39/ecma262/pull/1506)

        Already implemented in V8.

        * builtins/PromiseConstructor.js:

2019-06-19  Tadeu Zagallo  <tzagallo@apple.com>

        Some of the ASSERTs in CachedTypes.cpp should be RELEASE_ASSERTs
        https://bugs.webkit.org/show_bug.cgi?id=199030

        Reviewed by Mark Lam.

        These assertions represent strong assumptions that the cache makes so
        it's not safe to keep executing if they fail.

        * runtime/CachedTypes.cpp:
        (JSC::Encoder::malloc):
        (JSC::Encoder::Page::alignEnd):
        (JSC::Decoder::ptrForOffsetFromBase):
        (JSC::Decoder::handleForEnvironment const):
        (JSC::Decoder::setHandleForEnvironment):
        (JSC::CachedPtr::get const):
        (JSC::CachedOptional::encode):
        (JSC::CachedOptional::decodeAsPtr const): Deleted.

2019-06-19  Adrian Perez de Castro  <aperez@igalia.com>

        [WPE][GTK] Fix build with unified sources disabled
        https://bugs.webkit.org/show_bug.cgi?id=198752

        Reviewed by Michael Catanzaro.

        * runtime/WeakObjectRefConstructor.h: Add missing inclusion of InternalFunction.h
        and forward declaration of WeakObjectRefPrototype.
        * wasm/js/WebAssemblyFunction.cpp: Add missing inclusion of JSWebAssemblyHelpers.h

2019-06-19  Justin Michaud  <justin_michaud@apple.com>

        [WASM-References] Rename anyfunc to funcref
        https://bugs.webkit.org/show_bug.cgi?id=198983

        Reviewed by Yusuke Suzuki.

        Anyfunc should become funcref since it was renamed in the spec. We should also support the string 'anyfunc' in the table constructor since this is 
        the only non-binary-format place where it is exposed to users.

        * wasm/WasmAirIRGenerator.cpp:
        (JSC::Wasm::AirIRGenerator::gFuncref):
        (JSC::Wasm::AirIRGenerator::tmpForType):
        (JSC::Wasm::AirIRGenerator::emitCCall):
        (JSC::Wasm::AirIRGenerator::moveOpForValueType):
        (JSC::Wasm::AirIRGenerator::AirIRGenerator):
        (JSC::Wasm::AirIRGenerator::addLocal):
        (JSC::Wasm::AirIRGenerator::addConstant):
        (JSC::Wasm::AirIRGenerator::addRefFunc):
        (JSC::Wasm::AirIRGenerator::addReturn):
        (JSC::Wasm::AirIRGenerator::gAnyfunc): Deleted.
        * wasm/WasmCallingConvention.h:
        (JSC::Wasm::CallingConventionAir::marshallArgument const):
        (JSC::Wasm::CallingConventionAir::setupCall const):
        * wasm/WasmExceptionType.h:
        * wasm/WasmFormat.h:
        (JSC::Wasm::isValueType):
        (JSC::Wasm::isSubtype):
        (JSC::Wasm::TableInformation::wasmType const):
        * wasm/WasmFunctionParser.h:
        (JSC::Wasm::FunctionParser<Context>::parseExpression):
        * wasm/WasmSectionParser.cpp:
        (JSC::Wasm::SectionParser::parseTableHelper):
        (JSC::Wasm::SectionParser::parseElement):
        (JSC::Wasm::SectionParser::parseInitExpr):
        * wasm/WasmValidate.cpp:
        (JSC::Wasm::Validate::addRefFunc):
        * wasm/js/JSToWasm.cpp:
        (JSC::Wasm::createJSToWasmWrapper):
        * wasm/js/WasmToJS.cpp:
        (JSC::Wasm::wasmToJS):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction):
        (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::link):
        * wasm/js/WebAssemblyTableConstructor.cpp:
        (JSC::constructJSWebAssemblyTable):
        * wasm/wasm.json:

2019-06-19  Fujii Hironori  <Hironori.Fujii@sony.com>

        [CMake][Win] CombinedDomains.json is generated twice in JavaScriptCore_CopyPrivateHeaders and JavaScriptCore projects
        https://bugs.webkit.org/show_bug.cgi?id=198853

        Reviewed by Don Olmstead.

        JavaScriptCore_CopyPrivateHeaders target needs to have a direct or
        indirect dependency of JavaScriptCore target for CMake Visual
        Studio generator to eliminate duplicated custom commands.

        * CMakeLists.txt: Added JavaScriptCore as a dependency of JavaScriptCore_CopyPrivateHeaders.

2019-06-18  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] JSLock should be WebThread aware
        https://bugs.webkit.org/show_bug.cgi?id=198911

        Reviewed by Geoffrey Garen.

        Since WebKitLegacy content rendering is done in WebThread instead of the main thread in iOS, user of WebKitLegacy (e.g. UIWebView) needs
        to grab the WebThread lock (which is a recursive lock) in the main thread when touching the WebKitLegacy content.
        But, WebKitLegacy can expose JSContext for the web view. And we can interact with the JS content through JavaScriptCore APIs. However,
        since WebThread is a concept in WebCore, JavaScriptCore APIs do not grab the WebThread lock. As a result, WebKitLegacy web content can be
        modified from the main thread without grabbing the WebThread lock through JavaScriptCore APIs.

        This patch makes JSC aware of WebThread: JSLock grabs the WebThread lock before grabbing JS's lock. While this seems layering violation,
        we already have many USE(WEB_THREAD) and WebThread aware code in WTF. Eventually, we should move WebThread code from WebCore to WTF since
        JSC and WTF need to be aware of WebThread. But, for now, we just use the function pointer exposed by WebCore.

        Since both JSLock and the WebThread lock are recursive locks, nested locking is totally OK. The possible problem is the order of locking.
        We ensure that we always grab locks in (1) the WebThread lock and (2) JSLock order.

        In JSLock, we take the WebThread lock, but we do not unlock it. This is how we use the WebThread lock: the WebThread lock is released
        automatically when RunLoop finishes the current cycle, and in WebKitLegacy, we do not call unlocking function of the WebThread lock except
        for some edge cases.

        * API/JSVirtualMachine.mm:
        (-[JSVirtualMachine isWebThreadAware]):
        * API/JSVirtualMachineInternal.h:
        * runtime/JSLock.cpp:
        (JSC::JSLockHolder::JSLockHolder):
        (JSC::JSLock::lock):
        (JSC::JSLockHolder::init): Deleted.
        * runtime/JSLock.h:
        (JSC::JSLock::makeWebThreadAware):
        (JSC::JSLock::isWebThreadAware const):

2019-06-18  Justin Michaud  <justin_michaud@apple.com>

        [WASM-References] Add support for Table.size, grow and fill instructions
        https://bugs.webkit.org/show_bug.cgi?id=198761

        Reviewed by Yusuke Suzuki.

        Add support for Table.size, grow and fill instructions. This also required
        adding support for two-byte opcodes to the ops generator.

        * wasm/WasmAirIRGenerator.cpp:
        (JSC::Wasm::AirIRGenerator::gAnyref):
        (JSC::Wasm::AirIRGenerator::tmpForType):
        (JSC::Wasm::AirIRGenerator::addTableSize):
        (JSC::Wasm::AirIRGenerator::addTableGrow):
        (JSC::Wasm::AirIRGenerator::addTableFill):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::addTableSize):
        (JSC::Wasm::B3IRGenerator::addTableGrow):
        (JSC::Wasm::B3IRGenerator::addTableFill):
        * wasm/WasmExceptionType.h:
        * wasm/WasmFormat.h:
        (JSC::Wasm::TableInformation::wasmType const):
        * wasm/WasmFunctionParser.h:
        (JSC::Wasm::FunctionParser<Context>::parseExpression):
        (JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
        * wasm/WasmInstance.cpp:
        (JSC::Wasm::doWasmTableGrow):
        (JSC::Wasm::doWasmTableFill):
        * wasm/WasmInstance.h:
        * wasm/WasmTable.cpp:
        (JSC::Wasm::Table::grow):
        * wasm/WasmValidate.cpp:
        (JSC::Wasm::Validate::addTableSize):
        (JSC::Wasm::Validate::addTableGrow):
        (JSC::Wasm::Validate::addTableFill):
        * wasm/generateWasmOpsHeader.py:
        (opcodeMacroizer):
        (ExtTableOpType):
        * wasm/wasm.json:

2019-06-18  Keith Miller  <keith_miller@apple.com>

        Unreviewed, fix signature of currentWeakRefVersion to return an uintptr_t.

        * runtime/VM.h:
        (JSC::VM::currentWeakRefVersion const):

2019-06-18  Justin Michaud  <justin_michaud@apple.com>

        [WASM-References] Add support for multiple tables
        https://bugs.webkit.org/show_bug.cgi?id=198760

        Reviewed by Saam Barati.

        Support multiple wasm tables. We turn tableInformation into a tables array, and update all of the
        existing users to give a table index. The array of Tables in Wasm::Instance is hung off the tail
        to make it easier to use from jit code. 

        * wasm/WasmAirIRGenerator.cpp:
        (JSC::Wasm::AirIRGenerator::AirIRGenerator):
        (JSC::Wasm::AirIRGenerator::addTableGet):
        (JSC::Wasm::AirIRGenerator::addTableSet):
        (JSC::Wasm::AirIRGenerator::addCallIndirect):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        (JSC::Wasm::B3IRGenerator::addTableGet):
        (JSC::Wasm::B3IRGenerator::addTableSet):
        (JSC::Wasm::B3IRGenerator::addCallIndirect):
        * wasm/WasmExceptionType.h:
        * wasm/WasmFormat.h:
        (JSC::Wasm::Element::Element):
        * wasm/WasmFunctionParser.h:
        (JSC::Wasm::FunctionParser<Context>::parseExpression):
        (JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
        * wasm/WasmInstance.cpp:
        (JSC::Wasm::Instance::Instance):
        (JSC::Wasm::Instance::create):
        (JSC::Wasm::Instance::extraMemoryAllocated const):
        (JSC::Wasm::Instance::table):
        (JSC::Wasm::Instance::setTable):
        * wasm/WasmInstance.h:
        (JSC::Wasm::Instance::updateCachedMemory):
        (JSC::Wasm::Instance::offsetOfGlobals):
        (JSC::Wasm::Instance::offsetOfTablePtr):
        (JSC::Wasm::Instance::allocationSize):
        (JSC::Wasm::Instance::table): Deleted.
        (JSC::Wasm::Instance::setTable): Deleted.
        (JSC::Wasm::Instance::offsetOfTable): Deleted.
        * wasm/WasmModuleInformation.h:
        (JSC::Wasm::ModuleInformation::tableCount const):
        * wasm/WasmSectionParser.cpp:
        (JSC::Wasm::SectionParser::parseImport):
        (JSC::Wasm::SectionParser::parseTableHelper):
        (JSC::Wasm::SectionParser::parseTable):
        (JSC::Wasm::SectionParser::parseElement):
        * wasm/WasmTable.h:
        (JSC::Wasm::Table::owner const):
        * wasm/WasmValidate.cpp:
        (JSC::Wasm::Validate::addTableGet):
        (JSC::Wasm::Validate::addTableSet):
        (JSC::Wasm::Validate::addCallIndirect):
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
        (JSC::JSWebAssemblyInstance::visitChildren):
        * wasm/js/JSWebAssemblyInstance.h:
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::link):
        (JSC::WebAssemblyModuleRecord::evaluate):
        * wasm/wasm.json:

2019-06-18  Alexey Shvayka  <shvaikalesh@gmail.com>

        [ESNExt] String.prototype.matchAll
        https://bugs.webkit.org/show_bug.cgi?id=186694

        Reviewed by Yusuke Suzuki.

        Implement String.prototype.matchAll.
        (https://tc39.es/ecma262/#sec-string.prototype.matchall)

        Also rename @globalPrivate @constructor functions and C++ variables holding them.

        Shipping in Chrome since version 73.
        Shipping in Firefox since version 67.

        * CMakeLists.txt:
        * DerivedSources-input.xcfilelist:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Scripts/wkbuiltins/builtins_generate_combined_header.py:
        (get_var_name):
        (generate_section_for_global_private_code_name_macro):
        * Sources.txt:
        * builtins/ArrayPrototype.js:
        (globalPrivate.ArrayIterator):
        (values):
        (keys):
        (entries):
        (globalPrivate.createArrayIterator): Deleted.
        * builtins/AsyncFromSyncIteratorPrototype.js:
        (globalPrivate.createAsyncFromSyncIterator):
        (globalPrivate.AsyncFromSyncIterator):
        (globalPrivate.AsyncFromSyncIteratorConstructor): Deleted.
        * builtins/BuiltinNames.h:
        * builtins/MapPrototype.js:
        (globalPrivate.MapIterator):
        (values):
        (keys):
        (entries):
        (globalPrivate.createMapIterator): Deleted.
        * builtins/RegExpPrototype.js:
        (globalPrivate.RegExpStringIterator):
        (overriddenName.string_appeared_here.matchAll):
        * builtins/RegExpStringIteratorPrototype.js: Added.
        (next):
        * builtins/SetPrototype.js:
        (globalPrivate.SetIterator):
        (values):
        (entries):
        (globalPrivate.createSetIterator): Deleted.
        * builtins/StringPrototype.js:
        (matchAll):
        * builtins/TypedArrayPrototype.js:
        (values):
        (keys):
        (entries):
        * runtime/CommonIdentifiers.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/RegExpPrototype.cpp:
        (JSC::RegExpPrototype::finishCreation):
        * runtime/RegExpStringIteratorPrototype.cpp: Added.
        (JSC::RegExpStringIteratorPrototype::finishCreation):
        * runtime/RegExpStringIteratorPrototype.h: Added.
        * runtime/StringPrototype.cpp:

2019-06-18  Keith Miller  <keith_miller@apple.com>

        Add support for WeakRef
        https://bugs.webkit.org/show_bug.cgi?id=198710

        Reviewed by Yusuke Suzuki.

        Add support for WeakRefs which are now at stage 3
        (https://tc39.es/proposal-weakrefs). This patch doesn't add
        support for FinalizationGroups, which I'll add in another patch.

        Some other things of interest. Per the spec, we cannot collect a
        weak refs target unless it has not been dereffed (or created) in
        the current microtask turn. i.e. WeakRefs are only allowed to be
        collected at the end of a drain of the Microtask queue. My
        understanding for this behavior is to reduce implementation
        dependence on specific GC behavior in a given browser.

        We track if a WeakRef is retaining its target by using a version
        number on each WeakRef as well as on the VM. Whenever a WeakRef is
        derefed we update its version number to match the VM's then
        WriteBarrier ourselves. During marking if the VM and the WeakRef
        have the same version number, the target is visited.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * heap/Heap.cpp:
        (JSC::Heap::finalizeUnconditionalFinalizers):
        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionReleaseWeakRefs):
        * runtime/CommonIdentifiers.h:
        * runtime/JSGlobalObject.cpp:
        * runtime/JSGlobalObject.h:
        * runtime/JSWeakObjectRef.cpp: Added.
        (JSC::JSWeakObjectRef::finishCreation):
        (JSC::JSWeakObjectRef::visitChildren):
        (JSC::JSWeakObjectRef::finalizeUnconditionally):
        (JSC::JSWeakObjectRef::toStringName):
        * runtime/JSWeakObjectRef.h: Added.
        * runtime/VM.cpp:
        (JSC::VM::drainMicrotasks):
        * runtime/VM.h:
        (JSC::VM::setOnEachMicrotaskTick):
        (JSC::VM::finalizeSynchronousJSExecution):
        (JSC::VM::currentWeakRefVersion const):
        * runtime/WeakObjectRefConstructor.cpp: Added.
        (JSC::WeakObjectRefConstructor::finishCreation):
        (JSC::WeakObjectRefConstructor::WeakObjectRefConstructor):
        (JSC::callWeakRef):
        (JSC::constructWeakRef):
        * runtime/WeakObjectRefConstructor.h: Added.
        (JSC::WeakObjectRefConstructor::create):
        (JSC::WeakObjectRefConstructor::createStructure):
        * runtime/WeakObjectRefPrototype.cpp: Added.
        (JSC::WeakObjectRefPrototype::finishCreation):
        (JSC::getWeakRef):
        (JSC::protoFuncWeakRefDeref):
        * runtime/WeakObjectRefPrototype.h: Added.

2019-06-18  Tadeu Zagallo  <tzagallo@apple.com>

        Add missing mutator fence in compileNewFunction
        https://bugs.webkit.org/show_bug.cgi?id=198849
        <rdar://problem/51733890>

        Reviewed by Saam Barati.

        Follow-up after r246553. Saam pointed out that we still need a mutator
        fence before allocating the FunctionRareData, since the allocation
        might trigger a slow path call.

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

2019-06-18  Tadeu Zagallo  <tzagallo@apple.com>

        DFG code should not reify the names of builtin functions with private names
        https://bugs.webkit.org/show_bug.cgi?id=198849
        <rdar://problem/51733890>

        Reviewed by Filip Pizlo.

        Builtin functions that have a private name call setHasReifiedName from finishCreation.
        When compiled with DFG and FTL, that does not get called and the function ends up reifying
        its name. In order to fix that, we initialize FunctionRareData and set m_hasReifiedName to
        true from compileNewFunction in both DFG and FTL.

        * bytecode/InternalFunctionAllocationProfile.h:
        (JSC::InternalFunctionAllocationProfile::offsetOfStructure):
        * bytecode/ObjectAllocationProfile.h:
        (JSC::ObjectAllocationProfileWithPrototype::offsetOfPrototype):
        * bytecode/UnlinkedFunctionExecutable.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNewFunctionCommon):
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
        * runtime/FunctionExecutable.h:
        * runtime/FunctionRareData.h:
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::finishCreation):
        * runtime/JSFunction.h:
        * runtime/JSFunctionInlines.h:
        (JSC::JSFunction::isAnonymousBuiltinFunction const):

2019-06-18  Keith Miller  <keith_miller@apple.com>

        MaybeParseAsGeneratorForScope sometimes loses track of its scope ref
        https://bugs.webkit.org/show_bug.cgi?id=198969
        <rdar://problem/51620714>

        Reviewed by Tadeu Zagallo.

        Sometimes if the parser has enough nested scopes
        MaybeParseAsGeneratorForScope can lose track of the ScopeRef it
        should be tracking. This is because the parser sometimes relocates
        its ScopeRefs. To fix this MaybeParseAsGeneratorForScope should
        hold the scope ref it's watching.

        * parser/Parser.cpp:
        (JSC::Scope::MaybeParseAsGeneratorForScope::MaybeParseAsGeneratorForScope):
        (JSC::Scope::MaybeParseAsGeneratorForScope::~MaybeParseAsGeneratorForScope):

2019-06-17  Justin Michaud  <justin_michaud@apple.com>

        Validate that table element type is funcref if using an element section
        https://bugs.webkit.org/show_bug.cgi?id=198910

        Reviewed by Yusuke Suzuki.

        Add missing validation when attempting to add an element section to an anyref table.

        * wasm/WasmSectionParser.cpp:
        (JSC::Wasm::SectionParser::parseElement):

2019-06-17  Tadeu Zagallo  <tzagallo@apple.com>

        Concurrent GC should check the conn before starting a new collection cycle
        https://bugs.webkit.org/show_bug.cgi?id=198913
        <rdar://problem/49515149>

        Reviewed by Filip Pizlo.

        Heap::requestCollection tries to steal the conn as an optimization to avoid waking up the collector
        thread if it's idle. We determine if the collector is idle by ensuring that there are no pending collections
        and that the current GC phase is NotRunning. However, that's not safe immediately after the concurrent
        GC has finished processing the last pending request. The collector thread will runEndPhase and immediately
        start runNotRunningPhase, without checking if it still has the conn. If the mutator has stolen the conn in
        the mean time, this will lead to both threads collecting concurrently, and eventually we'll crash in checkConn,
        since the collector is running but doesn't have the conn anymore.

        To solve this, we check if we still have the conn after holding the lock in runNotRunningPhase, in case the mutator
        has stolen the conn. Ideally, we wouldn't let the mutator steal the conn in the first place, but that doesn't seem
        trivial to determine.

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

2019-06-17  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Introduce DisposableCallSiteIndex to enforce type-safety
        https://bugs.webkit.org/show_bug.cgi?id=197378

        Reviewed by Saam Barati.

        Some of CallSiteIndex are disposable. This is because some of CallSiteIndex are allocated and freed at runtime (not DFG/FTL compile time).
        The example is CallSiteIndex for exception handler in GCAwareJITStubRoutineWithExceptionHandler. If we do not allocate and free CallSiteIndex,
        we will create a new CallSiteIndex continuously and leak memory.

        The other CallSiteIndex are not simply disposable because the ownership model is not unique one. They can be shared between multiple clients.
        But not disposing them is OK because they are static one: they are allocated when compiling DFG/FTL, and we do not allocate such CallSiteIndex
        at runtime.

        To make this difference explicit and avoid disposing non-disposable CallSiteIndex accidentally, we introduce DisposableCallSiteIndex type, and
        enforce type-safety to some degree.

        We also correctly update the DisposableCallSiteIndex => CodeOrigin table when we are reusing the previously used DisposableCallSiteIndex.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::newExceptionHandlingCallSiteIndex):
        (JSC::CodeBlock::removeExceptionHandlerForCallSite):
        * bytecode/CodeBlock.h:
        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessGenerationState::callSiteIndexForExceptionHandling):
        (JSC::PolymorphicAccess::regenerate):
        * bytecode/PolymorphicAccess.h:
        (JSC::AccessGenerationState::callSiteIndexForExceptionHandling): Deleted.
        * dfg/DFGCommonData.cpp:
        (JSC::DFG::CommonData::addUniqueCallSiteIndex):
        (JSC::DFG::CommonData::addDisposableCallSiteIndex):
        (JSC::DFG::CommonData::removeDisposableCallSiteIndex):
        (JSC::DFG::CommonData::removeCallSiteIndex): Deleted.
        * dfg/DFGCommonData.h:
        * interpreter/CallFrame.h:
        (JSC::DisposableCallSiteIndex::DisposableCallSiteIndex):
        (JSC::DisposableCallSiteIndex::fromCallSiteIndex):
        * jit/GCAwareJITStubRoutine.cpp:
        (JSC::GCAwareJITStubRoutineWithExceptionHandler::GCAwareJITStubRoutineWithExceptionHandler):
        (JSC::GCAwareJITStubRoutineWithExceptionHandler::observeZeroRefCount):
        (JSC::createJITStubRoutine):
        * jit/GCAwareJITStubRoutine.h:
        * jit/JITInlineCacheGenerator.h:

2019-06-17  Justin Michaud  <justin_michaud@apple.com>

        [WASM-References] Add support for Funcref in parameters and return types
        https://bugs.webkit.org/show_bug.cgi?id=198157

        Reviewed by Yusuke Suzuki.

        Add support for funcref in parameters, globals, and in table.get/set. When converting a JSValue to 
        a funcref (nee anyfunc), we first make sure it is an exported wasm function or null. 

        We also add support for Ref.func. Anywhere a Ref.func is used, (statically) we construct a JS wrapper
        for it so that we never need to construct JSValues when handling references. This should make threads
        easier to implement.

        Finally, we add some missing bounds checks for table.get/set.

        * wasm/WasmAirIRGenerator.cpp:
        (JSC::Wasm::AirIRGenerator::tmpForType):
        (JSC::Wasm::AirIRGenerator::moveOpForValueType):
        (JSC::Wasm::AirIRGenerator::AirIRGenerator):
        (JSC::Wasm::AirIRGenerator::addLocal):
        (JSC::Wasm::AirIRGenerator::addConstant):
        (JSC::Wasm::AirIRGenerator::addRefFunc):
        (JSC::Wasm::AirIRGenerator::addTableSet):
        (JSC::Wasm::AirIRGenerator::setGlobal):
        (JSC::Wasm::AirIRGenerator::addReturn):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::addLocal):
        (JSC::Wasm::B3IRGenerator::addTableSet):
        (JSC::Wasm::B3IRGenerator::addRefFunc):
        (JSC::Wasm::B3IRGenerator::setGlobal):
        * wasm/WasmBBQPlan.cpp:
        (JSC::Wasm::BBQPlan::compileFunctions):
        * wasm/WasmCallingConvention.h:
        (JSC::Wasm::CallingConventionAir::marshallArgument const):
        (JSC::Wasm::CallingConventionAir::setupCall const):
        * wasm/WasmExceptionType.h:
        * wasm/WasmFormat.h:
        (JSC::Wasm::isValueType):
        (JSC::Wasm::isSubtype):
        * wasm/WasmFunctionParser.h:
        (JSC::Wasm::FunctionParser<Context>::parseExpression):
        (JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
        * wasm/WasmInstance.cpp:
        (JSC::Wasm::Instance::Instance):
        (JSC::Wasm::Instance::getFunctionWrapper const):
        (JSC::Wasm::Instance::setFunctionWrapper):
        * wasm/WasmInstance.h:
        * wasm/WasmModuleInformation.h:
        (JSC::Wasm::ModuleInformation::referencedFunctions const):
        (JSC::Wasm::ModuleInformation::addReferencedFunction const):
        * wasm/WasmSectionParser.cpp:
        (JSC::Wasm::SectionParser::parseGlobal):
        (JSC::Wasm::SectionParser::parseInitExpr):
        * wasm/WasmValidate.cpp:
        (JSC::Wasm::Validate::addTableGet):
        (JSC::Wasm::Validate::addTableSet):
        (JSC::Wasm::Validate::addRefIsNull):
        (JSC::Wasm::Validate::addRefFunc):
        (JSC::Wasm::Validate::setLocal):
        (JSC::Wasm::Validate::addCall):
        (JSC::Wasm::Validate::addCallIndirect):
        * wasm/js/JSToWasm.cpp:
        (JSC::Wasm::createJSToWasmWrapper):
        * wasm/js/JSWebAssemblyHelpers.h:
        (JSC::isWebAssemblyHostFunction):
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::visitChildren):
        * wasm/js/JSWebAssemblyRuntimeError.cpp:
        (JSC::createJSWebAssemblyRuntimeError):
        * wasm/js/JSWebAssemblyRuntimeError.h:
        * wasm/js/WasmToJS.cpp:
        (JSC::Wasm::handleBadI64Use):
        (JSC::Wasm::wasmToJS):
        (JSC::Wasm::emitWasmToJSException):
        * wasm/js/WasmToJS.h:
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction):
        (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::link):
        * wasm/wasm.json:

2019-06-16  Darin Adler  <darin@apple.com>

        Rename AtomicString to AtomString
        https://bugs.webkit.org/show_bug.cgi?id=195276

        Reviewed by Michael Catanzaro.

        * many files: Let do-webcore-rename do the renaming.

2019-06-16  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Grown region of WasmTable should be initialized with null
        https://bugs.webkit.org/show_bug.cgi?id=198903

        Reviewed by Saam Barati.

        Grown region of Wasmtable is now empty. We should initialize it with null.
        We also rename Wasm::Table::visitChildren to Wasm::Table::visitAggregate to
        align to the naming convention.

        * wasm/WasmTable.cpp:
        (JSC::Wasm::Table::grow):
        (JSC::Wasm::Table::visitAggregate):
        (JSC::Wasm::Table::visitChildren): Deleted.
        * wasm/WasmTable.h:
        * wasm/js/JSWebAssemblyTable.cpp:
        (JSC::JSWebAssemblyTable::visitChildren):

2019-06-14  Keith Miller  <keith_miller@apple.com>

        Restore PAC based cage.
        https://bugs.webkit.org/show_bug.cgi?id=198872

        Rubber-stamped by Saam Barati.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::bitFieldInsert64):
        * assembler/MacroAssemblerARM64E.h:
        * assembler/testmasm.cpp:
        (JSC::testCagePreservesPACFailureBit):
        (JSC::run):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds):
        (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
        (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
        (JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
        (JSC::FTL::DFG::LowerDFGToB3::caged):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::cageWithoutUntagging):
        (JSC::AssemblyHelpers::cageConditionally):
        (JSC::AssemblyHelpers::cage): Deleted.
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitIntTypedArrayGetByVal):
        (JSC::JIT::emitFloatTypedArrayGetByVal):
        (JSC::JIT::emitIntTypedArrayPutByVal):
        (JSC::JIT::emitFloatTypedArrayPutByVal):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter64.asm:
        * offlineasm/arm64.rb:
        * offlineasm/instructions.rb:
        * offlineasm/registers.rb:
        * wasm/WasmAirIRGenerator.cpp:
        (JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
        (JSC::Wasm::AirIRGenerator::addCallIndirect):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
        (JSC::Wasm::B3IRGenerator::addCallIndirect):
        * wasm/WasmBinding.cpp:
        (JSC::Wasm::wasmToWasm):
        * wasm/js/JSToWasm.cpp:
        (JSC::Wasm::createJSToWasmWrapper):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::WebAssemblyFunction::jsCallEntrypointSlow):

2019-06-13  Yusuke Suzuki  <ysuzuki@apple.com>

        Yarr bytecode compilation failure should be gracefully handled
        https://bugs.webkit.org/show_bug.cgi?id=198700

        Reviewed by Michael Saboff.

        Currently, we assume that Yarr bytecode compilation does not fail. But in fact it can fail.
        We should gracefully handle this failure as a runtime error, as we did for parse errors in [1].
        We also harden Yarr's consumed character calculation by using Checked.

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

        * inspector/ContentSearchUtilities.cpp:
        (Inspector::ContentSearchUtilities::findMagicComment):
        * runtime/RegExp.cpp:
        (JSC::RegExp::byteCodeCompileIfNecessary):
        (JSC::RegExp::compile):
        (JSC::RegExp::compileMatchOnly):
        * runtime/RegExpInlines.h:
        (JSC::RegExp::matchInline):
        * yarr/YarrErrorCode.cpp:
        (JSC::Yarr::errorMessage):
        (JSC::Yarr::errorToThrow):
        * yarr/YarrErrorCode.h:
        * yarr/YarrInterpreter.cpp:
        (JSC::Yarr::ByteCompiler::ByteCompiler):
        (JSC::Yarr::ByteCompiler::compile):
        (JSC::Yarr::ByteCompiler::atomCharacterClass):
        (JSC::Yarr::ByteCompiler::atomBackReference):
        (JSC::Yarr::ByteCompiler::atomParenthesesOnceBegin):
        (JSC::Yarr::ByteCompiler::atomParenthesesTerminalBegin):
        (JSC::Yarr::ByteCompiler::atomParenthesesSubpatternBegin):
        (JSC::Yarr::ByteCompiler::atomParentheticalAssertionBegin):
        (JSC::Yarr::ByteCompiler::popParenthesesStack):
        (JSC::Yarr::ByteCompiler::closeAlternative):
        (JSC::Yarr::ByteCompiler::closeBodyAlternative):
        (JSC::Yarr::ByteCompiler::alternativeBodyDisjunction):
        (JSC::Yarr::ByteCompiler::alternativeDisjunction):
        (JSC::Yarr::ByteCompiler::emitDisjunction):

2019-06-12  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Polymorphic call stub's slow path should restore callee saves before performing tail call
        https://bugs.webkit.org/show_bug.cgi?id=198770

        Reviewed by Saam Barati.

        Polymorphic call stub is a bit specially patched in JS call site. Typical JS call site for tail calls
        are the following.

            if (callee == patchableCallee) {
                restore callee saves for tail call
                prepare for tail call
                jump to the target function
            }
            restore callee saves for slow path
            call the slow path function

        And linking patches patchableCallee, target function, and slow path function. But polymorphic call stub
        patches the above `if` statement with the jump to the stub.

            jump to the polymorphic call stub

        This is because polymorphic call stub wants to use CallFrameShuffler to get scratch registers. As a result,
        "restore callee saves for tail call" thing needs to be done in the polymorphic call stubs. While it is
        correctly done for the major cases, we have `slowPath` skips, and that path missed restoring callee saves.
        This skip happens if the callee is non JSCell or non JS function, so typically, InternalFunction is handled
        in that path.

        This patch does that skips after restoring callee saves.

        * bytecode/CallLinkInfo.cpp:
        (JSC::CallLinkInfo::CallLinkInfo):
        * bytecode/CallLinkInfo.h:
        (JSC::CallLinkInfo::setUpCall):
        (JSC::CallLinkInfo::calleeGPR):
        (JSC::CallLinkInfo::setCalleeGPR): Deleted.
        * jit/Repatch.cpp:
        (JSC::revertCall):
        (JSC::linkVirtualFor):
        (JSC::linkPolymorphicCall):
        * jit/Repatch.h:
        * jit/ThunkGenerators.cpp:
        (JSC::virtualThunkFor):

2019-06-12  Commit Queue  <commit-queue@webkit.org>

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

        "It's a huge page load regression on iOS" (Requested by
        saamyjoon on #webkit).

        Reverted changeset:

        "Roll out PAC cage"
        https://bugs.webkit.org/show_bug.cgi?id=198726
        https://trac.webkit.org/changeset/246322

2019-06-11  Alexey Shvayka  <shvaikalesh@gmail.com>

        JSC should throw if proxy set returns falsish in strict mode context
        https://bugs.webkit.org/show_bug.cgi?id=177398

        Reviewed by Yusuke Suzuki.

        Throw TypeError exception if Proxy's `set` trap returns falsy value.
        (step 6.c of https://tc39.es/ecma262/#sec-putvalue)

        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::performPut):
        (JSC::ProxyObject::put):
        (JSC::ProxyObject::putByIndexCommon):
        * runtime/ProxyObject.h:

2019-06-11  Alexey Shvayka  <shvaikalesh@gmail.com>

        Error message for non-callable Proxy `construct` trap is misleading
        https://bugs.webkit.org/show_bug.cgi?id=198637

        Reviewed by Saam Barati.

        Just like other traps, Proxy `construct` trap is invoked with [[Call]], not [[Construct]].

        * runtime/ProxyObject.cpp:
        (JSC::performProxyConstruct): Tweak error message.

2019-06-10  Tadeu Zagallo  <tzagallo@apple.com>

        AI BitURShift's result should not be unsigned
        https://bugs.webkit.org/show_bug.cgi?id=198689
        <rdar://problem/51550063>

        Reviewed by Saam Barati.

        Treating BitURShift's result as unsigned in the abstract interpreter incorrectly overflows it.
        This breaks the DFG and FTL, since they assume that BitURShift's result is an int32 value, but
        get a double constant from AI. Since the result will be converted to unsigned by UInt32ToNumber,
        all we have to do is store the result as a signed int32.

        * dfg/DFGAbstractInterpreterInlines.h:

2019-06-11  Michael Catanzaro  <mcatanzaro@igalia.com>

        Unreviewed build warning fixes

        Silence -Wreturn-type warning

        * wasm/WasmTable.cpp:
        (JSC::Wasm::Table::tryCreate):

2019-06-11  Saam Barati  <sbarati@apple.com>

        Roll out PAC cage
        https://bugs.webkit.org/show_bug.cgi?id=198726

        Reviewed by Keith Miller.

        This patch rolls out: r245064, r245145, r245168, r245313, r245432, r245622.
        
        The resulting state we're in is we have Gigacage enabled on arm64.
        There is no more PAC caging.

        We're doing this because there are performance issues with PAC caging
        that we haven't resolved yet.

        * assembler/CPU.h:
        (JSC::isARM64E): Deleted.
        * assembler/MacroAssemblerARM64E.h:
        (JSC::MacroAssemblerARM64E::tagArrayPtr): Deleted.
        (JSC::MacroAssemblerARM64E::untagArrayPtr): Deleted.
        (JSC::MacroAssemblerARM64E::removeArrayPtrTag): Deleted.
        * b3/B3LowerToAir.cpp:
        * b3/B3PatchpointSpecial.cpp:
        (JSC::B3::PatchpointSpecial::admitsStack):
        * b3/B3StackmapSpecial.cpp:
        (JSC::B3::StackmapSpecial::forEachArgImpl):
        (JSC::B3::StackmapSpecial::isArgValidForRep):
        * b3/B3Validate.cpp:
        * b3/B3ValueRep.cpp:
        (JSC::B3::ValueRep::addUsedRegistersTo const):
        (JSC::B3::ValueRep::dump const):
        (WTF::printInternal):
        * b3/B3ValueRep.h:
        (JSC::B3::ValueRep::ValueRep):
        (JSC::B3::ValueRep::isReg const):
        * dfg/DFGOperations.cpp:
        (JSC::DFG::newTypedArrayWithSize):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds):
        (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
        (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
        (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
        (JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
        (JSC::FTL::DFG::LowerDFGToB3::compileDataViewGet):
        (JSC::FTL::DFG::LowerDFGToB3::compileDataViewSet):
        (JSC::FTL::DFG::LowerDFGToB3::caged):
        (JSC::FTL::DFG::LowerDFGToB3::speculateTypedArrayIsNotNeutered):
        (JSC::FTL::DFG::LowerDFGToB3::untagArrayPtr): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::removeArrayPtrTag): Deleted.
        * heap/ConservativeRoots.cpp:
        (JSC::ConservativeRoots::genericAddPointer):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::cageConditionally):
        * jit/IntrinsicEmitter.cpp:
        (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitDirectArgumentsGetByVal):
        (JSC::JIT::emitIntTypedArrayGetByVal):
        (JSC::JIT::emitFloatTypedArrayGetByVal):
        (JSC::JIT::emitIntTypedArrayPutByVal):
        (JSC::JIT::emitFloatTypedArrayPutByVal):
        * jit/PolymorphicCallStubRoutine.cpp:
        (JSC::PolymorphicCallNode::clearCallLinkInfo):
        * jit/RegisterSet.h:
        * llint/LowLevelInterpreter64.asm:
        * runtime/ArrayBuffer.cpp:
        (JSC::SharedArrayBufferContents::SharedArrayBufferContents):
        (JSC::SharedArrayBufferContents::~SharedArrayBufferContents):
        (JSC::ArrayBufferContents::ArrayBufferContents):
        (JSC::ArrayBufferContents::destroy):
        (JSC::ArrayBufferContents::tryAllocate):
        (JSC::ArrayBufferContents::makeShared):
        (JSC::ArrayBufferContents::copyTo):
        * runtime/ArrayBuffer.h:
        (JSC::SharedArrayBufferContents::data const):
        (JSC::ArrayBufferContents::data const):
        (JSC::ArrayBuffer::data):
        (JSC::ArrayBuffer::data const):
        (JSC::ArrayBuffer::byteLength const):
        * runtime/ArrayBufferView.cpp:
        (JSC::ArrayBufferView::ArrayBufferView):
        * runtime/ArrayBufferView.h:
        (JSC::ArrayBufferView::baseAddress const):
        (JSC::ArrayBufferView::setRangeImpl):
        (JSC::ArrayBufferView::getRangeImpl):
        (JSC::ArrayBufferView::byteLength const): Deleted.
        * runtime/CachedTypes.cpp:
        (JSC::CachedScopedArgumentsTable::encode):
        (JSC::CachedScopedArgumentsTable::decode const):
        * runtime/CagedBarrierPtr.h:
        (JSC::CagedBarrierPtr::CagedBarrierPtr):
        (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):
        (JSC::CagedBarrierPtr::getUnsafe const): Deleted.
        (JSC::CagedBarrierPtr::at const): Deleted.
        * runtime/DataView.cpp:
        (JSC::DataView::DataView):
        * runtime/DataView.h:
        (JSC::DataView::get):
        (JSC::DataView::set):
        * runtime/DirectArguments.cpp:
        (JSC::DirectArguments::visitChildren):
        (JSC::DirectArguments::overrideThings):
        (JSC::DirectArguments::unmapArgument):
        * runtime/DirectArguments.h:
        * runtime/GenericArguments.h:
        * runtime/GenericArgumentsInlines.h:
        (JSC::GenericArguments<Type>::visitChildren):
        (JSC::GenericArguments<Type>::initModifiedArgumentsDescriptor):
        (JSC::GenericArguments<Type>::setModifiedArgumentDescriptor):
        (JSC::GenericArguments<Type>::isModifiedArgumentDescriptor):
        * runtime/GenericTypedArrayView.h:
        * runtime/GenericTypedArrayViewInlines.h:
        (JSC::GenericTypedArrayView<Adaptor>::GenericTypedArrayView):
        * runtime/JSArrayBufferView.cpp:
        (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
        (JSC::JSArrayBufferView::JSArrayBufferView):
        (JSC::JSArrayBufferView::finalize):
        (JSC::JSArrayBufferView::slowDownAndWasteMemory):
        * runtime/JSArrayBufferView.h:
        (JSC::JSArrayBufferView::ConstructionContext::vector const):
        (JSC::JSArrayBufferView::isNeutered):
        (JSC::JSArrayBufferView::vector const):
        (JSC::JSArrayBufferView::hasVector const): Deleted.
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::createUninitialized):
        (JSC::JSGenericTypedArrayView<Adaptor>::estimatedSize):
        (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren):
        * runtime/Options.h:
        * runtime/ScopedArgumentsTable.cpp:
        (JSC::ScopedArgumentsTable::clone):
        (JSC::ScopedArgumentsTable::setLength):
        * runtime/ScopedArgumentsTable.h:
        * runtime/SymbolTable.h:
        * wasm/WasmAirIRGenerator.cpp:
        (JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
        (JSC::Wasm::AirIRGenerator::addCallIndirect):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
        (JSC::Wasm::B3IRGenerator::addCallIndirect):
        * wasm/WasmBBQPlan.cpp:
        (JSC::Wasm::BBQPlan::complete):
        * wasm/WasmBinding.cpp:
        (JSC::Wasm::wasmToWasm):
        * wasm/WasmInstance.h:
        (JSC::Wasm::Instance::cachedMemory const):
        (JSC::Wasm::Instance::updateCachedMemory):
        * wasm/WasmMemory.cpp:
        (JSC::Wasm::Memory::Memory):
        (JSC::Wasm::Memory::~Memory):
        (JSC::Wasm::Memory::grow):
        (JSC::Wasm::Memory::dump const):
        * wasm/WasmMemory.h:
        (JSC::Wasm::Memory::memory const):
        * wasm/js/JSToWasm.cpp:
        (JSC::Wasm::createJSToWasmWrapper):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::WebAssemblyFunction::jsCallEntrypointSlow):

2019-06-10  Basuke Suzuki  <Basuke.Suzuki@sony.com>

        [WinCairo] Remove build warning from RemoteInspector.
        https://bugs.webkit.org/show_bug.cgi?id=198724

        Reviewed by Joseph Pecoraro.

        In `RemoteInspectorConnectionClient.h`, an interface was defined with empty implementation.
        This method is to be overwritten by sub classes so that parameter name is important
        so they are commented out rather than just removing from the definition.

        * inspector/remote/RemoteInspector.h:

2019-06-10  Sam Weinig  <weinig@apple.com>

        Remove Dashboard support
        https://bugs.webkit.org/show_bug.cgi?id=198615

        Reviewed by Ryosuke Niwa.

        * Configurations/FeatureDefines.xcconfig:

2019-06-10  Devin Rousso  <drousso@apple.com>

        Web Automation: add notifications for when remote automation is enabled/disabled
        https://bugs.webkit.org/show_bug.cgi?id=198703
        <rdar://problem/50588975>

        Reviewed by Timothy Hatcher.

        * inspector/remote/RemoteInspectorConstants.h:

2019-06-10  Yusuke Suzuki  <ysuzuki@apple.com>

        Unreviewed, build fix for non-DFG configurations, part 2
        https://bugs.webkit.org/show_bug.cgi?id=198023

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

2019-06-10  Yusuke Suzuki  <ysuzuki@apple.com>

        Unreviewed, build fix for non-DFG configurations
        https://bugs.webkit.org/show_bug.cgi?id=198023

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

2019-06-10  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] UnlinkedCodeBlock should be eventually jettisoned in VM mini mode
        https://bugs.webkit.org/show_bug.cgi?id=198023

        Reviewed by Saam Barati.

        While CodeBlock is periodically jettisoned, UnlinkedCodeBlock and UnlinkedFunctionExecutable can be retained almost forever in certain type of applications.
        When we execute a program, which has UnlinkedProgramCodeBlock retained in CodeCache. And UnlinkedProgramCodeBlock holds array of UnlinkedFunctionExecutable.
        And UnlinkedFunctionExecutables hold UnlinkedFunctionCodeBlocks once it is generated. So eventually, this tree gets larger and larger until we purge
        UnlinkedProgramCodeBlock from CodeCache. This is OK in the browser case. We navigate to various other pages, and UnlinkedProgramCodeBlocks should eventually
        be pruned from CodeCache with the new ones. So this tree won't be retained forever. But the behavior is different in the other applications that do not have
        navigations. If they only have one program which holds all, we basically retain this tree during executing this application. The same thing can happen in
        web applications which does not have navigation and keeps alive for a long time. Once we hit CodeCache limit by periodically executing a new script, we will
        hit the uppermost of memory footprint. But until that, we increase our memory footprint.

        However, destroying these UnlinkedCodeBlocks and UnlinkedFunctionExecutables causes a tricky problem. In the browser environment, navigation can happen at any
        time. So even if the given UnlinkedCodeBlock seems unused in the current page, it can be used when navigating to a new page which is under the same domain.
        One example is initializing function in a script. It is only executed once per page. So once it is executed, it seems that this UnlinkedCodeBlock is unused.
        But this will be used when we navigate to a new page. Pruning code blocks based on usage could cause performance regression.

        But if our VM is mini VM mode, the story is different. In mini VM mode, we focus on memory footprint rather than performance e.g. daemons. The daemon never
        reuse these CodeCache since we do not have the navigation.

        This patch logically makes UnlinkedFunctionExecutable -> UnlinkedCodeBlock reference weak when VM is mini mode. If UnlinkedCodeBlock is used in previous GC
        cycle, we retain it. But if it is not used, and if UnlinkedFunctionExecutable is only the cell keeping UnlinkedCodeBlock alive, we destroy it. It is a
        heuristic. In a super pathological case, it could increase memory footprint. Consider the following example.

            UnlinkedFunctionExecutable(A1) -> UnlinkedCodeBlock(B1) -> UnlinkedFunctionExecutable(C1) -> UnlinkedCodeBlock(D1)
                                                                                                             ^
                                                                                                         CodeBlock(E1)

        We could delete A1, B1, and C1 while keeping D1. But if we eventually re-execute the same code corresponding to A1, B1, C1, they will be newly created, and
        we will create duplicate UnlinkedCodeBlock and instructions stream for D1.

                                                                                                         UnlinkedCodeBlock(D1)
                                                                                                             ^
                                                                                                         CodeBlock(E1)

            UnlinkedFunctionExecutable(A2) -> UnlinkedCodeBlock(B2) -> UnlinkedFunctionExecutable(C2) -> UnlinkedCodeBlock(D2)

        But this does not happen in practice and even it happens, we eventually discard D1 and D2 since CodeBlock E1 will be jettisoned anyway. So in practice, we do
        not see memory footprint increase. We tested it in Gmail and the target application, but both said memory footprint reduction (30 MB / 400 MB and 1 MB /6 MB).
        While this affects on performance much on tests which has navigation (1-3 % regression in Speedometer2, note that JetStream2 does not show regression in x64,
        while it is not enabling mini mode), we do not apply this to non mini mode VM until we come up with a good strategy to fasten performance of re-generation.
        Personally I think flushing destroyed UnlinkedCodeBlock to the disk sounds promising.

        If UnlinkedCodeBlock is generated from bytecode cache, we do not make UnlinkedFunctionExecutable -> UnlinkedCodeBlock link weak because the decoder of the bytecode
        cache assumes that generated JSCells won't be destroyed while the parent cells of that cell are live. This is true in the current implementation, and this assumption
        will be broken with this patch. So, for now, we do not make this link weak. Currently, our target application does not use bytecode cache so it is OK.

        This patch also introduce simple heuristic. We are counting UnlinkedCodeBlock's age. And once the age becomes maximum size, we make UnlinkedFunctionExecutable ->
        UnlinkedCodeBlock link weak. We also use execution counter information to reset this age: CodeBlock will reset undelying UnlinkedCodeBlock's age if it has executed
        While this heuristic is quite simple, it has some effect in practice. Basically what happens with this heuristic is that UnlinkedFunctionExecutable ->
        UnlinkedCodeBlock link strong. When GC happens, we are executing some CodeBlocks, which become live. And ScriptExecutables -> UnlinkedFunctionExecutables held
        by this CodeBlock become also live. Then UnlinkedFunctionExecutables can mark the child UnlinkedCodeBlocks if it is not so old.
        If some of parent UnlinkedFunctionExecutable becomes dead, child UnlinkedCodeBlocks tends to be dead unless some live CodeBlock holds it. But it is OK for a first
        heuristics since this means that parent code block is now considered old, reachable UnlinkedCodeBlock will be used when the parent is executed again. So destroying
        the tree is OK even if the tree may include some new UnlinkedCodeBlock. While we could make more sophisticated mechanism to manage these lifetime, I think this is a
        good starting point.

        Based on measurement, we pick 7 as a maximum age. If we pick 0, we can get more memory reduction (1 - 1.5 MB!), while we ends up reparsing codes so many times.
        It seems that 7 can reduce fair amount of memory while doing small # of reparsing on average (usually, 1, 2. Sometimes, 100. But not 300, which is the case in 0).
        If we want to get more memory reduction for the sake of performance, we could decrease this age limit.

        Since we do not have an automated script right now so it is a bit difficult to measure memory footprint precisely. But manual testing shows that this patch improves
        memory footprint of our target application from about 6.5 MB to about 5.9 MB.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finalizeUnconditionally):
        * bytecode/CodeBlock.h:
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        (JSC::UnlinkedCodeBlock::visitChildren):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::age const):
        (JSC::UnlinkedCodeBlock::resetAge):
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        (JSC::UnlinkedFunctionExecutable::visitChildren):
        (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
        (JSC::UnlinkedFunctionExecutable::decodeCachedCodeBlocks):
        (JSC::UnlinkedFunctionExecutable::finalizeUnconditionally):
        * bytecode/UnlinkedFunctionExecutable.h:
        * heap/Heap.cpp:
        (JSC::Heap::finalizeUnconditionalFinalizers):
        * runtime/CachedTypes.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        * runtime/CodeSpecializationKind.h:
        * runtime/Options.h:
        * runtime/VM.cpp:
        (JSC::VM::isInMiniMode): Deleted.
        * runtime/VM.h:
        (JSC::VM::isInMiniMode):
        (JSC::VM::useUnlinkedCodeBlockJettisoning):

2019-06-10  Timothy Hatcher  <timothy@apple.com>

        Integrate dark mode support for iOS.
        https://bugs.webkit.org/show_bug.cgi?id=198687
        rdar://problem/51545643

        Reviewed by Tim Horton.

        * Configurations/FeatureDefines.xcconfig:

2019-06-10  Adrian Perez de Castro  <aperez@igalia.com>

        [JSC] Linker fails when unified sources are not in use
        https://bugs.webkit.org/show_bug.cgi?id=198722

        Reviewed by Keith Miller.

        Added missing inclusions of headers in several files which make use of inline functions.

        * b3/B3AtomicValue.cpp:
        * b3/B3BlockInsertionSet.cpp:
        * b3/B3FenceValue.cpp:
        * b3/B3LowerMacrosAfterOptimizations.cpp:
        * b3/B3PureCSE.cpp:
        * b3/B3StackmapValue.cpp:
        * b3/B3SwitchValue.cpp:
        * b3/B3UseCounts.cpp:
        * b3/B3VariableValue.cpp:
        * b3/B3WasmAddressValue.cpp:
        * b3/B3WasmBoundsCheckValue.cpp:
        * ftl/FTLCompile.cpp:
        * wasm/WasmSectionParser.cpp:
        * wasm/WasmTable.cpp:
        * wasm/WasmValidate.cpp:

2019-06-10  Keith Miller  <keith_miller@apple.com>

        Make new Symbol/Promise API public
        https://bugs.webkit.org/show_bug.cgi?id=198709

        Reviewed by Saam Barati.

        We also need to #ifdef some tests when building for older
        platforms because the signatures for some methods are outdated on
        those platforms.

        * API/JSObjectRef.h:
        * API/JSObjectRefPrivate.h:
        * API/JSValue.h:
        * API/JSValuePrivate.h:
        * API/JSValueRef.h:
        * API/tests/testapi.mm:
        (testObjectiveCAPIMain):

2019-06-09  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r246150, r246160, and r246166.
        https://bugs.webkit.org/show_bug.cgi?id=198698

        Regresses page loading time on iOS 13 (Requested by keith_m__
        on #webkit).

        Reverted changesets:

        "Reenable Gigacage on ARM64."
        https://bugs.webkit.org/show_bug.cgi?id=198453
        https://trac.webkit.org/changeset/246150

        "Unrevied build fix for FTL without Gigacage."
        https://trac.webkit.org/changeset/246160

        "Fix typo in cageWithoutUntagging"
        https://bugs.webkit.org/show_bug.cgi?id=198617
        https://trac.webkit.org/changeset/246166

2019-06-09  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Use mergePrediction in ValuePow prediction propagation
        https://bugs.webkit.org/show_bug.cgi?id=198648

        Reviewed by Saam Barati.

        We are accidentally using setPrediction. This is wrong since prediction propagation (not processInvariant)
        must extend the speculation types to ensure we eventually reach to the fixed point. setPrediction can discard
        previously configured predictions, can lead to oscillation potentially. Use mergePrediction instead.

        * dfg/DFGPredictionPropagationPhase.cpp:

2019-06-07  Tadeu Zagallo  <tzagallo@apple.com>

        AI should get GetterSetter structure from the base's GlobalObject for GetGetterSetterByOffset
        https://bugs.webkit.org/show_bug.cgi?id=198581
        <rdar://problem/51099753>

        Reviewed by Saam Barati.

        For GetGetterSetterByOffset, when the abstract interpreter fails to read the property
        from the object, it gets the GetterSetter structure from the CodeBlock's global object.
        However, that's not correct, since the global object for the base object might differ
        from the CodeBlock's. Instead, we try to get the global object from the base, when it's
        a constant object. Otherwise, we can't infer the value and only set the type.

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

2019-06-06  Devin Rousso  <drousso@apple.com>

        Web Inspector: create CommandLineAPIHost lazily like the other agents
        https://bugs.webkit.org/show_bug.cgi?id=196047
        <rdar://problem/49087835>

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScriptManager.h:
        * inspector/InjectedScriptManager.cpp:
        (Inspector::InjectedScriptManager::connect): Added.

2019-06-06  Keith Miller  <keith_miller@apple.com>

        Fix typo in cageWithoutUntagging
        https://bugs.webkit.org/show_bug.cgi?id=198617

        Reviewed by Saam Barati.

        * assembler/testmasm.cpp:
        (JSC::testCagePreservesPACFailureBit):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
        (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::cageWithoutUntagging):
        (JSC::AssemblyHelpers::cageConditionally):
        (JSC::AssemblyHelpers::cageWithoutUntaging): Deleted.

2019-06-06  Alexey Shvayka  <shvaikalesh@gmail.com>

        JSON.parse throws incorrect exception when called w/o arguments
        https://bugs.webkit.org/show_bug.cgi?id=198574

        Reviewed by Yusuke Suzuki.

        Always coerce first argument to string and attempt to parse it.
        (steps 1-2 of https://tc39.github.io/ecma262/#sec-json.parse)

        * runtime/JSONObject.cpp:
        (JSC::JSONProtoFuncParse): Remove argumentCount check.

2019-06-06  Keith Miller  <keith_miller@apple.com>

        Unrevied build fix for FTL without Gigacage.

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

2019-06-06  Michael Catanzaro  <mcatanzaro@igalia.com>

        aarch64: ‘JSC::ARM64Assembler::LinkRecord::<unnamed union>::RealTypes::m_compareRegister’ is too small to hold all values of ‘JSC::ARM64Assembler::RegisterID’ {aka ‘enum JSC::ARM64Registers::RegisterID’}
        https://bugs.webkit.org/show_bug.cgi?id=198014

        Reviewed by Yusuke Suzuki.

        When building for aarch64, there is a huge warning spam here. It's impossible to see any
        other warnings. This has been ongoing for so long I've begun to suspect that nobody works
        on this architecture.

        Anyway, the problem is because we need eight bits to store all possible RegisterID values,
        but the bitfield is only six bits wide. Fix it. The COMPILE_ASSERT checking the size of this
        struct is still happy, so I presume the change is OK.

        * assembler/ARM64Assembler.h:

2019-06-06  Keith Miller  <keith_miller@apple.com>

        Reenable Gigacage on ARM64.
        https://bugs.webkit.org/show_bug.cgi?id=198453

        Reviewed by Michael Saboff.

        This patch adds back Gigacaging on Apple's ARM64 ports. Unlike the
        old Gigacage however, arm64e uses both Gigacaging and PAC. In
        order to ensure the PAC bits are not stripped in the caging
        process we use the bit field insert instruction to take the low
        bits from caging and the high bits from the PAC authentication.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::bitFieldInsert64):
        * assembler/MacroAssemblerARM64E.h:
        * assembler/testmasm.cpp:
        (JSC::testCagePreservesPACFailureBit):
        (JSC::run):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds):
        (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
        (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
        (JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
        (JSC::FTL::DFG::LowerDFGToB3::caged):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::cageWithoutUntaging):
        (JSC::AssemblyHelpers::cageConditionally):
        (JSC::AssemblyHelpers::cage): Deleted.
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitIntTypedArrayGetByVal):
        (JSC::JIT::emitFloatTypedArrayGetByVal):
        (JSC::JIT::emitIntTypedArrayPutByVal):
        (JSC::JIT::emitFloatTypedArrayPutByVal):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter64.asm:
        * offlineasm/arm64.rb:
        * offlineasm/instructions.rb:
        * offlineasm/registers.rb:
        * wasm/WasmAirIRGenerator.cpp:
        (JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
        (JSC::Wasm::AirIRGenerator::addCallIndirect):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
        (JSC::Wasm::B3IRGenerator::addCallIndirect):
        * wasm/WasmBinding.cpp:
        (JSC::Wasm::wasmToWasm):
        * wasm/js/JSToWasm.cpp:
        (JSC::Wasm::createJSToWasmWrapper):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::WebAssemblyFunction::jsCallEntrypointSlow):

2019-06-06  Michael Saboff  <msaboff@apple.com>

        [ARM64E]: Add disassembler support for authenticated instructions
        https://bugs.webkit.org/show_bug.cgi?id=198562

        Reviewed by Keith Miller.

        Added support for all the instructions supported in ARM64EAssembler.h.

        * disassembler/ARM64/A64DOpcode.cpp:
        (JSC::ARM64Disassembler::A64DOpcodeDataProcessing1Source::format):
        (JSC::ARM64Disassembler::A64DOpcodeDataProcessing2Source::format):
        (JSC::ARM64Disassembler::A64DOpcodeHint::format):
        (JSC::ARM64Disassembler::A64DOpcodeHint::opName):
        (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::format):
        (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::authOpName):
        (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::format):
        * disassembler/ARM64/A64DOpcode.h:
        (JSC::ARM64Disassembler::A64DOpcodeDataProcessing2Source::opNameIndex):
        (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::opName):
        (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::opNum):
        (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::mBit):
        (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::sBit):
        (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::wBit):
        (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::immediate10):
        (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::authOpCode):
        (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::op2):
        (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::op3):
        (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::op4):
        (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::mBit):
        (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::rm):
        (JSC::ARM64Disassembler::A64DOpcodeHint::opName): Deleted.

2019-06-05  Justin Michaud  <justin_michaud@apple.com>

        [WASM-References] Add support for Anyref tables, Table.get and Table.set (for Anyref only).
        https://bugs.webkit.org/show_bug.cgi?id=198398

        Reviewed by Saam Barati.

        Create a new table subtype called FuncRefTable (note: Anyfunc was renamed to Funcref in the references spec).
        Table now write-barriers and visits its children's wrapper objects. FuncRefTable caches some extra data to
        support calling from wasm. A JSWebAssemblyTable is required to set an anyref element, but this is only because
        we need to write barrier it (so it should not restrict how we implement threads). This patch does, however,
        restrict the implementation of function references to require every Ref.func to have an associated wrapper. This
        can be done statically, so this too should not restrict our threads implementation. 

        * wasm/WasmAirIRGenerator.cpp:
        (JSC::Wasm::AirIRGenerator::addTableGet):
        (JSC::Wasm::AirIRGenerator::addTableSet):
        (JSC::Wasm::AirIRGenerator::addCallIndirect):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::addLocal):
        (JSC::Wasm::B3IRGenerator::addTableGet):
        (JSC::Wasm::B3IRGenerator::addTableSet):
        (JSC::Wasm::B3IRGenerator::addCallIndirect):
        * wasm/WasmFormat.h:
        (JSC::Wasm::TableInformation::TableInformation):
        (JSC::Wasm::TableInformation::type const):
        * wasm/WasmFunctionParser.h:
        (JSC::Wasm::FunctionParser<Context>::parseExpression):
        (JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
        * wasm/WasmSectionParser.cpp:
        (JSC::Wasm::SectionParser::parseTableHelper):
        * wasm/WasmTable.cpp:
        (JSC::Wasm::Table::Table):
        (JSC::Wasm::Table::tryCreate):
        (JSC::Wasm::Table::grow):
        (JSC::Wasm::Table::clear):
        (JSC::Wasm::Table::set):
        (JSC::Wasm::Table::get):
        (JSC::Wasm::Table::visitChildren):
        (JSC::Wasm::FuncRefTable::FuncRefTable):
        (JSC::Wasm::FuncRefTable::setFunction):
        (JSC::Wasm::Table::~Table): Deleted.
        (JSC::Wasm::Table::clearFunction): Deleted.
        (JSC::Wasm::Table::setFunction): Deleted.
        * wasm/WasmTable.h:
        (JSC::Wasm::Table::length const):
        (JSC::Wasm::Table::type const):
        (JSC::Wasm::Table::setOwner):
        (JSC::Wasm::FuncRefTable::offsetOfFunctions):
        (JSC::Wasm::FuncRefTable::offsetOfInstances):
        (JSC::Wasm::Table::offsetOfFunctions): Deleted.
        (JSC::Wasm::Table::offsetOfInstances): Deleted.
        * wasm/WasmValidate.cpp:
        (JSC::Wasm::Validate::addTableGet):
        (JSC::Wasm::Validate::addTableSet):
        (JSC::Wasm::Validate::addCallIndirect):
        * wasm/js/JSWebAssemblyTable.cpp:
        (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
        (JSC::JSWebAssemblyTable::finishCreation):
        (JSC::JSWebAssemblyTable::visitChildren):
        (JSC::JSWebAssemblyTable::grow):
        (JSC::JSWebAssemblyTable::get):
        (JSC::JSWebAssemblyTable::set):
        (JSC::JSWebAssemblyTable::clear):
        (JSC::JSWebAssemblyTable::getFunction): Deleted.
        (JSC::JSWebAssemblyTable::clearFunction): Deleted.
        (JSC::JSWebAssemblyTable::setFunction): Deleted.
        * wasm/js/JSWebAssemblyTable.h:
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::link):
        (JSC::WebAssemblyModuleRecord::evaluate):
        * wasm/js/WebAssemblyTableConstructor.cpp:
        (JSC::constructJSWebAssemblyTable):
        * wasm/js/WebAssemblyTablePrototype.cpp:
        (JSC::webAssemblyTableProtoFuncGet):
        (JSC::webAssemblyTableProtoFuncSet):
        * wasm/wasm.json:

2019-06-05  Justin Michaud  <justin_michaud@apple.com>

        WebAssembly: pow functions returns 0 when exponent 1.0 or -1.0
        https://bugs.webkit.org/show_bug.cgi?id=198106

        Reviewed by Saam Barati.

        Fix bug caused by using fcsel sX instead of fcsel dX on an f64 value in moveDoubleConditionally32.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::moveDoubleConditionally32):

2019-06-05  Alex Christensen  <achristensen@webkit.org>

        Progress towards resurrecting Mac CMake build
        https://bugs.webkit.org/show_bug.cgi?id=197132

        Reviewed by Don Olmstead.

        * API/JSScript.mm:
        (-[JSScript readCache]):
        (-[JSScript sourceCode]):
        (-[JSScript jsSourceCode]):
        (-[JSScript writeCache:]):
        * CMakeLists.txt:

== Rolled over to ChangeLog-2019-06-05 ==