op_check_tdz does not def its argument
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
index 48ae586..082240b 100644 (file)
+2019-03-08  Tadeu Zagallo  <tzagallo@apple.com>
+
+        op_check_tdz does not def its argument
+        https://bugs.webkit.org/show_bug.cgi?id=192880
+        <rdar://problem/46221598>
+
+        Reviewed by Saam Barati.
+
+        This prevented the for-in loop optimization in the bytecode generator, since
+        the analysis sees a redefinition of the loop variable.
+
+        * bytecode/BytecodeUseDef.h:
+        (JSC::computeDefsForBytecodeOffset):
+
+2019-03-07  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Make more fields lazy in JSGlobalObject
+        https://bugs.webkit.org/show_bug.cgi?id=195449
+
+        Reviewed by Mark Lam.
+
+        This patch makes more fields lazy-allocated in JSGlobalObject to save memory.
+
+        1. Some minor structures like moduleRecordStructure.
+        2. Some functions like parseInt / parseFloat. While they are eagerly created in JIT mode anyway to materialize NumberConstructor, we can lazily allocate them in non JIT mode.
+        3. ArrayBuffer constructor. While it is eagerly allocated in WebCore, we can make lazily allocated in JSC.
+
+        * interpreter/Interpreter.cpp:
+        (JSC::Interpreter::execute):
+        * runtime/JSArrayBufferPrototype.h:
+        * runtime/JSGlobalObject.cpp:
+        (JSC::JSGlobalObject::init):
+        (JSC::JSGlobalObject::visitChildren):
+        * runtime/JSGlobalObject.h:
+        (JSC::JSGlobalObject::parseIntFunction const):
+        (JSC::JSGlobalObject::parseFloatFunction const):
+        (JSC::JSGlobalObject::evalFunction const):
+        (JSC::JSGlobalObject::strictEvalActivationStructure const):
+        (JSC::JSGlobalObject::moduleRecordStructure const):
+        (JSC::JSGlobalObject::moduleNamespaceObjectStructure const):
+        (JSC::JSGlobalObject::proxyObjectStructure const):
+        (JSC::JSGlobalObject::callableProxyObjectStructure const):
+        (JSC::JSGlobalObject::proxyRevokeStructure const):
+        (JSC::JSGlobalObject::arrayBufferConstructor const):
+        (JSC::JSGlobalObject::arrayBufferPrototype const):
+        (JSC::JSGlobalObject::arrayBufferStructure const):
+        * runtime/ProxyObject.h:
+        * runtime/StrictEvalActivation.cpp:
+        (JSC::StrictEvalActivation::StrictEvalActivation):
+        * runtime/StrictEvalActivation.h:
+        * wasm/js/JSWebAssemblyMemory.cpp:
+        (JSC::JSWebAssemblyMemory::buffer):
+        * wasm/js/WebAssemblyModuleConstructor.cpp:
+        (JSC::webAssemblyModuleCustomSections):
+
+2019-03-07  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Remove merging must handle values into proven types in CFA
+        https://bugs.webkit.org/show_bug.cgi?id=195444
+
+        Reviewed by Saam Barati.
+
+        Previously, we are merging must handle values as a proven constant in CFA. This is OK as long as this proven AbstractValue is blurred by merging the other legit AbstractValues
+        from the successors. But let's consider the following code, this is actually generated DFG graph from the attached test in r242626.
+
+            Block #2 (loop header) succ #3, #4
+            ...
+            1: ForceOSRExit
+            ...
+            2: JSConstant(0)
+            3: SetLocal(@2, loc6)
+            ...
+            4: Branch(#3, #4)
+
+            Block #3 (This is OSR entry target) pred #2, #3, must handle value for loc6 => JSConstant(Int32, 31)
+            ...
+            5: GetLocal(loc6)
+            6: StringFromCharCode(@5)
+            ...
+
+        Block #3 is OSR entry target. So we have must handle value for loc6 and it is Int32 constant 31. Then we merge this constant as a proven value in #3's loc6 AbstractValue.
+        If the value from #2 blurs the value, it is OK. However, #2 has ForceOSRExit. So must handle value suddenly becomes the only source of loc6 in #3. Then we use this constant
+        as a proven value. But this is not expected behavior since must handle value is just a snapshot of the locals when we kick off the concurrent compilation. In the above example,
+        we assume that loop index is an constant 31, but it is wrong, and OSR entry fails. Because there is no strong assumption that the must handle value is the proven type or value,
+        we should not merge it in CFA.
+
+        Since (1) this is just an optimization, (2) type information is already propagated in prediction injection phase, and (3) the must handle value does not show the performance
+        progression in r211461 and we no longer see type misprediction in marsaglia-osr-entry.js, this patch simply removes must handle value type widening in CFA.
+
+        * dfg/DFGCFAPhase.cpp:
+        (JSC::DFG::CFAPhase::run):
+        (JSC::DFG::CFAPhase::performBlockCFA):
+        (JSC::DFG::CFAPhase::injectOSR): Deleted.
+
+2019-03-07  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] StringFromCharCode fast path should accept 0xff in DFG and FTL
+        https://bugs.webkit.org/show_bug.cgi?id=195429
+
+        Reviewed by Saam Barati.
+
+        We can create single characters without allocation up to 0xff character code. But currently, DFGSpeculativeJIT and FTLLowerDFGToB3 go to the slow path
+        for 0xff case. On the other hand, DFG DoesGC phase says GC won't happen if the child is int32 constant and it is <= 0xff. So, if you have `String.fromCharCode(0xff)`,
+        this breaks the assumption in DFG DoesGC. The correct fix is changing the check in DFGSpeculativeJIT and FTLLowerDFGToB3 from AboveOrEqual to Above.
+        Note that ThunkGenerators's StringFromCharCode thunk was correct.
+
+        * dfg/DFGSpeculativeJIT.cpp:
+        (JSC::DFG::SpeculativeJIT::compileFromCharCode):
+        * ftl/FTLLowerDFGToB3.cpp:
+        (JSC::FTL::DFG::LowerDFGToB3::compileStringFromCharCode):
+
+2019-03-07  Mark Lam  <mark.lam@apple.com>
+
+        Follow up refactoring in try-finally code after r242591.
+        https://bugs.webkit.org/show_bug.cgi?id=195428
+
+        Reviewed by Saam Barati.
+
+        1. Added some comments in emitFinallyCompletion() to describe each completion case.
+        2. Converted CatchEntry into a struct.
+        3. Renamed variable hasBreaksOrContinuesNotCoveredByJumps to hasBreaksOrContinuesThatEscapeCurrentFinally
+           to be more clear about its purpose.
+
+        * bytecompiler/BytecodeGenerator.cpp:
+        (JSC::BytecodeGenerator::generate):
+        (JSC::BytecodeGenerator::emitOutOfLineExceptionHandler):
+        (JSC::BytecodeGenerator::emitFinallyCompletion):
+        * bytecompiler/BytecodeGenerator.h:
+
+2019-03-07  Saam Barati  <sbarati@apple.com>
+
+        CompactVariableMap::Handle's copy operator= leaks the previous data
+        https://bugs.webkit.org/show_bug.cgi?id=195398
+
+        Reviewed by Yusuke Suzuki.
+
+        The copy constructor was just assigning |this| to the new value,
+        forgetting to decrement the ref count of the thing pointed to by
+        the |this| handle. Based on Yusuke's suggestion, this patch refactors
+        the move constructor, move operator=, and copy operator= to use the
+        swap() primitive and the copy constructor primitive.
+
+        * parser/VariableEnvironment.cpp:
+        (JSC::CompactVariableMap::Handle::Handle):
+        (JSC::CompactVariableMap::Handle::swap):
+        (JSC::CompactVariableMap::Handle::operator=): Deleted.
+        * parser/VariableEnvironment.h:
+        (JSC::CompactVariableMap::Handle::Handle):
+        (JSC::CompactVariableMap::Handle::operator=):
+
+2019-03-07  Tadeu Zagallo  <tzagallo@apple.com>
+
+        Lazily decode cached bytecode
+        https://bugs.webkit.org/show_bug.cgi?id=194810
+
+        Reviewed by Saam Barati.
+
+        Like lazy parsing, we should pause at code block boundaries. Instead
+        of always eagerly decoding UnlinkedFunctionExecutable's UnlinkedCodeBlocks,
+        we store their offsets in the executable and lazily decode them on the next
+        call to `unlinkedCodeBlockFor`.
+
+        * bytecode/UnlinkedFunctionExecutable.cpp:
+        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
+        (JSC::UnlinkedFunctionExecutable::~UnlinkedFunctionExecutable):
+        (JSC::UnlinkedFunctionExecutable::visitChildren):
+        (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
+        (JSC::UnlinkedFunctionExecutable::decodeCachedCodeBlocks):
+        * bytecode/UnlinkedFunctionExecutable.h:
+        * runtime/CachedTypes.cpp:
+        (JSC::Decoder::Decoder):
+        (JSC::Decoder::~Decoder):
+        (JSC::Decoder::create):
+        (JSC::Decoder::offsetOf):
+        (JSC::Decoder::cacheOffset):
+        (JSC::Decoder::ptrForOffsetFromBase):
+        (JSC::Decoder::handleForEnvironment const):
+        (JSC::Decoder::setHandleForEnvironment):
+        (JSC::Decoder::addFinalizer):
+        (JSC::VariableLengthObject::isEmpty const):
+        (JSC::CachedWriteBarrier::isEmpty const):
+        (JSC::CachedFunctionExecutable::unlinkedCodeBlockForCall const):
+        (JSC::CachedFunctionExecutable::unlinkedCodeBlockForConstruct const):
+        (JSC::CachedFunctionExecutable::decode const):
+        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
+        (JSC::decodeCodeBlockImpl):
+        (JSC::isCachedBytecodeStillValid):
+        (JSC::decodeFunctionCodeBlock):
+        * runtime/CachedTypes.h:
+        (JSC::Decoder::vm):
+
+2019-03-06  Mark Lam  <mark.lam@apple.com>
+
+        Exception is a JSCell, not a JSObject.
+        https://bugs.webkit.org/show_bug.cgi?id=195392
+
+        Reviewed by Saam Barati.
+
+        Exception is a VM implementation construct to carry a stack trace for the point
+        where it is thrown from.  As a reminder, an Exception is needed because:
+        1. JS code can throw primitives as well that are non-cells.
+        2. Error objects capture the stack trace at the point where they are constructed,
+           which is not always the same as the point where they are thrown (if they are
+           thrown).
+
+        Hence, Exception should not be visible to JS code, and therefore should not be a
+        JSObject.  Hence, it should not inherit from JSDestructibleObject.
+
+        This patch changes the following:
+
+        1. Exception now inherits directly from JSCell instead.
+
+        2. Places where we return an Exception masquerading as a JSObject* are now
+           updated to return a nullptr when we encounter an exception.
+
+        3. We still return Exception* as JSValue or EncodedJSValue when we encounter an
+           exception in functions that return JSValue or EncodedJSValue.  This is because
+           the number that implements the following pattern is too numerous:
+
+                return throw<Some Error>(...)
+
+           We'll leave these as is for now.
+
+        * bytecode/CodeBlock.h:
+        (JSC::ScriptExecutable::prepareForExecution):
+        * interpreter/Interpreter.cpp:
+        (JSC::Interpreter::executeProgram):
+        (JSC::Interpreter::executeCall):
+        (JSC::Interpreter::executeConstruct):
+        (JSC::Interpreter::prepareForRepeatCall):
+        (JSC::Interpreter::execute):
+        (JSC::Interpreter::executeModuleProgram):
+        * jit/JITOperations.cpp:
+        * llint/LLIntSlowPaths.cpp:
+        (JSC::LLInt::setUpCall):
+        * runtime/ConstructData.cpp:
+        (JSC::construct):
+        * runtime/Error.cpp:
+        (JSC::throwConstructorCannotBeCalledAsFunctionTypeError):
+        (JSC::throwTypeError):
+        (JSC::throwSyntaxError):
+        * runtime/Error.h:
+        (JSC::throwRangeError):
+        * runtime/Exception.cpp:
+        (JSC::Exception::createStructure):
+        * runtime/Exception.h:
+        * runtime/ExceptionHelpers.cpp:
+        (JSC::throwOutOfMemoryError):
+        (JSC::throwStackOverflowError):
+        (JSC::throwTerminatedExecutionException):
+        * runtime/ExceptionHelpers.h:
+        * runtime/FunctionConstructor.cpp:
+        (JSC::constructFunction):
+        (JSC::constructFunctionSkippingEvalEnabledCheck):
+        * runtime/IntlPluralRules.cpp:
+        (JSC::IntlPluralRules::resolvedOptions):
+        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
+        (JSC::constructGenericTypedArrayViewWithArguments):
+        * runtime/JSObject.h:
+        * runtime/ObjectConstructor.cpp:
+        (JSC::objectConstructorSeal):
+        (JSC::objectConstructorFreeze):
+        * runtime/ProgramExecutable.cpp:
+        (JSC::ProgramExecutable::initializeGlobalProperties):
+        * runtime/RegExpConstructor.cpp:
+        (JSC::regExpCreate):
+        (JSC::constructRegExp):
+        * runtime/ScriptExecutable.cpp:
+        (JSC::ScriptExecutable::newCodeBlockFor):
+        (JSC::ScriptExecutable::prepareForExecutionImpl):
+        * runtime/ScriptExecutable.h:
+        * runtime/ThrowScope.cpp:
+        (JSC::ThrowScope::throwException):
+        * runtime/ThrowScope.h:
+        (JSC::ThrowScope::throwException):
+        (JSC::throwException):
+        * runtime/VM.cpp:
+        (JSC::VM::throwException):
+        * runtime/VM.h:
+
+2019-03-06  Ross Kirsling  <ross.kirsling@sony.com>
+
+        [Win] Remove -DUCHAR_TYPE=wchar_t stopgap and learn to live with char16_t.
+        https://bugs.webkit.org/show_bug.cgi?id=195346
+
+        Reviewed by Fujii Hironori.
+
+        * jsc.cpp:
+        (currentWorkingDirectory):
+        (fetchModuleFromLocalFileSystem):
+        * runtime/DateConversion.cpp:
+        (JSC::formatDateTime):
+        Use wchar helpers as needed.
+
+2019-03-06  Mark Lam  <mark.lam@apple.com>
+
+        Fix incorrect handling of try-finally completion values.
+        https://bugs.webkit.org/show_bug.cgi?id=195131
+        <rdar://problem/46222079>
+
+        Reviewed by Saam Barati and Yusuke Suzuki.
+
+        Consider the following:
+
+            function foo() {                        // line 1
+                try {
+                    return 42;                      // line 3
+                } finally {
+                    for (var j = 0; j < 1; j++) {   // line 5
+                        try {
+                            throw '';               // line 7
+                        } finally {
+                            continue;               // line 9
+                        }
+                    }
+                }                                   // line 11
+            }
+            var result = foo();
+
+        With the current (before fix) code base, result will be the exception object thrown
+        at line 7.  The expected result should be 42, returned at line 3.
+
+        The bug is that we were previously only using one set of completion type and
+        value registers for the entire function.  This is inadequate because the outer
+        try-finally needs to preserve its own completion type and value ({ Return, 42 }
+        in this case) in order to be able to complete correctly.
+
+        One might be deceived into thinking that the above example should complete with
+        the exception thrown at line 7.  However, according to Section 13.15.8 of the
+        ECMAScript spec, the 'continue' in the finally at line 9 counts as an abrupt
+        completion.  As a result, it overrides the throw from line 7.  After the continue,
+        execution resumes at the top of the loop at line 5, followed by a normal completion
+        at line 11.
+
+        Also according to Section 13.15.8, given that the completion type of the outer
+        finally is normal, the resultant completion of the outer try-finally should be
+        the completion of the outer try block i.e. { Return, 42 }.
+
+        This patch makes the following changes:
+        
+        1. Fix handling of finally completion to use a unique set of completion
+           type and value registers for each FinallyContext.
+
+        2. Move the setting of Throw completion type to the out of line exception handler.
+           This makes the mainline code slightly less branchy.
+
+        3. Introduce emitOutOfLineCatchHandler(), emitOutOfLineFinallyHandler(), and
+           emitOutOfLineExceptionHandler() to make it clearer that these are not emitting
+           bytecode inline.  Also, these make it clearer when we're emitting a handler
+           for a catch vs a finally.
+
+        4. Allocate the FinallyContext on the stack instead of as a member of the
+           heap allocated ControlFlowScope.  This simplifies its life-cycle management
+           and reduces the amount of needed copying.
+
+        5. Update emitFinallyCompletion() to propagate the completion type and value to
+           the outer FinallyContext when needed.
+
+        6. Fix emitJumpIf() to use the right order of operands.  Previously, we were
+           only using it to do op_stricteq and op_nstricteq comparisons.  So, the order
+           wasn't important.  We now use it to also do op_beloweq comparisons.  Hence,
+           the order needs to be corrected.
+
+        7. Remove the unused CompletionType::Break and Continue.  These are encoded with
+           the jumpIDs of the jump targets instead.
+
+        Relevant specifications:
+        Section 13.15.8: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-try-statement-runtime-semantics-evaluation
+        Section 6.3.2.4: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-updateempty
+
+        * bytecompiler/BytecodeGenerator.cpp:
+        (JSC::FinallyContext::FinallyContext):
+        (JSC::BytecodeGenerator::generate):
+        (JSC::BytecodeGenerator::BytecodeGenerator):
+        (JSC::BytecodeGenerator::pushFinallyControlFlowScope):
+        (JSC::BytecodeGenerator::popFinallyControlFlowScope):
+        (JSC::BytecodeGenerator::emitOutOfLineCatchHandler):
+        (JSC::BytecodeGenerator::emitOutOfLineFinallyHandler):
+        (JSC::BytecodeGenerator::emitOutOfLineExceptionHandler):
+        (JSC::BytecodeGenerator::emitEnumeration):
+        (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
+        (JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
+        (JSC::BytecodeGenerator::emitFinallyCompletion):
+        (JSC::BytecodeGenerator::emitJumpIf):
+        (JSC::BytecodeGenerator::emitCatch): Deleted.
+        (JSC::BytecodeGenerator::allocateCompletionRecordRegisters): Deleted.
+        (JSC::BytecodeGenerator::releaseCompletionRecordRegisters): Deleted.
+        * bytecompiler/BytecodeGenerator.h:
+        (JSC::FinallyContext::completionTypeRegister const):
+        (JSC::FinallyContext::completionValueRegister const):
+        (JSC::ControlFlowScope::ControlFlowScope):
+        (JSC::BytecodeGenerator::emitLoad):
+        (JSC::BytecodeGenerator::CompletionRecordScope::CompletionRecordScope): Deleted.
+        (JSC::BytecodeGenerator::CompletionRecordScope::~CompletionRecordScope): Deleted.
+        (JSC::BytecodeGenerator::completionTypeRegister const): Deleted.
+        (JSC::BytecodeGenerator::completionValueRegister const): Deleted.
+        (JSC::BytecodeGenerator::emitSetCompletionType): Deleted.
+        (JSC::BytecodeGenerator::emitSetCompletionValue): Deleted.
+        * bytecompiler/NodesCodegen.cpp:
+        (JSC::TryNode::emitBytecode):
+
+2019-03-06  Saam Barati  <sbarati@apple.com>
+
+        JSScript should keep the cache file locked for the duration of its existence and should truncate the cache when it is out of date
+        https://bugs.webkit.org/show_bug.cgi?id=195186
+
+        Reviewed by Keith Miller.
+
+        This patch makes it so that JSScript will keep its bytecode cache file
+        locked as long as the JSScript is alive. This makes it obvious that it's
+        safe to update that file, as it will only be used in a single VM, across
+        all processes, at a single time. We may be able to extend this in the future
+        if we can atomically update it across VMs/processes. However, we're choosing
+        more restricted semantics now as it's always easier to extend these semantics
+        in the future opposed to having to support the more flexible behavior
+        up front.
+        
+        This patch also:
+        - Adds error messages if writing the cache fails. We don't expect this to
+          fail, but previously we would say we cached it even if write() fails.
+        - Removes the unused m_moduleKey field.
+        - Makes calling cacheBytecodeWithError with an already non-empty cache file fail.
+          In the future, we should extend this to just fill in the parts of the cache
+          that are not present. But we don't have the ability to do that yet, so we
+          just result in an error for now.
+
+        * API/JSScript.mm:
+        (-[JSScript dealloc]):
+        (-[JSScript readCache]):
+        (-[JSScript init]):
+        (-[JSScript writeCache:]):
+        * API/JSScriptInternal.h:
+        * API/tests/testapi.mm:
+        (testCacheFileIsExclusive):
+        (testCacheFileFailsWhenItsAlreadyCached):
+        (testObjectiveCAPI):
+
+2019-03-06  Christopher Reid  <chris.reid@sony.com>
+
+        Followups to (r242306): Use LockHolder instead of std::lock_guard on Remote Inspector Locks
+        https://bugs.webkit.org/show_bug.cgi?id=195381
+
+        Reviewed by Mark Lam.
+
+        Replacing std::lock_guard uses in Remote Inspector with WTF::LockHolder.
+        Also using `= { }` for struct initialization instead of memeset.
+
+        * inspector/remote/RemoteConnectionToTarget.cpp:
+        * inspector/remote/RemoteInspector.cpp:
+        * inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
+        * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
+        * inspector/remote/cocoa/RemoteInspectorXPCConnection.mm:
+        * inspector/remote/glib/RemoteInspectorGlib.cpp:
+        * inspector/remote/playstation/RemoteInspectorPlayStation.cpp:
+        * inspector/remote/playstation/RemoteInspectorSocketClientPlayStation.cpp:
+        * inspector/remote/playstation/RemoteInspectorSocketPlayStation.cpp:
+        * inspector/remote/playstation/RemoteInspectorSocketServerPlayStation.cpp:
+
+2019-03-06  Saam Barati  <sbarati@apple.com>
+
+        Air::reportUsedRegisters must padInterference
+        https://bugs.webkit.org/show_bug.cgi?id=195303
+        <rdar://problem/48270343>
+
+        Reviewed by Keith Miller.
+
+        reportUsedRegisters uses reg liveness to eliminate loads/moves into dead
+        registers. However, liveness can report incorrect results in certain 
+        scenarios when considering liveness at instruction boundaries. For example,
+        it can go wrong when an Inst has a LateUse of a register and the following
+        Inst has an EarlyDef of that same register. Such a scenario could lead us
+        to incorrectly say the register is not live-in to the first Inst. Pad
+        interference inserts Nops between such instruction boundaries that cause
+        this issue.
+        
+        The test with this patch fixes the issue in reportUsedRegisters. This patch
+        also conservatively makes it so that lowerAfterRegAlloc calls padInterference
+        since it also reasons about liveness.
+
+        * b3/air/AirLowerAfterRegAlloc.cpp:
+        (JSC::B3::Air::lowerAfterRegAlloc):
+        * b3/air/AirPadInterference.h:
+        * b3/air/AirReportUsedRegisters.cpp:
+        (JSC::B3::Air::reportUsedRegisters):
+        * b3/testb3.cpp:
+        (JSC::B3::testReportUsedRegistersLateUseNotDead):
+        (JSC::B3::run):
+
+2019-03-06  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] AI should not propagate AbstractValue relying on constant folding phase
+        https://bugs.webkit.org/show_bug.cgi?id=195375
+
+        Reviewed by Saam Barati.
+
+        MakeRope rule in AI attempts to propagate the node, which will be produced after constant folding phase runs.
+        This is wrong since we do not guarantee that constant folding phase runs after AI runs (e.g. DFGSpeculativeJIT
+        and FTLLowerDFGToB3 run AI). This results in the bug that the value produced at runtime is different from the
+        proven constant value in AI. In the attached test, AI says the value is SpecStringIdent while the resulted value
+        at runtime is SpecStringVar, resulting in wrong MakeRope code. This patch removes the path propagating the node
+        relying on constant folding phase.
+
+        * dfg/DFGAbstractInterpreterInlines.h:
+        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+
+2019-03-05  Saam barati  <sbarati@apple.com>
+
+        op_switch_char broken for rope strings after JSRopeString layout rewrite
+        https://bugs.webkit.org/show_bug.cgi?id=195339
+        <rdar://problem/48592545>
+
+        Reviewed by Yusuke Suzuki.
+
+        When we did the JSString rewrite, we accidentally broke LLInt's switch_char
+        for rope strings. That change made it so that we always go to the slow path
+        for ropes. That's wrong. The slow path should only be taken when the rope
+        is of length 1. For lengths other than 1, we need to fall through to the
+        default case. This patch fixes this.
+
+        * llint/LowLevelInterpreter32_64.asm:
+        * llint/LowLevelInterpreter64.asm:
+        * runtime/JSString.h:
+
+2019-03-05  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Should check exception for JSString::toExistingAtomicString
+        https://bugs.webkit.org/show_bug.cgi?id=195337
+
+        Reviewed by Keith Miller, Saam Barati, and Mark Lam.
+
+        We missed the exception check for JSString::toExistingAtomicString while it can resolve
+        a rope and throw an OOM exception. This patch adds necessary exception checks. This patch
+        fixes test failures in debug build, reported in https://bugs.webkit.org/show_bug.cgi?id=194375#c93.
+
+        * dfg/DFGOperations.cpp:
+        * jit/JITOperations.cpp:
+        (JSC::getByVal):
+        * llint/LLIntSlowPaths.cpp:
+        (JSC::LLInt::getByVal):
+        * runtime/CommonSlowPaths.cpp:
+        (JSC::SLOW_PATH_DECL):
+
+2019-03-04  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        Unreviewed, build fix for debug builds after r242397
+
+        * runtime/JSString.h:
+
+2019-03-04  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Store bits for JSRopeString in 3 stores
+        https://bugs.webkit.org/show_bug.cgi?id=195234
+
+        Reviewed by Saam Barati.
+
+        This patch cleans up the initialization of JSRopeString fields in DFG and FTL.
+        Previously, we store some part of data separately. Instead, this patch calculates
+        the data first by bit operations and store calculated data with fewer stores.
+
+        This patch also cleans up is8Bit and isSubstring flags. We put them in lower bits
+        of the first fiber instead of the upper 16 bits. Since we only have 3 bit flags, (isRope, is8Bit, isSubstring),
+        we can put them into the lower 3 bits, they are always empty due to alignment.
+
+        * bytecode/AccessCase.cpp:
+        (JSC::AccessCase::generateImpl): A bit clean up of StringLength IC to give a chance of unnecessary mov removal.
+        * dfg/DFGSpeculativeJIT.cpp:
+        (JSC::DFG::SpeculativeJIT::canBeRope):
+        (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
+        (JSC::DFG::SpeculativeJIT::compileMakeRope):
+        * dfg/DFGSpeculativeJIT.h:
+        * ftl/FTLAbstractHeapRepository.cpp:
+        (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
+        * ftl/FTLAbstractHeapRepository.h:
+        * ftl/FTLLowerDFGToB3.cpp:
+        (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
+        (JSC::FTL::DFG::LowerDFGToB3::isRopeString):
+        (JSC::FTL::DFG::LowerDFGToB3::isNotRopeString):
+        * runtime/JSString.cpp:
+        (JSC::JSString::visitChildren):
+        * runtime/JSString.h:
+        (JSC::JSString::is8Bit const):
+        (JSC::JSString::isSubstring const):
+        * tools/JSDollarVM.cpp:
+        (JSC::functionCreateNullRopeString):
+        (JSC::JSDollarVM::finishCreation):
+
+2019-03-04  Joseph Pecoraro  <pecoraro@apple.com>
+
+        ITMLKit Inspector: Data Bindings / Associated Data for nodes
+        https://bugs.webkit.org/show_bug.cgi?id=195290
+        <rdar://problem/48304019>
+
+        Reviewed by Devin Rousso.
+
+        * inspector/protocol/DOM.json:
+
+2019-03-04  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Make Reflect lazily-allocated by dropping @Reflect references from builtin JS
+        https://bugs.webkit.org/show_bug.cgi?id=195250
+
+        Reviewed by Saam Barati.
+
+        By removing @Reflect from builtin JS, we can make Reflect object allocation lazy.
+        We move @ownKeys function from @Reflect to @Object to remove @Reflect reference.
+
+        We also remove m_intlObject field from JSGlobalObject since we no longer use it.
+
+        * builtins/BuiltinNames.h:
+        * builtins/GlobalOperations.js:
+        (globalPrivate.copyDataProperties):
+        (globalPrivate.copyDataPropertiesNoExclusions):
+        * runtime/JSGlobalObject.cpp:
+        (JSC::createReflectProperty):
+        (JSC::JSGlobalObject::init):
+        (JSC::JSGlobalObject::visitChildren):
+        * runtime/JSGlobalObject.h:
+        * runtime/ObjectConstructor.cpp:
+        (JSC::ObjectConstructor::finishCreation):
+        (JSC::objectConstructorOwnKeys):
+        * runtime/ReflectObject.cpp:
+        (JSC::ReflectObject::finishCreation):
+
+2019-03-04  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Offer @makeTypeError instead of exposing @TypeError
+        https://bugs.webkit.org/show_bug.cgi?id=193858
+
+        Reviewed by Mark Lam.
+
+        Instead of exposing @TypeError, we expose @makeTypeError function.
+        And we make TypeError and Error lazily-allocated objects in non JIT environment.
+        In JIT environment, only TypeError becomes lazily-allocated since WebAssembly errors
+        touch Error prototype anyway. But we can make them lazy in a subsequent patch.
+
+        * builtins/AsyncFromSyncIteratorPrototype.js:
+        * builtins/AsyncGeneratorPrototype.js:
+        (globalPrivate.asyncGeneratorEnqueue):
+        * builtins/BuiltinNames.h:
+        * builtins/PromiseOperations.js:
+        (globalPrivate.createResolvingFunctions.resolve):
+        * runtime/JSGlobalObject.cpp:
+        (JSC::JSGlobalObject::initializeErrorConstructor):
+        (JSC::JSGlobalObject::init):
+        (JSC::JSGlobalObject::visitChildren):
+        * runtime/JSGlobalObject.h:
+        (JSC::JSGlobalObject::errorPrototype const):
+        (JSC::JSGlobalObject::errorStructure const):
+        * runtime/JSGlobalObjectFunctions.cpp:
+        (JSC::globalFuncMakeTypeError):
+        * runtime/JSGlobalObjectFunctions.h:
+
+2019-03-04  Carlos Garcia Campos  <cgarcia@igalia.com>
+
+        [GLib] Returning G_TYPE_OBJECT from a constructor does not work
+        https://bugs.webkit.org/show_bug.cgi?id=195206
+
+        Reviewed by Žan Doberšek.
+
+        We are freeing the newly created object before returning from the constructor.
+
+        * API/glib/JSCCallbackFunction.cpp:
+        (JSC::JSCCallbackFunction::construct):
+
+2019-03-02  Darin Adler  <darin@apple.com>
+
+        Retire legacy dtoa function and DecimalNumber class
+        https://bugs.webkit.org/show_bug.cgi?id=195253
+
+        Reviewed by Daniel Bates.
+
+        * runtime/NumberPrototype.cpp:
+        (JSC::numberProtoFuncToExponential): Removed dependency on NumberToStringBufferLength,
+        using NumberToStringBuffer instead. Also tweaked style of implementation a bit.
+
+2019-03-01  Darin Adler  <darin@apple.com>
+
+        Finish removing String::format
+        https://bugs.webkit.org/show_bug.cgi?id=194893
+
+        Reviewed by Daniel Bates.
+
+        * bytecode/CodeBlock.cpp:
+        (JSC::CodeBlock::nameForRegister): Use makeString instead of String::format,
+        using the new "pad" function.
+
+2019-03-01  Christopher Reid  <chris.reid@sony.com>
+
+        [PlayStation] Upstream playstation's remote inspector server
+        https://bugs.webkit.org/show_bug.cgi?id=193806
+
+        Reviewed by Joseph Pecoraro.
+
+        Upstreaming PlayStation's Remote Inspector implementation.
+        It is using a JSON RPC protocol over TCP sockets.
+        This inspector implementation is planned to also support running on a WinCairo Client and Server.
+
+        * PlatformPlayStation.cmake:
+        * SourcesGTK.txt:
+        * SourcesWPE.txt:
+        * inspector/remote/RemoteConnectionToTarget.cpp: Renamed from Source/JavaScriptCore/inspector/remote/glib/RemoteConnectionToTargetGlib.cpp.
+        * inspector/remote/RemoteInspector.h:
+        * inspector/remote/playstation/RemoteInspectorConnectionClient.h: Added.
+        * inspector/remote/playstation/RemoteInspectorConnectionClientPlayStation.cpp: Added.
+        * inspector/remote/playstation/RemoteInspectorMessageParser.h: Added.
+        * inspector/remote/playstation/RemoteInspectorMessageParserPlayStation.cpp: Added.
+        * inspector/remote/playstation/RemoteInspectorPlayStation.cpp: Added.
+        * inspector/remote/playstation/RemoteInspectorServer.h: Added.
+        * inspector/remote/playstation/RemoteInspectorServerPlayStation.cpp: Added.
+        * inspector/remote/playstation/RemoteInspectorSocket.h: Added.
+        * inspector/remote/playstation/RemoteInspectorSocketClient.h: Added.
+        * inspector/remote/playstation/RemoteInspectorSocketClientPlayStation.cpp: Added.
+        * inspector/remote/playstation/RemoteInspectorSocketPlayStation.cpp: Added.
+        * inspector/remote/playstation/RemoteInspectorSocketServer.h: Added.
+        * inspector/remote/playstation/RemoteInspectorSocketServerPlayStation.cpp: Added.
+
+2019-03-01  Saam Barati  <sbarati@apple.com>
+
+        Create SPI to crash if a JSC VM is created
+        https://bugs.webkit.org/show_bug.cgi?id=195231
+        <rdar://problem/47717990>
+
+        Reviewed by Mark Lam.
+
+        * API/JSVirtualMachine.mm:
+        (+[JSVirtualMachine setCrashOnVMCreation:]):
+        * API/JSVirtualMachinePrivate.h:
+        * runtime/VM.cpp:
+        (JSC::VM::VM):
+        (JSC::VM::setCrashOnVMCreation):
+        * runtime/VM.h:
+
+2019-03-01  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Fix FTL build on ARM32_64 by adding stubs for JSRopeString::offsetOfXXX
+        https://bugs.webkit.org/show_bug.cgi?id=195235
+
+        Reviewed by Saam Barati.
+
+        This is a workaround until https://bugs.webkit.org/show_bug.cgi?id=195234 is done.
+
+        * runtime/JSString.h:
+
+2019-03-01  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Use runtime calls for DFG MakeRope if !CPU(ADDRESS64)
+        https://bugs.webkit.org/show_bug.cgi?id=195221
+
+        Reviewed by Mark Lam.
+
+        ARM32_64 builds DFG 64bit, but the size of address is 32bit. Make DFG MakeRope a runtime call not only for DFG 32_64,
+        but also DFG 64 with !CPU(ADDRESS64). This patch unifies compileMakeRope again, and use a runtime call for !CPU(ADDRESS64).
+
+        * dfg/DFGSpeculativeJIT.cpp:
+        (JSC::DFG::SpeculativeJIT::compileMakeRope):
+        * dfg/DFGSpeculativeJIT32_64.cpp:
+        (JSC::DFG::SpeculativeJIT::compileMakeRope): Deleted.
+        * dfg/DFGSpeculativeJIT64.cpp:
+        (JSC::DFG::SpeculativeJIT::compileMakeRope): Deleted.
+
+2019-03-01  Justin Fan  <justin_fan@apple.com>
+
+        [Web GPU] 32-bit builds broken by attempt to disable WebGPU on 32-bit
+        https://bugs.webkit.org/show_bug.cgi?id=195191
+
+        Rubber-stamped by Dean Jackson.
+
+        Dropping support for 32-bit entirely, so I'm intentionally leaving 32-bit broken.
+
+        * Configurations/FeatureDefines.xcconfig:
+
+2019-03-01  Dominik Infuehr  <dinfuehr@igalia.com>
+
+        Fix debug builds with GCC
+        https://bugs.webkit.org/show_bug.cgi?id=195205
+
+        Unreviewed. Fix debug builds in GCC by removing
+        the constexpr-keyword for this function.
+
+        * runtime/CachedTypes.cpp:
+        (JSC::tagFromSourceCodeType):
+
+2019-03-01  Dominik Infuehr  <dinfuehr@igalia.com>
+
+        [ARM] Fix assembler warnings in ctiMasmProbeTrampoline
+        https://bugs.webkit.org/show_bug.cgi?id=195164
+
+        Reviewed by Mark Lam.
+
+        Short branches in IT blocks are deprecated in AArch32. In addition the
+        the conditional branch was the only instruction in the IT block. Short
+        branches are able to encode the condition code themselves, the additional
+        IT instruction is not needed.
+
+        The assembler was also warning that writing into APSR without a bitmask
+        was deprecated. Therefore use APSR_nzcvq instead, this generates the same
+        instruction encoding.
+
+        * assembler/MacroAssemblerARMv7.cpp:
+
+2019-02-28  Tadeu Zagallo  <tzagallo@apple.com>
+
+        Remove CachedPtr::m_isEmpty and CachedOptional::m_isEmpty fields
+        https://bugs.webkit.org/show_bug.cgi?id=194999
+
+        Reviewed by Saam Barati.
+
+        These fields are unnecessary, since we can just check that m_offset
+        has not been initialized (I added VariableLengthObject::isEmpty for
+        that). They also add 7-byte padding to these classes, which is pretty
+        bad given how frequently CachedPtr is used.
+
+        * runtime/CachedTypes.cpp:
+        (JSC::CachedObject::operator new[]):
+        (JSC::VariableLengthObject::allocate):
+        (JSC::VariableLengthObject::isEmpty const):
+        (JSC::CachedPtr::encode):
+        (JSC::CachedPtr::decode const):
+        (JSC::CachedPtr::get const):
+        (JSC::CachedOptional::encode):
+        (JSC::CachedOptional::decode const):
+        (JSC::CachedOptional::decodeAsPtr const):
+
+2019-02-28  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] sizeof(JSString) should be 16
+        https://bugs.webkit.org/show_bug.cgi?id=194375
+
+        Reviewed by Saam Barati.
+
+        This patch reduces sizeof(JSString) from 24 to 16 to fit it into GC heap cell atom. And it also reduces sizeof(JSRopeString) from 48 to 32.
+        Both classes cut 16 bytes per instance in GC allocation. This new layout is used in 64bit architectures which has little endianess.
+
+        JSString no longer has length and flags directly. JSString has String, and we query information to this String instead of holding duplicate
+        information in JSString. We embed isRope bit into this String's pointer so that we can convert JSRopeString to JSString in an atomic manner.
+        We emit store-store fence before we put String pointer. This should exist even before this patch, so this patch also fixes one concurrency issue.
+
+        The old JSRopeString separately had JSString* fibers along with String. In this patch, we merge the first JSString* fiber and String pointer
+        storage into one to reduce the size of JSRopeString. JSRopeString has three pointer width storage. We pick 48bit effective address of JSString*
+        fibers to compress three fibers + length + flags into three pointer width storage.
+
+        In 64bit architecture, JSString and JSRopeString have the following memory layout to make sizeof(JSString) == 16 and sizeof(JSRopeString) == 32.
+        JSString has only one pointer. We use it for String. length() and is8Bit() queries go to StringImpl. In JSRopeString, we reuse the above pointer
+        place for the 1st fiber. JSRopeString has three fibers so its size is 48. To keep length and is8Bit flag information in JSRopeString, JSRopeString
+        encodes these information into the fiber pointers. is8Bit flag is encoded in the 1st fiber pointer. length is embedded directly, and two fibers
+        are compressed into 12bytes. isRope information is encoded in the first fiber's LSB.
+
+        Since length of JSRopeString should be frequently accessed compared to each fiber, we put length in contiguous 32byte field, and compress 2nd
+        and 3rd fibers into the following 80byte fields. One problem is that now 2nd and 3rd fibers are split. Storing and loading 2nd and 3rd fibers
+        are not one pointer load operation. To make concurrent collector work correctly, we must initialize 2nd and 3rd fibers at JSRopeString creation
+        and we must not modify these part later.
+
+                     0                        8        10               16                       32                                     48
+        JSString     [   ID      ][  header  ][   String pointer      0]
+        JSRopeString [   ID      ][  header  ][ flags ][ 1st fiber    1][  length  ][2nd lower32][2nd upper16][3rd lower16][3rd upper32]
+                                                                      ^
+                                                                   isRope bit
+
+        Since fibers in JSRopeString are not initialized in atomic pointer store manner, we must initialize all the fiber fields at JSRopeString creation.
+        To achieve this, we modify our JSRopeString::RopeBuilder implementation not to create half-baked JSRopeString.
+
+        This patch also makes an empty JSString singleton per VM. This makes evaluation of JSString in boolean context one pointer comparison. This is
+        critical in this change since this patch enlarges the code necessary to get length from JSString in JIT. Without this guarantee, our code of boolean
+        context evaluation is bloated. This patch hides all the JSString::create and JSRopeString::create in the private permission. JSString and JSRopeString
+        creation is only allowed from jsString and related helper functions and they return a singleton empty JSString if the length is zero. We also change
+        JSRopeString::RopeBuilder not to construct an empty JSRopeString.
+
+        This patch is performance neutral in Speedometer2 and JetStream2. And it improves RAMification by 2.7%.
+
+        * JavaScriptCore.xcodeproj/project.pbxproj:
+        * assembler/MacroAssemblerARM64.h:
+        (JSC::MacroAssemblerARM64::storeZero16):
+        * assembler/MacroAssemblerX86Common.h:
+        (JSC::MacroAssemblerX86Common::storeZero16):
+        (JSC::MacroAssemblerX86Common::store16):
+        * bytecode/AccessCase.cpp:
+        (JSC::AccessCase::generateImpl):
+        * bytecode/InlineAccess.cpp:
+        (JSC::InlineAccess::dumpCacheSizesAndCrash):
+        (JSC::linkCodeInline):
+        (JSC::InlineAccess::isCacheableStringLength):
+        (JSC::InlineAccess::generateStringLength):
+        * bytecode/InlineAccess.h:
+        (JSC::InlineAccess::sizeForPropertyAccess):
+        (JSC::InlineAccess::sizeForPropertyReplace):
+        (JSC::InlineAccess::sizeForLengthAccess):
+        * dfg/DFGOperations.cpp:
+        * dfg/DFGOperations.h:
+        * dfg/DFGSpeculativeJIT.cpp:
+        (JSC::DFG::SpeculativeJIT::compileStringSlice):
+        (JSC::DFG::SpeculativeJIT::compileToLowerCase):
+        (JSC::DFG::SpeculativeJIT::compileGetCharCodeAt):
+        (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
+        (JSC::DFG::SpeculativeJIT::compileStringEquality):
+        (JSC::DFG::SpeculativeJIT::compileStringZeroLength):
+        (JSC::DFG::SpeculativeJIT::compileLogicalNotStringOrOther):
+        (JSC::DFG::SpeculativeJIT::emitStringBranch):
+        (JSC::DFG::SpeculativeJIT::emitStringOrOtherBranch):
+        (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
+        (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
+        (JSC::DFG::SpeculativeJIT::emitPopulateSliceIndex):
+        (JSC::DFG::SpeculativeJIT::compileArraySlice):
+        (JSC::DFG::SpeculativeJIT::compileArrayIndexOf):
+        (JSC::DFG::SpeculativeJIT::speculateStringIdentAndLoadStorage):
+        (JSC::DFG::SpeculativeJIT::emitSwitchCharStringJump):
+        (JSC::DFG::SpeculativeJIT::emitSwitchStringOnString):
+        (JSC::DFG::SpeculativeJIT::compileMakeRope): Deleted.
+        * dfg/DFGSpeculativeJIT.h:
+        * dfg/DFGSpeculativeJIT32_64.cpp:
+        (JSC::DFG::SpeculativeJIT::compile):
+        (JSC::DFG::SpeculativeJIT::compileMakeRope):
+        * dfg/DFGSpeculativeJIT64.cpp:
+        (JSC::DFG::SpeculativeJIT::compile):
+        (JSC::DFG::SpeculativeJIT::compileMakeRope):
+        * ftl/FTLAbstractHeapRepository.cpp:
+        (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
+        * ftl/FTLAbstractHeapRepository.h:
+        * ftl/FTLLowerDFGToB3.cpp:
+        (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage):
+        (JSC::FTL::DFG::LowerDFGToB3::compileGetArrayLength):
+        (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
+        (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
+        (JSC::FTL::DFG::LowerDFGToB3::compileStringCharCodeAt):
+        (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
+        (JSC::FTL::DFG::LowerDFGToB3::compileStringToUntypedStrictEquality):
+        (JSC::FTL::DFG::LowerDFGToB3::compileSwitch):
+        (JSC::FTL::DFG::LowerDFGToB3::mapHashString):
+        (JSC::FTL::DFG::LowerDFGToB3::compileMapHash):
+        (JSC::FTL::DFG::LowerDFGToB3::compileHasOwnProperty):
+        (JSC::FTL::DFG::LowerDFGToB3::compileStringSlice):
+        (JSC::FTL::DFG::LowerDFGToB3::compileToLowerCase):
+        (JSC::FTL::DFG::LowerDFGToB3::stringsEqual):
+        (JSC::FTL::DFG::LowerDFGToB3::boolify):
+        (JSC::FTL::DFG::LowerDFGToB3::switchString):
+        (JSC::FTL::DFG::LowerDFGToB3::isRopeString):
+        (JSC::FTL::DFG::LowerDFGToB3::isNotRopeString):
+        (JSC::FTL::DFG::LowerDFGToB3::speculateStringIdent):
+        * jit/AssemblyHelpers.cpp:
+        (JSC::AssemblyHelpers::emitConvertValueToBoolean):
+        (JSC::AssemblyHelpers::branchIfValue):
+        * jit/AssemblyHelpers.h:
+        (JSC::AssemblyHelpers::branchIfRopeStringImpl):
+        (JSC::AssemblyHelpers::branchIfNotRopeStringImpl):
+        * jit/JITInlines.h:
+        (JSC::JIT::emitLoadCharacterString):
+        * jit/Repatch.cpp:
+        (JSC::tryCacheGetByID):
+        * jit/ThunkGenerators.cpp:
+        (JSC::stringGetByValGenerator):
+        (JSC::stringCharLoad):
+        * llint/LowLevelInterpreter.asm:
+        * llint/LowLevelInterpreter32_64.asm:
+        * llint/LowLevelInterpreter64.asm:
+        * runtime/JSString.cpp:
+        (JSC::JSString::createEmptyString):
+        (JSC::JSRopeString::RopeBuilder<RecordOverflow>::expand):
+        (JSC::JSString::dumpToStream):
+        (JSC::JSString::estimatedSize):
+        (JSC::JSString::visitChildren):
+        (JSC::JSRopeString::resolveRopeInternal8 const):
+        (JSC::JSRopeString::resolveRopeInternal8NoSubstring const):
+        (JSC::JSRopeString::resolveRopeInternal16 const):
+        (JSC::JSRopeString::resolveRopeInternal16NoSubstring const):
+        (JSC::JSRopeString::resolveRopeToAtomicString const):
+        (JSC::JSRopeString::convertToNonRope const):
+        (JSC::JSRopeString::resolveRopeToExistingAtomicString const):
+        (JSC::JSRopeString::resolveRopeWithFunction const):
+        (JSC::JSRopeString::resolveRope const):
+        (JSC::JSRopeString::resolveRopeSlowCase8 const):
+        (JSC::JSRopeString::resolveRopeSlowCase const):
+        (JSC::JSRopeString::outOfMemory const):
+        (JSC::JSRopeString::visitFibers): Deleted.
+        (JSC::JSRopeString::clearFibers const): Deleted.
+        * runtime/JSString.h:
+        (JSC::JSString::uninitializedValueInternal const):
+        (JSC::JSString::valueInternal const):
+        (JSC::JSString::JSString):
+        (JSC::JSString::finishCreation):
+        (JSC::JSString::create):
+        (JSC::JSString::offsetOfValue):
+        (JSC::JSString::isRope const):
+        (JSC::JSString::is8Bit const):
+        (JSC::JSString::length const):
+        (JSC::JSString::tryGetValueImpl const):
+        (JSC::JSString::toAtomicString const):
+        (JSC::JSString::toExistingAtomicString const):
+        (JSC::JSString::value const):
+        (JSC::JSString::tryGetValue const):
+        (JSC::JSRopeString::unsafeView const):
+        (JSC::JSRopeString::viewWithUnderlyingString const):
+        (JSC::JSString::unsafeView const):
+        (JSC::JSString::viewWithUnderlyingString const):
+        (JSC::JSString::offsetOfLength): Deleted.
+        (JSC::JSString::offsetOfFlags): Deleted.
+        (JSC::JSString::setIs8Bit const): Deleted.
+        (JSC::JSString::setLength): Deleted.
+        (JSC::JSString::string): Deleted.
+        (JSC::jsStringBuilder): Deleted.
+        * runtime/JSStringInlines.h:
+        (JSC::JSString::~JSString):
+        (JSC::JSString::equal const):
+        * runtime/ObjectPrototype.cpp:
+        (JSC::objectProtoFuncToString):
+        * runtime/RegExpMatchesArray.h:
+        (JSC::createRegExpMatchesArray):
+        * runtime/RegExpObjectInlines.h:
+        (JSC::collectMatches):
+        * runtime/RegExpPrototype.cpp:
+        (JSC::regExpProtoFuncSplitFast):
+        * runtime/SmallStrings.cpp:
+        (JSC::SmallStrings::initializeCommonStrings):
+        (JSC::SmallStrings::createEmptyString): Deleted.
+        * runtime/SmallStrings.h:
+        * runtime/StringPrototype.cpp:
+        (JSC::stringProtoFuncSlice):
+        * runtime/StringPrototypeInlines.h: Added.
+        (JSC::stringSlice):
+
+2019-02-28  Saam barati  <sbarati@apple.com>
+
+        Unreviewed. Attempt windows build fix after r242239.
+
+        * runtime/CachedTypes.cpp:
+        (JSC::tagFromSourceCodeType):
+
+2019-02-28  Mark Lam  <mark.lam@apple.com>
+
+        In cloop.rb, rename :int and :uint to :intptr and :uintptr.
+        https://bugs.webkit.org/show_bug.cgi?id=195183
+
+        Reviewed by Yusuke Suzuki.
+
+        Also changed intMemRef and uintMemRef to intptrMemRef and uintptrMemRef respectively.
+
+        * offlineasm/cloop.rb:
+
+2019-02-28  Saam barati  <sbarati@apple.com>
+
+        Make JSScript:cacheBytecodeWithError update the cache when the script changes
+        https://bugs.webkit.org/show_bug.cgi?id=194912
+
+        Reviewed by Mark Lam.
+
+        Prior to this patch, the JSScript SPI would never check if its cached
+        bytecode were still valid. This would lead the cacheBytecodeWithError
+        succeeding even if the underlying cache were stale. This patch fixes
+        that by making JSScript check if the cache is still valid. If it's not,
+        we will cache bytecode when cacheBytecodeWithError is invoked.
+
+        * API/JSScript.mm:
+        (-[JSScript readCache]):
+        (-[JSScript writeCache:]):
+        * API/tests/testapi.mm:
+        (testBytecodeCacheWithSameCacheFileAndDifferentScript):
+        (testObjectiveCAPI):
+        * runtime/CachedTypes.cpp:
+        (JSC::Decoder::Decoder):
+        (JSC::VariableLengthObject::buffer const):
+        (JSC::CachedPtr::decode const):
+        (JSC::tagFromSourceCodeType):
+        (JSC::GenericCacheEntry::isUpToDate const):
+        (JSC::CacheEntry::isStillValid const):
+        (JSC::GenericCacheEntry::decode const):
+        (JSC::GenericCacheEntry::isStillValid const):
+        (JSC::encodeCodeBlock):
+        (JSC::decodeCodeBlockImpl):
+        (JSC::isCachedBytecodeStillValid):
+        * runtime/CachedTypes.h:
+        * runtime/CodeCache.cpp:
+        (JSC::sourceCodeKeyForSerializedBytecode):
+        (JSC::sourceCodeKeyForSerializedProgram):
+        (JSC::sourceCodeKeyForSerializedModule):
+        (JSC::serializeBytecode):
+        * runtime/CodeCache.h:
+        (JSC::CodeCacheMap::fetchFromDiskImpl):
+        * runtime/Completion.cpp:
+        (JSC::generateProgramBytecode):
+        (JSC::generateBytecode): Deleted.
+        * runtime/Completion.h:
+
+2019-02-28  Mark Lam  <mark.lam@apple.com>
+
+        cloop.rb shift mask should depend on the word size being shifted.
+        https://bugs.webkit.org/show_bug.cgi?id=195181
+        <rdar://problem/48484164>
+
+        Reviewed by Yusuke Suzuki.
+
+        Previously, we're always masking the shift amount with 0x1f.  This is only correct
+        for 32-bit words.  For 64-bit words, the mask should be 0x3f.  For pointer sized
+        shifts, the mask depends on sizeof(uintptr_t).
+
+        * offlineasm/cloop.rb:
+
+2019-02-28  Justin Fan  <justin_fan@apple.com>
+
+        [Web GPU] Enable Web GPU only on 64-bit
+        https://bugs.webkit.org/show_bug.cgi?id=195139
+
+        Because Metal is only supported on 64 bit apps.
+
+        Unreviewed build fix.
+
+        * Configurations/FeatureDefines.xcconfig:
+
+2019-02-27  Mark Lam  <mark.lam@apple.com>
+
+        The parser is failing to record the token location of new in new.target.
+        https://bugs.webkit.org/show_bug.cgi?id=195127
+        <rdar://problem/39645578>
+
+        Reviewed by Yusuke Suzuki.
+
+        Also adjust the token location for the following to be as shown:
+
+            new.target
+            ^
+            super
+            ^
+            import.meta
+            ^
+
+        * parser/Parser.cpp:
+        (JSC::Parser<LexerType>::parseMemberExpression):
+
+2019-02-27  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] mustHandleValues for dead bytecode locals should be ignored in DFG phases
+        https://bugs.webkit.org/show_bug.cgi?id=195144
+        <rdar://problem/47595961>
+
+        Reviewed by Mark Lam.
+
+        DFGMaximalFlushInsertionPhase inserts Flush for all the locals at the end of basic blocks. This enlarges the live ranges of
+        locals in DFG, and it sometimes makes DFG value live while it is dead in bytecode. The issue happens when we use mustHandleValues
+        to widen AbstractValue in CFAPhase. At that time, DFG tells "this value is live in DFG", but it may be dead in the bytecode level.
+        At that time, we attempt to merge AbstractValue with dead mustHandleValue, which is cleared as jsUndefined() in
+        DFG::Plan::cleanMustHandleValuesIfNecessary before start compilation, and crash because jsUndefined() may be irrelevant to the FlushFormat
+        in VariableAccessData.
+
+        This patch makes the type of mustHandleValues Operands<Optional<JSValue>>. We clear dead JSValues in DFG::Plan::cleanMustHandleValuesIfNecessary.
+        And we skip handling dead mustHandleValue in DFG phases.
+
+        * bytecode/Operands.h:
+        (JSC::Operands::isLocal const):
+        (JSC::Operands::isVariable const): Deleted.
+        * dfg/DFGCFAPhase.cpp:
+        (JSC::DFG::CFAPhase::injectOSR):
+        * dfg/DFGDriver.cpp:
+        (JSC::DFG::compileImpl):
+        (JSC::DFG::compile):
+        * dfg/DFGDriver.h:
+        * dfg/DFGJITCode.cpp:
+        (JSC::DFG::JITCode::reconstruct):
+        * dfg/DFGJITCode.h:
+        * dfg/DFGOperations.cpp:
+        * dfg/DFGPlan.cpp:
+        (JSC::DFG::Plan::Plan):
+        (JSC::DFG::Plan::checkLivenessAndVisitChildren):
+        (JSC::DFG::Plan::cleanMustHandleValuesIfNecessary):
+        * dfg/DFGPlan.h:
+        (JSC::DFG::Plan::mustHandleValues const):
+        * dfg/DFGPredictionInjectionPhase.cpp:
+        (JSC::DFG::PredictionInjectionPhase::run):
+        * dfg/DFGTypeCheckHoistingPhase.cpp:
+        (JSC::DFG::TypeCheckHoistingPhase::disableHoistingAcrossOSREntries):
+        * ftl/FTLOSREntry.cpp:
+        (JSC::FTL::prepareOSREntry):
+        * jit/JITOperations.cpp:
+
+2019-02-27  Simon Fraser  <simon.fraser@apple.com>
+
+        Roll out r242014; it caused crashes in compositing logging (webkit.org/b/195141)
+
+        * bytecode/CodeBlock.cpp:
+        (JSC::CodeBlock::nameForRegister):
+
+2019-02-27  Robin Morisset  <rmorisset@apple.com>
+
+        DFG: Loop-invariant code motion (LICM) should not hoist dead code
+        https://bugs.webkit.org/show_bug.cgi?id=194945
+        <rdar://problem/48311657>
+
+        Reviewed by Saam Barati.
+
+        * dfg/DFGLICMPhase.cpp:
+        (JSC::DFG::LICMPhase::run):
+
+2019-02-27  Antoine Quint  <graouts@apple.com>
+
+        Support Pointer Events on macOS
+        https://bugs.webkit.org/show_bug.cgi?id=195008
+        <rdar://problem/47454419>
+
+        Reviewed by Dean Jackson.
+
+        * Configurations/FeatureDefines.xcconfig:
+
+2019-02-26  Mark Lam  <mark.lam@apple.com>
+
+        Remove poisons in JSCPoison and uses of them.
+        https://bugs.webkit.org/show_bug.cgi?id=195082
+
+        Reviewed by Yusuke Suzuki.
+
+        Also removed unused poisoning code in WriteBarrier, AssemblyHelpers,
+        DFG::SpeculativeJIT, FTLLowerDFGToB3, and FTL::Output.
+
+        * API/JSAPIWrapperObject.h:
+        (JSC::JSAPIWrapperObject::wrappedObject):
+        * API/JSCallbackFunction.h:
+        * API/JSCallbackObject.h:
+        * API/glib/JSAPIWrapperGlobalObject.h:
+        * CMakeLists.txt:
+        * JavaScriptCore.xcodeproj/project.pbxproj:
+        * Sources.txt:
+        * bytecode/AccessCase.cpp:
+        (JSC::AccessCase::generateWithGuard):
+        * dfg/DFGSpeculativeJIT.cpp:
+        (JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
+        (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
+        (JSC::DFG::SpeculativeJIT::compileNewFunctionCommon):
+        (JSC::DFG::SpeculativeJIT::compileGetExecutable):
+        (JSC::DFG::SpeculativeJIT::compileCreateThis):
+        * dfg/DFGSpeculativeJIT.h:
+        (JSC::DFG::SpeculativeJIT::TrustedImmPtr::weakPoisonedPointer): Deleted.
+        * ftl/FTLLowerDFGToB3.cpp:
+        (JSC::FTL::DFG::LowerDFGToB3::compileGetExecutable):
+        (JSC::FTL::DFG::LowerDFGToB3::compileGetArrayLength):
+        (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
+        (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
+        (JSC::FTL::DFG::LowerDFGToB3::weakPointer):
+        (JSC::FTL::DFG::LowerDFGToB3::dynamicPoison): Deleted.
+        (JSC::FTL::DFG::LowerDFGToB3::dynamicPoisonOnLoadedType): Deleted.
+        (JSC::FTL::DFG::LowerDFGToB3::dynamicPoisonOnType): Deleted.
+        (JSC::FTL::DFG::LowerDFGToB3::weakPoisonedPointer): Deleted.
+        * ftl/FTLOutput.h:
+        (JSC::FTL::Output::weakPoisonedPointer): Deleted.
+        * jit/AssemblyHelpers.cpp:
+        (JSC::AssemblyHelpers::emitDynamicPoison): Deleted.
+        (JSC::AssemblyHelpers::emitDynamicPoisonOnLoadedType): Deleted.
+        (JSC::AssemblyHelpers::emitDynamicPoisonOnType): Deleted.
+        * jit/AssemblyHelpers.h:
+        * jit/JITOpcodes.cpp:
+        (JSC::JIT::emit_op_create_this):
+        * jit/JITPropertyAccess.cpp:
+        (JSC::JIT::emitScopedArgumentsGetByVal):
+        * jit/Repatch.cpp:
+        (JSC::linkPolymorphicCall):
+        * jit/ThunkGenerators.cpp:
+        (JSC::virtualThunkFor):
+        (JSC::nativeForGenerator):
+        (JSC::boundThisNoArgsFunctionCallGenerator):
+        * parser/UnlinkedSourceCode.h:
+        * runtime/ArrayPrototype.h:
+        * runtime/CustomGetterSetter.h:
+        (JSC::CustomGetterSetter::getter const):
+        (JSC::CustomGetterSetter::setter const):
+        * runtime/InitializeThreading.cpp:
+        (JSC::initializeThreading):
+        * runtime/InternalFunction.cpp:
+        (JSC::InternalFunction::getCallData):
+        (JSC::InternalFunction::getConstructData):
+        * runtime/InternalFunction.h:
+        (JSC::InternalFunction::nativeFunctionFor):
+        * runtime/JSArrayBuffer.h:
+        * runtime/JSBoundFunction.h:
+        * runtime/JSCPoison.cpp: Removed.
+        * runtime/JSCPoison.h: Removed.
+        * runtime/JSFunction.h:
+        * runtime/JSGlobalObject.h:
+        * runtime/JSScriptFetchParameters.h:
+        * runtime/JSScriptFetcher.h:
+        * runtime/JSString.h:
+        * runtime/NativeExecutable.cpp:
+        (JSC::NativeExecutable::hashFor const):
+        * runtime/NativeExecutable.h:
+        * runtime/Options.h:
+        * runtime/ScopedArguments.h:
+        * runtime/Structure.cpp:
+        (JSC::StructureTransitionTable::setSingleTransition):
+        * runtime/StructureTransitionTable.h:
+        (JSC::StructureTransitionTable::map const):
+        (JSC::StructureTransitionTable::weakImpl const):
+        (JSC::StructureTransitionTable::setMap):
+        * runtime/WriteBarrier.h:
+        * wasm/WasmB3IRGenerator.cpp:
+        * wasm/WasmInstance.h:
+        * wasm/js/JSToWasm.cpp:
+        (JSC::Wasm::createJSToWasmWrapper):
+        * wasm/js/JSWebAssemblyCodeBlock.h:
+        * wasm/js/JSWebAssemblyInstance.cpp:
+        (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
+        (JSC::JSWebAssemblyInstance::visitChildren):
+        * wasm/js/JSWebAssemblyInstance.h:
+        * wasm/js/JSWebAssemblyMemory.h:
+        * wasm/js/JSWebAssemblyModule.h:
+        * wasm/js/JSWebAssemblyTable.cpp:
+        (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
+        (JSC::JSWebAssemblyTable::grow):
+        (JSC::JSWebAssemblyTable::clearFunction):
+        * wasm/js/JSWebAssemblyTable.h:
+        * wasm/js/WasmToJS.cpp:
+        (JSC::Wasm::materializeImportJSCell):
+        (JSC::Wasm::handleBadI64Use):
+        (JSC::Wasm::wasmToJS):
+        * wasm/js/WebAssemblyFunctionBase.h:
+        * wasm/js/WebAssemblyModuleRecord.cpp:
+        (JSC::WebAssemblyModuleRecord::link):
+        (JSC::WebAssemblyModuleRecord::evaluate):
+        * wasm/js/WebAssemblyModuleRecord.h:
+        * wasm/js/WebAssemblyToJSCallee.h:
+        * wasm/js/WebAssemblyWrapperFunction.h:
+
+2019-02-26  Mark Lam  <mark.lam@apple.com>
+
+        wasmToJS() should purify incoming NaNs.
+        https://bugs.webkit.org/show_bug.cgi?id=194807
+        <rdar://problem/48189132>
+
+        Reviewed by Saam Barati.
+
+        * runtime/JSCJSValue.h:
+        (JSC::jsNumber):
+        * runtime/TypedArrayAdaptors.h:
+        (JSC::IntegralTypedArrayAdaptor::toJSValue):
+        * wasm/js/WasmToJS.cpp:
+        (JSC::Wasm::wasmToJS):
+
+2019-02-26  Dominik Infuehr  <dinfuehr@igalia.com>
+
+        Fix warnings on ARM and MIPS
+        https://bugs.webkit.org/show_bug.cgi?id=195049
+
+        Reviewed by Mark Lam.
+
+        Fix all warnings on ARM and MIPS.
+
+        * assembler/MacroAssemblerPrinter.cpp:
+        (JSC::Printer::printMemory):
+        * assembler/testmasm.cpp:
+        (JSC::testProbeModifiesStackValues):
+        * bytecode/InByIdStatus.cpp:
+        (JSC::InByIdStatus::computeFor):
+        * runtime/CachedTypes.cpp:
+        (JSC::VariableLengthObject::buffer const):
+        * runtime/JSBigInt.h:
+        * tools/JSDollarVM.cpp:
+        (JSC::codeBlockFromArg):
+
+2019-02-26  Mark Lam  <mark.lam@apple.com>
+
+        Misc cleanup in StructureIDTable after r242096.
+        https://bugs.webkit.org/show_bug.cgi?id=195063
+
+        Reviewed by Saam Barati.
+
+        * runtime/StructureIDTable.cpp:
+        (JSC::StructureIDTable::allocateID):
+        - RELEASE_ASSERT that the StructureID allocation will succeed.
+
+        * runtime/StructureIDTable.h:
+        (JSC::StructureIDTable::decode):
+        (JSC::StructureIDTable::encode):
+        - Add back a comment that Yusuke requested but was lost when the patch was rolled
+          out and relanded.
+        - Applied bitwise_casts that Saam requested.
+
+2019-02-26  Mark Lam  <mark.lam@apple.com>
+
+        Gardening: 32-bit build fix after r242096.
+        https://bugs.webkit.org/show_bug.cgi?id=194989
+
+        Not reviewed.
+
+        * jit/AssemblyHelpers.cpp:
+        (JSC::AssemblyHelpers::emitLoadStructure):
+
+2019-02-26  Mark Lam  <mark.lam@apple.com>
+
+        Unpoison MacroAssemblerCodePtr, ClassInfo pointers, and a few other things.
+        https://bugs.webkit.org/show_bug.cgi?id=195039
+
+        Reviewed by Saam Barati.
+
+        1. Unpoison MacroAssemblerCodePtrs, ReturnAddressPtr.
+        2. Replace PoisonedClassInfoPtr with ClassInfo*.
+        3. Replace PoisonedMasmPtr with const void*.
+        4. Remove all references to CodeBlockPoison, JITCodePoison, and GlobalDataPoison.
+
+        * API/JSCallbackObject.h:
+        * API/JSObjectRef.cpp:
+        (classInfoPrivate):
+        * assembler/MacroAssemblerCodeRef.h:
+        (JSC::FunctionPtr::FunctionPtr):
+        (JSC::FunctionPtr::executableAddress const):
+        (JSC::FunctionPtr::retaggedExecutableAddress const):
+        (JSC::ReturnAddressPtr::ReturnAddressPtr):
+        (JSC::ReturnAddressPtr::value const):
+        (JSC::MacroAssemblerCodePtr::MacroAssemblerCodePtr):
+        (JSC::MacroAssemblerCodePtr::createFromExecutableAddress):
+        (JSC::MacroAssemblerCodePtr:: const):
+        (JSC::MacroAssemblerCodePtr::operator! const):
+        (JSC::MacroAssemblerCodePtr::operator== const):
+        (JSC::MacroAssemblerCodePtr::hash const):
+        (JSC::MacroAssemblerCodePtr::emptyValue):
+        (JSC::MacroAssemblerCodePtr::deletedValue):
+        (JSC::FunctionPtr<tag>::FunctionPtr):
+        (JSC::MacroAssemblerCodePtr::poisonedPtr const): Deleted.
+        * b3/B3LowerMacros.cpp:
+        * b3/testb3.cpp:
+        (JSC::B3::testInterpreter):
+        * dfg/DFGOSRExitCompilerCommon.h:
+        (JSC::DFG::adjustFrameAndStackInOSRExitCompilerThunk):
+        * dfg/DFGSpeculativeJIT.cpp:
+        (JSC::DFG::SpeculativeJIT::compileCheckSubClass):
+        (JSC::DFG::SpeculativeJIT::compileNewStringObject):
+        (JSC::DFG::SpeculativeJIT::emitSwitchIntJump):
+        (JSC::DFG::SpeculativeJIT::emitSwitchImm):
+        (JSC::DFG::SpeculativeJIT::emitSwitchCharStringJump):
+        (JSC::DFG::SpeculativeJIT::emitSwitchChar):
+        * dfg/DFGSpeculativeJIT.h:
+        * ftl/FTLLowerDFGToB3.cpp:
+        (JSC::FTL::DFG::LowerDFGToB3::compileNewStringObject):
+        (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass):
+        * jit/AssemblyHelpers.h:
+        (JSC::AssemblyHelpers::emitAllocateDestructibleObject):
+        * jit/ThunkGenerators.cpp:
+        (JSC::virtualThunkFor):
+        (JSC::boundThisNoArgsFunctionCallGenerator):
+        * runtime/JSCPoison.h:
+        * runtime/JSDestructibleObject.h:
+        (JSC::JSDestructibleObject::classInfo const):
+        * runtime/JSSegmentedVariableObject.h:
+        (JSC::JSSegmentedVariableObject::classInfo const):
+        * runtime/Structure.h:
+        * runtime/VM.h:
+        * wasm/WasmB3IRGenerator.cpp:
+        (JSC::Wasm::B3IRGenerator::addCall):
+        (JSC::Wasm::B3IRGenerator::addCallIndirect):
+        * wasm/WasmBinding.cpp:
+        (JSC::Wasm::wasmToWasm):
+
+2019-02-26  Mark Lam  <mark.lam@apple.com>
+
+        [Re-landing] Add some randomness into the StructureID.
+        https://bugs.webkit.org/show_bug.cgi?id=194989
+        <rdar://problem/47975563>
+
+        Reviewed by Yusuke Suzuki.
+
+        1. On 64-bit, the StructureID will now be encoded as:
+
+            ----------------------------------------------------------------
+            | 1 Nuke Bit | 24 StructureIDTable index bits | 7 entropy bits |
+            ----------------------------------------------------------------
+
+           The entropy bits are chosen at random and assigned when a StructureID is
+           allocated.
+
+        2. Instead of Structure pointers, the StructureIDTable will now contain
+           encodedStructureBits, which is encoded as such:
+
+            ----------------------------------------------------------------
+            | 7 entropy bits |                   57 structure pointer bits |
+            ----------------------------------------------------------------
+
+           The entropy bits here are the same 7 bits used in the encoding of the
+           StructureID for this structure entry in the StructureIDTable.
+
+        3. Retrieval of the structure pointer given a StructureID is now computed as
+           follows:
+
+                index = structureID >> 7; // with arithmetic shift.
+                encodedStructureBits = structureIDTable[index];
+                structure = encodedStructureBits ^ (structureID << 57);
+
+            We use an arithmetic shift for the right shift because that will preserve
+            the nuke bit in the high bit of the index if the StructureID was not
+            decontaminated before use as expected.
+
+        4. Remove unused function loadArgumentWithSpecificClass() in SpecializedThunkJIT.
+
+        5. Define StructureIDTable::m_size to be the number of allocated StructureIDs
+           instead of always being the same as m_capacity.
+
+        6. Change StructureIDTable::s_unusedID's value to 0.
+
+           Its previous value of unusedPointer i.e. 0xd1e7beef, does not make sense for
+           StructureID on 64-bit.  Also, there was never any code that initializes unused
+           IDs to the s_unusedID.  The only meaningful value for s_unusedID is 0, which
+           is the ID we'll get when the freelist is empty, prompting a resize of the
+           structureIDTable.
+
+        This patch appears to be perf neutral on JetStream 2 run via the cli on a
+        11" MacBook Air, 13" MacBook Pro, iPhone 6S, and iPhone XR.
+
+        * ftl/FTLLowerDFGToB3.cpp:
+        (JSC::FTL::DFG::LowerDFGToB3::loadStructure):
+        * heap/SlotVisitor.cpp:
+        (JSC::SlotVisitor::appendJSCellOrAuxiliary):
+        * jit/AssemblyHelpers.cpp:
+        (JSC::AssemblyHelpers::emitLoadStructure):
+        * jit/AssemblyHelpers.h:
+        * jit/SpecializedThunkJIT.h:
+        (JSC::SpecializedThunkJIT::loadArgumentWithSpecificClass): Deleted.
+        * llint/LowLevelInterpreter.asm:
+        * llint/LowLevelInterpreter64.asm:
+        * runtime/StructureIDTable.cpp:
+        (JSC::StructureIDTable::StructureIDTable):
+        (JSC::StructureIDTable::makeFreeListFromRange):
+        (JSC::StructureIDTable::resize):
+        (JSC::StructureIDTable::allocateID):
+        (JSC::StructureIDTable::deallocateID):
+        * runtime/StructureIDTable.h:
+        (JSC::StructureIDTable::decode):
+        (JSC::StructureIDTable::encode):
+        (JSC::StructureIDTable::get):
+        (JSC::StructureIDTable::isValid):
+
+2019-02-26  Ryan Haddad  <ryanhaddad@apple.com>
+
+        Unreviewed, rolling out r242071.
+
+        Breaks internal builds.
+
+        Reverted changeset:
+
+        "Add some randomness into the StructureID."
+        https://bugs.webkit.org/show_bug.cgi?id=194989
+        https://trac.webkit.org/changeset/242071
+
+2019-02-26  Guillaume Emont  <guijemont@igalia.com>
+
+        [JSC] Fix compilation on 32-bit platforms after r242071
+        https://bugs.webkit.org/show_bug.cgi?id=195042
+
+        Reviewed by Carlos Garcia Campos.
+
+        * jit/AssemblyHelpers.cpp:
+        (JSC::AssemblyHelpers::emitLoadStructure):
+
+2019-02-26  Guillaume Emont  <guijemont@igalia.com>
+
+        [JSC] Repeat string created from Array.prototype.join() take too much memory
+        https://bugs.webkit.org/show_bug.cgi?id=193912
+
+        Reviewed by Saam Barati.
+
+        Added a fast case in Array.prototype.join when the array is
+        uninitialized.
+
+        * runtime/ArrayPrototype.cpp:
+        (JSC::canUseFastJoin):
+        (JSC::fastJoin):
+        * runtime/JSStringInlines.h:
+        (JSC::repeatCharacter): moved from StringPrototype.cpp
+        * runtime/StringPrototype.cpp:
+
+2019-02-25  Mark Lam  <mark.lam@apple.com>
+
+        Add some randomness into the StructureID.
+        https://bugs.webkit.org/show_bug.cgi?id=194989
+        <rdar://problem/47975563>
+
+        Reviewed by Yusuke Suzuki.
+
+        1. On 64-bit, the StructureID will now be encoded as:
+
+            ----------------------------------------------------------------
+            | 1 Nuke Bit | 24 StructureIDTable index bits | 7 entropy bits |
+            ----------------------------------------------------------------
+
+           The entropy bits are chosen at random and assigned when a StructureID is
+           allocated.
+
+        2. Instead of Structure pointers, the StructureIDTable will now contain
+           encodedStructureBits, which is encoded as such:
+
+            ----------------------------------------------------------------
+            | 7 entropy bits |                   57 structure pointer bits |
+            ----------------------------------------------------------------
+
+           The entropy bits here are the same 7 bits used in the encoding of the
+           StructureID for this structure entry in the StructureIDTable.
+
+        3. Retrieval of the structure pointer given a StructureID is now computed as
+           follows:
+
+                index = structureID >> 7; // with arithmetic shift.
+                encodedStructureBits = structureIDTable[index];
+                structure = encodedStructureBits ^ (structureID << 57);
+
+            We use an arithmetic shift for the right shift because that will preserve
+            the nuke bit in the high bit of the index if the StructureID was not
+            decontaminated before use as expected.
+
+        4. Remove unused function loadArgumentWithSpecificClass() in SpecializedThunkJIT.
+
+        5. Define StructureIDTable::m_size to be the number of allocated StructureIDs
+           instead of always being the same as m_capacity.
+
+        6. Change StructureIDTable::s_unusedID's value to 0.
+
+           Its previous value of unusedPointer i.e. 0xd1e7beef, does not make sense for
+           StructureID on 64-bit.  Also, there was never any code that initializes unused
+           IDs to the s_unusedID.  The only meaningful value for s_unusedID is 0, which
+           is the ID we'll get when the freelist is empty, prompting a resize of the
+           structureIDTable.
+
+        This patch appears to be perf neutral on JetStream 2 run via the cli on a
+        11" MacBook Air, 13" MacBook Pro, iPhone 6S, and iPhone XR.
+
+        * ftl/FTLLowerDFGToB3.cpp:
+        (JSC::FTL::DFG::LowerDFGToB3::loadStructure):
+        * heap/SlotVisitor.cpp:
+        (JSC::SlotVisitor::appendJSCellOrAuxiliary):
+        * jit/AssemblyHelpers.cpp:
+        (JSC::AssemblyHelpers::emitLoadStructure):
+        * jit/AssemblyHelpers.h:
+        * jit/SpecializedThunkJIT.h:
+        (JSC::SpecializedThunkJIT::loadArgumentWithSpecificClass): Deleted.
+        * llint/LowLevelInterpreter.asm:
+        * llint/LowLevelInterpreter64.asm:
+        * runtime/StructureIDTable.cpp:
+        (JSC::StructureIDTable::StructureIDTable):
+        (JSC::StructureIDTable::makeFreeListFromRange):
+        (JSC::StructureIDTable::resize):
+        (JSC::StructureIDTable::allocateID):
+        (JSC::StructureIDTable::deallocateID):
+        * runtime/StructureIDTable.h:
+        (JSC::StructureIDTable::decode):
+        (JSC::StructureIDTable::encode):
+        (JSC::StructureIDTable::get):
+        (JSC::StructureIDTable::isValid):
+
+2019-02-25  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Revert r226885 to make SlotVisitor creation lazy
+        https://bugs.webkit.org/show_bug.cgi?id=195013
+
+        Reviewed by Saam Barati.
+
+        We once changed SlotVisitor creation apriori to drop the lock. Also, it turns out that SlotVisitor is memory-consuming.
+        We should defer SlotVisitor creation until it is actually required. This patch reverts r226885. Even with this patch,
+        we still hold many SlotVisitors after we execute many parallel markers at least once. But recovering the feature of
+        dynamically allocating SlotVisitors helps further memory optimizations in this area.
+
+        * heap/Heap.cpp:
+        (JSC::Heap::Heap):
+        (JSC::Heap::runBeginPhase):
+        * heap/Heap.h:
+        * heap/HeapInlines.h:
+        (JSC::Heap::forEachSlotVisitor):
+        (JSC::Heap::numberOfSlotVisitors):
+        * heap/MarkingConstraintSolver.cpp:
+        (JSC::MarkingConstraintSolver::didVisitSomething const):
+        * heap/SlotVisitor.h:
+
+2019-02-25  Saam Barati  <sbarati@apple.com>
+
+        testb3 and testair should test O0/O1/O2
+        https://bugs.webkit.org/show_bug.cgi?id=194637
+
+        Reviewed by Mark Lam.
+
+        This patch makes it so that we run all tests in testair and testb3
+        in O0, O1, and O2. However, some tests are invalid for O0 and O1.
+        This patch makes it so we only run those tests in O2. These are
+        often tests that assert certain optimizations have occurred. There
+        are also a class of tests that rely on using patchpoints to stress 
+        the register allocator into only a single valid allocation. The
+        O0, and sometimes O1, register allocators are not always good enough
+        to allocate such programs. To make these valid allocators to use, we rely
+        on the FTL and Wasm to not emit such patchpoints.
+
+        * b3/air/testair.cpp:
+        (main):
+        * b3/testb3.cpp:
+        (JSC::B3::compileProc):
+        (JSC::B3::testAddLoadTwice):
+        (JSC::B3::testMulLoadTwice):
+        (JSC::B3::testSimplePatchpointWithOuputClobbersGPArgs):
+        (JSC::B3::testSimplePatchpointWithOuputClobbersFPArgs):
+        (JSC::B3::testPatchpointWithEarlyClobber):
+        (JSC::B3::testSimpleCheck):
+        (JSC::B3::testCheckFalse):
+        (JSC::B3::testCheckTrue):
+        (JSC::B3::testCheckLessThan):
+        (JSC::B3::testCheckMegaCombo):
+        (JSC::B3::testCheckTrickyMegaCombo):
+        (JSC::B3::testCheckTwoMegaCombos):
+        (JSC::B3::testCheckTwoNonRedundantMegaCombos):
+        (JSC::B3::testCheckAddImm):
+        (JSC::B3::testCheckAddImmCommute):
+        (JSC::B3::testCheckAddImmSomeRegister):
+        (JSC::B3::testCheckAdd):
+        (JSC::B3::testCheckAdd64):
+        (JSC::B3::testCheckAddFold):
+        (JSC::B3::testCheckAddFoldFail):
+        (JSC::B3::testCheckAddSelfOverflow64):
+        (JSC::B3::testCheckAddSelfOverflow32):
+        (JSC::B3::testCheckSubImm):
+        (JSC::B3::testCheckSubBadImm):
+        (JSC::B3::testCheckSub):
+        (JSC::B3::testCheckSub64):
+        (JSC::B3::testCheckSubFold):
+        (JSC::B3::testCheckSubFoldFail):
+        (JSC::B3::testCheckNeg):
+        (JSC::B3::testCheckNeg64):
+        (JSC::B3::testCheckMul):
+        (JSC::B3::testCheckMulMemory):
+        (JSC::B3::testCheckMul2):
+        (JSC::B3::testCheckMul64):
+        (JSC::B3::testCheckMulFold):
+        (JSC::B3::testCheckMulFoldFail):
+        (JSC::B3::testCheckMul64SShr):
+        (JSC::B3::testLinearScanWithCalleeOnStack):
+        (JSC::B3::testCheckSelect):
+        (JSC::B3::testCheckSelectCheckSelect):
+        (JSC::B3::testCheckSelectAndCSE):
+        (JSC::B3::testLateRegister):
+        (JSC::B3::testReduceStrengthCheckBottomUseInAnotherBlock):
+        (JSC::B3::testSomeEarlyRegister):
+        (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled2):
+        (JSC::B3::testPinRegisters):
+        (JSC::B3::testX86LeaAddAddShlLeft):
+        (JSC::B3::testX86LeaAddAddShlRight):
+        (JSC::B3::testX86LeaAddAdd):
+        (JSC::B3::testX86LeaAddShlRight):
+        (JSC::B3::testX86LeaAddShlLeftScale1):
+        (JSC::B3::testX86LeaAddShlLeftScale2):
+        (JSC::B3::testX86LeaAddShlLeftScale4):
+        (JSC::B3::testX86LeaAddShlLeftScale8):
+        (JSC::B3::testLoadBaseIndexShift2):
+        (JSC::B3::testOptimizeMaterialization):
+        (JSC::B3::testLICMPure):
+        (JSC::B3::testLICMPureSideExits):
+        (JSC::B3::testLICMPureWritesPinned):
+        (JSC::B3::testLICMPureWrites):
+        (JSC::B3::testLICMReadsPinned):
+        (JSC::B3::testLICMReads):
+        (JSC::B3::testLICMPureNotBackwardsDominant):
+        (JSC::B3::testLICMPureNotBackwardsDominantFoiledByChild):
+        (JSC::B3::testLICMControlDependent):
+        (JSC::B3::testLICMControlDependentNotBackwardsDominant):
+        (JSC::B3::testLICMReadsWritesDifferentHeaps):
+        (JSC::B3::testWasmBoundsCheck):
+        (JSC::B3::run):
+        (main):
+
+2019-02-25  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] stress/function-constructor-reading-from-global-lexical-environment.js fails in 32bit arch
+        https://bugs.webkit.org/show_bug.cgi?id=195030
+        <rdar://problem/48385088>
+
+        Reviewed by Saam Barati.
+
+        While LLInt64 has checkTDZInGlobalPutToScopeIfNecessary for op_put_to_scope GlobalLexicalVar to check the value in the variable slot is not empty,
+        this check is missing in LLInt32_64. Previously, this check was subsumed accidentally by the WatchpointSet check in GlobalLexicalVar in `notifyWrite`:
+        because no "put" attempt succeeds here, the status WatchpointSet was ClearWatchpoint, we always go to the slow path, and we always throw the TDZ error
+        before configuring the WatchpointSet in the slow path. But after r241862, WatchpointSet is not used under non-JIT configuration. This skips WatchpointSet
+        check and LLInt32_64 starts failing tests because of lack of checkTDZInGlobalPutToScopeIfNecessary. This patch adds checkTDZInGlobalPutToScopeIfNecessary
+        in LLInt32_64 too. This patch fixes the following four failing tests.
+
+            stress/function-constructor-reading-from-global-lexical-environment.js.bytecode-cache
+            stress/function-constructor-reading-from-global-lexical-environment.js.default
+            stress/global-lexical-variable-tdz.js.bytecode-cache
+            stress/global-lexical-variable-tdz.js.default
+
+        * llint/LowLevelInterpreter32_64.asm:
+
+2019-02-25  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Make Intl fields lazily-allocated
+        https://bugs.webkit.org/show_bug.cgi?id=195022
+
+        Reviewed by Mark Lam.
+
+        This patch makes the following memory footprint optimization in IntlObject.
+
+        1. Make IntlObject fields including Intl.Collator lazily-allocated because we already removed direct references from JS builtins to these constructors (@Collator etc.).
+
+        2. Move LazyProperty<IntlObject, Structure> structures from IntlObject to JSGlobalObject. This makes sizeof(IntlObject) the same to the other ones of usual runtime Objects,
+           and drop one MarkedBlock.
+
+        * runtime/IntlCollatorConstructor.h:
+        * runtime/IntlDateTimeFormatConstructor.h:
+        * runtime/IntlNumberFormatConstructor.h:
+        * runtime/IntlObject.cpp:
+        (JSC::createCollatorConstructor):
+        (JSC::createNumberFormatConstructor):
+        (JSC::createDateTimeFormatConstructor):
+        (JSC::createPluralRulesConstructor):
+        (JSC::IntlObject::finishCreation):
+        (JSC::IntlObject::visitChildren): Deleted.
+        * runtime/IntlObject.h:
+        * runtime/IntlPluralRulesConstructor.h:
+        * runtime/JSGlobalObject.cpp:
+        (JSC::JSGlobalObject::init):
+        (JSC::JSGlobalObject::visitChildren):
+        (JSC::JSGlobalObject::defaultCollator):
+        * runtime/JSGlobalObject.h:
+        (JSC::JSGlobalObject::collatorStructure):
+        (JSC::JSGlobalObject::numberFormatStructure):
+        (JSC::JSGlobalObject::dateTimeFormatStructure):
+        (JSC::JSGlobalObject::pluralRulesStructure):
+        (JSC::JSGlobalObject::intlObject const): Deleted.
+        * runtime/JSGlobalObjectFunctions.cpp:
+        (JSC::globalFuncDateTimeFormat):
+        * runtime/NumberPrototype.cpp:
+        (JSC::numberProtoFuncToLocaleString):
+        * runtime/StringPrototype.cpp:
+        (JSC::stringProtoFuncLocaleCompare):
+
+2019-02-25  Tadeu Zagallo  <tzagallo@apple.com>
+
+        Avoid hashing CompactVariableEnvironment when decoding CompactVariableMap::Handle
+        https://bugs.webkit.org/show_bug.cgi?id=194937
+
+        Reviewed by Saam Barati.
+
+        Hashing the CompactVariableEnvironment is expensive and we could avoid it
+        when decoding multiple handles to the same environment. This is sound because
+        a pointer to the same CompactVariableEnvironment will hash the same.
+
+        * runtime/CachedTypes.cpp:
+        (JSC::Decoder::handleForEnvironment const):
+        (JSC::Decoder::setHandleForEnvironment):
+        (JSC::CachedCompactVariableMapHandle::decode const):
+
+2019-02-25  Tadeu Zagallo  <tzagallo@apple.com>
+
+        Remove unnecessary WTF:: prefixes in CachedTypes
+        https://bugs.webkit.org/show_bug.cgi?id=194936
+
+        Reviewed by Saam Barati.
+
+        Cleanup unnecessary prefixes from Optional, roundUpToMultipleOf and
+        pageSize.
+
+        * runtime/CachedTypes.cpp:
+        (JSC::Encoder::cachedOffsetForPtr):
+        (JSC::Encoder::Page::malloc):
+        (JSC::Encoder::allocateNewPage):
+        (JSC::CachedPtr::encode):
+        (JSC::CachedPtr::decode const):
+        (JSC::CachedOptional::encode):
+        (JSC::CachedOptional::decode const):
+
+2019-02-25  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Drop direct references to Intl constructors by rewriting Intl JS builtins in C++
+        https://bugs.webkit.org/show_bug.cgi?id=194976
+
+        Reviewed by Michael Saboff.
+
+        This patch paves the way to making IntlObject allocation lazy by removing direct references
+        to Intl constructors (Intl.Collator etc.) from builtin JS. To achieve that,
+
+        1. We implement String.prototype.toLocaleCompare and Number.prototype.toLocaleString in C++
+           instead of JS builtins. Since these functions end up calling ICU C++ runtime, writing them in
+           JS does not offer performance improvement.
+
+        2. We remove @DateTimeFormat constructor reference, and instead, exposing @dateTimeFormat function,
+           which returns formatted string directly. We still have JS builtins for DateTimeFormat things
+           because the initialization of its "options" JSObject involves many get_by_id / put_by_id things,
+           which are efficient in JS. But we avoid exposing @DateTimeFormat directly, so that Intl constructors
+           can be lazily allocated.
+
+        * CMakeLists.txt:
+        * DerivedSources-input.xcfilelist:
+        * DerivedSources.make:
+        * JavaScriptCore.xcodeproj/project.pbxproj:
+        * builtins/BuiltinNames.h:
+        * builtins/DatePrototype.js:
+        (toLocaleString):
+        (toLocaleDateString):
+        (toLocaleTimeString):
+        * builtins/NumberPrototype.js: Removed.
+        * builtins/StringPrototype.js:
+        (intrinsic.StringPrototypeReplaceIntrinsic.replace):
+        (globalPrivate.getDefaultCollator): Deleted.
+        * runtime/JSGlobalObject.cpp:
+        (JSC::JSGlobalObject::init):
+        (JSC::JSGlobalObject::visitChildren):
+        (JSC::JSGlobalObject::defaultCollator):
+        * runtime/JSGlobalObject.h:
+        * runtime/JSGlobalObjectFunctions.cpp:
+        (JSC::globalFuncDateTimeFormat):
+        * runtime/JSGlobalObjectFunctions.h:
+        * runtime/NumberPrototype.cpp:
+        (JSC::NumberPrototype::finishCreation):
+        (JSC::throwVMToThisNumberError):
+        (JSC::numberProtoFuncToExponential):
+        (JSC::numberProtoFuncToFixed):
+        (JSC::numberProtoFuncToPrecision):
+        (JSC::numberProtoFuncToString):
+        (JSC::numberProtoFuncToLocaleString):
+        (JSC::numberProtoFuncValueOf):
+        * runtime/StringPrototype.cpp:
+        (JSC::StringPrototype::finishCreation):
+        (JSC::stringProtoFuncLocaleCompare):
+
+2019-02-24  Devin Rousso  <drousso@apple.com>
+
+        Web Inspector: Change the InspectorOverlay to use native rather than canvas
+        https://bugs.webkit.org/show_bug.cgi?id=105023
+        <rdar://problem/13443692>
+
+        Reviewed by Brian Burg.
+
+        * inspector/protocol/OverlayTypes.json: Removed.
+        Now that the overlay is entirely generated in C++, we no longer need the special prototol
+        types for transferring data to a JavaScript context.
+
+        * inspector/protocol/Debugger.json:
+        * inspector/agents/InspectorDebuggerAgent.h:
+        * inspector/agents/InspectorDebuggerAgent.cpp:
+        (Inspector::InspectorDebuggerAgent::setOverlayMessage): Deleted.
+        Remove `Debugger.setOverlayMessage` command as it hasn't been used and is no longer supported.
+
+        * CMakeLists.txt:
+        * DerivedSources-input.xcfilelist:
+        * DerivedSources.make:
+
+2019-02-24  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Lazily create sentinel Map and Set buckets
+        https://bugs.webkit.org/show_bug.cgi?id=194975
+
+        Reviewed by Saam Barati.
+
+        If VM::canUseJIT() returns false, we can lazily initialize sentinel Map and Set buckets.
+        This patch adds getters to VM which lazily allocate these buckets. We eagerly initialize
+        them if VM::canUseJIT() returns true since they can be touched from DFG and FTL.
+
+        * bytecode/BytecodeIntrinsicRegistry.cpp:
+        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
+        (JSC::BytecodeIntrinsicRegistry::sentinelMapBucketValue):
+        (JSC::BytecodeIntrinsicRegistry::sentinelSetBucketValue):
+        * bytecode/BytecodeIntrinsicRegistry.h:
+        * dfg/DFGByteCodeParser.cpp:
+        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
+        * dfg/DFGOperations.cpp:
+        * dfg/DFGSpeculativeJIT.cpp:
+        (JSC::DFG::SpeculativeJIT::compileGetMapBucketNext):
+        * dfg/DFGSpeculativeJIT64.cpp:
+        (JSC::DFG::SpeculativeJIT::compile):
+        * ftl/FTLLowerDFGToB3.cpp:
+        (JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucket):
+        (JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucketNext):
+        * runtime/MapConstructor.cpp:
+        (JSC::mapPrivateFuncMapBucketNext):
+        * runtime/SetConstructor.cpp:
+        (JSC::setPrivateFuncSetBucketNext):
+        * runtime/VM.cpp:
+        (JSC::VM::VM):
+        (JSC::VM::sentinelSetBucketSlow):
+        (JSC::VM::sentinelMapBucketSlow):
+        * runtime/VM.h:
+        (JSC::VM::sentinelSetBucket):
+        (JSC::VM::sentinelMapBucket):
+
+2019-02-20  Darin Adler  <darin@apple.com>
+
+        Finish removing String::format
+        https://bugs.webkit.org/show_bug.cgi?id=194893
+
+        Reviewed by Daniel Bates.
+
+        * bytecode/CodeBlock.cpp:
+        (JSC::CodeBlock::nameForRegister): Use makeString instead of String::format,
+        using the new "pad" function.
+
+2019-02-23  Robin Morisset  <rmorisset@apple.com>
+
+        Remove dead code: AdjacencyList::justOneChild()
+        https://bugs.webkit.org/show_bug.cgi?id=194965
+
+        Reviewed by Sam Weinig.
+
+        * dfg/DFGAdjacencyList.h:
+        (JSC::DFG::AdjacencyList::justOneChild const): Deleted.
+
+2019-02-23  Michael Catanzaro  <mcatanzaro@igalia.com>
+
+        Unreviewed, fix -Wunused-param warning
+
+        * jsc.cpp:
+
+2019-02-23  Mark Lam  <mark.lam@apple.com>
+
+        Add an exception check and some assertions in StringPrototype.cpp.
+        https://bugs.webkit.org/show_bug.cgi?id=194962
+        <rdar://problem/48013416>
+
+        Reviewed by Yusuke Suzuki and Saam Barati.
+
+        * runtime/StringPrototype.cpp:
+        (JSC::jsSpliceSubstrings):
+        (JSC::jsSpliceSubstringsWithSeparators):
+        (JSC::operationStringProtoFuncReplaceRegExpEmptyStr):
+
+2019-02-23  Keith Miller  <keith_miller@apple.com>
+
+        Add new mac target numbers
+        https://bugs.webkit.org/show_bug.cgi?id=194955
+
+        Reviewed by Tim Horton.
+
+        * Configurations/Base.xcconfig:
+        * Configurations/DebugRelease.xcconfig:
+
+2019-02-22  Robin Morisset  <rmorisset@apple.com>
+
+        DFGBytecodeParser should not declare that a node won't clobberExit if DFGFixupPhase can later declare it does clobberExit
+        https://bugs.webkit.org/show_bug.cgi?id=194953
+        <rdar://problem/47595253>
+
+        Reviewed by Saam Barati.
+
+        For each node that
+        (a) may or may not clobberExit depending on their arrayMode
+        (b) and get their arrayMode from profiling information in DFGBytecodeParser
+        (c) and can have their arrayMode refined by DFGFixupPhase,
+        We must make sure to be conservative in the DFGBytecodeParser and treat it as if it unconditionnally clobbered the exit.
+        Otherwise we will hit a validation failure after fixup if the next node was marked ExitValid and exits to the same semantic origin.
+
+        The list of nodes that fit (a) is:
+        - StringCharAt
+        - HasIndexProperty
+        - GetByVal
+        - PutByValDirect
+        - PutByVal
+        - PutByValAlias
+        - GetIndexedPropertyStorage
+
+        Out of these, the following also fit (b) and (c):
+        - HasIndexedProperty
+        - GetByVal
+        - PutByValDirect
+        - PutByVal
+
+        GetByVal already had "m_exitOK = false; // GetByVal must be treated as if it clobbers exit state, since FixupPhase may make it generic."
+        So we just have to fix the other three the same way.
+
+        * dfg/DFGByteCodeParser.cpp:
+        (JSC::DFG::ByteCodeParser::parseBlock):
+        (JSC::DFG::ByteCodeParser::handlePutByVal):
+
+2019-02-22  Robin Morisset  <rmorisset@apple.com>
+
+        B3ReduceStrength: missing peephole optimizations for binary operations
+        https://bugs.webkit.org/show_bug.cgi?id=194252
+
+        Reviewed by Saam Barati.
+
+        Adds several sets of optimizations for BitAnd, BitOr and BitXor.
+        Using BitAnd distributivity over BitOr and BitXor:
+          Turn any of these (for Op == BitOr || Op == BitXor):
+                Op(BitAnd(x1, x2), BitAnd(x1, x3))
+                Op(BitAnd(x2, x1), BitAnd(x1, x3))
+                Op(BitAnd(x1, x2), BitAnd(x3, x1))
+                Op(BitAnd(x2, x1), BitAnd(x3, x1))
+           Into this: BitAnd(Op(x2, x3), x1)
+           And any of these:
+                Op(BitAnd(x1, x2), x1)
+                Op(BitAnd(x2, x1), x1)
+                Op(x1, BitAnd(x1, x2))
+                Op(x1, BitAnd(x2, x1))
+           Into this: BitAnd(Op(x2, x1), x1)
+           This second set is equivalent to doing x1 => BitAnd(x1, x1), and then applying the first set.
+        Using de Morgan laws (we represent not as BitXor with allOnes):
+          BitAnd(BitXor(x1, allOnes), BitXor(x2, allOnes)) => BitXor(BitOr(x1, x2), allOnes)
+          BitOr(BitXor(x1, allOnes), BitXor(x2, allOnes) => BitXor(BitAnd(x1, x2), allOnes)
+          BitOr(BitXor(x, allOnes), c) => BitXor(BitAnd(x, ~c), allOnes)
+          BitAnd(BitXor(x, allOnes), c) => BitXor(BitOr(x, ~c), allOnes)
+        The latter two are equivalent to doing c => BitXor(~c, allOnes), and then applying the former two.
+
+        All of these transformations either reduce the number of operations (which we always do when possible), or bring the expression closer to having:
+          - BitXor with all ones at the outermost
+          - then BitAnd
+          - then other BitXor
+          - then BitOr at the innermost.
+        These transformations that don't directly reduce the number of operations are still useful for normalization (helping things like CSE), and also can enable
+        more optimizations (for example BitXor with all ones can easily cancel each other once they are all at the outermost level).
+
+        * b3/B3ReduceStrength.cpp:
+        * b3/testb3.cpp:
+        (JSC::B3::testBitAndNotNot):
+        (JSC::B3::testBitAndNotImm):
+        (JSC::B3::testBitOrAndAndArgs):
+        (JSC::B3::testBitOrAndSameArgs):
+        (JSC::B3::testBitOrNotNot):
+        (JSC::B3::testBitOrNotImm):
+        (JSC::B3::testBitXorAndAndArgs):
+        (JSC::B3::testBitXorAndSameArgs):
+        (JSC::B3::run):
+
+2019-02-22  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] putNonEnumerable in JSWrapperMap is too costly
+        https://bugs.webkit.org/show_bug.cgi?id=194935
+
+        Reviewed by Mark Lam.
+
+        When we convert Objective-C blocks to JS objects, we need to set up a corresponding function object correctly.
+        During this allocation, we call [JSValue defineProperty:descriptor] to connect a "prototype" object and "constructor" object.
+        The problem is that this API has a particularly costly implementation:
+
+            [[_context globalObject][@"Object"] invokeMethod:@"defineProperty" withArguments:@[ self, key, descriptor ]];
+
+        This wraps each JS objects appear in this code with Objective-C wrapper. And we convert a NSDictionary to JSObject, which
+        has "writable", "enumerable", "configurable", "value" fields, and call the "defineProperty" JS function through Objective-C wrapper.
+        This allocates many Objective-C wrappers and JS objects for descriptors. Since JSC has a direct C++ API "defineOwnProperty", we should
+        bypass these Objective-C APIs and call JSC's code directly.
+
+        This patch changes `putNonEnumerable` implementation, from calling [JSValue defineProperty:descriptor] to calling JSC C++ code directly.
+        We do not change [JSValue defineProperty:descriptor] implementation for now because of two reasons. (1) This is not used in our benchmarks
+        except for this (converting an Objective-C block to a JS object) one path. And (2) even if we were to re-write [JSValue defineProperty:descriptor]
+        to be more optimized, we would still want to call the JSC C++ version of defineProperty directly here to avoid NSDictionary allocation for a descriptor.
+
+        * API/APIUtils.h:
+        (setException):
+        * API/JSWrapperMap.mm:
+        (putNonEnumerable):
+        (copyMethodsToObject):
+        (-[JSObjCClassInfo allocateConstructorAndPrototypeInContext:]):
+        (-[JSObjCClassInfo wrapperForObject:inContext:]):
+
+2019-02-22  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        Unreviewed, build fix after r241954
+        https://bugs.webkit.org/show_bug.cgi?id=194939
+
+        Renaming setCanAccessHeap was incomplete.
+
+        * runtime/SmallStrings.cpp:
+        (JSC::SmallStrings::initializeCommonStrings):
+        * runtime/VM.cpp:
+        (JSC::VM::~VM):
+
+2019-02-22  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] SmallStringsStorage is unnecessary
+        https://bugs.webkit.org/show_bug.cgi?id=194939
+
+        Reviewed by Mark Lam.
+
+        SmallStrings hold common small JSStrings. Their underlying StringImpl is also held by SmallStringsStorage.
+        But it is duplicate since we can get StringImpl from small JSStrings. This patch removes SmallStringsStorage,
+        and get StringImpls from JSStrings if necessary.
+
+        We also add m_canAccessHeap flag to SmallStrings. At the time of VM destruction, JSStrings are destroyed when
+        VM's Heap is finalized. We must not touch JSStrings before VM's heap (and JSStrings in SmallStrings) is initialized,
+        and after VM's Heap is destroyed. We add this m_canAccessHeap flag to allow users to get StringImpl during the
+        this sensitive period. If m_canAccessHeap is false, we get StringImpl from AtomicStringImpl::add.
+
+        * runtime/SmallStrings.cpp:
+        (JSC::SmallStrings::initializeCommonStrings):
+        (JSC::SmallStrings::singleCharacterStringRep):
+        (JSC::SmallStringsStorage::rep): Deleted.
+        (JSC::SmallStringsStorage::SmallStringsStorage): Deleted.
+        (JSC::SmallStrings::createSingleCharacterString): Deleted.
+        * runtime/SmallStrings.h:
+        (JSC::SmallStrings::setCanAccessHeap):
+        * runtime/VM.cpp:
+        (JSC::VM::VM):
+        (JSC::VM::~VM):
+
+2019-02-22  Tadeu Zagallo  <tzagallo@apple.com>
+
+        Cache CompactVariableMap::Handle instead of VariableEnvironment for UnlinkedFunctionExecutable
+        https://bugs.webkit.org/show_bug.cgi?id=194706
+
+        Reviewed by Saam Barati.
+
+        In https://bugs.webkit.org/show_bug.cgi?id=194583 we started using a
+        CompactVariableMap::Handle instead of VariableEnvironment for
+        UnlinkedFunctionExecutables, but we were creating the full environment
+        to encode the executable in the bytecode cache. This patch changes it so
+        that we cache the handle instead of the environment. This avoids duplicating
+        the VariableEnvironment whenever we have to cache two handles that point
+        to the environment.
+
+        * bytecode/UnlinkedFunctionExecutable.h:
+        * parser/VariableEnvironment.cpp:
+        (JSC::CompactVariableMap::get):
+        * parser/VariableEnvironment.h:
+        * runtime/CachedTypes.cpp:
+        (JSC::CachedCompactVariableEnvironment::encode):
+        (JSC::CachedCompactVariableEnvironment::decode const):
+        (JSC::CachedCompactVariableMapHandle::encode):
+        (JSC::CachedCompactVariableMapHandle::decode const):
+        (JSC::CachedFunctionExecutable::encode):
+        (JSC::CachedFunctionExecutable::decode const):
+        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
+
+2019-02-21  Saam Barati  <sbarati@apple.com>
+
+        Update JSScript SPI based on feedback
+        https://bugs.webkit.org/show_bug.cgi?id=194517
+
+        Reviewed by Keith Miller.
+
+        This patch updates the JSScript SPI in the following ways:
+        - JSScript can now represent both modules and programs. This is a property
+        of the script determined during creation.
+        - JSScript now takes a sourceURL during construction. For modules, this acts
+        as the module identifier.
+        - JSScript now has SPI for writing the cache out to disk. We don't do this
+        automatically.
+        - JSScript will load the bytecode cache on creation if it exists.
+        - We retrofit these new requirements on the prior JSScript SPI that
+        we're going to remove as soon as we can: https://bugs.webkit.org/show_bug.cgi?id=194909.
+        Previous SPI assumes all JSScripts are modules. Previous SPI also assigns
+        a sourceURL to the JSScript based on what the module loader decided the
+        identifier should be. We'll remove this once we remove the old SPI.
+        
+        This patch also adds SPI to JSContext to evaluate a JSScript. For modules,
+        this is like returning the result of doing dynamic import. For programs,
+        this does normal program evaluation.
+        
+        This patch also fixes a bug in generateBytecode/generateModuleBytecode where
+        we would try to cache the bytecode even if recursivelyGenerateUnlinkedCodeBlock
+        returned null. E.g, if the script had a syntax error.
+        
+        When writing tests, I also discovered that someone previously broke
+        testapi. This patch also fixes those failures. They were broken when
+        we switched to using a testapiScripts directory to hold our test .js
+        scripts. 
+
+        * API/JSAPIGlobalObject.h:
+        * API/JSAPIGlobalObject.mm:
+        (JSC::JSAPIGlobalObject::moduleLoaderResolve):
+        (JSC::JSAPIGlobalObject::moduleLoaderFetch):
+        (JSC::JSAPIGlobalObject::loadAndEvaluateJSScriptModule):
+        * API/JSBase.cpp:
+        (JSEvaluateScriptInternal):
+        (JSEvaluateScript):
+        * API/JSBaseInternal.h: Added.
+        * API/JSContext.mm:
+        (-[JSContext evaluateScript:withSourceURL:]):
+        (-[JSContext evaluateJSScript:]):
+        * API/JSContextPrivate.h:
+        * API/JSScript.h:
+        * API/JSScript.mm:
+        (+[JSScript scriptWithSource:inVirtualMachine:]):
+        (+[JSScript scriptFromASCIIFile:inVirtualMachine:withCodeSigning:andBytecodeCache:]):
+        (createError):
+        (+[JSScript scriptOfType:inVirtualMachine:withSourceURL:andSource:andBytecodeCache:error:]):
+        (+[JSScript scriptOfType:inVirtualMachine:memoryMappedFromASCIIFile:withSourceURL:andBytecodeCache:error:]):
+        (-[JSScript cacheBytecodeWithError:]):
+        (-[JSScript sourceURL]):
+        (-[JSScript type]):
+        (-[JSScript jsSourceCode]):
+        (-[JSScript writeCache:]):
+        (-[JSScript setSourceURL:]):
+        (-[JSScript forceRecreateJSSourceCode]):
+        (-[JSScript writeCache]): Deleted.
+        (-[JSScript jsSourceCode:]): Deleted.
+        * API/JSScriptInternal.h:
+        * API/tests/FunctionOverridesTest.cpp:
+        (testFunctionOverrides):
+        * API/tests/testapi.c:
+        (main):
+        * API/tests/testapi.mm:
+        (tempFile):
+        (testModuleBytecodeCache):
+        (testProgramBytecodeCache):
+        (testBytecodeCacheWithSyntaxError):
+        (testProgramJSScriptException):
+        (testLoadBasicFileLegacySPI):
+        (+[JSContextMemoryMappedLoaderDelegate newContext]):
+        (-[JSContextMemoryMappedLoaderDelegate context:fetchModuleForIdentifier:withResolveHandler:andRejectHandler:]):
+        (testLoadBasicFile):
+        (+[JSContextAugmentedLoaderDelegate newContext]):
+        (-[JSContextAugmentedLoaderDelegate context:fetchModuleForIdentifier:withResolveHandler:andRejectHandler:]):
+        (testJSScriptURL):
+        (testObjectiveCAPI):
+        (testBytecodeCache): Deleted.
+        * API/tests/testapiScripts/foo.js: Added.
+        * JavaScriptCore.xcodeproj/project.pbxproj:
+        * runtime/Completion.cpp:
+        (JSC::generateBytecode):
+        (JSC::generateModuleBytecode):
+
+2019-02-21  Mark Lam  <mark.lam@apple.com>
+
+        Add more doesGC() assertions.
+        https://bugs.webkit.org/show_bug.cgi?id=194911
+        <rdar://problem/48285723>
+
+        Reviewed by Saam Barati and Yusuke Suzuki.
+
+        * dfg/DFGOSRExit.cpp:
+        (JSC::DFG::OSRExit::compileOSRExit):
+        - Set expectDoesGC here because we no longer have to worry about missing store
+          barriers in optimized code after this point.  This will prevent false positive
+          assertion failures arising from functions called beneath compileOSRExit().
+
+        (JSC::DFG::OSRExit::compileExit):
+        - Add a comment to explain why the generated ramp needs to set expectDoesGC even
+          though compileOSRExit() also sets it.  Reason: compileOSRExit() is only called
+          for the first OSR from this code origin, the generated ramp is called for many
+          subsequents OSR exits from this code origin.
+
+        * ftl/FTLOSRExitCompiler.cpp:
+        (JSC::FTL::compileStub):
+        - Added a comment for the equivalent reason to the one above.
+
+        (JSC::FTL::compileFTLOSRExit):
+        - Set expectDoesGC here because we no longer have to worry about missing store
+          barriers in optimized code after this point.  This will prevent false positive
+          assertion failures arising from functions called beneath compileFTLOSRExit().
+
+        * heap/CompleteSubspace.cpp:
+        (JSC::CompleteSubspace::tryAllocateSlow):
+        * heap/CompleteSubspaceInlines.h:
+        (JSC::CompleteSubspace::allocateNonVirtual):
+        - assert expectDoesGC.
+
+        * heap/DeferGC.h:
+        (JSC::DeferGC::~DeferGC):
+        - assert expectDoesGC.
+        - Also added WTF_FORBID_HEAP_ALLOCATION to DeferGC, DeferGCForAWhile, and DisallowGC
+          because all 3 should be stack allocated RAII objects.
+
+        * heap/GCDeferralContext.h:
+        * heap/GCDeferralContextInlines.h:
+        (JSC::GCDeferralContext::~GCDeferralContext):
+        - Added WTF_FORBID_HEAP_ALLOCATION.
+        - assert expectDoesGC.
+
+        * heap/Heap.cpp:
+        (JSC::Heap::collectNow):
+        (JSC::Heap::collectAsync):
+        (JSC::Heap::collectSync):
+        (JSC::Heap::stopIfNecessarySlow):
+        (JSC::Heap::collectIfNecessaryOrDefer):
+        * heap/HeapInlines.h:
+        (JSC::Heap::acquireAccess):
+        (JSC::Heap::stopIfNecessary):
+        * heap/LargeAllocation.cpp:
+        (JSC::LargeAllocation::tryCreate):
+        * heap/LocalAllocatorInlines.h:
+        (JSC::LocalAllocator::allocate):
+        - conservatively assert expectDoesGC on these functions that may trigger a GC
+          though they don't always do.
+
+        * runtime/DisallowScope.h:
+        - DisallowScope should be stack allocated because it's an RAII object.
+
+        * runtime/JSCellInlines.h:
+        (JSC::tryAllocateCellHelper):
+        - Remove the expectDoesGC assertion because it is now covered by assertions in
+          CompleteSubspace, LargeAllocation, and LocalAllocator.
+
+        * runtime/RegExpMatchesArray.h:
+        (JSC::createRegExpMatchesArray):
+        - assert expectDoesGC.
+
+2019-02-21  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Use Fast Malloc as much as possible
+        https://bugs.webkit.org/show_bug.cgi?id=194316
+
+        Reviewed by Mark Lam.
+
+        We should use Fast Malloc as much as possible to offer the whole memory view to bmalloc.
+
+        * inspector/scripts/codegen/cpp_generator_templates.py:
+        * inspector/scripts/tests/all/expected/definitions-with-mac-platform.json-result:
+        * inspector/scripts/tests/generic/expected/enum-values.json-result:
+        * inspector/scripts/tests/generic/expected/events-with-optional-parameters.json-result:
+        * inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result:
+        * inspector/scripts/tests/mac/expected/definitions-with-mac-platform.json-result:
+        * jit/ExecutableAllocator.h:
+        * jsc.cpp:
+        * runtime/JSRunLoopTimer.h:
+        * tools/VMInspector.h:
+        * wasm/WasmThunks.h:
+
+2019-02-20  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Remove WatchpointSet creation for SymbolTable entries if VM::canUseJIT() returns false
+        https://bugs.webkit.org/show_bug.cgi?id=194891
+
+        Reviewed by Geoffrey Garen.
+
+        WatchpointSet in SymbolTable is used to fold the value into a constant in JIT tiers. And it is
+        not useful under the non-JIT mode. This patch avoids creation of WatchpointSet in SymbolTable
+        if VM::canUseJIT() returns false.
+
+        * llint/LowLevelInterpreter32_64.asm:
+        * llint/LowLevelInterpreter64.asm:
+        * runtime/SymbolTable.cpp:
+        (JSC::SymbolTableEntry::addWatchpoint): Deleted.
+        * runtime/SymbolTable.h:
+        (JSC::SymbolTableEntry::isWatchable const):
+        (JSC::SymbolTableEntry::watchpointSet):
+
+2019-02-20  Mark Lam  <mark.lam@apple.com>
+
+        Add code to validate expected GC activity modelled by doesGC() against what the runtime encounters.
+        https://bugs.webkit.org/show_bug.cgi?id=193938
+        <rdar://problem/47616277>
+
+        Reviewed by Michael Saboff, Saam Barati, and Robin Morisset.
+
+        In DFG::SpeculativeJIT::compile() and FTL::LowerDFGToB3::compileNode(), before
+        emitting code / B3IR for each DFG node, we emit a write to set Heap::m_expectDoesGC
+        to the value returned by doesGC() for that node.  In the runtime (i.e. in allocateCell()
+        and functions that can resolve a rope), we assert that Heap::m_expectDoesGC is
+        true.
+
+        This validation code is currently only enabled for debug builds.  It is disabled
+        for release builds by default, but it can easily be made to run on release builds
+        as well by forcing ENABLE_DFG_DOES_GC_VALIDATION to 1 in Heap.h.
+
+        To allow this validation code to run on release builds as well, the validation uses
+        RELEASE_ASSERT instead of ASSERT.
+
+        To ensure that Heap.h is #include'd for all files that needs to do this validation
+        (so that the validation code is accidentally disabled), we guard the validation
+        code with an if conditional on constexpr bool validateDFGDoesGC (instead of using
+        a #if ENABLE(DFG_DOES_GC_VALIDATION)).  This way, if Heap.h isn't #include'd, the
+        validation code will fail to build (no silent failures).
+
+        Currently, all JSC tests and Layout tests should pass with this validation enabled
+        in debug builds.  We'll only see new failures if there's a regression or if new
+        tests reveal a previously untested code path that has an undetected issue.
+
+        * dfg/DFGOSRExit.cpp:
+        (JSC::DFG::OSRExit::executeOSRExit):
+        (JSC::DFG::OSRExit::compileExit):
+        * dfg/DFGSpeculativeJIT64.cpp:
+        (JSC::DFG::SpeculativeJIT::compile):
+        * ftl/FTLLowerDFGToB3.cpp:
+        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
+        * ftl/FTLOSRExitCompiler.cpp:
+        (JSC::FTL::compileStub):
+        * heap/Heap.h:
+        (JSC::Heap::expectDoesGC const):
+        (JSC::Heap::setExpectDoesGC):
+        (JSC::Heap::addressOfExpectDoesGC):
+        * jit/JITArithmetic.cpp:
+        (JSC::JIT::emit_compareAndJump):
+        * runtime/JSCellInlines.h:
+        (JSC::tryAllocateCellHelper):
+        * runtime/JSString.h:
+        (JSC::jsSingleCharacterString):
+        (JSC::JSString::toAtomicString const):
+        (JSC::JSString::toExistingAtomicString const):
+        (JSC::JSString::value const):
+        (JSC::JSString::tryGetValue const):
+        (JSC::JSRopeString::unsafeView const):
+        (JSC::JSRopeString::viewWithUnderlyingString const):
+        (JSC::JSString::unsafeView const):
+
+2019-02-20  Andy Estes  <aestes@apple.com>
+
+        [Xcode] Add SDKVariant.xcconfig to various Xcode projects
+        https://bugs.webkit.org/show_bug.cgi?id=194869
+
+        Rubber-stamped by Jer Noble.
+
+        * JavaScriptCore.xcodeproj/project.pbxproj:
+
+2019-02-19  Joseph Pecoraro  <pecoraro@apple.com>
+
+        Web Inspector: Improve ES6 Class instances in Heap Snapshot instances view
+        https://bugs.webkit.org/show_bug.cgi?id=172848
+        <rdar://problem/25709212>
+
+        Reviewed by Mark Lam.
+
+        * heap/HeapSnapshotBuilder.h:
+        * heap/HeapSnapshotBuilder.cpp:
+        Update the snapshot version. Change the node's 0 | 1 internal value
+        to be a 32bit bit flag. This is nice in that it is both compatible
+        with the previous snapshot version and the same size. We can use more
+        flags in the future.
+
+        (JSC::HeapSnapshotBuilder::json):
+        In cases where the classInfo gives us "Object" check for a better
+        class name by checking (o).__proto__.constructor.name. We avoid this
+        check in cases where (o).hasOwnProperty("constructor") which is the
+        case for most Foo.prototype objects. Otherwise this would get the
+        name of the Foo superclass for the Foo.prototype object.
+
+        * runtime/JSObject.cpp:
+        (JSC::JSObject::calculatedClassName):
+        Handle some possible edge cases that were not handled before, such as
+        a JSObject without a GlobalObject or an object which doesn't
+        have a default getPrototype. Try to make the code a little clearer.
+
+2019-02-19  Truitt Savell  <tsavell@apple.com>
+
+        Unreviewed, rolling out r241784.
+
+        Broke all OpenSource builds.
+
+        Reverted changeset:
+
+        "Web Inspector: Improve ES6 Class instances in Heap Snapshot
+        instances view"
+        https://bugs.webkit.org/show_bug.cgi?id=172848
+        https://trac.webkit.org/changeset/241784
+
+2019-02-19  Joseph Pecoraro  <pecoraro@apple.com>
+
+        Web Inspector: Improve ES6 Class instances in Heap Snapshot instances view
+        https://bugs.webkit.org/show_bug.cgi?id=172848
+        <rdar://problem/25709212>
+
+        Reviewed by Mark Lam.
+
+        * heap/HeapSnapshotBuilder.h:
+        * heap/HeapSnapshotBuilder.cpp:
+        Update the snapshot version. Change the node's 0 | 1 internal value
+        to be a 32bit bit flag. This is nice in that it is both compatible
+        with the previous snapshot version and the same size. We can use more
+        flags in the future.
+
+        (JSC::HeapSnapshotBuilder::json):
+        In cases where the classInfo gives us "Object" check for a better
+        class name by checking (o).__proto__.constructor.name. We avoid this
+        check in cases where (o).hasOwnProperty("constructor") which is the
+        case for most Foo.prototype objects. Otherwise this would get the
+        name of the Foo superclass for the Foo.prototype object.
+
+        * runtime/JSObject.cpp:
+        (JSC::JSObject::calculatedClassName):
+        Handle some possible edge cases that were not handled before, such as
+        a JSObject without a GlobalObject or an object which doesn't
+        have a default getPrototype. Try to make the code a little clearer.
+
+2019-02-19  Robin Morisset  <rmorisset@apple.com>
+
+        B3-O2 incorrectly optimizes this subtest
+        https://bugs.webkit.org/show_bug.cgi?id=194625
+
+        Reviewed by Saam Barati.
+
+        Trivial fix. Instead of doing
+            if (!cond) foo else bar => if (cond) bar else foo
+        B3LowerToAir was doing
+            if (x^C) foo else bar => if (cond) bar else foo whenever C&1, even if C was for example 3.
+
+        * b3/B3LowerToAir.cpp:
+        * b3/testb3.cpp:
+        (JSC::B3::testBitNotOnBooleanAndBranch32):
+        (JSC::B3::testNotOnBooleanAndBranch32): Added.
+
+2019-02-19  Robin Morisset  <rmorisset@apple.com>
+
+        CachedCall should not consider it UNLIKELY that it will not stack overflow
+        https://bugs.webkit.org/show_bug.cgi?id=194831
+
+        Reviewed by Mark Lam.
+
+        * interpreter/CachedCall.h:
+        (JSC::CachedCall::CachedCall):
+
+2019-02-19  Mark Lam  <mark.lam@apple.com>
+
+        Fix DFG doesGC() for TryGetById and ProfileType nodes.
+        https://bugs.webkit.org/show_bug.cgi?id=194821
+        <rdar://problem/48206690>
+
+        Reviewed by Saam Barati.
+
+        Fix doesGC() for the following nodes:
+
+            ProfileType:
+                calls operationProcessTypeProfilerLogDFG(), which can calculatedClassName(),
+                which can call JSString::tryGetValue(), which can resolve a rope.
+
+            TryGetById:
+                calls operationTryGetByIdOptimize(), which can startWatchingPropertyForReplacements()
+                on a structure, which can allocate StructureRareData.
+
+        * dfg/DFGDoesGC.cpp:
+        (JSC::DFG::doesGC):
+
+2019-02-18  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Introduce JSNonDestructibleProxy for JavaScriptCore.framework's GlobalThis
+        https://bugs.webkit.org/show_bug.cgi?id=194799
+
+        Reviewed by Saam Barati.
+
+        JSProxy is destructible one because we have JSWindowProxy which has ref counted object.
+        However, JavaScriptCore.framework's JSProxy for GlobalThis does not need to be destructible.
+        This is important since we need to separate Heap subspaces between destructible and non-destructible objects.
+        If we can put more and more objects in non-destructible status, we can get rid of low-usage MarkedBlock.
+        This patch adds JSNonDestructibleProxy, which is not destructible JSProxy. While it inherits JSDestructibleObject,
+        we can make the subclass still non-destructible thanks to Subspace mechanism. This drops one more low-usage MarkedBlock.
+
+        * CMakeLists.txt:
+        * JavaScriptCore.xcodeproj/project.pbxproj:
+        * Sources.txt:
+        * runtime/JSGlobalObject.cpp:
+        (JSC::JSGlobalObject::resetPrototype):
+        (JSC::JSGlobalObject::finishCreation):
+        * runtime/JSNonDestructibleProxy.cpp: Added.
+        * runtime/JSNonDestructibleProxy.h: Added.
+        (JSC::JSNonDestructibleProxy::subspaceFor):
+        (JSC::JSNonDestructibleProxy::create):
+        (JSC::JSNonDestructibleProxy::createStructure):
+        (JSC::JSNonDestructibleProxy::JSNonDestructibleProxy):
+        * runtime/JSProxy.h:
+        (JSC::JSProxy::JSProxy):
+
 2019-02-19  Robin Morisset  <rmorisset@apple.com>
 
         B3ReduceStrength::simplifyCFG() could do a lot more on each iteration