ChangeLog   [plain text]


2018-04-26  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r230459. rdar://problem/39766214

    [JSC] Introduce @putByIdDirectPrivate
    https://bugs.webkit.org/show_bug.cgi?id=184400
    
    Reviewed by Saam Barati.
    
    This patch adds @putByIdDirectPrivate() to use it for builtin JS.
    @getByIdDirectPrivate and @putByIdDirectPrivate are pair of intrinsics
    accessing to ECMAScript internal fields.
    
    This change removes accidental [[Put]] operation to an object whose [[Prototype]]
    has internal fields (not direct properties). By using @getByIdDirectPrivate() and
    @putByIdDirectPrivate(), we strongly keep the semantics of the ECMAScript internal
    fields that accessing to the internal fields does not traverse prototype chains.
    
    * builtins/ArrayIteratorPrototype.js:
    (globalPrivate.arrayIteratorValueNext):
    (globalPrivate.arrayIteratorKeyNext):
    (globalPrivate.arrayIteratorKeyValueNext):
    * builtins/ArrayPrototype.js:
    (globalPrivate.createArrayIterator):
    * builtins/AsyncFromSyncIteratorPrototype.js:
    (globalPrivate.AsyncFromSyncIteratorConstructor):
    * builtins/AsyncFunctionPrototype.js:
    (globalPrivate.asyncFunctionResume):
    * builtins/AsyncGeneratorPrototype.js:
    (globalPrivate.asyncGeneratorQueueEnqueue):
    (globalPrivate.asyncGeneratorQueueDequeue):
    (asyncGeneratorYieldAwaited):
    (globalPrivate.asyncGeneratorYield):
    (globalPrivate.doAsyncGeneratorBodyCall):
    (globalPrivate.asyncGeneratorResumeNext):
    * builtins/GeneratorPrototype.js:
    (globalPrivate.generatorResume):
    * builtins/MapIteratorPrototype.js:
    (globalPrivate.mapIteratorNext):
    * builtins/MapPrototype.js:
    (globalPrivate.createMapIterator):
    * builtins/ModuleLoaderPrototype.js:
    (forceFulfillPromise):
    * builtins/PromiseOperations.js:
    (globalPrivate.newHandledRejectedPromise):
    (globalPrivate.rejectPromise):
    (globalPrivate.fulfillPromise):
    (globalPrivate.initializePromise):
    * builtins/PromisePrototype.js:
    (then):
    * builtins/SetIteratorPrototype.js:
    (globalPrivate.setIteratorNext):
    * builtins/SetPrototype.js:
    (globalPrivate.createSetIterator):
    * builtins/StringIteratorPrototype.js:
    (next):
    * bytecode/BytecodeIntrinsicRegistry.h:
    * bytecompiler/NodesCodegen.cpp:
    (JSC::BytecodeIntrinsicNode::emit_intrinsic_putByIdDirect):
    (JSC::BytecodeIntrinsicNode::emit_intrinsic_putByIdDirectPrivate):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230459 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2018-04-08  Yusuke Suzuki  <utatane.tea@gmail.com>

            [JSC] Introduce @putByIdDirectPrivate
            https://bugs.webkit.org/show_bug.cgi?id=184400

            Reviewed by Saam Barati.

            This patch adds @putByIdDirectPrivate() to use it for builtin JS.
            @getByIdDirectPrivate and @putByIdDirectPrivate are pair of intrinsics
            accessing to ECMAScript internal fields.

            This change removes accidental [[Put]] operation to an object whose [[Prototype]]
            has internal fields (not direct properties). By using @getByIdDirectPrivate() and
            @putByIdDirectPrivate(), we strongly keep the semantics of the ECMAScript internal
            fields that accessing to the internal fields does not traverse prototype chains.

            * builtins/ArrayIteratorPrototype.js:
            (globalPrivate.arrayIteratorValueNext):
            (globalPrivate.arrayIteratorKeyNext):
            (globalPrivate.arrayIteratorKeyValueNext):
            * builtins/ArrayPrototype.js:
            (globalPrivate.createArrayIterator):
            * builtins/AsyncFromSyncIteratorPrototype.js:
            (globalPrivate.AsyncFromSyncIteratorConstructor):
            * builtins/AsyncFunctionPrototype.js:
            (globalPrivate.asyncFunctionResume):
            * builtins/AsyncGeneratorPrototype.js:
            (globalPrivate.asyncGeneratorQueueEnqueue):
            (globalPrivate.asyncGeneratorQueueDequeue):
            (asyncGeneratorYieldAwaited):
            (globalPrivate.asyncGeneratorYield):
            (globalPrivate.doAsyncGeneratorBodyCall):
            (globalPrivate.asyncGeneratorResumeNext):
            * builtins/GeneratorPrototype.js:
            (globalPrivate.generatorResume):
            * builtins/MapIteratorPrototype.js:
            (globalPrivate.mapIteratorNext):
            * builtins/MapPrototype.js:
            (globalPrivate.createMapIterator):
            * builtins/ModuleLoaderPrototype.js:
            (forceFulfillPromise):
            * builtins/PromiseOperations.js:
            (globalPrivate.newHandledRejectedPromise):
            (globalPrivate.rejectPromise):
            (globalPrivate.fulfillPromise):
            (globalPrivate.initializePromise):
            * builtins/PromisePrototype.js:
            (then):
            * builtins/SetIteratorPrototype.js:
            (globalPrivate.setIteratorNext):
            * builtins/SetPrototype.js:
            (globalPrivate.createSetIterator):
            * builtins/StringIteratorPrototype.js:
            (next):
            * bytecode/BytecodeIntrinsicRegistry.h:
            * bytecompiler/NodesCodegen.cpp:
            (JSC::BytecodeIntrinsicNode::emit_intrinsic_putByIdDirect):
            (JSC::BytecodeIntrinsicNode::emit_intrinsic_putByIdDirectPrivate):

2018-04-17  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r230662. rdar://problem/39496355

    Function.prototype.caller shouldn't return generator bodies
    https://bugs.webkit.org/show_bug.cgi?id=184630
    
    Reviewed by Yusuke Suzuki.
    JSTests:
    
    
    * stress/function-caller-async-arrow-function-body.js: Added.
    * stress/function-caller-async-function-body.js: Added.
    * stress/function-caller-async-generator-body.js: Added.
    * stress/function-caller-generator-body.js: Added.
    * stress/function-caller-generator-method-body.js: Added.
    
    Source/JavaScriptCore:
    
            
    Function.prototype.caller no longer returns generator bodies. Those are meant to be
    private.
            
    Also added some builtin debugging tools so that it's easier to do the investigation that I
    did.
    
    * builtins/BuiltinNames.h:
    * runtime/JSFunction.cpp:
    (JSC::JSFunction::callerGetter):
    * runtime/JSGlobalObject.cpp:
    (JSC::JSGlobalObject::init):
    * runtime/JSGlobalObjectFunctions.cpp:
    (JSC::globalFuncBuiltinDescribe):
    * runtime/JSGlobalObjectFunctions.h:
    
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230662 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2018-04-14  Filip Pizlo  <fpizlo@apple.com>

            Function.prototype.caller shouldn't return generator bodies
            https://bugs.webkit.org/show_bug.cgi?id=184630

            Reviewed by Yusuke Suzuki.

            Function.prototype.caller no longer returns generator bodies. Those are meant to be
            private.

            Also added some builtin debugging tools so that it's easier to do the investigation that I
            did.

            * builtins/BuiltinNames.h:
            * runtime/JSFunction.cpp:
            (JSC::JSFunction::callerGetter):
            * runtime/JSGlobalObject.cpp:
            (JSC::JSGlobalObject::init):
            * runtime/JSGlobalObjectFunctions.cpp:
            (JSC::globalFuncBuiltinDescribe):
            * runtime/JSGlobalObjectFunctions.h:

2018-04-11  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r230494. rdar://problem/39337455

    Unreviewed, fix cloop build.
    
    * dfg/DFGAbstractInterpreterClobberState.cpp:
    
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230494 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2018-04-10  Filip Pizlo  <fpizlo@apple.com>

            Unreviewed, fix cloop build.

            * dfg/DFGAbstractInterpreterClobberState.cpp:

2018-04-11  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r227692. rdar://problem/39337417

    We should only append ParserArenaDeletable pointers to ParserArena::m_deletableObjects.
    https://bugs.webkit.org/show_bug.cgi?id=182180
    <rdar://problem/36460697>
    
    Reviewed by Michael Saboff.
    
    Some parser Node subclasses extend ParserArenaDeletable via multiple inheritance,
    but not as the Node's first base class.  ParserArena::m_deletableObjects is
    expecting pointers to objects of the shape of ParserArenaDeletable.  We ensure
    this by allocating the Node subclass, and casting it to ParserArenaDeletable to
    get the correct pointer to append to ParserArena::m_deletableObjects.
    
    To simplify things, we introduce a JSC_MAKE_PARSER_ARENA_DELETABLE_ALLOCATED 
    (analogous to WTF_MAKE_FAST_ALLOCATED) for use in Node subclasses that extends
    ParserArenaDeletable.
    
    * parser/NodeConstructors.h:
    (JSC::ParserArenaDeletable::operator new):
    * parser/Nodes.h:
    * parser/ParserArena.h:
    (JSC::ParserArena::allocateDeletable):
    
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@227692 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2018-01-26  Mark Lam  <mark.lam@apple.com>

            We should only append ParserArenaDeletable pointers to ParserArena::m_deletableObjects.
            https://bugs.webkit.org/show_bug.cgi?id=182180
            <rdar://problem/36460697>

            Reviewed by Michael Saboff.

            Some parser Node subclasses extend ParserArenaDeletable via multiple inheritance,
            but not as the Node's first base class.  ParserArena::m_deletableObjects is
            expecting pointers to objects of the shape of ParserArenaDeletable.  We ensure
            this by allocating the Node subclass, and casting it to ParserArenaDeletable to
            get the correct pointer to append to ParserArena::m_deletableObjects.

            To simplify things, we introduce a JSC_MAKE_PARSER_ARENA_DELETABLE_ALLOCATED
            (analogous to WTF_MAKE_FAST_ALLOCATED) for use in Node subclasses that extends
            ParserArenaDeletable.

            * parser/NodeConstructors.h:
            (JSC::ParserArenaDeletable::operator new):
            * parser/Nodes.h:
            * parser/ParserArena.h:
            (JSC::ParserArena::allocateDeletable):

2018-04-10  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r230379. rdar://problem/39317885

    Unreviewed, follow-up patch for DFG 32bit
    https://bugs.webkit.org/show_bug.cgi?id=183970
    
    * dfg/DFGSpeculativeJIT32_64.cpp:
    (JSC::DFG::SpeculativeJIT::cachedGetById):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230379 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2018-04-08  Yusuke Suzuki  <utatane.tea@gmail.com>

            Unreviewed, follow-up patch for DFG 32bit
            https://bugs.webkit.org/show_bug.cgi?id=183970

            * dfg/DFGSpeculativeJIT32_64.cpp:
            (JSC::DFG::SpeculativeJIT::cachedGetById):

