Re-enable generate-xcfilelists
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
index b91c29f..82d5cfe 100644 (file)
+2019-05-17  Keith Rollin  <krollin@apple.com>
+
+        Re-enable generate-xcfilelists
+        https://bugs.webkit.org/show_bug.cgi?id=197933
+        <rdar://problem/50831677>
+
+        Reviewed by Jonathan Bedard.
+
+        The following two tasks have been completed, and we can re-enable
+        generate-xcfilelists:
+
+        Bug 197619 <rdar://problem/50507392> Temporarily disable generate-xcfilelists (197619)
+        Bug 197622 <rdar://problem/50508222> Rewrite generate-xcfilelists in Python (197622)
+
+        * Scripts/check-xcfilelists.sh:
+
+2019-05-16  Keith Miller  <keith_miller@apple.com>
+
+        Wasm should cage the memory base pointers in structs
+        https://bugs.webkit.org/show_bug.cgi?id=197620
+
+        Reviewed by Saam Barati.
+
+        Currently, we use cageConditionally; this only matters for API
+        users since the web content process cannot disable primitive
+        gigacage. This patch also adds a set helper for union/intersection
+        of RegisterSets.
+
+        * assembler/CPU.h:
+        (JSC::isARM64E):
+        * jit/RegisterSet.h:
+        (JSC::RegisterSet::set):
+        * 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/WasmInstance.h:
+        (JSC::Wasm::Instance::cachedMemory const):
+        (JSC::Wasm::Instance::updateCachedMemory):
+        * wasm/WasmMemory.cpp:
+        (JSC::Wasm::Memory::grow):
+        * wasm/WasmMemory.h:
+        (JSC::Wasm::Memory::memory const):
+        * wasm/js/JSToWasm.cpp:
+        (JSC::Wasm::createJSToWasmWrapper):
+        * wasm/js/WebAssemblyFunction.cpp:
+        (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
+
+2019-05-16  David Kilzer  <ddkilzer@apple.com>
+
+        REGRESSION (r15133): Fix leak of JSStringRef in minidom
+        <https://webkit.org/b/197968>
+        <rdar://problem/50872430>
+
+        Reviewed by Joseph Pecoraro.
+
+        * API/tests/minidom.c:
+        (print): Call JSStringRelease() to fix the leak.
+
+2019-05-16  Ross Kirsling  <ross.kirsling@sony.com>
+
+        [JSC] Invalid AssignmentTargetType should be an early error.
+        https://bugs.webkit.org/show_bug.cgi?id=197603
+
+        Reviewed by Keith Miller.
+
+        Since ES6, expressions like 0++, ++0, 0 = 0, and 0 += 0 are all specified as early errors:
+          https://tc39.github.io/ecma262/#sec-update-expressions-static-semantics-early-errors
+          https://tc39.github.io/ecma262/#sec-assignment-operators-static-semantics-early-errors
+
+        We currently throw late ReferenceErrors for these -- let's turn them into early SyntaxErrors.
+        (This is based on the expectation that https://github.com/tc39/ecma262/pull/1527 will be accepted;
+        if that doesn't come to pass, we can subsequently introduce early ReferenceError and revise these.)
+
+        * bytecompiler/NodesCodegen.cpp:
+        (JSC::PostfixNode::emitBytecode): Add an assert for "function call LHS" case.
+        (JSC::PrefixNode::emitBytecode): Add an assert for "function call LHS" case.
+
+        * parser/ASTBuilder.h:
+        (JSC::ASTBuilder::isLocation): Added.
+        (JSC::ASTBuilder::isAssignmentLocation): Fix misleading parameter name.
+        (JSC::ASTBuilder::isFunctionCall): Added.
+        (JSC::ASTBuilder::makeAssignNode): Add an assert for "function call LHS" case.
+        * parser/SyntaxChecker.h:
+        (JSC::SyntaxChecker::isLocation): Added.
+        (JSC::SyntaxChecker::isAssignmentLocation): Fix incorrect definition and align with ASTBuilder.
+        (JSC::SyntaxChecker::isFunctionCall): Added.
+        * parser/Nodes.h:
+        (JSC::ExpressionNode::isFunctionCall const): Added.
+        Ensure that the parser can check whether an expression node is a function call.
+
+        * parser/Parser.cpp:
+        (JSC::Parser<LexerType>::isSimpleAssignmentTarget): Added.
+        (JSC::Parser<LexerType>::parseAssignmentExpression):
+        (JSC::Parser<LexerType>::parseUnaryExpression): See below.
+        * parser/Parser.h:
+        Throw SyntaxError whenever an assignment or update expression's target is invalid.
+        Unfortunately, it seems that web compatibility obliges us to exempt the "function call LHS" case in sloppy mode.
+        (https://github.com/tc39/ecma262/issues/257#issuecomment-195106880)
+
+        Additional cleanup items:
+          - Make use of `semanticFailIfTrue` for `isMetaProperty` checks, as it's equivalent.
+          - Rename `requiresLExpr` to `hasPrefixUpdateOp` since it's now confusing,
+            and get rid of `modifiesExpr` since it refers to the exact same condition.
+          - Stop setting `lastOperator` near the end -- one case was incorrect and regardless neither is used.
+
+2019-05-15  Saam Barati  <sbarati@apple.com>
+
+        Bound liveness of SetArgumentMaybe nodes when maximal flush insertion phase is enabled
+        https://bugs.webkit.org/show_bug.cgi?id=197855
+        <rdar://problem/50236506>
+
+        Reviewed by Michael Saboff.
+
+        Maximal flush insertion phase assumes it can extend the live range of
+        variables. However, this is not true with SetArgumentMaybe nodes, because
+        they are not guaranteed to demarcate the birth of a variable in the way
+        that SetArgumentDefinitely does. This caused things to break in SSA conversion
+        when we wanted to use the result of a SetArgumentMaybe node. To obviate this,
+        when we're done inlining something with SetArgumentMaybes, we SetLocal(undefined)
+        to the same set of locals. This caps the live range of the SetArgumentMaybe
+        and makes it so that extending the live range of the SetLocal is valid.
+
+        * dfg/DFGByteCodeParser.cpp:
+        (JSC::DFG::ByteCodeParser::handleVarargsInlining):
+
+2019-05-14  Keith Miller  <keith_miller@apple.com>
+
+        Fix issue with byteOffset on ARM64E
+        https://bugs.webkit.org/show_bug.cgi?id=197884
+
+        Reviewed by Saam Barati.
+
+        We forgot to remove the tag from the ArrayBuffer's data
+        pointer. This corrupted data when computing the offset.  We didn't
+        catch this because we didn't run any with a non-zero byteOffset in
+        the JITs.
+
+        * dfg/DFGSpeculativeJIT.cpp:
+        (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
+        * ftl/FTLLowerDFGToB3.cpp:
+        (JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset):
+        (JSC::FTL::DFG::LowerDFGToB3::untagArrayPtr):
+        (JSC::FTL::DFG::LowerDFGToB3::removeArrayPtrTag):
+        (JSC::FTL::DFG::LowerDFGToB3::speculateTypedArrayIsNotNeutered):
+        * jit/IntrinsicEmitter.cpp:
+        (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
+
+2019-05-14  Tadeu Zagallo  <tzagallo@apple.com>
+
+        REGRESSION (r245249): ASSERTION FAILED: !m_needExceptionCheck seen with stress/proxy-delete.js and stress/proxy-property-descriptor.js
+        https://bugs.webkit.org/show_bug.cgi?id=197885
+        <rdar://problem/50770190>
+
+        Reviewed by Yusuke Suzuki.
+
+        In r245249 we added a throw scope to JSObject::getOwnPropertyDescriptor and its
+        callers now need to check for exceptions.
+
+        * runtime/ProxyObject.cpp:
+        (JSC::performProxyGet):
+        (JSC::ProxyObject::performDelete):
+
+2019-05-14  Ross Kirsling  <ross.kirsling@sony.com>
+
+        Unreviewed restoration of non-unified build.
+
+        * dfg/DFGMinifiedID.h:
+        * runtime/ObjectToStringAdaptiveStructureWatchpoint.cpp:
+
+2019-05-14  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Shrink sizeof(UnlinkedFunctionExecutable) more
+        https://bugs.webkit.org/show_bug.cgi?id=197833
+
+        Reviewed by Darin Adler.
+
+        It turns out that Gmail creates so many JSFunctions, FunctionExecutables, and UnlinkedFunctionExecutables.
+        So we should shrink size of them to save memory. As a first step, this patch reduces the sizeof(UnlinkedFunctionExecutable) more by 16 bytes.
+
+        1. We reorder some fields to get 8 bytes. And we use 31 bits for xxx offset things since their maximum size should be within 31 bits due to
+           String's length & int32_t representation in our parser.
+
+        2. We drop m_inferredName and prefer m_ecmaName. The inferred name is used to offer better function name when the function expression lacks
+           the name, but now ECMAScript has a specified semantics to name those functions with intuitive names. We should use ecmaName consistently,
+           and should not eat 8 bytes for inferred names in UnlinkedFunctionExecutable.
+
+        We also fix generator ecma name.
+
+        * bytecode/CodeBlock.cpp:
+        (JSC::CodeBlock::inferredName const):
+        * bytecode/InlineCallFrame.cpp:
+        (JSC::InlineCallFrame::inferredName const):
+        * bytecode/UnlinkedFunctionExecutable.cpp:
+        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
+        * bytecode/UnlinkedFunctionExecutable.h:
+        * parser/ASTBuilder.h:
+        (JSC::ASTBuilder::createAssignResolve):
+        (JSC::ASTBuilder::createGeneratorFunctionBody):
+        (JSC::ASTBuilder::createGetterOrSetterProperty):
+        (JSC::ASTBuilder::createProperty):
+        (JSC::ASTBuilder::tryInferNameInPatternWithIdentifier):
+        (JSC::ASTBuilder::makeAssignNode):
+        * parser/Nodes.cpp:
+        (JSC::FunctionMetadataNode::operator== const):
+        (JSC::FunctionMetadataNode::dump const):
+        * parser/Nodes.h:
+        * runtime/CachedTypes.cpp:
+        (JSC::CachedFunctionExecutable::ecmaName const):
+        (JSC::CachedFunctionExecutable::encode):
+        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
+        (JSC::CachedFunctionExecutable::inferredName const): Deleted.
+        * runtime/FunctionExecutable.h:
+        * runtime/FunctionExecutableDump.cpp:
+        (JSC::FunctionExecutableDump::dump const):
+        * runtime/JSFunction.cpp:
+        (JSC::JSFunction::calculatedDisplayName):
+        (JSC::getCalculatedDisplayName):
+        * runtime/SamplingProfiler.cpp:
+        (JSC::SamplingProfiler::StackFrame::displayName):
+        (JSC::SamplingProfiler::StackFrame::displayNameForJSONTests):
+
+2019-05-13  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Compress JIT related data more by using Packed<>
+        https://bugs.webkit.org/show_bug.cgi?id=197866
+
+        Reviewed by Saam Barati.
+
+        This patch leverages Packed<> more to reduce JIT related data size. When we measure memory usage on Gmail, we found that a lot of memory is
+        consumed in DFG data. This patch attempts to reduce that size by using Packed<> to make various data structure's alignment 1.
+
+        * dfg/DFGCommonData.cpp:
+        (JSC::DFG::CommonData::shrinkToFit): Add more shrinkToFit.
+        * dfg/DFGMinifiedID.h: Make alignment = 1.
+        (JSC::DFG::MinifiedID::operator! const):
+        (JSC::DFG::MinifiedID::operator== const):
+        (JSC::DFG::MinifiedID::operator!= const):
+        (JSC::DFG::MinifiedID::operator< const):
+        (JSC::DFG::MinifiedID::operator> const):
+        (JSC::DFG::MinifiedID::operator<= const):
+        (JSC::DFG::MinifiedID::operator>= const):
+        (JSC::DFG::MinifiedID::hash const):
+        (JSC::DFG::MinifiedID::dump const):
+        (JSC::DFG::MinifiedID::isHashTableDeletedValue const):
+        (JSC::DFG::MinifiedID::bits const):
+        * dfg/DFGMinifiedIDInlines.h:
+        (JSC::DFG::MinifiedID::MinifiedID):
+        * dfg/DFGMinifiedNode.cpp:
+        (JSC::DFG::MinifiedNode::fromNode): Make sizeof(MinifiedNode) from 16 to 13 with alignment = 1.
+        * dfg/DFGMinifiedNode.h:
+        (JSC::DFG::MinifiedNode::id const):
+        (JSC::DFG::MinifiedNode::hasConstant const):
+        (JSC::DFG::MinifiedNode::constant const):
+        (JSC::DFG::MinifiedNode::isPhantomDirectArguments const):
+        (JSC::DFG::MinifiedNode::isPhantomClonedArguments const):
+        (JSC::DFG::MinifiedNode::hasInlineCallFrame const):
+        (JSC::DFG::MinifiedNode::inlineCallFrame const):
+        (JSC::DFG::MinifiedNode::op const): Deleted.
+        (JSC::DFG::MinifiedNode::hasInlineCallFrame): Deleted.
+        * dfg/DFGVariableEvent.h: Make sizeof(VariableEvent) from 12 to 10 with alignment = 1.
+        (JSC::DFG::VariableEvent::fillGPR):
+        (JSC::DFG::VariableEvent::fillPair):
+        (JSC::DFG::VariableEvent::fillFPR):
+        (JSC::DFG::VariableEvent::birth):
+        (JSC::DFG::VariableEvent::spill):
+        (JSC::DFG::VariableEvent::death):
+        (JSC::DFG::VariableEvent::setLocal):
+        (JSC::DFG::VariableEvent::movHint):
+        (JSC::DFG::VariableEvent::id const):
+        (JSC::DFG::VariableEvent::gpr const):
+        (JSC::DFG::VariableEvent::tagGPR const):
+        (JSC::DFG::VariableEvent::payloadGPR const):
+        (JSC::DFG::VariableEvent::fpr const):
+        (JSC::DFG::VariableEvent::spillRegister const):
+        (JSC::DFG::VariableEvent::bytecodeRegister const):
+        (JSC::DFG::VariableEvent::machineRegister const):
+        (JSC::DFG::VariableEvent::variableRepresentation const):
+        * dfg/DFGVariableEventStream.cpp:
+        (JSC::DFG::tryToSetConstantRecovery):
+
+2019-05-13  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [WTF] Simplify GCThread and CompilationThread flags by adding them to WTF::Thread
+        https://bugs.webkit.org/show_bug.cgi?id=197146
+
+        Reviewed by Saam Barati.
+
+        Rename Heap::Thread to Heap::HeapThread to remove conflict between WTF::Thread.
+
+        * heap/AlignedMemoryAllocator.cpp:
+        (JSC::AlignedMemoryAllocator::registerDirectory):
+        * heap/Heap.cpp:
+        (JSC::Heap::HeapThread::HeapThread):
+        (JSC::Heap::Heap):
+        (JSC::Heap::runCurrentPhase):
+        (JSC::Heap::runBeginPhase):
+        (JSC::Heap::resumeThePeriphery):
+        (JSC::Heap::requestCollection):
+        (JSC::Heap::isCurrentThreadBusy):
+        (JSC::Heap::notifyIsSafeToCollect):
+        (JSC::Heap::Thread::Thread): Deleted.
+        * heap/Heap.h:
+        * heap/HeapInlines.h:
+        (JSC::Heap::incrementDeferralDepth):
+        (JSC::Heap::decrementDeferralDepth):
+        (JSC::Heap::decrementDeferralDepthAndGCIfNeeded):
+        * heap/MarkedSpace.cpp:
+        (JSC::MarkedSpace::prepareForAllocation):
+
+2019-05-13  Saam Barati  <sbarati@apple.com>
+
+        macro assembler code-pointer tagging has its arguments backwards
+        https://bugs.webkit.org/show_bug.cgi?id=197677
+
+        Reviewed by Michael Saboff.
+
+        We had the destination as the leftmost instead of the rightmost argument,
+        which goes against the convention of how we order arguments in macro assembler
+        methods.
+
+        * assembler/MacroAssemblerARM64E.h:
+        (JSC::MacroAssemblerARM64E::tagReturnAddress):
+        (JSC::MacroAssemblerARM64E::untagReturnAddress):
+        (JSC::MacroAssemblerARM64E::tagPtr):
+        (JSC::MacroAssemblerARM64E::untagPtr):
+        * dfg/DFGOSRExitCompilerCommon.cpp:
+        (JSC::DFG::reifyInlinedCallFrames):
+        * ftl/FTLThunks.cpp:
+        (JSC::FTL::genericGenerationThunkGenerator):
+        * jit/CCallHelpers.h:
+        (JSC::CCallHelpers::prepareForTailCallSlow):
+        * jit/CallFrameShuffler.cpp:
+        (JSC::CallFrameShuffler::prepareForTailCall):
+        * jit/ThunkGenerators.cpp:
+        (JSC::emitPointerValidation):
+        (JSC::arityFixupGenerator):
+        * wasm/js/WebAssemblyFunction.cpp:
+        (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
+
+2019-05-13  Tadeu Zagallo  <tzagallo@apple.com>
+
+        JSObject::getOwnPropertyDescriptor is missing an exception check
+        https://bugs.webkit.org/show_bug.cgi?id=197693
+        <rdar://problem/50441784>
+
+        Reviewed by Saam Barati.
+
+        The method table call to getOwnPropertySlot might throw, and JSObject::getOwnPropertyDescriptor
+        must handle the exception before calling PropertySlot::getValue, which can also throw.
+
+        * runtime/JSObject.cpp:
+        (JSC::JSObject::getOwnPropertyDescriptor):
+
+2019-05-13  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Compress miscelaneous JIT related data structures with Packed<>
+        https://bugs.webkit.org/show_bug.cgi?id=197830
+
+        Reviewed by Saam Barati.
+
+        This patch leverages Packed<> to compress miscelaneous data structures related to JIT.
+
+        1. JIT IC data structures
+
+        2. ValueRecovery
+
+            We use Packed<> for EncodedJSValue in ValueRecovery. This means that conservative GC cannot find
+            these values. But this is OK anyway since ValueRecovery's constant should be already registered
+            in DFG graph. From 16 (alignment 8) to 9 (alignment 1).
+
+        3. FTL::ExitValue
+
+            We use Packed<> for EncodedJSValue in FTL::ExitValue. This is also OK since this constant should
+            be already registered by DFG/FTL graph. From 16 (alignment 8) to 9 (alignment 1).
+
+        * assembler/CodeLocation.h:
+        * bytecode/ByValInfo.h:
+        * bytecode/CallLinkInfo.cpp:
+        (JSC::CallLinkInfo::CallLinkInfo):
+        (JSC::CallLinkInfo::callReturnLocation):
+        * bytecode/CallLinkInfo.h:
+        (JSC::CallLinkInfo::nearCallMode const):
+        * bytecode/CodeBlock.cpp:
+        (JSC::CodeBlock::addJITAddIC):
+        (JSC::CodeBlock::addJITMulIC):
+        (JSC::CodeBlock::addJITSubIC):
+        (JSC::CodeBlock::addJITNegIC):
+        * bytecode/CodeBlock.h:
+        (JSC::CodeBlock::addMathIC):
+        * bytecode/InlineCallFrame.h:
+        (JSC::InlineCallFrame::InlineCallFrame):
+        * bytecode/ValueRecovery.h:
+        (JSC::ValueRecovery::inGPR):
+        (JSC::ValueRecovery::inPair):
+        (JSC::ValueRecovery::inFPR):
+        (JSC::ValueRecovery::displacedInJSStack):
+        (JSC::ValueRecovery::constant):
+        (JSC::ValueRecovery::directArgumentsThatWereNotCreated):
+        (JSC::ValueRecovery::clonedArgumentsThatWereNotCreated):
+        (JSC::ValueRecovery::gpr const):
+        (JSC::ValueRecovery::tagGPR const):
+        (JSC::ValueRecovery::payloadGPR const):
+        (JSC::ValueRecovery::fpr const):
+        (JSC::ValueRecovery::virtualRegister const):
+        (JSC::ValueRecovery::withLocalsOffset const):
+        (JSC::ValueRecovery::constant const):
+        (JSC::ValueRecovery::nodeID const):
+        * dfg/DFGSpeculativeJIT.cpp:
+        (JSC::DFG::SpeculativeJIT::compileValueAdd):
+        (JSC::DFG::SpeculativeJIT::compileValueSub):
+        (JSC::DFG::SpeculativeJIT::compileValueNegate):
+        (JSC::DFG::SpeculativeJIT::compileValueMul):
+        * ftl/FTLExitValue.cpp:
+        (JSC::FTL::ExitValue::materializeNewObject):
+        * ftl/FTLExitValue.h:
+        (JSC::FTL::ExitValue::inJSStack):
+        (JSC::FTL::ExitValue::inJSStackAsInt32):
+        (JSC::FTL::ExitValue::inJSStackAsInt52):
+        (JSC::FTL::ExitValue::inJSStackAsDouble):
+        (JSC::FTL::ExitValue::constant):
+        (JSC::FTL::ExitValue::exitArgument):
+        (JSC::FTL::ExitValue::exitArgument const):
+        (JSC::FTL::ExitValue::adjustStackmapLocationsIndexByOffset):
+        (JSC::FTL::ExitValue::constant const):
+        (JSC::FTL::ExitValue::virtualRegister const):
+        (JSC::FTL::ExitValue::objectMaterialization const):
+        (JSC::FTL::ExitValue::withVirtualRegister const):
+        * ftl/FTLLowerDFGToB3.cpp:
+        (JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
+        (JSC::FTL::DFG::LowerDFGToB3::compileValueSub):
+        (JSC::FTL::DFG::LowerDFGToB3::compileValueMul):
+        (JSC::FTL::DFG::LowerDFGToB3::compileUnaryMathIC):
+        (JSC::FTL::DFG::LowerDFGToB3::compileBinaryMathIC):
+        (JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub):
+        (JSC::FTL::DFG::LowerDFGToB3::compileValueNegate):
+        * jit/CachedRecovery.h:
+        * jit/CallFrameShuffleData.h:
+        * jit/JITArithmetic.cpp:
+        (JSC::JIT::emit_op_negate):
+        (JSC::JIT::emit_op_add):
+        (JSC::JIT::emit_op_mul):
+        (JSC::JIT::emit_op_sub):
+        * jit/JITMathIC.h:
+        (JSC::isProfileEmpty):
+        (JSC::JITBinaryMathIC::JITBinaryMathIC):
+        (JSC::JITUnaryMathIC::JITUnaryMathIC):
+        * jit/PolymorphicCallStubRoutine.h:
+        (JSC::PolymorphicCallNode::hasCallLinkInfo):
+        * jit/SnippetOperand.h:
+        (JSC::SnippetOperand::asRawBits const):
+        (JSC::SnippetOperand::asConstInt32 const):
+        (JSC::SnippetOperand::asConstDouble const):
+        (JSC::SnippetOperand::setConstInt32):
+        (JSC::SnippetOperand::setConstDouble):
+
+2019-05-12  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Compress Watchpoint size by using enum type and Packed<> data structure
+        https://bugs.webkit.org/show_bug.cgi?id=197730
+
+        Reviewed by Filip Pizlo.
+
+        Watchpoint takes 5~ MB memory in Gmail (total memory starts with 400 - 500 MB), so 1~%. Since it is allocated massively,
+        reducing each size of Watchpoint reduces memory footprint significantly.
+
+        As a first step, this patch uses Packed<> and enum to reduce the size of Watchpoint.
+
+        1. Watchpoint should have enum type and should not use vtable. vtable takes one pointer, and it is too costly for such a
+           memory sensitive objects. We perform downcast and dispatch the method of the derived classes based on this enum. Since
+           the # of derived Watchpoint classes are limited (Only 8), we can list up them easily. One unfortunate thing is that
+           we cannot do this for destructor so long as we use "delete" for deleting objects. If we dispatch the destructor of derived
+           class in the destructor of the base class, we call the destructor of the base class multiple times. delete operator override
+           does not help since custom delete operator is called after the destructor is called. While we can fix this issue by always
+           using custom deleter, currently we do not since all the watchpoints do not have members which have non trivial destructor.
+           Once it is strongly required, we can start using custom deleter, but for now, we do not need to do this.
+
+        2. We use Packed<> to compact pointers in Watchpoint. Since Watchpoint is a node of doubly linked list, each one has two
+           pointers for prev and next. This is also too costly. PackedPtr reduces the size and makes alignment 1.S
+
+        3. We use PackedCellPtr<> for JSCells in Watchpoint. This leverages alignment information and makes pointers smaller in
+           Darwin ARM64. One important thing to note here is that since this pointer is packed, it cannot be found by conservative
+           GC scan. It is OK for watchpoint since they are allocated in the heap anyway.
+
+        We applied this change to Watchpoint and get the following memory reduction. The highlight is that CodeBlockJettisoningWatchpoint in
+        ARM64 only takes 2 pointers size.
+
+                                                                              ORIGINAL    X86_64   ARM64
+            WatchpointSet:                                                    40          32       28
+            CodeBlockJettisoningWatchpoint:                                   32          19       15
+            StructureStubClearingWatchpoint:                                  56          48       40
+            AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint: 24          13       11
+            AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint:  24          13       11
+            FunctionRareData::AllocationProfileClearingWatchpoint:            32          19       15
+            ObjectToStringAdaptiveStructureWatchpoint:                        56          48       40
+            LLIntPrototypeLoadAdaptiveStructureWatchpoint:                    64          48       48
+            DFG::AdaptiveStructureWatchpoint:                                 56          48       40
+
+        While we will re-architect the mechanism of Watchpoint, anyway Packed<> mechanism and enum types will be used too.
+
+        * CMakeLists.txt:
+        * JavaScriptCore.xcodeproj/project.pbxproj:
+        * Sources.txt:
+        * bytecode/AdaptiveInferredPropertyValueWatchpointBase.h:
+        * bytecode/CodeBlockJettisoningWatchpoint.h:
+        * bytecode/CodeOrigin.h:
+        * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
+        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
+        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
+        * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
+        * bytecode/StructureStubClearingWatchpoint.cpp:
+        (JSC::StructureStubClearingWatchpoint::fireInternal):
+        * bytecode/StructureStubClearingWatchpoint.h:
+        * bytecode/Watchpoint.cpp:
+        (JSC::Watchpoint::fire):
+        * bytecode/Watchpoint.h:
+        (JSC::Watchpoint::Watchpoint):
+        * dfg/DFGAdaptiveStructureWatchpoint.cpp:
+        (JSC::DFG::AdaptiveStructureWatchpoint::AdaptiveStructureWatchpoint):
+        * dfg/DFGAdaptiveStructureWatchpoint.h:
+        * heap/PackedCellPtr.h: Added.
+        * runtime/FunctionRareData.h:
+        * runtime/ObjectToStringAdaptiveStructureWatchpoint.cpp: Added.
+        (JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint):
+        (JSC::ObjectToStringAdaptiveStructureWatchpoint::install):
+        (JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
+        * runtime/ObjectToStringAdaptiveStructureWatchpoint.h: Added.
+        * runtime/StructureRareData.cpp:
+        (JSC::StructureRareData::clearObjectToStringValue):
+        (JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint): Deleted.
+        (JSC::ObjectToStringAdaptiveStructureWatchpoint::install): Deleted.
+        (JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal): Deleted.
+        * runtime/StructureRareData.h:
+
+2019-05-12  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Compact generator code's bytecode size
+        https://bugs.webkit.org/show_bug.cgi?id=197822
+
+        Reviewed by Michael Saboff.
+
+        op_put_to_scope's symbolTableOrScopeDepth is represented as int. This was OK for the old bytecode format since
+        VirtualRegister / scope depth can be represented by int anyway. But it is problematic now since only int8_t range
+        will be represented in narrow bytecode. When this field is used for symbol table constant index, it is always
+        larger than FirstConstantRegisterIndex. So it always exceeds the range of int8_t, and results in wide bytecode.
+        It makes all generator's op_put_to_scope wide bytecode.
+
+        In this patch, we introduce a new (logically) union type SymbolTableOrScopeDepth. It holds unsigned value, and we store the
+        SymbolTableConstantIndex - FirstConstantRegisterIndex in this unsigned value to make op_put_to_scope narrow bytecode.
+
+        * CMakeLists.txt:
+        * JavaScriptCore.xcodeproj/project.pbxproj:
+        * bytecode/BytecodeGeneratorification.cpp:
+        (JSC::BytecodeGeneratorification::run):
+        * bytecode/BytecodeList.rb:
+        * bytecode/CodeBlock.cpp:
+        (JSC::CodeBlock::finishCreation):
+        * bytecode/Fits.h:
+        * bytecompiler/BytecodeGenerator.cpp:
+        (JSC::BytecodeGenerator::BytecodeGenerator):
+        (JSC::BytecodeGenerator::emitProfileType):
+        (JSC::BytecodeGenerator::emitPutToScope):
+        (JSC::BytecodeGenerator::localScopeDepth const):
+        * bytecompiler/BytecodeGenerator.h:
+        * runtime/SymbolTableOrScopeDepth.h: Added.
+        (JSC::SymbolTableOrScopeDepth::symbolTable):
+        (JSC::SymbolTableOrScopeDepth::scopeDepth):
+        (JSC::SymbolTableOrScopeDepth::raw):
+        (JSC::SymbolTableOrScopeDepth::symbolTable const):
+        (JSC::SymbolTableOrScopeDepth::scopeDepth const):
+        (JSC::SymbolTableOrScopeDepth::raw const):
+        (JSC::SymbolTableOrScopeDepth::dump const):
+        (JSC::SymbolTableOrScopeDepth::SymbolTableOrScopeDepth):
+
+2019-05-10  Saam barati  <sbarati@apple.com>
+
+        Call to JSToWasmICCallee::createStructure passes in wrong prototype value
+        https://bugs.webkit.org/show_bug.cgi?id=197807
+        <rdar://problem/50530400>
+
+        Reviewed by Yusuke Suzuki.
+
+        We were passing the empty value instead of null. However, the empty
+        value means the Structure is poly proto. That's definitely not the case
+        here.
+
+        * runtime/JSGlobalObject.cpp:
+        (JSC::JSGlobalObject::init):
+
+2019-05-10  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] String substring operation should return ropes consistently
+        https://bugs.webkit.org/show_bug.cgi?id=197765
+        <rdar://problem/37689944>
+
+        Reviewed by Michael Saboff.
+
+        Currently we have different policies per string substring operation function.
+
+            1. String#slice returns the resolved non-rope string
+            2. String#substring returns rope string
+            3. String#substr returns rope string in runtime function, non-rope string in DFG and FTL
+
+        Due to (3), we see large memory use in the tested web page[1]. Non rope substring have a problem.
+        First of all, that returned string seems not used immediately. It is possible that the resulted
+        string is used as a part of the other ropes (like, xxx.substring(...) + "Hello"). To avoid the
+        eager materialization of the string, we are using StringImpl::createSubstringSharingImpl for the
+        resulted non rope string. StringImpl::createSubstringSharingImpl is StringImpl's substring feature: the
+        substring is pointing the owner StringImpl. While this has memory saving benefit, it can retain owner
+        StringImpl so long, and it could keep very large owner StringImpl alive.
+
+        The problem we are attempting to solve with StringImpl::createSubstringSharingImpl can be solved by
+        the rope string simply. Rope string can share the underlying string. And good feature of the rope
+        string is that, when resolving rope string, the rope string always create a new StringImpl instead of
+        using StringImpl::createSubstringSharingImpl. So we allow the owner StringImpl to be destroyed. And this
+        resolving only happens when we actually want to use the content of the rope string. In addition, we recently
+        shrunk the sizeof(JSRopeString) from 48 to 32, so JSRopeString is cheap.
+
+        In this patch, we change (2) and (3) to (1), using rope String as a result of substring operations.
+
+        RAMification and JetStream2 are neutral. The web page[1] shows large memory footprint improvement from 776MB to 681MB.
+
+        [1]: https://beta.observablehq.com/@ldgardner/assignment-4-visualizations-and-multiple-views
+
+        * dfg/DFGOperations.cpp:
+        * runtime/StringPrototype.cpp:
+        (JSC::stringProtoFuncSlice):
+        * runtime/StringPrototypeInlines.h:
+        (JSC::stringSlice):
+
+2019-05-10  Robin Morisset  <rmorisset@apple.com>
+
+        testb3 failing with crash in JSC::B3::BasicBlock::appendNonTerminal
+        https://bugs.webkit.org/show_bug.cgi?id=197756
+        <rdar://problem/50641659>
+
+        Reviewed by Saam Barati.
+
+        When I added https://bugs.webkit.org/show_bug.cgi?id=197265 I assumed that which block is the root does not change in the middle of strength reduction.
+        But specializeSelect can use splitForward, which uses a new block for the first half of the given block.
+        So if the block being split is the root block I must update m_root and erase the m_valueInConstant cache.
+        Erasing the cache cannot cause wrong results: at most it can make us miss some optimization opportunities in this iteration of the fixpoint.
+
+        * b3/B3ReduceStrength.cpp:
+
+2019-05-09  Keith Miller  <keith_miller@apple.com>
+
+        Fix crashes related to pointer authentication for primitive gigacage
+        https://bugs.webkit.org/show_bug.cgi?id=197763
+        <rdar://problem/50629257>
+
+        Reviewed by Saam Barati.
+
+        This fixes two bugs related to PAC for caging. The first is that
+        we didn't clear the high bits of the size register going into the
+        patchpoint to tag the new buffer for NewArrayBuffer. The second is
+        that the GC needs to strip all stack pointers when considering
+        them as a conservative root.
+
+        * ftl/FTLLowerDFGToB3.cpp:
+        (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
+        * heap/ConservativeRoots.cpp:
+        (JSC::ConservativeRoots::genericAddPointer):
+
+2019-05-09  Keith Miller  <keith_miller@apple.com>
+
+        parseStatementListItem needs a stack overflow check
+        https://bugs.webkit.org/show_bug.cgi?id=197749
+        <rdar://problem/50302697>
+
+        Reviewed by Saam Barati.
+
+        There currently exists a path in the parser where you can loop
+        arbibrarily many times without a stack overflow check. This patch
+        adds a check to parseStatementListItem to break that cycle.
+
+        * parser/Parser.cpp:
+        (JSC::Parser<LexerType>::parseStatementListItem):
+
+2019-05-09  Keith Miller  <keith_miller@apple.com>
+
+        REGRESSION (r245064): ASSERTION FAILED: m_ptr seen with wasm.yaml/wasm/js-api/test_Data.js.wasm-slow-memory
+        https://bugs.webkit.org/show_bug.cgi?id=197740
+
+        Reviewed by Saam Barati.
+
+        If a TypedArray constructor is called with just 0 as the first argument, we don't allocate a backing vector.
+        This means we need to handle null when calling vector() in ConstructionContext.
+
+        * runtime/JSArrayBufferView.h:
+        (JSC::JSArrayBufferView::ConstructionContext::vector const):
+
+2019-05-09  Xan L√≥pez  <xan@igalia.com>
+
+        [CMake] Detect SSE2 at compile time
+        https://bugs.webkit.org/show_bug.cgi?id=196488
+
+        Reviewed by Carlos Garcia Campos.
+
+        * assembler/MacroAssemblerX86Common.cpp: Remove unnecessary (and
+        incorrect) static_assert.
+        (JSC::MacroAssemblerX86Common::collectCPUFeatures):
+        * assembler/MacroAssemblerX86Common.h: Remove SSE2 flags.
+
+2019-05-08  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        Unreviewed, build fix after r245064
+        https://bugs.webkit.org/show_bug.cgi?id=197110
+
+        * runtime/GenericTypedArrayView.h:
+
+2019-05-08  Saam barati  <sbarati@apple.com>
+
+        AccessGenerationState::emitExplicitExceptionHandler can clobber an in use register
+        https://bugs.webkit.org/show_bug.cgi?id=197715
+        <rdar://problem/50399252>
+
+        Reviewed by Filip Pizlo.
+
+        AccessGenerationState::emitExplicitExceptionHandler was always clobbering
+        x86's r9 without considering if that register was needed to be preserved
+        by the IC. This leads to bad things when the DFG/FTL need that register when
+        OSR exitting after an exception from a GetById call.
+
+        * b3/air/AirCode.cpp:
+        (JSC::B3::Air::Code::Code):
+        * bytecode/PolymorphicAccess.cpp:
+        (JSC::AccessGenerationState::emitExplicitExceptionHandler):
+        * runtime/Options.h:
+
+2019-05-08  Ryan Haddad  <ryanhaddad@apple.com>
+
+        Unreviewed, rolling out r245068.
+
+        Caused debug layout tests to exit early due to an assertion
+        failure.
+
+        Reverted changeset:
+
+        "All prototypes should call didBecomePrototype()"
+        https://bugs.webkit.org/show_bug.cgi?id=196315
+        https://trac.webkit.org/changeset/245068
+
+2019-05-08  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        Invalid DFG JIT genereation in high CPU usage state
+        https://bugs.webkit.org/show_bug.cgi?id=197453
+
+        Reviewed by Saam Barati.
+
+        We have a DFG graph like this.
+
+            a: JSConstant(rope JSString)
+            b: CheckStringIdent(Check:StringUse:@a)
+            ... AI think this is unreachable ...
+
+        When executing StringUse edge filter onto @a, AbstractValue::filterValueByType clears AbstractValue and makes it None.
+        This is because @a constant produces SpecString (SpecStringVar | SpecStringIdent) while StringUse edge filter requires
+        SpecStringIdent. AbstractValue::filterValueByType has an assumption that the JS constant always produces the same
+        SpeculatedType. So it clears AbstractValue completely.
+        But this assumption is wrong. JSString can produce SpecStringIdent later if the string is resolved to AtomicStringImpl.
+        AI think that we always fail. But once the string is resolved to AtomicStringImpl, we pass this check. So we execute
+        the breakpoint emitted by DFG since DFG think this is unreachable.
+
+        In this patch, we just clear the `m_value` if AbstractValue type filter fails with the held constant, since the constant
+        may produce a narrower type which can meet the type filter later.
+
+        * dfg/DFGAbstractValue.cpp:
+        (JSC::DFG::AbstractValue::filterValueByType):
+
+2019-05-08  Robin Morisset  <rmorisset@apple.com>
+
+        All prototypes should call didBecomePrototype()
+        https://bugs.webkit.org/show_bug.cgi?id=196315
+
+        Reviewed by Saam Barati.
+
+        This changelog already landed, but the commit was missing the actual changes.
+
+        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/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-05-08  Keith Miller  <keith_miller@apple.com>
+
+        Remove Gigacage from arm64 and use PAC for arm64e instead
+        https://bugs.webkit.org/show_bug.cgi?id=197110
+
+        Reviewed by Saam Barati.
+
+        This patch makes a bunch of changes. I'll start with global changes then go over changes to each tier and finish with bug fixes.
+
+        Global Changes:
+        Change CagedBarrierPtr to work with PAC so constructors and accessors now expect to receive a length.
+        Update assembler helper methods to use do PAC when caging.
+
+        LLInt:
+        Add arm64e.rb backend as we missed that when originally open sourcing our arm64e code.
+        Add a new optional t6 temporary, which is only used currently on arm64e for GetByVal on a TypedArray.
+        Refactor caging into two helper macros for Primitive/JSValue cages.
+
+        Baseline/DFG:
+        Add authentication where needed for GetByVal and inline object construction.
+
+        FTL:
+        Add a new ValueRep that allows for a late register use. We want this for the authentication patchpoint since we use the length register at the same time as we are defing the authenticated pointer.
+
+        Wasm:
+        Use the TaggedArrayStoragePtr class for the memory base pointer. In theory we should be caging those pointers but I don't want to risk introducing a performance regression with the rest of this change. I've filed https://bugs.webkit.org/show_bug.cgi?id=197620 to do this later.
+        As we no longer have the Gigacage using most of our VA memory, we can enable fast memories on iOS.
+        Using fast memories leads to roughly a 2% JetStream2 speedup.
+
+        * assembler/MacroAssemblerARM64E.h:
+        (JSC::MacroAssemblerARM64E::tagArrayPtr):
+        (JSC::MacroAssemblerARM64E::untagArrayPtr):
+        (JSC::MacroAssemblerARM64E::removeArrayPtrTag):
+        * 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::untagArrayPtr):
+        (JSC::FTL::DFG::LowerDFGToB3::caged):
+        (JSC::FTL::DFG::LowerDFGToB3::speculateTypedArrayIsNotNeutered):
+        * 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):
+        * llint/LowLevelInterpreter64.asm:
+        * offlineasm/arm64.rb:
+        * offlineasm/arm64e.rb: Added.
+        * offlineasm/ast.rb:
+        * offlineasm/instructions.rb:
+        * offlineasm/registers.rb:
+        * offlineasm/x86.rb:
+        * 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::byteLength const):
+        (JSC::ArrayBufferView::setRangeImpl):
+        (JSC::ArrayBufferView::getRangeImpl):
+        * 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::getUnsafe const):
+        (JSC::CagedBarrierPtr::at const):
+        (JSC::CagedBarrierPtr::operator== const):
+        (JSC::CagedBarrierPtr::operator bool const):
+        (JSC::CagedBarrierPtr::setWithoutBarrier):
+        (JSC::CagedBarrierPtr::operator* const): Deleted.
+        (JSC::CagedBarrierPtr::operator-> const): Deleted.
+        (JSC::CagedBarrierPtr::operator[] const): Deleted.
+        (): 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::hasVector const):
+        (JSC::JSArrayBufferView::vector const):
+        * 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-05-08  Caio Lima  <ticaiolima@gmail.com>
+
+        [BigInt] Add ValueMod into DFG
+        https://bugs.webkit.org/show_bug.cgi?id=186174
+
+        Reviewed by Saam Barati.
+
+        This patch is introducing a new DFG node called ValueMod, that is
+        responsible to handle BigInt and Untyped specialization of op_mod.
+        With the introduction of BigInt, we think that cases with
+        ValueMod(Untyped, Untyped) can be more common and we introduced
+        support for such kind of node.
+
+        * dfg/DFGAbstractInterpreter.h:
+        * dfg/DFGAbstractInterpreterInlines.h:
+        (JSC::DFG::AbstractInterpreter<AbstractStateType>::handleConstantDivOp):
+
+        We are abstracting the constant rules of division operations. It
+        includes ArithDiv, ValueDiv, ArithMod and ValueMod, since they perform
+        the same analysis.
+
+        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+        * dfg/DFGBackwardsPropagationPhase.cpp:
+        (JSC::DFG::BackwardsPropagationPhase::propagate):
+        * dfg/DFGByteCodeParser.cpp:
+        (JSC::DFG::ByteCodeParser::makeSafe):
+        (JSC::DFG::ByteCodeParser::parseBlock):
+
+        Here we check if lhs and rhs have number result to emit ArithMod.
+        Otherwise, we need to fallback to ValueMod and let fixup replace this
+        operation when possible.
+
+        * dfg/DFGClobberize.h:
+        (JSC::DFG::clobberize):
+
+        ValueMod(BigIntUse) doesn't clobberize world because it only calls
+        `operationModBigInt`.
+
+        * dfg/DFGDoesGC.cpp:
+        (JSC::DFG::doesGC):
+
+        ValueMod(BigIntUse) can trigger GC since it allocates intermediate
+        JSBigInt to perform calculation. ValueMod(UntypedUse) can trigger GC
+        because it can execute arbritary code from user.
+
+        * dfg/DFGFixupPhase.cpp:
+        (JSC::DFG::FixupPhase::fixupArithDivInt32):
+
+        Function created to simplify readability of ArithDiv/AirthMod fixup
+        operation.
+
+        (JSC::DFG::FixupPhase::fixupArithDiv):
+        (JSC::DFG::FixupPhase::fixupNode):
+
+        Following the same fixup rules of ArithDiv.
+
+        * dfg/DFGNodeType.h:
+        * dfg/DFGOperations.cpp:
+        (JSC::DFG::binaryOp):
+        * dfg/DFGOperations.h:
+        * dfg/DFGPredictionPropagationPhase.cpp:
+
+        ValueMod follows the same prediction propagation rules of ArithMod and
+        the same rules for `doDoubleVoting`.
+
+        * dfg/DFGSafeToExecute.h:
+        (JSC::DFG::safeToExecute):
+        * dfg/DFGSpeculativeJIT.cpp:
+        (JSC::DFG::SpeculativeJIT::compileValueMod):
+        * dfg/DFGSpeculativeJIT.h:
+        * dfg/DFGSpeculativeJIT32_64.cpp:
+        (JSC::DFG::SpeculativeJIT::compile):
+        * dfg/DFGSpeculativeJIT64.cpp:
+        (JSC::DFG::SpeculativeJIT::compile):
+        * dfg/DFGValidate.cpp:
+        * ftl/FTLCapabilities.cpp:
+        (JSC::FTL::canCompile):
+        * ftl/FTLLowerDFGToB3.cpp:
+        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
+        (JSC::FTL::DFG::LowerDFGToB3::compileValueMod):
+
+2019-05-07  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] DFG_ASSERT failed in lowInt52
+        https://bugs.webkit.org/show_bug.cgi?id=197569
+
+        Reviewed by Saam Barati.
+
+        GetStack with FlushedInt52 should load the flushed value in Int52 form and put the result in m_int52Values / m_strictInt52Values. Previously,
+        we load it in JSValue / Int32 form and lowInt52 fails to get appropriate one since GetStack does not put the result in m_int52Values / m_strictInt52Values.
+
+        * ftl/FTLLowerDFGToB3.cpp:
+        (JSC::FTL::DFG::LowerDFGToB3::compileGetStack):
+
+2019-05-07  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] LLIntPrototypeLoadAdaptiveStructureWatchpoint does not require Bag<>
+        https://bugs.webkit.org/show_bug.cgi?id=197645
+
+        Reviewed by Saam Barati.
+
+        We are using HashMap<std::tuple<Structure*, const Instruction*>, Bag<LLIntPrototypeLoadAdaptiveStructureWatchpoint>> for LLIntPrototypeLoadAdaptiveStructureWatchpoint,
+        but this has several memory inefficiency.
+
+        1. Structure* and Instruction* are too large. We can just use StructureID and bytecodeOffset (unsigned).
+        2. While we are using Bag<>, we do not add a new LLIntPrototypeLoadAdaptiveStructureWatchpoint after constructing this Bag first. So we can
+           use Vector<LLIntPrototypeLoadAdaptiveStructureWatchpoint> instead. We ensure that new entry won't be added to this Vector by making Watchpoint
+           non-movable.
+        3. Instead of having OpGetById::Metadata&, we just hold `unsigned` bytecodeOffset, and get Metadata& from the owner CodeBlock when needed.
+
+        * bytecode/CodeBlock.cpp:
+        (JSC::CodeBlock::finalizeLLIntInlineCaches):
+        * bytecode/CodeBlock.h:
+        * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
+        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
+        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
+        * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
+        * bytecode/Watchpoint.h:
+        * llint/LLIntSlowPaths.cpp:
+        (JSC::LLInt::setupGetByIdPrototypeCache):
+
+2019-05-07  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        JSC: A bug in BytecodeGenerator::emitEqualityOpImpl
+        https://bugs.webkit.org/show_bug.cgi?id=197479
+
+        Reviewed by Saam Barati.
+
+        Our peephole optimization in BytecodeGenerator is (1) rewinding the previous instruction and (2) emit optimized instruction instead.
+        If we have jump target between the previous instruction and the subsequent instruction, this peephole optimization breaks the jump target.
+        To prevent it, we had a mechanism disabling peephole optimization, setting m_lastOpcodeID = op_end and checking m_lastOpcodeID when performing
+        peephole optimization. However, BytecodeGenerator::emitEqualityOpImpl checks `m_lastInstruction->is<OpTypeof>` instead of `m_lastOpcodeID == op_typeof`,
+        and miss `op_end` case.
+
+        This patch makes the following changes.
+
+        1. Add canDoPeepholeOptimization method to clarify the intent of `m_lastInstruction = op_end`.
+        2. Check canDoPeepholeOptimization status before performing peephole optimization in emitJumpIfTrue, emitJumpIfFalse, and emitEqualityOpImpl.
+        3. Add `ASSERT(canDoPeepholeOptimization())` in fuseCompareAndJump and fuseTestAndJmp to ensure that peephole optimization is allowed.
+
+        * bytecompiler/BytecodeGenerator.cpp:
+        (JSC::BytecodeGenerator::fuseCompareAndJump):
+        (JSC::BytecodeGenerator::fuseTestAndJmp):
+        (JSC::BytecodeGenerator::emitJumpIfTrue):
+        (JSC::BytecodeGenerator::emitJumpIfFalse):
+        (JSC::BytecodeGenerator::emitEqualityOpImpl):
+        * bytecompiler/BytecodeGenerator.h:
+        (JSC::BytecodeGenerator::canDoPeepholeOptimization const):
+
+2019-05-07  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        TemplateObject passed to template literal tags are not always identical for the same source location.
+        https://bugs.webkit.org/show_bug.cgi?id=190756
+
+        Reviewed by Saam Barati.
+
+        Tagged template literal requires that the site object is allocated per source location. Previously, we create the site object
+        when linking CodeBlock and cache it in CodeBlock. But this is wrong because,
+
+        1. CodeBlock can be jettisoned and regenerated. So every time CodeBlock is regenerated, we get the different site object.
+        2. Call and Construct can have different CodeBlock. Even if the function is called in call-form or construct-form, we should return the same site object.
+
+        In this patch, we start caching these site objects in the top-level ScriptExecutable, this matches the spec's per source location since the only one top-level
+        ScriptExecutable is created for the given script code. Each ScriptExecutable of JSFunction can be created multiple times because CodeBlock creates it.
+        But the top-level one is not created by CodeBlock. This top-level ScriptExecutable is well-aligned to the Script itself. The top-level ScriptExecutable now has HashMap,
+        which maps source locations to cached site objects.
+
+        1. This patch threads the top-level ScriptExecutable to each FunctionExecutable creation. Each FunctionExecutable has a reference to the top-level ScriptExecutable.
+        2. We put TemplateObjectMap in ScriptExecutable, which manages cached template objects.
+        3. We move FunctionExecutable::m_cachedPolyProtoStructure to the FunctionExecutable::RareDate to keep FunctionExecutable 128 bytes.
+        4. TemplateObjectMap is indexed with endOffset of TaggedTemplate.
+
+        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
+        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
+        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
+        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
+        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
+        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
+        * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
+        * Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.js-result:
+        * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
+        * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
+        * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
+        * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
+        * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
+        * Scripts/wkbuiltins/builtins_templates.py:
+        * bytecode/CodeBlock.cpp:
+        (JSC::CodeBlock::finishCreation):
+        (JSC::CodeBlock::setConstantRegisters):
+        * bytecode/CodeBlock.h:
+        * bytecode/UnlinkedFunctionExecutable.cpp:
+        (JSC::UnlinkedFunctionExecutable::link):
+        * bytecode/UnlinkedFunctionExecutable.h:
+        * bytecompiler/BytecodeGenerator.cpp:
+        (JSC::BytecodeGenerator::addTemplateObjectConstant):
+        (JSC::BytecodeGenerator::emitGetTemplateObject):
+        * bytecompiler/BytecodeGenerator.h:
+        * parser/ASTBuilder.h:
+        (JSC::ASTBuilder::createTaggedTemplate):
+        * runtime/CachedTypes.cpp:
+        (JSC::CachedTemplateObjectDescriptor::encode):
+        (JSC::CachedTemplateObjectDescriptor::decode const):
+        (JSC::CachedJSValue::encode):
+        (JSC::CachedJSValue::decode const):
+        * runtime/EvalExecutable.cpp:
+        (JSC::EvalExecutable::ensureTemplateObjectMap):
+        (JSC::EvalExecutable::visitChildren):
+        * runtime/EvalExecutable.h:
+        * runtime/FunctionExecutable.cpp:
+        (JSC::FunctionExecutable::finishCreation):
+        (JSC::FunctionExecutable::visitChildren):
+        (JSC::FunctionExecutable::fromGlobalCode):
+        (JSC::FunctionExecutable::ensureRareDataSlow):
+        (JSC::FunctionExecutable::ensureTemplateObjectMap):
+        * runtime/FunctionExecutable.h:
+        * runtime/JSModuleRecord.cpp:
+        (JSC::JSModuleRecord::instantiateDeclarations):
+        * runtime/JSTemplateObjectDescriptor.cpp:
+        (JSC::JSTemplateObjectDescriptor::JSTemplateObjectDescriptor):
+        (JSC::JSTemplateObjectDescriptor::create):
+        * runtime/JSTemplateObjectDescriptor.h:
+        * runtime/ModuleProgramExecutable.cpp:
+        (JSC::ModuleProgramExecutable::ensureTemplateObjectMap):
+        (JSC::ModuleProgramExecutable::visitChildren):
+        * runtime/ModuleProgramExecutable.h:
+        * runtime/ProgramExecutable.cpp:
+        (JSC::ProgramExecutable::ensureTemplateObjectMap):
+        (JSC::ProgramExecutable::visitChildren):
+        * runtime/ProgramExecutable.h:
+        * runtime/ScriptExecutable.cpp:
+        (JSC::ScriptExecutable::topLevelExecutable):
+        (JSC::ScriptExecutable::createTemplateObject):
+        (JSC::ScriptExecutable::ensureTemplateObjectMapImpl):
+        (JSC::ScriptExecutable::ensureTemplateObjectMap):
+        * runtime/ScriptExecutable.h:
+        * tools/JSDollarVM.cpp:
+        (JSC::functionCreateBuiltin):
+        (JSC::functionDeleteAllCodeWhenIdle):
+        (JSC::JSDollarVM::finishCreation):
+
+2019-05-07  Robin Morisset  <rmorisset@apple.com>
+
+        [B3] Constants should be hoisted to the root block until moveConstants
+        https://bugs.webkit.org/show_bug.cgi?id=197265
+
+        Reviewed by Saam Barati.
+
+        This patch does the following:
+        - B3ReduceStrength now hoists all constants to the root BB, and de-duplicates them along the way
+        - B3PureCSE no longer bothers with constants, since they are already de-duplicated by the time it gets to see them
+        - We now run eliminateDeadCode just after moveConstants, so that the Nops that moveConstants generates are freed instead of staying live throughout Air compilation, reducing memory pressure.
+        - I also took the opportunity to fix typos in comments in various parts of the code base.
+
+        Here are a few numbers to justify this patch:
+        - In JetStream2, about 27% of values at the beginning of B3 are constants
+        - In JetStream2, about 11% of values at the end of B3 are Nops
+        - In JetStream2, this patch increases the number of times that tail duplication happens from a bit less than 24k to a bit more than 25k (hoisting constants makes blocks smaller).
+
+        When I tried measuring the total effect on JetStream2 I got a tiny and almost certainly non-significant progression.
+
+        * b3/B3Generate.cpp:
+        (JSC::B3::generateToAir):
+        * b3/B3MoveConstants.cpp:
+        * b3/B3PureCSE.cpp:
+        (JSC::B3::PureCSE::process):
+        * b3/B3PureCSE.h:
+        * b3/B3ReduceStrength.cpp:
+        * bytecode/GetByIdStatus.cpp:
+        (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
+        * dfg/DFGCSEPhase.cpp:
+        * dfg/DFGOSRAvailabilityAnalysisPhase.h:
+        * dfg/DFGOSRExit.cpp:
+        (JSC::DFG::OSRExit::executeOSRExit):
+
+2019-05-07  Robin Morisset  <rmorisset@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/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-05-07  Robin Morisset  <rmorisset@apple.com>
+
+        WTF::BitVector should have an isEmpty() method
+        https://bugs.webkit.org/show_bug.cgi?id=197637
+
+        Reviewed by Keith Miller.
+
+        Just replaces some comparison of bitCount() to 0 by calls to isEmpty()
+
+        * b3/air/AirAllocateRegistersByGraphColoring.cpp:
+
+2019-05-07  Commit Queue  <commit-queue@webkit.org>
+
+        Unreviewed, rolling out r244978.
+        https://bugs.webkit.org/show_bug.cgi?id=197671
+
+        TemplateObject map should use start/end offsets (Requested by
+        yusukesuzuki on #webkit).
+
+        Reverted changeset:
+
+        "TemplateObject passed to template literal tags are not always
+        identical for the same source location."
+        https://bugs.webkit.org/show_bug.cgi?id=190756
+        https://trac.webkit.org/changeset/244978
+
+2019-05-07  Tadeu Zagallo  <tzagallo@apple.com>
+
+        tryCachePutByID should not crash if target offset changes
+        https://bugs.webkit.org/show_bug.cgi?id=197311
+        <rdar://problem/48033612>
+
+        Reviewed by Filip Pizlo.
+
+        When tryCachePutID is called with a cacheable setter, if the target object where the setter was
+        found is still in the prototype chain and there's no poly protos in the chain, we use
+        generateConditionsForPrototypePropertyHit to validate that the target object remains the same.
+        It checks for the absence of the property in every object in the prototype chain from the base
+        down to the target object and checks that the property is still present in the target object. It
+        also bails if there are any uncacheable objects, proxies or dictionary objects in the prototype
+        chain. However, it does not consider two edge cases:
+        - It asserts that the property should still be at the same offset in the target object, but this
+        assertion does not hold if the setter deletes properties of the object and causes the structure
+        to be flattened after the deletion. Instead of asserting, we just use the updated offset.
+        - It does not check whether the new slot is also a setter, which leads to a crash in case it's not.
+
+        * jit/Repatch.cpp:
+        (JSC::tryCachePutByID):
+
+2019-05-07  Saam Barati  <sbarati@apple.com>
+
+        Don't OSR enter into an FTL CodeBlock that has been jettisoned
+        https://bugs.webkit.org/show_bug.cgi?id=197531
+        <rdar://problem/50162379>
+
+        Reviewed by Yusuke Suzuki.
+
+        Sometimes we make silly mistakes. This is one of those times. It's invalid to OSR
+        enter into an FTL OSR entry code block that has been jettisoned already.
+
+        * dfg/DFGJITCode.cpp:
+        (JSC::DFG::JITCode::clearOSREntryBlockAndResetThresholds):
+        * dfg/DFGJITCode.h:
+        (JSC::DFG::JITCode::clearOSREntryBlock): Deleted.
+        * dfg/DFGOSREntry.cpp:
+        (JSC::DFG::prepareOSREntry):
+        (JSC::DFG::prepareCatchOSREntry):
+        * dfg/DFGOperations.cpp:
+        * ftl/FTLOSREntry.cpp:
+        (JSC::FTL::prepareOSREntry):
+
+2019-05-06  Keith Miller  <keith_miller@apple.com>
+
+        JSWrapperMap should check if existing prototype properties are wrappers when copying exported methods.
+        https://bugs.webkit.org/show_bug.cgi?id=197324
+        <rdar://problem/50253144>
+
+        Reviewed by Saam Barati.
+
+        The current implementation prevents using JSExport to shadow a
+        method from a super class. This was because we would only add a
+        method if the prototype didn't already claim to have the
+        property. Normally this would only happen if an Objective-C super
+        class already exported a ObjCCallbackFunction for the method,
+        however, if the user exports a property that is already on
+        Object.prototype the overriden method won't be exported.
+
+        This patch fixes the object prototype issue by checking if the
+        property on the prototype chain is an ObjCCallbackFunction, if
+        it's not then it adds an override.
+
+        * API/JSWrapperMap.mm:
+        (copyMethodsToObject):
+        * API/tests/testapi.mm:
+        (-[ToStringClass toString]):
+        (-[ToStringClass other]):
+        (-[ToStringSubclass toString]):
+        (-[ToStringSubclassNoProtocol toString]):
+        (testToString):
+        (testObjectiveCAPI):
+
+2019-05-06  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] We should check OOM for description string of Symbol
+        https://bugs.webkit.org/show_bug.cgi?id=197634
+
+        Reviewed by Keith Miller.
+
+        When resoling JSString for description of Symbol, we should check OOM error.
+        We also change JSValueMakeSymbol(..., nullptr) to returning a symbol value
+        without description, (1) to simplify the code and (2) give a way for JSC API
+        to create a symbol value without description.
+
+        * API/JSValueRef.cpp:
+        (JSValueMakeSymbol):
+        * API/tests/testapi.cpp:
+        (TestAPI::symbolsTypeof):
+        (TestAPI::symbolsDescription):
+        (testCAPIViaCpp):
+        * dfg/DFGOperations.cpp:
+        * runtime/Symbol.cpp:
+        (JSC::Symbol::createWithDescription):
+        * runtime/Symbol.h:
+        * runtime/SymbolConstructor.cpp:
+        (JSC::callSymbol):
+
+2019-05-06  Keith Rollin  <krollin@apple.com>
+
+        Temporarily disable generate-xcfilelists
+        https://bugs.webkit.org/show_bug.cgi?id=197619
+        <rdar://problem/50507392>
+
+        Reviewed by Alex Christensen.
+
+        We need to perform a significant update to the generate-xcfilelist
+        scripts. This work involves coordinated work with another facility. If
+        the work does not occur in tandem, the build will be broken. To avoid
+        this, disable the invoking of the scripts during the transition. The
+        checking will be restored once the new scripts are in place.
+
+        * Scripts/check-xcfilelists.sh:
+
+2019-05-06  Basuke Suzuki  <Basuke.Suzuki@sony.com>
+
+        [PlayStation] Fix build break since r244919
+        https://bugs.webkit.org/show_bug.cgi?id=197627
+
+        Reviewed by Ross Kirsling.
+
+        Bugfix for POSIX socket implementation and suppress warnings.
+
+        * inspector/remote/socket/RemoteInspectorConnectionClient.h:
+        (Inspector::RemoteInspectorConnectionClient::didAccept):
+        * inspector/remote/socket/posix/RemoteInspectorSocketPOSIX.cpp:
+        (Inspector::Socket::getPort):
+
+2019-05-06  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        TemplateObject passed to template literal tags are not always identical for the same source location.
+        https://bugs.webkit.org/show_bug.cgi?id=190756
+
+        Reviewed by Saam Barati.
+
+        Tagged template literal requires that the site object is allocated per source location. Previously, we create the site object
+        when linking CodeBlock and cache it in CodeBlock. But this is wrong because,
+
+        1. CodeBlock can be jettisoned and regenerated. So every time CodeBlock is regenerated, we get the different site object.
+        2. Call and Construct can have different CodeBlock. Even if the function is called in call-form or construct-form, we should return the same site object.
+
+        In this patch, we start caching these site objects in the top-level ScriptExecutable, this matches the spec's per source location since the only one top-level
+        ScriptExecutable is created for the given script code. Each ScriptExecutable of JSFunction can be created multiple times because CodeBlock creates it.
+        But the top-level one is not created by CodeBlock. This top-level ScriptExecutable is well-aligned to the Script itself. The top-level ScriptExecutable now has HashMap,
+        which maps source locations to cached site objects.
+
+        1. This patch threads the top-level ScriptExecutable to each FunctionExecutable creation. Each FunctionExecutable has a reference to the top-level ScriptExecutable.
+        2. We put TemplateObjectMap in ScriptExecutable, which manages cached template objects.
+        3. We move FunctionExecutable::m_cachedPolyProtoStructure to the FunctionExecutable::RareDate to keep FunctionExecutable 128 bytes.
+
+        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
+        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
+        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
+        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
+        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
+        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
+        * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
+        * Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.js-result:
+        * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
+        * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
+        * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
+        * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
+        * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
+        * Scripts/wkbuiltins/builtins_templates.py:
+        * bytecode/CodeBlock.cpp:
+        (JSC::CodeBlock::finishCreation):
+        (JSC::CodeBlock::setConstantRegisters):
+        * bytecode/CodeBlock.h:
+        * bytecode/UnlinkedFunctionExecutable.cpp:
+        (JSC::UnlinkedFunctionExecutable::link):
+        * bytecode/UnlinkedFunctionExecutable.h:
+        * bytecompiler/BytecodeGenerator.cpp:
+        (JSC::BytecodeGenerator::addTemplateObjectConstant):
+        (JSC::BytecodeGenerator::emitGetTemplateObject):
+        * bytecompiler/BytecodeGenerator.h:
+        * runtime/CachedTypes.cpp:
+        (JSC::CachedTemplateObjectDescriptor::encode):
+        (JSC::CachedTemplateObjectDescriptor::decode const):
+        (JSC::CachedJSValue::encode):
+        (JSC::CachedJSValue::decode const):
+        * runtime/EvalExecutable.cpp:
+        (JSC::EvalExecutable::ensureTemplateObjectMap):
+        (JSC::EvalExecutable::visitChildren):
+        * runtime/EvalExecutable.h:
+        * runtime/FunctionExecutable.cpp:
+        (JSC::FunctionExecutable::finishCreation):
+        (JSC::FunctionExecutable::visitChildren):
+        (JSC::FunctionExecutable::fromGlobalCode):
+        (JSC::FunctionExecutable::ensureRareDataSlow):
+        (JSC::FunctionExecutable::ensureTemplateObjectMap):
+        * runtime/FunctionExecutable.h:
+        * runtime/JSModuleRecord.cpp:
+        (JSC::JSModuleRecord::instantiateDeclarations):
+        * runtime/JSTemplateObjectDescriptor.cpp:
+        (JSC::JSTemplateObjectDescriptor::JSTemplateObjectDescriptor):
+        (JSC::JSTemplateObjectDescriptor::create):
+        * runtime/JSTemplateObjectDescriptor.h:
+        * runtime/ModuleProgramExecutable.cpp:
+        (JSC::ModuleProgramExecutable::ensureTemplateObjectMap):
+        (JSC::ModuleProgramExecutable::visitChildren):
+        * runtime/ModuleProgramExecutable.h:
+        * runtime/ProgramExecutable.cpp:
+        (JSC::ProgramExecutable::ensureTemplateObjectMap):
+        (JSC::ProgramExecutable::visitChildren):
+        * runtime/ProgramExecutable.h:
+        * runtime/ScriptExecutable.cpp:
+        (JSC::ScriptExecutable::topLevelExecutable):
+        (JSC::ScriptExecutable::createTemplateObject):
+        (JSC::ScriptExecutable::ensureTemplateObjectMap):
+        * runtime/ScriptExecutable.h:
+        * tools/JSDollarVM.cpp:
+        (JSC::functionCreateBuiltin):
+        (JSC::functionDeleteAllCodeWhenIdle):
+        (JSC::JSDollarVM::finishCreation):
+
+2019-05-04  Tadeu Zagallo  <tzagallo@apple.com>
+
+        TypedArrays should not store properties that are canonical numeric indices
+        https://bugs.webkit.org/show_bug.cgi?id=197228
+        <rdar://problem/49557381>
+
+        Reviewed by Saam Barati.
+
+        According to the spec[1]:
+        - TypedArrays should not perform an ordinary GetOwnProperty/SetOwnProperty if the index is a
+        CanonicalNumericIndexString, but invalid according to IntegerIndexedElementGet and similar
+        functions. I.e., there are a few properties that should not be set in a TypedArray, like NaN,
+        Infinity and -0.
+        - On DefineOwnProperty, the out-of-bounds check should be performed before validating the property
+        descriptor.
+        - On GetOwnProperty, the returned descriptor for numeric properties should have writable set to true.
+
+        [1]: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-integer-indexed-exotic-objects-defineownproperty-p-desc
+
+        * CMakeLists.txt:
+        * JavaScriptCore.xcodeproj/project.pbxproj:
+        * runtime/JSGenericTypedArrayViewInlines.h:
+        (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
+        (JSC::JSGenericTypedArrayView<Adaptor>::put):
+        (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
+        (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlotByIndex):
+        (JSC::JSGenericTypedArrayView<Adaptor>::putByIndex):
+        * runtime/PropertyName.h:
+        (JSC::isCanonicalNumericIndexString):
+
+2019-05-03  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Need to emit SetLocal if we emit MovHint in DFGByteCodeParser
+        https://bugs.webkit.org/show_bug.cgi?id=197584
+
+        Reviewed by Saam Barati.
+
+        In r244864, we emit MovHint for adhocly created GetterCall/SetterCall frame locals in the callee side to make OSR availability analysis's pruning correct.
+        However, we just emit MovHint, and we do not emit SetLocal since we ensured that these locals are already flushed in the same place before. However, MovHint
+        and SetLocal are needed to be a pair in DFGByteCodeParser because we rely on this assumption in SSA conversion phase. SSA conversion phase always emit KillStack
+        just before MovHint's target location even if the MovHint's target is the same to the previously emitted MovHint and SetLocal.
+        This patch emits SetLocal too when emitting MovHint for GetterCall/SetterCall frame locals.
+
+        The example is like this.
+
+            a:  SomeValueNode
+             :  MovHint(@a, loc10)
+            b:  SetLocal(@a, loc10)
+                ...
+            c:  MovHint(@a, loc10)
+
+        Then, this will be converted to the style in SSA conversion.
+
+            a:  SomeValueNode
+             :  KillStack(loc10)
+            b:  PutStack(@a, loc10)
+                ...
+            c:  KillStack(loc10)
+
+        Then, @b will be removed later since @c kills it.
+
+        * dfg/DFGByteCodeParser.cpp:
+        (JSC::DFG::ByteCodeParser::inlineCall):
+        * heap/MarkedBlock.cpp:
+        (JSC::MarkedBlock::MarkedBlock):
+        (JSC::MarkedBlock::Handle::stopAllocating):
+        (JSC::MarkedBlock::Handle::resumeAllocating):
+        (JSC::MarkedBlock::aboutToMarkSlow):
+        (JSC::MarkedBlock::Handle::didConsumeFreeList):
+
+2019-05-03  Devin Rousso  <drousso@apple.com>
+
+        Web Inspector: DOM: rename "low power" to "display composited"
+        https://bugs.webkit.org/show_bug.cgi?id=197296
+
+        Reviewed by Joseph Pecoraro.
+
+        Removed specific ChangeLog entries since it is almost entirely mechanical changes.
+
+        * inspector/protocol/DOM.json:
+
+2019-05-03  Basuke Suzuki  <Basuke.Suzuki@sony.com>
+
+        [WinCairo] Implement and enable RemoteInspector Server.
+        https://bugs.webkit.org/show_bug.cgi?id=197432
+
+        Reviewed by Ross Kirsling.
+
+        Implement Windows implementation for Socket Backend of RemoteInspector and enable it on WinCairo
+        for experimental feature.
+
+        Also add listener interface for connection between RemoteInspector and RemoteInspectorServer
+        for flexible configuration.
+
+        * PlatformWin.cmake:
+        * inspector/remote/RemoteInspector.h:
+        * inspector/remote/socket/RemoteInspectorConnectionClient.h:
+        (Inspector::RemoteInspectorConnectionClient::didAccept):
+        * inspector/remote/socket/RemoteInspectorServer.cpp:
+        (Inspector::RemoteInspectorServer::connect):
+        (Inspector::RemoteInspectorServer::listenForTargets):
+        (Inspector::RemoteInspectorServer::didAccept):
+        (Inspector::RemoteInspectorServer::dispatchMap):
+        (Inspector::RemoteInspectorServer::start):
+        (Inspector::RemoteInspectorServer::addServerConnection): Deleted.
+        * inspector/remote/socket/RemoteInspectorServer.h:
+        (Inspector::RemoteInspectorServer::RemoteInspectorServer):
+        * inspector/remote/socket/RemoteInspectorSocket.cpp:
+        (Inspector::RemoteInspector::RemoteInspector):
+        (Inspector::RemoteInspector::dispatchMap):
+        (Inspector::RemoteInspector::start):
+        (Inspector::RemoteInspector::stopInternal):
+        (Inspector::RemoteInspector::setServerPort):
+        * inspector/remote/socket/RemoteInspectorSocket.h:
+        * inspector/remote/socket/RemoteInspectorSocketEndpoint.cpp:
+        (Inspector::RemoteInspectorSocketEndpoint::listenInet):
+        (Inspector::RemoteInspectorSocketEndpoint::getPort const):
+        (Inspector::RemoteInspectorSocketEndpoint::acceptInetSocketIfEnabled):
+        * inspector/remote/socket/RemoteInspectorSocketEndpoint.h:
+        * inspector/remote/socket/posix/RemoteInspectorSocketPOSIX.cpp:
+        (Inspector::Socket::init): Added.
+        (Inspector::Socket::listen): Signature changed.
+        (Inspector::Socket::getPort): Added.
+        * inspector/remote/socket/win/RemoteInspectorSocketWin.cpp: Added.
+        (Inspector::Socket::init):
+        (Inspector::Socket::Socket::Socket):
+        (Inspector::Socket::Socket::~Socket):
+        (Inspector::Socket::Socket::close):
+        (Inspector::Socket::Socket::operator PlatformSocketType const):
+        (Inspector::Socket::Socket::operator bool const):
+        (Inspector::Socket::Socket::leak):
+        (Inspector::Socket::Socket::create):
+        (Inspector::Socket::setOpt):
+        (Inspector::Socket::setOptEnabled):
+        (Inspector::Socket::enableOpt):
+        (Inspector::Socket::connectTo):
+        (Inspector::Socket::bindAndListen):
+        (Inspector::Socket::connect):
+        (Inspector::Socket::listen):
+        (Inspector::Socket::accept):
+        (Inspector::Socket::createPair):
+        (Inspector::Socket::setup):
+        (Inspector::Socket::isValid):
+        (Inspector::Socket::isListening):
+        (Inspector::Socket::getPort):
+        (Inspector::Socket::read):
+        (Inspector::Socket::write):
+        (Inspector::Socket::close):
+        (Inspector::Socket::preparePolling):
+        (Inspector::Socket::poll):
+        (Inspector::Socket::isReadable):
+        (Inspector::Socket::isWritable):
+        (Inspector::Socket::markWaitingWritable):
+        (Inspector::Socket::clearWaitingWritable):
+
+2019-05-03  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Generator CodeBlock generation should be idempotent
+        https://bugs.webkit.org/show_bug.cgi?id=197552
+
+        Reviewed by Keith Miller.
+
+        ES6 Generator saves and resumes the current execution state. Since ES6 generator can save the execution state at expression
+        granularity (not statement granularity), the saved state involves locals. But if the underlying CodeBlock is jettisoned and
+        recompiled with different code generation option (like, debugger, type profiler etc.), the generated instructions can be largely
+        different and it does not have the same state previously used. If we resume the previously created generator with the newly
+        generator function, resuming is messed up.
+
+            function* gen () { ... }
+            var g = gen();
+            g.next();
+
+            // CodeBlock is destroyed & Debugger is enabled.
+
+            g.next();
+
+        In this patch,
+
+        1. In generatorification, we use index Identifier (localN => Identifier("N")) instead of private symbols to generate the same
+           instructions every time we regenerate the CodeBlock.
+
+        2. We decouple the options which can affect on the generated code (Debugger, TypeProfiler, ControlFlowProfiler) from the BytecodeGenerator,
+           and pass them as a parameter, OptionSet<CodeGeneratorMode>.
+
+        3. Generator ScriptExecutable remembers the previous CodeGeneratorMode and reuses this parameter to regenerate CodeBlock. It means that,
+           even if the debugger is enabled, previously created generators are not debuggable. But newly created generators are debuggable.
+
+        * bytecode/BytecodeGeneratorification.cpp:
+        (JSC::BytecodeGeneratorification::storageForGeneratorLocal):
+        (JSC::BytecodeGeneratorification::run):
+        * bytecode/CodeBlock.cpp:
+        (JSC::CodeBlock::finishCreation):
+        (JSC::CodeBlock::setConstantRegisters):
+        * bytecode/UnlinkedCodeBlock.cpp:
+        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
+        * bytecode/UnlinkedCodeBlock.h:
+        (JSC::UnlinkedCodeBlock::wasCompiledWithDebuggingOpcodes const):
+        (JSC::UnlinkedCodeBlock::wasCompiledWithTypeProfilerOpcodes const):
+        (JSC::UnlinkedCodeBlock::wasCompiledWithControlFlowProfilerOpcodes const):
+        (JSC::UnlinkedCodeBlock::codeGenerationMode const):
+        * bytecode/UnlinkedEvalCodeBlock.h:
+        * bytecode/UnlinkedFunctionCodeBlock.h:
+        * bytecode/UnlinkedFunctionExecutable.cpp:
+        (JSC::generateUnlinkedFunctionCodeBlock):
+        (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
+        (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
+        * bytecode/UnlinkedFunctionExecutable.h:
+        * bytecode/UnlinkedGlobalCodeBlock.h:
+        (JSC::UnlinkedGlobalCodeBlock::UnlinkedGlobalCodeBlock):
+        * bytecode/UnlinkedModuleProgramCodeBlock.h:
+        * bytecode/UnlinkedProgramCodeBlock.h:
+        * bytecompiler/BytecodeGenerator.cpp:
+        (JSC::BytecodeGenerator::BytecodeGenerator):
+        (JSC::BytecodeGenerator::emitTypeProfilerExpressionInfo):
+        (JSC::BytecodeGenerator::emitProfileType):
+        (JSC::BytecodeGenerator::emitProfileControlFlow):
+        (JSC::BytecodeGenerator::pushLexicalScopeInternal):
+        (JSC::BytecodeGenerator::popLexicalScopeInternal):
+        (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
+        (JSC::BytecodeGenerator::emitCall):
+        (JSC::BytecodeGenerator::emitCallVarargs):
+        (JSC::BytecodeGenerator::emitLogShadowChickenPrologueIfNecessary):
+        (JSC::BytecodeGenerator::emitLogShadowChickenTailIfNecessary):
+        (JSC::BytecodeGenerator::emitDebugHook):
+        * bytecompiler/BytecodeGenerator.h:
+        (JSC::BytecodeGenerator::generate):
+        (JSC::BytecodeGenerator::shouldEmitDebugHooks const):
+        (JSC::BytecodeGenerator::shouldEmitTypeProfilerHooks const):
+        (JSC::BytecodeGenerator::shouldEmitControlFlowProfilerHooks const):
+        * bytecompiler/NodesCodegen.cpp:
+        (JSC::PrefixNode::emitResolve):
+        (JSC::EmptyVarExpression::emitBytecode):
+        (JSC::ReturnNode::emitBytecode):
+        (JSC::FunctionNode::emitBytecode):
+        * parser/ParserModes.h:
+        (): Deleted.
+        * parser/SourceCodeKey.h:
+        (JSC::SourceCodeFlags::SourceCodeFlags):
+        (JSC::SourceCodeKey::SourceCodeKey):
+        * runtime/CachedTypes.cpp:
+        (JSC::CachedCodeBlock::isClassContext const):
+        (JSC::CachedCodeBlock::codeGenerationMode const):
+        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
+        (JSC::CachedCodeBlock<CodeBlockType>::encode):
+        (JSC::CachedCodeBlock::wasCompiledWithDebuggingOpcodes const): Deleted.
+        * runtime/CodeCache.cpp:
+        (JSC::CodeCache::getUnlinkedGlobalCodeBlock):
+        (JSC::CodeCache::getUnlinkedProgramCodeBlock):
+        (JSC::CodeCache::getUnlinkedEvalCodeBlock):
+        (JSC::CodeCache::getUnlinkedModuleProgramCodeBlock):
+        (JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
+        (JSC::generateUnlinkedCodeBlockForFunctions):
+        (JSC::sourceCodeKeyForSerializedBytecode):
+        (JSC::sourceCodeKeyForSerializedProgram):
+        (JSC::sourceCodeKeyForSerializedModule):
+        (JSC::serializeBytecode):
+        * runtime/CodeCache.h:
+        (JSC::generateUnlinkedCodeBlockImpl):
+        (JSC::generateUnlinkedCodeBlock):
+        * runtime/Completion.cpp:
+        (JSC::generateProgramBytecode):
+        (JSC::generateModuleBytecode):
+        * runtime/DirectEvalExecutable.cpp:
+        (JSC::DirectEvalExecutable::create):
+        * runtime/IndirectEvalExecutable.cpp:
+        (JSC::IndirectEvalExecutable::create):
+        * runtime/JSGlobalObject.h:
+        (JSC::JSGlobalObject::defaultCodeGenerationMode const):
+        * runtime/ModuleProgramExecutable.cpp:
+        (JSC::ModuleProgramExecutable::create):
+        * runtime/ProgramExecutable.cpp:
+        (JSC::ProgramExecutable::initializeGlobalProperties):
+        * runtime/ScriptExecutable.cpp:
+        (JSC::ScriptExecutable::ScriptExecutable):
+        (JSC::ScriptExecutable::newCodeBlockFor):
+        * runtime/ScriptExecutable.h:
+        * tools/JSDollarVM.cpp:
+        (JSC::changeDebuggerModeWhenIdle):
+        (JSC::functionEnableDebuggerModeWhenIdle):
+        (JSC::functionDisableDebuggerModeWhenIdle):
+
+2019-05-03  Devin Rousso  <drousso@apple.com>
+
+        Web Inspector: Record actions performed on WebGL2RenderingContext
+        https://bugs.webkit.org/show_bug.cgi?id=176008
+        <rdar://problem/34213884>
+
+        Reviewed by Joseph Pecoraro.
+
+        * inspector/protocol/Recording.json:
+        * inspector/scripts/codegen/generator.py:
+        Add `canvas-webgl2` as a `Type`.
+
+2019-05-03  Commit Queue  <commit-queue@webkit.org>
+
+        Unreviewed, rolling out r244881.
+        https://bugs.webkit.org/show_bug.cgi?id=197559
+
+        Breaks compilation of jsconly on linux, breaking compilation
+        for jsc-i386-ews, jsc-mips-ews and jsc-armv7-ews (Requested by
+        guijemont on #webkit).
+
+        Reverted changeset:
+
+        "[CMake] Refactor WEBKIT_MAKE_FORWARDING_HEADERS into
+        WEBKIT_COPY_FILES"
+        https://bugs.webkit.org/show_bug.cgi?id=197174
+        https://trac.webkit.org/changeset/244881
+
+2019-05-02  Don Olmstead  <don.olmstead@sony.com>
+
+        [CMake] Refactor WEBKIT_MAKE_FORWARDING_HEADERS into WEBKIT_COPY_FILES
+        https://bugs.webkit.org/show_bug.cgi?id=197174
+
+        Reviewed by Alex Christensen.
+
+        Replace WEBKIT_MAKE_FORWARDING_HEADERS with WEBKIT_COPY_FILES and make dependencies
+        for framework headers explicit.
+
+        * CMakeLists.txt:
+
+2019-05-02  Michael Saboff  <msaboff@apple.com>
+
+        Unreviewed rollout of r244862.
+
+        * runtime/JSObject.cpp:
+        (JSC::JSObject::getOwnPropertyDescriptor):
+
+2019-05-01  Saam barati  <sbarati@apple.com>
+
+        Baseline JIT should do argument value profiling after checking for stack overflow
+        https://bugs.webkit.org/show_bug.cgi?id=197052
+        <rdar://problem/50009602>
+
+        Reviewed by Yusuke Suzuki.
+
+        Otherwise, we may do value profiling without running a write barrier, which
+        is against the rules of how we do value profiling.
+
+        * jit/JIT.cpp:
+        (JSC::JIT::compileWithoutLinking):
+
+2019-05-01  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Inlining Getter/Setter should care availability of ad-hocly constructed frame
+        https://bugs.webkit.org/show_bug.cgi?id=197405
+
+        Reviewed by Saam Barati.
+
+        When inlining getter and setter calls, we setup a stack frame which does not appear in the bytecode.
+        Because Inlining can switch on executable, we could have a graph like this.
+
+        BB#0
+            ...
+            30: GetSetter
+            31: MovHint(loc10)
+            32: SetLocal(loc10)
+            33: MovHint(loc9)
+            34: SetLocal(loc9)
+            ...
+            37: GetExecutable(@30)
+            ...
+            41: Switch(@37)
+
+        BB#2
+            42: GetLocal(loc12, bc#7 of caller)
+            ...
+            --> callee: loc9 and loc10 are arguments of callee.
+              ...
+              <HERE, exit to callee, loc9 and loc10 are required in the bytecode>
+
+        When we prune OSR availability at the beginning of BB#2 (bc#7 in the caller), we prune loc9 and loc10's liveness because the caller does not actually have loc9 and loc10.
+        However, when we begin executing the callee, we need OSR exit to be aware of where it can recover the arguments to the setter, loc9 and loc10.
+
+        This patch inserts MovHint at the beginning of callee for a getter / setter stack frame to make arguments (loc9 and loc10 in the above example) recoverable from OSR exit.
+        We also move arity fixup DFG nodes from the caller to the callee, since moved arguments are not live in the caller too.
+
+        Interestingly, this fix also reveals the existing issue in LiveCatchVariablePreservationPhase. We emitted Flush for |this| of InlineCallFrame blindly if we saw InlineCallFrame
+        inside a block which is covered by catch handler. But this is wrong because inlined function can finish its execution within the block, and |this| is completely unrelated to
+        the catch handler if the catch handler is in the outer callee. We already collect all the live locals at the catch handler. And this locals must include arguments too if the
+        catch handler is in inlined function. So, we should not emit Flush for each |this| of seen InlineCallFrame. This emitted Flush may connect unrelated locals in the catch handler
+        to the locals that is only defined and used in the inlined function, and it leads to the results like DFG says the local is live while the bytecode says the local is dead.
+        This results in reading and using garbage in OSR entry because DFG OSR entry needs to fill live DFG values from the stack.
+
+        * dfg/DFGByteCodeParser.cpp:
+        (JSC::DFG::ByteCodeParser::inlineCall):
+        (JSC::DFG::ByteCodeParser::handleGetById):
+        (JSC::DFG::ByteCodeParser::handlePutById):
+        * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
+        (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch):
+
+2019-05-01  Michael Saboff  <msaboff@apple.com>
+
+        ASSERTION FAILED: !m_needExceptionCheck with --validateExceptionChecks=1; ProxyObject.getOwnPropertySlotCommon/JSFunction.callerGetter
+        https://bugs.webkit.org/show_bug.cgi?id=197485
+
+        Reviewed by Saam Barati.
+
+        Added an EXCEPTION_ASSERT after call to getOwnPropertySlot().
+
+        * runtime/JSObject.cpp:
+        (JSC::JSObject::getOwnPropertyDescriptor):
+
+2019-05-01  Ross Kirsling  <ross.kirsling@sony.com>
+
+        RemoteInspector::updateAutomaticInspectionCandidate should have a default implementation.
+        https://bugs.webkit.org/show_bug.cgi?id=197439
+
+        Reviewed by Devin Rousso.
+
+        On non-Cocoa platforms, automatic inspection is not currently implemented,
+        so updateAutomaticInspectionCandidate falls back to the logic of updateTarget.
+        This logic already existed in three places, so refactor it into a common private method
+        and allow our websocket-based RWI implementation to make use of it too.
+
+        * inspector/remote/RemoteInspector.cpp:
+        (Inspector::RemoteInspector::updateTarget):
+        (Inspector::RemoteInspector::updateTargetMap):
+        (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
+        * inspector/remote/RemoteInspector.h:
+        * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
+        (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
+        * inspector/remote/glib/RemoteInspectorGlib.cpp:
+        (Inspector::RemoteInspector::updateAutomaticInspectionCandidate): Deleted.
+        * inspector/remote/socket/RemoteInspectorSocket.cpp:
+        (Inspector::RemoteInspector::updateAutomaticInspectionCandidate): Deleted.
+
+2019-05-01  Darin Adler  <darin@apple.com>
+
+        WebKit has too much of its own UTF-8 code and should rely more on ICU's UTF-8 support
+        https://bugs.webkit.org/show_bug.cgi?id=195535
+
+        Reviewed by Alexey Proskuryakov.
+
+        * API/JSClassRef.cpp: Removed uneeded include of UTF8Conversion.h.
+
+        * API/JSStringRef.cpp:
+        (JSStringCreateWithUTF8CString): Updated for changes to convertUTF8ToUTF16.
+        (JSStringGetUTF8CString): Updated for changes to convertLatin1ToUTF8.
+        Removed unneeded "true" to get the strict version of convertUTF16ToUTF8,
+        since that is the default. Also updated for changes to CompletionResult.
+
+        * runtime/JSGlobalObjectFunctions.cpp:
+        (JSC::decode): Stop using UTF8SequenceLength, and instead use U8_COUNT_TRAIL_BYTES
+        and U8_MAX_LENGTH. Instead of decodeUTF8Sequence, use U8_NEXT. Also use U_IS_BMP,
+        U_IS_SUPPLEMENTARY, U16_LEAD, U16_TRAIL, and U_IS_SURROGATE instead of our own
+        equivalents, since these macros from ICU are correct and efficient.
+
+        * wasm/WasmParser.h:
+        (JSC::Wasm::Parser<SuccessType>::consumeUTF8String): Updated for changes to
+        convertUTF8ToUTF16.
+
+2019-05-01  Shawn Roberts  <sroberts@apple.com>
+
+        Unreviewed, rolling out r244821.
+
+        Causing
+
+        Reverted changeset:
+
+        "WebKit has too much of its own UTF-8 code and should rely
+        more on ICU's UTF-8 support"
+        https://bugs.webkit.org/show_bug.cgi?id=195535
+        https://trac.webkit.org/changeset/244821
+
+2019-04-29  Darin Adler  <darin@apple.com>
+
+        WebKit has too much of its own UTF-8 code and should rely more on ICU's UTF-8 support
+        https://bugs.webkit.org/show_bug.cgi?id=195535
+
+        Reviewed by Alexey Proskuryakov.
+
+        * API/JSClassRef.cpp: Removed uneeded include of UTF8Conversion.h.
+
+        * API/JSStringRef.cpp:
+        (JSStringCreateWithUTF8CString): Updated for changes to convertUTF8ToUTF16.
+        (JSStringGetUTF8CString): Updated for changes to convertLatin1ToUTF8.
+        Removed unneeded "true" to get the strict version of convertUTF16ToUTF8,
+        since that is the default. Also updated for changes to CompletionResult.
+
+        * runtime/JSGlobalObjectFunctions.cpp:
+        (JSC::decode): Stop using UTF8SequenceLength, and instead use U8_COUNT_TRAIL_BYTES
+        and U8_MAX_LENGTH. Instead of decodeUTF8Sequence, use U8_NEXT. Also use U_IS_BMP,
+        U_IS_SUPPLEMENTARY, U16_LEAD, U16_TRAIL, and U_IS_SURROGATE instead of our own
+        equivalents, since these macros from ICU are correct and efficient.
+
+        * wasm/WasmParser.h:
+        (JSC::Wasm::Parser<SuccessType>::consumeUTF8String): Updated for changes to
+        convertUTF8ToUTF16.
+
+2019-04-30  Commit Queue  <commit-queue@webkit.org>
+
+        Unreviewed, rolling out r244806.
+        https://bugs.webkit.org/show_bug.cgi?id=197446
+
+        Causing Test262 and JSC test failures on multiple builds
+        (Requested by ShawnRoberts on #webkit).
+
+        Reverted changeset:
+
+        "TypeArrays should not store properties that are canonical
+        numeric indices"
+        https://bugs.webkit.org/show_bug.cgi?id=197228
+        https://trac.webkit.org/changeset/244806
+
+2019-04-30  Saam barati  <sbarati@apple.com>
+
+        CodeBlock::m_instructionCount is wrong
+        https://bugs.webkit.org/show_bug.cgi?id=197304
+
+        Reviewed by Yusuke Suzuki.
+
+        What we were calling instructionCount() was wrong, as evidenced by
+        us using it incorrectly both in the sampling profiler and when we
+        dumped bytecode for a given CodeBlock. Prior to the bytecode rewrite,
+        instructionCount() was probably valid to do bounds checks against.
+        However, this is no longer the case. This patch renames what we called
+        instructionCount() to bytecodeCost(). It is now only used to make decisions
+        about inlining and tier up heuristics. I've also named options related to
+        this appropriately.
+        
+        This patch also introduces instructionsSize(). The result of this method
+        is valid to do bounds checks against.
+
+        * bytecode/CodeBlock.cpp:
+        (JSC::CodeBlock::dumpAssumingJITType const):
+        (JSC::CodeBlock::CodeBlock):
+        (JSC::CodeBlock::finishCreation):
+        (JSC::CodeBlock::optimizationThresholdScalingFactor):
+        (JSC::CodeBlock::predictedMachineCodeSize):
+        * bytecode/CodeBlock.h:
+        (JSC::CodeBlock::instructionsSize const):
+        (JSC::CodeBlock::bytecodeCost const):
+        (JSC::CodeBlock::instructionCount const): Deleted.
+        * dfg/DFGByteCodeParser.cpp:
+        (JSC::DFG::ByteCodeParser::inliningCost):
+        (JSC::DFG::ByteCodeParser::getInliningBalance):
+        * dfg/DFGCapabilities.cpp:
+        (JSC::DFG::mightCompileEval):
+        (JSC::DFG::mightCompileProgram):
+        (JSC::DFG::mightCompileFunctionForCall):
+        (JSC::DFG::mightCompileFunctionForConstruct):
+        (JSC::DFG::mightInlineFunctionForCall):
+        (JSC::DFG::mightInlineFunctionForClosureCall):
+        (JSC::DFG::mightInlineFunctionForConstruct):
+        * dfg/DFGCapabilities.h:
+        (JSC::DFG::isSmallEnoughToInlineCodeInto):
+        * dfg/DFGDisassembler.cpp:
+        (JSC::DFG::Disassembler::dumpHeader):
+        * dfg/DFGDriver.cpp:
+        (JSC::DFG::compileImpl):
+        * dfg/DFGPlan.cpp:
+        (JSC::DFG::Plan::compileInThread):
+        * dfg/DFGTierUpCheckInjectionPhase.cpp:
+        (JSC::DFG::TierUpCheckInjectionPhase::run):
+        * ftl/FTLCapabilities.cpp:
+        (JSC::FTL::canCompile):
+        * ftl/FTLCompile.cpp:
+        (JSC::FTL::compile):
+        * ftl/FTLLink.cpp:
+        (JSC::FTL::link):
+        * jit/JIT.cpp:
+        (JSC::JIT::link):
+        * jit/JITDisassembler.cpp:
+        (JSC::JITDisassembler::dumpHeader):
+        * llint/LLIntSlowPaths.cpp:
+        (JSC::LLInt::shouldJIT):
+        * profiler/ProfilerBytecodes.cpp:
+        (JSC::Profiler::Bytecodes::Bytecodes):
+        * runtime/Options.h:
+        * runtime/SamplingProfiler.cpp:
+        (JSC::tryGetBytecodeIndex):
+        (JSC::SamplingProfiler::processUnverifiedStackTraces):
+
+2019-04-30  Tadeu Zagallo  <tzagallo@apple.com>
+
+        TypeArrays should not store properties that are canonical numeric indices
+        https://bugs.webkit.org/show_bug.cgi?id=197228
+        <rdar://problem/49557381>
+
+        Reviewed by Darin Adler.
+
+        According to the spec[1], TypedArrays should not perform an ordinary GetOwnProperty/SetOwnProperty
+        if the index is a CanonicalNumericIndexString, but invalid according toIntegerIndexedElementGet
+        and similar functions. I.e., there are a few properties that should not be set in a TypedArray,
+        like NaN, Infinity and -0.
+
+        [1]: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-integer-indexed-exotic-objects-defineownproperty-p-desc
+
+        * CMakeLists.txt:
+        * JavaScriptCore.xcodeproj/project.pbxproj:
+        * runtime/JSGenericTypedArrayViewInlines.h:
+        (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
+        (JSC::JSGenericTypedArrayView<Adaptor>::put):
+        (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
+        (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlotByIndex):
+        (JSC::JSGenericTypedArrayView<Adaptor>::putByIndex):
+        * runtime/JSTypedArrays.cpp:
+        * runtime/PropertyName.h:
+        (JSC::canonicalNumericIndexString):
+
+2019-04-30  Brian Burg  <bburg@apple.com>
+
+        Web Automation: use a more informative key to indicate automation availability
+        https://bugs.webkit.org/show_bug.cgi?id=197377
+        <rdar://problem/50258069>
+
+        Reviewed by Devin Rousso.
+
+        The existing WIRAutomationEnabledKey does not encode uncertainty.
+        Add a new key that provides an 'Unknown' state, and prefer to use it.
+
+        Since an application's initial listing is sent from a background dispatch queue
+        on Cocoa platforms, this can race with main thread initialization that sets up
+        RemoteInspector::Client. Therefore, the initial listing may not properly represent
+        the client's capabilites because the client is not yet available. Allowing for
+        an "Unknown" state that is later upgraded to Available or Not Available makes it
+        possible to work around this potential race.
+
+        * inspector/remote/RemoteInspectorConstants.h:
+        * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
+        (Inspector::RemoteInspector::pushListingsNow):
+
+2019-04-30  Keith Miller  <keith_miller@apple.com>
+
+        Fix failing ARM64E wasm tests
+        https://bugs.webkit.org/show_bug.cgi?id=197420
+
+        Reviewed by Saam Barati.
+
+        This patch fixes a bug in the slow path of our JS->Wasm IC bridge
+        where we wouldn't untag the link register before tail calling.
+
+        Additionally, this patch fixes a broken assert when using setting
+        Options::useTailCalls=false.
+
+        * bytecompiler/BytecodeGenerator.cpp:
+        (JSC::BytecodeGenerator::emitCallForwardArgumentsInTailPosition):
+        * wasm/js/WebAssemblyFunction.cpp:
+        (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
+
+2019-04-29  Saam Barati  <sbarati@apple.com>
+
+        Make JITType an enum class
+        https://bugs.webkit.org/show_bug.cgi?id=197394
+
+        Reviewed by Yusuke Suzuki.
+
+        This makes the code more easily searchable.
+
+        * bytecode/CallLinkStatus.cpp:
+        (JSC::CallLinkStatus::computeFor):
+        * bytecode/CodeBlock.cpp:
+        (JSC::CodeBlock::dumpAssumingJITType const):
+        (JSC::CodeBlock::specialOSREntryBlockOrNull):
+        (JSC::timeToLive):
+        (JSC::CodeBlock::propagateTransitions):
+        (JSC::CodeBlock::baselineAlternative):
+        (JSC::CodeBlock::baselineVersion):
+        (JSC::CodeBlock::hasOptimizedReplacement):
+        (JSC::CodeBlock::noticeIncomingCall):
+        (JSC::CodeBlock::setOptimizationThresholdBasedOnCompilationResult):
+        (JSC::CodeBlock::tallyFrequentExitSites):
+        (JSC::CodeBlock::frameRegisterCount):
+        (JSC::CodeBlock::bytecodeOffsetFromCallSiteIndex):
+        * bytecode/CodeBlock.h:
+        (JSC::CodeBlock::jitType const):
+        (JSC::CodeBlock::hasBaselineJITProfiling const):
+        * bytecode/CodeBlockWithJITType.h:
+        (JSC::CodeBlockWithJITType::CodeBlockWithJITType):
+        * bytecode/DeferredSourceDump.cpp:
+        (JSC::DeferredSourceDump::DeferredSourceDump):
+        * bytecode/DeferredSourceDump.h:
+        * bytecode/ExitingJITType.h:
+        (JSC::exitingJITTypeFor):
+        * bytecode/InlineCallFrame.h:
+        (JSC::baselineCodeBlockForOriginAndBaselineCodeBlock):
+        * dfg/DFGByteCodeParser.cpp:
+        (JSC::DFG::ByteCodeParser::parseCodeBlock):
+        * dfg/DFGDisassembler.cpp:
+        (JSC::DFG::Disassembler::dumpHeader):
+        * dfg/DFGDriver.cpp:
+        (JSC::DFG::compileImpl):
+        * dfg/DFGGraph.cpp:
+        (JSC::DFG::Graph::dump):
+        * dfg/DFGJITCode.cpp:
+        (JSC::DFG::JITCode::JITCode):
+        (JSC::DFG::JITCode::checkIfOptimizationThresholdReached):
+        (JSC::DFG::JITCode::optimizeNextInvocation):
+        (JSC::DFG::JITCode::dontOptimizeAnytimeSoon):
+        (JSC::DFG::JITCode::optimizeAfterWarmUp):
+        (JSC::DFG::JITCode::optimizeSoon):
+        (JSC::DFG::JITCode::forceOptimizationSlowPathConcurrently):
+        (JSC::DFG::JITCode::setOptimizationThresholdBasedOnCompilationResult):
+        * dfg/DFGJITFinalizer.cpp:
+        (JSC::DFG::JITFinalizer::finalize):
+        (JSC::DFG::JITFinalizer::finalizeFunction):
+        * dfg/DFGOSREntry.cpp:
+        (JSC::DFG::prepareOSREntry):
+        (JSC::DFG::prepareCatchOSREntry):
+        * dfg/DFGOSRExit.cpp:
+        (JSC::DFG::OSRExit::executeOSRExit):
+        (JSC::DFG::reifyInlinedCallFrames):
+        (JSC::DFG::OSRExit::compileOSRExit):
+        * dfg/DFGOSRExitCompilerCommon.cpp:
+        (JSC::DFG::handleExitCounts):
+        (JSC::DFG::reifyInlinedCallFrames):
+        (JSC::DFG::adjustAndJumpToTarget):
+        * dfg/DFGOSRExitCompilerCommon.h:
+        (JSC::DFG::adjustFrameAndStackInOSRExitCompilerThunk):
+        * dfg/DFGOperations.cpp:
+        * dfg/DFGThunks.cpp:
+        (JSC::DFG::osrExitGenerationThunkGenerator):
+        * dfg/DFGVariableEventStream.cpp:
+        (JSC::DFG::VariableEventStream::reconstruct const):
+        * ftl/FTLCompile.cpp:
+        (JSC::FTL::compile):
+        * ftl/FTLJITCode.cpp:
+        (JSC::FTL::JITCode::JITCode):
+        * ftl/FTLJITFinalizer.cpp:
+        (JSC::FTL::JITFinalizer::finalizeCommon):
+        * ftl/FTLLink.cpp:
+        (JSC::FTL::link):
+        * ftl/FTLOSRExitCompiler.cpp:
+        (JSC::FTL::compileFTLOSRExit):
+        * ftl/FTLThunks.cpp:
+        (JSC::FTL::genericGenerationThunkGenerator):
+        * interpreter/CallFrame.cpp:
+        (JSC::CallFrame::callSiteBitsAreBytecodeOffset const):
+        (JSC::CallFrame::callSiteBitsAreCodeOriginIndex const):
+        * interpreter/StackVisitor.cpp:
+        (JSC::StackVisitor::Frame::dump const):
+        * jit/AssemblyHelpers.h:
+        (JSC::AssemblyHelpers::AssemblyHelpers):
+        * jit/JIT.cpp:
+        (JSC::JIT::link):
+        * jit/JITCode.cpp:
+        (JSC::JITCode::typeName):
+        (WTF::printInternal):
+        * jit/JITCode.h:
+        (JSC::JITCode::bottomTierJIT):
+        (JSC::JITCode::topTierJIT):
+        (JSC::JITCode::nextTierJIT):
+        (JSC::JITCode::isExecutableScript):
+        (JSC::JITCode::couldBeInterpreted):
+        (JSC::JITCode::isJIT):
+        (JSC::JITCode::isOptimizingJIT):
+        (JSC::JITCode::isBaselineCode):
+        (JSC::JITCode::jitTypeFor):
+        * jit/JITDisassembler.cpp:
+        (JSC::JITDisassembler::dumpHeader):
+        * jit/JITOperations.cpp:
+        * jit/JITThunks.cpp:
+        (JSC::JITThunks::hostFunctionStub):
+        * jit/JITToDFGDeferredCompilationCallback.cpp:
+        (JSC::JITToDFGDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
+        (JSC::JITToDFGDeferredCompilationCallback::compilationDidComplete):
+        * jit/JITWorklist.cpp:
+        (JSC::JITWorklist::compileLater):
+        (JSC::JITWorklist::compileNow):
+        * jit/Repatch.cpp:
+        (JSC::readPutICCallTarget):
+        (JSC::ftlThunkAwareRepatchCall):
+        * llint/LLIntEntrypoint.cpp:
+        (JSC::LLInt::setFunctionEntrypoint):
+        (JSC::LLInt::setEvalEntrypoint):
+        (JSC::LLInt::setProgramEntrypoint):
+        (JSC::LLInt::setModuleProgramEntrypoint):
+        * llint/LLIntSlowPaths.cpp:
+        (JSC::LLInt::jitCompileAndSetHeuristics):
+        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
+        * runtime/SamplingProfiler.cpp:
+        (JSC::SamplingProfiler::processUnverifiedStackTraces):
+        * runtime/SamplingProfiler.h:
+        * runtime/VM.cpp:
+        (JSC::jitCodeForCallTrampoline):
+        (JSC::jitCodeForConstructTrampoline):
+        * tools/CodeProfile.cpp:
+        (JSC::CodeProfile::sample):
+        * tools/JSDollarVM.cpp:
+        (JSC::CallerFrameJITTypeFunctor::CallerFrameJITTypeFunctor):
+        (JSC::CallerFrameJITTypeFunctor::jitType):
+        (JSC::functionLLintTrue):
+        (JSC::functionJITTrue):
+
+2019-04-29  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        Unreivewed, fix FTL implementation of r244760
+        https://bugs.webkit.org/show_bug.cgi?id=197362
+
+        Reviewed by Saam Barati.
+
+        Looked with Saam. ValueFromBlock from double case block was overridden by NaN thing now.
+
+        * ftl/FTLLowerDFGToB3.cpp:
+        (JSC::FTL::DFG::LowerDFGToB3::compileNormalizeMapKey):
+
+2019-04-29  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        normalizeMapKey should normalize NaN to one PureNaN bit pattern to make MapHash same
+        https://bugs.webkit.org/show_bug.cgi?id=197362
+
+        Reviewed by Saam Barati.
+
+        Our Map/Set's hash algorithm relies on the bit pattern of JSValue. So our Map/Set has
+        normalization of the key, which normalizes Int32 / Double etc. But we did not normalize
+        pure NaNs into one canonicalized pure NaN. So we end up having multiple different pure NaNs
+        in one Map/Set. This patch normalizes NaN into one jsNaN(), which uses PNaN for the representation.
+
+        * dfg/DFGSpeculativeJIT.cpp:
+        (JSC::DFG::SpeculativeJIT::compileNormalizeMapKey):
+        * ftl/FTLLowerDFGToB3.cpp:
+        (JSC::FTL::DFG::LowerDFGToB3::compileNormalizeMapKey):
+        * runtime/HashMapImpl.h:
+        (JSC::normalizeMapKey):
+
+2019-04-29  Alex Christensen  <achristensen@webkit.org>
+
+        <rdar://problem/50299396> Fix internal High Sierra build
+        https://bugs.webkit.org/show_bug.cgi?id=197388
+
+        * Configurations/Base.xcconfig:
+
+2019-04-29  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        JITStubRoutineSet wastes 180KB of HashTable capacity on can.com
+        https://bugs.webkit.org/show_bug.cgi?id=186732
+
+        Reviewed by Saam Barati.
+
+        Our current mechanism of JITStubRoutineSet consumes more memory than needed. Basically we have HashMap<uintptr_t, StubRoutine*> and register
+        each executable address by 16 byte to this entry. So if your StubRoutine has 128bytes, it just adds 8 entries to this hash table.
+        In Gmail, we see a ~2MB table size.
+
+        Instead, this patch uses Vector<pair<uintptr_t, StubRoutine*>> and performs binary search onto this sorted vector. Before conservative
+        scanning, we sort this vector. And doing binary search with the sorted vector to find executing stub routines from the conservative roots.
+        This vector includes uintptr_t startAddress to make binary searching fast.
+
+        Large amount of conservative scan should be filtered by range check, so I think binary search here is OK, but we can decide based on what the
+        performance bots say.
+
+        * heap/Heap.cpp:
+        (JSC::Heap::addCoreConstraints):
+        * heap/JITStubRoutineSet.cpp:
+        (JSC::JITStubRoutineSet::~JITStubRoutineSet):
+        (JSC::JITStubRoutineSet::add):
+        (JSC::JITStubRoutineSet::prepareForConservativeScan):
+        (JSC::JITStubRoutineSet::clearMarks):
+        (JSC::JITStubRoutineSet::markSlow):
+        (JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines):
+        (JSC::JITStubRoutineSet::traceMarkedStubRoutines):
+        * heap/JITStubRoutineSet.h:
+        (JSC::JITStubRoutineSet::mark):
+        (JSC::JITStubRoutineSet::prepareForConservativeScan):
+        (JSC::JITStubRoutineSet::size const): Deleted.
+        (JSC::JITStubRoutineSet::at const): Deleted.
+
+2019-04-29  Basuke Suzuki  <Basuke.Suzuki@sony.com>
+
+        [Win] Add flag to enable version information stamping and disable by default.
+        https://bugs.webkit.org/show_bug.cgi?id=197249
+        <rdar://problem/50224412>
+
+        Reviewed by Ross Kirsling.
+
+        This feature is only used in AppleWin port. Add flag for this task and make it OFF by default.
+        Then enable it by default on AppleWin.
+
+        * CMakeLists.txt:
+
+2019-04-26  Keith Rollin  <krollin@apple.com>
+
+        Enable new build rule for post-processing headers when using XCBuild
+        https://bugs.webkit.org/show_bug.cgi?id=197340
+        <rdar://problem/50226685>
+
+        Reviewed by Brent Fulgham.
+
+        In Bug 197116, we conditionally disabled the old method for
+        post-processing header files when we are using the new XCBuild build
+        system. This check-in conditionally enables the new post-processing
+        facility. Note that the old system is disabled and the new system
+        enabled only when the USE_NEW_BUILD_SYSTEM environment variable is set
+        to YES.
+
+        * Configurations/JavaScriptCore.xcconfig:
+
 2019-04-26  Jessie Berlin  <jberlin@webkit.org>
 
         Add new mac target numbers