Re-enable generate-xcfilelists
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
index a555e56..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.