2018-04-10  Kocsen Chung  <kocsen_chung@apple.com>

        Cherry-pick r230376. rdar://problem/39317885

    [JSC] Introduce op_get_by_id_direct
    https://bugs.webkit.org/show_bug.cgi?id=183970
    
    Reviewed by Filip Pizlo.
    
    JSTests:
    
    * stress/generator-prototype-copy.js: Added.
    (gen):
    (catch):
    Adopted JF's tests.
    
    * stress/generator-type-check.js: Added.
    (shouldThrow):
    (foo2):
    (i.shouldThrow):
    * stress/get-by-id-direct-getter.js: Added.
    (shouldBe):
    (shouldThrow):
    (obj.get hello):
    (builtin.createBuiltin):
    (obj2.get length):
    * stress/get-by-id-direct.js: Added.
    (shouldBe):
    (shouldThrow):
    (builtin.createBuiltin):
    * test262.yaml:
    We fixed long-standing spec compatibility issue.
    As a result, this patch makes several test262 tests passed!
    
    Source/JavaScriptCore:
    
    This patch introduces op_get_by_id_direct bytecode. This is super similar to op_get_by_id.
    But it just performs [[GetOwnProperty]] operation instead of [[Get]]. We support this
    in all the tiers, so using this opcode does not lead to inefficiency.
    
    Main purpose of this op_get_by_id_direct is using it for private properties. We are using
    properties indexed with private symbols to implement ECMAScript internal fields. Before this
    patch, we just use get and put operations. However, it is not the correct semantics: accessing
    to the internal fields should not traverse prototype chain, which is specified in the spec.
    We use op_get_by_id_direct to access to properties which are used internal fields, so that
    prototype chains are not traversed.
    
    To emit op_get_by_id_direct, we introduce a new bytecode intrinsic @getByIdDirectPrivate().
    When you write `@getByIdDirectPrivate(object, "name")`, the bytecode generator emits the
    bytecode `op_get_by_id_direct, object, @name`.
    
    * builtins/ArrayIteratorPrototype.js:
    (next):
    (globalPrivate.arrayIteratorValueNext):
    (globalPrivate.arrayIteratorKeyNext):
    (globalPrivate.arrayIteratorKeyValueNext):
    * builtins/AsyncFromSyncIteratorPrototype.js:
    * builtins/AsyncFunctionPrototype.js:
    (globalPrivate.asyncFunctionResume):
    * builtins/AsyncGeneratorPrototype.js:
    (globalPrivate.asyncGeneratorQueueIsEmpty):
    (globalPrivate.asyncGeneratorQueueEnqueue):
    (globalPrivate.asyncGeneratorQueueDequeue):
    (globalPrivate.asyncGeneratorDequeue):
    (globalPrivate.isExecutionState):
    (globalPrivate.isSuspendYieldState):
    (globalPrivate.asyncGeneratorReject):
    (globalPrivate.asyncGeneratorResolve):
    (globalPrivate.doAsyncGeneratorBodyCall):
    (globalPrivate.asyncGeneratorEnqueue):
    * builtins/GeneratorPrototype.js:
    (globalPrivate.generatorResume):
    (next):
    (return):
    (throw):
    * builtins/MapIteratorPrototype.js:
    (next):
    * builtins/PromiseOperations.js:
    (globalPrivate.isPromise):
    (globalPrivate.rejectPromise):
    (globalPrivate.fulfillPromise):
    * builtins/PromisePrototype.js:
    (then):
    * builtins/SetIteratorPrototype.js:
    (next):
    * builtins/StringIteratorPrototype.js:
    (next):
    * builtins/TypedArrayConstructor.js:
    (of):
    (from):
    * bytecode/BytecodeDumper.cpp:
    (JSC::BytecodeDumper<Block>::dumpBytecode):
    * bytecode/BytecodeIntrinsicRegistry.h:
    * bytecode/BytecodeList.json:
    * bytecode/BytecodeUseDef.h:
    (JSC::computeUsesForBytecodeOffset):
    (JSC::computeDefsForBytecodeOffset):
    * bytecode/CodeBlock.cpp:
    (JSC::CodeBlock::finishCreation):
    (JSC::CodeBlock::finalizeLLIntInlineCaches):
    * bytecode/GetByIdStatus.cpp:
    (JSC::GetByIdStatus::computeFromLLInt):
    (JSC::GetByIdStatus::computeFor):
    * bytecode/StructureStubInfo.cpp:
    (JSC::StructureStubInfo::reset):
    * bytecode/StructureStubInfo.h:
    (JSC::appropriateOptimizingGetByIdFunction):
    (JSC::appropriateGenericGetByIdFunction):
    * bytecompiler/BytecodeGenerator.cpp:
    (JSC::BytecodeGenerator::emitDirectGetById):
    * bytecompiler/BytecodeGenerator.h:
    * bytecompiler/NodesCodegen.cpp:
    (JSC::BytecodeIntrinsicNode::emit_intrinsic_getByIdDirect):
    (JSC::BytecodeIntrinsicNode::emit_intrinsic_getByIdDirectPrivate):
    * dfg/DFGAbstractInterpreterInlines.h:
    (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
    * dfg/DFGByteCodeParser.cpp:
    (JSC::DFG::ByteCodeParser::handleGetById):
    (JSC::DFG::ByteCodeParser::parseBlock):
    * dfg/DFGCapabilities.cpp:
    (JSC::DFG::capabilityLevel):
    * dfg/DFGClobberize.h:
    (JSC::DFG::clobberize):
    * dfg/DFGConstantFoldingPhase.cpp:
    (JSC::DFG::ConstantFoldingPhase::foldConstants):
    * dfg/DFGDoesGC.cpp:
    (JSC::DFG::doesGC):
    * dfg/DFGFixupPhase.cpp:
    (JSC::DFG::FixupPhase::fixupNode):
    * dfg/DFGNode.h:
    (JSC::DFG::Node::convertToGetByOffset):
    (JSC::DFG::Node::convertToMultiGetByOffset):
    (JSC::DFG::Node::hasIdentifier):
    (JSC::DFG::Node::hasHeapPrediction):
    * dfg/DFGNodeType.h:
    * dfg/DFGOperations.cpp:
    * dfg/DFGOperations.h:
    * dfg/DFGPredictionPropagationPhase.cpp:
    * dfg/DFGSafeToExecute.h:
    (JSC::DFG::safeToExecute):
    * dfg/DFGSpeculativeJIT.cpp:
    (JSC::DFG::SpeculativeJIT::compileGetById):
    (JSC::DFG::SpeculativeJIT::compileGetByIdFlush):
    (JSC::DFG::SpeculativeJIT::compileTryGetById): Deleted.
    * dfg/DFGSpeculativeJIT.h:
    * dfg/DFGSpeculativeJIT32_64.cpp:
    (JSC::DFG::SpeculativeJIT::cachedGetById):
    (JSC::DFG::SpeculativeJIT::compile):
    * dfg/DFGSpeculativeJIT64.cpp:
    (JSC::DFG::SpeculativeJIT::cachedGetById):
    (JSC::DFG::SpeculativeJIT::compile):
    * ftl/FTLCapabilities.cpp:
    (JSC::FTL::canCompile):
    * ftl/FTLLowerDFGToB3.cpp:
    (JSC::FTL::DFG::LowerDFGToB3::compileNode):
    (JSC::FTL::DFG::LowerDFGToB3::compileGetById):
    (JSC::FTL::DFG::LowerDFGToB3::compileGetByIdWithThis):
    (JSC::FTL::DFG::LowerDFGToB3::getById):
    * jit/JIT.cpp:
    (JSC::JIT::privateCompileMainPass):
    (JSC::JIT::privateCompileSlowCases):
    * jit/JIT.h:
    * jit/JITOperations.cpp:
    * jit/JITOperations.h:
    * jit/JITPropertyAccess.cpp:
    (JSC::JIT::emit_op_get_by_id_direct):
    (JSC::JIT::emitSlow_op_get_by_id_direct):
    * jit/JITPropertyAccess32_64.cpp:
    (JSC::JIT::emit_op_get_by_id_direct):
    (JSC::JIT::emitSlow_op_get_by_id_direct):
    * jit/Repatch.cpp:
    (JSC::appropriateOptimizingGetByIdFunction):
    (JSC::appropriateGetByIdFunction):
    (JSC::tryCacheGetByID):
    (JSC::repatchGetByID):
    (JSC::appropriateGenericGetByIdFunction): Deleted.
    * jit/Repatch.h:
    * llint/LLIntSlowPaths.cpp:
    (JSC::LLInt::LLINT_SLOW_PATH_DECL):
    * llint/LLIntSlowPaths.h:
    * llint/LowLevelInterpreter32_64.asm:
    * llint/LowLevelInterpreter64.asm:
    * runtime/JSCJSValue.h:
    * runtime/JSCJSValueInlines.h:
    (JSC::JSValue::getOwnPropertySlot const):
    * runtime/JSObject.h:
    * runtime/JSObjectInlines.h:
    (JSC::JSObject::getOwnPropertySlotInline):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230376 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2018-04-08  Yusuke Suzuki  <utatane.tea@gmail.com>

            [JSC] Introduce op_get_by_id_direct
            https://bugs.webkit.org/show_bug.cgi?id=183970

            Reviewed by Filip Pizlo.

            This patch introduces op_get_by_id_direct bytecode. This is super similar to op_get_by_id.
            But it just performs [[GetOwnProperty]] operation instead of [[Get]]. We support this
            in all the tiers, so using this opcode does not lead to inefficiency.

            Main purpose of this op_get_by_id_direct is using it for private properties. We are using
            properties indexed with private symbols to implement ECMAScript internal fields. Before this
            patch, we just use get and put operations. However, it is not the correct semantics: accessing
            to the internal fields should not traverse prototype chain, which is specified in the spec.
            We use op_get_by_id_direct to access to properties which are used internal fields, so that
            prototype chains are not traversed.

            To emit op_get_by_id_direct, we introduce a new bytecode intrinsic @getByIdDirectPrivate().
            When you write `@getByIdDirectPrivate(object, "name")`, the bytecode generator emits the
            bytecode `op_get_by_id_direct, object, @name`.

            * builtins/ArrayIteratorPrototype.js:
            (next):
            (globalPrivate.arrayIteratorValueNext):
            (globalPrivate.arrayIteratorKeyNext):
            (globalPrivate.arrayIteratorKeyValueNext):
            * builtins/AsyncFromSyncIteratorPrototype.js:
            * builtins/AsyncFunctionPrototype.js:
            (globalPrivate.asyncFunctionResume):
            * builtins/AsyncGeneratorPrototype.js:
            (globalPrivate.asyncGeneratorQueueIsEmpty):
            (globalPrivate.asyncGeneratorQueueEnqueue):
            (globalPrivate.asyncGeneratorQueueDequeue):
            (globalPrivate.asyncGeneratorDequeue):
            (globalPrivate.isExecutionState):
            (globalPrivate.isSuspendYieldState):
            (globalPrivate.asyncGeneratorReject):
            (globalPrivate.asyncGeneratorResolve):
            (globalPrivate.doAsyncGeneratorBodyCall):
            (globalPrivate.asyncGeneratorEnqueue):
            * builtins/GeneratorPrototype.js:
            (globalPrivate.generatorResume):
            (next):
            (return):
            (throw):
            * builtins/MapIteratorPrototype.js:
            (next):
            * builtins/PromiseOperations.js:
            (globalPrivate.isPromise):
            (globalPrivate.rejectPromise):
            (globalPrivate.fulfillPromise):
            * builtins/PromisePrototype.js:
            (then):
            * builtins/SetIteratorPrototype.js:
            (next):
            * builtins/StringIteratorPrototype.js:
            (next):
            * builtins/TypedArrayConstructor.js:
            (of):
            (from):
            * bytecode/BytecodeDumper.cpp:
            (JSC::BytecodeDumper<Block>::dumpBytecode):
            * bytecode/BytecodeIntrinsicRegistry.h:
            * bytecode/BytecodeList.json:
            * bytecode/BytecodeUseDef.h:
            (JSC::computeUsesForBytecodeOffset):
            (JSC::computeDefsForBytecodeOffset):
            * bytecode/CodeBlock.cpp:
            (JSC::CodeBlock::finishCreation):
            (JSC::CodeBlock::finalizeLLIntInlineCaches):
            * bytecode/GetByIdStatus.cpp:
            (JSC::GetByIdStatus::computeFromLLInt):
            (JSC::GetByIdStatus::computeFor):
            * bytecode/StructureStubInfo.cpp:
            (JSC::StructureStubInfo::reset):
            * bytecode/StructureStubInfo.h:
            (JSC::appropriateOptimizingGetByIdFunction):
            (JSC::appropriateGenericGetByIdFunction):
            * bytecompiler/BytecodeGenerator.cpp:
            (JSC::BytecodeGenerator::emitDirectGetById):
            * bytecompiler/BytecodeGenerator.h:
            * bytecompiler/NodesCodegen.cpp:
            (JSC::BytecodeIntrinsicNode::emit_intrinsic_getByIdDirect):
            (JSC::BytecodeIntrinsicNode::emit_intrinsic_getByIdDirectPrivate):
            * dfg/DFGAbstractInterpreterInlines.h:
            (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
            * dfg/DFGByteCodeParser.cpp:
            (JSC::DFG::ByteCodeParser::handleGetById):
            (JSC::DFG::ByteCodeParser::parseBlock):
            * dfg/DFGCapabilities.cpp:
            (JSC::DFG::capabilityLevel):
            * dfg/DFGClobberize.h:
            (JSC::DFG::clobberize):
            * dfg/DFGConstantFoldingPhase.cpp:
            (JSC::DFG::ConstantFoldingPhase::foldConstants):
            * dfg/DFGDoesGC.cpp:
            (JSC::DFG::doesGC):
            * dfg/DFGFixupPhase.cpp:
            (JSC::DFG::FixupPhase::fixupNode):
            * dfg/DFGNode.h:
            (JSC::DFG::Node::convertToGetByOffset):
            (JSC::DFG::Node::convertToMultiGetByOffset):
            (JSC::DFG::Node::hasIdentifier):
            (JSC::DFG::Node::hasHeapPrediction):
            * dfg/DFGNodeType.h:
            * dfg/DFGOperations.cpp:
            * dfg/DFGOperations.h:
            * dfg/DFGPredictionPropagationPhase.cpp:
            * dfg/DFGSafeToExecute.h:
            (JSC::DFG::safeToExecute):
            * dfg/DFGSpeculativeJIT.cpp:
            (JSC::DFG::SpeculativeJIT::compileGetById):
            (JSC::DFG::SpeculativeJIT::compileGetByIdFlush):
            (JSC::DFG::SpeculativeJIT::compileTryGetById): Deleted.
            * dfg/DFGSpeculativeJIT.h:
            * dfg/DFGSpeculativeJIT32_64.cpp:
            (JSC::DFG::SpeculativeJIT::cachedGetById):
            (JSC::DFG::SpeculativeJIT::compile):
            * dfg/DFGSpeculativeJIT64.cpp:
            (JSC::DFG::SpeculativeJIT::cachedGetById):
            (JSC::DFG::SpeculativeJIT::compile):
            * ftl/FTLCapabilities.cpp:
            (JSC::FTL::canCompile):
            * ftl/FTLLowerDFGToB3.cpp:
            (JSC::FTL::DFG::LowerDFGToB3::compileNode):
            (JSC::FTL::DFG::LowerDFGToB3::compileGetById):
            (JSC::FTL::DFG::LowerDFGToB3::compileGetByIdWithThis):
            (JSC::FTL::DFG::LowerDFGToB3::getById):
            * jit/JIT.cpp:
            (JSC::JIT::privateCompileMainPass):
            (JSC::JIT::privateCompileSlowCases):
            * jit/JIT.h:
            * jit/JITOperations.cpp:
            * jit/JITOperations.h:
            * jit/JITPropertyAccess.cpp:
            (JSC::JIT::emit_op_get_by_id_direct):
            (JSC::JIT::emitSlow_op_get_by_id_direct):
            * jit/JITPropertyAccess32_64.cpp:
            (JSC::JIT::emit_op_get_by_id_direct):
            (JSC::JIT::emitSlow_op_get_by_id_direct):
            * jit/Repatch.cpp:
            (JSC::appropriateOptimizingGetByIdFunction):
            (JSC::appropriateGetByIdFunction):
            (JSC::tryCacheGetByID):
            (JSC::repatchGetByID):
            (JSC::appropriateGenericGetByIdFunction): Deleted.
            * jit/Repatch.h:
            * llint/LLIntSlowPaths.cpp:
            (JSC::LLInt::LLINT_SLOW_PATH_DECL):
            * llint/LLIntSlowPaths.h:
            * llint/LowLevelInterpreter32_64.asm:
            * llint/LowLevelInterpreter64.asm:
            * runtime/JSCJSValue.h:
            * runtime/JSCJSValueInlines.h:
            (JSC::JSValue::getOwnPropertySlot const):
            * runtime/JSObject.h:
            * runtime/JSObjectInlines.h:
            (JSC::JSObject::getOwnPropertySlotInline):

2018-04-05  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r230287. rdar://problem/39208588

    REGRESSION(r222563): removed DoubleReal type check causes tons of crashes because CSE has never known how to handle SaneChain
    https://bugs.webkit.org/show_bug.cgi?id=184319
    
    Reviewed by Saam Barati.
    
    JSTests:
    
    * stress/array-push-nan-to-double-array-cse-sane-and-insane-chain.js: Added.
    (foo):
    (bar):
    * stress/array-push-nan-to-double-array.js: Added.
    (foo):
    (bar):
    
    Source/JavaScriptCore:
    
    In r222581, we replaced type checks about DoubleReal in ArrayPush in the DFG/FTL backends with
    assertions. That's correct because FixupPhase was emitting those checks as Check(DoubleRealRep:) before
    the ArrayPush.
    
    But this revealed a longstanding CSE bug: CSE will happily match a SaneChain GetByVal with a InBounds
    GetByVal. SaneChain can return NaN while InBounds cannot. This means that if we first use AI to
    eliminate the Check(DoubleRealRep:) based on the input being a GetByVal(InBounds) but then replace that
    with a GetByVal(SaneChain), then we will hit the assertion.
    
    This teaches CSE to not replace GetByVal(InBounds) with GetByVal(SaneChain) and vice versa. That gets
    tricky because PutByVal can match either. So, we use the fact that it's legal for a store to def() more
    than once: PutByVal now defs() a HeapLocation for InBounds and a HeapLocation for SaneChain.
    
    * dfg/DFGCSEPhase.cpp:
    * dfg/DFGClobberize.h:
    (JSC::DFG::clobberize):
    * dfg/DFGHeapLocation.cpp:
    (WTF::printInternal):
    * dfg/DFGHeapLocation.h:
    * dfg/DFGSpeculativeJIT.cpp:
    (JSC::DFG::SpeculativeJIT::compileArrayPush):
    
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230287 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2018-04-04  Filip Pizlo  <fpizlo@apple.com>

            REGRESSION(r222563): removed DoubleReal type check causes tons of crashes because CSE has never known how to handle SaneChain
            https://bugs.webkit.org/show_bug.cgi?id=184319

            Reviewed by Saam Barati.

            In r222581, we replaced type checks about DoubleReal in ArrayPush in the DFG/FTL backends with
            assertions. That's correct because FixupPhase was emitting those checks as Check(DoubleRealRep:) before
            the ArrayPush.

            But this revealed a longstanding CSE bug: CSE will happily match a SaneChain GetByVal with a InBounds
            GetByVal. SaneChain can return NaN while InBounds cannot. This means that if we first use AI to
            eliminate the Check(DoubleRealRep:) based on the input being a GetByVal(InBounds) but then replace that
            with a GetByVal(SaneChain), then we will hit the assertion.

            This teaches CSE to not replace GetByVal(InBounds) with GetByVal(SaneChain) and vice versa. That gets
            tricky because PutByVal can match either. So, we use the fact that it's legal for a store to def() more
            than once: PutByVal now defs() a HeapLocation for InBounds and a HeapLocation for SaneChain.

            * dfg/DFGCSEPhase.cpp:
            * dfg/DFGClobberize.h:
            (JSC::DFG::clobberize):
            * dfg/DFGHeapLocation.cpp:
            (WTF::printInternal):
            * dfg/DFGHeapLocation.h:
            * dfg/DFGSpeculativeJIT.cpp:
            (JSC::DFG::SpeculativeJIT::compileArrayPush):

2018-04-03  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r229987. rdar://problem/39155464

    DFG should know that CreateThis can be effectful
    https://bugs.webkit.org/show_bug.cgi?id=184013
    
    Reviewed by Saam Barati.
    
    JSTests:
    
    * stress/create-this-property-change.js: Added.
    (Foo):
    (RealBar):
    (get if):
    * stress/create-this-structure-change-without-cse.js: Added.
    (Foo):
    (RealBar):
    (get if):
    * stress/create-this-structure-change.js: Added.
    (Foo):
    (RealBar):
    (get if):
    
    Source/JavaScriptCore:
    
    As shown in the tests added in JSTests, CreateThis can be effectful if the constructor this
    is a proxy.
    
    * dfg/DFGAbstractInterpreterInlines.h:
    (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
    * dfg/DFGClobberize.h:
    (JSC::DFG::clobberize):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@229987 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2018-03-26  Filip Pizlo  <fpizlo@apple.com>

            DFG should know that CreateThis can be effectful
            https://bugs.webkit.org/show_bug.cgi?id=184013

            Reviewed by Saam Barati.

            As shown in the tests added in JSTests, CreateThis can be effectful if the constructor this
            is a proxy.

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

2018-04-03  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r230143. rdar://problem/39155381

    JSC crash in JIT code with for-of loop and Array/Set iterators
    https://bugs.webkit.org/show_bug.cgi?id=183174
    
    Reviewed by Saam Barati.
    
    JSTests:
    
    * microbenchmarks/hoist-get-by-offset-tower-with-inferred-types.js: Added. This test shows that fixing the bug didn't break hoisting of GetByOffset with inferred types. I confirmed that if I did break it, this test slows down by >7x.
    (foo):
    * stress/hoist-get-by-offset-with-control-dependent-inferred-type.js: Added. This test shows that the bug is fixed.
    (f):
    
    Source/JavaScriptCore:
    
    * dfg/DFGSafeToExecute.h:
    (JSC::DFG::safeToExecute): Fix the bug by making GetByOffset and friends verify that they are getting the type proof they want at the desired hoisting site.
    
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230143 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2018-03-31  Filip Pizlo  <fpizlo@apple.com>

            JSC crash in JIT code with for-of loop and Array/Set iterators
            https://bugs.webkit.org/show_bug.cgi?id=183174

            Reviewed by Saam Barati.

            * dfg/DFGSafeToExecute.h:
            (JSC::DFG::safeToExecute): Fix the bug by making GetByOffset and friends verify that they are getting the type proof they want at the desired hoisting site.

2018-04-03  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r230119. rdar://problem/39155070

    WebAssembly compilation from DataView
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230119 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2018-03-30  JF Bastien  <jfbastien@apple.com>

            WebAssembly: support DataView compilation
            https://bugs.webkit.org/show_bug.cgi?id=183342

            Reviewed by Mark Lam.

            Compiling a module from a DataView was incorrectly dealing with
            DataView's offset.

            * wasm/WasmModuleParser.cpp:
            (JSC::Wasm::ModuleParser::parse):
            * wasm/js/JSWebAssemblyHelpers.h:
            (JSC::getWasmBufferFromValue):
            (JSC::createSourceBufferFromValue):
            * wasm/js/WebAssemblyPrototype.cpp:
            (JSC::webAssemblyValidateFunc):

2018-04-03  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r230102. rdar://problem/38154594

    A stack overflow in the parsing of a builtin (called by createExecutable) cause a crash instead of a catchable js exception
    https://bugs.webkit.org/show_bug.cgi?id=184074
    <rdar://problem/37165897>
    
    Reviewed by Keith Miller.
    
    JSTests:
    
    * stress/stack-overflow-while-parsing-builtin.js: Added.
    (f):
    
    Source/JavaScriptCore:
    
    Fixing this requires getting the ParserError (with information about the failure) and an ExecState* (to throw an exception) in the same place.
    It is surprisingly painful, with quite a long call stack between the last function with an access to an ExecState* and the first function with the ParserError.
    Even worse, many of these functions are generated by macros, themselves generated by a maze of python scripts.
    As a result, this patch is grotesquely large, while all it does is adding enough plumbing to throw a proper exception in this specific case.
    
    There are now bare calls to '.value()' on several paths that may crash. It is not a problem in my opinion, since we previously crashed in every case regardless of the path that took us to createExecutable when encountering a stack overflow.
    If we ever find an example that can cause these calls to fail, it should be doable to throw a proper exception there too.
    
    Two other minor changes:
    - I removed BuiltinExecutableCreator.{cpp, h} as it was nearly empty, and only used in one place. That place now includes BuiltinExecutables.h directly instead.
    - I moved code from ParserError.h into a newly created ParserError.cpp, as I see no need to inline functions that are only used when encountering a parser error, and ParserError.h is now included in quite a few places.
    
    * JavaScriptCore.xcodeproj/project.pbxproj:
    * Scripts/builtins/builtins_generate_combined_header.py:
    (BuiltinsCombinedHeaderGenerator.generate_forward_declarations):
    (ParserError):
    (generate_section_for_object): Deleted.
    (generate_externs_for_object): Deleted.
    (generate_macros_for_object): Deleted.
    (generate_section_for_code_table_macro): Deleted.
    (generate_section_for_code_name_macro): Deleted.
    (generate_section_for_global_private_code_name_macro): Deleted.
    * Scripts/builtins/builtins_generate_separate_header.py:
    (generate_secondary_header_includes):
    * Scripts/builtins/builtins_templates.py:
    * Sources.txt:
    * builtins/BuiltinExecutableCreator.cpp: Removed.
    * builtins/BuiltinExecutableCreator.h: Removed.
    * builtins/BuiltinExecutables.cpp:
    (JSC::BuiltinExecutables::createDefaultConstructor):
    (JSC::BuiltinExecutables::createBuiltinExecutable):
    (JSC::createBuiltinExecutable):
    (JSC::BuiltinExecutables::createExecutableOrCrash):
    (JSC::BuiltinExecutables::createExecutable):
    * builtins/BuiltinExecutables.h:
    * bytecompiler/BytecodeGenerator.h:
    * parser/ParserError.cpp: Added.
    (JSC::ParserError::toErrorObject):
    (JSC::ParserError::throwStackOverflowOrOutOfMemory):
    (WTF::printInternal):
    * parser/ParserError.h:
    (JSC::ParserError::toErrorObject): Deleted.
    (WTF::printInternal): Deleted.
    * runtime/AsyncIteratorPrototype.cpp:
    (JSC::AsyncIteratorPrototype::finishCreation):
    * runtime/FunctionPrototype.cpp:
    (JSC::FunctionPrototype::addFunctionProperties):
    * runtime/JSGlobalObject.cpp:
    (JSC::JSGlobalObject::init):
    * runtime/JSObject.cpp:
    (JSC::JSObject::getOwnStaticPropertySlot):
    (JSC::JSObject::reifyAllStaticProperties):
    * runtime/JSObject.h:
    (JSC::JSObject::getOwnNonIndexPropertySlot):
    (JSC::JSObject::getOwnPropertySlot):
    (JSC::JSObject::getPropertySlot):
    * runtime/JSObjectInlines.h:
    (JSC::JSObject::getNonIndexPropertySlot):
    * runtime/JSTypedArrayViewPrototype.cpp:
    (JSC::JSTypedArrayViewPrototype::finishCreation):
    * runtime/Lookup.cpp:
    (JSC::reifyStaticAccessor):
    (JSC::setUpStaticFunctionSlot):
    * runtime/Lookup.h:
    (JSC::getStaticPropertySlotFromTable):
    (JSC::reifyStaticProperty):
    * runtime/MapPrototype.cpp:
    (JSC::MapPrototype::finishCreation):
    * runtime/SetPrototype.cpp:
    (JSC::SetPrototype::finishCreation):
    * tools/JSDollarVM.cpp:
    (JSC::functionCreateBuiltin):
    
    Source/WebCore:
    
    I had to slightly change the type of some bindings between JSC and WebCore. No functional change intended on the WebCore side.
    
    * bindings/js/JSReadableStreamPrivateConstructors.cpp:
    (WebCore::JSBuiltinReadableStreamDefaultReaderPrivateConstructor::initializeExecutable):
    (WebCore::JSBuiltinReadableStreamDefaultControllerPrivateConstructor::initializeExecutable):
    (WebCore::JSBuiltinReadableByteStreamControllerPrivateConstructor::initializeExecutable):
    (WebCore::JSBuiltinReadableStreamBYOBReaderPrivateConstructor::initializeExecutable):
    (WebCore::JSBuiltinReadableStreamBYOBRequestPrivateConstructor::initializeExecutable):
    * bindings/scripts/CodeGeneratorJS.pm:
    (GenerateConstructorHelperMethods):
    * bindings/scripts/test/JS/JSTestClassWithJSBuiltinConstructor.cpp:
    (WebCore::JSTestClassWithJSBuiltinConstructorConstructor::initializeExecutable):
    * bindings/scripts/test/JS/JSTestJSBuiltinConstructor.cpp:
    (WebCore::JSTestJSBuiltinConstructorConstructor::initializeExecutable):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230102 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2018-03-30  Robin Morisset  <rmorisset@apple.com>

            A stack overflow in the parsing of a builtin (called by createExecutable) cause a crash instead of a catchable js exception
            https://bugs.webkit.org/show_bug.cgi?id=184074
            <rdar://problem/37165897>

            Reviewed by Keith Miller.

            Fixing this requires getting the ParserError (with information about the failure) and an ExecState* (to throw an exception) in the same place.
            It is surprisingly painful, with quite a long call stack between the last function with an access to an ExecState* and the first function with the ParserError.
            Even worse, many of these functions are generated by macros, themselves generated by a maze of python scripts.
            As a result, this patch is grotesquely large, while all it does is adding enough plumbing to throw a proper exception in this specific case.

            There are now bare calls to '.value()' on several paths that may crash. It is not a problem in my opinion, since we previously crashed in every case regardless of the path that took us to createExecutable when encountering a stack overflow.
            If we ever find an example that can cause these calls to fail, it should be doable to throw a proper exception there too.

            Two other minor changes:
            - I removed BuiltinExecutableCreator.{cpp, h} as it was nearly empty, and only used in one place. That place now includes BuiltinExecutables.h directly instead.
            - I moved code from ParserError.h into a newly created ParserError.cpp, as I see no need to inline functions that are only used when encountering a parser error, and ParserError.h is now included in quite a few places.

            * JavaScriptCore.xcodeproj/project.pbxproj:
            * Scripts/builtins/builtins_generate_combined_header.py:
            (BuiltinsCombinedHeaderGenerator.generate_forward_declarations):
            (ParserError):
            (generate_section_for_object): Deleted.
            (generate_externs_for_object): Deleted.
            (generate_macros_for_object): Deleted.
            (generate_section_for_code_table_macro): Deleted.
            (generate_section_for_code_name_macro): Deleted.
            (generate_section_for_global_private_code_name_macro): Deleted.
            * Scripts/builtins/builtins_generate_separate_header.py:
            (generate_secondary_header_includes):
            * Scripts/builtins/builtins_templates.py:
            * Sources.txt:
            * builtins/BuiltinExecutableCreator.cpp: Removed.
            * builtins/BuiltinExecutableCreator.h: Removed.
            * builtins/BuiltinExecutables.cpp:
            (JSC::BuiltinExecutables::createDefaultConstructor):
            (JSC::BuiltinExecutables::createBuiltinExecutable):
            (JSC::createBuiltinExecutable):
            (JSC::BuiltinExecutables::createExecutableOrCrash):
            (JSC::BuiltinExecutables::createExecutable):
            * builtins/BuiltinExecutables.h:
            * bytecompiler/BytecodeGenerator.h:
            * parser/ParserError.cpp: Added.
            (JSC::ParserError::toErrorObject):
            (JSC::ParserError::throwStackOverflowOrOutOfMemory):
            (WTF::printInternal):
            * parser/ParserError.h:
            (JSC::ParserError::toErrorObject): Deleted.
            (WTF::printInternal): Deleted.
            * runtime/AsyncIteratorPrototype.cpp:
            (JSC::AsyncIteratorPrototype::finishCreation):
            * runtime/FunctionPrototype.cpp:
            (JSC::FunctionPrototype::addFunctionProperties):
            * runtime/JSGlobalObject.cpp:
            (JSC::JSGlobalObject::init):
            * runtime/JSObject.cpp:
            (JSC::JSObject::getOwnStaticPropertySlot):
            (JSC::JSObject::reifyAllStaticProperties):
            * runtime/JSObject.h:
            (JSC::JSObject::getOwnNonIndexPropertySlot):
            (JSC::JSObject::getOwnPropertySlot):
            (JSC::JSObject::getPropertySlot):
            * runtime/JSObjectInlines.h:
            (JSC::JSObject::getNonIndexPropertySlot):
            * runtime/JSTypedArrayViewPrototype.cpp:
            (JSC::JSTypedArrayViewPrototype::finishCreation):
            * runtime/Lookup.cpp:
            (JSC::reifyStaticAccessor):
            (JSC::setUpStaticFunctionSlot):
            * runtime/Lookup.h:
            (JSC::getStaticPropertySlotFromTable):
            (JSC::reifyStaticProperty):
            * runtime/MapPrototype.cpp:
            (JSC::MapPrototype::finishCreation):
            * runtime/SetPrototype.cpp:
            (JSC::SetPrototype::finishCreation):
            * tools/JSDollarVM.cpp:
            (JSC::functionCreateBuiltin):

2018-04-03  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r230101. rdar://problem/39155394

    Out-of-bounds accesses due to a missing check for MAX_STORAGE_VECTOR_LENGTH in unshiftCountForAnyIndexingType
    https://bugs.webkit.org/show_bug.cgi?id=183657
    JSTests:
    
    Reviewed by Keith Miller.
    
    * stress/large-unshift-splice.js: Added.
    (make_contig_arr):
    
    Source/JavaScriptCore:
    
    <rdar://problem/38464399>
    
    Reviewed by Keith Miller.
    
    There was just a missing check in unshiftCountForIndexingType.
    I've also replaced 'return false' by 'return true' in the case of an 'out-of-memory' exception, because 'return false' means 'please continue to the slow path',
    and the slow path has an assert that there is no unhandled exception (line 360 of ArrayPrototype.cpp).
    Finally, I made the assert in ensureLength a release assert as it would have caught this bug and prevented it from being a security risk.
    
    * runtime/ArrayPrototype.cpp:
    (JSC::unshift):
    * runtime/JSArray.cpp:
    (JSC::JSArray::unshiftCountWithAnyIndexingType):
    * runtime/JSObject.h:
    (JSC::JSObject::ensureLength):
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230101 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2018-03-30  Robin Morisset  <rmorisset@apple.com>

            Out-of-bounds accesses due to a missing check for MAX_STORAGE_VECTOR_LENGTH in unshiftCountForAnyIndexingType
            https://bugs.webkit.org/show_bug.cgi?id=183657
            <rdar://problem/38464399>

            Reviewed by Keith Miller.

            There was just a missing check in unshiftCountForIndexingType.
            I've also replaced 'return false' by 'return true' in the case of an 'out-of-memory' exception, because 'return false' means 'please continue to the slow path',
            and the slow path has an assert that there is no unhandled exception (line 360 of ArrayPrototype.cpp).
            Finally, I made the assert in ensureLength a release assert as it would have caught this bug and prevented it from being a security risk.

            * runtime/ArrayPrototype.cpp:
            (JSC::unshift):
            * runtime/JSArray.cpp:
            (JSC::JSArray::unshiftCountWithAnyIndexingType):
            * runtime/JSObject.h:
            (JSC::JSObject::ensureLength):

2018-04-03  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r230026. rdar://problem/39155085

    appendQuotedJSONString stops on arithmetic overflow instead of propagating it upwards
    https://bugs.webkit.org/show_bug.cgi?id=183894
    
    Reviewed by Saam Barati.
    
    JSTests:
    
    * stress/json-stringified-overflow.js: Added.
    (catch):
    
    Source/JavaScriptCore:
    
    Use the return value of appendQuotedJSONString to fail more gracefully when given a string that is too large to handle.
    
    * runtime/JSONObject.cpp:
    (JSC::Stringifier::appendStringifiedValue):
    
    Source/WTF:
    
    appendQuotedJSONString now returns a bool indicating whether it succeeded, instead of silently failing when given a string too large
    to fit in 4GB.
    
    * wtf/text/StringBuilder.h:
    * wtf/text/StringBuilderJSON.cpp:
    (WTF::StringBuilder::appendQuotedJSONString):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230026 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2018-03-28  Robin Morisset  <rmorisset@apple.com>

            appendQuotedJSONString stops on arithmetic overflow instead of propagating it upwards
            https://bugs.webkit.org/show_bug.cgi?id=183894

            Reviewed by Saam Barati.

            Use the return value of appendQuotedJSONString to fail more gracefully when given a string that is too large to handle.

            * runtime/JSONObject.cpp:
            (JSC::Stringifier::appendStringifiedValue):

2018-04-03  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r229962. rdar://problem/39122091

    r228149 accidentally removed code that resets m_emptyCursor at the end of a GC
    https://bugs.webkit.org/show_bug.cgi?id=183995
    
    Reviewed by Filip Pizlo.
    
    The removal of this line of code was unintended and happened during some
    refactoring Fil was doing. The consequence of removing this line of code
    is that the m_emptyCursor became a monotonically increasing integer, leading
    the cursor to usually being out of bounds of the block range (depending on
    what the program is doing). This made the functionality of finding an empty
    block to steal almost always fail.
    
    * heap/BlockDirectory.cpp:
    (JSC::BlockDirectory::prepareForAllocation):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@229962 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2018-03-25  Saam Barati  <sbarati@apple.com>

            r228149 accidentally removed code that resets m_emptyCursor at the end of a GC
            https://bugs.webkit.org/show_bug.cgi?id=183995

            Reviewed by Filip Pizlo.

            The removal of this line of code was unintended and happened during some
            refactoring Fil was doing. The consequence of removing this line of code
            is that the m_emptyCursor became a monotonically increasing integer, leading
            the cursor to usually being out of bounds of the block range (depending on
            what the program is doing). This made the functionality of finding an empty
            block to steal almost always fail.

            * heap/BlockDirectory.cpp:
            (JSC::BlockDirectory::prepareForAllocation):

2018-04-03  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r229850. rdar://problem/39155286

    Race Condition in arrayProtoFuncReverse() causes wrong results or crash
    https://bugs.webkit.org/show_bug.cgi?id=183901
    
    Reviewed by Keith Miller.
    
    JSTests:
    
    New test.
    
    * stress/array-reverse-doesnt-clobber.js: Added.
    (testArrayReverse):
    (createArrayOfArrays):
    (createArrayStorage):
    
    Source/JavaScriptCore:
    
    Added write barriers to ensure the reversed contents are properly marked.
    
    * runtime/ArrayPrototype.cpp:
    (JSC::arrayProtoFuncReverse):
    
    
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@229850 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    2018-03-22  Michael Saboff  <msaboff@apple.com>

            Race Condition in arrayProtoFuncReverse() causes wrong results or crash
            https://bugs.webkit.org/show_bug.cgi?id=183901

            Reviewed by Keith Miller.

            Added write barriers to ensure the reversed contents are properly marked.

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

2018-03-20  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r229366. rdar://problem/38651632

    2018-03-06  Filip Pizlo  <fpizlo@apple.com>

            MarkedArgumentsBuffer should allocate from the JSValue Gigacage
            https://bugs.webkit.org/show_bug.cgi?id=183377

            Reviewed by Michael Saboff.

            That prevents it from being used to pivot UAF on malloc memory into corruption in the JS heap.

            * runtime/ArgList.cpp:
            (JSC::MarkedArgumentBuffer::expandCapacity):

2018-03-20  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r229109. rdar://problem/38651610

    2018-02-28  JF Bastien  <jfbastien@apple.com>

            GC should sweep code block before deleting
            https://bugs.webkit.org/show_bug.cgi?id=183229
            <rdar://problem/32767615>

            Reviewed by Saam Barati, Fil Pizlo.

            Stub routines shouldn't get deleted before codeblocks have been
            swept, otherwise there's a small race window where the codeblock
            thinks it's still reachable.

            * heap/Heap.cpp:
            (JSC::Heap::deleteUnmarkedCompiledCode):
            (JSC::Heap::sweepInFinalize):

2018-02-21  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r228860. rdar://problem/37751729

    2018-02-20  Saam Barati  <sbarati@apple.com>

            DFG::VarargsForwardingPhase should eliminate getting argument length
            https://bugs.webkit.org/show_bug.cgi?id=182959

            Reviewed by Keith Miller.

            This patch teaches the DFG VarargsForwardingPhase to not treat
            length accesses on Cloned/Direct Arguments objects as escapes.
            It teaches this phase to materialize the length in the same
            way the ArgumentsEliminationPhase does.

            This is around a 0.5-1% speedup on ARES6 on my iMac. It speeds
            up the ML subtest by 2-4%.

            This patch also extends compileGetArgumentCountIncludingThis to take
            a parameter that is the inline call frame to load from (in the case
            where the inline call frame is a varargs frame). This allows the
            the emitCodeToGetArgumentsArrayLength helper function to just emit
            a GetArgumentCountIncludingThis node instead of a GetLocal. If we
            emitted a GetLocal, we'd need to rerun CPS rethreading.

            * dfg/DFGArgumentsEliminationPhase.cpp:
            * dfg/DFGArgumentsUtilities.cpp:
            (JSC::DFG::emitCodeToGetArgumentsArrayLength):
            * dfg/DFGByteCodeParser.cpp:
            (JSC::DFG::ByteCodeParser::getArgumentCount):
            * dfg/DFGClobberize.h:
            (JSC::DFG::clobberize):
            * dfg/DFGNode.h:
            (JSC::DFG::Node::argumentsInlineCallFrame):
            * dfg/DFGSpeculativeJIT.cpp:
            (JSC::DFG::SpeculativeJIT::compileGetArgumentCountIncludingThis):
            * dfg/DFGVarargsForwardingPhase.cpp:
            * ftl/FTLLowerDFGToB3.cpp:
            (JSC::FTL::DFG::LowerDFGToB3::compileGetArgumentCountIncludingThis):

2018-02-20  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r228725. rdar://problem/37714027

    2018-02-19  Saam Barati  <sbarati@apple.com>

            Don't use JSFunction's allocation profile when getting the prototype can be effectful
            https://bugs.webkit.org/show_bug.cgi?id=182942
            <rdar://problem/37584764>

            Reviewed by Mark Lam.

            Prior to this patch, the create_this implementation assumed that anything
            that is a JSFunction can use the object allocation profile and go down the
            fast path to allocate the |this| object. Implied by this approach is that
            accessing the 'prototype' property of the incoming function is not an
            effectful operation. This is inherent to the ObjectAllocationProfile
            data structure: it caches the prototype field. However, getting the
            'prototype' property might be an effectful operation, e.g, it could
            be a getter. Many variants of functions in JS have the 'prototype' property
            as non-configurable. However, some functions, like bound functions, do not
            have the 'prototype' field with these attributes.

            This patch adds the notion of 'canUseAllocationProfile' to JSFunction
            and threads it through so that we only go down the fast path and use
            the allocation profile when the prototype property is non-configurable.

            * bytecompiler/NodesCodegen.cpp:
            (JSC::ClassExprNode::emitBytecode):
            * dfg/DFGOperations.cpp:
            * runtime/CommonSlowPaths.cpp:
            (JSC::SLOW_PATH_DECL):
            * runtime/JSFunction.cpp:
            (JSC::JSFunction::prototypeForConstruction):
            (JSC::JSFunction::allocateAndInitializeRareData):
            (JSC::JSFunction::initializeRareData):
            (JSC::JSFunction::getOwnPropertySlot):
            (JSC::JSFunction::canUseAllocationProfileNonInline):
            * runtime/JSFunction.h:
            (JSC::JSFunction::ensureRareDataAndAllocationProfile):
            * runtime/JSFunctionInlines.h:
            (JSC::JSFunction::canUseAllocationProfile):

2018-02-20  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r228720. rdar://problem/37714022

    2018-02-19  Saam Barati  <sbarati@apple.com>

            Don't mark an array profile out of bounds for the cases where the DFG will convert the access to SaneChain
            https://bugs.webkit.org/show_bug.cgi?id=182912
            <rdar://problem/37685083>

            Reviewed by Keith Miller.

            In the baseline JIT and LLInt, when we loading a hole from an original array,
            with the array prototype chain being normal, we end up marking the ArrayProfile
            for that GetByVal as out of bounds. However, the DFG knows exactly how to
            optimize this case by returning undefined when loading from a hole. Currently,
            it only does this for Contiguous arrays (and sometimes Double arrays).
            This patch just makes sure to not mark the ArrayProfile as out of bounds
            in this scenario for Contiguous arrays, since the DFG will always optimize
            this case.

            However, we should extend this by profiling when a GetByVal loads a hole. By
            doing so, we can optimize this for Int32, ArrayStorage, and maybe even Double
            arrays. That work will happen in:
            https://bugs.webkit.org/show_bug.cgi?id=182940

            This patch is a 30-50%  speedup on JetStream's hash-map test. This patch
            speeds up JetStream by 1% when testing on my iMac.

            * dfg/DFGArrayMode.cpp:
            (JSC::DFG::ArrayMode::refine const):
            * dfg/DFGFixupPhase.cpp:
            (JSC::DFG::FixupPhase::fixupNode):
            * jit/JITOperations.cpp:
            (JSC::getByVal):
            (JSC::canAccessArgumentIndexQuickly): Deleted.
            * llint/LLIntSlowPaths.cpp:
            (JSC::LLInt::getByVal):
            (JSC::LLInt::LLINT_SLOW_PATH_DECL):
            * llint/LowLevelInterpreter32_64.asm:
            * llint/LowLevelInterpreter64.asm:
            * runtime/CommonSlowPaths.h:
            (JSC::CommonSlowPaths::canAccessArgumentIndexQuickly):

2018-02-20  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r228693. rdar://problem/37697679

    2018-02-17  Filip Pizlo  <fpizlo@apple.com>

            GetArrayMask should support constant folding
            https://bugs.webkit.org/show_bug.cgi?id=182907

            Reviewed by Saam Barati.

            Implement constant folding for GetArrayMask. This revealed a bug in tryGetFoldableView, where it was
            ignoring the result of a jsDynamicCast<>(). This wasn't a bug before because it would have been
            impossible for that function to get called with a non-null value if the value was not an array view,
            due to type filtering in CheckArray, the fact that CheckArray had to dominate GetArrayLength, and
            the fact that the other tryGetFoldableView overload made sure that the array mode was some typed
            array.

            This isn't a measurable progression, but it does save a register in the codegen for typed array
            accesses. Hopefully these improvements add up.

            * assembler/AssemblerBuffer.h:
            * dfg/DFGAbstractInterpreterInlines.h:
            (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
            * dfg/DFGGraph.cpp:
            (JSC::DFG::Graph::tryGetFoldableView):

2018-02-20  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r228565. rdar://problem/37697682

    2018-02-16  Saam Barati  <sbarati@apple.com>

            Fix bugs from r228411
            https://bugs.webkit.org/show_bug.cgi?id=182851
            <rdar://problem/37577732>

            Reviewed by JF Bastien.

            There was a bug from r228411 where inside the constant folding phase,
            we used an insertCheck method that didn't handle varargs. This would
            lead to a crash. When thinking about the fix for that function, I realized
            a made a couple of mistakes in r228411. One is probably a security bug, and
            the other is a performance bug because it'll prevent CSE for certain flavors
            of GetByVal nodes. Both blunders are similar in nature.

            In r228411, I added code in LICM that inserted a CheckVarargs node with children
            of another varargs node. However, to construct this new node's children,
            I just copied the AdjacencyList. This does a shallow copy. What we needed
            was a deep copy. We needed to create a new vararg AdjacencyList that points
            to edges that are deep copies of the original varargs children. This patch
            fixes this goof in LICM.

            r228411 made it so that PureValue over a varargs node would just compare actual
            AdjacencyLists structs. So, if you had two GetByVals that had equal santized
            children, their actual AdjacencyList structs are *not* bitwise equal, since they'll
            have different firstChild values. Instead, we need to do a deep compare of their
            adjacency lists. This patch teaches PureValue how to do that.

            * dfg/DFGClobberize.h:
            (JSC::DFG::clobberize):
            * dfg/DFGConstantFoldingPhase.cpp:
            (JSC::DFG::ConstantFoldingPhase::foldConstants):
            * dfg/DFGGraph.h:
            (JSC::DFG::Graph::copyVarargChildren):
            * dfg/DFGInsertionSet.h:
            (JSC::DFG::InsertionSet::insertCheck):
            * dfg/DFGLICMPhase.cpp:
            (JSC::DFG::LICMPhase::attemptHoist):
            * dfg/DFGPureValue.cpp:
            (JSC::DFG::PureValue::dump const):
            * dfg/DFGPureValue.h:
            (JSC::DFG::PureValue::PureValue):
            (JSC::DFG::PureValue::op const):
            (JSC::DFG::PureValue::hash const):
            (JSC::DFG::PureValue::operator== const):
            (JSC::DFG::PureValue::isVarargs const):
            (JSC::DFG::PureValue::children const): Deleted.
            * dfg/DFGStrengthReductionPhase.cpp:
            (JSC::DFG::StrengthReductionPhase::handleNode):
            (JSC::DFG::StrengthReductionPhase::convertToIdentityOverChild):

2018-02-16  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r228454. rdar://problem/37615380

    2018-02-13  Saam Barati  <sbarati@apple.com>

            putDirectIndexSlowOrBeyondVectorLength needs to convert to dictionary indexing mode always if attributes are present
            https://bugs.webkit.org/show_bug.cgi?id=182755
            <rdar://problem/37080864>

            Reviewed by Keith Miller.

            putDirectIndexSlowOrBeyondVectorLength with non-zero attributes only converted
            the object in question to a dictionary indexing mode when the index is less than
            the vector length. This makes no sense. If we're defining a getter, setter, or read
            only property, we must always enter the dictionary indexing mode irrespective
            of the index in relation to the vector length.

            * runtime/JSObject.cpp:
            (JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength):

2018-02-15  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r228481. rdar://problem/37570863

    2018-02-14  Michael Saboff  <msaboff@apple.com>

            REGRESSION(225695) : com.apple.WebKit.WebContent at com.apple.JavaScriptCore: JSC::RegExp::match + 630 :: stack overflow
            https://bugs.webkit.org/show_bug.cgi?id=182705

            Reviewed by Mark Lam.

            Moved the pattern context buffer used by YARR JIT'ed code from a stack local to a lazily allocated
            buffer on the VM.  Exposed when the buffer is needed to reduce likelihood that we'd allocated it.
            Guarded use of the buffer with a lock since the DFG compiler may call into YARR JIT'ed code on a
            compilation thread.

            * runtime/RegExpInlines.h:
            (JSC::RegExp::matchInline):
            * runtime/VM.cpp:
            (JSC::VM::~VM):
            (JSC::VM::acquireRegExpPatternContexBuffer):
            (JSC::VM::releaseRegExpPatternContexBuffer):
            * runtime/VM.h:
            * yarr/YarrJIT.cpp:
            (JSC::Yarr::YarrGenerator::generate):
            (JSC::Yarr::YarrGenerator::backtrack):
            (JSC::Yarr::YarrGenerator::opCompileParenthesesSubpattern):
            (JSC::Yarr::YarrGenerator::generateEnter):
            (JSC::Yarr::YarrGenerator::generateReturn):
            (JSC::Yarr::YarrGenerator::YarrGenerator):
            (JSC::Yarr::YarrGenerator::compile):
            * yarr/YarrJIT.h:
            (JSC::Yarr::YarrCodeBlock::usesPatternContextBuffer):
            (JSC::Yarr::YarrCodeBlock::setUsesPaternContextBuffer):

2018-02-15  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r228488. rdar://problem/37570860

    2018-02-14  Saam Barati  <sbarati@apple.com>

            Setting a VMTrap shouldn't look at topCallFrame since that may imply we're in C code and holding the malloc lock
            https://bugs.webkit.org/show_bug.cgi?id=182801

            Reviewed by Keith Miller.

            VMTraps would sometimes install traps when it paused the JS thread when it
            was in C code. This is wrong, as installing traps mallocs, and the JS thread
            may have been holding the malloc lock while in C code. This could lead to a
            deadlock when C code was holding the malloc lock.

            This patch makes it so that we only install traps when we've proven the PC
            is in JIT or LLInt code. If we're in JIT/LLInt code, we are guaranteed that
            we're not holding the malloc lock.

            * jsc.cpp:
            (GlobalObject::finishCreation):
            (functionMallocInALoop):
            * runtime/VMTraps.cpp:
            (JSC::VMTraps::tryInstallTrapBreakpoints):

2018-02-13  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r228420. rdar://problem/37521084

    2018-02-10  Filip Pizlo  <fpizlo@apple.com>

            Lock down JSFunction
            https://bugs.webkit.org/show_bug.cgi?id=182652

            Reviewed by Saam Barati.

            This poisons pointers in JSFunction and puts all of the types in the JSFunction hierarchy in
            isospaces.

            This is so neutral on JetStream: 0.01% slower with p = 0.969211.

            * dfg/DFGSpeculativeJIT.cpp:
            (JSC::DFG::SpeculativeJIT::compileNewFunctionCommon):
            (JSC::DFG::SpeculativeJIT::compileNewFunction):
            (JSC::DFG::SpeculativeJIT::compileCreateThis):
            * dfg/DFGSpeculativeJIT.h:
            (JSC::DFG::SpeculativeJIT::TrustedImmPtr::TrustedImmPtr):
            (JSC::DFG::SpeculativeJIT::TrustedImmPtr::weakPointer):
            (JSC::DFG::SpeculativeJIT::TrustedImmPtr::weakPoisonedPointer):
            * dfg/DFGSpeculativeJIT64.cpp:
            (JSC::DFG::SpeculativeJIT::compile):
            * ftl/FTLLowerDFGToB3.cpp:
            (JSC::FTL::DFG::LowerDFGToB3::compileGetExecutable):
            (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
            (JSC::FTL::DFG::LowerDFGToB3::weakPointer):
            (JSC::FTL::DFG::LowerDFGToB3::weakPoisonedPointer):
            * ftl/FTLOutput.h:
            (JSC::FTL::Output::weakPointer):
            (JSC::FTL::Output::weakPoisonedPointer):
            * heap/MarkedSpace.cpp:
            * jit/JITOpcodes.cpp:
            (JSC::JIT::emit_op_create_this):
            * jit/ThunkGenerators.cpp:
            (JSC::virtualThunkFor):
            (JSC::nativeForGenerator):
            (JSC::boundThisNoArgsFunctionCallGenerator):
            * llint/LowLevelInterpreter.asm:
            * llint/LowLevelInterpreter64.asm:
            * runtime/JSAsyncFunction.h:
            (JSC::JSAsyncFunction::subspaceFor):
            * runtime/JSAsyncGeneratorFunction.h:
            (JSC::JSAsyncGeneratorFunction::subspaceFor):
            * runtime/JSBoundFunction.h:
            (JSC::JSBoundFunction::subspaceFor):
            * runtime/JSCPoison.h:
            * runtime/JSCustomGetterSetterFunction.h:
            (JSC::JSCustomGetterSetterFunction::subspaceFor):
            * runtime/JSFunction.h:
            (JSC::JSFunction::subspaceFor):
            * runtime/JSGeneratorFunction.h:
            (JSC::JSGeneratorFunction::subspaceFor):
            * runtime/JSNativeStdFunction.h:
            (JSC::JSNativeStdFunction::subspaceFor):
            * runtime/VM.cpp:
            (JSC::VM::VM):
            * runtime/VM.h:
            * wasm/js/WebAssemblyFunction.h:
            * wasm/js/WebAssemblyWrapperFunction.h:

2018-02-13  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r228438. rdar://problem/37521089

    2018-02-13  Saam Barati  <sbarati@apple.com>

            Follup fix to r228411 for 32-bit builds. I missed a place where we used non vararg getter for child2().

            * dfg/DFGSpeculativeJIT32_64.cpp:
            (JSC::DFG::SpeculativeJIT::compile):

2018-02-13  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r228411. rdar://problem/37521089

    2018-02-12  Saam Barati  <sbarati@apple.com>

            Add a GetIndexMask node and make it an input to GetByVal for array and typed array accesses in DFG SSA
            https://bugs.webkit.org/show_bug.cgi?id=182633
            <rdar://problem/37441037>

            Reviewed by Keith Miller.

            This patch introduces a GetIndexMask node to DFG SSA. This is an input to
            GetByVal for the GetByVal variants that do conservative index masking.
            The reason I'm adding this node is I realized there were loads of
            the butterfly index mask inside loops that B3 couldn't reason about
            because B3 can't arbitrarily hoist loads out of loops if those loops
            have side exits (because the side exit might be protecting the safety of the
            load). However, for these loops I analyzed, the DFG would be able to hoist
            these loads out of loops because it knows about JS semantics to correctly
            reason about the safety of hoisting the load.

            This is a 1% speedup on JetStream on Mac and iOS in my testing.

            This patch also adds some infrastructure for eliminating and doing CSE on
            varargs nodes. Because this patch makes GetByVal a varargs node, I ran into
            issues we never had before. We never had a varargs node that could be CSEd or be
            hoisted out of a loop until I made GetByVal varargs. To make it all work,
            I added a CheckVarargs node. This is just like Check, but it's varargs.

            * dfg/DFGAbstractInterpreterInlines.h:
            (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
            * dfg/DFGAdjacencyList.h:
            (JSC::DFG::AdjacencyList::AdjacencyList):
            * dfg/DFGArgumentsEliminationPhase.cpp:
            * dfg/DFGBackwardsPropagationPhase.cpp:
            (JSC::DFG::BackwardsPropagationPhase::propagate):
            * dfg/DFGBasicBlock.cpp:
            (JSC::DFG::BasicBlock::replaceTerminal):
            * dfg/DFGBasicBlock.h:
            (JSC::DFG::BasicBlock::findTerminal const):
            * dfg/DFGBasicBlockInlines.h:
            (JSC::DFG::BasicBlock::replaceTerminal):
            * dfg/DFGByteCodeParser.cpp:
            (JSC::DFG::ByteCodeParser::parseBlock):
            * dfg/DFGCFGSimplificationPhase.cpp:
            (JSC::DFG::CFGSimplificationPhase::mergeBlocks):
            * dfg/DFGCPSRethreadingPhase.cpp:
            (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
            (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
            * dfg/DFGCSEPhase.cpp:
            * dfg/DFGCleanUpPhase.cpp:
            (JSC::DFG::CleanUpPhase::run):
            * dfg/DFGClobberize.h:
            (JSC::DFG::clobberize):
            * dfg/DFGConstantFoldingPhase.cpp:
            (JSC::DFG::ConstantFoldingPhase::foldConstants):
            (JSC::DFG::ConstantFoldingPhase::fixUpsilons):
            * dfg/DFGDCEPhase.cpp:
            (JSC::DFG::DCEPhase::run):
            (JSC::DFG::DCEPhase::fixupBlock):
            * dfg/DFGDoesGC.cpp:
            (JSC::DFG::doesGC):
            * dfg/DFGFixupPhase.cpp:
            (JSC::DFG::FixupPhase::fixupNode):
            (JSC::DFG::FixupPhase::fixupChecksInBlock):
            * dfg/DFGHeapLocation.cpp:
            (WTF::printInternal):
            * dfg/DFGHeapLocation.h:
            * dfg/DFGIntegerCheckCombiningPhase.cpp:
            (JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
            * dfg/DFGIntegerRangeOptimizationPhase.cpp:
            * dfg/DFGLICMPhase.cpp:
            (JSC::DFG::LICMPhase::attemptHoist):
            * dfg/DFGMayExit.cpp:
            * dfg/DFGNode.cpp:
            (JSC::DFG::Node::remove):
            (JSC::DFG::Node::convertToIdentityOn):
            * dfg/DFGNode.h:
            (JSC::DFG::Node::replaceWith):
            * dfg/DFGNodeType.h:
            * dfg/DFGObjectAllocationSinkingPhase.cpp:
            * dfg/DFGPredictionPropagationPhase.cpp:
            * dfg/DFGPureValue.cpp:
            (JSC::DFG::PureValue::dump const):
            * dfg/DFGPureValue.h:
            (JSC::DFG::PureValue::PureValue):
            * dfg/DFGPutStackSinkingPhase.cpp:
            * dfg/DFGSSAConversionPhase.cpp:
            (JSC::DFG::SSAConversionPhase::run):
            * dfg/DFGSSALoweringPhase.cpp:
            (JSC::DFG::SSALoweringPhase::handleNode):
            * dfg/DFGSafeToExecute.h:
            (JSC::DFG::safeToExecute):
            * dfg/DFGSpeculativeJIT.cpp:
            (JSC::DFG::SpeculativeJIT::SpeculativeJIT):
            (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
            (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
            (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray):
            (JSC::DFG::SpeculativeJIT::compileGetByValForObjectWithString):
            (JSC::DFG::SpeculativeJIT::compileGetByValForObjectWithSymbol):
            (JSC::DFG::SpeculativeJIT::compileGetByValOnDirectArguments):
            (JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
            * dfg/DFGSpeculativeJIT.h:
            * dfg/DFGSpeculativeJIT32_64.cpp:
            (JSC::DFG::SpeculativeJIT::compile):
            * dfg/DFGSpeculativeJIT64.cpp:
            (JSC::DFG::SpeculativeJIT::compile):
            * dfg/DFGStoreBarrierClusteringPhase.cpp:
            * dfg/DFGValidate.cpp:
            * dfg/DFGVarargsForwardingPhase.cpp:
            * ftl/FTLCapabilities.cpp:
            (JSC::FTL::canCompile):
            * ftl/FTLLowerDFGToB3.cpp:
            (JSC::FTL::DFG::LowerDFGToB3::compileNode):
            (JSC::FTL::DFG::LowerDFGToB3::compileGetArrayMask):
            (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
            (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
            (JSC::FTL::DFG::LowerDFGToB3::maskedIndex):
            (JSC::FTL::DFG::LowerDFGToB3::pointerIntoTypedArray):

2018-02-13  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r228401. rdar://problem/37521078

    2018-02-12  Saam Barati  <sbarati@apple.com>

            DFG::emitCodeToGetArgumentsArrayLength needs to handle NewArrayBuffer/PhantomNewArrayBuffer
            https://bugs.webkit.org/show_bug.cgi?id=182706
            <rdar://problem/36833681>

            Reviewed by Filip Pizlo.

            When we added support for PhantomNewArrayBuffer, we forgot to update
            the emitCodeToGetArgumentsArrayLength function to handle PhantomNewArrayBuffer.
            This patch adds that support. It's trivial to generate the length for
            a PhantomNewArrayBuffer node since it's a constant buffer, with a constant
            length.

            * dfg/DFGArgumentsUtilities.cpp:
            (JSC::DFG::emitCodeToGetArgumentsArrayLength):

2018-02-06  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r228193. rdar://problem/37292950

    2018-02-06  Keith Miller  <keith_miller@apple.com>

            put_to_scope/get_from_scope should not cache lexical scopes when expecting a global object
            https://bugs.webkit.org/show_bug.cgi?id=182549
            <rdar://problem/36189995>

            Reviewed by Saam Barati.

            Previously, the llint/baseline caching for put_to_scope and
            get_from_scope would cache lexical environments when the
            varInjectionWatchpoint had been fired for global properties. Code
            in the DFG does not follow this same assumption so we could
            potentially return the wrong result. Additionally, the baseline
            would write barrier the global object rather than the lexical
            enviroment object. This patch makes it so that we do not cache
            anything other than the global object for when the resolve type is
            GlobalPropertyWithVarInjectionChecks or GlobalProperty.

            * assembler/MacroAssembler.cpp:
            (JSC::MacroAssembler::jitAssert):
            * assembler/MacroAssembler.h:
            * jit/JITPropertyAccess.cpp:
            (JSC::JIT::emit_op_get_from_scope):
            (JSC::JIT::emit_op_put_to_scope):
            * runtime/CommonSlowPaths.h:
            (JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
            (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
            * runtime/Options.h:

2018-02-06  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r228149. rdar://problem/37264543

    2018-01-28  Filip Pizlo  <fpizlo@apple.com>

            Global objects should be able to use TLCs to allocate from different blocks from each other
            https://bugs.webkit.org/show_bug.cgi?id=182227

            Reviewed by JF Bastien.

            This uses TLCs to create at least `minimumDistanceBetweenCellsFromDifferenOrigins` bytes of
            distance between objects from different origins, using the following combination of things. For
            short lets refer to that constant as K.

            - Since r227721, LargeAllocation puts K bytes padding at the end of each allocation.

            - Since r227718, MarkedBlock puts at least K bytes in its footer.

            - Since r227617, global objects can have their own TLCs, which make them allocate from a
              different set of blocks than other global objects. The TLC of a global object comes into
              effect when you enter the VM via that global object.

            - With this change, TLCs and blocks both have security origins. A TLC will only use blocks that
              share the same security origin or empty blocks (in which case we zero the block and change
              its security origin).

            WebCore determines the TLC-GlobalObject mapping. By default, global objects would simply use
            the VM's default TLC. WebCore makes it so that DOM windows (but not worker global objects) get
            a TLC based on their document's SecurityOrigin.

            * JavaScriptCore.xcodeproj/project.pbxproj:
            * Sources.txt:
            * heap/BlockDirectory.cpp:
            (JSC::BlockDirectory::findBlockForAllocation):
            (JSC::BlockDirectory::prepareForAllocation):
            * heap/BlockDirectory.h:
            * heap/LocalAllocator.cpp:
            (JSC::LocalAllocator::LocalAllocator):
            (JSC::LocalAllocator::reset):
            (JSC::LocalAllocator::~LocalAllocator):
            (JSC::LocalAllocator::allocateSlowCase):
            (JSC::LocalAllocator::tryAllocateWithoutCollecting):
            * heap/LocalAllocator.h:
            (JSC::LocalAllocator::tlc const):
            * heap/MarkStackMergingConstraint.cpp:
            * heap/MarkStackMergingConstraint.h:
            * heap/MarkedBlock.cpp:
            (JSC::MarkedBlock::Handle::associateWithOrigin):
            * heap/MarkedBlock.h:
            (JSC::MarkedBlock::Handle::securityOriginToken const):
            * heap/SecurityOriginToken.cpp: Added.
            (JSC::uniqueSecurityOriginToken):
            * heap/SecurityOriginToken.h: Added.
            * heap/ThreadLocalCache.cpp:
            (JSC::ThreadLocalCache::create):
            (JSC::ThreadLocalCache::ThreadLocalCache):
            (JSC::ThreadLocalCache::allocateData):
            (JSC::ThreadLocalCache::installSlow):
            * heap/ThreadLocalCache.h:
            (JSC::ThreadLocalCache::securityOriginToken const):
            * heap/ThreadLocalCacheInlines.h:
            (JSC::ThreadLocalCache::install):
            * runtime/JSGlobalObject.cpp:
            (JSC::JSGlobalObject::JSGlobalObject):
            (JSC::JSGlobalObject::createThreadLocalCache):
            * runtime/JSGlobalObject.h:
            (JSC::JSGlobalObject::threadLocalCache):
            (JSC::JSGlobalObject::threadLocalCache const): Deleted.
            * runtime/VMEntryScope.cpp:
            (JSC::VMEntryScope::VMEntryScope):
            (JSC::VMEntryScope::~VMEntryScope):
            * runtime/VMEntryScope.h:

2018-02-04  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r228035. rdar://problem/37220146

    2018-02-02  Saam Barati  <sbarati@apple.com>

            Make various DFG_ASSERTs provide more data to WTFCrashWithInfo
            https://bugs.webkit.org/show_bug.cgi?id=182453
            <rdar://problem/37174236>

            Reviewed by JF Bastien and Mark Lam.

            * dfg/DFGAbstractInterpreterInlines.h:
            (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
            * dfg/DFGArgumentsEliminationPhase.cpp:
            * dfg/DFGArgumentsUtilities.cpp:
            (JSC::DFG::emitCodeToGetArgumentsArrayLength):
            * dfg/DFGFixupPhase.cpp:
            (JSC::DFG::FixupPhase::fixupChecksInBlock):
            * dfg/DFGFlowIndexing.h:
            (JSC::DFG::FlowIndexing::shadowIndex const):
            * dfg/DFGLICMPhase.cpp:
            (JSC::DFG::LICMPhase::run):
            (JSC::DFG::LICMPhase::attemptHoist):
            * dfg/DFGLoopPreHeaderCreationPhase.cpp:
            (JSC::DFG::LoopPreHeaderCreationPhase::run):
            * dfg/DFGPutStackSinkingPhase.cpp:
            * dfg/DFGSpeculativeJIT.cpp:
            (JSC::DFG::SpeculativeJIT::compileArithAbs):
            (JSC::DFG::SpeculativeJIT::compileArithRounding):
            (JSC::DFG::SpeculativeJIT::compileToPrimitive):
            * dfg/DFGSpeculativeJIT64.cpp:
            (JSC::DFG::SpeculativeJIT::fillJSValue):
            (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
            (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Strict):
            (JSC::DFG::SpeculativeJIT::fillSpeculateInt52):
            (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
            (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
            (JSC::DFG::SpeculativeJIT::compile):
            * dfg/DFGStoreBarrierClusteringPhase.cpp:
            * dfg/DFGStoreBarrierInsertionPhase.cpp:
            * ftl/FTLLowerDFGToB3.cpp:
            (JSC::FTL::DFG::LowerDFGToB3::compileGetStack):
            (JSC::FTL::DFG::LowerDFGToB3::compileArithClz32):
            (JSC::FTL::DFG::LowerDFGToB3::compileArithAbs):
            (JSC::FTL::DFG::LowerDFGToB3::compileArithRound):
            (JSC::FTL::DFG::LowerDFGToB3::compileArithFloor):
            (JSC::FTL::DFG::LowerDFGToB3::compileArithCeil):
            (JSC::FTL::DFG::LowerDFGToB3::compileArithTrunc):
            (JSC::FTL::DFG::LowerDFGToB3::compileArithNegate):
            (JSC::FTL::DFG::LowerDFGToB3::compilePutById):
            (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage):
            (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
            (JSC::FTL::DFG::LowerDFGToB3::compileStringFromCharCode):
            (JSC::FTL::DFG::LowerDFGToB3::compileMultiPutByOffset):
            (JSC::FTL::DFG::LowerDFGToB3::compileCompareEq):
            (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
            (JSC::FTL::DFG::LowerDFGToB3::compileIn):
            (JSC::FTL::DFG::LowerDFGToB3::compare):
            (JSC::FTL::DFG::LowerDFGToB3::switchStringRecurse):
            (JSC::FTL::DFG::LowerDFGToB3::lowInt32):
            (JSC::FTL::DFG::LowerDFGToB3::lowInt52):
            (JSC::FTL::DFG::LowerDFGToB3::lowCell):
            (JSC::FTL::DFG::LowerDFGToB3::lowBoolean):
            (JSC::FTL::DFG::LowerDFGToB3::lowDouble):
            (JSC::FTL::DFG::LowerDFGToB3::lowJSValue):

2018-02-04  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r228031. rdar://problem/37220129

    2018-02-02  Saam Barati  <sbarati@apple.com>

            When BytecodeParser inserts Unreachable after ForceOSRExit it needs to update ArgumentPositions for Flushes it inserts
            https://bugs.webkit.org/show_bug.cgi?id=182368
            <rdar://problem/36932466>

            Reviewed by Mark Lam.

            When preserving liveness when inserting Unreachable nodes after ForceOSRExit,
            we must add the VariableAccessData to the given argument position. Otherwise,
            we may end up with a VariableAccessData that doesn't respect the shouldNeverUnbox bit.
            If we end up with such a situation, it can lead to invalid IR after the
            arguments elimination phase optimizes a GetByVal to a GetStack.

            * dfg/DFGByteCodeParser.cpp:
            (JSC::DFG::ByteCodeParser::flushImpl):
            (JSC::DFG::ByteCodeParser::flushForTerminalImpl):
            (JSC::DFG::ByteCodeParser::flush):
            (JSC::DFG::ByteCodeParser::flushForTerminal):
            (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
            (JSC::DFG::ByteCodeParser::parse):

2018-02-04  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227998. rdar://problem/37220126

    2018-02-01  Mark Lam  <mark.lam@apple.com>

            Fix broken bounds check in FTL's compileGetMyArgumentByVal().
            https://bugs.webkit.org/show_bug.cgi?id=182419
            <rdar://problem/37044945>

            Reviewed by Saam Barati.

            In compileGetMyArgumentByVal(), it computes:
                limit = m_out.sub(limit, m_out.constInt32(m_node->numberOfArgumentsToSkip()));
                ...
                LValue isOutOfBounds = m_out.aboveOrEqual(originalIndex, limit);

            where the original "limit" is the number of arguments passed in by the caller.
            If the original limit is less than numberOfArgumentsToSkip, the resultant limit
            will be a large unsigned number.  As a result, this will defeat the bounds check
            that follows it.

            Note: later on in compileGetMyArgumentByVal(), we have to adjust adjust the index
            value by adding numberOfArgumentsToSkip to it, in order to determine the actual
            entry in the arguments array to get.

            The fix is to just add numberOfArgumentsToSkip to index upfront (instead of
            subtracting it from limit), and doing an overflow speculation check on that
            addition before doing the bounds check.

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

2018-02-04  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227994. rdar://problem/37145542

    2018-02-01  Keith Miller  <keith_miller@apple.com>

            Fix crashes due to mishandling custom sections.
            https://bugs.webkit.org/show_bug.cgi?id=182404
            <rdar://problem/36935863>

            Reviewed by Saam Barati.

            This also cleans up some of our validation code. We also
            mistakenly, allowed unknown (different from custom sections with
            id: 0) section ids.

            * wasm/WasmModuleParser.cpp:
            (JSC::Wasm::ModuleParser::parse):
            * wasm/WasmModuleParser.h:
            * wasm/WasmSections.h:
            (JSC::Wasm::isKnownSection):
            (JSC::Wasm::decodeSection):
            (JSC::Wasm::validateOrder):
            (JSC::Wasm::makeString):
            (JSC::Wasm::isValidSection): Deleted.

2018-02-04  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227959. rdar://problem/37145559

    2018-02-01  Chris Dumez  <cdumez@apple.com>

            Queue a microtask when a waitUntil() promise is settled
            https://bugs.webkit.org/show_bug.cgi?id=182372
            <rdar://problem/37101019>

            Reviewed by Mark Lam.

            Export a symbol so it can be used in WebCore.

            * runtime/JSGlobalObject.h:

2018-02-04  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227951. rdar://problem/37145493

    2018-01-31  Saam Barati  <sbarati@apple.com>

            Replace tryLargeMemalignVirtual with tryLargeZeroedMemalignVirtual and use it to allocate large zeroed memory in Wasm
            https://bugs.webkit.org/show_bug.cgi?id=182064
            <rdar://problem/36840132>

            Reviewed by Geoffrey Garen.

            This patch switches WebAssembly Memory to always use bmalloc's
            zeroed virtual allocation API. This makes it so that we don't
            dirty the memory to zero it. It's a huge compile time speedup
            on WasmBench on iOS.

            * wasm/WasmMemory.cpp:
            (JSC::Wasm::Memory::create):
            (JSC::Wasm::Memory::~Memory):
            (JSC::Wasm::Memory::addressIsInActiveFastMemory):
            (JSC::Wasm::Memory::grow):
            (JSC::Wasm::commitZeroPages): Deleted.

2018-01-31  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227898. rdar://problem/37079009

    2018-01-31  Saam Barati  <sbarati@apple.com>

            JSC incorrectly interpreting script, sets Global Property instead of Global Lexical variable (LiteralParser / JSONP path)
            https://bugs.webkit.org/show_bug.cgi?id=182074
            <rdar://problem/36846261>

            Reviewed by Mark Lam.

            This patch teaches the JSONP evaluator about the global lexical environment.
            Before, it was using the global object as the global scope, but that's wrong.
            The global lexical environment is the first node in the global scope chain.

            * interpreter/Interpreter.cpp:
            (JSC::Interpreter::executeProgram):
            * jsc.cpp:
            (GlobalObject::finishCreation):
            (shellSupportsRichSourceInfo):
            (functionDisableRichSourceInfo):
            * runtime/LiteralParser.cpp:
            (JSC::LiteralParser<CharType>::tryJSONPParse):
            * runtime/LiteralParser.h:

2018-01-31  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227721. rdar://problem/37019345

    2018-01-28  Filip Pizlo  <fpizlo@apple.com>

            LargeAllocation should do the same distancing as MarkedBlock
            https://bugs.webkit.org/show_bug.cgi?id=182226

            Reviewed by Saam Barati.

            This makes LargeAllocation do the same exact distancing that MarkedBlock promises to do.

            To make that possible, this patch first makes MarkedBlock know exactly how much distancing it
            is doing:

            - I've rationalized the payloadSize calculation. In particular, I made MarkedSpace use the
              calculation done in MarkedBlock. MarkedSpace used to do the math a different way. This
              keeps the old way just for a static_assert.

            - The promised amount of distancing is now codified in HeapCell.h as
              minimumDistanceBetweenCellsFromDifferentOrigins. We assert that the footer size is at least
              as big as this. I didn't want to just use footer size for this constant because then, if
              you increased the size of the footer, you'd also add padding to every large allocation.

            Then this patch just adds minimumDistanceBetweenCellsFromDifferentOrigins to each large
            allocation. It also zeroes that slice of memory to prevent any information leaks that way.

            This is perf neutral. Large allocations start out at ~8000 bytes. The amount of padding is
            ~300 bytes. That's 3.75% space overhead for objects that are ~8000 bytes, zero overhead for
            smaller objects, and diminishing overhead for larger objects. We allocate very few large
            objects, so we shouldn't have any real space overhead from this.

            * heap/HeapCell.h:
            * heap/LargeAllocation.cpp:
            (JSC::LargeAllocation::tryCreate):
            * heap/MarkedBlock.h:
            * heap/MarkedSpace.h:

2018-01-31  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227718. rdar://problem/37019341

    2018-01-27  Filip Pizlo  <fpizlo@apple.com>

            Make MarkedBlock::Footer bigger
            https://bugs.webkit.org/show_bug.cgi?id=182220

            Reviewed by JF Bastien.

            This makes the block footer larger by moving the newlyAllocated bits from the handle into
            the footer.

            It used to be profitable to put anything we could into the handle because that would free up
            payload space inside the block. But now that we want to use the footer for padding, it's
            profitable to put GC state information - especially data that is used by the GC itself and so
            is not useful for a Spectre attack - into the footer to increase object distancing.

            * heap/CellContainer.cpp:
            (JSC::CellContainer::isNewlyAllocated const):
            * heap/IsoCellSet.cpp:
            (JSC::IsoCellSet::sweepToFreeList):
            * heap/MarkedBlock.cpp:
            (JSC::MarkedBlock::Handle::Handle):
            (JSC::MarkedBlock::Footer::Footer):
            (JSC::MarkedBlock::Handle::stopAllocating):
            (JSC::MarkedBlock::Handle::lastChanceToFinalize):
            (JSC::MarkedBlock::Handle::resumeAllocating):
            (JSC::MarkedBlock::aboutToMarkSlow):
            (JSC::MarkedBlock::resetAllocated):
            (JSC::MarkedBlock::Handle::resetAllocated): Deleted.
            * heap/MarkedBlock.h:
            (JSC::MarkedBlock::newlyAllocatedVersion const):
            (JSC::MarkedBlock::isNewlyAllocated):
            (JSC::MarkedBlock::setNewlyAllocated):
            (JSC::MarkedBlock::clearNewlyAllocated):
            (JSC::MarkedBlock::newlyAllocated const):
            (JSC::MarkedBlock::Handle::newlyAllocatedVersion const): Deleted.
            (JSC::MarkedBlock::Handle::isNewlyAllocated): Deleted.
            (JSC::MarkedBlock::Handle::setNewlyAllocated): Deleted.
            (JSC::MarkedBlock::Handle::clearNewlyAllocated): Deleted.
            (JSC::MarkedBlock::Handle::newlyAllocated const): Deleted.
            * heap/MarkedBlockInlines.h:
            (JSC::MarkedBlock::isNewlyAllocatedStale const):
            (JSC::MarkedBlock::hasAnyNewlyAllocated):
            (JSC::MarkedBlock::Handle::isLive):
            (JSC::MarkedBlock::Handle::specializedSweep):
            (JSC::MarkedBlock::Handle::newlyAllocatedMode):
            (JSC::MarkedBlock::Handle::isNewlyAllocatedStale const): Deleted.
            (JSC::MarkedBlock::Handle::hasAnyNewlyAllocated): Deleted.
            * heap/MarkedSpace.cpp:
            (JSC::MarkedSpace::endMarking):
            * heap/SlotVisitor.cpp:
            (JSC::SlotVisitor::appendJSCellOrAuxiliary):

2018-01-31  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227717. rdar://problem/37019339

    2018-01-27  Filip Pizlo  <fpizlo@apple.com>

            MarkedBlock should have a footer instead of a header
            https://bugs.webkit.org/show_bug.cgi?id=182217

            Reviewed by JF Bastien.

            This moves the MarkedBlock's meta-data from the header to the footer. This doesn't really
            change anything except for some compile-time constants, so it should not affect performance.

            This change is to help protect against Spectre attacks on structure checks, which allow for
            small-offset out-of-bounds access. By putting the meta-data at the end of the block, small
            OOBs will only get to other objects in the same block or the block footer. The block footer
            is not super interesting. So, if we combine this with the TLC change (r227617), this means we
            can use blocks as the mechanism of achieving distance between objects from different origins.
            We just need to avoid ever putting objects from different origins in the same block. That's
            what bug 181636 is about.

            * heap/BlockDirectory.cpp:
            (JSC::blockHeaderSize): Deleted.
            (JSC::BlockDirectory::blockSizeForBytes): Deleted.
            * heap/BlockDirectory.h:
            * heap/HeapUtil.h:
            (JSC::HeapUtil::findGCObjectPointersForMarking):
            * heap/MarkedBlock.cpp:
            (JSC::MarkedBlock::MarkedBlock):
            (JSC::MarkedBlock::~MarkedBlock):
            (JSC::MarkedBlock::Footer::Footer):
            (JSC::MarkedBlock::Footer::~Footer):
            (JSC::MarkedBlock::Handle::stopAllocating):
            (JSC::MarkedBlock::Handle::lastChanceToFinalize):
            (JSC::MarkedBlock::Handle::resumeAllocating):
            (JSC::MarkedBlock::aboutToMarkSlow):
            (JSC::MarkedBlock::resetMarks):
            (JSC::MarkedBlock::assertMarksNotStale):
            (JSC::MarkedBlock::Handle::didConsumeFreeList):
            (JSC::MarkedBlock::markCount):
            (JSC::MarkedBlock::clearHasAnyMarked):
            (JSC::MarkedBlock::Handle::didAddToDirectory):
            (JSC::MarkedBlock::Handle::didRemoveFromDirectory):
            (JSC::MarkedBlock::Handle::sweep):
            * heap/MarkedBlock.h:
            (JSC::MarkedBlock::markingVersion const):
            (JSC::MarkedBlock::lock):
            (JSC::MarkedBlock::subspace const):
            (JSC::MarkedBlock::footer):
            (JSC::MarkedBlock::footer const):
            (JSC::MarkedBlock::handle):
            (JSC::MarkedBlock::handle const):
            (JSC::MarkedBlock::Handle::blockFooter):
            (JSC::MarkedBlock::isAtomAligned):
            (JSC::MarkedBlock::Handle::cellAlign):
            (JSC::MarkedBlock::blockFor):
            (JSC::MarkedBlock::vm const):
            (JSC::MarkedBlock::weakSet):
            (JSC::MarkedBlock::cellSize):
            (JSC::MarkedBlock::attributes const):
            (JSC::MarkedBlock::atomNumber):
            (JSC::MarkedBlock::areMarksStale):
            (JSC::MarkedBlock::aboutToMark):
            (JSC::MarkedBlock::isMarkedRaw):
            (JSC::MarkedBlock::isMarked):
            (JSC::MarkedBlock::testAndSetMarked):
            (JSC::MarkedBlock::marks const):
            (JSC::MarkedBlock::isAtom):
            (JSC::MarkedBlock::Handle::forEachCell):
            (JSC::MarkedBlock::hasAnyMarked const):
            (JSC::MarkedBlock::noteMarked):
            (WTF::MarkedBlockHash::hash):
            (JSC::MarkedBlock::firstAtom): Deleted.
            * heap/MarkedBlockInlines.h:
            (JSC::MarkedBlock::marksConveyLivenessDuringMarking):
            (JSC::MarkedBlock::Handle::isLive):
            (JSC::MarkedBlock::Handle::specializedSweep):
            (JSC::MarkedBlock::Handle::forEachLiveCell):
            (JSC::MarkedBlock::Handle::forEachDeadCell):
            (JSC::MarkedBlock::Handle::forEachMarkedCell):
            * heap/MarkedSpace.cpp:
            * heap/MarkedSpace.h:
            * llint/LowLevelInterpreter.asm:
            * llint/LowLevelInterpreter32_64.asm:
            * llint/LowLevelInterpreter64.asm:

2018-01-31  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227700. rdar://problem/37019364

    2018-01-26  Saam Barati  <sbarati@apple.com>

            Fix emitAllocateWithNonNullAllocator to work on arm
            https://bugs.webkit.org/show_bug.cgi?id=182187
            <rdar://problem/36906550>

            Reviewed by Filip Pizlo.

            This patch unifies the x86 and ARM paths in emitAllocateWithNonNullAllocator
            and makes it so that emitAllocateWithNonNullAllocator uses the macro scratch
            register on ARM.

            * ftl/FTLLowerDFGToB3.cpp:
            (JSC::FTL::DFG::LowerDFGToB3::allocateHeapCell):
            * jit/AssemblyHelpers.cpp:
            (JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator):

2018-01-31  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227683. rdar://problem/37019334

    2018-01-26  Filip Pizlo  <fpizlo@apple.com>

            Disable TLS-based TLCs
            https://bugs.webkit.org/show_bug.cgi?id=182175

            Reviewed by Saam Barati.

            Check for the new USE(FAST_TLS_FOR_TLC) flag instead of just ENABLE(FAST_TLS_JIT).

            * heap/BlockDirectory.cpp:
            (JSC::BlockDirectory::~BlockDirectory):
            * heap/BlockDirectory.h:
            * heap/ThreadLocalCache.cpp:
            (JSC::ThreadLocalCache::installSlow):
            (JSC::ThreadLocalCache::installData):
            * heap/ThreadLocalCache.h:
            * heap/ThreadLocalCacheInlines.h:
            (JSC::ThreadLocalCache::getImpl):
            * jit/AssemblyHelpers.cpp:
            (JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator):
            * runtime/VM.cpp:
            (JSC::VM::~VM):
            * runtime/VM.h:

2018-01-30  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227617. rdar://problem/37019352

    2018-01-25  Filip Pizlo  <fpizlo@apple.com>

            JSC GC should support TLCs (thread local caches)
            https://bugs.webkit.org/show_bug.cgi?id=181559

            Reviewed by Mark Lam and Saam Barati.

            This is a big step towards object distancing by site origin. This patch implements TLCs, or
            thread-local caches, which allow each thread to allocate from its own free lists. It also
            means that any given thread can context-switch TLCs. This will allow us to do separate
            allocation for separate site origins. Eventually, once we reshape how MarkedBlock looks, this
            will allow us to have a hard distancing constraint between objects from different origins.

            In this new design, every "size class" is represented as a BlockDirectory (formerly known as
            MarkedAllocator, prior to r226822). This contains a bag of blocks allocated using some
            aligned memory allocator (which roughly represents which cage you came out of), and anyone
            using the same allocator can share those blocks - but so long as they are in that
            BlockDirectory, they will have the size and type of that directory. Previously, each
            BlockDirectory had exactly one FreeList. Now, each BlockDirectory has a double-linked-list of
            LocalAllocators, each of which has a FreeList.

            To decide which LocalAllocator to allocate out of, we need a ThreadLocalCache and a
            BlockDirectory. The directory gives us an offset-within-the-ThreadLocalCache, which we simply
            call the Allocator (which is just a POD type that contains a 32-bit offset). Each allocation
            starts by figuring out what Allocator it wants (often we have this information at JIT time).
            Then the allocation loads its ThreadLocalCache::Data from a fast TLS slot. Then we add the
            Allocator offset to the ThreadLocalCache::Data to get the LocalAllocator. Note that we use
            offsets as opposed to indices to make it easy to do the math on each allocation (if
            LocalAllocator had a weird size then every allocation would have to do an imul).

            This is a definite slow-down on GC-heavy benchmarks, but by a small margin, and only on
            unusually heavy tests. For example, boyer and splay are both 3% regressed, but the Octane
            geomean is just fine. The JetStream score regressed by 0.5% with p = 0.08 (so maybe there is
            something there, but it's not significant according to our threshold).

            Relanding after fixing ARM64 bug in AssemblyHelpers::emitAllocateWithNonNullAllocator(). That
            function needs to be careful to avoid using the scratch register because the FTL will call it
            in disallow-scratch-register mode.

            * JavaScriptCore.xcodeproj/project.pbxproj:
            * Sources.txt:
            * b3/B3LowerToAir.cpp:
            * b3/B3PatchpointSpecial.cpp:
            (JSC::B3::PatchpointSpecial::admitsStack):
            * b3/B3StackmapSpecial.cpp:
            (JSC::B3::StackmapSpecial::forEachArgImpl):
            (JSC::B3::StackmapSpecial::isArgValidForRep):
            * b3/B3StackmapValue.cpp:
            (JSC::B3::StackmapValue::appendSomeRegisterWithClobber):
            * b3/B3StackmapValue.h:
            * b3/B3Validate.cpp:
            * b3/B3ValueRep.cpp:
            (JSC::B3::ValueRep::addUsedRegistersTo const):
            (JSC::B3::ValueRep::dump const):
            (WTF::printInternal):
            * b3/B3ValueRep.h:
            (JSC::B3::ValueRep::ValueRep):
            * bytecode/AccessCase.cpp:
            (JSC::AccessCase::generateImpl):
            * bytecode/ObjectAllocationProfile.h:
            (JSC::ObjectAllocationProfile::ObjectAllocationProfile):
            (JSC::ObjectAllocationProfile::clear):
            * bytecode/ObjectAllocationProfileInlines.h:
            (JSC::ObjectAllocationProfile::initializeProfile):
            * dfg/DFGSpeculativeJIT.cpp:
            (JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
            (JSC::DFG::SpeculativeJIT::compileMakeRope):
            (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
            (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
            (JSC::DFG::SpeculativeJIT::compileCreateThis):
            (JSC::DFG::SpeculativeJIT::compileNewObject):
            * dfg/DFGSpeculativeJIT.h:
            (JSC::DFG::SpeculativeJIT::emitAllocateJSCell):
            (JSC::DFG::SpeculativeJIT::emitAllocateJSObject):
            * ftl/FTLAbstractHeapRepository.h:
            * ftl/FTLLowerDFGToB3.cpp:
            (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
            (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
            (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorageWithSizeImpl):
            (JSC::FTL::DFG::LowerDFGToB3::allocateHeapCell):
            (JSC::FTL::DFG::LowerDFGToB3::allocateObject):
            (JSC::FTL::DFG::LowerDFGToB3::allocatorForSize):
            (JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedObject):
            (JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedCell):
            * heap/Allocator.cpp: Added.
            (JSC::Allocator::cellSize const):
            * heap/Allocator.h: Added.
            (JSC::Allocator::Allocator):
            (JSC::Allocator::offset const):
            (JSC::Allocator::operator== const):
            (JSC::Allocator::operator!= const):
            (JSC::Allocator::operator bool const):
            * heap/AllocatorInlines.h: Added.
            (JSC::Allocator::allocate const):
            (JSC::Allocator::tryAllocate const):
            * heap/BlockDirectory.cpp:
            (JSC::BlockDirectory::BlockDirectory):
            (JSC::BlockDirectory::findBlockForAllocation):
            (JSC::BlockDirectory::stopAllocating):
            (JSC::BlockDirectory::prepareForAllocation):
            (JSC::BlockDirectory::stopAllocatingForGood):
            (JSC::BlockDirectory::resumeAllocating):
            (JSC::BlockDirectory::endMarking):
            (JSC::BlockDirectory::isFreeListedCell):
            (JSC::BlockDirectory::didConsumeFreeList): Deleted.
            (JSC::BlockDirectory::tryAllocateWithoutCollecting): Deleted.
            (JSC::BlockDirectory::allocateIn): Deleted.
            (JSC::BlockDirectory::tryAllocateIn): Deleted.
            (JSC::BlockDirectory::doTestCollectionsIfNeeded): Deleted.
            (JSC::BlockDirectory::allocateSlowCase): Deleted.
            * heap/BlockDirectory.h:
            (JSC::BlockDirectory::cellKind const):
            (JSC::BlockDirectory::allocator const):
            (JSC::BlockDirectory::freeList const): Deleted.
            (JSC::BlockDirectory::offsetOfFreeList): Deleted.
            (JSC::BlockDirectory::offsetOfCellSize): Deleted.
            * heap/BlockDirectoryInlines.h:
            (JSC::BlockDirectory::isFreeListedCell const): Deleted.
            (JSC::BlockDirectory::allocate): Deleted.
            * heap/CompleteSubspace.cpp:
            (JSC::CompleteSubspace::CompleteSubspace):
            (JSC::CompleteSubspace::allocatorFor):
            (JSC::CompleteSubspace::allocate):
            (JSC::CompleteSubspace::allocateNonVirtual):
            (JSC::CompleteSubspace::allocatorForSlow):
            (JSC::CompleteSubspace::allocateSlow):
            (JSC::CompleteSubspace::tryAllocateSlow):
            * heap/CompleteSubspace.h:
            (JSC::CompleteSubspace::allocatorForSizeStep):
            (JSC::CompleteSubspace::allocatorForNonVirtual):
            * heap/FreeList.h:
            * heap/GCDeferralContext.h:
            * heap/Heap.cpp:
            (JSC::Heap::Heap):
            (JSC::Heap::lastChanceToFinalize):
            * heap/Heap.h:
            (JSC::Heap::threadLocalCacheLayout):
            * heap/IsoCellSet.h:
            * heap/IsoSubspace.cpp:
            (JSC::IsoSubspace::IsoSubspace):
            (JSC::IsoSubspace::allocatorFor):
            (JSC::IsoSubspace::allocate):
            (JSC::IsoSubspace::allocateNonVirtual):
            * heap/IsoSubspace.h:
            (JSC::IsoSubspace::allocatorForNonVirtual):
            * heap/LocalAllocator.cpp: Added.
            (JSC::LocalAllocator::LocalAllocator):
            (JSC::LocalAllocator::reset):
            (JSC::LocalAllocator::~LocalAllocator):
            (JSC::LocalAllocator::stopAllocating):
            (JSC::LocalAllocator::resumeAllocating):
            (JSC::LocalAllocator::prepareForAllocation):
            (JSC::LocalAllocator::stopAllocatingForGood):
            (JSC::LocalAllocator::allocateSlowCase):
            (JSC::LocalAllocator::didConsumeFreeList):
            (JSC::LocalAllocator::tryAllocateWithoutCollecting):
            (JSC::LocalAllocator::allocateIn):
            (JSC::LocalAllocator::tryAllocateIn):
            (JSC::LocalAllocator::doTestCollectionsIfNeeded):
            (JSC::LocalAllocator::isFreeListedCell const):
            * heap/LocalAllocator.h: Added.
            (JSC::LocalAllocator::offsetOfFreeList):
            (JSC::LocalAllocator::offsetOfCellSize):
            * heap/LocalAllocatorInlines.h: Added.
            (JSC::LocalAllocator::allocate):
            * heap/MarkedSpace.cpp:
            (JSC::MarkedSpace::stopAllocatingForGood):
            * heap/MarkedSpace.h:
            * heap/SlotVisitor.cpp:
            * heap/SlotVisitor.h:
            * heap/Subspace.h:
            * heap/ThreadLocalCache.cpp: Added.
            (JSC::ThreadLocalCache::create):
            (JSC::ThreadLocalCache::ThreadLocalCache):
            (JSC::ThreadLocalCache::~ThreadLocalCache):
            (JSC::ThreadLocalCache::allocateData):
            (JSC::ThreadLocalCache::destroyData):
            (JSC::ThreadLocalCache::installSlow):
            (JSC::ThreadLocalCache::installData):
            (JSC::ThreadLocalCache::allocatorSlow):
            (JSC::ThreadLocalCache::destructor):
            * heap/ThreadLocalCache.h: Added.
            (JSC::ThreadLocalCache::offsetOfSize):
            (JSC::ThreadLocalCache::offsetOfFirstAllocator):
            * heap/ThreadLocalCacheInlines.h: Added.
            (JSC::ThreadLocalCache::getImpl):
            (JSC::ThreadLocalCache::get):
            (JSC::ThreadLocalCache::install):
            (JSC::ThreadLocalCache::allocator):
            (JSC::ThreadLocalCache::tryGetAllocator):
            * heap/ThreadLocalCacheLayout.cpp: Added.
            (JSC::ThreadLocalCacheLayout::ThreadLocalCacheLayout):
            (JSC::ThreadLocalCacheLayout::~ThreadLocalCacheLayout):
            (JSC::ThreadLocalCacheLayout::allocateOffset):
            (JSC::ThreadLocalCacheLayout::snapshot):
            (JSC::ThreadLocalCacheLayout::directory):
            * heap/ThreadLocalCacheLayout.h: Added.
            * jit/AssemblyHelpers.cpp:
            (JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator):
            (JSC::AssemblyHelpers::emitAllocate):
            (JSC::AssemblyHelpers::emitAllocateVariableSized):
            * jit/AssemblyHelpers.h:
            (JSC::AssemblyHelpers::vm):
            (JSC::AssemblyHelpers::emitAllocateJSCell):
            (JSC::AssemblyHelpers::emitAllocateJSObject):
            (JSC::AssemblyHelpers::emitAllocateJSObjectWithKnownSize):
            (JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator): Deleted.
            (JSC::AssemblyHelpers::emitAllocate): Deleted.
            (JSC::AssemblyHelpers::emitAllocateVariableSized): Deleted.
            * jit/JITOpcodes.cpp:
            (JSC::JIT::emit_op_new_object):
            (JSC::JIT::emit_op_create_this):
            * jit/JITOpcodes32_64.cpp:
            (JSC::JIT::emit_op_new_object):
            (JSC::JIT::emit_op_create_this):
            * runtime/ButterflyInlines.h:
            (JSC::Butterfly::createUninitialized):
            (JSC::Butterfly::tryCreate):
            (JSC::Butterfly::growArrayRight):
            * runtime/DirectArguments.cpp:
            (JSC::DirectArguments::overrideThings):
            * runtime/GenericArgumentsInlines.h:
            (JSC::GenericArguments<Type>::initModifiedArgumentsDescriptor):
            * runtime/HashMapImpl.h:
            (JSC::HashMapBuffer::create):
            * runtime/JSArray.cpp:
            (JSC::JSArray::tryCreateUninitializedRestricted):
            (JSC::JSArray::unshiftCountSlowCase):
            * runtime/JSArray.h:
            (JSC::JSArray::tryCreate):
            * runtime/JSArrayBufferView.cpp:
            (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
            * runtime/JSCellInlines.h:
            (JSC::tryAllocateCellHelper):
            * runtime/JSGlobalObject.cpp:
            (JSC::JSGlobalObject::JSGlobalObject):
            * runtime/JSGlobalObject.h:
            (JSC::JSGlobalObject::threadLocalCache const):
            * runtime/JSLock.cpp:
            (JSC::JSLock::didAcquireLock):
            * runtime/Options.h:
            * runtime/RegExpMatchesArray.h:
            (JSC::tryCreateUninitializedRegExpMatchesArray):
            * runtime/VM.cpp:
            (JSC::VM::VM):
            * runtime/VM.h:
            * runtime/VMEntryScope.cpp:
            (JSC::VMEntryScope::VMEntryScope):

2018-01-30  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r226783. rdar://problem/37077980

    2018-01-04  Filip Pizlo  <fpizlo@apple.com>

            CodeBlocks should be in IsoSubspaces
            https://bugs.webkit.org/show_bug.cgi?id=180884

            Reviewed by Saam Barati.

            This moves CodeBlocks into IsoSubspaces. Doing so means that we no longer need to have the
            special CodeBlockSet HashSets of new and old CodeBlocks. We also no longer use
            WeakReferenceHarvester or UnconditionalFinalizer. Instead:

            - Code block sweeping is now just eager sweeping. This means that it automatically takes
              advantage of our unswept set, which roughly corresponds to what CodeBlockSet used to use
              its eden set for.

            - Those idea of Executable "weakly visiting" the CodeBlock is replaced by Executable
              marking a ExecutableToCodeBlockEdge object. That object being marked corresponds to what
              we used to call CodeBlock "having been weakly visited". This means that CodeBlockSet no
              longer has to clear the set of weakly visited code blocks. This also means that
              determining CodeBlock liveness, propagating CodeBlock transitions, and jettisoning
              CodeBlocks during GC are now the edge's job. The edge is also in an IsoSubspace and it
              has IsoCellSets to tell us which edges have output constraints (what we used to call
              CodeBlock's weak reference harvester) and which have unconditional finalizers.

            - CodeBlock now uses an IsoCellSet to tell if it has an unconditional finalizer.

            - CodeBlockSet still exists!  It has one unified HashSet of CodeBlocks that we use to
              handle requests from the sampler, debugger, and other facilities. They may want to ask
              if some pointer corresponds to a CodeBlock during stages of execution during which the
              GC is unable to answer isLive() queries. The trickiest is the sampling profiler thread.
              There is no way that the GC's isLive could tell us of a CodeBlock that had already been
              allocated has now been full constructed.

            Rolling this back in because it was rolled out by mistake. There was a flaky crash that was
            happening before and after this change, but we misread the revision numbers at first and
            thought that this was the cause.

            * JavaScriptCore.xcodeproj/project.pbxproj:
            * Sources.txt:
            * bytecode/CodeBlock.cpp:
            (JSC::CodeBlock::CodeBlock):
            (JSC::CodeBlock::finishCreation):
            (JSC::CodeBlock::finishCreationCommon):
            (JSC::CodeBlock::~CodeBlock):
            (JSC::CodeBlock::visitChildren):
            (JSC::CodeBlock::propagateTransitions):
            (JSC::CodeBlock::determineLiveness):
            (JSC::CodeBlock::finalizeUnconditionally):
            (JSC::CodeBlock::stronglyVisitStrongReferences):
            (JSC::CodeBlock::hasInstalledVMTrapBreakpoints const):
            (JSC::CodeBlock::installVMTrapBreakpoints):
            (JSC::CodeBlock::dumpMathICStats):
            (JSC::CodeBlock::visitWeakly): Deleted.
            (JSC::CodeBlock::WeakReferenceHarvester::visitWeakReferences): Deleted.
            (JSC::CodeBlock::UnconditionalFinalizer::finalizeUnconditionally): Deleted.
            * bytecode/CodeBlock.h:
            (JSC::CodeBlock::subspaceFor):
            (JSC::CodeBlock::ownerEdge const):
            (JSC::CodeBlock::clearVisitWeaklyHasBeenCalled): Deleted.
            * bytecode/EvalCodeBlock.h:
            (JSC::EvalCodeBlock::create): Deleted.
            (JSC::EvalCodeBlock::createStructure): Deleted.
            (JSC::EvalCodeBlock::variable): Deleted.
            (JSC::EvalCodeBlock::numVariables): Deleted.
            (JSC::EvalCodeBlock::functionHoistingCandidate): Deleted.
            (JSC::EvalCodeBlock::numFunctionHoistingCandidates): Deleted.
            (JSC::EvalCodeBlock::EvalCodeBlock): Deleted.
            (JSC::EvalCodeBlock::unlinkedEvalCodeBlock const): Deleted.
            * bytecode/ExecutableToCodeBlockEdge.cpp: Added.
            (JSC::ExecutableToCodeBlockEdge::createStructure):
            (JSC::ExecutableToCodeBlockEdge::create):
            (JSC::ExecutableToCodeBlockEdge::visitChildren):
            (JSC::ExecutableToCodeBlockEdge::visitOutputConstraints):
            (JSC::ExecutableToCodeBlockEdge::finalizeUnconditionally):
            (JSC::ExecutableToCodeBlockEdge::activate):
            (JSC::ExecutableToCodeBlockEdge::deactivate):
            (JSC::ExecutableToCodeBlockEdge::deactivateAndUnwrap):
            (JSC::ExecutableToCodeBlockEdge::wrap):
            (JSC::ExecutableToCodeBlockEdge::wrapAndActivate):
            (JSC::ExecutableToCodeBlockEdge::ExecutableToCodeBlockEdge):
            (JSC::ExecutableToCodeBlockEdge::runConstraint):
            * bytecode/ExecutableToCodeBlockEdge.h: Added.
            (JSC::ExecutableToCodeBlockEdge::subspaceFor):
            (JSC::ExecutableToCodeBlockEdge::codeBlock const):
            (JSC::ExecutableToCodeBlockEdge::unwrap):
            * bytecode/FunctionCodeBlock.h:
            (JSC::FunctionCodeBlock::subspaceFor):
            (JSC::FunctionCodeBlock::createStructure):
            * bytecode/ModuleProgramCodeBlock.h:
            (JSC::ModuleProgramCodeBlock::create): Deleted.
            (JSC::ModuleProgramCodeBlock::createStructure): Deleted.
            (JSC::ModuleProgramCodeBlock::ModuleProgramCodeBlock): Deleted.
            * bytecode/ProgramCodeBlock.h:
            (JSC::ProgramCodeBlock::create): Deleted.
            (JSC::ProgramCodeBlock::createStructure): Deleted.
            (JSC::ProgramCodeBlock::ProgramCodeBlock): Deleted.
            * debugger/Debugger.cpp:
            (JSC::Debugger::SetSteppingModeFunctor::operator() const):
            (JSC::Debugger::ToggleBreakpointFunctor::operator() const):
            (JSC::Debugger::ClearCodeBlockDebuggerRequestsFunctor::operator() const):
            (JSC::Debugger::ClearDebuggerRequestsFunctor::operator() const):
            * heap/CodeBlockSet.cpp:
            (JSC::CodeBlockSet::contains):
            (JSC::CodeBlockSet::dump const):
            (JSC::CodeBlockSet::add):
            (JSC::CodeBlockSet::remove):
            (JSC::CodeBlockSet::promoteYoungCodeBlocks): Deleted.
            (JSC::CodeBlockSet::clearMarksForFullCollection): Deleted.
            (JSC::CodeBlockSet::lastChanceToFinalize): Deleted.
            (JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced): Deleted.
            * heap/CodeBlockSet.h:
            * heap/CodeBlockSetInlines.h:
            (JSC::CodeBlockSet::iterate):
            (JSC::CodeBlockSet::iterateViaSubspaces):
            * heap/ConservativeRoots.cpp:
            (JSC::ConservativeRoots::genericAddPointer):
            (JSC::DummyMarkHook::markKnownJSCell):
            (JSC::CompositeMarkHook::mark):
            (JSC::CompositeMarkHook::markKnownJSCell):
            * heap/ConservativeRoots.h:
            * heap/Heap.cpp:
            (JSC::Heap::lastChanceToFinalize):
            (JSC::Heap::finalizeMarkedUnconditionalFinalizers):
            (JSC::Heap::finalizeUnconditionalFinalizers):
            (JSC::Heap::beginMarking):
            (JSC::Heap::deleteUnmarkedCompiledCode):
            (JSC::Heap::sweepInFinalize):
            (JSC::Heap::forEachCodeBlockImpl):
            (JSC::Heap::forEachCodeBlockIgnoringJITPlansImpl):
            (JSC::Heap::addCoreConstraints):
            (JSC::Heap::finalizeUnconditionalFinalizersInIsoSubspace): Deleted.
            * heap/Heap.h:
            * heap/HeapCell.h:
            * heap/HeapCellInlines.h:
            (JSC::HeapCell::subspace const):
            * heap/HeapInlines.h:
            (JSC::Heap::forEachCodeBlock):
            (JSC::Heap::forEachCodeBlockIgnoringJITPlans):
            * heap/HeapUtil.h:
            (JSC::HeapUtil::findGCObjectPointersForMarking):
            * heap/IsoCellSet.cpp:
            (JSC::IsoCellSet::parallelNotEmptyMarkedBlockSource):
            * heap/IsoCellSet.h:
            * heap/IsoCellSetInlines.h:
            (JSC::IsoCellSet::forEachMarkedCellInParallel):
            (JSC::IsoCellSet::forEachLiveCell):
            * heap/LargeAllocation.h:
            (JSC::LargeAllocation::subspace const):
            * heap/MarkStackMergingConstraint.cpp:
            (JSC::MarkStackMergingConstraint::executeImpl):
            * heap/MarkStackMergingConstraint.h:
            * heap/MarkedAllocator.cpp:
            (JSC::MarkedAllocator::parallelNotEmptyBlockSource):
            * heap/MarkedBlock.cpp:
            (JSC::MarkedBlock::Handle::didAddToAllocator):
            (JSC::MarkedBlock::Handle::didRemoveFromAllocator):
            * heap/MarkedBlock.h:
            (JSC::MarkedBlock::subspace const):
            * heap/MarkedBlockInlines.h:
            (JSC::MarkedBlock::Handle::forEachLiveCell):
            * heap/MarkedSpaceInlines.h:
            (JSC::MarkedSpace::forEachLiveCell):
            * heap/MarkingConstraint.cpp:
            (JSC::MarkingConstraint::execute):
            (JSC::MarkingConstraint::doParallelWork):
            (JSC::MarkingConstraint::finishParallelWork): Deleted.
            (JSC::MarkingConstraint::doParallelWorkImpl): Deleted.
            (JSC::MarkingConstraint::finishParallelWorkImpl): Deleted.
            * heap/MarkingConstraint.h:
            * heap/MarkingConstraintSet.cpp:
            (JSC::MarkingConstraintSet::add):
            * heap/MarkingConstraintSet.h:
            (JSC::MarkingConstraintSet::add):
            * heap/MarkingConstraintSolver.cpp:
            (JSC::MarkingConstraintSolver::execute):
            (JSC::MarkingConstraintSolver::addParallelTask):
            (JSC::MarkingConstraintSolver::runExecutionThread):
            (JSC::MarkingConstraintSolver::didExecute): Deleted.
            * heap/MarkingConstraintSolver.h:
            (JSC::MarkingConstraintSolver::TaskWithConstraint::TaskWithConstraint):
            (JSC::MarkingConstraintSolver::TaskWithConstraint::operator== const):
            * heap/SimpleMarkingConstraint.cpp:
            (JSC::SimpleMarkingConstraint::SimpleMarkingConstraint):
            (JSC::SimpleMarkingConstraint::executeImpl):
            * heap/SimpleMarkingConstraint.h:
            (JSC::SimpleMarkingConstraint::SimpleMarkingConstraint):
            * heap/SlotVisitor.cpp:
            (JSC::SlotVisitor::addParallelConstraintTask):
            * heap/SlotVisitor.h:
            * heap/Subspace.cpp:
            (JSC::Subspace::sweep):
            * heap/Subspace.h:
            * heap/SubspaceInlines.h:
            (JSC::Subspace::forEachLiveCell):
            * llint/LowLevelInterpreter.asm:
            * runtime/EvalExecutable.cpp:
            (JSC::EvalExecutable::visitChildren):
            * runtime/EvalExecutable.h:
            (JSC::EvalExecutable::codeBlock):
            * runtime/FunctionExecutable.cpp:
            (JSC::FunctionExecutable::baselineCodeBlockFor):
            (JSC::FunctionExecutable::visitChildren):
            * runtime/FunctionExecutable.h:
            * runtime/JSType.h:
            * runtime/ModuleProgramExecutable.cpp:
            (JSC::ModuleProgramExecutable::visitChildren):
            * runtime/ModuleProgramExecutable.h:
            * runtime/ProgramExecutable.cpp:
            (JSC::ProgramExecutable::visitChildren):
            * runtime/ProgramExecutable.h:
            * runtime/ScriptExecutable.cpp:
            (JSC::ScriptExecutable::installCode):
            (JSC::ScriptExecutable::newReplacementCodeBlockFor):
            * runtime/VM.cpp:
            (JSC::VM::VM):
            * runtime/VM.h:
            (JSC::VM::SpaceAndFinalizerSet::SpaceAndFinalizerSet):
            (JSC::VM::SpaceAndFinalizerSet::finalizerSetFor):
            (JSC::VM::forEachCodeBlockSpace):
            * runtime/VMTraps.cpp:
            (JSC::VMTraps::handleTraps):
            * tools/VMInspector.cpp:
            (JSC::VMInspector::codeBlockForMachinePC):
            (JSC::VMInspector::isValidCodeBlock):

2018-01-31  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227874. rdar://problem/37059537

    2018-01-30  Mark Lam  <mark.lam@apple.com>

            Apply poisoning to TypedArray vector pointers.
            https://bugs.webkit.org/show_bug.cgi?id=182155
            <rdar://problem/36286266>

            Reviewed by JF Bastien.

            The TypeArray's vector pointer is now poisoned.  The poison value is chosen based
            on a TypeArray's jsType.  The JSType must be between FirstTypedArrayType and
            LastTypedArrayType.  At runtime, we enforce that the index is well-behaved by
            masking it against TypedArrayPoisonIndexMask.  TypedArrayPoisonIndexMask (16) is
            the number of TypedArray types (10) rounded up to the next power of 2.
            Accordingly, we reserve an array of TypedArrayPoisonIndexMask poisons so that we
            can use index masking on the index, and be guaranteed that the masked index will
            be within bounds of the poisons array.

            1. Fixed both DFG and FTL versions of compileGetTypedArrayByteOffset() to not
               do any unnecessary work if the TypedArray vector is null.

               FTL's cagedMayBeNull() is no longer needed because it is only used by
               compileGetTypedArrayByteOffset(), and we need to enhance it to handle unpoisoning
               in a TypedArray specific way.  So, might as well do the work inline in
               compileGetTypedArrayByteOffset() instead.

            2. Removed an unnecessary null-check in DFGSpeculativeJIT's compileNewTypedArrayWithSize()
               because there's already a null check above it that ensures that sizeGPR is
               never null.

            3. In LLInt's _llint_op_get_by_val, move the TypedArray length check before the
               loading of the vector for unpoisoning and uncaging.  We don't need the vector
               if the length is 0.

            Implementation notes on the need to null check the TypeArray vector:

            1. DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds() does not need a
               m_poisonedVector null check because the function is a null check.

            2. DFG::SpeculativeJIT::compileGetIndexedPropertyStorage() does not need a
               m_poisonedVector null check because it is followed by a call to
               cageTypedArrayStorage() which assumes that storageReg cannot be null.

            3. DFG::SpeculativeJIT::compileGetTypedArrayByteOffset() already has a
               m_poisonedVector null check.

            4. DFG::SpeculativeJIT::compileNewTypedArrayWithSize() does not need a vector null
               check because the poisoning code is preceded by a sizeGPR null check, which
               ensures that the storageGPR (vector to be poisoned) is not null.

            5. FTL's compileGetIndexedPropertyStorage() does not need a m_poisonedVector null
               check because it is followed by a call to caged() which assumes that the
               vector cannot be null.

            6. FTL's compileGetTypedArrayByteOffset() already has a m_poisonedVector null check.

            7. FTL's compileNewTypedArray() does not need a vector null check because the
               poisoning code is preceded by a size null check, which ensures that the
               storage (vector to be poisoned) is not null.

            8. FTL's speculateTypedArrayIsNotNeutered() does not need a
               m_poisonedVector null check because the function is a null check.

            9. IntrinsicGetterAccessCase::emitIntrinsicGetter()'s TypedArrayByteOffsetIntrinsic
               case needs a null check so that it does not try to unpoison a null vector.

            10. JIT::emitIntTypedArrayGetByVal() does not need a vector null check because
                we already do a length check even before loading the vector.

            11. JIT::emitFloatTypedArrayGetByVal() does not need a vector null check because
                we already do a length check even before loading the vector.

            12. JIT::emitIntTypedArrayPutByVal() does not need a vector null check because
                we already do a length check even before loading the vector.

            13. JIT::emitFloatTypedArrayPutByVal() does not need a vector null check because
                we already do a length check even before loading the vector.

            14. LLInt's loadTypedArrayCaged() does not need a vector null check because its
                client will do a TypedArray length check before calling it.

            * dfg/DFGFixupPhase.cpp:
            (JSC::DFG::FixupPhase::checkArray):
            * dfg/DFGNode.h:
            (JSC::DFG::Node::hasArrayMode):
            * dfg/DFGSpeculativeJIT.cpp:
            (JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds):
            (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
            (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
            (JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize):
            * ftl/FTLAbstractHeapRepository.h:
            * ftl/FTLLowerDFGToB3.cpp:
            (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage):
            (JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset):
            (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
            (JSC::FTL::DFG::LowerDFGToB3::speculateTypedArrayIsNotNeutered):
            (JSC::FTL::DFG::LowerDFGToB3::cagedMayBeNull): Deleted.
            * jit/IntrinsicEmitter.cpp:
            (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
            * jit/JITPropertyAccess.cpp:
            (JSC::JIT::emitIntTypedArrayGetByVal):
            (JSC::JIT::emitFloatTypedArrayGetByVal):
            (JSC::JIT::emitIntTypedArrayPutByVal):
            (JSC::JIT::emitFloatTypedArrayPutByVal):
            * llint/LowLevelInterpreter.asm:
            * llint/LowLevelInterpreter64.asm:
            * offlineasm/arm64.rb:
            * offlineasm/x86.rb:
            * runtime/CagedBarrierPtr.h:
            * runtime/JSArrayBufferView.cpp:
            (JSC::JSArrayBufferView::JSArrayBufferView):
            (JSC::JSArrayBufferView::finalize):
            (JSC::JSArrayBufferView::neuter):
            * runtime/JSArrayBufferView.h:
            (JSC::JSArrayBufferView::vector const):
            (JSC::JSArrayBufferView::offsetOfPoisonedVector):
            (JSC::JSArrayBufferView::poisonFor):
            (JSC::JSArrayBufferView::Poison::key):
            (JSC::JSArrayBufferView::offsetOfVector): Deleted.
            * runtime/JSCPoison.cpp:
            (JSC::initializePoison):
            * runtime/JSCPoison.h:
            * runtime/JSGenericTypedArrayViewInlines.h:
            (JSC::JSGenericTypedArrayView<Adaptor>::estimatedSize):
            (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren):
            (JSC::JSGenericTypedArrayView<Adaptor>::slowDownAndWasteMemory):
            * runtime/JSObject.h:

2018-01-30  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227649. rdar://problem/37019344

    2018-01-25  Yusuke Suzuki  <utatane.tea@gmail.com>

            imported/w3c/web-platform-tests/html/semantics/scripting-1/the-script-element/module/errorhandling.html crashes
            https://bugs.webkit.org/show_bug.cgi?id=181980

            Reviewed by Ryosuke Niwa.

            We accidentally failed to propagate errored promise in instantiate and satify phase if entry.{instantiate,satisfy}
            promises are set. Since we just returned `entry`, it becomes succeeded promise even if the dependent fetch, instantiate,
            and satisfy promises are failed. This patch fixes error propagation by returning `entry.instantiate` and `entry.satisfy`
            correctly.

            * builtins/ModuleLoaderPrototype.js:
            (requestInstantiate):
            (requestSatisfy):

2018-01-30  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227742. rdar://problem/37019360

    2018-01-29  Michael Saboff  <msaboff@apple.com>

            REGRESSION (r227341): DFG_ASSERT failure at JSC::DFG::AtTailAbstractState::forNode()
            https://bugs.webkit.org/show_bug.cgi?id=182249

            Reviewed by Keith Miller.

            Changed clobberize() handling of CompareEq, et al to properly handle comparisons between
            Untyped and Object values when compared against built in types.  Such comparisons can
            invoke toNumber() or other methods.

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

2018-01-30  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227716. rdar://problem/37019460

    2018-01-27  Yusuke Suzuki  <utatane.tea@gmail.com>

            DFG strength reduction fails to convert NumberToStringWithValidRadixConstant for 0 to constant '0'
            https://bugs.webkit.org/show_bug.cgi?id=182213

            Reviewed by Mark Lam.

            toStringWithRadixInternal is originally used for the slow path if the given value is larger than radix or negative.
            As a result, it does not accept 0 correctly, and produces an empty string. Since DFGStrengthReductionPhase uses
            this function, it accidentally converts NumberToStringWithValidRadixConstant(0, radix) to an empty string.
            This patch fixes toStringWithRadixInternal to accept 0. This change fixes twitch.tv's issue.

            We also add a careful cast to avoid `-INT32_MIN`. It does not produce incorrect value in x86 in practice,
            but it is UB, and a compiler may assume that the given value is never INT32_MIN and could do an incorrect optimization.

            * runtime/NumberPrototype.cpp:
            (JSC::toStringWithRadixInternal):

2018-01-30  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227644. rdar://problem/37019367

    2018-01-25  Mark Lam  <mark.lam@apple.com>

            Gardening: fix 32-bit build after r227643.
            https://bugs.webkit.org/show_bug.cgi?id=182086

            Not reviewed.

            * jit/AssemblyHelpers.cpp:
            (JSC::AssemblyHelpers::emitDynamicPoisonOnLoadedType):

2018-01-30  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227643. rdar://problem/37019367

    2018-01-24  Filip Pizlo  <fpizlo@apple.com>

            DirectArguments should protect itself using dynamic poisoning and precise index masking
            https://bugs.webkit.org/show_bug.cgi?id=182086

            Reviewed by Saam Barati.

            This implements dynamic poisoning and precise index masking in DirectArguments, using the
            helpers from <wtf/MathExtras.h> and helpers in AssemblyHelpers and FTL::LowerDFGToB3.

            We use dynamic poisoning for DirectArguments since this object did not have any additional
            indirection inside it that could have been poisoned. So, we use the xor of the expected type
            and the actual type as an additional input into the pointer.

            We use precise index masking for bounds checks, because it's not worth doing index masking
            unless we know that precise index masking is too slow.

            * assembler/MacroAssembler.h:
            (JSC::MacroAssembler::lshiftPtr):
            (JSC::MacroAssembler::rshiftPtr):
            * dfg/DFGSpeculativeJIT.cpp:
            (JSC::DFG::SpeculativeJIT::compileGetByValOnDirectArguments):
            * ftl/FTLLowerDFGToB3.cpp:
            (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
            (JSC::FTL::DFG::LowerDFGToB3::compileGetMyArgumentByVal):
            (JSC::FTL::DFG::LowerDFGToB3::preciseIndexMask64):
            (JSC::FTL::DFG::LowerDFGToB3::preciseIndexMask32):
            (JSC::FTL::DFG::LowerDFGToB3::dynamicPoison):
            (JSC::FTL::DFG::LowerDFGToB3::dynamicPoisonOnLoadedType):
            (JSC::FTL::DFG::LowerDFGToB3::dynamicPoisonOnType):
            * jit/AssemblyHelpers.cpp:
            (JSC::AssemblyHelpers::emitPreciseIndexMask32):
            (JSC::AssemblyHelpers::emitDynamicPoison):
            (JSC::AssemblyHelpers::emitDynamicPoisonOnLoadedType):
            (JSC::AssemblyHelpers::emitDynamicPoisonOnType):
            * jit/AssemblyHelpers.h:
            * jit/JITPropertyAccess.cpp:
            (JSC::JIT::emitDirectArgumentsGetByVal):
            * runtime/DirectArguments.h:
            (JSC::DirectArguments::getIndexQuickly const):
            (JSC::DirectArguments::setIndexQuickly):
            (JSC::DirectArguments::argument):
            * runtime/GenericArgumentsInlines.h:

2018-01-30  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227636. rdar://problem/37019363

    2018-01-25  Mark Lam  <mark.lam@apple.com>

            Rename some local vars from type to typedArrayType for greater clarity.
            https://bugs.webkit.org/show_bug.cgi?id=182148
            <rdar://problem/36882310>

            Reviewed by Saam Barati.

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

2018-01-25  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227435. rdar://problem/36873349

    2018-01-23  Robin Morisset  <rmorisset@apple.com>

            Rollout r219636
            https://bugs.webkit.org/show_bug.cgi?id=181997
            <rdar://problem/35883022>

            Unreviewed, as it is a rollout.

            * dfg/DFGSpeculativeJIT.cpp:
            (JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
            * runtime/JSArray.cpp:
            (JSC::JSArray::tryCreateUninitializedRestricted):
            * runtime/JSArray.h:
            (JSC::JSArray::tryCreate):
            * runtime/JSObject.cpp:
            (JSC::JSObject::ensureLengthSlow):

2018-01-25  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227410. rdar://problem/36873404

    2018-01-23  Robin Morisset  <rmorisset@apple.com>

            Update the argument count in DFGByteCodeParser::handleRecursiveCall
            https://bugs.webkit.org/show_bug.cgi?id=181739
            <rdar://problem/36627662>

            Reviewed by Saam Barati.

            When calling a function, its number of arguments is set on the stack. When we turn a recursive tail call
            into a jump, we should update that stack slot as there is no guarantee that the function was originally
            called with the same number of arguments. Forgetting to do this is observable through 'arguments.length'.

            It required adding a new DFG node: 'SetArgumentCountIncludingThis', that takes an unsigned int
            as its first OpInfo field, and stores it to the stack at the right place.

            We must be a bit careful in where we put this new node, as it ClobbersExit.
            We must also fix DFGArgumentsEliminationPhase and DFGPutStackSinkingPhase as they assumed that any node that writes to the stack must write to either an argument or a local.

            * dfg/DFGAbstractInterpreterInlines.h:
            (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
            * dfg/DFGArgumentsEliminationPhase.cpp:
            * dfg/DFGByteCodeParser.cpp:
            (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
            * dfg/DFGClobberize.h:
            (JSC::DFG::clobberize):
            * dfg/DFGDoesGC.cpp:
            (JSC::DFG::doesGC):
            * dfg/DFGFixupPhase.cpp:
            (JSC::DFG::FixupPhase::fixupNode):
            * dfg/DFGMayExit.cpp:
            * dfg/DFGNode.h:
            (JSC::DFG::Node::argumentCountIncludingThis):
            * dfg/DFGNodeType.h:
            * dfg/DFGPredictionPropagationPhase.cpp:
            * dfg/DFGPutStackSinkingPhase.cpp:
            * dfg/DFGSafeToExecute.h:
            (JSC::DFG::safeToExecute):
            * dfg/DFGSpeculativeJIT.cpp:
            (JSC::DFG::SpeculativeJIT::compileSetArgumentCountIncludingThis):
            * dfg/DFGSpeculativeJIT.h:
            * dfg/DFGSpeculativeJIT32_64.cpp:
            (JSC::DFG::SpeculativeJIT::compile):
            * dfg/DFGSpeculativeJIT64.cpp:
            (JSC::DFG::SpeculativeJIT::compile):
            * ftl/FTLCapabilities.cpp:
            (JSC::FTL::canCompile):
            * ftl/FTLLowerDFGToB3.cpp:
            (JSC::FTL::DFG::LowerDFGToB3::compileNode):
            (JSC::FTL::DFG::LowerDFGToB3::compileSetArgumentCountIncludingThis):

2018-01-24  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227527. rdar://problem/36830339

    2018-01-23  Mark Lam  <mark.lam@apple.com>

            Update Poisoned pointers to take a Poison class instead of a uintptr_t&.
            https://bugs.webkit.org/show_bug.cgi?id=182017
            <rdar://problem/36795513>

            Reviewed by Filip Pizlo and JF Bastien.

            Removed the POISON() macro.  Now that we have Poison types, we can just use the
            the Poison type instead and make the code a bit nicer to read.

            * API/JSAPIWrapperObject.h:
            * API/JSCallbackFunction.h:
            * API/JSCallbackObject.h:
            * b3/B3LowerMacros.cpp:
            * b3/testb3.cpp:
            (JSC::B3::testInterpreter):
            * bytecode/CodeBlock.h:
            (JSC::CodeBlock::instructions):
            (JSC::CodeBlock::instructions const):
            * dfg/DFGOSRExitCompilerCommon.h:
            (JSC::DFG::adjustFrameAndStackInOSRExitCompilerThunk):
            * dfg/DFGSpeculativeJIT.cpp:
            (JSC::DFG::SpeculativeJIT::compileCheckSubClass):
            (JSC::DFG::SpeculativeJIT::emitSwitchIntJump):
            * ftl/FTLLowerDFGToB3.cpp:
            (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass):
            * jit/JIT.h:
            * jit/ThunkGenerators.cpp:
            (JSC::virtualThunkFor):
            (JSC::nativeForGenerator):
            (JSC::boundThisNoArgsFunctionCallGenerator):
            * parser/UnlinkedSourceCode.h:
            * runtime/ArrayPrototype.h:
            * runtime/CustomGetterSetter.h:
            * runtime/DateInstance.h:
            * runtime/InternalFunction.h:
            * runtime/JSArrayBuffer.h:
            * runtime/JSCPoison.cpp:
            (JSC::initializePoison):
            * runtime/JSCPoison.h:
            * runtime/JSGlobalObject.h:
            * runtime/JSScriptFetchParameters.h:
            * runtime/JSScriptFetcher.h:
            * runtime/NativeExecutable.h:
            * runtime/StructureTransitionTable.h:
            * runtime/WriteBarrier.h:
            (JSC::WriteBarrier::poison): Deleted.
            * wasm/js/JSToWasm.cpp:
            (JSC::Wasm::createJSToWasmWrapper):
            * wasm/js/JSWebAssemblyCodeBlock.cpp:
            (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock):
            * wasm/js/JSWebAssemblyCodeBlock.h:
            * wasm/js/JSWebAssemblyInstance.h:
            (JSC::JSWebAssemblyInstance::poison):
            * wasm/js/JSWebAssemblyMemory.h:
            * wasm/js/JSWebAssemblyModule.h:
            * wasm/js/JSWebAssemblyTable.h:
            * wasm/js/WasmToJS.cpp:
            (JSC::Wasm::handleBadI64Use):
            (JSC::Wasm::wasmToJS):
            * wasm/js/WebAssemblyFunctionBase.h:
            * wasm/js/WebAssemblyModuleRecord.h:
            * wasm/js/WebAssemblyToJSCallee.h:
            * wasm/js/WebAssemblyWrapperFunction.h:

2018-01-23  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227462. rdar://problem/36807140

    2018-01-23  Filip Pizlo  <fpizlo@apple.com>

            Use precise index masking for FTL GetByArgumentByVal
            https://bugs.webkit.org/show_bug.cgi?id=182006

            Reviewed by Keith Miller.

            This protects speculative out-of-bounds on arguments[index].

            Making this work right involved fixing a possible overflow situation with
            numberOfArgumentsToSkip.

            * dfg/DFGByteCodeParser.cpp:
            (JSC::DFG::ByteCodeParser::findArgumentPositionForLocal):
            * dfg/DFGGraph.cpp:
            (JSC::DFG::Graph::dump):
            * dfg/DFGNode.h:
            (JSC::DFG::Node::hasNumberOfArgumentsToSkip):
            (JSC::DFG::Node::numberOfArgumentsToSkip):
            * dfg/DFGStackLayoutPhase.cpp:
            (JSC::DFG::StackLayoutPhase::run):
            * ftl/FTLLowerDFGToB3.cpp:
            (JSC::FTL::DFG::LowerDFGToB3::compileGetMyArgumentByVal):

2018-01-23  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227434. rdar://problem/36791632

    2018-01-23  Mark Lam  <mark.lam@apple.com>

            Re-arrange TypedArray JSTypes to match the order of the TypedArrayType enum list.
            https://bugs.webkit.org/show_bug.cgi?id=181976
            <rdar://problem/36766936>

            Reviewed by Filip Pizlo.

            1. The order of TypedArray JSTypes now matches the order the TypedArrayType enum
               list.  I also added static asserts in TypedArrayType.h to enforce this.

               Also redefined FOR_EACH_TYPED_ARRAY_TYPE() in terms of

            2. Define 4 new values:
               a. FirstTypedArrayType
               b. LastTypedArrayType
               c. NumberOfTypedArrayTypesExcludingDataView
               d. NumberOfTypedArrayTypes

               Use these everywhere where we iterate or bisect the TypedArray JSTypes.

            3. Removed NUMBER_OF_TYPED_ARRAY_TYPES, and use NumberOfTypedArrayTypes instead.

            4. Simplify the code that converts between TypedArrayType and JSType.

               Changed typedArrayTypeForType() to be the mirror image of typeForTypedArrayType().
               Previously, typedArrayTypeForType() converts DataViewType to NotTypedArray
               instead of TypeDataView.  Now, it converts to TypeDataView.

               This does not result in any change of behavior because typedArrayTypeForType()
               is only called in Structure::hasIndexingHeader(), and its result is passed to
               isTypedView(), which handles TypeDataView correctly.

            5. Also fixed a bug in SpeculativeJIT::compileGetTypedArrayByteOffset().
               If the vector is null, we can skip the rest of the checks.  While the current
               code does not result in incorrect behavior, it is inefficient, and communicates
               wrong information to the reader i.e. implying that there's something in the
               dataGPR when there's not.  The dataGPR should also be null in this case.

            * dfg/DFGByteCodeParser.cpp:
            (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
            * dfg/DFGSpeculativeJIT.cpp:
            (JSC::DFG::SpeculativeJIT::compileIsTypedArrayView):
            (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
            * ftl/FTLLowerDFGToB3.cpp:
            (JSC::FTL::DFG::LowerDFGToB3::isTypedArrayView):
            * ftl/FTLOSRExit.cpp:
            * llint/LowLevelInterpreter.asm:
            * llint/LowLevelInterpreter64.asm:
            * runtime/JSGlobalObject.cpp:
            (JSC::JSGlobalObject::visitChildren):
            * runtime/JSType.h:
            * runtime/TypedArrayType.cpp:
            (JSC::typeForTypedArrayType): Deleted.
            * runtime/TypedArrayType.h:
            (JSC::typedArrayTypeForType):
            (JSC::typeForTypedArrayType):

2018-01-23  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227431. rdar://problem/36791656

    2018-01-23  Filip Pizlo  <fpizlo@apple.com>

            DFG should always flush `this`
            https://bugs.webkit.org/show_bug.cgi?id=181999

            Reviewed by Saam Barati and Mark Lam.

            This is going to make it possible to use precise index masking for arguments-on-the-stack
            accesses with an index adjusted so that 0 is this. Without this change, we would have no way
            of masking when the argument count is 0, unless we padded the argument area so that there was
            always an argument slot after `this` and it was always initialized.

            This is neutral on all benchmarks.

            * dfg/DFGByteCodeParser.cpp:
            (JSC::DFG::ByteCodeParser::flushImpl):
            (JSC::DFG::ByteCodeParser::flushForTerminalImpl):
            (JSC::DFG::ByteCodeParser::flush):
            (JSC::DFG::ByteCodeParser::flushForTerminal):
            (JSC::DFG::ByteCodeParser::parse):
            (JSC::DFG::flushImpl): Deleted.
            (JSC::DFG::flushForTerminalImpl): Deleted.
            * dfg/DFGPreciseLocalClobberize.h:
            (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):

2018-01-23  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227424. rdar://problem/36791625

    2018-01-23  Filip Pizlo  <fpizlo@apple.com>

            JSC should use a speculation fence on VM entry/exit
            https://bugs.webkit.org/show_bug.cgi?id=181991

            Reviewed by JF Bastien and Mark Lam.

            This adds a WTF::speculationFence on VM entry and exit.

            For a microbenchmark that just calls a native function (supplied via an Objective-C block) in a
            tight loop from JS is a 0% regression on x86 and a 11% regression on ARM64.

            * runtime/JSLock.cpp:
            (JSC::JSLock::didAcquireLock):
            (JSC::JSLock::willReleaseLock):

2018-01-22  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227341. rdar://problem/36746038

    2018-01-22  Michael Saboff  <msaboff@apple.com>

            DFG abstract interpreter needs to properly model effects of some Math ops
            https://bugs.webkit.org/show_bug.cgi?id=181886

            Reviewed by Saam Barati.

            Reviewed the processing of the various ArithXXX and CompareXXX and found that
            several nodes don't handle UntypedUse.  Added clobberWorld() for those cases.

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

2018-01-22  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227236. rdar://problem/36722544

    2018-01-19  Saam Barati  <sbarati@apple.com>

            Kill ArithNegate's ArithProfile assert inside BytecodeParser
            https://bugs.webkit.org/show_bug.cgi?id=181877
            <rdar://problem/36630552>

            Reviewed by Mark Lam.

            Before this patch, we used to assert that op_negate's result ArithProfile
            only produces number. It's logically true that negate only produces a number.
            However, the DFG may incorrectly pick this ArithProfile when doing OSR exit
            profiling. So we'll end up profiling something that's likely the input to
            negate. This patch removes the assert. We cede to the fact that Graph::methodOfGettingAValueProfileFor
            is entirely heuristic based, potentially leading to profiling results being imprecise.

            * dfg/DFGByteCodeParser.cpp:
            (JSC::DFG::ByteCodeParser::makeSafe):

2018-01-22  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227229. rdar://problem/36722641

    2018-01-19  Saam Barati  <sbarati@apple.com>

            Spread's effects are modeled incorrectly both in AI and in Clobberize
            https://bugs.webkit.org/show_bug.cgi?id=181867
            <rdar://problem/36290415>

            Reviewed by Michael Saboff.

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

2018-01-22  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227168. rdar://problem/36722591

    2018-01-18  JF Bastien  <jfbastien@apple.com>

            Set the minimum executable allocator size properly
            https://bugs.webkit.org/show_bug.cgi?id=181816
            <rdar://problem/36635533>

            Reviewed by Saam Barati.

            Executable allocator expects at least two page size's worth of
            allocation in certain conditions, and that causes some tests to
            now fail because they ask for less. Set that minimum correctly. We
            were already rounding up to a page size, so having a minimum of 2
            page sizes is fine.

            * jit/ExecutableAllocator.cpp:
            (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator):

2018-01-22  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227159. rdar://problem/36722618

    2018-01-18  Mark Lam  <mark.lam@apple.com>

            Poisons should be initialized after Options are initialized.
            https://bugs.webkit.org/show_bug.cgi?id=181807
            <rdar://problem/36629138>

            Reviewed by Keith Miller.

            This is because poison initialization may depend on options.

            * runtime/InitializeThreading.cpp:
            (JSC::initializeThreading):

2018-01-22  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227136. rdar://problem/36722486

    2018-01-18  Commit Queue  <commit-queue@webkit.org>

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

            "it caused a 15% octane regression" (Requested by saamyjoon on
            #webkit).

            Reverted changeset:

            "Support MultiGetByOffset in the DFG"
            https://bugs.webkit.org/show_bug.cgi?id=181466
            https://trac.webkit.org/changeset/227096

2018-01-18  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r226956. rdar://problem/36598688

    2018-01-15  JF Bastien  <jfbastien@apple.com>

            Remove makePoisonedUnique
            https://bugs.webkit.org/show_bug.cgi?id=181630
            <rdar://problem/36498623>

            Reviewed by Mark Lam.

            I added a conversion from std::unique_ptr, so we can just use
            std::make_unique and it'll auto-poison when converted.

            * bytecode/CodeBlock.h:
            (JSC::CodeBlock::makePoisonedUnique): Deleted.
            * runtime/JSGlobalObject.cpp:
            (JSC::JSGlobalObject::init):
            * runtime/JSGlobalObject.h:
            (JSC::JSGlobalObject::makePoisonedUnique): Deleted.

2018-01-18  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227165. rdar://problem/36628552

    2018-01-18  Michael Saboff  <msaboff@apple.com>

            Unreviewed build fix for Windows

            * interpreter/FrameTracers.h:
            (JSC::assertStackPointerIsAligned): Can't use gcc style inlined assembly
            on Windows.

2018-01-18  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227152. rdar://problem/36628552

    2018-01-18  Michael Saboff  <msaboff@apple.com>

            REGRESSION (r226068): [X86] Crash in JavaScriptCore ShadowChicken when handling exceptions
            https://bugs.webkit.org/show_bug.cgi?id=181802

            Reviewed by Filip Pizlo.

            There where a few places where the stack isn't properly aligned for X86 when we call into C++ code.
            Two places are where we call into exception handling code, the LLInt and from nativeForGenerator.
            The other place was when we call into the operationOSRWriteBarrier().

            Added an assert check that the stack is aligned on X86 platforms in the native call tracing code.
            This helped find the other cases beyond the original problem.

            * dfg/DFGOSRExitCompilerCommon.cpp:
            (JSC::DFG::osrWriteBarrier):
            * interpreter/FrameTracers.h:
            (JSC::assertStackPointerIsAligned):
            (JSC::NativeCallFrameTracer::NativeCallFrameTracer):
            (JSC::NativeCallFrameTracerWithRestore::NativeCallFrameTracerWithRestore):
            * jit/ThunkGenerators.cpp:
            (JSC::nativeForGenerator):
            * llint/LowLevelInterpreter32_64.asm:

2018-01-17  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227104. rdar://problem/36609536

    2018-01-17  Saam Barati  <sbarati@apple.com>

            Disable Atomics when SharedArrayBuffer isn’t enabled
            https://bugs.webkit.org/show_bug.cgi?id=181572
            <rdar://problem/36553206>

            Reviewed by Michael Saboff.

            * runtime/JSGlobalObject.cpp:
            (JSC::JSGlobalObject::init):
            (JSC::createAtomicsProperty): Deleted.

2018-01-17  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227096. rdar://problem/36609546

    2018-01-17  Saam Barati  <sbarati@apple.com>

            Support MultiGetByOffset in the DFG
            https://bugs.webkit.org/show_bug.cgi?id=181466

            Reviewed by Keith Miller.

            This seems to benefit Speedometer in my local testing. It seems like this
            might be around a 0.5% improvement.

            * dfg/DFGAbstractInterpreterInlines.h:
            (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
            * dfg/DFGByteCodeParser.cpp:
            (JSC::DFG::ByteCodeParser::handleGetById):
            * dfg/DFGConstantFoldingPhase.cpp:
            (JSC::DFG::ConstantFoldingPhase::foldConstants):
            * dfg/DFGGraph.h:
            (JSC::DFG::Graph::supportsMultiGetByOffset):
            * dfg/DFGSpeculativeJIT64.cpp:
            (JSC::DFG::SpeculativeJIT::compile):

2018-01-17  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227053. rdar://problem/36587231

    2018-01-17  Saam Barati  <sbarati@apple.com>

            DFG::Node::convertToConstant needs to clear the varargs flags
            https://bugs.webkit.org/show_bug.cgi?id=181697
            <rdar://problem/36497332>

            Reviewed by Yusuke Suzuki.

            * dfg/DFGNode.h:
            (JSC::DFG::Node::convertToConstant):

2018-01-17  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r227047. rdar://problem/36587246

    2018-01-16  JF Bastien  <jfbastien@apple.com>

            Allow dangerous disabling of poison
            https://bugs.webkit.org/show_bug.cgi?id=181685
            <rdar://problem/36546265>

            Reviewed by Keith Miller.

            Some tools such as leak detectors and such like to look at real
            pointers, and poisoned ones confuse them. Add a JSC option to
            disable poisoning, but log to the console when this is done.

            * runtime/JSCPoison.cpp:
            (JSC::initializePoison):
            * runtime/Options.h:

2018-01-17  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r226940. rdar://problem/36598019

    2018-01-13  Mark Lam  <mark.lam@apple.com>

            Replace all use of ConstExprPoisoned with Poisoned.
            https://bugs.webkit.org/show_bug.cgi?id=181542
            <rdar://problem/36442138>

            Reviewed by JF Bastien.

            1. All JSC poisons are now defined in JSCPoison.h.

            2. Change all clients to use the new poison values via the POISON() macro.

            3. The LLInt code has been updated to handle CodeBlock poison.  Some of this code
               uses the t5 temp register, which is not available on the Windows port.
               Fortunately, we don't currently do poisoning on the Windows port yet.  So,
               it will just work for now.

               When poisoning is enabled for the Windows port, this LLInt code will need a
               Windows specific implementation to workaround its lack of a t5 register.

            * API/JSAPIWrapperObject.h:
            * API/JSCallbackFunction.h:
            * API/JSCallbackObject.h:
            * JavaScriptCore.xcodeproj/project.pbxproj:
            * Sources.txt:
            * assembler/MacroAssemblerCodeRef.h:
            (JSC::MacroAssemblerCodePtr::emptyValue):
            (JSC::MacroAssemblerCodePtr::deletedValue):
            * b3/B3LowerMacros.cpp:
            * b3/testb3.cpp:
            (JSC::B3::testInterpreter):
            * bytecode/CodeBlock.h:
            (JSC::CodeBlock::instructions):
            (JSC::CodeBlock::instructions const):
            (JSC::CodeBlock::makePoisonedUnique):
            * dfg/DFGOSRExitCompilerCommon.h:
            (JSC::DFG::adjustFrameAndStackInOSRExitCompilerThunk):
            * dfg/DFGSpeculativeJIT.cpp:
            (JSC::DFG::SpeculativeJIT::compileCheckSubClass):
            (JSC::DFG::SpeculativeJIT::emitSwitchIntJump):
            * ftl/FTLLowerDFGToB3.cpp:
            (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass):
            * jit/JIT.h:
            * jit/ThunkGenerators.cpp:
            (JSC::virtualThunkFor):
            (JSC::nativeForGenerator):
            (JSC::boundThisNoArgsFunctionCallGenerator):
            * llint/LowLevelInterpreter.asm:
            * llint/LowLevelInterpreter32_64.asm:
            * llint/LowLevelInterpreter64.asm:
            * parser/UnlinkedSourceCode.h:
            * runtime/ArrayPrototype.h:
            * runtime/CustomGetterSetter.h:
            * runtime/DateInstance.h:
            * runtime/InternalFunction.h:
            * runtime/JSArrayBuffer.h:
            * runtime/JSCPoison.cpp: Copied from Source/JavaScriptCore/runtime/JSCPoisonedPtr.cpp.
            (JSC::initializePoison):
            * runtime/JSCPoison.h:
            (): Deleted.
            * runtime/JSCPoisonedPtr.cpp: Removed.
            * runtime/JSCPoisonedPtr.h: Removed.
            * runtime/JSGlobalObject.h:
            (JSC::JSGlobalObject::makePoisonedUnique):
            * runtime/JSScriptFetchParameters.h:
            * runtime/JSScriptFetcher.h:
            * runtime/NativeExecutable.h:
            * runtime/StructureTransitionTable.h:
            (JSC::StructureTransitionTable::map const):
            (JSC::StructureTransitionTable::weakImpl const):
            * runtime/WriteBarrier.h:
            (JSC::WriteBarrier::poison):
            * wasm/js/JSToWasm.cpp:
            (JSC::Wasm::createJSToWasmWrapper):
            * wasm/js/JSWebAssemblyCodeBlock.cpp:
            (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock):
            * wasm/js/JSWebAssemblyCodeBlock.h:
            * wasm/js/JSWebAssemblyInstance.h:
            * wasm/js/JSWebAssemblyMemory.h:
            * wasm/js/JSWebAssemblyModule.h:
            * wasm/js/JSWebAssemblyTable.h:
            * wasm/js/WasmToJS.cpp:
            (JSC::Wasm::handleBadI64Use):
            (JSC::Wasm::wasmToJS):
            * wasm/js/WebAssemblyFunctionBase.h:
            * wasm/js/WebAssemblyModuleRecord.h:
            * wasm/js/WebAssemblyToJSCallee.h:
            * wasm/js/WebAssemblyWrapperFunction.h:

2018-01-17  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r226752. rdar://problem/36601128

    2018-01-10  JF Bastien  <jfbastien@apple.com>

            Poison small JSObject derivatives which only contain pointers
            https://bugs.webkit.org/show_bug.cgi?id=181483
            <rdar://problem/36407127>

            Reviewed by Mark Lam.

            I wrote a script that finds interesting things to poison or
            generally harden. These stood out because they derive from
            JSObject and only contain a few pointer or pointer-like fields,
            and could therefore just be poisoned. This also requires some
            template "improvements" to our poisoning machinery. Worth noting
            is that I'm making PoisonedUniquePtr move-assignable and
            move-constructible from unique_ptr, which makes it a better
            drop-in replacement because we don't need to use
            makePoisonedUniquePtr. This means function-locals can be
            unique_ptr and get the nice RAII pattern, and once the function is
            done you can just move to the class' PoisonedUniquePtr without
            worrying.

            * API/JSAPIWrapperObject.h:
            (JSC::JSAPIWrapperObject::wrappedObject):
            * API/JSAPIWrapperObject.mm:
            (JSC::JSAPIWrapperObject::JSAPIWrapperObject):
            * API/JSCallbackObject.h:
            * runtime/ArrayPrototype.h:
            * runtime/DateInstance.h:
            * runtime/JSArrayBuffer.cpp:
            (JSC::JSArrayBuffer::finishCreation):
            (JSC::JSArrayBuffer::isShared const):
            (JSC::JSArrayBuffer::sharingMode const):
            * runtime/JSArrayBuffer.h:
            * runtime/JSCPoison.h:

2018-01-16  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r226942. rdar://problem/36567945

    2018-01-14  Saam Barati  <sbarati@apple.com>

            Unreviewed. r226928 broke the CLOOP build. This patch fixes the CLOOP build.

            * bytecode/CallLinkStatus.cpp:
            (JSC::CallLinkStatus::computeFromLLInt):
            (JSC::CallLinkStatus::computeExitSiteData):

2018-01-16  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r226928. rdar://problem/36567945

    2018-01-12  Saam Barati  <sbarati@apple.com>

            Move ExitProfile to UnlinkedCodeBlock so it can be shared amongst CodeBlocks backed by the same UnlinkedCodeBlock
            https://bugs.webkit.org/show_bug.cgi?id=181545

            Reviewed by Michael Saboff.

            This patch follows the theme of putting optimization profiling information on
            UnlinkedCodeBlock. This allows the unlinked code cache to remember OSR exit data.
            This often leads to the first compile of a CodeBlock, backed by an UnlinkedCodeBlock
            pulled from the code cache, making better compilation decisions, usually
            resulting in fewer exits, and fewer recompilations.

            This is a 1% Speedometer progression in my testing.

            * bytecode/BytecodeDumper.cpp:
            (JSC::BytecodeDumper<CodeBlock>::dumpProfilesForBytecodeOffset):
            * bytecode/CallLinkStatus.cpp:
            (JSC::CallLinkStatus::computeFromLLInt):
            (JSC::CallLinkStatus::computeFor):
            (JSC::CallLinkStatus::computeExitSiteData):
            (JSC::CallLinkStatus::computeDFGStatuses):
            * bytecode/CallLinkStatus.h:
            * bytecode/CodeBlock.h:
            (JSC::CodeBlock::addFrequentExitSite): Deleted.
            (JSC::CodeBlock::hasExitSite const): Deleted.
            (JSC::CodeBlock::exitProfile): Deleted.
            * bytecode/DFGExitProfile.cpp:
            (JSC::DFG::ExitProfile::add):
            (JSC::DFG::QueryableExitProfile::initialize):
            * bytecode/DFGExitProfile.h:
            (JSC::DFG::ExitProfile::hasExitSite const):
            * bytecode/GetByIdStatus.cpp:
            (JSC::GetByIdStatus::hasExitSite):
            (JSC::GetByIdStatus::computeFor):
            (JSC::GetByIdStatus::computeForStubInfo):
            * bytecode/GetByIdStatus.h:
            * bytecode/PutByIdStatus.cpp:
            (JSC::PutByIdStatus::hasExitSite):
            (JSC::PutByIdStatus::computeFor):
            (JSC::PutByIdStatus::computeForStubInfo):
            * bytecode/PutByIdStatus.h:
            * bytecode/UnlinkedCodeBlock.cpp:
            (JSC::UnlinkedCodeBlock::livenessAnalysisSlow):
            * bytecode/UnlinkedCodeBlock.h:
            (JSC::UnlinkedCodeBlock::hasExitSite const):
            (JSC::UnlinkedCodeBlock::hasExitSite):
            (JSC::UnlinkedCodeBlock::exitProfile):
            * dfg/DFGByteCodeParser.cpp:
            (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
            * dfg/DFGGraph.h:
            (JSC::DFG::Graph::hasGlobalExitSite):
            (JSC::DFG::Graph::hasExitSite):
            * dfg/DFGLICMPhase.cpp:
            (JSC::DFG::LICMPhase::attemptHoist):
            * dfg/DFGOSRExitBase.cpp:
            (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSiteSlow):

2018-01-16  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r226920. rdar://problem/36567951

    2018-01-12  JF Bastien  <jfbastien@apple.com>

            PoisonedWriteBarrier
            https://bugs.webkit.org/show_bug.cgi?id=181599
            <rdar://problem/36474351>

            Reviewed by Mark Lam.

            Allow poisoning of WriteBarrier objects, and use this for
            WebAssembly because it is perf-neutral, at least on WasmBench on
            my MBP. If it indeed is perf-neutral according to the bots, start
            using it in more performance-sensitive places.

            * heap/HandleTypes.h:
            * heap/SlotVisitor.h:
            * heap/SlotVisitorInlines.h:
            (JSC::SlotVisitor::append):
            (JSC::SlotVisitor::appendHidden):
            * runtime/JSCJSValue.h:
            * runtime/JSCPoison.h:
            * runtime/Structure.h:
            * runtime/StructureInlines.h:
            (JSC::Structure::setPrototypeWithoutTransition):
            (JSC::Structure::setGlobalObject):
            (JSC::Structure::setPreviousID):
            * runtime/WriteBarrier.h:
            (JSC::WriteBarrierBase::copyFrom):
            (JSC::WriteBarrierBase::get const):
            (JSC::WriteBarrierBase::operator* const):
            (JSC::WriteBarrierBase::operator-> const):
            (JSC::WriteBarrierBase::clear):
            (JSC::WriteBarrierBase::slot):
            (JSC::WriteBarrierBase::operator bool const):
            (JSC::WriteBarrierBase::setWithoutWriteBarrier):
            (JSC::WriteBarrierBase::unvalidatedGet const):
            (JSC::operator==):
            * runtime/WriteBarrierInlines.h:
            (JSC::Traits>::set):
            (JSC::Traits>::setMayBeNull):
            (JSC::Traits>::setEarlyValue):
            (JSC::DumbValueTraits<Unknown>>::set):
            * wasm/WasmInstance.h:
            * wasm/js/JSWebAssemblyInstance.cpp:
            (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
            (JSC::JSWebAssemblyInstance::finishCreation):
            (JSC::JSWebAssemblyInstance::visitChildren):
            (JSC::JSWebAssemblyInstance::create):
            * wasm/js/JSWebAssemblyInstance.h:
            (JSC::JSWebAssemblyInstance::offsetOfPoisonedCallee):
            * 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:

2018-01-16  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r226907. rdar://problem/36567949

    2018-01-12  Saam Barati  <sbarati@apple.com>

            CheckStructure can be incorrectly subsumed by CheckStructureOrEmpty
            https://bugs.webkit.org/show_bug.cgi?id=181177
            <rdar://problem/36205704>

            Reviewed by Yusuke Suzuki.

            The semantics of CheckStructure are such that it does not allow the empty value to flow through it.
            However, we may eliminate a CheckStructure if it's preceded by a CheckStructureOrEmpty. This doesn't
            have semantic consequences when validation is turned off. However, with validation on, this trips up
            our OSR exit machinery that says when an exit is allowed to happen.

            Consider the following IR:

            a: GetClosureVar // Or any other node that produces BytecodeTop
            ...
            c: CheckStructure(Cell:@a, {s2})
            d: PutByOffset(KnownCell:@a, KnownCell:@a, @value)

            In the TypeCheckHoistingPhase, we may insert CheckStructureOrEmptys like this:
            a: GetClosureVar
            e: CheckStructureOrEmpty(@a, {s1})
            ...
            f: CheckStructureOrEmpty(@a, {s2})
            c: CheckStructure(Cell:@a, {s2})
            d: PutByOffset(KnownCell:@a, KnownCell:@a, @value)

            This will cause constant folding to change the IR to:
            a: GetClosureVar
            e: CheckStructureOrEmpty(@a, {s1})
            ...
            f: CheckStructureOrEmpty(@a, {s2})
            d: PutByOffset(KnownCell:@a, KnownCell:@a, @value)

            Our mayExit analysis determines that the PutByOffset should not exit. Note
            that AI will determine the only value the PutByOffset can see in @a is
            the empty value. Because KnownCell filters SpecCell and not SpecCellCheck,
            when lowering the PutByOffset, we reach a contradiction in AI and emit
            an OSR exit. However, because mayExit said we couldn't exit, we assert.

            Note that if we did not run the TypeCheckHoistingPhase on this IR, AI
            would have determined we would OSR exit at the second CheckStructure.

            This patch makes it so constant folding produces the following IR:
            a: GetClosureVar
            e: CheckStructureOrEmpty(@a, {s1})
            g: AssertNotEmpty(@a)
            ...
            f: CheckStructureOrEmpty(@a, {s2})
            h: AssertNotEmpty(@a)
            d: PutByOffset(KnownCell:@a, KnownCell:@a, @value)

            This modification will cause AI to know we will OSR exit before even reaching
            the PutByOffset. Note that in the original IR, the GetClosureVar won't
            actually produce the TDZ value. If it did, bytecode would have caused us
            to emit a CheckNotEmpty before the CheckStructure/PutByOffset combo. That's
            why this bug is about IR bookkeeping and not an actual error in IR analysis.
            This patch introduces AssertNotEmpty instead of using CheckNotEmpty to be
            more congruous with CheckStructure's semantics of crashing on the empty value
            as input (on 64 bit platforms).

            * dfg/DFGAbstractInterpreterInlines.h:
            (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
            * dfg/DFGClobberize.h:
            (JSC::DFG::clobberize):
            * dfg/DFGConstantFoldingPhase.cpp:
            (JSC::DFG::ConstantFoldingPhase::foldConstants):
            * dfg/DFGDoesGC.cpp:
            (JSC::DFG::doesGC):
            * dfg/DFGFixupPhase.cpp:
            (JSC::DFG::FixupPhase::fixupNode):
            * dfg/DFGNodeType.h:
            * dfg/DFGPredictionPropagationPhase.cpp:
            * dfg/DFGSafeToExecute.h:
            (JSC::DFG::safeToExecute):
            * dfg/DFGSpeculativeJIT32_64.cpp:
            (JSC::DFG::SpeculativeJIT::compile):
            * dfg/DFGSpeculativeJIT64.cpp:
            (JSC::DFG::SpeculativeJIT::compile):
            * ftl/FTLCapabilities.cpp:
            (JSC::FTL::canCompile):
            * ftl/FTLLowerDFGToB3.cpp:
            (JSC::FTL::DFG::LowerDFGToB3::compileNode):
            (JSC::FTL::DFG::LowerDFGToB3::compileAssertNotEmpty):

2018-01-16  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r226895. rdar://problem/36568085

    2018-01-12  Joseph Pecoraro  <pecoraro@apple.com>

            Web Inspector: Remove unnecessary raw pointer in InspectorConsoleAgent
            https://bugs.webkit.org/show_bug.cgi?id=181579
            <rdar://problem/36193759>

            Reviewed by Brian Burg.

            * inspector/agents/InspectorConsoleAgent.h:
            * inspector/agents/InspectorConsoleAgent.cpp:
            (Inspector::InspectorConsoleAgent::clearMessages):
            (Inspector::InspectorConsoleAgent::addConsoleMessage):
            Switch from a raw pointer to m_consoleMessages.last().
            Also move the expiration check into the if block since it can only
            happen inside here when the number of console messages changes.

            (Inspector::InspectorConsoleAgent::discardValues):
            Also clear the expired message count when messages are cleared.

2018-01-16  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r226881. rdar://problem/36567948

    2018-01-12  Saam Barati  <sbarati@apple.com>

            Each variant of a polymorphic inlined call should be exitOK at the top of the block
            https://bugs.webkit.org/show_bug.cgi?id=181562
            <rdar://problem/36445624>

            Reviewed by Yusuke Suzuki.

            Before this patch, the very first block in the switch for polymorphic call
            inlining will have exitOK at the top. The others are not guaranteed to.
            That was just a bug. They're all exitOK at the top. This will lead to crashes
            in FixupPhase because we won't have a node in a block that has ExitOK, so
            when we fixup various type checks, we assert out.

            * dfg/DFGByteCodeParser.cpp:
            (JSC::DFG::ByteCodeParser::handleInlining):

2018-01-16  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r226806. rdar://problem/36567946

    2018-01-11  Saam Barati  <sbarati@apple.com>

            JITMathIC code in the FTL is wrong when code gets duplicated
            https://bugs.webkit.org/show_bug.cgi?id=181525
            <rdar://problem/36351993>

            Reviewed by Michael Saboff and Keith Miller.

            B3/Air may duplicate code for various reasons. Patchpoint generators inside
            FTLLower must be aware that they can be called multiple times because of this.
            The patchpoint for math ICs was not aware of this, and shared state amongst
            all invocations of the patchpoint's generator. This patch fixes this bug so
            that each invocation of the patchpoint's generator gets a unique math IC.

            * bytecode/CodeBlock.h:
            (JSC::CodeBlock::addMathIC):
            * ftl/FTLLowerDFGToB3.cpp:
            (JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
            (JSC::FTL::DFG::LowerDFGToB3::compileUnaryMathIC):
            (JSC::FTL::DFG::LowerDFGToB3::compileBinaryMathIC):
            (JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub):
            (JSC::FTL::DFG::LowerDFGToB3::compileArithMul):
            (JSC::FTL::DFG::LowerDFGToB3::compileArithNegate):
            (JSC::FTL::DFG::LowerDFGToB3::compileMathIC): Deleted.
            * jit/JITMathIC.h:
            (JSC::isProfileEmpty):

2018-01-12  Jason Marcell  <jmarcell@apple.com>

        Apply patch. rdar://problem/36303061

    Disable WebKit features we don't want to ship after branching
    <rdar://problem/36303061>

    2018-01-12  Maciej Stachowiak  <mjs@apple.com>

            Disable WebKit features we don't want to ship after branching
            <rdar://problem/36303061>

            Reviewed by Maciej Stachowiak.

            * Configurations/FeatureDefines.xcconfig:

2018-01-12  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r226840. rdar://problem/36479468

    2018-01-11  Michael Saboff  <msaboff@apple.com>

            REGRESSION(226788): AppStore Crashed @ JavaScriptCore: JSC::MacroAssemblerARM64::pushToSaveImmediateWithoutTouchingRegisters
            https://bugs.webkit.org/show_bug.cgi?id=181570

            Reviewed by Keith Miller.

            * assembler/MacroAssemblerARM64.h:
            (JSC::MacroAssemblerARM64::abortWithReason):
            Reverting these functions to use dataTempRegister and memoryTempRegister as they are
            JIT release asserts that will crash the program.

            (JSC::MacroAssemblerARM64::pushToSaveImmediateWithoutTouchingRegisters):
            Changed this so that it invalidates any cached dataTmpRegister contents if temp register
            caching is enabled.

2018-01-12  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r226822. rdar://problem/36458924

    2018-01-11  Filip Pizlo  <fpizlo@apple.com>

            Rename MarkedAllocator to BlockDirectory and AllocatorAttributes to CellAttributes
            https://bugs.webkit.org/show_bug.cgi?id=181543

            Rubber stamped by Michael Saboff.

            In a world that has thread-local caches, the thing we now call the "MarkedAllocator" doesn't
            really have anything to do with allocation anymore. The allocation will be done by something
            in the TLC. When you move the allocation logic out of MarkedAllocator, it becomes just a
            place to find blocks (a "block directory").

            Once we do that renaming, the term "allocator attributes" becomes weird. Those are really the
            attributes of the HeapCellType. So let's call them CellAttributes.

            * JavaScriptCore.xcodeproj/project.pbxproj:
            * Sources.txt:
            * bytecode/AccessCase.cpp:
            (JSC::AccessCase::generateImpl):
            * bytecode/ObjectAllocationProfile.h:
            * bytecode/ObjectAllocationProfileInlines.h:
            (JSC::ObjectAllocationProfile::initializeProfile):
            * dfg/DFGSpeculativeJIT.cpp:
            (JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
            (JSC::DFG::SpeculativeJIT::compileMakeRope):
            (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
            (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
            (JSC::DFG::SpeculativeJIT::compileNewObject):
            * dfg/DFGSpeculativeJIT.h:
            (JSC::DFG::SpeculativeJIT::emitAllocateJSCell):
            (JSC::DFG::SpeculativeJIT::emitAllocateJSObject):
            * ftl/FTLAbstractHeapRepository.h:
            * ftl/FTLLowerDFGToB3.cpp:
            (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
            (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
            (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorageWithSizeImpl):
            (JSC::FTL::DFG::LowerDFGToB3::allocateHeapCell):
            (JSC::FTL::DFG::LowerDFGToB3::allocateObject):
            (JSC::FTL::DFG::LowerDFGToB3::allocatorForSize):
            * heap/AlignedMemoryAllocator.cpp:
            (JSC::AlignedMemoryAllocator::registerDirectory):
            (JSC::AlignedMemoryAllocator::registerAllocator): Deleted.
            * heap/AlignedMemoryAllocator.h:
            (JSC::AlignedMemoryAllocator::firstDirectory const):
            (JSC::AlignedMemoryAllocator::firstAllocator const): Deleted.
            * heap/AllocatorAttributes.cpp: Removed.
            * heap/AllocatorAttributes.h: Removed.
            * heap/BlockDirectory.cpp: Copied from Source/JavaScriptCore/heap/MarkedAllocator.cpp.
            (JSC::BlockDirectory::BlockDirectory):
            (JSC::BlockDirectory::setSubspace):
            (JSC::BlockDirectory::isPagedOut):
            (JSC::BlockDirectory::findEmptyBlockToSteal):
            (JSC::BlockDirectory::didConsumeFreeList):
            (JSC::BlockDirectory::tryAllocateWithoutCollecting):
            (JSC::BlockDirectory::allocateIn):
            (JSC::BlockDirectory::tryAllocateIn):
            (JSC::BlockDirectory::doTestCollectionsIfNeeded):
            (JSC::BlockDirectory::allocateSlowCase):
            (JSC::BlockDirectory::blockSizeForBytes):
            (JSC::BlockDirectory::tryAllocateBlock):
            (JSC::BlockDirectory::addBlock):
            (JSC::BlockDirectory::removeBlock):
            (JSC::BlockDirectory::stopAllocating):
            (JSC::BlockDirectory::prepareForAllocation):
            (JSC::BlockDirectory::lastChanceToFinalize):
            (JSC::BlockDirectory::resumeAllocating):
            (JSC::BlockDirectory::beginMarkingForFullCollection):
            (JSC::BlockDirectory::endMarking):
            (JSC::BlockDirectory::snapshotUnsweptForEdenCollection):
            (JSC::BlockDirectory::snapshotUnsweptForFullCollection):
            (JSC::BlockDirectory::findBlockToSweep):
            (JSC::BlockDirectory::sweep):
            (JSC::BlockDirectory::shrink):
            (JSC::BlockDirectory::assertNoUnswept):
            (JSC::BlockDirectory::parallelNotEmptyBlockSource):
            (JSC::BlockDirectory::dump const):
            (JSC::BlockDirectory::dumpBits):
            (JSC::BlockDirectory::markedSpace const):
            (JSC::MarkedAllocator::MarkedAllocator): Deleted.
            (JSC::MarkedAllocator::setSubspace): Deleted.
            (JSC::MarkedAllocator::isPagedOut): Deleted.
            (JSC::MarkedAllocator::findEmptyBlockToSteal): Deleted.
            (JSC::MarkedAllocator::didConsumeFreeList): Deleted.
            (JSC::MarkedAllocator::tryAllocateWithoutCollecting): Deleted.
            (JSC::MarkedAllocator::allocateIn): Deleted.
            (JSC::MarkedAllocator::tryAllocateIn): Deleted.
            (JSC::MarkedAllocator::doTestCollectionsIfNeeded): Deleted.
            (JSC::MarkedAllocator::allocateSlowCase): Deleted.
            (JSC::MarkedAllocator::blockSizeForBytes): Deleted.
            (JSC::MarkedAllocator::tryAllocateBlock): Deleted.
            (JSC::MarkedAllocator::addBlock): Deleted.
            (JSC::MarkedAllocator::removeBlock): Deleted.
            (JSC::MarkedAllocator::stopAllocating): Deleted.
            (JSC::MarkedAllocator::prepareForAllocation): Deleted.
            (JSC::MarkedAllocator::lastChanceToFinalize): Deleted.
            (JSC::MarkedAllocator::resumeAllocating): Deleted.
            (JSC::MarkedAllocator::beginMarkingForFullCollection): Deleted.
            (JSC::MarkedAllocator::endMarking): Deleted.
            (JSC::MarkedAllocator::snapshotUnsweptForEdenCollection): Deleted.
            (JSC::MarkedAllocator::snapshotUnsweptForFullCollection): Deleted.
            (JSC::MarkedAllocator::findBlockToSweep): Deleted.
            (JSC::MarkedAllocator::sweep): Deleted.
            (JSC::MarkedAllocator::shrink): Deleted.
            (JSC::MarkedAllocator::assertNoUnswept): Deleted.
            (JSC::MarkedAllocator::parallelNotEmptyBlockSource): Deleted.
            (JSC::MarkedAllocator::dump const): Deleted.
            (JSC::MarkedAllocator::dumpBits): Deleted.
            (JSC::MarkedAllocator::markedSpace const): Deleted.
            * heap/BlockDirectory.h: Copied from Source/JavaScriptCore/heap/MarkedAllocator.h.
            (JSC::BlockDirectory::attributes const):
            (JSC::BlockDirectory::forEachBitVector):
            (JSC::BlockDirectory::forEachBitVectorWithName):
            (JSC::BlockDirectory::nextDirectory const):
            (JSC::BlockDirectory::nextDirectoryInSubspace const):
            (JSC::BlockDirectory::nextDirectoryInAlignedMemoryAllocator const):
            (JSC::BlockDirectory::setNextDirectory):
            (JSC::BlockDirectory::setNextDirectoryInSubspace):
            (JSC::BlockDirectory::setNextDirectoryInAlignedMemoryAllocator):
            (JSC::BlockDirectory::offsetOfFreeList):
            (JSC::BlockDirectory::offsetOfCellSize):
            (JSC::MarkedAllocator::cellSize const): Deleted.
            (JSC::MarkedAllocator::attributes const): Deleted.
            (JSC::MarkedAllocator::needsDestruction const): Deleted.
            (JSC::MarkedAllocator::destruction const): Deleted.
            (JSC::MarkedAllocator::cellKind const): Deleted.
            (JSC::MarkedAllocator::heap): Deleted.
            (JSC::MarkedAllocator::bitvectorLock): Deleted.
            (JSC::MarkedAllocator::forEachBitVector): Deleted.
            (JSC::MarkedAllocator::forEachBitVectorWithName): Deleted.
            (JSC::MarkedAllocator::nextAllocator const): Deleted.
            (JSC::MarkedAllocator::nextAllocatorInSubspace const): Deleted.
            (JSC::MarkedAllocator::nextAllocatorInAlignedMemoryAllocator const): Deleted.
            (JSC::MarkedAllocator::setNextAllocator): Deleted.
            (JSC::MarkedAllocator::setNextAllocatorInSubspace): Deleted.
            (JSC::MarkedAllocator::setNextAllocatorInAlignedMemoryAllocator): Deleted.
            (JSC::MarkedAllocator::subspace const): Deleted.
            (JSC::MarkedAllocator::freeList const): Deleted.
            (JSC::MarkedAllocator::offsetOfFreeList): Deleted.
            (JSC::MarkedAllocator::offsetOfCellSize): Deleted.
            * heap/BlockDirectoryInlines.h: Copied from Source/JavaScriptCore/heap/MarkedAllocatorInlines.h.
            (JSC::BlockDirectory::isFreeListedCell const):
            (JSC::BlockDirectory::allocate):
            (JSC::BlockDirectory::forEachBlock):
            (JSC::BlockDirectory::forEachNotEmptyBlock):
            (JSC::MarkedAllocator::isFreeListedCell const): Deleted.
            (JSC::MarkedAllocator::allocate): Deleted.
            (JSC::MarkedAllocator::forEachBlock): Deleted.
            (JSC::MarkedAllocator::forEachNotEmptyBlock): Deleted.
            * heap/CellAttributes.cpp: Copied from Source/JavaScriptCore/heap/AllocatorAttributes.cpp.
            (JSC::CellAttributes::dump const):
            (JSC::AllocatorAttributes::dump const): Deleted.
            * heap/CellAttributes.h: Copied from Source/JavaScriptCore/heap/AllocatorAttributes.h.
            (JSC::CellAttributes::CellAttributes):
            (JSC::AllocatorAttributes::AllocatorAttributes): Deleted.
            * heap/CompleteSubspace.cpp:
            (JSC::CompleteSubspace::allocatorFor):
            (JSC::CompleteSubspace::allocateNonVirtual):
            (JSC::CompleteSubspace::allocatorForSlow):
            (JSC::CompleteSubspace::tryAllocateSlow):
            * heap/CompleteSubspace.h:
            (JSC::CompleteSubspace::allocatorForSizeStep):
            (JSC::CompleteSubspace::allocatorForNonVirtual):
            * heap/GCDeferralContext.h:
            * heap/Heap.cpp:
            (JSC::Heap::updateAllocationLimits):
            * heap/Heap.h:
            * heap/HeapCell.h:
            * heap/HeapCellInlines.h:
            (JSC::HeapCell::cellAttributes const):
            (JSC::HeapCell::destructionMode const):
            (JSC::HeapCell::cellKind const):
            (JSC::HeapCell::allocatorAttributes const): Deleted.
            * heap/HeapCellType.cpp:
            (JSC::HeapCellType::HeapCellType):
            * heap/HeapCellType.h:
            (JSC::HeapCellType::attributes const):
            * heap/IncrementalSweeper.cpp:
            (JSC::IncrementalSweeper::IncrementalSweeper):
            (JSC::IncrementalSweeper::sweepNextBlock):
            (JSC::IncrementalSweeper::startSweeping):
            (JSC::IncrementalSweeper::stopSweeping):
            * heap/IncrementalSweeper.h:
            * heap/IsoCellSet.cpp:
            (JSC::IsoCellSet::IsoCellSet):
            (JSC::IsoCellSet::parallelNotEmptyMarkedBlockSource):
            (JSC::IsoCellSet::addSlow):
            (JSC::IsoCellSet::didRemoveBlock):
            (JSC::IsoCellSet::sweepToFreeList):
            * heap/IsoCellSetInlines.h:
            (JSC::IsoCellSet::forEachMarkedCell):
            (JSC::IsoCellSet::forEachLiveCell):
            * heap/IsoSubspace.cpp:
            (JSC::IsoSubspace::IsoSubspace):
            (JSC::IsoSubspace::allocatorFor):
            (JSC::IsoSubspace::allocateNonVirtual):
            * heap/IsoSubspace.h:
            (JSC::IsoSubspace::allocatorForNonVirtual):
            * heap/LargeAllocation.h:
            (JSC::LargeAllocation::attributes const):
            * heap/MarkedAllocator.cpp: Removed.
            * heap/MarkedAllocator.h: Removed.
            * heap/MarkedAllocatorInlines.h: Removed.
            * heap/MarkedBlock.cpp:
            (JSC::MarkedBlock::Handle::~Handle):
            (JSC::MarkedBlock::Handle::setIsFreeListed):
            (JSC::MarkedBlock::Handle::stopAllocating):
            (JSC::MarkedBlock::Handle::lastChanceToFinalize):
            (JSC::MarkedBlock::Handle::resumeAllocating):
            (JSC::MarkedBlock::aboutToMarkSlow):
            (JSC::MarkedBlock::Handle::didConsumeFreeList):
            (JSC::MarkedBlock::noteMarkedSlow):
            (JSC::MarkedBlock::Handle::removeFromDirectory):
            (JSC::MarkedBlock::Handle::didAddToDirectory):
            (JSC::MarkedBlock::Handle::didRemoveFromDirectory):
            (JSC::MarkedBlock::Handle::dumpState):
            (JSC::MarkedBlock::Handle::subspace const):
            (JSC::MarkedBlock::Handle::sweep):
            (JSC::MarkedBlock::Handle::isFreeListedCell const):
            (JSC::MarkedBlock::Handle::removeFromAllocator): Deleted.
            (JSC::MarkedBlock::Handle::didAddToAllocator): Deleted.
            (JSC::MarkedBlock::Handle::didRemoveFromAllocator): Deleted.
            * heap/MarkedBlock.h:
            (JSC::MarkedBlock::Handle::directory const):
            (JSC::MarkedBlock::Handle::attributes const):
            (JSC::MarkedBlock::attributes const):
            (JSC::MarkedBlock::Handle::allocator const): Deleted.
            * heap/MarkedBlockInlines.h:
            (JSC::MarkedBlock::Handle::isAllocated):
            (JSC::MarkedBlock::Handle::isLive):
            (JSC::MarkedBlock::Handle::specializedSweep):
            (JSC::MarkedBlock::Handle::isEmpty):
            * heap/MarkedSpace.cpp:
            (JSC::MarkedSpace::lastChanceToFinalize):
            (JSC::MarkedSpace::sweep):
            (JSC::MarkedSpace::stopAllocating):
            (JSC::MarkedSpace::resumeAllocating):
            (JSC::MarkedSpace::isPagedOut):
            (JSC::MarkedSpace::freeBlock):
            (JSC::MarkedSpace::shrink):
            (JSC::MarkedSpace::beginMarking):
            (JSC::MarkedSpace::endMarking):
            (JSC::MarkedSpace::snapshotUnswept):
            (JSC::MarkedSpace::assertNoUnswept):
            (JSC::MarkedSpace::dumpBits):
            (JSC::MarkedSpace::addBlockDirectory):
            (JSC::MarkedSpace::addMarkedAllocator): Deleted.
            * heap/MarkedSpace.h:
            (JSC::MarkedSpace::firstDirectory const):
            (JSC::MarkedSpace::directoryLock):
            (JSC::MarkedSpace::forEachBlock):
            (JSC::MarkedSpace::forEachDirectory):
            (JSC::MarkedSpace::firstAllocator const): Deleted.
            (JSC::MarkedSpace::allocatorLock): Deleted.
            (JSC::MarkedSpace::forEachAllocator): Deleted.
            * heap/MarkedSpaceInlines.h:
            * heap/Subspace.cpp:
            (JSC::Subspace::initialize):
            (JSC::Subspace::prepareForAllocation):
            (JSC::Subspace::findEmptyBlockToSteal):
            (JSC::Subspace::parallelDirectorySource):
            (JSC::Subspace::parallelNotEmptyMarkedBlockSource):
            (JSC::Subspace::sweep):
            (JSC::Subspace::parallelAllocatorSource): Deleted.
            * heap/Subspace.h:
            (JSC::Subspace::attributes const):
            (JSC::Subspace::didCreateFirstDirectory):
            (JSC::Subspace::didCreateFirstAllocator): Deleted.
            * heap/SubspaceInlines.h:
            (JSC::Subspace::forEachDirectory):
            (JSC::Subspace::forEachMarkedBlock):
            (JSC::Subspace::forEachNotEmptyMarkedBlock):
            (JSC::Subspace::forEachAllocator): Deleted.
            * jit/AssemblyHelpers.h:
            (JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator):
            (JSC::AssemblyHelpers::emitAllocate):
            (JSC::AssemblyHelpers::emitAllocateJSCell):
            (JSC::AssemblyHelpers::emitAllocateJSObject):
            (JSC::AssemblyHelpers::emitAllocateJSObjectWithKnownSize):
            * jit/JIT.h:
            * jit/JITOpcodes.cpp:
            (JSC::JIT::emit_op_new_object):
            * jit/JITOpcodes32_64.cpp:
            (JSC::JIT::emit_op_new_object):
            * runtime/JSDestructibleObjectHeapCellType.cpp:
            (JSC::JSDestructibleObjectHeapCellType::JSDestructibleObjectHeapCellType):
            * runtime/JSSegmentedVariableObjectHeapCellType.cpp:
            (JSC::JSSegmentedVariableObjectHeapCellType::JSSegmentedVariableObjectHeapCellType):
            * runtime/JSStringHeapCellType.cpp:
            (JSC::JSStringHeapCellType::JSStringHeapCellType):
            * runtime/VM.cpp:
            (JSC::VM::VM):
            * wasm/js/JSWebAssemblyCodeBlockHeapCellType.cpp:
            (JSC::JSWebAssemblyCodeBlockHeapCellType::JSWebAssemblyCodeBlockHeapCellType):

2018-01-11  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r226811. rdar://problem/36458907

    2018-01-11  Saam Barati  <sbarati@apple.com>

            When inserting Unreachable in byte code parser we need to flush all the right things
            https://bugs.webkit.org/show_bug.cgi?id=181509
            <rdar://problem/36423110>

            Reviewed by Mark Lam.

            I added code in r226655 that had its own mechanism for preserving liveness when
            inserting Unreachable nodes after ForceOSRExit. There are two ways to preserve
            liveness: PhantomLocal and Flush. Certain values *must* be flushed to the stack.
            I got some of these values wrong, which was leading to a crash when recovering the
            callee value from an inlined frame. Instead of making the same mistake and repeating
            similar code again, this patch refactors this logic to be shared with the other
            liveness preservation code in the DFG bytecode parser. This is what I should have
            done in my initial patch.

            * bytecode/InlineCallFrame.h:
            (JSC::remapOperand):
            * dfg/DFGByteCodeParser.cpp:
            (JSC::DFG::flushImpl):
            (JSC::DFG::flushForTerminalImpl):
            (JSC::DFG::ByteCodeParser::flush):
            (JSC::DFG::ByteCodeParser::flushForTerminal):
            (JSC::DFG::ByteCodeParser::parse):

2018-01-11  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r226788. rdar://problem/36450828

    2018-01-11  Michael Saboff  <msaboff@apple.com>

            Ensure there are no unsafe uses of MacroAssemblerARM64::dataTempRegister
            https://bugs.webkit.org/show_bug.cgi?id=181512

            Reviewed by Saam Barati.

            * assembler/MacroAssemblerARM64.h:
            (JSC::MacroAssemblerARM64::abortWithReason):
            (JSC::MacroAssemblerARM64::pushToSaveImmediateWithoutTouchingRegisters):
            All current uses of dataTempRegister in these functions are safe, but it makes sense to
            fix them in case they might be used elsewhere.

2018-01-11  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r226778. rdar://problem/36450800

    2018-01-11  Michael Saboff  <msaboff@apple.com>

            Add a DOM gadget for Spectre testing
            https://bugs.webkit.org/show_bug.cgi?id=181351

            Reviewed by Ryosuke Niwa.

            * runtime/Options.h:

2018-01-11  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r226767. rdar://problem/36450818

    2018-01-11  Saam Barati  <sbarati@apple.com>

            Our for-in caching is wrong when we add indexed properties on things in the prototype chain
            https://bugs.webkit.org/show_bug.cgi?id=181508

            Reviewed by Yusuke Suzuki.

            Our for-in caching would cache structure chains that had prototypes with
            indexed properties. Clearly this is wrong. This caching breaks when a prototype
            adds new indexed properties. We would continue to enumerate the old cached
            state of properties, and not include the new indexed properties.

            The old code used to prevent caching only if the base structure had
            indexed properties. This patch extends it to prevent caching if the
            base, or any structure in the prototype chain, has indexed properties.

            * runtime/Structure.cpp:
            (JSC::Structure::canCachePropertyNameEnumerator const):

2018-01-11  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r226655. rdar://problem/36450822

    2018-01-09  Saam Barati  <sbarati@apple.com>

            Reduce graph size by replacing terminal nodes in blocks that have a ForceOSRExit with Unreachable
            https://bugs.webkit.org/show_bug.cgi?id=181409

            Reviewed by Keith Miller.

            When I was looking at profiler data for Speedometer, I noticed that one of
            the hottest functions in Speedometer is around 1100 bytecode operations long.
            Only about 100 of those bytecode ops ever execute. However, we ended up
            spending a lot of time compiling basic blocks that never executed. We often
            plant ForceOSRExit nodes when we parse bytecodes that have a null value profile.
            This is the case when such a node never executes.

            This patch makes it so that anytime a block has a ForceOSRExit, we replace its
            terminal node with an Unreachable node (and remove all nodes after the
            ForceOSRExit). This will cut down on graph size when such a block dominates
            other blocks in the CFG. This allows us to get rid of huge chunks of the CFG
            in certain programs. When doing this transformation, we also insert
            Flushes/PhantomLocals to ensure we can recover values that are bytecode
            live-in to the ForceOSRExit.

            Using ForceOSRExit as the signal for this is a bit of a hack. It definitely
            does not get rid of all the CFG that it could. If we decide it's worth
            it, we could use additional inputs into this mechanism. For example, we could
            profile if a basic block ever executes inside the LLInt/Baseline, and
            remove parts of the CFG based on that.

            When running Speedometer with the concurrent JIT turned off, this patch
            improves DFG/FTL compile times by around 5%.

            * dfg/DFGByteCodeParser.cpp:
            (JSC::DFG::ByteCodeParser::addToGraph):
            (JSC::DFG::ByteCodeParser::parse):

2018-01-11  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r226650. rdar://problem/36429150

    2018-01-09  Mark Lam  <mark.lam@apple.com>

            ASSERTION FAILED: pair.second->m_type & PropertyNode::Getter
            https://bugs.webkit.org/show_bug.cgi?id=181388
            <rdar://problem/36349351>

            Reviewed by Saam Barati.

            When there are duplicate setters or getters, we may end up overwriting a getter
            with a setter, or vice versa.  This patch adds tracking for getters/setters that
            have been overwritten with duplicates and ignore them.

            * bytecompiler/NodesCodegen.cpp:
            (JSC::PropertyListNode::emitBytecode):
            * parser/NodeConstructors.h:
            (JSC::PropertyNode::PropertyNode):
            * parser/Nodes.h:
            (JSC::PropertyNode::isOverriddenByDuplicate const):
            (JSC::PropertyNode::setIsOverriddenByDuplicate):

2018-01-09  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r226672. rdar://problem/36397330

    2018-01-09  Keith Miller  <keith_miller@apple.com>

            and32 with an Address source on ARM64 did not invalidate dataTempRegister
            https://bugs.webkit.org/show_bug.cgi?id=181467

            Reviewed by Michael Saboff.

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

2018-01-09  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r226615. rdar://problem/36392328

    2018-01-08  JF Bastien  <jfbastien@apple.com>

            WebAssembly: mask indexed accesses to Table
            https://bugs.webkit.org/show_bug.cgi?id=181412
            <rdar://problem/36363236>

            Reviewed by Saam Barati.

            WebAssembly Table indexed accesses are user-controlled and
            bounds-checked. Force allocations of Table data to be a
            power-of-two, and explicitly mask accesses after bounds-check
            branches.

            Rename misleading usage of "size" when "length" of a Table was
            intended.

            Rename the Spectre option from "disable" to "enable".

            * dfg/DFGSpeculativeJIT.cpp:
            (JSC::DFG::SpeculativeJIT::SpeculativeJIT):
            * ftl/FTLLowerDFGToB3.cpp:
            (JSC::FTL::DFG::LowerDFGToB3::LowerDFGToB3):
            * jit/JIT.cpp:
            (JSC::JIT::JIT):
            * runtime/Options.h:
            * wasm/WasmB3IRGenerator.cpp:
            (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
            (JSC::Wasm::B3IRGenerator::addCallIndirect):
            * wasm/WasmTable.cpp:
            (JSC::Wasm::Table::allocatedLength):
            (JSC::Wasm::Table::setLength):
            (JSC::Wasm::Table::create):
            (JSC::Wasm::Table::Table):
            (JSC::Wasm::Table::grow):
            (JSC::Wasm::Table::clearFunction):
            (JSC::Wasm::Table::setFunction):
            * wasm/WasmTable.h:
            (JSC::Wasm::Table::length const):
            (JSC::Wasm::Table::offsetOfLength):
            (JSC::Wasm::Table::offsetOfMask):
            (JSC::Wasm::Table::mask const):
            (JSC::Wasm::Table::isValidLength):
            * wasm/js/JSWebAssemblyInstance.cpp:
            (JSC::JSWebAssemblyInstance::create):
            * wasm/js/JSWebAssemblyTable.cpp:
            (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
            (JSC::JSWebAssemblyTable::visitChildren):
            (JSC::JSWebAssemblyTable::grow):
            (JSC::JSWebAssemblyTable::getFunction):
            (JSC::JSWebAssemblyTable::clearFunction):
            (JSC::JSWebAssemblyTable::setFunction):
            * wasm/js/JSWebAssemblyTable.h:
            (JSC::JSWebAssemblyTable::isValidLength):
            (JSC::JSWebAssemblyTable::length const):
            (JSC::JSWebAssemblyTable::allocatedLength const):
            * wasm/js/WebAssemblyModuleRecord.cpp:
            (JSC::WebAssemblyModuleRecord::evaluate):
            * wasm/js/WebAssemblyTablePrototype.cpp:
            (JSC::webAssemblyTableProtoFuncLength):
            (JSC::webAssemblyTableProtoFuncGrow):
            (JSC::webAssemblyTableProtoFuncGet):
            (JSC::webAssemblyTableProtoFuncSet):

2018-01-09  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r226556. rdar://problem/36392331

    2018-01-08  Mark Lam  <mark.lam@apple.com>

            Rename CodeBlock::m_vm to CodeBlock::m_poisonedVM.
            https://bugs.webkit.org/show_bug.cgi?id=181403
            <rdar://problem/36359789>

            Rubber-stamped by JF Bastien.

            * bytecode/CodeBlock.cpp:
            (JSC::CodeBlock::CodeBlock):
            (JSC::CodeBlock::~CodeBlock):
            (JSC::CodeBlock::setConstantRegisters):
            (JSC::CodeBlock::propagateTransitions):
            (JSC::CodeBlock::finalizeLLIntInlineCaches):
            (JSC::CodeBlock::jettison):
            (JSC::CodeBlock::predictedMachineCodeSize):
            * bytecode/CodeBlock.h:
            (JSC::CodeBlock::vm const):
            (JSC::CodeBlock::addConstant):
            (JSC::CodeBlock::heap const):
            (JSC::CodeBlock::replaceConstant):
            * llint/LowLevelInterpreter.asm:
            * llint/LowLevelInterpreter32_64.asm:
            * llint/LowLevelInterpreter64.asm:

2018-01-09  Jason Marcell  <jmarcell@apple.com>

        Cherry-pick r226530. rdar://problem/36392325

    2018-01-07  Mark Lam  <mark.lam@apple.com>

            Apply poisoning to more pointers in JSC.
            https://bugs.webkit.org/show_bug.cgi?id=181096
            <rdar://problem/36182970>

            Reviewed by JF Bastien.

            * assembler/MacroAssembler.h:
            (JSC::MacroAssembler::xorPtr):
            * assembler/MacroAssemblerARM64.h:
            (JSC::MacroAssemblerARM64::xor64):
            * assembler/MacroAssemblerX86_64.h:
            (JSC::MacroAssemblerX86_64::xor64):
            - Add xorPtr implementation.

            * bytecode/CodeBlock.cpp:
            (JSC::CodeBlock::inferredName const):
            (JSC::CodeBlock::CodeBlock):
            (JSC::CodeBlock::finishCreation):
            (JSC::CodeBlock::~CodeBlock):
            (JSC::CodeBlock::setConstantRegisters):
            (JSC::CodeBlock::visitWeakly):
            (JSC::CodeBlock::visitChildren):
            (JSC::CodeBlock::propagateTransitions):
            (JSC::CodeBlock::WeakReferenceHarvester::visitWeakReferences):
            (JSC::CodeBlock::finalizeLLIntInlineCaches):
            (JSC::CodeBlock::finalizeBaselineJITInlineCaches):
            (JSC::CodeBlock::UnconditionalFinalizer::finalizeUnconditionally):
            (JSC::CodeBlock::jettison):
            (JSC::CodeBlock::predictedMachineCodeSize):
            (JSC::CodeBlock::findPC):
            * bytecode/CodeBlock.h:
            (JSC::CodeBlock::UnconditionalFinalizer::UnconditionalFinalizer):
            (JSC::CodeBlock::WeakReferenceHarvester::WeakReferenceHarvester):
            (JSC::CodeBlock::stubInfoBegin):
            (JSC::CodeBlock::stubInfoEnd):
            (JSC::CodeBlock::callLinkInfosBegin):
            (JSC::CodeBlock::callLinkInfosEnd):
            (JSC::CodeBlock::instructions):
            (JSC::CodeBlock::instructions const):
            (JSC::CodeBlock::vm const):
            * dfg/DFGOSRExitCompilerCommon.h:
            (JSC::DFG::adjustFrameAndStackInOSRExitCompilerThunk):
            * jit/JIT.h:
            * llint/LLIntOfflineAsmConfig.h:
            * llint/LowLevelInterpreter.asm:
            * llint/LowLevelInterpreter64.asm:
            * parser/UnlinkedSourceCode.h:
            * runtime/JSCPoison.h:
            * runtime/JSGlobalObject.cpp:
            (JSC::JSGlobalObject::init):
            * runtime/JSGlobalObject.h:
            * runtime/JSScriptFetchParameters.h:
            * runtime/JSScriptFetcher.h:
            * runtime/StructureTransitionTable.h:
            * wasm/js/JSWebAssemblyCodeBlock.cpp:
            (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock):
            (JSC::JSWebAssemblyCodeBlock::visitChildren):
            (JSC::JSWebAssemblyCodeBlock::UnconditionalFinalizer::finalizeUnconditionally):
            * wasm/js/JSWebAssemblyCodeBlock.h:

2018-01-06  Yusuke Suzuki  <utatane.tea@gmail.com>

        Object.getOwnPropertyNames includes "arguments" and "caller" for bound functions
        https://bugs.webkit.org/show_bug.cgi?id=181321

        Reviewed by Saam Barati.

        According to ECMA262 16.2[1], functions created using the bind method must not have
        "caller" and "arguments" own properties.

        [1]: https://tc39.github.io/ecma262/#sec-forbidden-extensions

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

2018-01-05  JF Bastien  <jfbastien@apple.com>

        WebAssembly: poison JS object's secrets
        https://bugs.webkit.org/show_bug.cgi?id=181339
        <rdar://problem/36325001>

        Reviewed by Mark Lam.

        Separating WebAssembly's JS objects from their non-JS
        implementation means that all interesting information lives
        outside of the JS object itself. This patch poisons each JS
        object's pointer to non-JS implementation using the poisoning
        mechanism and a unique key per JS object type origin.

        * runtime/JSCPoison.h:
        * wasm/js/JSToWasm.cpp:
        (JSC::Wasm::createJSToWasmWrapper): JS -> wasm stores the JS
        object in a stack slot when fast TLS is disabled. This requires
        that we unpoison the Wasm::Instance.
        * wasm/js/JSWebAssemblyCodeBlock.h:
        * wasm/js/JSWebAssemblyInstance.h:
        (JSC::JSWebAssemblyInstance::offsetOfPoisonedInstance): renamed to
        be explicit that the pointer is poisoned.
        * wasm/js/JSWebAssemblyMemory.h:
        * wasm/js/JSWebAssemblyModule.h:
        * wasm/js/JSWebAssemblyTable.h:

2018-01-05  Michael Saboff  <msaboff@apple.com>

        Add ability to disable indexed property masking for testing
        https://bugs.webkit.org/show_bug.cgi?id=181350

        Reviewed by Keith Miller.

        Made the masking of indexed properties runtime controllable via a new JSC::Option
        named disableSpectreMitigations.  This is done to test the efficacy of that mitigation.

        The new option has a generic name as it will probably be used to disable future mitigations.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::SpeculativeJIT):
        (JSC::DFG::SpeculativeJIT::loadFromIntTypedArray):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::LowerDFGToB3):
        (JSC::FTL::DFG::LowerDFGToB3::maskedIndex):
        (JSC::FTL::DFG::LowerDFGToB3::pointerIntoTypedArray):
        * jit/JIT.cpp:
        (JSC::JIT::JIT):
        * jit/JIT.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitDoubleLoad):
        (JSC::JIT::emitContiguousLoad):
        (JSC::JIT::emitArrayStorageLoad):
        * runtime/Options.h:
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):

2018-01-05  Michael Saboff  <msaboff@apple.com>

        Allow JSC Config Files to set Restricted Options
        https://bugs.webkit.org/show_bug.cgi?id=181352

        Reviewed by Mark Lam.

        * runtime/ConfigFile.cpp:
        (JSC::ConfigFile::parse):

2018-01-04  Keith Miller  <keith_miller@apple.com>

        TypedArrays and Wasm should use index masking.
        https://bugs.webkit.org/show_bug.cgi?id=181313

        Reviewed by Michael Saboff.

        We should have index masking for our TypedArray code in the
        DFG/FTL and for Wasm when doing bounds checking. Index masking for
        Wasm is added to the WasmBoundsCheckValue. Since we don't CSE any
        WasmBoundsCheckValues we don't need to worry about combining a
        bounds check for a load and a store. I went with fusing the
        pointer masking in the WasmBoundsCheckValue since it should reduce
        additional compiler overhead.

        * b3/B3LowerToAir.cpp:
        * b3/B3Validate.cpp:
        * b3/B3WasmBoundsCheckValue.cpp:
        (JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue):
        (JSC::B3::WasmBoundsCheckValue::dumpMeta const):
        * b3/B3WasmBoundsCheckValue.h:
        (JSC::B3::WasmBoundsCheckValue::pinnedIndexingMask const):
        * b3/air/AirCustom.h:
        (JSC::B3::Air::WasmBoundsCheckCustom::generate):
        * b3/testb3.cpp:
        (JSC::B3::testWasmBoundsCheck):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
        (JSC::DFG::SpeculativeJIT::loadFromIntTypedArray):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray):
        (JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileAtomicsReadModifyWrite):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
        (JSC::FTL::DFG::LowerDFGToB3::pointerIntoTypedArray):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitIntTypedArrayGetByVal):
        * runtime/Butterfly.h:
        (JSC::Butterfly::computeIndexingMask const):
        (JSC::Butterfly::computeIndexingMaskForVectorLength): Deleted.
        * runtime/JSArrayBufferView.cpp:
        (JSC::JSArrayBufferView::JSArrayBufferView):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
        (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
        (JSC::Wasm::B3IRGenerator::load):
        (JSC::Wasm::B3IRGenerator::store):
        (JSC::Wasm::B3IRGenerator::addCallIndirect):
        * wasm/WasmBinding.cpp:
        (JSC::Wasm::wasmToWasm):
        * wasm/WasmMemory.cpp:
        (JSC::Wasm::Memory::Memory):
        (JSC::Wasm::Memory::grow):
        * wasm/WasmMemory.h:
        (JSC::Wasm::Memory::offsetOfIndexingMask):
        * wasm/WasmMemoryInformation.cpp:
        (JSC::Wasm::PinnedRegisterInfo::get):
        (JSC::Wasm::PinnedRegisterInfo::PinnedRegisterInfo):
        * wasm/WasmMemoryInformation.h:
        (JSC::Wasm::PinnedRegisterInfo::toSave const):
        * wasm/js/JSToWasm.cpp:
        (JSC::Wasm::createJSToWasmWrapper):

2018-01-05  Commit Queue  <commit-queue@webkit.org>

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

        32bit JSC failure in x86 (Requested by yusukesuzuki on
        #webkit).

        Reverted changeset:

        "[DFG] Unify ToNumber implementation in 32bit and 64bit by
        changing 32bit Int32Tag and LowestTag"
        https://bugs.webkit.org/show_bug.cgi?id=181134
        https://trac.webkit.org/changeset/226434

2018-01-04  Devin Rousso  <webkit@devinrousso.com>

        Web Inspector: replace HTMLCanvasElement with CanvasRenderingContext for instrumentation logic
        https://bugs.webkit.org/show_bug.cgi?id=180770

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/Canvas.json:

2018-01-04  Commit Queue  <commit-queue@webkit.org>

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

        Speculative rollout due to Octane/SplayLatency,Octane/Splay
        regressions (Requested by yusukesuzuki on #webkit).

        Reverted changeset:

        "[JSC] Create parallel SlotVisitors apriori"
        https://bugs.webkit.org/show_bug.cgi?id=180907
        https://trac.webkit.org/changeset/226405

2018-01-04  Saam Barati  <sbarati@apple.com>

        Do value profiling in to_this
        https://bugs.webkit.org/show_bug.cgi?id=181299

        Reviewed by Filip Pizlo.

        This patch adds value profiling to to_this. We use the result of the value
        profiling only for strict mode code when we don't predict that the input is
        of a specific type. This helps when the input is SpecCellOther. Such cells
        might implement a custom ToThis, which can produce an arbitrary result. Before
        this patch, in prediction propagation, we were saying that a ToThis with a
        SpecCellOther input also produced SpecCellOther. However, this is incorrect,
        given that the input may implement ToThis that produces an arbitrary result.
        This is seen inside Speedometer. This patch fixes an OSR exit loop in Speedometer.
        
        Interestingly, this patch only does value profiling on the slow path. The fast
        path of to_this in the LLInt/baseline just perform a structure check. If it
        passes, the result is the same as the input. Therefore, doing value profiling
        from the fast path wouldn't actually produce new information for the ValueProfile.

        * bytecode/BytecodeDumper.cpp:
        (JSC::BytecodeDumper<Block>::dumpBytecode):
        * bytecode/BytecodeList.json:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitToThis):
        * bytecompiler/BytecodeGenerator.h:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasHeapPrediction):
        * dfg/DFGPredictionPropagationPhase.cpp:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):

2018-01-04  Yusuke Suzuki  <utatane.tea@gmail.com>

        [DFG] Unify ToNumber implementation in 32bit and 64bit by changing 32bit Int32Tag and LowestTag
        https://bugs.webkit.org/show_bug.cgi?id=181134

        Reviewed by Mark Lam.

        We would like to unify DFG ToNumber implementation in 32bit and 64bit. One problem is that
        branchIfNumber signature is different between 32bit and 64bit. 32bit implementation requires
        an additional scratch register. We do not want to allocate an unnecessary register in 64bit
        implementation.

        This patch removes the additional register in branchIfNumber/branchIfNotNumber in both 32bit
        and 64bit implementation. To achieve this goal, we change Int32Tag and LowestTag order. By
        setting Int32Tag as LowestTag, we can query whether the given tag is a number by checking
        `<= LowestTag(Int32Tag)`.

        We also change the order of UndefinedTag, NullTag, and BooleanTag to keep `(UndefinedTag | 1) == NullTag`.

        We also clean up speculateMisc implementation by adding branchIfMisc/branchIfNotMisc.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileValueToInt32):
        (JSC::DFG::SpeculativeJIT::compileDoubleRep):
        (JSC::DFG::SpeculativeJIT::speculateNumber):
        (JSC::DFG::SpeculativeJIT::speculateMisc):
        (JSC::DFG::SpeculativeJIT::compileNormalizeMapKey):
        (JSC::DFG::SpeculativeJIT::compileToNumber):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNullOrUndefined):
        (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
        (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::branchIfNotType):
        (JSC::AssemblyHelpers::jitAssertIsJSNumber):
        (JSC::AssemblyHelpers::emitConvertValueToBoolean):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::branchIfMisc):
        (JSC::AssemblyHelpers::branchIfNotMisc):
        (JSC::AssemblyHelpers::branchIfNumber):
        (JSC::AssemblyHelpers::branchIfNotNumber):
        (JSC::AssemblyHelpers::branchIfNotDoubleKnownNotInt32):
        (JSC::AssemblyHelpers::emitTypeOf):
        * jit/JITAddGenerator.cpp:
        (JSC::JITAddGenerator::generateFastPath):
        * jit/JITArithmetic32_64.cpp:
        (JSC::JIT::emitBinaryDoubleOp):
        * jit/JITDivGenerator.cpp:
        (JSC::JITDivGenerator::loadOperand):
        * jit/JITMulGenerator.cpp:
        (JSC::JITMulGenerator::generateInline):
        (JSC::JITMulGenerator::generateFastPath):
        * jit/JITNegGenerator.cpp:
        (JSC::JITNegGenerator::generateInline):
        (JSC::JITNegGenerator::generateFastPath):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_is_number):
        (JSC::JIT::emit_op_jeq_null):
        (JSC::JIT::emit_op_jneq_null):
        (JSC::JIT::emit_op_to_number):
        (JSC::JIT::emit_op_profile_type):
        * jit/JITRightShiftGenerator.cpp:
        (JSC::JITRightShiftGenerator::generateFastPath):
        * jit/JITSubGenerator.cpp:
        (JSC::JITSubGenerator::generateInline):
        (JSC::JITSubGenerator::generateFastPath):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * runtime/JSCJSValue.h:

2018-01-04  JF Bastien  <jfbastien@apple.com>

        Add assembler support for x86 lfence and sfence
        https://bugs.webkit.org/show_bug.cgi?id=181311
        <rdar://problem/36301780>

        Reviewed by Michael Saboff.

        Useful for testing performance of serializing instructions (hint:
        it's not good).

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::lfence):
        (JSC::MacroAssemblerX86Common::sfence):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::lfence):
        (JSC::X86Assembler::sfence):

2018-01-04  Saam Barati  <sbarati@apple.com>

        Add a new pattern matching rule to Graph::methodOfGettingAValueProfileFor for SetLocal(@nodeWithHeapPrediction)
        https://bugs.webkit.org/show_bug.cgi?id=181296

        Reviewed by Filip Pizlo.

        Inside Speedometer's Ember test, there is a recompile loop like:
        a: GetByVal(..., semanticOriginX)
        b: SetLocal(Cell:@a, semanticOriginX)
        
        where the cell check always fails. For reasons I didn't investigate, the
        baseline JIT's value profiling doesn't accurately capture the GetByVal's
        result.
        
        However, when compiling this cell speculation check in the DFG, we get a null
        MethodOfGettingAValueProfile inside Graph::methodOfGettingAValueProfileFor for
        this IR pattern because both @a and @b have the same semantic origin. We
        should not follow the same semantic origin heuristic when dealing with
        SetLocal since SetLocal(@nodeWithHeapPrediction) is such a common IR pattern.
        For patterns like this, we introduce a new heuristic: @NodeThatDoesNotProduceAValue(@nodeWithHeapPrediction).
        For this IR pattern, we will update the value profile for the semantic origin
        for @nodeWithHeapPrediction. So, for the Speedometer example above, we
        will correctly update the GetByVal's value profile, which will prevent
        an OSR exit loop.

        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::methodOfGettingAValueProfileFor):

2018-01-04  Keith Miller  <keith_miller@apple.com>

        Array Storage operations sometimes did not update the indexing mask correctly.
        https://bugs.webkit.org/show_bug.cgi?id=181301

        Reviewed by Mark Lam.

        I will add tests in a follow up patch. See: https://bugs.webkit.org/show_bug.cgi?id=181303

        * runtime/JSArray.cpp:
        (JSC::JSArray::shiftCountWithArrayStorage):
        * runtime/JSObject.cpp:
        (JSC::JSObject::increaseVectorLength):

2018-01-04  Yusuke Suzuki  <utatane.tea@gmail.com>

        [DFG] Define defs for MapSet/SetAdd to participate in CSE
        https://bugs.webkit.org/show_bug.cgi?id=179911

        Reviewed by Saam Barati.

        With this patch, our MapSet and SetAdd DFG nodes participate in CSE.
        To handle a bit tricky DFG Map operation nodes, MapSet and SetAdd
        produce added bucket as its result. Subsequent GetMapBucket will
        be removed by CSE.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileSetAdd):
        (JSC::DFG::SpeculativeJIT::compileMapSet):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileSetAdd):
        (JSC::FTL::DFG::LowerDFGToB3::compileMapSet):
        * jit/JITOperations.h:
        * runtime/HashMapImpl.h:
        (JSC::HashMapImpl::addNormalized):
        (JSC::HashMapImpl::addNormalizedInternal):

2018-01-04  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Remove LocalScope
        https://bugs.webkit.org/show_bug.cgi?id=181206

        Reviewed by Geoffrey Garen.

        The last user of HandleStack and LocalScope is JSON. But MarkedArgumentBuffer is enough for their use.
        This patch changes JSON parsing and stringifying to using MarkedArgumentBuffer. And remove HandleStack
        and LocalScope.

        We make Stringifier and Walker WTF_FORBID_HEAP_ALLOCATION to place them on the stack. So they can hold
        JSObject* directly in their fields.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * heap/HandleStack.cpp: Removed.
        * heap/HandleStack.h: Removed.
        * heap/Heap.cpp:
        (JSC::Heap::addCoreConstraints):
        * heap/Heap.h:
        (JSC::Heap::handleSet):
        (JSC::Heap::handleStack): Deleted.
        * heap/Local.h: Removed.
        * heap/LocalScope.h: Removed.
        * runtime/JSONObject.cpp:
        (JSC::Stringifier::Holder::object const):
        (JSC::gap):
        (JSC::Stringifier::Stringifier):
        (JSC::Stringifier::stringify):
        (JSC::Stringifier::appendStringifiedValue):
        (JSC::Stringifier::Holder::Holder):
        (JSC::Stringifier::Holder::appendNextProperty):
        (JSC::Walker::Walker):
        (JSC::Walker::callReviver):
        (JSC::Walker::walk):
        (JSC::JSONProtoFuncParse):
        (JSC::JSONProtoFuncStringify):
        (JSC::JSONParse):
        (JSC::JSONStringify):

2018-01-04  Yusuke Suzuki  <utatane.tea@gmail.com>

        [FTL] Optimize ObjectAllocationSinking mergePointerSets by using removeIf
        https://bugs.webkit.org/show_bug.cgi?id=180238

        Reviewed by Saam Barati.

        We can optimize ObjectAllocationSinking a bit by using removeIf.

        * dfg/DFGObjectAllocationSinkingPhase.cpp:

2018-01-04  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Create parallel SlotVisitors apriori
        https://bugs.webkit.org/show_bug.cgi?id=180907

        Reviewed by Saam Barati.

        The number of SlotVisitors are capped with the number of HeapHelperPool's threads + 2.
        If we create these SlotVisitors apriori, we do not need to create SlotVisitors dynamically.
        Then we do not need to grab locks while iterating all the SlotVisitors.

        In addition, we do not need to consider the case that the number of SlotVisitors increases
        after setting up VisitCounters in MarkingConstraintSolver since the number of SlotVisitors
        does not increase any more.

        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::runBeginPhase):
        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::forEachSlotVisitor):
        (JSC::Heap::numberOfSlotVisitors): Deleted.
        * heap/MarkingConstraintSolver.cpp:
        (JSC::MarkingConstraintSolver::didVisitSomething const):

2018-01-03  Ting-Wei Lan  <lantw44@gmail.com>

        Replace hard-coded paths in shebangs with #!/usr/bin/env
        https://bugs.webkit.org/show_bug.cgi?id=181040

        Reviewed by Alex Christensen.

        * Scripts/UpdateContents.py:
        * Scripts/cssmin.py:
        * Scripts/generate-combined-inspector-json.py:
        * Scripts/xxd.pl:
        * create_hash_table:
        * generate-bytecode-files:
        * wasm/generateWasm.py:
        * wasm/generateWasmOpsHeader.py:
        * yarr/generateYarrCanonicalizeUnicode:

2018-01-03  Michael Saboff  <msaboff@apple.com>

        Disable SharedArrayBuffers from Web API
        https://bugs.webkit.org/show_bug.cgi?id=181266

        Reviewed by Saam Barati.

        Removed SharedArrayBuffer prototype and structure from GlobalObject creation
        to disable.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::arrayBufferPrototype const):
        (JSC::JSGlobalObject::arrayBufferStructure const):

2018-01-03  Michael Saboff  <msaboff@apple.com>

        Add "noInline" to $vm
        https://bugs.webkit.org/show_bug.cgi?id=181265

        Reviewed by Mark Lam.

        This would be useful for web based tests.

        * tools/JSDollarVM.cpp:
        (JSC::getExecutableForFunction):
        (JSC::functionNoInline):
        (JSC::JSDollarVM::finishCreation):

2018-01-03  Michael Saboff  <msaboff@apple.com>

        Remove unnecessary flushing of Butterfly pointer in functionCpuClflush()
        https://bugs.webkit.org/show_bug.cgi?id=181263

        Reviewed by Mark Lam.

        Flushing the butterfly pointer provides no benefit and slows this function.

        * tools/JSDollarVM.cpp:
        (JSC::functionCpuClflush):

2018-01-03  Saam Barati  <sbarati@apple.com>

        Fix BytecodeParser op_catch assert to work with useProfiler=1
        https://bugs.webkit.org/show_bug.cgi?id=181260

        Reviewed by Keith Miller.

        op_catch was asserting that the current block was empty. This is only true
        if the profiler isn't enabled. When the profiler is enabled, we will
        insert a CountExecution node before each bytecode. This patch fixes the
        assert to work with the profiler.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):

2018-01-03  Per Arne Vollan  <pvollan@apple.com>

        [Win][Debug] testapi link error.
        https://bugs.webkit.org/show_bug.cgi?id=181247
        <rdar://problem/36166729>

        Reviewed by Brent Fulgham.

        Do not set the runtime library compile flag for C files, it is already set to the correct value.
 
        * shell/PlatformWin.cmake:

2018-01-03  Robin Morisset  <rmorisset@apple.com>

        Inlining of a function that ends in op_unreachable crashes
        https://bugs.webkit.org/show_bug.cgi?id=181027

        Reviewed by Filip Pizlo.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::allocateTargetableBlock):
        (JSC::DFG::ByteCodeParser::inlineCall):

2018-01-02  Saam Barati  <sbarati@apple.com>

        Incorrect assertion inside AccessCase
        https://bugs.webkit.org/show_bug.cgi?id=181200
        <rdar://problem/35494754>

        Reviewed by Yusuke Suzuki.

        Consider a PutById compiled to a setter in a function like so:
        
        ```
        function foo(o) { o.f = o; }
        ```
        
        The DFG will often assign the same registers to the baseGPR (o in o.f) and the
        valueRegsPayloadGPR (o in the RHS). The code totally works when these are assigned
        to the same register. However, we're asserting that they're not the same register.
        This patch just removes this invalid assertion.

        * bytecode/AccessCase.cpp:
        (JSC::AccessCase::generateImpl):

2018-01-02  Caio Lima  <ticaiolima@gmail.com>

        [ESNext][BigInt] Implement BigIntConstructor and BigIntPrototype
        https://bugs.webkit.org/show_bug.cgi?id=175359

        Reviewed by Yusuke Suzuki.

        This patch is implementing BigIntConstructor and BigIntPrototype
        following spec[1, 2]. As addition, we are also implementing BigIntObject
        warapper to handle ToObject(v) abstract operation when "v" is a BigInt
        primitive. With these classes, now it's possible to syntetize
        BigInt.prototype and then call "toString", "valueOf" and
        "toLocaleString" when the primitive is a BigInt.
        BigIntConstructor exposes an API to parse other primitives such as
        Number, Boolean and String to BigInt.
        We decided to skip parseInt implementation, since it was removed from
        spec.

        [1] - https://tc39.github.io/proposal-bigint/#sec-bigint-constructor
        [2] - https://tc39.github.io/proposal-bigint/#sec-properties-of-the-bigint-prototype-object 

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * jsc.cpp:
        * runtime/BigIntConstructor.cpp: Added.
        (JSC::BigIntConstructor::BigIntConstructor):
        (JSC::BigIntConstructor::finishCreation):
        (JSC::isSafeInteger):
        (JSC::toBigInt):
        (JSC::callBigIntConstructor):
        (JSC::bigIntConstructorFuncAsUintN):
        (JSC::bigIntConstructorFuncAsIntN):
        * runtime/BigIntConstructor.h: Added.
        (JSC::BigIntConstructor::create):
        (JSC::BigIntConstructor::createStructure):
        * runtime/BigIntObject.cpp: Added.
        (JSC::BigIntObject::BigIntObject):
        (JSC::BigIntObject::finishCreation):
        (JSC::BigIntObject::toStringName):
        (JSC::BigIntObject::defaultValue):
        * runtime/BigIntObject.h: Added.
        (JSC::BigIntObject::create):
        (JSC::BigIntObject::internalValue const):
        (JSC::BigIntObject::createStructure):
        * runtime/BigIntPrototype.cpp: Added.
        (JSC::BigIntPrototype::BigIntPrototype):
        (JSC::BigIntPrototype::finishCreation):
        (JSC::toThisBigIntValue):
        (JSC::bigIntProtoFuncToString):
        (JSC::bigIntProtoFuncToLocaleString):
        (JSC::bigIntProtoFuncValueOf):
        * runtime/BigIntPrototype.h: Added.
        (JSC::BigIntPrototype::create):
        (JSC::BigIntPrototype::createStructure):
        * runtime/IntlCollator.cpp:
        (JSC::IntlCollator::initializeCollator):
        * runtime/IntlNumberFormat.cpp:
        (JSC::IntlNumberFormat::initializeNumberFormat):
        * runtime/JSBigInt.cpp:
        (JSC::JSBigInt::createFrom):
        (JSC::JSBigInt::parseInt):
        (JSC::JSBigInt::toObject const):
        * runtime/JSBigInt.h:
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::synthesizePrototype const):
        * runtime/JSCPoisonedPtr.cpp:
        * runtime/JSCell.cpp:
        (JSC::JSCell::toObjectSlow const):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::bigIntPrototype const):
        (JSC::JSGlobalObject::bigIntObjectStructure const):
        * runtime/StructureCache.h:
        * runtime/StructureInlines.h:
        (JSC::prototypeForLookupPrimitiveImpl):

2018-01-02  Tim Horton  <timothy_horton@apple.com>

        Fix the MathCommon build with a recent compiler
        https://bugs.webkit.org/show_bug.cgi?id=181216

        Reviewed by Sam Weinig.

        * runtime/MathCommon.cpp:
        (JSC::fdlibmPow):
        This cast drops the 'const' qualifier from the pointer to 'one',
        but it doesn't have to, and it makes the compiler sad.

== Rolled over to ChangeLog-2018-01-01 ==