Delete WebMetal implementation in favor of WebGPU
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
index 4f15643..85a1673 100644 (file)
+2019-03-29  Myles C. Maxfield  <mmaxfield@apple.com>
+
+        Delete WebMetal implementation in favor of WebGPU
+        https://bugs.webkit.org/show_bug.cgi?id=195418
+
+        Reviewed by Dean Jackson.
+
+        * Configurations/FeatureDefines.xcconfig:
+        * inspector/protocol/Canvas.json:
+        * inspector/scripts/codegen/generator.py:
+
+2019-03-29  Tadeu Zagallo  <tzagallo@apple.com>
+
+        Assertion failed in JSC::createError
+        https://bugs.webkit.org/show_bug.cgi?id=196305
+        <rdar://problem/49387382>
+
+        Reviewed by Saam Barati.
+
+        JSC::createError assumes that `errorDescriptionForValue` will either
+        throw an exception or return a valid description string. However, that
+        is not true if the value is a rope string and we successfully resolve it,
+        but later fail to wrap the string in quotes with `tryMakeString`.
+
+        * runtime/ExceptionHelpers.cpp:
+        (JSC::createError):
+
+2019-03-29  Devin Rousso  <drousso@apple.com>
+
+        Web Inspector: add fast returns for instrumentation hooks that have no affect before a frontend is connected
+        https://bugs.webkit.org/show_bug.cgi?id=196382
+        <rdar://problem/49403417>
+
+        Reviewed by Joseph Pecoraro.
+
+        Ensure that all instrumentation hooks use `FAST_RETURN_IF_NO_FRONTENDS` or check that
+        `developerExtrasEnabled`. There should be no activity to/from any inspector objects until
+        developer extras are enabled.
+
+        * inspector/agents/InspectorConsoleAgent.cpp:
+        (Inspector::InspectorConsoleAgent::startTiming):
+        (Inspector::InspectorConsoleAgent::stopTiming):
+        (Inspector::InspectorConsoleAgent::count):
+        (Inspector::InspectorConsoleAgent::addConsoleMessage):
+
+2019-03-29  Cathie Chen  <cathiechen@igalia.com>
+
+        Implement ResizeObserver.
+        https://bugs.webkit.org/show_bug.cgi?id=157743
+
+        Reviewed by Simon Fraser.
+
+        Add ENABLE_RESIZE_OBSERVER.
+
+        * Configurations/FeatureDefines.xcconfig:
+
+2019-03-28  Michael Saboff  <msaboff@apple.com>
+
+        [YARR] Precompute BMP / non-BMP status when constructing character classes
+        https://bugs.webkit.org/show_bug.cgi?id=196296
+
+        Reviewed by Keith Miller.
+
+        Changed CharacterClass::m_hasNonBMPCharacters into a character width bit field which
+        indicateis if the class includes characters from either BMP, non-BMP or both ranges.
+        This allows the recognizing code to eliminate checks for the width of a matched
+        characters when the class has only one width.  The character width is needed to
+        determine if we advance 1 or 2 character.  Also, the pre-computed width of character
+        classes that contains either all BMP or all non-BMP characters allows the parser to
+        use fixed widths for terms using those character classes.  Changed both the code gen
+        scripts and Yarr compiler to compute this bit field during the construction of
+        character classes.
+
+        For JIT'ed code of character classes that contain either all BMP or all non-BMP
+        characters, we can eliminate the generic check we were doing do compute how much
+        to advance after sucessfully matching a character in the class.
+
+                Generic isBMP check      BMP only            non-BMP only
+                --------------           --------------      --------------
+                inc %r9d                 inc %r9d            add $0x2, %r9d
+                cmp $0x10000, %eax
+                jl isBMP
+                cmp %edx, %esi
+                jz atEndOfString
+                inc %r9d
+                inc %esi
+         isBMP:
+
+        For character classes that contained non-BMP characters, we were always generating
+        the code in the left column.  The middle column is the code we generate for character
+        classes that contain only BMP characters.  The right column is the code we now
+        generate if the character class has only non-BMP characters.  In the fix width cases,
+        we can eliminate both the isBMP check as well as the atEndOfString check.  The
+        atEndOfstring check is eliminated since we know how many characters this character
+        class requires and that check can be factored out to the beginning of the current
+        alternative.  For character classes that contain both BMP and non-BMP characters,
+        we still generate the generic left column.
+
+        This change is a ~8% perf progression on UniPoker and a ~2% improvement on RexBench
+        as a whole.
+
+        * runtime/RegExp.cpp:
+        (JSC::RegExp::matchCompareWithInterpreter):
+        * runtime/RegExpInlines.h:
+        (JSC::RegExp::matchInline):
+        * yarr/YarrInterpreter.cpp:
+        (JSC::Yarr::Interpreter::checkCharacterClassDontAdvanceInputForNonBMP):
+        (JSC::Yarr::Interpreter::matchCharacterClass):
+        * yarr/YarrJIT.cpp:
+        (JSC::Yarr::YarrGenerator::optimizeAlternative):
+        (JSC::Yarr::YarrGenerator::matchCharacterClass):
+        (JSC::Yarr::YarrGenerator::advanceIndexAfterCharacterClassTermMatch):
+        (JSC::Yarr::YarrGenerator::tryReadUnicodeCharImpl):
+        (JSC::Yarr::YarrGenerator::generateCharacterClassOnce):
+        (JSC::Yarr::YarrGenerator::generateCharacterClassFixed):
+        (JSC::Yarr::YarrGenerator::generateCharacterClassGreedy):
+        (JSC::Yarr::YarrGenerator::backtrackCharacterClassGreedy):
+        (JSC::Yarr::YarrGenerator::generateCharacterClassNonGreedy):
+        (JSC::Yarr::YarrGenerator::backtrackCharacterClassNonGreedy):
+        (JSC::Yarr::YarrGenerator::generateEnter):
+        (JSC::Yarr::YarrGenerator::YarrGenerator):
+        (JSC::Yarr::YarrGenerator::compile):
+        * yarr/YarrPattern.cpp:
+        (JSC::Yarr::CharacterClassConstructor::CharacterClassConstructor):
+        (JSC::Yarr::CharacterClassConstructor::reset):
+        (JSC::Yarr::CharacterClassConstructor::charClass):
+        (JSC::Yarr::CharacterClassConstructor::addSorted):
+        (JSC::Yarr::CharacterClassConstructor::addSortedRange):
+        (JSC::Yarr::CharacterClassConstructor::hasNonBMPCharacters):
+        (JSC::Yarr::CharacterClassConstructor::characterWidths):
+        (JSC::Yarr::PatternTerm::dump):
+        (JSC::Yarr::anycharCreate):
+        * yarr/YarrPattern.h:
+        (JSC::Yarr::operator|):
+        (JSC::Yarr::operator&):
+        (JSC::Yarr::operator|=):
+        (JSC::Yarr::CharacterClass::CharacterClass):
+        (JSC::Yarr::CharacterClass::hasNonBMPCharacters):
+        (JSC::Yarr::CharacterClass::hasOneCharacterSize):
+        (JSC::Yarr::CharacterClass::hasOnlyNonBMPCharacters):
+        (JSC::Yarr::PatternTerm::invert const):
+        (JSC::Yarr::PatternTerm::invert): Deleted.
+        * yarr/create_regex_tables:
+        * yarr/generateYarrUnicodePropertyTables.py:
+
+2019-03-28  Saam Barati  <sbarati@apple.com>
+
+        BackwardsGraph needs to consider back edges as the backward's root successor
+        https://bugs.webkit.org/show_bug.cgi?id=195991
+
+        Reviewed by Filip Pizlo.
+
+        * b3/testb3.cpp:
+        (JSC::B3::testInfiniteLoopDoesntCauseBadHoisting):
+        (JSC::B3::run):
+
+2019-03-28  Fujii Hironori  <Hironori.Fujii@sony.com>
+
+        Opcode.h(159,27): warning: adding 'unsigned int' to a string does not append to the string [-Wstring-plus-int]
+        https://bugs.webkit.org/show_bug.cgi?id=196343
+
+        Reviewed by Saam Barati.
+
+        Clang reports a compilation warning and recommend '&PADDING_STRING[PADDING_STRING_LENGTH]'
+        instead of 'PADDING_STRING + PADDING_STRING_LENGTH'.
+
+        * bytecode/Opcode.cpp:
+        (JSC::padOpcodeName): Moved padOpcodeName from Opcode.h because
+        this function is used only in Opcode.cpp. Changed macros
+        PADDING_STRING and PADDING_STRING_LENGTH to simple variables.
+        (JSC::compareOpcodePairIndices): Replaced pair with std::pair.
+        * bytecode/Opcode.h:
+        (JSC::padOpcodeName): Moved.
+
+2019-03-28  Tadeu Zagallo  <tzagallo@apple.com>
+
+        CodeBlock::jettison() should disallow repatching its own calls
+        https://bugs.webkit.org/show_bug.cgi?id=196359
+        <rdar://problem/48973663>
+
+        Reviewed by Saam Barati.
+
+        CodeBlock::jettison() calls CommonData::invalidate, which replaces the `hlt`
+        instruction with the jump to OSR exit. However, if the `hlt` was immediately
+        followed by a call to the CodeBlock being jettisoned, we would write over the
+        OSR exit address while unlinking all the incoming CallLinkInfos later in
+        CodeBlock::jettison().
+
+        Change it so that we set a flag, `clearedByJettison`, in all the CallLinkInfos
+        owned by the CodeBlock being jettisoned. If the flag is set, we will avoid
+        repatching the call during unlinking. This is safe because this call will never
+        be reachable again after the CodeBlock is jettisoned.
+
+        * bytecode/CallLinkInfo.cpp:
+        (JSC::CallLinkInfo::CallLinkInfo):
+        (JSC::CallLinkInfo::setCallee):
+        (JSC::CallLinkInfo::clearCallee):
+        (JSC::CallLinkInfo::setCodeBlock):
+        (JSC::CallLinkInfo::clearCodeBlock):
+        * bytecode/CallLinkInfo.h:
+        (JSC::CallLinkInfo::clearedByJettison):
+        (JSC::CallLinkInfo::setClearedByJettison):
+        * bytecode/CodeBlock.cpp:
+        (JSC::CodeBlock::jettison):
+        * jit/Repatch.cpp:
+        (JSC::revertCall):
+
+2019-03-27  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Drop VM and Context cache map in JavaScriptCore.framework
+        https://bugs.webkit.org/show_bug.cgi?id=196341
+
+        Reviewed by Saam Barati.
+
+        Previously, we created Objective-C weak map to maintain JSVirtualMachine and JSContext wrappers corresponding to VM and JSGlobalObject.
+        But Objective-C weak map is really memory costly. Even if the entry is only one, it consumes 2.5KB per weak map. Since we can modify
+        JSC intrusively for JavaScriptCore.framework (and we already did it, like, holding JSWrapperMap in JSGlobalObject), we can just hold
+        a pointer to a wrapper in VM and JSGlobalObject.
+
+        This patch adds void* members to VM and JSGlobalObject, which holds a non-strong reference to a wrapper. When a wrapper is gone, we
+        clear this pointer too. This removes unnecessary two Objective-C weak maps, and save 5KB.
+
+        * API/JSContext.mm:
+        (-[JSContext initWithVirtualMachine:]):
+        (-[JSContext dealloc]):
+        (-[JSContext initWithGlobalContextRef:]):
+        (-[JSContext wrapperMap]):
+        (+[JSContext contextWithJSGlobalContextRef:]):
+        * API/JSVirtualMachine.mm:
+        (-[JSVirtualMachine initWithContextGroupRef:]):
+        (-[JSVirtualMachine dealloc]):
+        (+[JSVirtualMachine virtualMachineWithContextGroupRef:]):
+        (scanExternalObjectGraph):
+        (scanExternalRememberedSet):
+        (initWrapperCache): Deleted.
+        (wrapperCache): Deleted.
+        (+[JSVMWrapperCache addWrapper:forJSContextGroupRef:]): Deleted.
+        (+[JSVMWrapperCache wrapperForJSContextGroupRef:]): Deleted.
+        (-[JSVirtualMachine contextForGlobalContextRef:]): Deleted.
+        (-[JSVirtualMachine addContext:forGlobalContextRef:]): Deleted.
+        * API/JSVirtualMachineInternal.h:
+        * runtime/JSGlobalObject.h:
+        (JSC::JSGlobalObject::setAPIWrapper):
+        (JSC::JSGlobalObject::apiWrapper const):
+        * runtime/VM.h:
+
+2019-03-28  Tadeu Zagallo  <tzagallo@apple.com>
+
+        In-memory code cache should not share bytecode across domains
+        https://bugs.webkit.org/show_bug.cgi?id=196321
+
+        Reviewed by Geoffrey Garen.
+
+        Use the SourceProvider's URL to make sure that the hosts match for the
+        two SourceCodeKeys in operator==.
+
+        * parser/SourceCodeKey.h:
+        (JSC::SourceCodeKey::host const):
+        (JSC::SourceCodeKey::operator== const):
+
+2019-03-28  Víctor Manuel Jáquez Leal  <vjaquez@igalia.com>
+
+        Silence lot of warnings when compiling with clang
+        https://bugs.webkit.org/show_bug.cgi?id=196310
+
+        Reviewed by Michael Catanzaro.
+
+        Initialize variable with default constructor.
+
+        * API/glib/JSCOptions.cpp:
+        (jsc_options_foreach):
+
+2019-03-27  Saam Barati  <sbarati@apple.com>
+
+        validateOSREntryValue with Int52 should box the value being checked into double format
+        https://bugs.webkit.org/show_bug.cgi?id=196313
+        <rdar://problem/49306703>
+
+        Reviewed by Yusuke Suzuki.
+
+        * dfg/DFGOSREntry.cpp:
+        (JSC::DFG::prepareOSREntry):
+        * ftl/FTLLowerDFGToB3.cpp:
+        (JSC::FTL::DFG::LowerDFGToB3::validateAIState):
+
+2019-03-27  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Owner of watchpoints should validate at GC finalizing phase
+        https://bugs.webkit.org/show_bug.cgi?id=195827
+
+        Reviewed by Filip Pizlo.
+
+        This patch fixes JSC's watchpoint liveness issue by the following two policies.
+
+        1. Watchpoint should have owner cell, and "fire" operation should be gaurded with owner cell's isLive check.
+
+        Watchpoints should hold its owner cell, and fire procedure should be guarded by `owner->isLive()`.
+        When the owner cell is destroyed, these watchpoints are destroyed too. But this destruction can
+        be delayed due to incremental sweeper. So the following condition can happen.
+
+        When we have a watchpoint like the following.
+
+            class XXXWatchpoint {
+                ObjectPropertyCondition m_key;
+                JSCell* m_owner;
+            };
+
+        Both m_key's cell and m_owner is now unreachable from the root. So eventually, m_owner cell's destructor
+        is called and this watchpoint will be destroyed. But before that, m_key's cell can be destroyed. And this
+        watchpoint's fire procedure can be called since m_owner's destructor is not called yet. In this situation,
+        we encounter the destroyed cell held in m_key. This problem can be avoided if we guard fire procedure with
+        `m_owner->isLive()`. Until the owner cell is destroyed, this guard avoids "fire" procedure execution. And
+        once the destructor of m_owner is called, this watchpoint will be destroyed too.
+
+        2. Watchpoint liveness should be maintained by owner cell's unconditional finalizer
+
+        Watchpoints often hold weak references to the other cell (like, m_key in the above example). If we do not
+        delete watchpoints with dead cells when these weak cells become dead, these watchpoints continue holding dead cells,
+        and watchpoint's fire operation can use these dead cells accidentally. isLive / isStillLive check for these weak cells
+        in fire operation is not useful. Because these dead cells can be reused to the other live cells eventually, and this
+        isLive / isStillLive checks fail to see these cells are live if they are reused. Appropriate way is deleting watchpoints
+        with dead cells when finalizing GC. In this patch, we do this in unconditional finalizers in owner cells of watchpoints.
+        We already did this in CodeBlock etc. We add the same thing to StructureRareData which owns watchpoints for toString operations.
+
+        * JavaScriptCore.xcodeproj/project.pbxproj:
+        * Sources.txt:
+        * bytecode/AdaptiveInferredPropertyValueWatchpointBase.h:
+        (JSC::AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint::StructureWatchpoint): Deleted.
+        (JSC::AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint::PropertyWatchpoint): Deleted.
+        * bytecode/CodeBlockJettisoningWatchpoint.h:
+        (JSC::CodeBlockJettisoningWatchpoint::CodeBlockJettisoningWatchpoint): Deleted.
+        * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
+        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
+        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
+        * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
+        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::key const): Deleted.
+        * bytecode/StructureStubClearingWatchpoint.cpp:
+        (JSC::StructureStubClearingWatchpoint::fireInternal):
+        (JSC::WatchpointsOnStructureStubInfo::isValid const):
+        * bytecode/StructureStubClearingWatchpoint.h:
+        (JSC::StructureStubClearingWatchpoint::StructureStubClearingWatchpoint): Deleted.
+        * dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:
+        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::isValid const):
+        * dfg/DFGAdaptiveInferredPropertyValueWatchpoint.h:
+        * dfg/DFGAdaptiveStructureWatchpoint.cpp:
+        (JSC::DFG::AdaptiveStructureWatchpoint::fireInternal):
+        * dfg/DFGAdaptiveStructureWatchpoint.h:
+        (JSC::DFG::AdaptiveStructureWatchpoint::key const): Deleted.
+        * dfg/DFGDesiredWatchpoints.cpp:
+        (JSC::DFG::ArrayBufferViewWatchpointAdaptor::add):
+        * heap/Heap.cpp:
+        (JSC::Heap::finalizeUnconditionalFinalizers):
+        * llint/LLIntSlowPaths.cpp:
+        (JSC::LLInt::setupGetByIdPrototypeCache):
+        * runtime/ArrayBuffer.cpp:
+        (JSC::ArrayBuffer::notifyIncommingReferencesOfTransfer):
+        * runtime/ArrayBufferNeuteringWatchpointSet.cpp: Renamed from Source/JavaScriptCore/runtime/ArrayBufferNeuteringWatchpoint.cpp.
+        (JSC::ArrayBufferNeuteringWatchpointSet::ArrayBufferNeuteringWatchpointSet):
+        (JSC::ArrayBufferNeuteringWatchpointSet::destroy):
+        (JSC::ArrayBufferNeuteringWatchpointSet::create):
+        (JSC::ArrayBufferNeuteringWatchpointSet::createStructure):
+        (JSC::ArrayBufferNeuteringWatchpointSet::fireAll):
+        * runtime/ArrayBufferNeuteringWatchpointSet.h: Renamed from Source/JavaScriptCore/runtime/ArrayBufferNeuteringWatchpoint.h.
+        * runtime/FunctionRareData.h:
+        * runtime/JSGlobalObject.cpp:
+        (JSC::JSGlobalObject::init):
+        (JSC::JSGlobalObject::tryInstallArraySpeciesWatchpoint):
+        * runtime/ObjectPropertyChangeAdaptiveWatchpoint.h:
+        (JSC::ObjectPropertyChangeAdaptiveWatchpoint::ObjectPropertyChangeAdaptiveWatchpoint): Deleted.
+        * runtime/StructureRareData.cpp:
+        (JSC::StructureRareData::finalizeUnconditionally):
+        * runtime/StructureRareData.h:
+        * runtime/VM.cpp:
+        (JSC::VM::VM):
+
+2019-03-26  Saam Barati  <sbarati@apple.com>
+
+        FTL: Emit code to validate AI's state when running the compiled code
+        https://bugs.webkit.org/show_bug.cgi?id=195924
+        <rdar://problem/49003422>
+
+        Reviewed by Filip Pizlo.
+
+        This patch adds code that between the execution of each node that validates
+        the types that AI proves. This option is too expensive to turn on for our
+        regression testing, but we think it will be valuable in other types of running
+        modes, such as when running with a fuzzer.
+        
+        This patch also adds options to only probabilistically run this validation
+        after the execution of each node. As the probability is lowered, there is
+        less of a perf hit.
+        
+        This patch just adds this validation in the FTL. A follow-up patch will land
+        it in the DFG too: https://bugs.webkit.org/show_bug.cgi?id=196219
+
+        * ftl/FTLLowerDFGToB3.cpp:
+        (JSC::FTL::DFG::LowerDFGToB3::LowerDFGToB3):
+        (JSC::FTL::DFG::LowerDFGToB3::compileBlock):
+        (JSC::FTL::DFG::LowerDFGToB3::validateAIState):
+        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
+        (JSC::FTL::DFG::LowerDFGToB3::lowJSValue):
+        * runtime/Options.h:
+
+2019-03-26  Tadeu Zagallo  <tzagallo@apple.com>
+
+        WebAssembly: Fix f32.min, f64.min and f64.max operations on NaN
+        https://bugs.webkit.org/show_bug.cgi?id=196217
+
+        Reviewed by Saam Barati.
+
+        Generalize the fix for f32.max to properly handle NaN by doing an extra GreatherThan
+        comparison in r243446 to all min and max float operations.
+
+        * wasm/WasmAirIRGenerator.cpp:
+        (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Min>):
+        (JSC::Wasm::AirIRGenerator::addFloatingPointMinOrMax):
+        (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Max>):
+        (JSC::Wasm::AirIRGenerator::addOp<OpType::F64Min>):
+        (JSC::Wasm::AirIRGenerator::addOp<OpType::F64Max>):
+        * wasm/wasm.json:
+
+2019-03-26  Andy VanWagoner  <andy@vanwagoner.family>
+
+        Intl.DateTimeFormat should obey 2-digit hour
+        https://bugs.webkit.org/show_bug.cgi?id=195974
+
+        Reviewed by Keith Miller.
+
+        * runtime/IntlDateTimeFormat.cpp:
+        (JSC::IntlDateTimeFormat::initializeDateTimeFormat):
+
+2019-03-25  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        Heap::isMarked and friends should be instance methods
+        https://bugs.webkit.org/show_bug.cgi?id=179988
+
+        Reviewed by Saam Barati.
+
+        Almost all the callers of Heap::isMarked have VM& reference. We should make Heap::isMarked instance function instead of static function
+        so that we do not need to look up Heap from the cell.
+
+        * API/JSAPIWrapperObject.mm:
+        (JSAPIWrapperObjectHandleOwner::isReachableFromOpaqueRoots):
+        * API/JSMarkingConstraintPrivate.cpp:
+        (JSC::isMarked):
+        * API/glib/JSAPIWrapperObjectGLib.cpp:
+        (JSAPIWrapperObjectHandleOwner::isReachableFromOpaqueRoots):
+        * builtins/BuiltinExecutables.cpp:
+        (JSC::BuiltinExecutables::finalizeUnconditionally):
+        * bytecode/AccessCase.cpp:
+        (JSC::AccessCase::visitWeak const):
+        (JSC::AccessCase::propagateTransitions const):
+        * bytecode/CallLinkInfo.cpp:
+        (JSC::CallLinkInfo::visitWeak):
+        * bytecode/CallLinkStatus.cpp:
+        (JSC::CallLinkStatus::finalize):
+        * bytecode/CallLinkStatus.h:
+        * bytecode/CallVariant.cpp:
+        (JSC::CallVariant::finalize):
+        * bytecode/CallVariant.h:
+        * bytecode/CodeBlock.cpp:
+        (JSC::CodeBlock::shouldJettisonDueToWeakReference):
+        (JSC::CodeBlock::shouldJettisonDueToOldAge):
+        (JSC::shouldMarkTransition):
+        (JSC::CodeBlock::propagateTransitions):
+        (JSC::CodeBlock::determineLiveness):
+        (JSC::CodeBlock::finalizeLLIntInlineCaches):
+        (JSC::CodeBlock::finalizeUnconditionally):
+        (JSC::CodeBlock::jettison):
+        * bytecode/CodeBlock.h:
+        * bytecode/ExecutableToCodeBlockEdge.cpp:
+        (JSC::ExecutableToCodeBlockEdge::visitChildren):
+        (JSC::ExecutableToCodeBlockEdge::finalizeUnconditionally):
+        (JSC::ExecutableToCodeBlockEdge::runConstraint):
+        * bytecode/GetByIdStatus.cpp:
+        (JSC::GetByIdStatus::finalize):
+        * bytecode/GetByIdStatus.h:
+        * bytecode/GetByIdVariant.cpp:
+        (JSC::GetByIdVariant::finalize):
+        * bytecode/GetByIdVariant.h:
+        * bytecode/InByIdStatus.cpp:
+        (JSC::InByIdStatus::finalize):
+        * bytecode/InByIdStatus.h:
+        * bytecode/InByIdVariant.cpp:
+        (JSC::InByIdVariant::finalize):
+        * bytecode/InByIdVariant.h:
+        * bytecode/ObjectPropertyCondition.cpp:
+        (JSC::ObjectPropertyCondition::isStillLive const):
+        * bytecode/ObjectPropertyCondition.h:
+        * bytecode/ObjectPropertyConditionSet.cpp:
+        (JSC::ObjectPropertyConditionSet::areStillLive const):
+        * bytecode/ObjectPropertyConditionSet.h:
+        * bytecode/PolymorphicAccess.cpp:
+        (JSC::PolymorphicAccess::visitWeak const):
+        * bytecode/PropertyCondition.cpp:
+        (JSC::PropertyCondition::isStillLive const):
+        * bytecode/PropertyCondition.h:
+        * bytecode/PutByIdStatus.cpp:
+        (JSC::PutByIdStatus::finalize):
+        * bytecode/PutByIdStatus.h:
+        * bytecode/PutByIdVariant.cpp:
+        (JSC::PutByIdVariant::finalize):
+        * bytecode/PutByIdVariant.h:
+        * bytecode/RecordedStatuses.cpp:
+        (JSC::RecordedStatuses::finalizeWithoutDeleting):
+        (JSC::RecordedStatuses::finalize):
+        * bytecode/RecordedStatuses.h:
+        * bytecode/StructureSet.cpp:
+        (JSC::StructureSet::isStillAlive const):
+        * bytecode/StructureSet.h:
+        * bytecode/StructureStubInfo.cpp:
+        (JSC::StructureStubInfo::visitWeakReferences):
+        * dfg/DFGPlan.cpp:
+        (JSC::DFG::Plan::finalizeInGC):
+        (JSC::DFG::Plan::isKnownToBeLiveDuringGC):
+        * heap/GCIncomingRefCounted.h:
+        * heap/GCIncomingRefCountedInlines.h:
+        (JSC::GCIncomingRefCounted<T>::filterIncomingReferences):
+        * heap/GCIncomingRefCountedSet.h:
+        * heap/GCIncomingRefCountedSetInlines.h:
+        (JSC::GCIncomingRefCountedSet<T>::lastChanceToFinalize):
+        (JSC::GCIncomingRefCountedSet<T>::sweep):
+        (JSC::GCIncomingRefCountedSet<T>::removeAll): Deleted.
+        (JSC::GCIncomingRefCountedSet<T>::removeDead): Deleted.
+        * heap/Heap.cpp:
+        (JSC::Heap::addToRememberedSet):
+        (JSC::Heap::runEndPhase):
+        (JSC::Heap::sweepArrayBuffers):
+        (JSC::Heap::addCoreConstraints):
+        * heap/Heap.h:
+        * heap/HeapInlines.h:
+        (JSC::Heap::isMarked):
+        * heap/HeapSnapshotBuilder.cpp:
+        (JSC::HeapSnapshotBuilder::appendNode):
+        * heap/SlotVisitor.cpp:
+        (JSC::SlotVisitor::appendToMarkStack):
+        (JSC::SlotVisitor::visitChildren):
+        * jit/PolymorphicCallStubRoutine.cpp:
+        (JSC::PolymorphicCallStubRoutine::visitWeak):
+        * runtime/ErrorInstance.cpp:
+        (JSC::ErrorInstance::finalizeUnconditionally):
+        * runtime/InferredValueInlines.h:
+        (JSC::InferredValue::finalizeUnconditionally):
+        * runtime/StackFrame.h:
+        (JSC::StackFrame::isMarked const):
+        * runtime/Structure.cpp:
+        (JSC::Structure::isCheapDuringGC):
+        (JSC::Structure::markIfCheap):
+        * runtime/Structure.h:
+        * runtime/TypeProfiler.cpp:
+        (JSC::TypeProfiler::invalidateTypeSetCache):
+        * runtime/TypeProfiler.h:
+        * runtime/TypeSet.cpp:
+        (JSC::TypeSet::invalidateCache):
+        * runtime/TypeSet.h:
+        * runtime/WeakMapImpl.cpp:
+        (JSC::WeakMapImpl<WeakMapBucket<WeakMapBucketDataKeyValue>>::visitOutputConstraints):
+        * runtime/WeakMapImplInlines.h:
+        (JSC::WeakMapImpl<WeakMapBucket>::finalizeUnconditionally):
+
+2019-03-25  Keith Miller  <keith_miller@apple.com>
+
+        ASSERTION FAILED: m_op == CompareStrictEq in JSC::DFG::Node::convertToCompareEqPtr(JSC::DFG::FrozenValue *, JSC::DFG::Edge)
+        https://bugs.webkit.org/show_bug.cgi?id=196176
+
+        Reviewed by Saam Barati.
+
+        convertToCompareEqPtr should allow for either CompareStrictEq or
+        the SameValue DFG node. This fixes the old assertion that only
+        allowed CompareStrictEq.
+
+        * dfg/DFGNode.h:
+        (JSC::DFG::Node::convertToCompareEqPtr):
+
+2019-03-25  Tadeu Zagallo  <tzagallo@apple.com>
+
+        WebAssembly: f32.max with NaN generates incorrect result
+        https://bugs.webkit.org/show_bug.cgi?id=175691
+        <rdar://problem/33952228>
+
+        Reviewed by Saam Barati.
+
+        Fix the B3 and Air compilation for f32.max. In order to handle the NaN
+        case, we need an extra GreaterThan comparison on top of the existing
+        Equal and LessThan ones.
+
+        * wasm/WasmAirIRGenerator.cpp:
+        (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Max>):
+        * wasm/wasm.json:
+
+2019-03-25  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        Unreviewed, speculative fix for CLoop build on CPU(UNKNOWN)
+        https://bugs.webkit.org/show_bug.cgi?id=195982
+
+        * jit/ExecutableAllocator.h:
+        (JSC::ExecutableAllocator::initializeUnderlyingAllocator):
+
+2019-03-25  Gyuyoung Kim  <gyuyoung.kim@webkit.org>
+
+        Remove NavigatorContentUtils in WebCore/Modules
+        https://bugs.webkit.org/show_bug.cgi?id=196070
+
+        Reviewed by Alex Christensen.
+
+        NavigatorContentUtils was to support the custom scheme spec [1].
+        However, in WebKit side, no port has supported the feature in
+        WebKit layer after EFL port was removed. So there has been the
+        only IDL implementation of the NavigatorContentUtils in WebCore.
+        So we don't need to keep the implementation in WebCore anymore.
+
+        [1] https://html.spec.whatwg.org/multipage/system-state.html#custom-handlers
+
+        * Configurations/FeatureDefines.xcconfig:
+
+2019-03-23  Mark Lam  <mark.lam@apple.com>
+
+        Rolling out r243032 and r243071 because the fix is incorrect.
+        https://bugs.webkit.org/show_bug.cgi?id=195892
+        <rdar://problem/48981239>
+
+        Not reviewed.
+
+        The fix is incorrect: it relies on being able to determine liveness of an object
+        in an ObjectPropertyCondition based on the state of the object's MarkedBit.
+        However, there's no guarantee that GC has run and that the MarkedBit is already
+        set even if the object is live.  As a result, we may not re-install adaptive
+        watchpoints based on presumed dead objects which are actually live.
+
+        I'm rolling this out, and will implement a more comprehensive fix to handle
+        watchpoint liveness later.
+
+        * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
+        (JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):
+        * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
+        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
+        * bytecode/ObjectPropertyCondition.cpp:
+        (JSC::ObjectPropertyCondition::dumpInContext const):
+        * bytecode/StructureStubClearingWatchpoint.cpp:
+        (JSC::StructureStubClearingWatchpoint::fireInternal):
+        * dfg/DFGAdaptiveStructureWatchpoint.cpp:
+        (JSC::DFG::AdaptiveStructureWatchpoint::fireInternal):
+        * runtime/StructureRareData.cpp:
+        (JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
+
+2019-03-23  Keith Miller  <keith_miller@apple.com>
+
+        Refactor clz/ctz and fix getLSBSet.
+        https://bugs.webkit.org/show_bug.cgi?id=196162
+
+        Reviewed by Saam Barati.
+
+        Refactor references of clz32/64 and ctz32 to use clz and ctz,
+        respectively.
+
+        * dfg/DFGAbstractInterpreterInlines.h:
+        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+        * dfg/DFGOperations.cpp:
+        * runtime/JSBigInt.cpp:
+        (JSC::JSBigInt::digitDiv):
+        (JSC::JSBigInt::absoluteDivWithBigIntDivisor):
+        (JSC::JSBigInt::calculateMaximumCharactersRequired):
+        (JSC::JSBigInt::toStringBasePowerOfTwo):
+        (JSC::JSBigInt::compareToDouble):
+        * runtime/MathObject.cpp:
+        (JSC::mathProtoFuncClz32):
+
+2019-03-23  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Shrink sizeof(RegExp)
+        https://bugs.webkit.org/show_bug.cgi?id=196133
+
+        Reviewed by Mark Lam.
+
+        Some applications have many RegExp cells. But RegExp cells are very large (144B).
+        This patch reduces the size from 144B to 48B by,
+
+        1. Allocate Yarr::YarrCodeBlock in non-GC heap. We can avoid this allocation if JIT is disabled.
+        2. m_captureGroupNames and m_namedGroupToParenIndex are moved to RareData. They are only used when RegExp has named capture groups.
+
+        * runtime/RegExp.cpp:
+        (JSC::RegExp::finishCreation):
+        (JSC::RegExp::estimatedSize):
+        (JSC::RegExp::compile):
+        (JSC::RegExp::matchConcurrently):
+        (JSC::RegExp::compileMatchOnly):
+        (JSC::RegExp::deleteCode):
+        (JSC::RegExp::printTraceData):
+        * runtime/RegExp.h:
+        * runtime/RegExpInlines.h:
+        (JSC::RegExp::hasCodeFor):
+        (JSC::RegExp::matchInline):
+        (JSC::RegExp::hasMatchOnlyCodeFor):
+
+2019-03-22  Keith Rollin  <krollin@apple.com>
+
+        Enable ThinLTO support in Production builds
+        https://bugs.webkit.org/show_bug.cgi?id=190758
+        <rdar://problem/45413233>
+
+        Reviewed by Daniel Bates.
+
+        Tweak JavaScriptCore's Base.xcconfig to be more in-line with other
+        .xcconfig files with regards to LTO settings. However, don't actually
+        enable LTO for JavaScriptCore. LTO is not enabled for JavaScriptCore
+        due to <rdar://problem/24543547>.
+
+        * Configurations/Base.xcconfig:
+
+2019-03-22  Mark Lam  <mark.lam@apple.com>
+
+        Placate exception check validation in genericTypedArrayViewProtoFuncLastIndexOf().
+        https://bugs.webkit.org/show_bug.cgi?id=196154
+        <rdar://problem/49145307>
+
+        Reviewed by Filip Pizlo.
+
+        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
+        (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
+
+2019-03-22  Mark Lam  <mark.lam@apple.com>
+
+        Placate exception check validation in constructJSWebAssemblyLinkError().
+        https://bugs.webkit.org/show_bug.cgi?id=196152
+        <rdar://problem/49145257>
+
+        Reviewed by Michael Saboff.
+
+        * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
+        (JSC::constructJSWebAssemblyLinkError):
+
+2019-03-22  Timothy Hatcher  <timothy@apple.com>
+
+        Change macosx() to macos() in WK_API... and JSC_API... macros.
+        https://bugs.webkit.org/show_bug.cgi?id=196106
+
+        Reviewed by Brian Burg.
+
+        * API/JSBasePrivate.h:
+        * API/JSContext.h:
+        * API/JSContextPrivate.h:
+        * API/JSContextRef.h:
+        * API/JSContextRefInternal.h:
+        * API/JSContextRefPrivate.h:
+        * API/JSManagedValue.h:
+        * API/JSObjectRef.h:
+        * API/JSObjectRefPrivate.h:
+        * API/JSRemoteInspector.h:
+        * API/JSScript.h:
+        * API/JSTypedArray.h:
+        * API/JSValue.h:
+        * API/JSValuePrivate.h:
+        * API/JSValueRef.h:
+        * API/JSVirtualMachinePrivate.h:
+
+2019-03-22  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        Unreviewed, build fix for Windows
+        https://bugs.webkit.org/show_bug.cgi?id=196122
+
+        * runtime/FunctionExecutable.cpp:
+
+2019-03-21  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Shrink sizeof(FunctionExecutable) by 16bytes
+        https://bugs.webkit.org/show_bug.cgi?id=196122
+
+        Reviewed by Saam Barati.
+
+        This patch reduces sizeof(FunctionExecutable) by 16 bytes.
+
+        1. ScriptExecutable::m_numParametersForCall and ScriptExecutable::m_numParametersForConstruct are not used in a meaningful way. Removed them.
+        2. ScriptExecutable::m_lastLine and ScriptExecutable::m_endColumn can be calculated from UnlinkedFunctionExecutable. So FunctionExecutable does not need to hold it.
+           This patch adds GlobalExecutable, which are non-function ScriptExecutables, and move m_lastLine and m_endColumn to this class.
+        3. FunctionExecutable still needs to have the feature overriding m_lastLine and m_endColumn. We move overridden data in FunctionExecutable::RareData.
+
+        * CMakeLists.txt:
+        * JavaScriptCore.xcodeproj/project.pbxproj:
+        * Sources.txt:
+        * bytecode/UnlinkedFunctionExecutable.cpp:
+        (JSC::UnlinkedFunctionExecutable::link):
+        * runtime/EvalExecutable.cpp:
+        (JSC::EvalExecutable::EvalExecutable):
+        * runtime/EvalExecutable.h:
+        * runtime/FunctionExecutable.cpp:
+        (JSC::FunctionExecutable::FunctionExecutable):
+        (JSC::FunctionExecutable::ensureRareDataSlow):
+        (JSC::FunctionExecutable::overrideInfo):
+        * runtime/FunctionExecutable.h:
+        * runtime/GlobalExecutable.cpp: Copied from Source/JavaScriptCore/tools/FunctionOverrides.h.
+        * runtime/GlobalExecutable.h: Copied from Source/JavaScriptCore/tools/FunctionOverrides.h.
+        (JSC::GlobalExecutable::lastLine const):
+        (JSC::GlobalExecutable::endColumn const):
+        (JSC::GlobalExecutable::recordParse):
+        (JSC::GlobalExecutable::GlobalExecutable):
+        * runtime/ModuleProgramExecutable.cpp:
+        (JSC::ModuleProgramExecutable::ModuleProgramExecutable):
+        * runtime/ModuleProgramExecutable.h:
+        * runtime/ProgramExecutable.cpp:
+        (JSC::ProgramExecutable::ProgramExecutable):
+        * runtime/ProgramExecutable.h:
+        * runtime/ScriptExecutable.cpp:
+        (JSC::ScriptExecutable::clearCode):
+        (JSC::ScriptExecutable::installCode):
+        (JSC::ScriptExecutable::hasClearableCode const):
+        (JSC::ScriptExecutable::newCodeBlockFor):
+        (JSC::ScriptExecutable::typeProfilingEndOffset const):
+        (JSC::ScriptExecutable::recordParse):
+        (JSC::ScriptExecutable::lastLine const):
+        (JSC::ScriptExecutable::endColumn const):
+        * runtime/ScriptExecutable.h:
+        (JSC::ScriptExecutable::hasJITCodeForCall const):
+        (JSC::ScriptExecutable::hasJITCodeForConstruct const):
+        (JSC::ScriptExecutable::recordParse):
+        (JSC::ScriptExecutable::lastLine const): Deleted.
+        (JSC::ScriptExecutable::endColumn const): Deleted.
+        * tools/FunctionOverrides.h:
+
+2019-03-21  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Shrink sizeof(RegExpObject)
+        https://bugs.webkit.org/show_bug.cgi?id=196130
+
+        Reviewed by Saam Barati.
+
+        sizeof(RegExpObject) is 48B due to one bool flag. We should compress this flag into lower bit of RegExp* field so that we can make RegExpObject 32B.
+        It saves memory footprint 1.3% in RAMification's regexp.
+
+        * dfg/DFGSpeculativeJIT.cpp:
+        (JSC::DFG::SpeculativeJIT::compileNewRegexp):
+        (JSC::DFG::SpeculativeJIT::compileSetRegExpObjectLastIndex):
+        * ftl/FTLAbstractHeapRepository.h:
+        * ftl/FTLLowerDFGToB3.cpp:
+        (JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp):
+        (JSC::FTL::DFG::LowerDFGToB3::compileSetRegExpObjectLastIndex):
+        * runtime/RegExpObject.cpp:
+        (JSC::RegExpObject::RegExpObject):
+        (JSC::RegExpObject::visitChildren):
+        (JSC::RegExpObject::getOwnPropertySlot):
+        (JSC::RegExpObject::defineOwnProperty):
+        * runtime/RegExpObject.h:
+
+2019-03-21  Tomas Popela  <tpopela@redhat.com>
+
+        [JSC] Fix build after r243232 on unsupported 64bit architectures
+        https://bugs.webkit.org/show_bug.cgi?id=196072
+
+        Reviewed by Keith Miller.
+
+        As Keith suggested we already expect 16 free bits at the top of any
+        pointer for JSValue even for the unsupported 64 bit arches.
+
+        * bytecode/CodeOrigin.h:
+
+2019-03-21  Mark Lam  <mark.lam@apple.com>
+
+        Remove an invalid assertion in DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined().
+        https://bugs.webkit.org/show_bug.cgi?id=196116
+        <rdar://problem/48976951>
+
+        Reviewed by Filip Pizlo.
+
+        The DFG backend should not make assumptions about what optimizations the front end
+        will or will not do.  The assertion asserts that the operand cannot be known to be
+        a cell.  However, it is not guaranteed that the front end will fold away this case.
+        Also, the DFG backend is perfectly capable of generating code to handle the case
+        where the operand is a cell.
+
+        The attached test case demonstrates a case where the operand can be a known cell.
+        The test needs to be run with the concurrent JIT and GC, and is racy.  It used to
+        trip up this assertion about once every 10 runs or so.
+
+        * dfg/DFGSpeculativeJIT64.cpp:
+        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined):
+
+2019-03-21  Tadeu Zagallo  <tzagallo@apple.com>
+
+        JSC::createError should clear exception thrown by errorDescriptionForValue
+        https://bugs.webkit.org/show_bug.cgi?id=196089
+
+        Reviewed by Mark Lam.
+
+        errorDescriptionForValue returns a nullString in case of failure, but it
+        might also throw an OOM exception when resolving a rope string. We need
+        to clear any potential exceptions thrown by errorDescriptionForValue
+        before returning the OOM from JSC::createError.
+
+        * runtime/ExceptionHelpers.cpp:
+        (JSC::createError):
+
+2019-03-21  Robin Morisset  <rmorisset@apple.com>
+
+        B3::Opcode can fit in a single byte, shrinking B3Value by 8 bytes
+        https://bugs.webkit.org/show_bug.cgi?id=196014
+
+        Reviewed by Keith Miller.
+
+        B3::Opcode has less than one hundred cases, so it can easily fit in one byte (from two currently)
+        This shrinks B3::Kind from 4 bytes to 2 (by removing the byte of padding at the end).
+        This in turns eliminate padding from B3::Value, shrinking it by 8 bytes (out of 80).
+
+        * b3/B3Opcode.h:
+
+2019-03-21  Michael Catanzaro  <mcatanzaro@igalia.com>
+
+        Unreviewed, more clang 3.8 build fixes
+        https://bugs.webkit.org/show_bug.cgi?id=195947
+        <rdar://problem/49069219>
+
+        In the spirit of making our code worse to please old compilers....
+
+        * bindings/ScriptValue.cpp:
+        (Inspector::jsToInspectorValue):
+        * bytecode/GetterSetterAccessCase.cpp:
+        (JSC::GetterSetterAccessCase::create):
+        (JSC::GetterSetterAccessCase::clone const):
+        * bytecode/InstanceOfAccessCase.cpp:
+        (JSC::InstanceOfAccessCase::clone const):
+        * bytecode/IntrinsicGetterAccessCase.cpp:
+        (JSC::IntrinsicGetterAccessCase::clone const):
+        * bytecode/ModuleNamespaceAccessCase.cpp:
+        (JSC::ModuleNamespaceAccessCase::clone const):
+        * bytecode/ProxyableAccessCase.cpp:
+        (JSC::ProxyableAccessCase::clone const):
+
+2019-03-21  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Do not create JIT related data under non-JIT mode
+        https://bugs.webkit.org/show_bug.cgi?id=195982
+
+        Reviewed by Mark Lam.
+
+        We avoid creations of JIT related data structures under non-JIT mode.
+        This patch removes the following allocations.
+
+        1. JITThunks
+        2. FTLThunks
+        3. FixedVMPoolExecutableAllocator
+        4. noJITValueProfileSingleton since it is no longer used
+        5. ARM disassembler should be initialized when it is used
+        6. Wasm related data structures are accidentally allocated if VM::canUseJIT() == false &&
+           Options::useWebAssembly() == true. Add Wasm::isSupported() function to check the both conditions.
+
+        * CMakeLists.txt:
+        * JavaScriptCore.xcodeproj/project.pbxproj:
+        * heap/Heap.cpp:
+        (JSC::Heap::runEndPhase):
+        * jit/ExecutableAllocator.cpp:
+        (JSC::FixedVMPoolExecutableAllocator::~FixedVMPoolExecutableAllocator):
+        (JSC::ExecutableAllocator::initializeUnderlyingAllocator):
+        (JSC::ExecutableAllocator::isValid const):
+        (JSC::ExecutableAllocator::underMemoryPressure):
+        (JSC::ExecutableAllocator::memoryPressureMultiplier):
+        (JSC::ExecutableAllocator::allocate):
+        (JSC::ExecutableAllocator::isValidExecutableMemory):
+        (JSC::ExecutableAllocator::getLock const):
+        (JSC::ExecutableAllocator::committedByteCount):
+        (JSC::ExecutableAllocator::dumpProfile):
+        (JSC::startOfFixedExecutableMemoryPoolImpl):
+        (JSC::endOfFixedExecutableMemoryPoolImpl):
+        (JSC::ExecutableAllocator::initialize):
+        (JSC::ExecutableAllocator::initializeAllocator): Deleted.
+        (JSC::ExecutableAllocator::ExecutableAllocator): Deleted.
+        (JSC::ExecutableAllocator::~ExecutableAllocator): Deleted.
+        * jit/ExecutableAllocator.h:
+        (JSC::ExecutableAllocatorBase::isValid const):
+        (JSC::ExecutableAllocatorBase::underMemoryPressure):
+        (JSC::ExecutableAllocatorBase::memoryPressureMultiplier):
+        (JSC::ExecutableAllocatorBase::dumpProfile):
+        (JSC::ExecutableAllocatorBase::allocate):
+        (JSC::ExecutableAllocatorBase::setJITEnabled):
+        (JSC::ExecutableAllocatorBase::isValidExecutableMemory):
+        (JSC::ExecutableAllocatorBase::committedByteCount):
+        (JSC::ExecutableAllocatorBase::getLock const):
+        (JSC::ExecutableAllocator::isValid const): Deleted.
+        (JSC::ExecutableAllocator::underMemoryPressure): Deleted.
+        (JSC::ExecutableAllocator::memoryPressureMultiplier): Deleted.
+        (JSC::ExecutableAllocator::allocate): Deleted.
+        (JSC::ExecutableAllocator::setJITEnabled): Deleted.
+        (JSC::ExecutableAllocator::isValidExecutableMemory): Deleted.
+        (JSC::ExecutableAllocator::committedByteCount): Deleted.
+        (JSC::ExecutableAllocator::getLock const): Deleted.
+        * jsc.cpp:
+        (functionWebAssemblyMemoryMode):
+        * runtime/InitializeThreading.cpp:
+        (JSC::initializeThreading):
+        * runtime/JSGlobalObject.cpp:
+        (JSC::JSGlobalObject::init):
+        * runtime/JSLock.cpp:
+        (JSC::JSLock::didAcquireLock):
+        * runtime/Options.cpp:
+        (JSC::recomputeDependentOptions):
+        * runtime/VM.cpp:
+        (JSC::enableAssembler):
+        (JSC::VM::canUseAssembler):
+        (JSC::VM::VM):
+        * runtime/VM.h:
+        * wasm/WasmCapabilities.h: Added.
+        (JSC::Wasm::isSupported):
+        * wasm/WasmFaultSignalHandler.cpp:
+        (JSC::Wasm::enableFastMemory):
+
+2019-03-21  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Fix JSC build with newer ICU
+        https://bugs.webkit.org/show_bug.cgi?id=196098
+
+        Reviewed by Keith Miller.
+
+        IntlDateTimeFormat and IntlNumberFormat have switch statement over ICU's enums. However it lacks "default" clause so that
+        the compile error occurs when a new enum value is added in ICU side. We should have "default" clause which just fallbacks
+        "unknown"_s case. The behavior is not changed since we already have `return "unknown"_s;` statement anyway after the
+        switch statement. This patch just suppresses a compile error.
+
+        * runtime/IntlDateTimeFormat.cpp:
+        (JSC::IntlDateTimeFormat::partTypeString):
+        * runtime/IntlNumberFormat.cpp:
+        (JSC::IntlNumberFormat::partTypeString):
+
+2019-03-21  Tadeu Zagallo  <tzagallo@apple.com>
+
+        JSObject::putDirectIndexSlowOrBeyondVectorLength should check if indexIsSufficientlyBeyondLengthForSparseMap
+        https://bugs.webkit.org/show_bug.cgi?id=196078
+        <rdar://problem/35925380>
+
+        Reviewed by Mark Lam.
+
+        Unlike the other variations of putByIndex, it only checked if the index
+        was larger than MIN_SPARSE_ARRAY_INDEX when the indexingType was
+        ALL_BLANK_INDEXING_TYPES. This resulted in a huge butterfly being
+        allocated for object literals (e.g. `{[9e4]: ...}`) and objects parsed
+        from JSON.
+
+        * runtime/JSObject.cpp:
+        (JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength):
+
+2019-03-21  Tadeu Zagallo  <tzagallo@apple.com>
+
+        CachedUnlinkedSourceCodeShape::m_provider should be a CachedRefPtr
+        https://bugs.webkit.org/show_bug.cgi?id=196079
+
+        Reviewed by Saam Barati.
+
+        It was mistakenly cached as CachedPtr, which was leaking the decoded SourceProvider.
+
+        * runtime/CachedTypes.cpp:
+        (JSC::CachedUnlinkedSourceCodeShape::encode):
+
+2019-03-21  Mark Lam  <mark.lam@apple.com>
+
+        Placate exception check validation in operationArrayIndexOfString().
+        https://bugs.webkit.org/show_bug.cgi?id=196067
+        <rdar://problem/49056572>
+
+        Reviewed by Michael Saboff.
+
+        * dfg/DFGOperations.cpp:
+
+2019-03-21  Xan Lopez  <xan@igalia.com>
+
+        [JSC][x86] Drop support for x87 floating point
+        https://bugs.webkit.org/show_bug.cgi?id=194853
+
+        Reviewed by Don Olmstead.
+
+        Require SSE2 throughout the codebase, and remove x87 support where
+        it was optionally available. SSE2 detection happens at compile
+        time through a static_assert.
+
+        * assembler/MacroAssemblerX86.h:
+        (JSC::MacroAssemblerX86::storeDouble):
+        (JSC::MacroAssemblerX86::moveDoubleToInts):
+        (JSC::MacroAssemblerX86::supportsFloatingPoint):
+        (JSC::MacroAssemblerX86::supportsFloatingPointTruncate):
+        (JSC::MacroAssemblerX86::supportsFloatingPointSqrt):
+        (JSC::MacroAssemblerX86::supportsFloatingPointAbs):
+        * assembler/MacroAssemblerX86Common.cpp:
+        * assembler/MacroAssemblerX86Common.h:
+        (JSC::MacroAssemblerX86Common::moveDouble):
+        (JSC::MacroAssemblerX86Common::loadDouble):
+        (JSC::MacroAssemblerX86Common::loadFloat):
+        (JSC::MacroAssemblerX86Common::storeDouble):
+        (JSC::MacroAssemblerX86Common::storeFloat):
+        (JSC::MacroAssemblerX86Common::convertDoubleToFloat):
+        (JSC::MacroAssemblerX86Common::convertFloatToDouble):
+        (JSC::MacroAssemblerX86Common::addDouble):
+        (JSC::MacroAssemblerX86Common::addFloat):
+        (JSC::MacroAssemblerX86Common::divDouble):
+        (JSC::MacroAssemblerX86Common::divFloat):
+        (JSC::MacroAssemblerX86Common::subDouble):
+        (JSC::MacroAssemblerX86Common::subFloat):
+        (JSC::MacroAssemblerX86Common::mulDouble):
+        (JSC::MacroAssemblerX86Common::mulFloat):
+        (JSC::MacroAssemblerX86Common::convertInt32ToDouble):
+        (JSC::MacroAssemblerX86Common::convertInt32ToFloat):
+        (JSC::MacroAssemblerX86Common::branchDouble):
+        (JSC::MacroAssemblerX86Common::branchFloat):
+        (JSC::MacroAssemblerX86Common::compareDouble):
+        (JSC::MacroAssemblerX86Common::compareFloat):
+        (JSC::MacroAssemblerX86Common::branchTruncateDoubleToInt32):
+        (JSC::MacroAssemblerX86Common::truncateDoubleToInt32):
+        (JSC::MacroAssemblerX86Common::truncateFloatToInt32):
+        (JSC::MacroAssemblerX86Common::branchConvertDoubleToInt32):
+        (JSC::MacroAssemblerX86Common::branchDoubleNonZero):
+        (JSC::MacroAssemblerX86Common::branchDoubleZeroOrNaN):
+        (JSC::MacroAssemblerX86Common::lshiftPacked):
+        (JSC::MacroAssemblerX86Common::rshiftPacked):
+        (JSC::MacroAssemblerX86Common::orPacked):
+        (JSC::MacroAssemblerX86Common::move32ToFloat):
+        (JSC::MacroAssemblerX86Common::moveFloatTo32):
+        (JSC::MacroAssemblerX86Common::moveConditionallyDouble):
+        (JSC::MacroAssemblerX86Common::moveConditionallyFloat):
+        * offlineasm/x86.rb:
+        * runtime/MathCommon.cpp:
+        (JSC::operationMathPow):
+
+2019-03-21  Carlos Garcia Campos  <cgarcia@igalia.com>
+
+        [GLIB] User data not correctly passed to callback of functions and constructors with no parameters
+        https://bugs.webkit.org/show_bug.cgi?id=196073
+
+        Reviewed by Michael Catanzaro.
+
+        This is because GClosure always expects a first parameter as instance. In case of functions or constructors with
+        no parameters we insert a fake instance which is just a null pointer that is ignored by the callback. But
+        if the function/constructor has user data the callback will expect one parameter for the user data. In that case
+        we can simply swap instance/user data so that the fake instance will be the second argument and user data the
+        first one.
+
+        * API/glib/JSCClass.cpp:
+        (jscClassCreateConstructor): Use g_cclosure_new_swap() if parameters is empty and user data was provided.
+        * API/glib/JSCValue.cpp:
+        (jscValueFunctionCreate): Ditto.
+
+2019-03-21  Pablo Saavedra  <psaavedra@igalia.com>
+
+        [JSC][32-bit] Build failure after r243232
+        https://bugs.webkit.org/show_bug.cgi?id=196068
+
+        Reviewed by Mark Lam.
+
+        * dfg/DFGOSRExit.cpp:
+        (JSC::DFG::reifyInlinedCallFrames):
+        * dfg/DFGOSRExitCompilerCommon.cpp:
+        (JSC::DFG::reifyInlinedCallFrames):
+
+2019-03-21  Carlos Garcia Campos  <cgarcia@igalia.com>
+
+        [GLib] Returning G_TYPE_OBJECT from a method does not work
+        https://bugs.webkit.org/show_bug.cgi?id=195574
+
+        Reviewed by Michael Catanzaro.
+
+        Add more documentation to clarify the ownership of wrapped objects when created and when returned by functions.
+
+        * API/glib/JSCCallbackFunction.cpp:
+        (JSC::JSCCallbackFunction::construct): Also allow to return boxed types from a constructor.
+        * API/glib/JSCClass.cpp:
+        * API/glib/JSCValue.cpp:
+
+2019-03-21  Mark Lam  <mark.lam@apple.com>
+
+        Cap length of an array with spread to MIN_ARRAY_STORAGE_CONSTRUCTION_LENGTH.
+        https://bugs.webkit.org/show_bug.cgi?id=196055
+        <rdar://problem/49067448>
+
+        Reviewed by Yusuke Suzuki.
+
+        We are doing this because:
+        1. We expect the array to be densely packed.
+        2. SpeculativeJIT::compileAllocateNewArrayWithSize() (and the FTL equivalent)
+           expects the array length to be less than MIN_ARRAY_STORAGE_CONSTRUCTION_LENGTH
+           if we don't want to use an ArrayStorage shape.
+        3. There's no reason why an array with spread needs to be that large anyway.
+           MIN_ARRAY_STORAGE_CONSTRUCTION_LENGTH is plenty.
+
+        In this patch, we also add a debug assert in compileAllocateNewArrayWithSize() and
+        emitAllocateButterfly() to check for overflows.
+
+        * assembler/AbortReason.h:
+        * dfg/DFGOperations.cpp:
+        * dfg/DFGSpeculativeJIT.cpp:
+        (JSC::DFG::SpeculativeJIT::compileCreateRest):
+        (JSC::DFG::SpeculativeJIT::compileNewArrayWithSpread):
+        (JSC::DFG::SpeculativeJIT::emitAllocateButterfly):
+        (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
+        * ftl/FTLLowerDFGToB3.cpp:
+        (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread):
+        * runtime/ArrayConventions.h:
+        * runtime/CommonSlowPaths.cpp:
+        (JSC::SLOW_PATH_DECL):
+
+2019-03-20  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Use finalizer in JSGlobalLexicalEnvironment and JSGlobalObject
+        https://bugs.webkit.org/show_bug.cgi?id=195992
+
+        Reviewed by Keith Miller and Mark Lam.
+
+        JSGlobalLexicalEnvironment and JSGlobalObject have their own CompleteSubspace to call destructors while they are not inheriting JSDestructibleObject.
+        But it is too costly since (1) it requires CompleteSubspace in VM, (2) both objects allocate MarkedBlocks while # of them are really small.
+
+        Instead of using CompleteSubspace, we just set finalizers for them. Since these objects are rarely allocated, setting finalizers does not show
+        memory / performance problems (actually, previously we used finalizer for ArrayPrototype due to the same reason, and it does not show any problems).
+
+        And we also add following two changes to JSSegmentedVariableObject.
+
+        1. Remove one boolean used for debugging in Release build. It enlarges sizeof(JSSegmentedVariableObject) and allocates one more MarkedBlock.
+        2. Use cellLock() instead.
+
+        * CMakeLists.txt:
+        * JavaScriptCore.xcodeproj/project.pbxproj:
+        * Sources.txt:
+        * runtime/JSSegmentedVariableObject.cpp:
+        (JSC::JSSegmentedVariableObject::findVariableIndex):
+        (JSC::JSSegmentedVariableObject::addVariables):
+        (JSC::JSSegmentedVariableObject::visitChildren):
+        (JSC::JSSegmentedVariableObject::~JSSegmentedVariableObject):
+        (JSC::JSSegmentedVariableObject::finishCreation):
+        * runtime/JSSegmentedVariableObject.h:
+        (JSC::JSSegmentedVariableObject::subspaceFor): Deleted.
+        * runtime/JSSegmentedVariableObjectHeapCellType.cpp: Removed.
+        * runtime/JSSegmentedVariableObjectHeapCellType.h: Removed.
+        * runtime/StringIteratorPrototype.cpp:
+        * runtime/VM.cpp:
+        (JSC::VM::VM):
+        * runtime/VM.h:
+
+2019-03-20  Saam Barati  <sbarati@apple.com>
+
+        DFG::AbstractValue::validateOSREntry is wrong when isHeapTop and the incoming value is Empty
+        https://bugs.webkit.org/show_bug.cgi?id=195721
+
+        Reviewed by Filip Pizlo.
+
+        There was a check in AbstractValue::validateOSREntry where it checked
+        if isHeapTop(), and if so, just returned true. However, this is wrong
+        if the value we're checking against is the empty value, since HeapTop
+        does not include the Empty value. Instead, this check should be
+        isBytecodeTop(), which does account for the empty value.
+        
+        This patch also does a couple of other things:
+        - For our OSR entry AbstractValues, we were using HeapTop to mark
+         a dead value. That is now changed to BytecodeTop. (The idea here
+         is just to have validateOSREntry return early.)
+        - It wasn't obvious to me how I could make this fail in JS code.
+         The symptom we'd end up seeing is something like a nullptr derefernece
+         from forgetting to do a TDZ check. Instead, I've added a unit test.
+         This unit test lives in a new test file: testdfg. testdfg is similar
+         to testb3/testair/testapi.
+
+        * JavaScriptCore.xcodeproj/project.pbxproj:
+        * bytecode/SpeculatedType.h:
+        * dfg/DFGAbstractValue.h:
+        (JSC::DFG::AbstractValue::isBytecodeTop const):
+        (JSC::DFG::AbstractValue::validateOSREntryValue const):
+        * dfg/testdfg.cpp: Added.
+        (hiddenTruthBecauseNoReturnIsStupid):
+        (usage):
+        (JSC::DFG::testEmptyValueDoesNotValidateWithHeapTop):
+        (JSC::DFG::run):
+        (run):
+        (main):
+        * shell/CMakeLists.txt:
+
+2019-03-20  Saam Barati  <sbarati@apple.com>
+
+        typeOfDoubleSum is wrong for when NaN can be produced
+        https://bugs.webkit.org/show_bug.cgi?id=196030
+
+        Reviewed by Filip Pizlo.
+
+        We were using typeOfDoubleSum(SpeculatedType, SpeculatedType) for add/sub/mul.
+        It assumed that the only way the resulting type could be NaN is if one of
+        the inputs were NaN. However, this is wrong. NaN can be produced in at least
+        these cases:
+          Infinity - Infinity
+          Infinity + (-Infinity)
+          Infinity * 0
+
+        * bytecode/SpeculatedType.cpp:
+        (JSC::typeOfDoubleSumOrDifferenceOrProduct):
+        (JSC::typeOfDoubleSum):
+        (JSC::typeOfDoubleDifference):
+        (JSC::typeOfDoubleProduct):
+
+2019-03-20  Simon Fraser  <simon.fraser@apple.com>
+
+        Rename ENABLE_ACCELERATED_OVERFLOW_SCROLLING macro to ENABLE_OVERFLOW_SCROLLING_TOUCH
+        https://bugs.webkit.org/show_bug.cgi?id=196049
+
+        Reviewed by Tim Horton.
+
+        This macro is about the -webkit-overflow-scrolling CSS property, not accelerated
+        overflow scrolling in general, so rename it.
+
+        * Configurations/FeatureDefines.xcconfig:
+
+2019-03-20  Saam Barati  <sbarati@apple.com>
+
+        GetCallee does not report the correct type in AI
+        https://bugs.webkit.org/show_bug.cgi?id=195981
+
+        Reviewed by Yusuke Suzuki.
+
+        I found this as part of my work in:
+        https://bugs.webkit.org/show_bug.cgi?id=195924
+        
+        I'm not sure how to write a test for it.
+        
+        GetCallee was always reporting that the result is SpecFunction. However,
+        for eval, it may result in just a JSCallee object, which is not a JSFunction.
+
+        * dfg/DFGAbstractInterpreterInlines.h:
+        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+
+2019-03-20  Mark Lam  <mark.lam@apple.com>
+
+        Open source arm64e code.
+        https://bugs.webkit.org/show_bug.cgi?id=196012
+        <rdar://problem/49066237>
+
+        Reviewed by Keith Miller.
+
+        * JavaScriptCore.xcodeproj/project.pbxproj:
+        * Sources.txt:
+        * assembler/ARM64EAssembler.h: Added.
+        (JSC::ARM64EAssembler::encodeGroup1):
+        (JSC::ARM64EAssembler::encodeGroup2):
+        (JSC::ARM64EAssembler::encodeGroup4):
+        (JSC::ARM64EAssembler::pacia1716):
+        (JSC::ARM64EAssembler::pacib1716):
+        (JSC::ARM64EAssembler::autia1716):
+        (JSC::ARM64EAssembler::autib1716):
+        (JSC::ARM64EAssembler::paciaz):
+        (JSC::ARM64EAssembler::paciasp):
+        (JSC::ARM64EAssembler::pacibz):
+        (JSC::ARM64EAssembler::pacibsp):
+        (JSC::ARM64EAssembler::autiaz):
+        (JSC::ARM64EAssembler::autiasp):
+        (JSC::ARM64EAssembler::autibz):
+        (JSC::ARM64EAssembler::autibsp):
+        (JSC::ARM64EAssembler::xpaclri):
+        (JSC::ARM64EAssembler::pacia):
+        (JSC::ARM64EAssembler::pacib):
+        (JSC::ARM64EAssembler::pacda):
+        (JSC::ARM64EAssembler::pacdb):
+        (JSC::ARM64EAssembler::autia):
+        (JSC::ARM64EAssembler::autib):
+        (JSC::ARM64EAssembler::autda):
+        (JSC::ARM64EAssembler::autdb):
+        (JSC::ARM64EAssembler::paciza):
+        (JSC::ARM64EAssembler::pacizb):
+        (JSC::ARM64EAssembler::pacdza):
+        (JSC::ARM64EAssembler::pacdzb):
+        (JSC::ARM64EAssembler::autiza):
+        (JSC::ARM64EAssembler::autizb):
+        (JSC::ARM64EAssembler::autdza):
+        (JSC::ARM64EAssembler::autdzb):
+        (JSC::ARM64EAssembler::xpaci):
+        (JSC::ARM64EAssembler::xpacd):
+        (JSC::ARM64EAssembler::pacga):
+        (JSC::ARM64EAssembler::braa):
+        (JSC::ARM64EAssembler::brab):
+        (JSC::ARM64EAssembler::blraa):
+        (JSC::ARM64EAssembler::blrab):
+        (JSC::ARM64EAssembler::braaz):
+        (JSC::ARM64EAssembler::brabz):
+        (JSC::ARM64EAssembler::blraaz):
+        (JSC::ARM64EAssembler::blrabz):
+        (JSC::ARM64EAssembler::retaa):
+        (JSC::ARM64EAssembler::retab):
+        (JSC::ARM64EAssembler::eretaa):
+        (JSC::ARM64EAssembler::eretab):
+        (JSC::ARM64EAssembler::linkPointer):
+        (JSC::ARM64EAssembler::repatchPointer):
+        (JSC::ARM64EAssembler::setPointer):
+        (JSC::ARM64EAssembler::readPointer):
+        (JSC::ARM64EAssembler::readCallTarget):
+        (JSC::ARM64EAssembler::ret):
+        * assembler/MacroAssembler.cpp:
+        * assembler/MacroAssembler.h:
+        * assembler/MacroAssemblerARM64.cpp:
+        * assembler/MacroAssemblerARM64E.h: Added.
+        (JSC::MacroAssemblerARM64E::tagReturnAddress):
+        (JSC::MacroAssemblerARM64E::untagReturnAddress):
+        (JSC::MacroAssemblerARM64E::tagPtr):
+        (JSC::MacroAssemblerARM64E::untagPtr):
+        (JSC::MacroAssemblerARM64E::removePtrTag):
+        (JSC::MacroAssemblerARM64E::callTrustedPtr):
+        (JSC::MacroAssemblerARM64E::call):
+        (JSC::MacroAssemblerARM64E::callRegister):
+        (JSC::MacroAssemblerARM64E::jump):
+        * dfg/DFGOSRExit.cpp:
+        (JSC::DFG::reifyInlinedCallFrames):
+        * 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/ExecutableAllocator.cpp:
+        (JSC::ExecutableAllocator::allocate):
+        * jit/ThunkGenerators.cpp:
+        (JSC::arityFixupGenerator):
+        * llint/LLIntOfflineAsmConfig.h:
+        * llint/LowLevelInterpreter.asm:
+        * llint/LowLevelInterpreter64.asm:
+        * runtime/ClassInfo.h:
+        * runtime/InitializeThreading.cpp:
+        (JSC::initializeThreading):
+        * runtime/JSCPtrTag.cpp: Added.
+        (JSC::tagForPtr):
+        (JSC::ptrTagName):
+        (JSC::initializePtrTagLookup):
+        * runtime/JSCPtrTag.h:
+        (JSC::initializePtrTagLookup):
+        * runtime/Options.cpp:
+        (JSC::recomputeDependentOptions):
+
+2019-03-20  Tadeu Zagallo  <tzagallo@apple.com>
+
+        JSC::createError needs to check for OOM in errorDescriptionForValue
+        https://bugs.webkit.org/show_bug.cgi?id=196032
+        <rdar://problem/46842740>
+
+        Reviewed by Mark Lam.
+
+        We were missing exceptions checks at two levels:
+        - In errorDescriptionForValue, when the value is a string, we should
+          check that JSString::value returns a valid string, since we might run
+          out of memory if it is a rope and we need to resolve it.
+        - In createError, we should check for the result of errorDescriptionForValue
+          before concatenating it with the message provided by the caller.
+
+        * runtime/ExceptionHelpers.cpp:
+        (JSC::errorDescriptionForValue):
+        (JSC::createError):
+        * runtime/ExceptionHelpers.h:
+
+2019-03-20  Devin Rousso  <drousso@apple.com>
+
+        Web Inspector: DOM: include window as part of any event listener chain
+        https://bugs.webkit.org/show_bug.cgi?id=195730
+        <rdar://problem/48916872>
+
+        Reviewed by Timothy Hatcher.
+
+        * inspector/protocol/DOM.json:
+        Modify `DOM.getEventListenersForNode` to not save the handler object, as that was never
+        used by the frontend. Add an `onWindow` optional property to `DOM.EventListener` that is set
+        when the event listener was retrieved from the `window` object.
+
+2019-03-20  Devin Rousso  <drousso@apple.com>
+
+        Web Inspector: Runtime: lazily create the agent
+        https://bugs.webkit.org/show_bug.cgi?id=195972
+        <rdar://problem/49039655>
+
+        Reviewed by Timothy Hatcher.
+
+        * inspector/JSGlobalObjectInspectorController.cpp:
+        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
+        (Inspector::JSGlobalObjectInspectorController::createLazyAgents):
+
+        * inspector/agents/InspectorRuntimeAgent.h:
+        (Inspector::InspectorRuntimeAgent::enabled): Deleted.
+        * inspector/agents/InspectorRuntimeAgent.cpp:
+        (Inspector::InspectorRuntimeAgent::didCreateFrontendAndBackend): Added.
+        (Inspector::InspectorRuntimeAgent::willDestroyFrontendAndBackend):
+
+        * inspector/agents/JSGlobalObjectRuntimeAgent.h:
+        * inspector/agents/JSGlobalObjectRuntimeAgent.cpp:
+        (Inspector::JSGlobalObjectRuntimeAgent::didCreateFrontendAndBackend): Deleted.
+
+2019-03-20  Michael Saboff  <msaboff@apple.com>
+
+        JSC test crash: stress/dont-strength-reduce-regexp-with-compile-error.js.default
+        https://bugs.webkit.org/show_bug.cgi?id=195906
+
+        Reviewed by Mark Lam.
+
+        The problem here as that we may successfully parsed a RegExp without running out of stack,
+        but later run out of stack when trying to JIT compile the same expression.
+
+        Added a check for available stack space when we call into one of the parenthesis compilation
+        functions that recurse.  When we don't have enough stack space to recurse, we fail the JIT
+        compilation and let the interpreter handle the expression.
+
+        From code inspection of the YARR interpreter it has the same issue, but I couldn't cause a failure.
+        Filed a new bug and added a FIXME comment for the Interpreter to have similar checks.
+        Given that we can reproduce a failure, this is sufficient for now.
+
+        This change is covered by the previously added failing test,
+        JSTests/stress/dont-strength-reduce-regexp-with-compile-error.js.
+
+        * yarr/YarrInterpreter.cpp:
+        (JSC::Yarr::Interpreter::interpret):
+        * yarr/YarrJIT.cpp:
+        (JSC::Yarr::YarrGenerator::opCompileParenthesesSubpattern):
+        (JSC::Yarr::YarrGenerator::opCompileParentheticalAssertion):
+        (JSC::Yarr::YarrGenerator::opCompileBody):
+        (JSC::Yarr::dumpCompileFailure):
+        * yarr/YarrJIT.h:
+
+2019-03-20  Robin Morisset  <rmorisset@apple.com>
+
+        DFGNodeAllocator.h is dead code
+        https://bugs.webkit.org/show_bug.cgi?id=196019
+
+        Reviewed by Yusuke Suzuki.
+
+        As explained by Yusuke on IRC, the comment on DFG::Node saying that it cannot have a destructor is obsolete since https://trac.webkit.org/changeset/216815/webkit.
+        This patch removes both the comment and DFGNodeAllocator.h that that patch forgot to remove.
+
+        * dfg/DFGNode.h:
+        (JSC::DFG::Node::dumpChildren):
+        * dfg/DFGNodeAllocator.h: Removed.
+
+2019-03-20  Robin Morisset  <rmorisset@apple.com>
+
+        Compress CodeOrigin into a single word in the common case
+        https://bugs.webkit.org/show_bug.cgi?id=195928
+
+        Reviewed by Saam Barati.
+
+        The trick is that pointers only take 48 bits on x86_64 in practice (and we can even use the bottom three bits of that thanks to alignment), and even less on ARM64.
+        So we can shove the bytecode index in the top bits almost all the time.
+        If the bytecodeIndex is too ginormous (1<<16 in practice on x86_64), we just set one bit at the bottom and store a pointer to some out-of-line storage instead.
+        Finally we represent an invalid bytecodeIndex (which used to be represented by UINT_MAX) by setting the second least signifcant bit.
+
+        The patch looks very long, but most of it is just replacing direct accesses to inlineCallFrame and bytecodeIndex by the relevant getters.
+
+        End result: CodeOrigin in the common case moves from 16 bytes (8 for InlineCallFrame*, 4 for unsigned bytecodeIndex, 4 of padding) to 8.
+        As a reference, during running JetStream2 we allocate more than 35M CodeOrigins. While they won't all be alive at the same time, it is still quite a lot of objects, so I am hoping for some small
+        improvement to RAMification from this work.
+
+        The one slightly tricky part is that we must implement copy and move assignment operators and constructors to make sure that any out-of-line storage belongs to a single CodeOrigin and is destroyed exactly once.
+
+        * bytecode/ByValInfo.h:
+        * bytecode/CallLinkStatus.cpp:
+        (JSC::CallLinkStatus::computeFor):
+        * bytecode/CodeBlock.cpp:
+        (JSC::CodeBlock::globalObjectFor):
+        (JSC::CodeBlock::updateOSRExitCounterAndCheckIfNeedToReoptimize):
+        (JSC::CodeBlock::bytecodeOffsetFromCallSiteIndex):
+        * bytecode/CodeOrigin.cpp:
+        (JSC::CodeOrigin::inlineDepth const):
+        (JSC::CodeOrigin::isApproximatelyEqualTo const):
+        (JSC::CodeOrigin::approximateHash const):
+        (JSC::CodeOrigin::inlineStack const):
+        (JSC::CodeOrigin::codeOriginOwner const):
+        (JSC::CodeOrigin::stackOffset const):
+        (JSC::CodeOrigin::dump const):
+        (JSC::CodeOrigin::inlineDepthForCallFrame): Deleted.
+        * bytecode/CodeOrigin.h:
+        (JSC::OutOfLineCodeOrigin::OutOfLineCodeOrigin):
+        (JSC::CodeOrigin::CodeOrigin):
+        (JSC::CodeOrigin::~CodeOrigin):
+        (JSC::CodeOrigin::isSet const):
+        (JSC::CodeOrigin::isHashTableDeletedValue const):
+        (JSC::CodeOrigin::bytecodeIndex const):
+        (JSC::CodeOrigin::inlineCallFrame const):
+        (JSC::CodeOrigin::buildCompositeValue):
+        (JSC::CodeOrigin::hash const):
+        (JSC::CodeOrigin::operator== const):
+        (JSC::CodeOrigin::exitingInlineKind const): Deleted.
+        * bytecode/DeferredSourceDump.h:
+        * bytecode/GetByIdStatus.cpp:
+        (JSC::GetByIdStatus::computeForStubInfo):
+        (JSC::GetByIdStatus::computeFor):
+        * bytecode/ICStatusMap.cpp:
+        (JSC::ICStatusContext::isInlined const):
+        * bytecode/InByIdStatus.cpp:
+        (JSC::InByIdStatus::computeFor):
+        (JSC::InByIdStatus::computeForStubInfo):
+        * bytecode/InlineCallFrame.cpp:
+        (JSC::InlineCallFrame::dumpInContext const):
+        * bytecode/InlineCallFrame.h:
+        (JSC::InlineCallFrame::computeCallerSkippingTailCalls):
+        (JSC::InlineCallFrame::getCallerInlineFrameSkippingTailCalls):
+        (JSC::baselineCodeBlockForOriginAndBaselineCodeBlock):
+        (JSC::CodeOrigin::walkUpInlineStack):
+        * bytecode/InstanceOfStatus.h:
+        * bytecode/PutByIdStatus.cpp:
+        (JSC::PutByIdStatus::computeForStubInfo):
+        (JSC::PutByIdStatus::computeFor):
+        * dfg/DFGAbstractInterpreterInlines.h:
+        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+        * dfg/DFGArgumentsEliminationPhase.cpp:
+        * dfg/DFGArgumentsUtilities.cpp:
+        (JSC::DFG::argumentsInvolveStackSlot):
+        (JSC::DFG::emitCodeToGetArgumentsArrayLength):
+        * dfg/DFGArrayMode.h:
+        * dfg/DFGByteCodeParser.cpp:
+        (JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation):
+        (JSC::DFG::ByteCodeParser::setLocal):
+        (JSC::DFG::ByteCodeParser::setArgument):
+        (JSC::DFG::ByteCodeParser::flushForTerminalImpl):
+        (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
+        (JSC::DFG::ByteCodeParser::parseBlock):
+        (JSC::DFG::ByteCodeParser::parseCodeBlock):
+        (JSC::DFG::ByteCodeParser::handlePutByVal):
+        * dfg/DFGClobberize.h:
+        (JSC::DFG::clobberize):
+        * dfg/DFGConstantFoldingPhase.cpp:
+        (JSC::DFG::ConstantFoldingPhase::foldConstants):
+        * dfg/DFGFixupPhase.cpp:
+        (JSC::DFG::FixupPhase::attemptToMakeGetArrayLength):
+        * dfg/DFGForAllKills.h:
+        (JSC::DFG::forAllKilledOperands):
+        * dfg/DFGGraph.cpp:
+        (JSC::DFG::Graph::dumpCodeOrigin):
+        (JSC::DFG::Graph::dump):
+        (JSC::DFG::Graph::isLiveInBytecode):
+        (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
+        (JSC::DFG::Graph::willCatchExceptionInMachineFrame):
+        * dfg/DFGGraph.h:
+        (JSC::DFG::Graph::executableFor):
+        (JSC::DFG::Graph::isStrictModeFor):
+        (JSC::DFG::Graph::hasExitSite):
+        (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
+        * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
+        (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch):
+        * dfg/DFGMinifiedNode.cpp:
+        (JSC::DFG::MinifiedNode::fromNode):
+        * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
+        (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
+        * dfg/DFGOSRExit.cpp:
+        (JSC::DFG::OSRExit::executeOSRExit):
+        (JSC::DFG::reifyInlinedCallFrames):
+        (JSC::DFG::adjustAndJumpToTarget):
+        (JSC::DFG::printOSRExit):
+        (JSC::DFG::OSRExit::compileExit):
+        * dfg/DFGOSRExitBase.cpp:
+        (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSiteSlow):
+        * dfg/DFGOSRExitCompilerCommon.cpp:
+        (JSC::DFG::handleExitCounts):
+        (JSC::DFG::reifyInlinedCallFrames):
+        (JSC::DFG::adjustAndJumpToTarget):
+        * dfg/DFGOSRExitPreparation.cpp:
+        (JSC::DFG::prepareCodeOriginForOSRExit):
+        * dfg/DFGObjectAllocationSinkingPhase.cpp:
+        * dfg/DFGOperations.cpp:
+        * dfg/DFGPreciseLocalClobberize.h:
+        (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
+        * dfg/DFGSpeculativeJIT.cpp:
+        (JSC::DFG::SpeculativeJIT::emitGetLength):
+        (JSC::DFG::SpeculativeJIT::emitGetCallee):
+        (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
+        (JSC::DFG::SpeculativeJIT::compileValueAdd):
+        (JSC::DFG::SpeculativeJIT::compileValueSub):
+        (JSC::DFG::SpeculativeJIT::compileValueNegate):
+        (JSC::DFG::SpeculativeJIT::compileValueMul):
+        (JSC::DFG::SpeculativeJIT::compileForwardVarargs):
+        (JSC::DFG::SpeculativeJIT::compileCreateDirectArguments):
+        * dfg/DFGSpeculativeJIT32_64.cpp:
+        (JSC::DFG::SpeculativeJIT::emitCall):
+        * dfg/DFGSpeculativeJIT64.cpp:
+        (JSC::DFG::SpeculativeJIT::emitCall):
+        (JSC::DFG::SpeculativeJIT::compile):
+        * dfg/DFGTierUpCheckInjectionPhase.cpp:
+        (JSC::DFG::TierUpCheckInjectionPhase::run):
+        (JSC::DFG::TierUpCheckInjectionPhase::canOSREnterAtLoopHint):
+        (JSC::DFG::TierUpCheckInjectionPhase::buildNaturalLoopToLoopHintMap):
+        * dfg/DFGTypeCheckHoistingPhase.cpp:
+        (JSC::DFG::TypeCheckHoistingPhase::run):
+        * dfg/DFGVariableEventStream.cpp:
+        (JSC::DFG::VariableEventStream::reconstruct const):
+        * ftl/FTLLowerDFGToB3.cpp:
+        (JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
+        (JSC::FTL::DFG::LowerDFGToB3::compileValueSub):
+        (JSC::FTL::DFG::LowerDFGToB3::compileValueMul):
+        (JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub):
+        (JSC::FTL::DFG::LowerDFGToB3::compileValueNegate):
+        (JSC::FTL::DFG::LowerDFGToB3::compileGetMyArgumentByVal):
+        (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread):
+        (JSC::FTL::DFG::LowerDFGToB3::compileSpread):
+        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
+        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
+        (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs):
+        (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargsWithSpread):
+        (JSC::FTL::DFG::LowerDFGToB3::getArgumentsLength):
+        (JSC::FTL::DFG::LowerDFGToB3::getCurrentCallee):
+        (JSC::FTL::DFG::LowerDFGToB3::getArgumentsStart):
+        (JSC::FTL::DFG::LowerDFGToB3::codeOriginDescriptionOfCallSite const):
+        * ftl/FTLOSRExitCompiler.cpp:
+        (JSC::FTL::compileStub):
+        * ftl/FTLOperations.cpp:
+        (JSC::FTL::operationMaterializeObjectInOSR):
+        * interpreter/CallFrame.cpp:
+        (JSC::CallFrame::bytecodeOffset):
+        * interpreter/StackVisitor.cpp:
+        (JSC::StackVisitor::unwindToMachineCodeBlockFrame):
+        (JSC::StackVisitor::readFrame):
+        (JSC::StackVisitor::readNonInlinedFrame):
+        (JSC::inlinedFrameOffset):
+        (JSC::StackVisitor::readInlinedFrame):
+        * interpreter/StackVisitor.h:
+        * jit/AssemblyHelpers.cpp:
+        (JSC::AssemblyHelpers::executableFor):
+        * jit/AssemblyHelpers.h:
+        (JSC::AssemblyHelpers::isStrictModeFor):
+        (JSC::AssemblyHelpers::argumentsStart):
+        (JSC::AssemblyHelpers::argumentCount):
+        * jit/PCToCodeOriginMap.cpp:
+        (JSC::PCToCodeOriginMap::PCToCodeOriginMap):
+        (JSC::PCToCodeOriginMap::findPC const):
+        * profiler/ProfilerOriginStack.cpp:
+        (JSC::Profiler::OriginStack::OriginStack):
+        * profiler/ProfilerOriginStack.h:
+        * runtime/ErrorInstance.cpp:
+        (JSC::appendSourceToError):
+        * runtime/SamplingProfiler.cpp:
+        (JSC::SamplingProfiler::processUnverifiedStackTraces):
+
+2019-03-20  Devin Rousso  <drousso@apple.com>
+
+        Web Inspector: Search: allow DOM searches to be case sensitive
+        https://bugs.webkit.org/show_bug.cgi?id=194673
+        <rdar://problem/48087577>
+
+        Reviewed by Timothy Hatcher.
+
+        Since `DOM.performSearch` also searches by selector and XPath, some results may appear
+        as unexpected. As an example, searching for "BoDy" will still return the <body> as a result,
+        as although the literal node name ("BODY") didn't match, it did match via selector/XPath.
+
+        * inspector/protocol/DOM.json:
+        Allow `DOM.performSearch` to be case sensitive.
+
+2019-03-20  Saam Barati  <sbarati@apple.com>
+
+        AI rule for ValueBitNot/ValueBitXor/ValueBitAnd/ValueBitOr is wrong
+        https://bugs.webkit.org/show_bug.cgi?id=195980
+
+        Reviewed by Yusuke Suzuki.
+
+        They were all saying they could be type: (SpecBoolInt32, SpecBigInt)
+        However, they should have been type: (SpecInt32Only, SpecBigInt)
+
+        * dfg/DFGAbstractInterpreterInlines.h:
+        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+
+2019-03-20  Michael Catanzaro  <mcatanzaro@igalia.com>
+
+        Remove copyRef() calls added in r243163
+        https://bugs.webkit.org/show_bug.cgi?id=195962
+
+        Reviewed by Chris Dumez.
+
+        As best I can tell, may be a GCC 9 bug. It shouldn't warn about this case because the return
+        value is noncopyable and the WTFMove() is absolutely required. We can avoid the warning
+        without refcount churn by introducing an intermediate variable.
+
+        * inspector/scripts/codegen/cpp_generator_templates.py:
+
+2019-03-20  Carlos Garcia Campos  <cgarcia@igalia.com>
+
+        [GLIB] Optimize jsc_value_object_define_property_data|accessor
+        https://bugs.webkit.org/show_bug.cgi?id=195679
+
+        Reviewed by Saam Barati.
+
+        Use direct C++ call instead of using the JSC GLib API to create the descriptor object and invoke Object.defineProperty().
+
+        * API/glib/JSCValue.cpp:
+        (jsc_value_object_define_property_data):
+        (jsc_value_object_define_property_accessor):
+
+2019-03-19  Devin Rousso  <drousso@apple.com>
+
+        Web Inspector: Debugger: lazily create the agent
+        https://bugs.webkit.org/show_bug.cgi?id=195973
+        <rdar://problem/49039674>
+
+        Reviewed by Joseph Pecoraro.
+
+        * inspector/JSGlobalObjectInspectorController.cpp:
+        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
+        (Inspector::JSGlobalObjectInspectorController::frontendInitialized):
+        (Inspector::JSGlobalObjectInspectorController::createLazyAgents):
+
+        * inspector/JSGlobalObjectConsoleClient.h:
+        (Inspector::JSGlobalObjectConsoleClient::setInspectorDebuggerAgent): Added.
+        * inspector/JSGlobalObjectConsoleClient.cpp:
+        (Inspector::JSGlobalObjectConsoleClient::JSGlobalObjectConsoleClient):
+        (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
+        (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):
+
+        * inspector/agents/InspectorDebuggerAgent.h:
+        (Inspector::InspectorDebuggerAgent::addListener): Added.
+        (Inspector::InspectorDebuggerAgent::removeListener): Added.
+        (Inspector::InspectorDebuggerAgent::setListener): Deleted.
+        * inspector/agents/InspectorDebuggerAgent.cpp:
+        (Inspector::InspectorDebuggerAgent::InspectorDebuggerAgent):
+        (Inspector::InspectorDebuggerAgent::enable):
+        (Inspector::InspectorDebuggerAgent::disable):
+        (Inspector::InspectorDebuggerAgent::getScriptSource):
+        (Inspector::InspectorDebuggerAgent::schedulePauseOnNextStatement):
+        (Inspector::InspectorDebuggerAgent::didPause):
+        (Inspector::InspectorDebuggerAgent::breakProgram):
+        (Inspector::InspectorDebuggerAgent::clearBreakDetails):
+        Drive-by: reorder some member variables for better sizing.
+        Drive-by: rename some member variables for clarity.
+
+2019-03-19  Saam barati  <sbarati@apple.com>
+
+        Prune code after ForceOSRExit
+        https://bugs.webkit.org/show_bug.cgi?id=195913
+
+        Reviewed by Keith Miller.
+
+        I removed our original implementation of this in r242989 because
+        it was not sound. It broke backwards propagation because it removed
+        uses of a node that backwards propagation relied on to be sound.
+        Essentially, backwards propagation relies on being able to see uses
+        that would exist in bytecode to be sound.
+        
+        The rollout in r242989 was a 1% Speedometer2 regression. This patch
+        rolls back in the optimization in a sound way.
+        
+        This patch augments the code we had prior to r242989 to be sound. In
+        addition to preserving liveness, we now also convert all uses after
+        the ForceOSRExit to be Phantom. This may pessimize the optimizations
+        we do in backwards propagation, but it will prevent that phase from
+        making unsound optimizations.
+
+        * dfg/DFGByteCodeParser.cpp:
+        (JSC::DFG::ByteCodeParser::addToGraph):
+        (JSC::DFG::ByteCodeParser::parse):
+
+2019-03-19  Michael Catanzaro  <mcatanzaro@igalia.com>
+
+        Build cleanly with GCC 9
+        https://bugs.webkit.org/show_bug.cgi?id=195920
+
+        Reviewed by Chris Dumez.
+
+        WebKit triggers three new GCC 9 warnings:
+
+        """
+        -Wdeprecated-copy, implied by -Wextra, warns about the C++11 deprecation of implicitly
+        declared copy constructor and assignment operator if one of them is user-provided.
+        """
+
+        Solution is to either add a copy constructor or copy assignment operator, if required, or
+        else remove one if it is redundant.
+
+        """
+        -Wredundant-move, implied by -Wextra, warns about redundant calls to std::move.
+        -Wpessimizing-move, implied by -Wall, warns when a call to std::move prevents copy elision.
+        """
+
+        These account for most of this patch. Solution is to just remove the bad WTFMove().
+
+        Additionally, -Wclass-memaccess has been enhanced to catch a few cases that GCC 8 didn't.
+        These are solved by casting nontrivial types to void* before using memcpy. (Of course, it
+        would be safer to not use memcpy on nontrivial types, but that's too complex for this
+        patch. Searching for memcpy used with static_cast<void*> will reveal other cases to fix.)
+
+        * b3/B3ValueRep.h:
+        * bindings/ScriptValue.cpp:
+        (Inspector::jsToInspectorValue):
+        * bytecode/GetterSetterAccessCase.cpp:
+        (JSC::GetterSetterAccessCase::create):
+        (JSC::GetterSetterAccessCase::clone const):
+        * bytecode/InstanceOfAccessCase.cpp:
+        (JSC::InstanceOfAccessCase::clone const):
+        * bytecode/IntrinsicGetterAccessCase.cpp:
+        (JSC::IntrinsicGetterAccessCase::clone const):
+        * bytecode/ModuleNamespaceAccessCase.cpp:
+        (JSC::ModuleNamespaceAccessCase::clone const):
+        * bytecode/ProxyableAccessCase.cpp:
+        (JSC::ProxyableAccessCase::clone const):
+        * bytecode/StructureSet.h:
+        * debugger/Breakpoint.h:
+        * dfg/DFGRegisteredStructureSet.h:
+        * inspector/agents/InspectorDebuggerAgent.cpp:
+        (Inspector::buildDebuggerLocation):
+        * inspector/scripts/codegen/cpp_generator_templates.py:
+        * parser/UnlinkedSourceCode.h:
+        * wasm/WasmAirIRGenerator.cpp:
+        (JSC::Wasm::parseAndCompileAir):
+        * wasm/WasmB3IRGenerator.cpp:
+        (JSC::Wasm::parseAndCompile):
+        * wasm/WasmNameSectionParser.cpp:
+        (JSC::Wasm::NameSectionParser::parse):
+        * wasm/WasmStreamingParser.cpp:
+        (JSC::Wasm::StreamingParser::consume):
+
+2019-03-19  Saam Barati  <sbarati@apple.com>
+
+        Style fix: remove C style cast in Instruction.h
+        https://bugs.webkit.org/show_bug.cgi?id=195917
+
+        Reviewed by Filip Pizlo.
+
+        * bytecode/Instruction.h:
+        (JSC::Instruction::wide const):
+
+2019-03-19  Devin Rousso  <drousso@apple.com>
+
+        Web Inspector: Provide $event in the console when paused on an event listener
+        https://bugs.webkit.org/show_bug.cgi?id=188672
+
+        Reviewed by Timothy Hatcher.
+
+        * inspector/InjectedScript.h:
+        * inspector/InjectedScript.cpp:
+        (Inspector::InjectedScript::setEventValue): Added.
+        (Inspector::InjectedScript::clearEventValue): Added.
+
+        * inspector/InjectedScriptManager.h:
+        * inspector/InjectedScriptManager.cpp:
+        (Inspector::InjectedScriptManager::clearEventValue): Added.
+
+        * inspector/InjectedScriptSource.js:
+        (WI.InjectedScript.prototype.setEventValue): Added.
+        (WI.InjectedScript.prototype.clearEventValue): Added.
+        (BasicCommandLineAPI):
+
+2019-03-19  Devin Rousso  <drousso@apple.com>
+
+        Web Inspector: ScriptProfiler: lazily create the agent
+        https://bugs.webkit.org/show_bug.cgi?id=195591
+        <rdar://problem/48791756>
+
+        Reviewed by Joseph Pecoraro.
+
+        * inspector/JSGlobalObjectConsoleClient.h:
+        (Inspector::JSGlobalObjectConsoleClient::setInspectorScriptProfilerAgent): Added.
+        * inspector/JSGlobalObjectConsoleClient.cpp:
+        (Inspector::JSGlobalObjectConsoleClient::JSGlobalObjectConsoleClient):
+        (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
+        (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):
+
+        * inspector/JSGlobalObjectInspectorController.cpp:
+        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
+        (Inspector::JSGlobalObjectInspectorController::createLazyAgents):
+
+2019-03-19  Devin Rousso  <drousso@apple.com>
+
+        Web Inspector: Heap: lazily create the agent
+        https://bugs.webkit.org/show_bug.cgi?id=195590
+        <rdar://problem/48791750>
+
+        Reviewed by Joseph Pecoraro.
+
+        * inspector/agents/InspectorHeapAgent.h:
+        * inspector/agents/InspectorHeapAgent.cpp:
+        (Inspector::InspectorHeapAgent::~InspectorHeapAgent): Deleted.
+
+        * inspector/agents/InspectorConsoleAgent.h:
+        (Inspector::InspectorConsoleAgent::setInspectorHeapAgent): Added.
+        * inspector/agents/InspectorConsoleAgent.cpp:
+        (Inspector::InspectorConsoleAgent::InspectorConsoleAgent):
+        (Inspector::InspectorConsoleAgent::takeHeapSnapshot):
+        (Inspector::InspectorConsoleAgent::~InspectorConsoleAgent): Deleted.
+
+        * inspector/JSGlobalObjectInspectorController.cpp:
+        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
+        (Inspector::JSGlobalObjectInspectorController::createLazyAgents):
+
+2019-03-19  Caio Lima  <ticaiolima@gmail.com>
+
+        [JSC] LLIntEntryPoint creates same DirectJITCode for all functions
+        https://bugs.webkit.org/show_bug.cgi?id=194648
+
+        Reviewed by Keith Miller.
+
+        1. Making LLIntThunks singleton. 
+
+        Motivation: Former implementation has one LLIntThunk per type per VM.
+        However, the generated code for every kind of thunk is essentially the
+        same and we end up wasting memory (right now jitAllocationGranule = 32 bytes)
+        when we have 2 or more VM instantiated. Turn these thunks into
+        singleton will avoid such wasting.
+
+        Tradeoff: This change comes with a price, because we will keep thunks
+        allocated even when there is no VM instantiated. Considering WebCore use case,
+        the situation of having no VM instantiated is uncommon, since once a
+        VM is created through `commomVM()`, it will never be destroyed. Given
+        that, this change does not impact the overall memory comsumption of
+        WebCore/JSC. It also doesn't impact memory footprint, since thunks are
+        generated lazily (see results below).
+
+        Since we are keeping a static `MacroAssemblerCodeRef<JITThunkPtrTag>`,
+        we have the assurance that JITed code will never be deallocated,
+        given it is being pointed by `RefPtr<ExecutableMemoryHandle> m_executableMemory`.
+        To understand why we decided to make LLIntThunks singleton instead of
+        removing them, please see the comment on `llint/LLIntThunks.cpp`.
+
+        2. Making all LLIntEntrypoints singleton
+
+        Motivation: With singleton LLIntThunks, we also can have singleton
+        DirectJITCodes and NativeJITCodes for each LLIntEntrypoint type and
+        avoid multiple allocations of objects with the same content.
+
+        Tradeoff: As explained before, once we allocate an entrypoint, it
+        will be alive until the program exits. However, the gains we can
+        achieve in some use cases justifies such allocations.
+
+        As DirectJITCode and NativeJITCode are ThreadSafeRefCounted and we are using
+        `codeBlock->setJITCode(makeRef(*jitCode))`, their reference counter
+        will never be less than 1.
+
+        3. Memory usage analysis
+
+        This change reduces memory usage on stress/generate-multiple-llint-entrypoints.js
+        by 2% and is neutral on JetStream 2. Following results were generated
+        running each benchmark 6 times and using 95% Student's t distribution
+        confidence interval.
+
+        microbenchmarks/generate-multiple-llint-entrypoints.js (Changes uses less memory): 
+            Mean of memory peak on ToT: 122576896 bytes (confidence interval: 67747.2316)
+            Mean of memory peak on Changes: 119248213.33 bytes (confidence interval: 50251.2718)
+
+        JetStream2 (Neutral):
+            Mean of memory peak on ToT: 5442742272 bytes (confidence interval: 134381565.9117)
+            Mean of memory peak on Changes: 5384949760 bytes (confidence interval: 158413904.8352)
+
+        4. Performance Analysis
+
+        This change is performance neutral on JetStream 2 and Speedometer 2.
+        See results below.:
+
+        JetStream 2 (Neutral):
+            Mean of score on ToT: 139.58 (confidence interval: 2.44)
+            Mean of score on Changes: 141.46 (confidence interval: 4.24)
+
+        Speedometer run #1
+           ToT: 110 +- 2.9
+           Changes: 110 +- 1.8
+
+        Speedometer run #2
+           ToT: 110 +- 1.6
+           Changes: 108 +- 2.3
+
+        Speedometer run #3
+           ToT: 110 +- 3.0
+           Changes: 110 +- 1.4
+
+        * jit/JSInterfaceJIT.h:
+        (JSC::JSInterfaceJIT::JSInterfaceJIT):
+        * llint/LLIntEntrypoint.cpp:
+
+        Here we are changing the usage or DirectJITCode by NativeJITCode on cases
+        where there is no difference from address of calls with and without
+        ArithCheck.
+
+        (JSC::LLInt::setFunctionEntrypoint):
+        (JSC::LLInt::setEvalEntrypoint):
+        (JSC::LLInt::setProgramEntrypoint):
+        (JSC::LLInt::setModuleProgramEntrypoint):
+        (JSC::LLInt::setEntrypoint):
+        * llint/LLIntEntrypoint.h:
+        * llint/LLIntThunks.cpp:
+        (JSC::LLInt::generateThunkWithJumpTo):
+        (JSC::LLInt::functionForCallEntryThunk):
+        (JSC::LLInt::functionForConstructEntryThunk):
+        (JSC::LLInt::functionForCallArityCheckThunk):
+        (JSC::LLInt::functionForConstructArityCheckThunk):
+        (JSC::LLInt::evalEntryThunk):
+        (JSC::LLInt::programEntryThunk):
+        (JSC::LLInt::moduleProgramEntryThunk):
+        (JSC::LLInt::functionForCallEntryThunkGenerator): Deleted.
+        (JSC::LLInt::functionForConstructEntryThunkGenerator): Deleted.
+        (JSC::LLInt::functionForCallArityCheckThunkGenerator): Deleted.
+        (JSC::LLInt::functionForConstructArityCheckThunkGenerator): Deleted.
+        (JSC::LLInt::evalEntryThunkGenerator): Deleted.
+        (JSC::LLInt::programEntryThunkGenerator): Deleted.
+        (JSC::LLInt::moduleProgramEntryThunkGenerator): Deleted.
+        * llint/LLIntThunks.h:
+        * runtime/ScriptExecutable.cpp:
+        (JSC::setupLLInt):
+        (JSC::ScriptExecutable::prepareForExecutionImpl):
+
+2019-03-18  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Add missing exception checks revealed by newly added exception checks, follow-up after r243081
+        https://bugs.webkit.org/show_bug.cgi?id=195927
+
+        Reviewed by Mark Lam.
+
+        r243081 adds more exception checks which are previously missing, and it reveals missing exception checks in the caller.
+        This patch is a follow-up patch after r243081, adding missing exception checks more to fix debug test failures.
+
+        * runtime/RegExpConstructor.cpp:
+        (JSC::setRegExpConstructorInput):
+        (JSC::setRegExpConstructorMultiline):
+        * runtime/RegExpGlobalData.cpp:
+        (JSC::RegExpGlobalData::getBackref):
+        (JSC::RegExpGlobalData::getLastParen):
+
+2019-03-18  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Generator should not create JSLexicalEnvironment if it is not necessary
+        https://bugs.webkit.org/show_bug.cgi?id=195901
+
+        Reviewed by Saam Barati.
+
+        It is not rare that generators do not need to have any registers to be suspended and resumed.
+        Since currently we always emit op_create_lexical_environment for generator code, we sometimes
+        create empty JSLexicalEnvironment while it is not required. We can see that a lot of empty JSLexicalEnvironment
+        are allocated in RAMification's Basic test.
+
+        This patch removes this unnecessary allocation. We introduce op_create_generator_frame_environment, which is
+        a marker, similar to op_yield. And generatorification phase decides whether we should actually emit op_create_lexical_environment,
+        based on the result of the analysis in generatorification. This can remove unnecessary JSLexicalEnvironment allocations.
+
+        We run RAMification in 6 times, use average of them.
+        RAMification's Basic in JIT mode shows 1.4% improvement.
+        ToT
+            Current: 55076864.00, Peak: 55080960.00
+        Patched
+            Current: 54325930.67, Peak: 54329344.00
+
+        RAMification's Basic in non-JIT mode shows 5.0% improvement.
+        ToT
+            Current: 12485290.67, Peak: 12485290.67
+        Patched
+            Current: 11894101.33, Peak: 11894101.33
+
+        * bytecode/BytecodeGeneratorification.cpp:
+        (JSC::BytecodeGeneratorification::BytecodeGeneratorification):
+        (JSC::BytecodeGeneratorification::generatorFrameData const):
+        (JSC::BytecodeGeneratorification::run):
+        * bytecode/BytecodeList.rb:
+        * bytecode/BytecodeUseDef.h:
+        (JSC::computeUsesForBytecodeOffset):
+        (JSC::computeDefsForBytecodeOffset):
+        * bytecompiler/BytecodeGenerator.cpp:
+        (JSC::BytecodeGenerator::BytecodeGenerator):
+        * dfg/DFGCapabilities.cpp:
+        (JSC::DFG::capabilityLevel):
+        * llint/LowLevelInterpreter.asm:
+
+2019-03-18  Robin Morisset  <rmorisset@apple.com>
+
+        Remove the inline capacity of Operands
+        https://bugs.webkit.org/show_bug.cgi?id=195898
+
+        Reviewed by Yusuke Suzuki.
+
+        Operands currently has a vector with an inline capacity of 24.
+        I tested on JetStream2, and only 4776 functions out of 12035 (that reach the DFG tier) have 24 or fewer elements in it.
+        This is a major problem, because we have 5 Operands in every DFG::BasicBlock, resulting in 2688 bytes of inline capacity per basic block.
+        Still on JetStream 2, functions have an average of 18 BB, but those functions whose operands overflow have an average of 27 BB (so we are wasting 72kB on average when compiling them), and the largest function has 1241 BB (!), for a total of 3.3MB being wasted while it is compiled.
+        
+        So I removed the inline capacity of the vector in Operands, and here are the results:
+        Baseline Jetstream2:
+        159.741
+        159.746
+        159.989
+        Baseline RAMification on grouped and jit tests: (end/peak/score)
+        89.288/89.763/89.526
+        90.166/90.761/90.418
+        89.560/90.014/89.787
+        After optimization Jetstream2:
+        159.342
+        161.812
+        162.037
+        After optimization RAMification:
+        89.147/89.644/89.395
+        89.102.89.585/89.343
+        88.953/89.536/89.2444
+        
+        So it looks like a roughly 1% improvement on RAMification (at least the tests where the JIT is enabled), and more surprisingly also a 1% progression on Jetstream2 (although I have more doubts about this one considering the variability in my numbers).
+        I hope to land this, and get more accurate results from the bots.
+
+        * bytecode/Operands.h:
+
+2019-03-18  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Add --destroy-vm shell option and dumpHeapStatisticsAtVMDestruction option
+        https://bugs.webkit.org/show_bug.cgi?id=195897
+
+        Reviewed by Keith Miller.
+
+        It is useful if we have an option logging the status of all the existing MarkedBlocks and their objects at VM destruction.
+        I used this feature to find wasting memory, and successfully removed many wasted MarkedBlocks and JS cells like r243081.
+        This patch adds,
+
+        1. --destroy-vm option to JSC shell to destroy main thread JSC::VM
+        2. dumpHeapStatisticsAtVMDestruction to dump MarkedBlocks at VM destruction
+
+        While the current option name is "dumpHeapStatisticsAtVMDestruction", we just dump the status of MarkedBlocks and cells. But eventually,
+        we would like to collect heap statistics and dump them to investigate Heap status more.
+
+        This patch also removes logHeapStatisticsAtExit option since it is no longer used in JSC.
+
+        * heap/Heap.cpp:
+        (JSC::Heap::dumpHeapStatisticsAtVMDestruction):
+        (JSC::Heap::lastChanceToFinalize):
+        * heap/Heap.h:
+        * jsc.cpp:
+        (printUsageStatement):
+        (CommandLine::parseArguments):
+        (runJSC):
+        * runtime/Options.h:
+
+2019-03-18  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] jsSubstring should resolve rope before calling JSRopeString::create
+        https://bugs.webkit.org/show_bug.cgi?id=195840
+
+        Reviewed by Geoffrey Garen.
+
+        jsSubstring always ends up resolving rope of the base string because substring JSRopeString only accepts non-rope JSString
+        as its base. Instead of resolving ropes in finishCreationSubstring, we should resolve before passing it to JSRopeString.
+        So that, we can access string data before creating JSRopeString, and we can introduce optimizations like avoiding creation
+        of single character substrings.
+
+        We can find that a lot of substrings for length = 1 are allocated in RAMification regexp tests. This patch avoids creation of these
+        strings to save memory.
+
+        This patch also strengthen error checks caused by rope resolution for base of substrings. Previously we sometimes miss this checks.
+
+        * dfg/DFGOperations.cpp:
+        * runtime/JSString.cpp:
+        (JSC::JSString::dumpToStream):
+        * runtime/JSString.h:
+        (JSC::jsSubstring):
+        (JSC::jsSubstringOfResolved):
+        (JSC::jsSingleCharacterString):
+        * runtime/RegExpCachedResult.cpp:
+        (JSC::RegExpCachedResult::lastResult): We no longer need to have length = 0 path since jsSubstring returns an empty string if length == 0.
+        (JSC::RegExpCachedResult::leftContext):
+        (JSC::RegExpCachedResult::rightContext):
+        (JSC::RegExpCachedResult::setInput):
+        * runtime/RegExpGlobalData.cpp:
+        (JSC::RegExpGlobalData::getBackref):
+        (JSC::RegExpGlobalData::getLastParen):
+        * runtime/StringObject.h:
+        (JSC::jsStringWithReuse):
+        (JSC::jsSubstring):
+        * runtime/StringPrototype.cpp:
+        (JSC::replaceUsingRegExpSearch):
+        (JSC::operationStringProtoFuncReplaceRegExpEmptyStr):
+        (JSC::replaceUsingStringSearch):
+        (JSC::stringProtoFuncSlice):
+        (JSC::splitStringByOneCharacterImpl):
+        (JSC::stringProtoFuncSplitFast):
+        (JSC::stringProtoFuncSubstr):
+        (JSC::stringProtoFuncSubstring):
+        (JSC::stringProtoFuncToLowerCase):
+        (JSC::stringProtoFuncToUpperCase):
+        Some `const String& value = string->value(exec)` is dangerous if GC happens later. Changed to getting `String` instead of `const String&` here.
+
+        * runtime/StringPrototypeInlines.h:
+        (JSC::stringSlice):
+
+2019-03-18  Mark Lam  <mark.lam@apple.com>
+
+        Missing a ThrowScope release in JSObject::toString().
+        https://bugs.webkit.org/show_bug.cgi?id=195893
+        <rdar://problem/48970986>
+
+        Reviewed by Michael Saboff.
+
+        Placate the validator with a RELEASE_AND_RETURN().
+
+        * runtime/JSObject.cpp:
+        (JSC::JSObject::toString const):
+
+2019-03-18  Mark Lam  <mark.lam@apple.com>
+
+        Structure::flattenDictionary() should clear unused property slots.
+        https://bugs.webkit.org/show_bug.cgi?id=195871
+        <rdar://problem/48959497>
+
+        Reviewed by Michael Saboff.
+
+        It currently attempts to do this but fails because it's actually clearing up the
+        preCapacity region instead.  The fix is simply to account for the preCapacity
+        when computing the start address of the property slots.
+
+        * runtime/Structure.cpp:
+        (JSC::Structure::flattenDictionaryStructure):
+
+2019-03-18  Robin Morisset  <rmorisset@apple.com>
+
+        B3 should reduce Shl(<S|Z>Shr(@x, @const), @const) to BitAnd(@x, -(1<<@const))
+        https://bugs.webkit.org/show_bug.cgi?id=152164
+
+        Reviewed by Filip Pizlo.
+
+        Turn this: Shl(<S|Z>Shr(@x, @const), @const)
+        Into this: BitAnd(@x, -(1<<@const))
+
+        I added two tests: one for ZShr/32 bits, and one for SShr/64 bits, I think it is enough coverage (no reason for any interaction between the signedness of the shift and the bitwidth).
+        I also modified a few adjacent tests to remove undefined behaviours.
+
+        * b3/B3ReduceStrength.cpp:
+        * b3/testb3.cpp:
+        (JSC::B3::testShlImms):
+        (JSC::B3::testShlArgImm):
+        (JSC::B3::testShlSShrArgImm):
+        (JSC::B3::testShlImms32):
+        (JSC::B3::testShlArgImm32):
+        (JSC::B3::testShlZShrArgImm32):
+        (JSC::B3::run):
+
+2019-03-17  Robin Morisset  <rmorisset@apple.com>
+
+        ParserError can be shrunk by 8 bytes
+        https://bugs.webkit.org/show_bug.cgi?id=195496
+
+        Reviewed by Mark Lam.
+
+        * parser/ParserError.h:
+
+2019-03-17  Diego Pino Garcia  <dpino@igalia.com>
+
+        Fix WPE and GTK Debug builds after r243049
+        https://bugs.webkit.org/show_bug.cgi?id=195860
+
+        Unreviewed, build fix after r243049.
+
+        * runtime/StringPrototype.cpp:
+        (JSC::normalizationAffects8Bit):
+
+2019-03-17  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        REGRESSION: !vm.isInitializingObject() void* JSC::tryAllocateCellHelper<JSC::Structure> JSC::Structure::create
+        https://bugs.webkit.org/show_bug.cgi?id=195858
+
+        Reviewed by Mark Lam.
+
+        r243011 changed WebAssembly related structures lazily-allocated. It means that this lazy allocation must not be done in the middle of
+        the other object allocations. This patch changes the signature of wasm related objects' ::create functions to taking Structure*.
+        This prevents us from materializing lazily-allocated structures while allocating wasm related objects, and this style is used in the
+        other places to fix the same problem. This bug is caught by existing debug tests for wasm.
+
+        * runtime/JSGlobalObject.h:
+        * wasm/js/JSWebAssemblyCompileError.cpp:
+        (JSC::createJSWebAssemblyCompileError):
+        * wasm/js/JSWebAssemblyInstance.cpp:
+        (JSC::JSWebAssemblyInstance::finalizeCreation):
+        (JSC::JSWebAssemblyInstance::create):
+        * wasm/js/JSWebAssemblyLinkError.cpp:
+        (JSC::createJSWebAssemblyLinkError):
+        * wasm/js/JSWebAssemblyModule.cpp:
+        (JSC::JSWebAssemblyModule::createStub):
+        (JSC::JSWebAssemblyModule::finishCreation):
+        * wasm/js/WasmToJS.cpp:
+        (JSC::Wasm::wasmToJSException):
+        * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
+        (JSC::constructJSWebAssemblyCompileError):
+        (JSC::callJSWebAssemblyCompileError):
+        * wasm/js/WebAssemblyFunction.cpp:
+        (JSC::WebAssemblyFunction::create):
+        * wasm/js/WebAssemblyFunction.h:
+        * wasm/js/WebAssemblyInstanceConstructor.cpp:
+        (JSC::constructJSWebAssemblyInstance):
+        * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
+        (JSC::constructJSWebAssemblyLinkError):
+        (JSC::callJSWebAssemblyLinkError):
+        * wasm/js/WebAssemblyMemoryConstructor.cpp:
+        (JSC::constructJSWebAssemblyMemory):
+        * wasm/js/WebAssemblyModuleConstructor.cpp:
+        (JSC::WebAssemblyModuleConstructor::createModule):
+        * wasm/js/WebAssemblyModuleRecord.cpp:
+        (JSC::WebAssemblyModuleRecord::link):
+        (JSC::WebAssemblyModuleRecord::evaluate):
+        * wasm/js/WebAssemblyPrototype.cpp:
+        (JSC::webAssemblyModuleValidateAsyncInternal):
+        (JSC::instantiate):
+        (JSC::compileAndInstantiate):
+        (JSC::webAssemblyModuleInstantinateAsyncInternal):
+        * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
+        (JSC::constructJSWebAssemblyRuntimeError):
+        (JSC::callJSWebAssemblyRuntimeError):
+        * wasm/js/WebAssemblyTableConstructor.cpp:
+        (JSC::constructJSWebAssemblyTable):
+        * wasm/js/WebAssemblyToJSCallee.cpp:
+        (JSC::WebAssemblyToJSCallee::create):
+        * wasm/js/WebAssemblyToJSCallee.h:
+        * wasm/js/WebAssemblyWrapperFunction.cpp:
+        (JSC::WebAssemblyWrapperFunction::create):
+        * wasm/js/WebAssemblyWrapperFunction.h:
+
+2019-03-16  Darin Adler  <darin@apple.com>
+
+        Improve normalization code, including moving from unorm.h to unorm2.h
+        https://bugs.webkit.org/show_bug.cgi?id=195330
+
+        Reviewed by Michael Catanzaro.
+
+        * runtime/JSString.h: Move StringViewWithUnderlyingString to StringView.h.
+
+        * runtime/StringPrototype.cpp: Include unorm2.h instead of unorm.h.
+        (JSC::normalizer): Added. Function to create normalizer object given
+        enumeration value indicating which is selected. Simplified because we
+        know the function will not fail and so we don't need error handling code.
+        (JSC::normalize): Changed this function to take a JSString* so we can
+        optimize the case where no normalization is needed. Added an early exit
+        if the string is stored as 8-bit and another if the string is already
+        normalized, using unorm2_isNormalized. Changed error handling to only
+        check cases that can actually fail in practice. Also did other small
+        optimizations like passing VM rather than ExecState.
+        (JSC::stringProtoFuncNormalize): Used smaller enumeration names that are
+        identical to the names used in the API and normalization parlance rather
+        than longer ones that expand the acronyms. Updated to pass JSString* to
+        the normalize function, so we can optimize 8-bit and already-normalized
+        cases, rather than callling the expensive String::upconvertedCharacters
+        function. Use throwVMRangeError.
+
+2019-03-15  Mark Lam  <mark.lam@apple.com>
+
+        Need to check ObjectPropertyCondition liveness before accessing it when firing watchpoints.
+        https://bugs.webkit.org/show_bug.cgi?id=195827
+        <rdar://problem/48845513>
+
+        Reviewed by Filip Pizlo.
+
+        m_object in ObjectPropertyCondition may no longer be live by the time the watchpoint fires.
+
+        * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
+        (JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):
+        * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
+        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
+        * bytecode/ObjectPropertyCondition.cpp:
+        (JSC::ObjectPropertyCondition::dumpInContext const):
+        * bytecode/StructureStubClearingWatchpoint.cpp:
+        (JSC::StructureStubClearingWatchpoint::fireInternal):
+        * dfg/DFGAdaptiveStructureWatchpoint.cpp:
+        (JSC::DFG::AdaptiveStructureWatchpoint::fireInternal):
+        * runtime/StructureRareData.cpp:
+        (JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
+
+2019-03-15  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Make more properties lazily-allocated in JSGlobalObject, including properties only used in JIT mode
+        https://bugs.webkit.org/show_bug.cgi?id=195816
+
+        Reviewed by Michael Saboff.
+
+        This patch makes more properties lazily-allocated in JSGlobalObject. This patch makes the following lazily-allocated.
+
+        1. iteratorResultObjectStructure
+        2. WebAssembly related objects except for JSWebAssembly top-level object.
+
+        * CMakeLists.txt:
+        * DerivedSources-input.xcfilelist:
+        * DerivedSources-output.xcfilelist:
+        * DerivedSources.make:
+        * runtime/JSGlobalObject.cpp:
+        (JSC::JSGlobalObject::init):
+        (JSC::JSGlobalObject::visitChildren):
+        * runtime/JSGlobalObject.h:
+        (JSC::JSGlobalObject::iteratorResultObjectStructure const):
+        (JSC::JSGlobalObject::webAssemblyModuleRecordStructure const):
+        (JSC::JSGlobalObject::webAssemblyFunctionStructure const):
+        (JSC::JSGlobalObject::webAssemblyWrapperFunctionStructure const):
+        (JSC::JSGlobalObject::webAssemblyToJSCalleeStructure const):
+        * wasm/js/JSWebAssembly.cpp:
+        * wasm/js/JSWebAssembly.h:
+
+2019-03-15  Dominik Infuehr  <dinfuehr@igalia.com>
+
+        [CMake] Move test .js files into testapiScripts
+        https://bugs.webkit.org/show_bug.cgi?id=195565
+
+        Reviewed by Yusuke Suzuki.
+
+        testapi expect .js file in the testapiScripts-directory.
+
+        * shell/CMakeLists.txt:
+
+2019-03-15  Mark Lam  <mark.lam@apple.com>
+
+        Gardening: add a missing exception check after r242991.
+        https://bugs.webkit.org/show_bug.cgi?id=195791
+
+        Unreviewed.
+
+        * tools/JSDollarVM.cpp:
+        (JSC::functionGetGetterSetter):
+
+2019-03-15  Devin Rousso  <drousso@apple.com>
+
+        Web Inspector: provide a way to capture a screenshot of a node from within the page
+        https://bugs.webkit.org/show_bug.cgi?id=194279
+        <rdar://problem/10731573>
+
+        Reviewed by Joseph Pecoraro.
+
+        Add `console.screenshot` functionality, which displays a screenshot of a given object (if
+        able) within Web Inspector's Console tab. From there, it can be viewed and saved.
+
+        Currently, `console.screenshot` will
+         - capture an image of a `Node` (if provided)
+         - capture an image of the viewport if nothing is provided
+
+        * inspector/protocol/Console.json:
+        Add `Image` enum value to `ConsoleMessage` type.
+        * runtime/ConsoleTypes.h:
+        * inspector/ConsoleMessage.h:
+        * inspector/ConsoleMessage.cpp:
+        (Inspector::messageTypeValue):
+
+        * runtime/ConsoleClient.h:
+        * runtime/ConsoleObject.cpp:
+        (JSC::ConsoleObject::finishCreation):
+        (JSC::consoleProtoFuncScreenshot): Added.
+
+        * inspector/JSGlobalObjectConsoleClient.h:
+        * inspector/JSGlobalObjectConsoleClient.cpp:
+        (Inspector::JSGlobalObjectConsoleClient::screenshot): Added.
+
+2019-03-14  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Retain PrivateName of Symbol before passing it to operations potentially incurring GC
+        https://bugs.webkit.org/show_bug.cgi?id=195791
+        <rdar://problem/48806130>
+
+        Reviewed by Mark Lam.
+
+        Consider the following example:
+
+            void putByVal(JSObject*, PropertyName propertyName, ...);
+
+            putByVal(object, symbol->privateName(), ...);
+
+        PropertyName does not retain the passed UniquedStringImpl*. It just holds the pointer to UniquedStringImpl*.
+        It means that since `Symbol::privateName()` returns `const PrivateName&` instead of `PrivateName`, putByVal
+        and its caller does not retain UniquedStringImpl* held in PropertyName. The problem happens when the putByVal
+        incurs GC, and when the `symbol` is missing in the conservative GC scan. The underlying UniquedStringImpl* of
+        PropertyName can be accidentally destroyed in the middle of the putByVal operation. We should retain PrivateName
+        before passing it to operations which takes it as PropertyName.
+
+        1. We use the code pattern like this.
+
+            auto propertyName = symbol->privateName();
+            someOperation(..., propertyName);
+
+        This pattern is well aligned to existing `JSValue::toPropertyKey(exec)` and `JSString::toIdentifier(exec)` code patterns.
+
+            auto propertyName = value.toPropertyKey(exec);
+            RETURN_IF_EXCEPTION(scope, { });
+            someOperation(..., propertyName);
+
+        2. We change `Symbol::privateName()` to returning `PrivateName` instead of `const PrivateName&` to avoid
+           potential dangerous use cases. This is OK because the code using `Symbol::privateName()` is not a critical path,
+           and they typically need to retain PrivateName.
+
+        3. We audit similar functions `toPropertyKey(exec)` and `toIdentifier(exec)` for needed but missing exception checks.
+           BTW, these functions are safe to the problem fixed in this patch since they return `Identifier` instead
+           of `const Identifier&`.
+
+        Mark and Robin investigated and offered important data to understand what went wrong. And figured out the reason behind
+        the mysterious behavior shown in the data, and now, we confirm that this is the right fix for this bug.
+
+        * dfg/DFGOperations.cpp:
+        * jit/JITOperations.cpp:
+        (JSC::tryGetByValOptimize):
+        * runtime/JSFunction.cpp:
+        (JSC::JSFunction::setFunctionName):
+        * runtime/JSModuleLoader.cpp:
+        (JSC::printableModuleKey):
+        * runtime/JSONObject.cpp:
+        (JSC::Stringifier::Stringifier):
+        * runtime/Symbol.cpp:
+        (JSC::Symbol::descriptiveString const):
+        (JSC::Symbol::description const):
+        * runtime/Symbol.h:
+        * runtime/SymbolConstructor.cpp:
+        (JSC::symbolConstructorKeyFor):
+        * tools/JSDollarVM.cpp:
+        (JSC::functionGetGetterSetter):
+
+2019-03-14  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        REGRESSION(r242841): Fix conservative DFG OSR entry validation to accept values which will be stored in AnyInt / Double flush formats
+        https://bugs.webkit.org/show_bug.cgi?id=195752
+
+        Reviewed by Saam Barati.
+
+        We fixed the bug skipping AbstractValue validations when the flush format is Double or AnyInt. But it
+        was too conservative. While validating inputs with AbstractValue is mandatory (without it, whole CFA
+        falls into wrong condition), our validation does not care AnyInt and Double representations in lower
+        tiers. For example, if a value is stored in Double flush format in DFG, its AbstractValue becomes
+        SpecFullDouble. However, it does not include Int32 and OSR entry is rejected if Int32 comes for DoubleRep
+        OSR entry value. This is wrong since we later convert these numbers into DoubleRep representation
+        before entering DFG code.
+
+        This patch performs AbstractValue validation onto the correctly converted value with flush format hint.
+
+        And it still does not fix OSR entry failures in navier-stokes. This is because AbstractValue representation
+        in navier-stokes's lin_solve was too strict. Then, this patch reverts r242627. Instead of removing must handle
+        value handling in CFA, DFG OSR entry now correctly validates inputs with AbstractValues even if the flush format
+        is Double or AnyInt. As long as DFG OSR entry validates inputs, merging must handle values as proven constants is OK.
+
+        We can see that # of OSR entry failures in navier-stokes.js becomes the same to the previous count. And we can see
+        AnyInt OSR entry actually works in microbenchmarks/large-int.js. However, AnyInt effect is hard to observe because this
+        is super rare. Since we inject type prediction based on must handle value, the flush format tends to be SpecAnyIntAsDouble
+        and it accepts JSValues simply.
+
+        * bytecode/SpeculatedType.cpp:
+        (JSC::dumpSpeculation):
+        * dfg/DFGAbstractValue.cpp:
+        (JSC::DFG::AbstractValue::filterValueByType):
+        * dfg/DFGAbstractValue.h:
+        (JSC::DFG::AbstractValue::validateOSREntryValue const):
+        (JSC::DFG::AbstractValue::validateTypeAcceptingBoxedInt52 const):
+        (JSC::DFG::AbstractValue::validate const): Deleted.
+        (JSC::DFG::AbstractValue::validateType const): Deleted.
+        * dfg/DFGCFAPhase.cpp:
+        (JSC::DFG::CFAPhase::run):
+        (JSC::DFG::CFAPhase::injectOSR):
+        (JSC::DFG::CFAPhase::performBlockCFA):
+        * dfg/DFGOSREntry.cpp:
+        (JSC::DFG::prepareOSREntry):
+
+2019-03-14  Saam barati  <sbarati@apple.com>
+
+        We can't remove code after ForceOSRExit until after FixupPhase
+        https://bugs.webkit.org/show_bug.cgi?id=186916
+        <rdar://problem/41396612>
+
+        Reviewed by Yusuke Suzuki.
+
+        There was an optimization in the bytecode parser I added in r232742 that converted blocks
+        with ForceOSRExit in them to remove all IR after the ForceOSRExit. However,
+        this is incorrect because it breaks backwards propagation. For example, it
+        could incorrectly lead us to think it's safe to not check for overflow in
+        an Add because such Add has no non-int uses. Backwards propagation relies on
+        having a view over bytecode uses, and this optimization broke that. This patch
+        rolls out that optimization, as initial perf data shows it may no longer be
+        needed.
+
+        * dfg/DFGByteCodeParser.cpp:
+        (JSC::DFG::ByteCodeParser::addToGraph):
+        (JSC::DFG::ByteCodeParser::parse):
+
+2019-03-14  Saam barati  <sbarati@apple.com>
+
+        JSScript should have an accessor saying if it's cached or not
+        https://bugs.webkit.org/show_bug.cgi?id=195783
+
+        Reviewed by Michael Saboff.
+
+        * API/JSScript.h:
+        * API/JSScript.mm:
+        (-[JSScript isUsingBytecodeCache]):
+        * API/tests/testapi.mm:
+        (testIsUsingBytecodeCacheAccessor):
+        (testObjectiveCAPI):
+
 2019-03-14  Saam barati  <sbarati@apple.com>
 
         Remove retain cycle from JSScript and also don't keep the cache file descriptor open so many JSScripts can be cached in a loop