ChangeLog-2016-09-26   [plain text]


2016-09-24  Chris Dumez  <cdumez@apple.com>

        REGRESSION (r206221): [USER] com.apple.WebKit.WebContent.Development at com.apple.JavaScriptCore: vmEntryToJavaScript + 299
        https://bugs.webkit.org/show_bug.cgi?id=162536
        <rdar://problem/28415971>

        Reviewed by Gavin Barraclough.

        Drop API on PropertySlot for setting a cacheable custom getter/setter
        given that this is not supported yet and will lead to crashes if used.

        * runtime/PropertySlot.h:
        (JSC::PropertySlot::isCacheableCustom):
        (JSC::PropertySlot::isCacheableCustomAccessor): Deleted.
        (JSC::PropertySlot::setCacheableCustomGetterSetter): Deleted.

2016-09-23  Filip Pizlo  <fpizlo@apple.com>

        Need a store-load fence between setting cell state and visiting the object in SlotVisitor
        https://bugs.webkit.org/show_bug.cgi?id=162354

        Reviewed by Mark Lam.
        
        This was meant to be a small change, but then it became bigger as I found small
        opportunities for improving this code. This adds a store-load fence and is performance-
        neutral. That's probably partly due to other optimizations that I did to visitChildren().
        
        Initially, I found that adding an mfence as a store-load fence was terribly expensive. So,
        I thought that I needed to buffer up a bunch of objects, set their states, do one mfence,
        and then visit all of them. This seemed like a win, so I went with it. Unfortunately, this
        made no sense for two reasons:
        
        - I shouldn't use mfence. I should use ortop (lock orl $0, (%rsp)) instead. Ortop is
          basically free, and it's what WTF now uses for storeLoadFence().
        
        - My data saying that buffering up objects was not a slow-down was wrong. That was actually
          almost as expensive as the mfence.
        
        But in order to implement that, I made some other improvements that I think we should stick
        with:
        
        - SlotVisitor::visitChildren() now uses a switch on type. This replaces what used to be
          some nasty ClassInfo look-ups.
        
        - We no longer save the object's old CellState. We would do that so that we would know what
          state the object had been before we blackened it. But I believe that the more logical
          solution is to have two kinds of black - one for black-for-the-first-time objects and one
          for repeat offenders. This is a lot easier to reason about, since you can now just figure
          this out by looking at the cell directly.
        
        The latter change meant rewiring a bunch of barriers. It didn't make them any more
        expensive.
        
        Relanding after fixing a nasty build failure in cloop and elsewhere.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/AbstractMacroAssembler.h:
        (JSC::isARMv7IDIVSupported): Deleted.
        (JSC::isARM64): Deleted.
        (JSC::isX86): Deleted.
        (JSC::isX86_64): Deleted.
        (JSC::optimizeForARMv7IDIVSupported): Deleted.
        (JSC::optimizeForARM64): Deleted.
        (JSC::optimizeForX86): Deleted.
        (JSC::optimizeForX86_64): Deleted.
        * assembler/CPU.h: Added.
        (JSC::isARMv7IDIVSupported):
        (JSC::isARM64):
        (JSC::isX86):
        (JSC::isX86_64):
        (JSC::optimizeForARMv7IDIVSupported):
        (JSC::optimizeForARM64):
        (JSC::optimizeForX86):
        (JSC::optimizeForX86_64):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::emitStoreBarrier):
        * heap/CellState.h:
        (JSC::isBlack):
        (JSC::blacken):
        * heap/Heap.cpp:
        (JSC::Heap::addToRememberedSet):
        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::writeBarrier):
        (JSC::Heap::reportExtraMemoryVisited):
        (JSC::Heap::reportExternalMemoryVisited):
        * heap/MarkStack.cpp:
        * heap/MarkStack.h:
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::visitChildren):
        * heap/SlotVisitor.h:
        * heap/SlotVisitorInlines.h:
        (JSC::SlotVisitor::reportExtraMemoryVisited):
        (JSC::SlotVisitor::reportExternalMemoryVisited):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::jumpIfIsRememberedOrInEden):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/JSObject.h:
        (JSC::isJSFinalObject):

2016-09-23  Caitlin Potter  <caitp@igalia.com>

        [JSC] Implement parsing of Async Functions
        https://bugs.webkit.org/show_bug.cgi?id=161409

        Reviewed by Yusuke Suzuki.

        Introduces frontend parsing for the async function proposal soon to be
        ratified in ECMA262 (https://tc39.github.io/ecmascript-asyncawait/).

        * API/JSScriptRef.cpp:
        (parseScript):
        * Configurations/FeatureDefines.xcconfig:
        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createExecutable):
        * bytecode/EvalCodeCache.h:
        (JSC::EvalCodeCache::CacheKey::CacheKey):
        * bytecode/ExecutableInfo.h:
        (JSC::ExecutableInfo::ExecutableInfo):
        (JSC::ExecutableInfo::scriptMode):
        (JSC::ExecutableInfo::commentMode): Deleted.
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::scriptMode):
        (JSC::UnlinkedCodeBlock::commentMode): Deleted.
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::generateUnlinkedFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitNewArrowFunctionExpression):
        (JSC::BytecodeGenerator::emitNewMethodDefinition):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::scriptMode):
        (JSC::BytecodeGenerator::makeFunction):
        (JSC::BytecodeGenerator::commentMode): Deleted.
        * bytecompiler/NodesCodegen.cpp:
        (JSC::AwaitExprNode::emitBytecode):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createAwait):
        (JSC::ASTBuilder::createAsyncFunctionBody):
        * parser/Keywords.table:
        * parser/Lexer.cpp:
        (JSC::Lexer<T>::Lexer):
        (JSC::Lexer<T>::lex):
        * parser/Lexer.h:
        * parser/NodeConstructors.h:
        (JSC::AwaitExprNode::AwaitExprNode):
        * parser/Nodes.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::Parser):
        (JSC::Parser<LexerType>::parseInner):
        (JSC::Parser<LexerType>::isArrowFunctionParameters):
        (JSC::Parser<LexerType>::parseAsyncFunctionSourceElements):
        (JSC::Parser<LexerType>::parseStatementListItem):
        (JSC::Parser<LexerType>::parseVariableDeclarationList):
        (JSC::Parser<LexerType>::parseDestructuringPattern):
        (JSC::Parser<LexerType>::parseStatement):
        (JSC::Parser<LexerType>::parseFunctionDeclarationStatement):
        (JSC::Parser<LexerType>::maybeParseAsyncFunctionDeclarationStatement):
        (JSC::Parser<LexerType>::parseFormalParameters):
        (JSC::stringForFunctionMode):
        (JSC::Parser<LexerType>::parseFunctionParameters):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseAsyncFunctionDeclaration):
        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parseExpressionOrLabelStatement):
        (JSC::Parser<LexerType>::parseImportClauseItem):
        (JSC::Parser<LexerType>::parseImportDeclaration):
        (JSC::Parser<LexerType>::parseExportDeclaration):
        (JSC::Parser<LexerType>::parseAssignmentExpression):
        (JSC::Parser<LexerType>::parseProperty): Deleted.
        (JSC::Parser<LexerType>::parsePropertyMethod): Deleted.
        (JSC::Parser<LexerType>::parsePrimaryExpression): Deleted.
        (JSC::Parser<LexerType>::parseMemberExpression): Deleted.
        (JSC::Parser<LexerType>::parseArrowFunctionExpression): Deleted.
        (JSC::Parser<LexerType>::parseUnaryExpression): Deleted.
        (JSC::Parser<LexerType>::printUnexpectedTokenText): Deleted.
        * parser/Parser.h:
        (JSC::Scope::Scope):
        (JSC::Scope::setSourceParseMode):
        (JSC::Scope::isAsyncFunction):
        (JSC::Scope::isAsyncFunctionBoundary):
        (JSC::Scope::setIsAsyncArrowFunction):
        (JSC::Scope::setIsAsyncFunction):
        (JSC::Scope::setIsAsyncFunctionBody):
        (JSC::Scope::setIsAsyncArrowFunctionBody):
        (JSC::Parser::ExpressionErrorClassifier::forceClassifyExpressionError):
        (JSC::Parser::ExpressionErrorClassifier::propagateExpressionErrorClass):
        (JSC::Parser::ExpressionErrorClassifier::indicatesPossibleAsyncArrowFunction):
        (JSC::Parser::forceClassifyExpressionError):
        (JSC::Parser::declarationTypeToVariableKind):
        (JSC::Parser::upperScope):
        (JSC::Parser::pushScope):
        (JSC::Parser::matchSpecIdentifier):
        (JSC::Parser::isDisallowedIdentifierAwait):
        (JSC::Parser::disallowedIdentifierAwaitReason):
        (JSC::parse):
        (JSC::Scope::isGeneratorBoundary): Deleted.
        (JSC::Parser::ExpressionErrorClassifier::indicatesPossiblePattern): Deleted.
        * parser/ParserModes.h:
        (JSC::SourceParseModeSet::SourceParseModeSet):
        (JSC::SourceParseModeSet::contains):
        (JSC::SourceParseModeSet::mergeSourceParseModes):
        (JSC::isFunctionParseMode):
        (JSC::isAsyncFunctionParseMode):
        (JSC::isAsyncArrowFunctionParseMode):
        (JSC::isAsyncFunctionWrapperParseMode):
        (JSC::isAsyncFunctionBodyParseMode):
        (JSC::isMethodParseMode):
        (JSC::isModuleParseMode):
        (JSC::isProgramParseMode):
        (JSC::constructAbilityForParseMode):
        * parser/ParserTokens.h:
        * parser/SourceCodeKey.h:
        (JSC::SourceCodeFlags::SourceCodeFlags):
        (JSC::SourceCodeKey::SourceCodeKey):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createAwait):
        (JSC::SyntaxChecker::createAsyncFunctionBody):
        (JSC::SyntaxChecker::createYield): Deleted.
        (JSC::SyntaxChecker::createFunctionExpr): Deleted.
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getProgramCodeBlock):
        (JSC::CodeCache::getEvalCodeBlock):
        (JSC::CodeCache::getModuleProgramCodeBlock):
        (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
        * runtime/CodeCache.h:
        * runtime/CommonIdentifiers.h:
        * runtime/Completion.cpp:
        (JSC::checkSyntax):
        (JSC::checkModuleSyntax):
        * runtime/Executable.cpp:
        (JSC::ProgramExecutable::checkSyntax):
        * runtime/Executable.h:
        * runtime/ModuleLoaderPrototype.cpp:
        (JSC::moduleLoaderPrototypeParseModule):

2016-09-23  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r206314, r206316, and r206319.
        https://bugs.webkit.org/show_bug.cgi?id=162506

        These changes broke various builds (Requested by ryanhaddad on
        #webkit).

        Reverted changesets:

        "Need a store-load fence between setting cell state and
        visiting the object in SlotVisitor"
        https://bugs.webkit.org/show_bug.cgi?id=162354
        http://trac.webkit.org/changeset/206314

        "Unreviewed, fix cloop."
        http://trac.webkit.org/changeset/206316

        "Unreviewed, fix all other builds."
        http://trac.webkit.org/changeset/206319

2016-09-23  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix all other builds.

        * assembler/AbstractMacroAssembler.h:

2016-09-23  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix cloop.

        * assembler/AbstractMacroAssembler.h:
        * heap/SlotVisitor.cpp:

2016-09-22  Filip Pizlo  <fpizlo@apple.com>

        Need a store-load fence between setting cell state and visiting the object in SlotVisitor
        https://bugs.webkit.org/show_bug.cgi?id=162354

        Reviewed by Mark Lam.
        
        This was meant to be a small change, but then it became bigger as I found small
        opportunities for improving this code. This adds a store-load fence and is performance-
        neutral. That's probably partly due to other optimizations that I did to visitChildren().
        
        Initially, I found that adding an mfence as a store-load fence was terribly expensive. So,
        I thought that I needed to buffer up a bunch of objects, set their states, do one mfence,
        and then visit all of them. This seemed like a win, so I went with it. Unfortunately, this
        made no sense for two reasons:
        
        - I shouldn't use mfence. I should use ortop (lock orl $0, (%rsp)) instead. Ortop is
          basically free, and it's what WTF now uses for storeLoadFence().
        
        - My data saying that buffering up objects was not a slow-down was wrong. That was actually
          almost as expensive as the mfence.
        
        But in order to implement that, I made some other improvements that I think we should stick
        with:
        
        - SlotVisitor::visitChildren() now uses a switch on type. This replaces what used to be
          some nasty ClassInfo look-ups.
        
        - We no longer save the object's old CellState. We would do that so that we would know what
          state the object had been before we blackened it. But I believe that the more logical
          solution is to have two kinds of black - one for black-for-the-first-time objects and one
          for repeat offenders. This is a lot easier to reason about, since you can now just figure
          this out by looking at the cell directly.
        
        The latter change meant rewiring a bunch of barriers. It didn't make them any more
        expensive.

        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::emitStoreBarrier):
        * heap/CellState.h:
        (JSC::blacken):
        * heap/Heap.cpp:
        (JSC::Heap::addToRememberedSet):
        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::writeBarrier):
        (JSC::Heap::reportExtraMemoryVisited):
        (JSC::Heap::reportExternalMemoryVisited):
        * heap/MarkStack.cpp:
        * heap/MarkStack.h:
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::visitChildren):
        * heap/SlotVisitor.h:
        * heap/SlotVisitorInlines.h:
        (JSC::SlotVisitor::reportExtraMemoryVisited):
        (JSC::SlotVisitor::reportExternalMemoryVisited):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::jumpIfIsRememberedOrInEden):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/JSObject.h:
        (JSC::isJSFinalObject):

2016-09-23  Csaba Osztrogonác  <ossy@webkit.org>

        ARM EABI buildfix after r206289
        https://bugs.webkit.org/show_bug.cgi?id=162486

        Unreviewed buildfix.

        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgumentsWithExecState):

2016-09-23  Antoine Quint  <graouts@apple.com>

        Add a new runtime flag for work on modern media controls (off by default)
        https://bugs.webkit.org/show_bug.cgi?id=162420
        <rdar://problem/27989489>

        Reviewed by Eric Carlson.

        * runtime/CommonIdentifiers.h:

2016-09-23  Carlos Garcia Campos  <cgarcia@igalia.com>

        REGRESSION(r194387): Crash on github.com in IntlDateTimeFormat::resolvedOptions in C locale
        https://bugs.webkit.org/show_bug.cgi?id=162139

        Reviewed by Michael Catanzaro.

        The crash happens in unix ports because the resolved locale is empty when system locale is "C". IntlObject
        considers any language tag with a size < 2 to be an invalid language, so "C" is not a valid language to resolve
        the locale. We should ensure that WTF::platformUserPreferredLanguages() never returns invalid languages, but
        that's not enough, because languages can be overriden from the public API, so we need to handle those cases and
        throw exceptions instead of crashing.

        * runtime/IntlCollator.cpp:
        (JSC::IntlCollator::initializeCollator): Throw a exception when we fail to resolve the locale.
        * runtime/IntlDateTimeFormat.cpp:
        (JSC::IntlDateTimeFormat::initializeDateTimeFormat): Ditto.
        * runtime/IntlNumberFormat.cpp:
        (JSC::IntlNumberFormat::initializeNumberFormat): Ditto.

2016-09-22  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Use an inline cache to generate op_negate
        https://bugs.webkit.org/show_bug.cgi?id=162371

        Reviewed by Saam Barati.

        Use an inline cache to reduce the amount of code
        required to implement op_negate.

        For pure integer negate, the generated asm shrinks
        from 147 bytes to 125 bytes (14%).
        For double negate, the generated asm shrinks
        to 130 bytes (11%).
        The average size on Sunspider is 100bytes, this is due
        to the op_negates that are never executed and do not
        generate much.

        * bytecode/ArithProfile.h:
        (JSC::ArithProfile::ArithProfile):
        (JSC::ArithProfile::observeLHS):
        (JSC::ArithProfile::observeLHSAndRHS):
        * bytecode/BytecodeList.json:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::addJITNegIC):
        * bytecode/CodeBlock.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitUnaryOp):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::UnaryOpNode::emitBytecode):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileMathIC):
        * dfg/DFGSpeculativeJIT.h:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileMathIC):
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgumentsWithExecState):
        * jit/JIT.h:
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_negate):
        (JSC::JIT::emitSlow_op_negate):
        (JSC::JIT::emitMathICFast):
        (JSC::JIT::emitMathICSlow):
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITMathIC.h:
        (JSC::JITMathIC::generateInline):
        (JSC::canGenerateWithBinaryProfile):
        (JSC::canGenerateWithUnaryProfile):
        * jit/JITMathICForwards.h:
        * jit/JITNegGenerator.cpp:
        (JSC::JITNegGenerator::generateInline):
        (JSC::JITNegGenerator::generateFastPath):
        * jit/JITNegGenerator.h:
        (JSC::JITNegGenerator::JITNegGenerator):
        (JSC::JITNegGenerator::arithProfile):
        (JSC::JITNegGenerator::didEmitFastPath): Deleted.
        (JSC::JITNegGenerator::endJumpList): Deleted.
        (JSC::JITNegGenerator::slowPathJumpList): Deleted.
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::updateArithProfileForUnaryArithOp):
        (JSC::SLOW_PATH_DECL):

2016-09-22  Mark Lam  <mark.lam@apple.com>

        Removed unused hasErrorInfo().
        https://bugs.webkit.org/show_bug.cgi?id=162473

        Reviewed by Saam Barati.

        * JavaScriptCore.order:
        * runtime/Error.cpp:
        (JSC::hasErrorInfo): Deleted.
        * runtime/Error.h:

2016-09-22  Mark Lam  <mark.lam@apple.com>

        Array.prototype.join should do overflow checks on string joins.
        https://bugs.webkit.org/show_bug.cgi?id=162459

        Reviewed by Saam Barati.

        Change the 2 JSRopeString::create() functions that do joins to be private, and
        force all clients of it to go through the jsString() utility functions that do
        overflow checks before creating the ropes.

        * dfg/DFGOperations.cpp:
        * runtime/ArrayPrototype.cpp:
        (JSC::slowJoin):
        * runtime/JSString.h:
        * runtime/Operations.h:
        (JSC::jsString):

2016-09-22  Filip Pizlo  <fpizlo@apple.com>

        Fences on x86 should be a lot cheaper
        https://bugs.webkit.org/show_bug.cgi?id=162417

        Reviewed by Mark Lam and Geoffrey Garen.

        It turns out that:
        
            lock; orl $0, (%rsp)
        
        does everything that we wanted from:
        
            mfence
        
        And it's a lot faster. When I tried mfence for making object visiting concurrent-GC-TSO-
        friendly, it was a 9% regression on Octane/splay. But when I tried ortop, it was neutral.
        So, we should use ortop from now on.
        
        This part of the change is for the JITs. MacroAssembler::memoryFence() appears to always
        mean something like an acqrel fence, so it's safe to make this use ortop. Since B3's Fence
        compiles to Air MemoryFence, which is just MacroAssembler::memoryFence(), this also changes
        B3 codegen.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::memoryFence):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::lock):
        * b3/testb3.cpp:
        (JSC::B3::testX86MFence):
        (JSC::B3::testX86CompilerFence):

2016-09-22  Joseph Pecoraro  <pecoraro@apple.com>

        test262: Function length should be number of parameters before parameters with default values
        https://bugs.webkit.org/show_bug.cgi?id=162377

        Reviewed by Saam Barati.

        https://tc39.github.io/ecma262/#sec-function-definitions-static-semantics-expectedargumentcount

        > NOTE: The ExpectedArgumentCount of a FormalParameterList is the number of
        > FormalParameters to the left of either the rest parameter or the first
        > FormalParameter with an Initializer. A FormalParameter without an
        > initializer is allowed after the first parameter with an initializer
        > but such parameters are considered to be optional with undefined as
        > their default value.

        Alongside the parameterCount value, maintain a separate count,
        functionLength, which will be the count before seeing a rest parameter
        or parameter with a default value. This will be the function's length.

        * bytecode/UnlinkedCodeBlock.h:
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        * bytecode/UnlinkedFunctionExecutable.h:
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createFunctionMetadata):
        * parser/Nodes.cpp:
        (JSC::FunctionMetadataNode::FunctionMetadataNode):
        * parser/Nodes.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::isArrowFunctionParameters):
        (JSC::Parser<LexerType>::parseGeneratorFunctionSourceElements):
        (JSC::Parser<LexerType>::parseFormalParameters):
        (JSC::Parser<LexerType>::parseFunctionBody):
        (JSC::Parser<LexerType>::parseFunctionParameters):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        * parser/Parser.h:
        * parser/ParserFunctionInfo.h:
        * parser/SourceProviderCacheItem.h:
        (JSC::SourceProviderCacheItem::SourceProviderCacheItem):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createFunctionMetadata):
        * runtime/Executable.h:
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::createBuiltinFunction):
        (JSC::JSFunction::reifyLength):

2016-09-22  Joseph Pecoraro  <pecoraro@apple.com>

        Remove a bunch of unnecessary includes
        https://bugs.webkit.org/show_bug.cgi?id=162376

        Reviewed by Mark Lam.

2016-09-21  Keith Miller  <keith_miller@apple.com>

        Fix build for future versions of Clang.
        https://bugs.webkit.org/show_bug.cgi?id=162346

        Reviewed by Filip Pizlo.

        This fixes issues with the WebCore build where inline
        template-class function definitions are marked as exported. This
        genereates a weak external symobl that our build does not like.


        * runtime/VM.h:
        (JSC::VM::setGlobalConstRedeclarationShouldThrow):

2016-09-21  Joseph Pecoraro  <pecoraro@apple.com>

        Inline function only used in one place
        https://bugs.webkit.org/show_bug.cgi?id=162363

        Reviewed by Saam Barati.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::ForInNode::emitBytecode):
        (JSC::ForInNode::emitMultiLoopBytecode):
        * parser/Nodes.h:
        No need for the extra function, it adds no clarification.

2016-09-21  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r206222 and r206227.
        https://bugs.webkit.org/show_bug.cgi?id=162361

        "broke the windows build" (Requested by keith_mi_ on #webkit).

        Reverted changesets:

        "Fix build for future versions of Clang."
        https://bugs.webkit.org/show_bug.cgi?id=162346
        http://trac.webkit.org/changeset/206222

        "Attempt to fix windows build after r206222."
        http://trac.webkit.org/changeset/206227

2016-09-21  Filip Pizlo  <fpizlo@apple.com>

        Add a Fence opcode to B3
        https://bugs.webkit.org/show_bug.cgi?id=162343

        Reviewed by Geoffrey Garen.
        
        This adds the most basic fence support to B3. Currently, this is optimal on x86 and correct
        on ARM. It also happens to be sufficient and optimal for what we'll do in the concurrent GC.
        
        The idea of Fence is that it can represent any standalone fence instruction by having two
        additional params: a read range and a write range. If the write range is empty, this is
        taken to be a store-store fence, which turns into zero code on x86 and a cheaper fence on
        ARM.
        
        It turns out that this is powerful enough to express store-load and store-store fences. For
        load-store and load-load fences, you wouldn't have wanted to use any code on x86 and you
        wouldn't have wanted a standalone barrier on ARM. For those cases, you'd want either a
        fenced load (load acquire) or a dependency. See bug 162349 and bug 162350, respectively.
        
        This isn't yet optimized for store-store fences on ARM because we don't have the
        MacroAssembler support. Also, the support for "dmb ish" is not really what we want (it seems
        to use a heavier fence). I don't think that this is urgent because of how the concurrent GC
        will use this facility. I've left that to bug 162342.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/MacroAssemblerCodeRef.cpp:
        (JSC::MacroAssemblerCodeRef::tryToDisassemble):
        (JSC::MacroAssemblerCodeRef::disassembly):
        * assembler/MacroAssemblerCodeRef.h:
        (JSC::MacroAssemblerCodeRef::size): Deleted.
        (JSC::MacroAssemblerCodeRef::tryToDisassemble): Deleted.
        * b3/B3Compilation.h:
        (JSC::B3::Compilation::codeRef):
        (JSC::B3::Compilation::disassembly):
        (JSC::B3::Compilation::code): Deleted.
        * b3/B3Effects.h:
        * b3/B3FenceValue.cpp: Added.
        (JSC::B3::FenceValue::~FenceValue):
        (JSC::B3::FenceValue::cloneImpl):
        (JSC::B3::FenceValue::FenceValue):
        * b3/B3FenceValue.h: Added.
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3Opcode.cpp:
        (WTF::printInternal):
        * b3/B3Opcode.h:
        * b3/B3Validate.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::effects):
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::checkUsesInstruction):
        (JSC::B3::checkDoesNotUseInstruction):
        (JSC::B3::testX86MFence):
        (JSC::B3::testX86CompilerFence):
        (JSC::B3::run):

2016-09-21  Keith Miller  <keith_miller@apple.com>

        Fix build for future versions of Clang.
        https://bugs.webkit.org/show_bug.cgi?id=162346

        Reviewed by Filip Pizlo.

        This fixes issues with the WebCore build where inline
        template-class function definitions are marked as exported. This
        genereates a weak external symobl that our build does not like.


        * runtime/VM.h:
        (JSC::VM::setGlobalConstRedeclarationShouldThrow):

2016-09-21  Chris Dumez  <cdumez@apple.com>

        Object.getOwnPropertyDescriptor() does not work correctly cross origin
        https://bugs.webkit.org/show_bug.cgi?id=162311

        Reviewed by Gavin Barraclough.

        Add a CustomGetterSetter field to PropertySlot that gets populated
        by getOwnPropertySlot() and use it in getOwnPropertyDescriptor()
        to properly populate the descriptor. We used to rely on reifying
        the properties and then call getDirect() in order to get the
        CustomGetterSetter. However, this hack was insufficient to support
        the cross-origin case because we need to control more precisely
        the visibility of the getter and the setter. For example, Location's
        href property has both a getter and a setter in the same origin
        case but only has a setter in the cross-origin case.

        In the future, we can extend the use of PropertySlot's
        customGetterSetter field to the same origin case and get rid of the
        reification + getDirect() hack in getOwnPropertyDescriptor().

        * runtime/JSObject.cpp:
        (JSC::JSObject::getOwnPropertyDescriptor):
        * runtime/PropertySlot.cpp:
        (JSC::PropertySlot::customAccessorGetter):
        * runtime/PropertySlot.h:

2016-09-21  Michael Saboff  <msaboff@apple.com>

        FTL needs to reserve callee stack space in bytes
        https://bugs.webkit.org/show_bug.cgi?id=162324

        Reviewed by Geoffrey Garen.

        Changed two instances where we call B3::Procedure::requestCallArgAreaSize() with the
        number of JSValue sized objects of stack space instead of bytes.  The correct units
        to use is bytes.

        Renamed both the Air and B3 related callArgAreaSize() to callArgAreaSizeInBytes().

        No new tests as this doesn't surface as an issue when arguments are passed on the stack.

        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::callArgAreaSizeInBytes):
        (JSC::B3::Procedure::requestCallArgAreaSizeInBytes):
        (JSC::B3::Procedure::callArgAreaSize): Deleted.
        (JSC::B3::Procedure::requestCallArgAreaSize): Deleted.
        * b3/B3Procedure.h:
        * b3/air/AirAllocateStack.cpp:
        (JSC::B3::Air::allocateStack):
        * b3/air/AirCCallingConvention.cpp:
        (JSC::B3::Air::computeCCallingConvention):
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::callArgAreaSizeInBytes):
        (JSC::B3::Air::Code::requestCallArgAreaSizeInBytes):
        (JSC::B3::Air::Code::callArgAreaSize): Deleted.
        (JSC::B3::Air::Code::requestCallArgAreaSize): Deleted.
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallEval):

2016-09-21  Csaba Osztrogonác  <ossy@webkit.org>

        [ARM] Unreviewed buildfix after r206136.

        * assembler/MacroAssembler.h:
        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::branchPtr): Added.

2016-09-20  Alex Christensen  <achristensen@webkit.org>

        Require WTFMove for String::adopt
        https://bugs.webkit.org/show_bug.cgi?id=162313

        Reviewed by Yusuke Suzuki.

        * runtime/JSStringBuilder.h:
        (JSC::JSStringBuilder::build):

2016-09-20  Joseph Pecoraro  <pecoraro@apple.com>

        REGRESSION(r205692): Minified builds have broken inspector
        https://bugs.webkit.org/show_bug.cgi?id=162327
        <rdar://problem/28370137>

        Reviewed by Matt Baker.

        * Scripts/cssmin.py:
        (cssminify):
        Converge on the newer cssmin that we mistakenly dropped in r205692.
        This knows how to handle more cases.

2016-09-20  Filip Pizlo  <fpizlo@apple.com>

        DFG::StoreBarrierInsertionPhase should assume that any epoch increment may make objects older
        https://bugs.webkit.org/show_bug.cgi?id=162319

        Reviewed by Saam Barati.
        
        The store barrier phase needs to be aware of the fact that an object that is not in the
        OldBlack state may be concurrently brought into that state. That means that:
        
        - We cannot reason about the relative ages of objects. An object is either new, in which
          case we can store to it without barriers, or it's not in which case it needs a barrier.
        
        - After we insert a barrier on an object, the object is no longer new, because now the GC
          knows about it and the GC may do things to it, like make it OldBlack.
        
        This is a perf-neutral change. These optimizations were never particularly profitable.

        * dfg/DFGStoreBarrierInsertionPhase.cpp:

2016-09-20  Filip Pizlo  <fpizlo@apple.com>

        Rename MarkedSpace::version/MarkedBlock::version to MarkedSpace::markingVersion/MarkedBlock::markingVersion
        https://bugs.webkit.org/show_bug.cgi?id=162310

        Reviewed by Geoffrey Garen.
        
        In bug 162309, which is part of my concurrent GC work, I'll need to introduce a second
        version-based flip. This one will be for newlyAllocated bits. This will allow me to
        cheaply preserve per-object live state during marking. MarkedBlock::aboutToMarkSlow() will
        do this instead of clearMarks():
        
            - Walk the mark bits, simultaneously counting the number of set bits and clearing
              them.
            - If the count is zero, then we're done.
            - If the count is equal to the max number of cells in the block, then set the
              allocated bit for the block.
            - If the count is something else, create a newlyAllocated vector.
        
        The hope is that the last mode is going to be rare, since most blocks are not fragmented
        at end of GC. Usually, we will fill them in with objects by allocating! But if we do
        create newlyAllocated bits then we need to have some way of blowing them away later.
        
        This is where a second version comes in. We can have a version for newlyAllocated bits,
        which we increment at the end of marking, at around the same time that we clear all
        allocated bits.
        
        This means that the MarkedBlock will have two different version-based flips, so terms like
        "flip" and "version" aren't enough.
        
        This patch gets rid of the term "flip" entirely. It's a term of art in GCs that refers to
        the state change at the beginning or end of GC. It refers to the logical state change, not
        the physical one. It doesn't actually make sense to speak of a block being flipped
        independently of other blocks. It's true that our implementation of the flip makes some
        state updates happen lazily, but the block updating itself in some way (like clearing mark
        bits) isn't the flip - the flip already happened when the version was incremented.
        
        We no longer refer to a version without qualifying what kind of version it is. The type is
        HeapVersion. All of the version members were renamed to markingVersion, to reflect the
        fact that this version is just used for doing things to marking state. Instead of asking
        if the block needsFlip(), we ask if areMarksStale().
        
        This will let us introduce a second version for newlyAllocated, and will let us speak of
        the two versions unambiguously.

        * heap/CellContainer.h:
        * heap/CellContainerInlines.h:
        (JSC::CellContainer::isMarked):
        (JSC::CellContainer::isMarkedOrNewlyAllocated):
        (JSC::CellContainer::aboutToMark):
        (JSC::CellContainer::areMarksStale):
        (JSC::CellContainer::needsFlip): Deleted.
        * heap/ConservativeRoots.cpp:
        (JSC::ConservativeRoots::genericAddPointer):
        (JSC::ConservativeRoots::genericAddSpan):
        * heap/HeapInlines.h:
        (JSC::Heap::isMarked):
        (JSC::Heap::isMarkedConcurrently):
        (JSC::Heap::testAndSetMarked):
        * heap/HeapUtil.h:
        (JSC::HeapUtil::findGCObjectPointersForMarking):
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::isPagedOut):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::MarkedBlock):
        (JSC::MarkedBlock::Handle::specializedSweep):
        (JSC::MarkedBlock::Handle::sweepHelperSelectSweepMode):
        (JSC::MarkedBlock::Handle::sweepHelperSelectMarksMode):
        (JSC::MarkedBlock::aboutToMarkSlow):
        (JSC::MarkedBlock::clearMarks):
        (JSC::MarkedBlock::assertMarksNotStale):
        (JSC::MarkedBlock::areMarksStale):
        (JSC::MarkedBlock::Handle::areMarksStale):
        (JSC::MarkedBlock::isMarked):
        (JSC::MarkedBlock::Handle::isMarkedOrNewlyAllocated):
        (JSC::MarkedBlock::isMarkedOrNewlyAllocated):
        (JSC::MarkedBlock::markCount):
        (JSC::MarkedBlock::Handle::isLive):
        (JSC::MarkedBlock::Handle::isLiveCell):
        (JSC::MarkedBlock::Handle::sweepHelperSelectFlipMode): Deleted.
        (JSC::MarkedBlock::assertFlipped): Deleted.
        (JSC::MarkedBlock::needsFlip): Deleted.
        (JSC::MarkedBlock::Handle::needsFlip): Deleted.
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::areMarksStale):
        (JSC::MarkedBlock::aboutToMark):
        (JSC::MarkedBlock::assertMarksNotStale):
        (JSC::MarkedBlock::Handle::assertMarksNotStale):
        (JSC::MarkedBlock::isMarked):
        (JSC::MarkedBlock::isMarkedConcurrently):
        (JSC::MarkedBlock::testAndSetMarked):
        (JSC::MarkedBlock::Handle::isMarkedOrNewlyAllocated):
        (JSC::MarkedBlock::isMarkedOrNewlyAllocated):
        (JSC::MarkedBlock::needsFlip): Deleted.
        (JSC::MarkedBlock::assertFlipped): Deleted.
        (JSC::MarkedBlock::Handle::assertFlipped): Deleted.
        * heap/MarkedBlockInlines.h:
        (JSC::MarkedBlock::Handle::isLive):
        (JSC::MarkedBlock::Handle::isLiveCell):
        (JSC::MarkedBlock::resetMarkingVersion):
        (JSC::MarkedBlock::resetVersion): Deleted.
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::beginMarking):
        * heap/MarkedSpace.h:
        (JSC::MarkedSpace::markingVersion):
        (JSC::MarkedSpace::version): Deleted.
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::SlotVisitor):
        (JSC::SlotVisitor::didStartMarking):
        (JSC::SlotVisitor::appendJSCellOrAuxiliary):
        (JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
        (JSC::SlotVisitor::markAuxiliary):
        * heap/SlotVisitor.h:
        (JSC::SlotVisitor::markingVersion):
        (JSC::SlotVisitor::version): Deleted.
        * heap/WeakBlock.cpp:
        (JSC::WeakBlock::specializedVisit):
        (JSC::WeakBlock::reap):

2016-09-20  Ryan Haddad  <ryanhaddad@apple.com>

        Rebaseline builtins generator tests after r206155.

        Unreviewed test gardening.

        * Scripts/tests/builtins/expected/WebCoreJSBuiltins.h-result:

2016-09-20  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix cloop build.

        * runtime/VM.h:

2016-09-20  Filip Pizlo  <fpizlo@apple.com>

        Make MarkedBlock state tracking support overlapped allocation and marking state
        https://bugs.webkit.org/show_bug.cgi?id=161581

        Reviewed by Geoffrey Garen.
        
        Concurrent GCs must allow for mutation and allocation during collection. We already know
        how to mutate during collection. We have a write barrier for that. Allocation during
        collection is more involved: the collector modifies the the mark bits, as well as other
        kinds of MarkedBlock state, in-place during a collection. The allocator uses that same
        MarkedBlock state to decide which regions of memory are free. This works if the allocator
        never runs while the collector is running, but if we want to allow them to run at the same
        time, then we need to have two versions of the state: one version built up by the
        collector and another consumed by the allocator. We clear the collector state at the
        beginning of collection, and splat the collector state onto the allocator state after
        collection.
        
        This could be super expensive, but we can make it cheap with some cleverness. The biggest
        observation is just that most of the state is a handful of bits per block: is the block
        free-listed? is it completely full? completely empty? in the incremental sweeper's
        snapshot? is it retired? is it in eden? There is also state inside blocks, like the mark
        bits, but I have a solid plan there and I'll save it for another patch. Once we view the
        state of blocks as bits, we can put that state into bitvectors, so that if the collector
        needs to transform the state of some blocks, it can do it with a single operation over
        bitvectors. I like to think of this as 32-way parallelizing block operations, since
        doing one operation on a 32-bit word in one of those bitvectors instantly affects 32
        blocks.
        
        This change converts all previous collections of MarkedBlocks, along with the MarkedBlock
        state, into 8 bitvectors (live, empty, allocated, canAllocateButNotEmpty, eden, unswept,
        markingNotEmpty, and markingRetired). The bitvectors separate allocator state (empty,
        allocated, canAllocateButNotEmpty) from marking state (markingNotEmpty, markingRetired).
        
        As a nice side-effect of switching to bitvectors, we get size class rebalancing for free.
        It used to be that if a MarkedAllocator had an empty block, we would only allow that
        memory to be reused by a different MarkedAllocator if we did an incremental sweep or a
        full eager sweep. Now we hunt down all destructorless empty blocks before allocating new
        MarkedBlocks. It would be relatively easy to also hunt down destructor empty blocks, but
        the theory is that those might be expensive to sweep, so it might still be better to leave
        those to the incremental sweeper.
        
        This change is perf-neutral all around. I did some tests with two different kinds of
        allocation strategies - something that is somewhat easier to do now that you can look for
        blocks that are candidates for allocation by just scanning some bitvectors. I tried two
        variants:
        
        - Allocate out of non-empty blocks first, leaving empty blocks for last in case a
          different allocator needed them. This is sort of a best-fit strategy. I tried this
          first, and it can be expressed as:
          
          m_allocationCursor = m_canAllocateButNotEmpty.findBit(m_allocationCursor, true)
        
        - Allocate out of lower-indexed blocks first, treating empty and canAllocateButNotEmpty
          blocks equally. This is sort of a first-fit strategy. This is what I ended up settling
          on, and it can be expressed as:
          
          m_allocationCursor = (m_canAllocateButNotEmpty | m_empty).findBit(m_allocationCursor, true)
        
        The best-fit strategy meant 1% regressions in LongSpider and Octane overall, and a 11%
        regression on Octane/earley. First-fit means perf-neutrality. Most great allocators skew
        towards first-fit because it's empirically better, so this result is not surprising.
        
        Overall, the performance of this patch on my machine is as follows, where "neutral" means
        less than 1% and not statistically significant.
        
        run-jsc-benchmarks:
            SunSpider: neutral
            LongSpider: 0.6% slower
            V8Spider: neutral
            Octane: neutral
            Kraken: neutral
            Microbenchmarks: 0.37% slower
            AsmBench: neutral
            CompressionBench: maybe 1% faster
        
        For browser benchmarks, I report the ratio of means (bigger / smaller) along with a T-test
        from Mathematica reported as % chance of not [sic] the null hypothesis. Note that we
        normally consider anything less than 95% confidence to be inconclusive.
        
        Browser benchmarks:
            PLT3: 0.3% faster with 67% confidence
            membuster:
                Snap2FinishedLoadingPost: 0.68% more memory with 50% confidence
                Snap3EndPost: 2.4% more memory with 61% confidence
            JetStream: 0.2% slower with 32% confidence
            Speedometer: 0.7% faster with 82% confidence
        
        Additionally, Octane/splay's heap capacity goes down to ~180KB from ~200KB, so about a 10%
        progression. This is due to the allocator rebalancing feature.
        
        Finally, this breaks --useImmortalObjects. It was already broken as far as I can tell. I
        filed a bug to reimplement it (bug 162296). Unless someone urgently needs this internal
        tool, it's probably best to reimplement it after I'm done refactoring MarkedSpace. 

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * debugger/Debugger.cpp:
        * heap/CellContainer.h:
        * heap/CellContainerInlines.h:
        (JSC::CellContainer::vm):
        (JSC::CellContainer::heap):
        (JSC::CellContainer::isMarkedOrNewlyAllocated):
        (JSC::CellContainer::aboutToMark):
        (JSC::CellContainer::isMarked): Deleted.
        (JSC::CellContainer::flipIfNecessary): Deleted.
        * heap/ConservativeRoots.cpp:
        * heap/Heap.cpp:
        (JSC::Heap::beginMarking):
        (JSC::Heap::endMarking):
        (JSC::Heap::collectAllGarbage):
        (JSC::Heap::collectImpl):
        (JSC::Heap::snapshotMarkedSpace):
        (JSC::Heap::prepareForAllocation):
        (JSC::Heap::zombifyDeadObjects):
        (JSC::MarkedBlockSnapshotFunctor::MarkedBlockSnapshotFunctor): Deleted.
        (JSC::MarkedBlockSnapshotFunctor::operator()): Deleted.
        (JSC::Heap::resetAllocators): Deleted.
        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::isMarked):
        (JSC::Heap::isMarkedConcurrently):
        (JSC::Heap::testAndSetMarked):
        * heap/HeapStatistics.cpp:
        * heap/HeapUtil.h:
        (JSC::HeapUtil::findGCObjectPointersForMarking):
        (JSC::HeapUtil::isPointerGCObjectJSCell):
        * heap/HeapVerifier.cpp:
        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::IncrementalSweeper):
        (JSC::IncrementalSweeper::doSweep):
        (JSC::IncrementalSweeper::sweepNextBlock):
        (JSC::IncrementalSweeper::startSweeping):
        (JSC::IncrementalSweeper::willFinishSweeping):
        * heap/IncrementalSweeper.h:
        * heap/LargeAllocation.h:
        (JSC::LargeAllocation::isMarked):
        (JSC::LargeAllocation::isMarkedConcurrently):
        (JSC::LargeAllocation::isMarkedOrNewlyAllocated):
        (JSC::LargeAllocation::aboutToMark):
        (JSC::LargeAllocation::isMarkedDuringWeakVisiting): Deleted.
        (JSC::LargeAllocation::flipIfNecessary): Deleted.
        (JSC::LargeAllocation::flipIfNecessaryDuringMarking): Deleted.
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::MarkedAllocator):
        (JSC::MarkedAllocator::isPagedOut):
        (JSC::MarkedAllocator::findEmptyBlock):
        (JSC::MarkedAllocator::tryAllocateWithoutCollectingImpl):
        (JSC::MarkedAllocator::allocateIn):
        (JSC::MarkedAllocator::tryAllocateIn):
        (JSC::MarkedAllocator::allocateSlowCaseImpl):
        (JSC::MarkedAllocator::tryAllocateBlock):
        (JSC::MarkedAllocator::addBlock):
        (JSC::MarkedAllocator::removeBlock):
        (JSC::MarkedAllocator::stopAllocating):
        (JSC::MarkedAllocator::prepareForAllocation):
        (JSC::MarkedAllocator::lastChanceToFinalize):
        (JSC::MarkedAllocator::resumeAllocating):
        (JSC::MarkedAllocator::beginMarkingForFullCollection):
        (JSC::MarkedAllocator::endMarking):
        (JSC::MarkedAllocator::snapshotForEdenCollection):
        (JSC::MarkedAllocator::snapshotForFullCollection):
        (JSC::MarkedAllocator::findBlockToSweep):
        (JSC::MarkedAllocator::sweep):
        (JSC::MarkedAllocator::shrink):
        (JSC::MarkedAllocator::assertSnapshotEmpty):
        (JSC::MarkedAllocator::dump):
        (JSC::MarkedAllocator::dumpBits):
        (JSC::MarkedAllocator::retire): Deleted.
        (JSC::MarkedAllocator::filterNextBlock): Deleted.
        (JSC::MarkedAllocator::setNextBlockToSweep): Deleted.
        (JSC::MarkedAllocator::reset): Deleted.
        * heap/MarkedAllocator.h:
        (JSC::MarkedAllocator::forEachBitVector):
        (JSC::MarkedAllocator::forEachBitVectorWithName):
        (JSC::MarkedAllocator::nextAllocator):
        (JSC::MarkedAllocator::setNextAllocator):
        (JSC::MarkedAllocator::forEachBlock):
        (JSC::MarkedAllocator::resumeAllocating): Deleted.
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::tryCreate):
        (JSC::MarkedBlock::Handle::Handle):
        (JSC::MarkedBlock::Handle::~Handle):
        (JSC::MarkedBlock::MarkedBlock):
        (JSC::MarkedBlock::Handle::specializedSweep):
        (JSC::MarkedBlock::Handle::sweep):
        (JSC::MarkedBlock::Handle::sweepHelperSelectScribbleMode):
        (JSC::MarkedBlock::Handle::sweepHelperSelectEmptyMode):
        (JSC::MarkedBlock::Handle::sweepHelperSelectHasNewlyAllocated):
        (JSC::MarkedBlock::Handle::sweepHelperSelectSweepMode):
        (JSC::MarkedBlock::Handle::sweepHelperSelectFlipMode):
        (JSC::MarkedBlock::Handle::unsweepWithNoNewlyAllocated):
        (JSC::MarkedBlock::Handle::setIsFreeListed):
        (JSC::MarkedBlock::Handle::stopAllocating):
        (JSC::MarkedBlock::Handle::lastChanceToFinalize):
        (JSC::MarkedBlock::Handle::resumeAllocating):
        (JSC::MarkedBlock::aboutToMarkSlow):
        (JSC::MarkedBlock::clearMarks):
        (JSC::MarkedBlock::isMarked):
        (JSC::MarkedBlock::Handle::isMarkedOrNewlyAllocated):
        (JSC::MarkedBlock::isMarkedOrNewlyAllocated):
        (JSC::MarkedBlock::Handle::didConsumeFreeList):
        (JSC::MarkedBlock::markCount):
        (JSC::MarkedBlock::Handle::isEmpty):
        (JSC::MarkedBlock::noteMarkedSlow):
        (JSC::MarkedBlock::Handle::removeFromAllocator):
        (JSC::MarkedBlock::Handle::didAddToAllocator):
        (JSC::MarkedBlock::Handle::didRemoveFromAllocator):
        (JSC::MarkedBlock::Handle::isLive):
        (JSC::MarkedBlock::Handle::isLiveCell):
        (JSC::MarkedBlock::Handle::sweepHelperSelectStateAndSweepMode): Deleted.
        (JSC::MarkedBlock::flipIfNecessary): Deleted.
        (JSC::MarkedBlock::Handle::flipIfNecessary): Deleted.
        (JSC::MarkedBlock::flipIfNecessarySlow): Deleted.
        (JSC::MarkedBlock::flipIfNecessaryDuringMarkingSlow): Deleted.
        (JSC::MarkedBlock::Handle::willRemoveBlock): Deleted.
        (WTF::printInternal): Deleted.
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::Handle::isFreeListed):
        (JSC::MarkedBlock::Handle::index):
        (JSC::MarkedBlock::aboutToMark):
        (JSC::MarkedBlock::isMarked):
        (JSC::MarkedBlock::isMarkedConcurrently):
        (JSC::MarkedBlock::Handle::isMarkedOrNewlyAllocated):
        (JSC::MarkedBlock::isMarkedOrNewlyAllocated):
        (JSC::MarkedBlock::Handle::isOnBlocksToSweep): Deleted.
        (JSC::MarkedBlock::Handle::setIsOnBlocksToSweep): Deleted.
        (JSC::MarkedBlock::Handle::state): Deleted.
        (JSC::MarkedBlock::flipIfNecessary): Deleted.
        (JSC::MarkedBlock::flipIfNecessaryDuringMarking): Deleted.
        (JSC::MarkedBlock::Handle::flipIfNecessary): Deleted.
        (JSC::MarkedBlock::Handle::flipIfNecessaryDuringMarking): Deleted.
        (JSC::MarkedBlock::Handle::flipForEdenCollection): Deleted.
        (JSC::MarkedBlock::isMarkedDuringWeakVisiting): Deleted.
        (JSC::MarkedBlock::Handle::isLive): Deleted.
        (JSC::MarkedBlock::Handle::isLiveCell): Deleted.
        (JSC::MarkedBlock::Handle::forEachLiveCell): Deleted.
        (JSC::MarkedBlock::Handle::forEachDeadCell): Deleted.
        (JSC::MarkedBlock::Handle::needsSweeping): Deleted.
        (JSC::MarkedBlock::Handle::isAllocated): Deleted.
        (JSC::MarkedBlock::Handle::isMarked): Deleted.
        * heap/MarkedBlockInlines.h: Added.
        (JSC::MarkedBlock::Handle::isLive):
        (JSC::MarkedBlock::Handle::isLiveCell):
        (JSC::MarkedBlock::Handle::forEachLiveCell):
        (JSC::MarkedBlock::Handle::forEachDeadCell):
        (JSC::MarkedBlock::resetVersion):
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::MarkedSpace):
        (JSC::MarkedSpace::allocate):
        (JSC::MarkedSpace::tryAllocate):
        (JSC::MarkedSpace::sweep):
        (JSC::MarkedSpace::prepareForAllocation):
        (JSC::MarkedSpace::shrink):
        (JSC::MarkedSpace::clearNewlyAllocated):
        (JSC::MarkedSpace::beginMarking):
        (JSC::MarkedSpace::endMarking):
        (JSC::MarkedSpace::didAllocateInBlock):
        (JSC::MarkedSpace::findEmptyBlock):
        (JSC::MarkedSpace::snapshot):
        (JSC::MarkedSpace::assertSnapshotEmpty):
        (JSC::MarkedSpace::dumpBits):
        (JSC::MarkedSpace::zombifySweep): Deleted.
        (JSC::MarkedSpace::resetAllocators): Deleted.
        (JSC::VerifyMarked::operator()): Deleted.
        (JSC::MarkedSpace::flip): Deleted.
        * heap/MarkedSpace.h:
        (JSC::MarkedSpace::nextVersion):
        (JSC::MarkedSpace::firstAllocator):
        (JSC::MarkedSpace::allocatorForEmptyAllocation):
        (JSC::MarkedSpace::forEachAllocator):
        (JSC::MarkedSpace::blocksWithNewObjects): Deleted.
        (JSC::MarkedSpace::setIsMarking): Deleted.
        (JSC::MarkedSpace::forEachLiveCell): Deleted.
        (JSC::MarkedSpace::forEachDeadCell): Deleted.
        * heap/MarkedSpaceInlines.h: Added.
        (JSC::MarkedSpace::forEachLiveCell):
        (JSC::MarkedSpace::forEachDeadCell):
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
        (JSC::SlotVisitor::markAuxiliary):
        (JSC::SlotVisitor::visitChildren):
        * heap/Weak.h:
        (WTF::HashTraits<JSC::Weak<T>>::emptyValue):
        (WTF::HashTraits<JSC::Weak<T>>::peek):
        * heap/WeakBlock.cpp:
        (JSC::WeakBlock::specializedVisit):
        (JSC::WeakBlock::reap):
        * heap/WeakInlines.h:
        (WTF::HashTraits<JSC::Weak<T>>::emptyValue): Deleted.
        (WTF::HashTraits<JSC::Weak<T>>::peek): Deleted.
        * jit/JITThunks.h:
        * runtime/JSGlobalObject.cpp:
        * runtime/PrototypeMap.h:
        * runtime/SamplingProfiler.cpp:
        * runtime/WeakGCMap.h:
        * tools/JSDollarVMPrototype.cpp:

2016-09-20  Jonathan Bedard  <jbedard@apple.com>

        Undefined behavior: Left shift negative number
        https://bugs.webkit.org/show_bug.cgi?id=161866

        Reviewed by Keith Miller.

        Left shifting a negative number is undefined behavior in C/C++, although most implementations do define it. Explicitly clarifying the intended behavior due to shifting negative number in some cases.

        * dfg/DFGAbstractHeap.h:
        (JSC::DFG::AbstractHeap::encode): Explicitly cast signed integer for left shift.

2016-09-20  Saam Barati  <sbarati@apple.com>

        Unreviewed fix for 32-bit DFG x86 implementation of HasOwnProperty.

        Fixup phase is always setting ObjectUse on child1() of HasOwnProperty.
        However, on x86 32-bit, I omitted a call to speculateObject() on child1().

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

2016-09-20  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Add `typeof value === "symbol"` handling to bytecode compiler
        https://bugs.webkit.org/show_bug.cgi?id=162253

        Reviewed by Sam Weinig.

        Add `typeof value === "symbol"` handling to the bytecode compiler.
        The effect is tiny, but it keeps consistency since the bytecode compiler
        already has the similar optimization for "string" case.

        * bytecode/SpeculatedType.cpp:
        (JSC::speculationFromJSType):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitEqualityOp):

2016-09-19  Saam Barati  <sbarati@apple.com>

        Make HasOwnProperty faster
        https://bugs.webkit.org/show_bug.cgi?id=161708

        Reviewed by Geoffrey Garen.

        This patch adds a cache for HasOwnProperty. The cache holds tuples
        of {StructureID, UniquedStringImpl*, boolean} where the boolean indicates
        the result of performing hasOwnProperty on an object with StructureID and
        UniquedStringImpl*. If the cache contains an item, we can be guaranteed
        that it contains the same result as performing hasOwnProperty on an
        object O with a given structure and key. To guarantee this, we only add
        items into the cache when the Structure of the given item is cacheable.

        The caching strategy is simple: when adding new items into the cache,
        we will evict any item that was in the location that the new item
        is hashed into. We also clear the cache on every GC. This strategy
        proves to be successful on speedometer, which sees a cache hit rate
        over 90%. This caching strategy is now inlined into the DFG/FTL JITs
        by now recognizing hasOwnProperty as an intrinsic with the corresponding
        HasOwnProperty node. The goal of the node is to emit inlined code for
        the cache lookup to prevent the overhead of the call for the common
        case where we get a cache hit.

        I'm seeing around a 1% to 1.5% percent improvement on Speedometer on
        my machine. Hopefully the perf bots agree with my machine.

        This patch also speeds up the microbenchmark I added by 2.5x.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        (JSC::DFG::SpeculateCellOperand::SpeculateCellOperand):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGValidate.cpp:
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileHasOwnProperty):
        * heap/Heap.cpp:
        (JSC::Heap::collectImpl):
        * jit/JITOperations.h:
        * runtime/HasOwnPropertyCache.h: Added.
        (JSC::HasOwnPropertyCache::Entry::offsetOfStructureID):
        (JSC::HasOwnPropertyCache::Entry::offsetOfImpl):
        (JSC::HasOwnPropertyCache::Entry::offsetOfResult):
        (JSC::HasOwnPropertyCache::operator delete):
        (JSC::HasOwnPropertyCache::create):
        (JSC::HasOwnPropertyCache::hash):
        (JSC::HasOwnPropertyCache::get):
        (JSC::HasOwnPropertyCache::tryAdd):
        (JSC::HasOwnPropertyCache::clear):
        (JSC::VM::ensureHasOwnPropertyCache):
        * runtime/Intrinsic.h:
        * runtime/JSObject.h:
        * runtime/JSObjectInlines.h:
        (JSC::JSObject::hasOwnProperty):
        * runtime/ObjectPrototype.cpp:
        (JSC::ObjectPrototype::finishCreation):
        (JSC::objectProtoFuncHasOwnProperty):
        * runtime/Symbol.h:
        * runtime/VM.cpp:
        * runtime/VM.h:
        (JSC::VM::hasOwnPropertyCache):

2016-09-19  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Make the rounding-related nodes support any type
        https://bugs.webkit.org/show_bug.cgi?id=161895

        Reviewed by Geoffrey Garen.

        This patch changes ArithRound, ArithFloor, ArithCeil and ArithTrunc
        to support polymorphic input without exiting on entry.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        The 4 functions ignore any input past the first argument. It is okay
        to use the nodes with the first argument and let the Phantoms keep
        the remaining arguments live.

        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        Our fixup had the issue we have seen on previous nodes: unaryArithShouldSpeculateInt32()
        prevents us from picking a good type if we do not see any double.

        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        Prediction propagation of those nodes are fully determined
        from their flags and results's prediction. They are moved
        to the invariant processing.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithRounding):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileArithRound):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithFloor):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithCeil):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithTrunc):

2016-09-19  Yusuke Suzuki  <utatane.tea@gmail.com>

        Unreviewed, build fix for Win64
        https://bugs.webkit.org/show_bug.cgi?id=162132

        In Windows 64bit, t3 register in LLInt is not r[a-d]x.
        It means that this cannot be used for byte operation.

        * llint/LowLevelInterpreter64.asm:

2016-09-19  Daniel Bates  <dabates@apple.com>

        Remove ENABLE(TEXT_AUTOSIZING) automatic text size adjustment code
        https://bugs.webkit.org/show_bug.cgi?id=162167

        Reviewed by Simon Fraser.

        * Configurations/FeatureDefines.xcconfig:

2016-09-19  Keith Miller  <keith_miller@apple.com>

        Update WASM towards 0xc
        https://bugs.webkit.org/show_bug.cgi?id=162067

        Reviewed by Geoffrey Garen.

        This patch updates some of the core parts of the WASM frontend to the 0xc standard.
        First, it changes the section names from strings to bytecodes. It also adds support
        for inline block signatures. This is a change from the old version that used to have
        each branch indicate the arity. Finally, this patch updates all the tests and deletes
        a duplicate test.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * testWASM.cpp:
        (runWASMTests):
        * wasm/WASMB3IRGenerator.cpp:
        * wasm/WASMFormat.h:
        * wasm/WASMFunctionParser.h:
        (JSC::WASM::FunctionParser<Context>::FunctionParser):
        (JSC::WASM::FunctionParser<Context>::parseBlock):
        (JSC::WASM::FunctionParser<Context>::parseExpression):
        * wasm/WASMModuleParser.cpp:
        (JSC::WASM::ModuleParser::parse):
        * wasm/WASMSections.cpp: Removed.
        (JSC::WASM::Sections::lookup): Deleted.
        * wasm/WASMSections.h:
        (JSC::WASM::Sections::validateOrder):

2016-09-19  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Use is_cell_with_type for @isRegExpObject, @isMap, and @isSet
        https://bugs.webkit.org/show_bug.cgi?id=162142

        Reviewed by Michael Saboff.

        Use is_cell_with_type for @isRegExpObject, @isMap and @isSet.
        Previously, they were implemented as functions and only @isRegExpObject was handled in the DFG and FTL.
        The recently added op_is_cell_with_type bytecode and DFG IsCellWithType node allows us to simplify the above checks in all JIT tiers.
        Changed these checks to bytecode intrinsics using op_is_cell_with_type.

        * builtins/BuiltinNames.h:
        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecode/SpeculatedType.cpp:
        (JSC::speculationFromJSType):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::emitIsRegExpObject):
        (JSC::BytecodeGenerator::emitIsMap):
        (JSC::BytecodeGenerator::emitIsSet):
        (JSC::BytecodeGenerator::emitIsProxyObject): Deleted.
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_isRegExpObject):
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_isMap):
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_isSet):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * runtime/ECMAScriptSpecInternalFunctions.cpp:
        (JSC::esSpecIsRegExpObject): Deleted.
        * runtime/ECMAScriptSpecInternalFunctions.h:
        * runtime/Intrinsic.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/MapPrototype.cpp:
        (JSC::privateFuncIsMap): Deleted.
        * runtime/MapPrototype.h:
        * runtime/SetPrototype.cpp:
        (JSC::privateFuncIsSet): Deleted.
        * runtime/SetPrototype.h:

2016-09-19  Brian Burg  <bburg@apple.com>

        Web Replay: teach the replay inputs generator to encode and decode OptionSet<T>
        https://bugs.webkit.org/show_bug.cgi?id=162107

        Reviewed by Anders Carlsson.

        Add a new type flag OPTION_SET. This means that the type is a typechecked enum class
        declaration, but it's stored in an OptionSet object and can contain multiple
        distinct enumeration values like an untyped enum declaration.

        Do some cleanup since the generator now supports three different enumerable types:
        'enum', 'enum class', and 'OptionSet<T>' where T is an enum class.

        Also clean up some sloppy variable names. Using an 'enum_' prefix is really confusing now.

        * replay/scripts/CodeGeneratorReplayInputs.py:
        (Type.is_enum_declaration):
        (Type.is_enum_class_declaration):
        (Type.is_option_set):
        (Type):
        (Type.is_enumerable):
        When we want all enumerable types, this property includes all three variants.

        (Type.declaration_kind): Forward-declare OptionSet's type parameter as an enum class.
        (VectorType.is_enum_declaration): Renamed from is_enum().
        (VectorType.is_enum_class_declaration): Renamed from is_enum_class().
        (VectorType.is_option_set): Added.
        (InputsModel.enumerable_types): Added.
        (InputsModel.parse_type_with_framework):
        (Generator.generate_header):
        (Generator.generate_implementation):
        (Generator.generate_includes):
        (Generator.generate_type_forward_declarations):
        (Generator.generate_enumerable_type_trait_declaration):
        (Generator.generate_enum_trait_declaration): Renamed.
        (Generator.generate_enum_trait_implementation): Renamed.

        * replay/scripts/CodeGeneratorReplayInputsTemplates.py:
        Add new templates for OptionSet types. Clean up parameter names and simplify the
        enumerable type declaration template, which is the same for all enumerable type variants.

        * replay/scripts/tests/expected/fail-on-c-style-enum-no-storage.json-error:
        * replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.cpp:
        (JSC::EncodingTraits<Test::PlatformEvent::OtherType>::encodeValue):
        (JSC::EncodingTraits<Test::PlatformEvent::OtherType>::decodeValue):
        * replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.h:
        * replay/scripts/tests/expected/generate-enum-with-guard.json-TestReplayInputs.h:
        Rebaseline test results.

        * replay/scripts/tests/generate-enum-encoding-helpers.json:
        Add a new type for OptionSet<PlatformEvent::Modifier> to capture generated encode/decode methods.

2016-09-19  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC][LLInt] Introduce is_cell_with_type
        https://bugs.webkit.org/show_bug.cgi?id=162132

        Reviewed by Sam Weinig.

        In this patch, we introduce is_cell_with_type bytecode. This bytecode can unify the following predicates,
        op_is_string, op_is_jsarray, op_is_proxy_object, and op_is_derived_array!
        And we now drop DFG node IsString since we can use IsCellWithType instead.
        This automatically offers optimization to previous IsString node: dropping cell check by using CellUse edge filter.

        Later, we are planning to use this is_cell_with_type to optimize @isRegExpObject, @isSet, and @isMap[1].

        The performance results are neutral.

        [1]: https://bugs.webkit.org/show_bug.cgi?id=162142

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecode/SpeculatedType.cpp:
        (JSC::speculationFromJSType):
        * bytecode/SpeculatedType.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitEqualityOp):
        (JSC::BytecodeGenerator::emitIsCellWithType):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::emitIsJSArray):
        (JSC::BytecodeGenerator::emitIsProxyObject):
        (JSC::BytecodeGenerator::emitIsDerivedArray):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::fixupIsCellWithType):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::speculatedTypeForQuery):
        * 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::compileIsString): Deleted.
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_is_cell_with_type):
        (JSC::JIT::emitIsCellWithType): Deleted.
        (JSC::JIT::emit_op_is_string): Deleted.
        (JSC::JIT::emit_op_is_jsarray): Deleted.
        (JSC::JIT::emit_op_is_proxy_object): Deleted.
        (JSC::JIT::emit_op_is_derived_array): Deleted.
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_is_cell_with_type):
        (JSC::JIT::emitIsCellWithType): Deleted.
        (JSC::JIT::emit_op_is_string): Deleted.
        (JSC::JIT::emit_op_is_jsarray): Deleted.
        (JSC::JIT::emit_op_is_proxy_object): Deleted.
        (JSC::JIT::emit_op_is_derived_array): Deleted.
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

2016-09-18  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Assert length of LLInt opcodes using isCellWithType is 3
        https://bugs.webkit.org/show_bug.cgi?id=162134

        Reviewed by Saam Barati.

        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):

2016-09-18  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Do not need to use defineProperty to define methods for object literals
        https://bugs.webkit.org/show_bug.cgi?id=162111

        Reviewed by Saam Barati.

        When we receive the following code,

            var object = { method() { } };

        currently, we use defineProperty to define "method" function for "object".
        This patch replaces it with the ordinary put_by_id_direct / put_by_val_direct
        because the following 2 conditions are met.

        1. While methods in classes have special attributes ({configurable: true, writable: true, enumerable: false}),
           the attributes of methods in object literals is just the same to the other normal properties ({configurable: true, writable: true, enumerable: true}).
           This means that we can use the usual put_by_id_direct / put_by_val_direct to define method properties for object literals.

        2. Furthermore, all the own properties that can reside in objects created by object literals have {configurable: true}.
           So there is no need to check conflict by defineProperty. Always overwriting is OK.

                let name = 'method';
                var object = { get [name]() { }, method() { } };
                // Latter method wins.

            On the other hand, in class syntax, conflict check is necessary since "prototype" own property is defined as {configurable: false}.

                class Hello { static prototype() { } }  // Should throw error by defineProperty's check.

            This means that conflict check done in defneProperty is not necessary for object literals' properties.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::PropertyListNode::emitPutConstantProperty):

2016-09-16  Yusuke Suzuki  <utatane.tea@gmail.com>

        [DFG] Introduce IsCellWithType node and unify IsJSArray, IsRegExpObject and newly added IsProxyObject
        https://bugs.webkit.org/show_bug.cgi?id=162000

        Reviewed by Filip Pizlo.

        Sampling profiler tells that ES6SampleBench/Basic frequently calls Array.isArray(). This function is introduced in
        ES5 and it is well-used to distinguish Array from the other objects. Moreover, this function is used in Array.prototype.xxx
        methods as @isArray. So it's worth optimizing.

        The difference between Array.isArray and @isJSArray is that Array.isArray need to consider about ProxyObject while
        @isJSArray builtin intrinsic does not. So in this patch, we leverage the existing @isJSArray to implement Array.isArray.
        Array.isArray is written in builtin JS code using @isJSArray and newly added @isProxyObject(). That allow us to inline
        Array.isArray() code and the inlined code uses existing DFG nodes well.

        Another problem is RuntimeArray and ArrayPrototype. They inherit JSArray and their JSType is ObjectType. But Array.isArray need
        to return true for those types. While optimizing type checking in generic way by type display is nice, RuntimeArray and
        ArrayPrototype are a bit tricky and it is super rare that these functions are passed to Array.isArray(). So instead of introducing
        type display in this patch, we just introduce a new JSType, DerivedArrayType and use it in the above 2 use classes. Since
        Array.isArray is specially handled in the spec (while we don't have any Date.isDate() like functions, only Array.isArray
        is specified in the spec because we frequently want to distinguish Arrays from other Objects), optimizing Array.isArray specially
        by introducing special DerivedArrayType is reasonable.

        In LLInt level, we add a new opcode, op_is_proxy_object and op_is_derived_array. This works similar to op_is_jsarray.
        And we also perform LLInt code cleanup by introducing a macro isCellWithType.

        In baseline, we perform some clean up for op_is_proxy_object etc. Now duplicate code is reduced.

        In DFG, we unify IsJSArray, IsRegExpObject, IsProxyObject, and IsDerivedArray into one IsCellWithType node. And we clean up
        some AI code related to IsJSArray and IsRegExpObject since SpeculatedType now recognizes ProxyObject. IsJSArray and IsRegExpObject
        does not do anything special for proxy objects.

        The above change simplify things to create a new IsXXX DFG handling and paves the way for optimizing @isMap & @isSet in DFG.
        Furthermore, introducing @isProxyObject() is nice for the first step to optimize ProxyObject handling.

        Here is microbenchmark result. We can see stable performance improvement (Even if we use Proxies!).

                                                    baseline                  patched

            is-array-for-array                   2.5156+-0.0288     ^      2.0668+-0.0285        ^ definitely 1.2171x faster
            is-array-for-mixed-case              4.7787+-0.0755     ^      4.4722+-0.0789        ^ definitely 1.0686x faster
            is-array-for-non-array-object        2.3596+-0.0368     ^      1.8178+-0.0262        ^ definitely 1.2980x faster
            is-array-for-proxy                   4.0469+-0.0437     ^      3.3845+-0.0404        ^ definitely 1.1957x faster

        And ES6SampleBench/Basic reports 5.2% perf improvement. And now sampling result in ES6SampleBench/Basic does not pose Array.isArray.

            Benchmark             First Iteration        Worst 2%               Steady State
            baseline:Basic        28.59 ms +- 1.03 ms    15.08 ms +- 0.28 ms    1656.96 ms +- 18.02 ms
            patched:Basic         27.82 ms +- 0.44 ms    14.59 ms +- 0.16 ms    1574.65 ms +- 8.44 ms

        * builtins/ArrayConstructor.js:
        (isArray):
        (from): Deleted.
        * builtins/BuiltinNames.h:
        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecode/SpeculatedType.cpp:
        (JSC::dumpSpeculation):
        (JSC::speculationFromClassInfo):
        (JSC::speculationFromStructure):
        * bytecode/SpeculatedType.h:
        (JSC::isProxyObjectSpeculation):
        (JSC::isDerivedArraySpeculation):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::emitIsProxyObject):
        (JSC::BytecodeGenerator::emitIsDerivedArray):
        (JSC::BytecodeGenerator::emitIsJSArray): Deleted.
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_isProxyObject):
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_isDerivedArray):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::fixupIsCellWithType):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasQueriedType):
        (JSC::DFG::Node::queriedType):
        (JSC::DFG::Node::hasSpeculatedTypeForQuery):
        (JSC::DFG::Node::speculatedTypeForQuery):
        (JSC::DFG::Node::shouldSpeculateProxyObject):
        (JSC::DFG::Node::shouldSpeculateDerivedArray):
        (JSC::DFG::Node::loadVarargsData): Deleted.
        (JSC::DFG::Node::shouldSpeculateArray): Deleted.
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::SafeToExecuteEdge::operator()):
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileIsCellWithType):
        (JSC::DFG::SpeculativeJIT::speculateProxyObject):
        (JSC::DFG::SpeculativeJIT::speculateDerivedArray):
        (JSC::DFG::SpeculativeJIT::speculate):
        (JSC::DFG::SpeculativeJIT::compileIsJSArray): Deleted.
        (JSC::DFG::SpeculativeJIT::compileIsRegExpObject): Deleted.
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGUseKind.cpp:
        (WTF::printInternal):
        * dfg/DFGUseKind.h:
        (JSC::DFG::typeFilterFor):
        (JSC::DFG::isCell):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsCellWithType):
        (JSC::FTL::DFG::LowerDFGToB3::speculate):
        (JSC::FTL::DFG::LowerDFGToB3::isCellWithType):
        (JSC::FTL::DFG::LowerDFGToB3::speculateProxyObject):
        (JSC::FTL::DFG::LowerDFGToB3::speculateDerivedArray):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsJSArray): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::compileIsRegExpObject): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::isArray): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::isRegExpObject): Deleted.
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emitIsCellWithType):
        (JSC::JIT::emit_op_is_string):
        (JSC::JIT::emit_op_is_jsarray):
        (JSC::JIT::emit_op_is_proxy_object):
        (JSC::JIT::emit_op_is_derived_array):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emitIsCellWithType):
        (JSC::JIT::emit_op_is_string):
        (JSC::JIT::emit_op_is_jsarray):
        (JSC::JIT::emit_op_is_proxy_object):
        (JSC::JIT::emit_op_is_derived_array):
        * jsc.cpp:
        (WTF::RuntimeArray::createStructure):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/ArrayConstructor.cpp:
        (JSC::ArrayConstructor::finishCreation):
        (JSC::isArraySlowInline):
        (JSC::isArraySlow):
        (JSC::arrayConstructorPrivateFuncIsArraySlow):
        (JSC::arrayConstructorIsArray): Deleted.
        * runtime/ArrayConstructor.h:
        (JSC::isArray):
        * runtime/ArrayPrototype.h:
        (JSC::ArrayPrototype::createStructure):
        * runtime/JSArray.h:
        (JSC::JSArray::finishCreation):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSType.h:

2016-09-16  Yusuke Suzuki  <utatane.tea@gmail.com>

        [DFG] Introduce ArrayUse
        https://bugs.webkit.org/show_bug.cgi?id=162063

        Reviewed by Keith Miller.

        ArrayUse is particularly useful: for IsJSArray.
        We can drop IsJSArray in fixup phase by setting ArrayUse edge filter.

        Since @isJSArray user is limited (Array.prototype.concat), the effect of this patch is small.
        But later, I'll update {@isArray, Array.isArray} to use @isJSArray[1]. In that patch, we are planning
        to implement more aggressive optimization like, setting CellUse edge filter to avoid cell check in
        SpeculativeJIT::compileIsJSArray.

        In the benchmark using Array.prototype.concat, we can see perf improvement since we can drop IsJSArray in fixup phase.

                                                     baseline                  patched

            lazy-array-species-watchpoints       25.0911+-0.0516     ^     24.7687+-0.0767        ^ definitely 1.0130x faster

        [1]: https://bugs.webkit.org/show_bug.cgi?id=162000

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::SafeToExecuteEdge::operator()):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::speculateArray):
        (JSC::DFG::SpeculativeJIT::speculate):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGUseKind.cpp:
        (WTF::printInternal):
        * dfg/DFGUseKind.h:
        (JSC::DFG::typeFilterFor):
        (JSC::DFG::isCell):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::speculate):
        (JSC::FTL::DFG::LowerDFGToB3::speculateArray):
        (JSC::FTL::DFG::LowerDFGToB3::speculateObject): Deleted.

2016-09-16  Joseph Pecoraro  <pecoraro@apple.com>

        test262: Various Constructors length properties should be configurable
        https://bugs.webkit.org/show_bug.cgi?id=161998

        Reviewed by Saam Barati.

        https://tc39.github.io/ecma262/#sec-ecmascript-standard-built-in-objects
        Unless otherwise specified, the length property of a built-in Function
        object has the attributes:
        { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: true }.

        * runtime/ErrorConstructor.cpp:
        (JSC::ErrorConstructor::finishCreation):
        * runtime/JSPromiseConstructor.cpp:
        (JSC::JSPromiseConstructor::finishCreation):
        * runtime/MapConstructor.cpp:
        (JSC::MapConstructor::finishCreation):
        * runtime/NativeErrorConstructor.cpp:
        (JSC::NativeErrorConstructor::finishCreation):
        * runtime/ProxyConstructor.cpp:
        (JSC::ProxyConstructor::finishCreation):
        * runtime/SetConstructor.cpp:
        (JSC::SetConstructor::finishCreation):
        * runtime/WeakMapConstructor.cpp:
        (JSC::WeakMapConstructor::finishCreation):
        * runtime/WeakSetConstructor.cpp:
        (JSC::WeakSetConstructor::finishCreation):

2016-09-16  Youenn Fablet  <youenn@apple.com>

        Custom promise-returning functions should not throw if callee has not the expected type
        https://bugs.webkit.org/show_bug.cgi?id=162011

        Reviewed by Sam Weinig.

        * JavaScriptCore.xcodeproj/project.pbxproj: Making JSPromiseConstructor.h private

2016-09-15  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION (r205462): Lot of leaks
        https://bugs.webkit.org/show_bug.cgi?id=161946

        Reviewed by Saam Barati.
        
        We were forgetting to delete LargeAllocations on VM exit!

        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::~MarkedSpace):

2016-09-15  Keith Miller  <keith_miller@apple.com>


        Pragma out undefined-var-template warnings in JSC for JSObjects that are templatized
        https://bugs.webkit.org/show_bug.cgi?id=161985

        Reviewed by Alex Christensen.

        I started a true fix for this in
        https://bugs.webkit.org/show_bug.cgi?id=161979, however the fix
        for this issue is not sustainable. Since the scope of this issue
        is just limited to the static const ClassInfo member it is
        simpler to just pragma out this warning. This works because
        COMDAT will, AFAIK, pick the actual specialization.  If, in the
        future, we want to expose these classes to WebCore we will need to
        do what we do for JSGenericTypedArrayViews and create a custom
        info() function with a switch.

        This patch also fixes a bunch of weak external symbols due to one of:
        1) out of line template member definitions functions not being marked inline.
        2) inline member functions definitions being marked as exported.
        3) missing header file includes for forward function declarations.

        * API/JSCallbackObject.h:
        * b3/B3ValueInlines.h:
        (JSC::B3::Value::as):
        * runtime/HashMapImpl.cpp:
        (JSC::getHashMapBucketKeyClassInfo):
        (JSC::getHashMapBucketKeyValueClassInfo):
        (JSC::getHashMapImplKeyClassInfo):
        (JSC::getHashMapImplKeyValueClassInfo):
        * runtime/HashMapImpl.h:
        (JSC::HashMapBucket::info):
        (JSC::HashMapImpl::info):
        * runtime/JSCJSValue.h:
        (JSC::toUInt32): Deleted.
        * runtime/JSGenericTypedArrayView.h:
        (JSC::JSGenericTypedArrayView::setIndexQuicklyToDouble):
        * runtime/JSGenericTypedArrayViewConstructor.h:
        * runtime/JSGenericTypedArrayViewPrototype.h:
        * runtime/MathCommon.h:
        (JSC::toUInt32):
        * runtime/TypedArrayAdaptors.h:
        * runtime/VM.h:
        (JSC::VM::watchdog):
        (JSC::VM::heapProfiler):
        (JSC::VM::samplingProfiler):

2016-09-14  Filip Pizlo  <fpizlo@apple.com>

        There is no good reason for WeakBlock to care about newly allocated objects
        https://bugs.webkit.org/show_bug.cgi?id=162006

        Reviewed by Geoffrey Garen.

        WeakBlock scans itself in two modes:

        visit: if a Weak in the block belongs to an unmarked object, ask the Weak to consider whether
            it should do things.
        
        reap: if a Weak in a block belongs to an unmarked object, delete the Weak.

        Except that "unmarked" has a peculiar meaning: WeakBlock defines it as
        !markedOrNewlyAllocated. So, a newly allocated object will never be consulted about anything. 
        That sounds scary until you realize that newlyAllocated must have been cleared before we even
        got here.

        So, we were paying the price of checking newlyAllocated for no reason. This switches the code
        to using isMarked(). I don't know why the code previously checked newlyAllocated, but I do
        trust my reasoning.

        * heap/LargeAllocation.h:
        (JSC::LargeAllocation::isMarkedDuringWeakVisiting):
        (JSC::LargeAllocation::isMarkedOrNewlyAllocatedDuringWeakVisiting): Deleted.
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::isMarkedDuringWeakVisiting):
        (JSC::MarkedBlock::isMarkedOrNewlyAllocatedDuringWeakVisiting): Deleted.
        * heap/WeakBlock.cpp:
        (JSC::WeakBlock::specializedVisit):
        (JSC::WeakBlock::reap):

2016-09-15  Commit Queue  <commit-queue@webkit.org>

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

        Tests for this change fail on 32-bit JSC bots (Requested by
        ryanhaddad on #webkit).

        Reverted changeset:

        "[JSC] Make the rounding-related nodes support any type"
        https://bugs.webkit.org/show_bug.cgi?id=161895
        http://trac.webkit.org/changeset/205931

2016-09-15  Joseph Pecoraro  <pecoraro@apple.com>

        test262: Should be a SyntaxError for duplicate parameter names in function with default parameters
        https://bugs.webkit.org/show_bug.cgi?id=162013

        Reviewed by Saam Barati.

        https://tc39.github.io/ecma262/#sec-function-definitions-static-semantics-early-errors
        It is a Syntax Error if IsSimpleParameterList of FormalParameterList is
        false and BoundNames of FormalParameterList contains any duplicate elements.

        Non-simple parameter lists include rest parameters, destructuring,
        and default parameters.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFormalParameters):
        Previously, we were not failing if there were default parameters
        early in the parameter list that were not yet identified as duplicates
        and simple parameters later were duplicates. Now, we fail if there
        are default parameters anywhere in the parameter list with a duplicate.

2016-09-14  Joseph Pecoraro  <pecoraro@apple.com>

        ASSERT_NOT_REACHED when using spread inside an array literal with Function.prototype.apply
        https://bugs.webkit.org/show_bug.cgi?id=162003

        Reviewed by Saam Barati.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::ArrayNode::isSimpleArray):
        Don't treat an Array that has a spread expression inside it as simple.
        This avoids a fast path for f.apply(x, simpleArray) that was not handling
        spread expressions within arrays, and instead taking a path that can
        handle the spreading.

2016-09-14  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r205933 and r205936.
        https://bugs.webkit.org/show_bug.cgi?id=162002

        broke the build (Requested by keith_miller on #webkit).

        Reverted changesets:

        "Pragma out undefined-var-template warnings in JSC for
        JSObjects that are templatized"
        https://bugs.webkit.org/show_bug.cgi?id=161985
        http://trac.webkit.org/changeset/205933

        "Unreviewed, fix the Windows build."
        http://trac.webkit.org/changeset/205936

2016-09-14  Chris Dumez  <cdumez@apple.com>

        REGRESSION (r205670): ASSERTION FAILED: methodTable(vm)->toThis(this, exec, NotStrictMode) == this
        https://bugs.webkit.org/show_bug.cgi?id=161982

        Reviewed by Saam Barati.

        Update JSProxy::setPrototype() to return false unconditionally instead
        of forwarding the call to its target. We used to forward to the target
        and then the JSDOMWindow's [[SetPrototypeOf]] would return false.
        However, the JSC tests use a different GlobalObject and forwarding
        the setPrototypeOf() call to the GlobalObject lead to hitting an
        assertion. This patch aligns the behavior of the GlobalObject used by
        the JSC tests with JSDOMWindow.

        * runtime/JSProxy.cpp:
        (JSC::JSProxy::setPrototype):

2016-09-14  Michael Saboff  <msaboff@apple.com>

        YARR doesn't check for invalid flags for literal regular expressions
        https://bugs.webkit.org/show_bug.cgi?id=161995

        Reviewed by Mark Lam.

        Added a new error and a check that the flags are valid when we create a
        literal regular expression.

        * runtime/RegExp.cpp:
        (JSC::RegExp::finishCreation):
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::YarrPattern::errorMessage):
        (JSC::Yarr::YarrPattern::compile):
        * yarr/YarrPattern.h:

2016-09-14  Keith Miller  <keith_miller@apple.com>

        Unreviewed, fix the Windows build.

        * runtime/HashMapImpl.cpp:

2016-09-14  Keith Miller  <keith_miller@apple.com>

        Pragma out undefined-var-template warnings in JSC for JSObjects that are templatized
        https://bugs.webkit.org/show_bug.cgi?id=161985

        Reviewed by Geoffrey Garen.

        I started a true fix for this in
        https://bugs.webkit.org/show_bug.cgi?id=161979, however the fix
        for this issue is not sustainable. Since the scope of this issue
        is just limited to the static const ClassInfo member it is
        simpler to just pragma out this warning. This works because
        COMDAT will, AFAIK, pick the actual specialization.  If, in the
        future, we want to expose these classes to WebCore we will need to
        do what we do for JSGenericTypedArrayViews and create a custom
        info() function with a switch.

        This patch also fixes a bunch of weak external symbols due to one of:
        1) out of line template member definitions functions not being marked inline.
        2) inline member functions definitions being marked as exported.
        3) missing header file includes for forward function declarations.

        * API/JSCallbackObject.h:
        * b3/B3ValueInlines.h:
        (JSC::B3::Value::as):
        * runtime/HashMapImpl.h:
        * runtime/JSCJSValue.h:
        (JSC::toUInt32): Deleted.
        * runtime/JSGenericTypedArrayView.h:
        (JSC::JSGenericTypedArrayView::setIndexQuicklyToDouble):
        * runtime/JSGenericTypedArrayViewConstructor.h:
        * runtime/JSGenericTypedArrayViewPrototype.h:
        * runtime/MathCommon.h:
        (JSC::toUInt32):
        * runtime/TypedArrayAdaptors.h:
        * runtime/VM.h:
        (JSC::VM::watchdog):
        (JSC::VM::heapProfiler):
        (JSC::VM::samplingProfiler):

2016-09-14  Joseph Pecoraro  <pecoraro@apple.com>

        test262: TypedArray constructors length should be 3 and configurable
        https://bugs.webkit.org/show_bug.cgi?id=161955

        Reviewed by Mark Lam.

        https://tc39.github.io/ecma262/#sec-ecmascript-standard-built-in-objects
        Unless otherwise specified, the length property of a built-in Function
        object has the attributes:
        { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: true }.

        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):

2016-09-14  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Make the rounding-related nodes support any type
        https://bugs.webkit.org/show_bug.cgi?id=161895

        Reviewed by Geoffrey Garen.

        This patch changes ArithRound, ArithFloor, ArithCeil and ArithTrunc
        to support polymorphic input without exiting on entry.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        The 4 functions ignore any input past the first argument. It is okay
        to use the nodes with the first argument and let the Phantoms keep
        the remaining arguments live.

        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        Our fixup had the issue we have seen on previous nodes: unaryArithShouldSpeculateInt32()
        prevents us from picking a good type if we do not see any double.

        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        Prediction propagation of those nodes are fully determined
        from their flags and results's prediction. They are moved
        to the invariant processing.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithRounding):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileArithRound):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithFloor):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithCeil):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithTrunc):

2016-09-14  Filip Pizlo  <fpizlo@apple.com>

        Remove Heap::setMarked()

        Rubber stamped by Keith Miller.
        
        Nobody uses this function.

        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::setMarked): Deleted.
        * heap/LargeAllocation.h:
        (JSC::LargeAllocation::testAndSetMarked):
        (JSC::LargeAllocation::setMarked): Deleted.
        * heap/MarkedBlock.h:

2016-09-14  Mark Lam  <mark.lam@apple.com>

        Use Options::validateExceptionChecks() instead of VM::m_verifyExceptionEvents.
        https://bugs.webkit.org/show_bug.cgi?id=161975

        Reviewed by Keith Miller.

        This makes it less burdensome (no longer needs a rebuild to enable checks) to do
        incremental work towards enabling checks all the time.

        * runtime/Options.h:
        * runtime/VM.cpp:
        (JSC::VM::verifyExceptionCheckNeedIsSatisfied):
        * runtime/VM.h:

2016-09-14  Joseph Pecoraro  <pecoraro@apple.com>

        TaggedTemplateString function calls should emit tail position calls
        https://bugs.webkit.org/show_bug.cgi?id=161948

        Reviewed by Yusuke Suzuki.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::TaggedTemplateNode::emitBytecode):
        The tagged template string function call can be a tail call:
        https://tc39.github.io/ecma262/#sec-tagged-templates-runtime-semantics-evaluation

2016-09-14  Joseph Pecoraro  <pecoraro@apple.com>

        test262: Array.prototype.slice should always set length
        https://bugs.webkit.org/show_bug.cgi?id=161953

        Reviewed by Mark Lam.

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

2016-09-13  Michael Saboff  <msaboff@apple.com>

        Promises aren't resolved properly when making a ObjC API callback
        https://bugs.webkit.org/show_bug.cgi?id=161929

        Reviewed by Geoffrey Garen.

        When we go to call out to an Objective C function registered via the API,
        we first drop all JSC locks to make the call.  As part of dropping the locks,
        we drain the microtask queue that is used among other things for handling deferred
        promise resolution.  The DropAllLocks scope class that drops the locks while in
        scope, resets the current thread's AtomicStringTable to the default table.  This
        is wrong for two reasons, first it happens before we drain the microtask queue and
        second it isn't needed as JSLock::willReleaseLock() restores the current thread's
        AtomicStringTable to the table before the lock was acquired.

        In fact, the manipulation of the current thread's AtomicStringTable is already 
        properly handled as a stack in JSLock::didAcquireLock() and willReleaseLock().
        Therefore the manipulation of the AtomicStringTable in DropAllLocks constructor
        and destructor should be removed.

        * API/tests/testapi.mm:
        (testObjectiveCAPIMain): Added a new test.
        * runtime/JSLock.cpp:
        (JSC::JSLock::DropAllLocks::DropAllLocks):
        (JSC::JSLock::DropAllLocks::~DropAllLocks):

2016-09-13  Filip Pizlo  <fpizlo@apple.com>

        Remove Heap::isLive()
        https://bugs.webkit.org/show_bug.cgi?id=161933

        Reviewed by Mark Lam.
        
        Before I put any more effort into maintaining this weird function, I decided to check how it
        was used. It turns out it's not.

        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::isLive): Deleted.

2016-09-13  Mark Lam  <mark.lam@apple.com>

        DFG NewArrayBuffer node should watch for "have a bad time" state change.
        https://bugs.webkit.org/show_bug.cgi?id=161927
        <rdar://problem/27995222>

        Reviewed by Geoffrey Garen.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):

2016-09-13  JF Bastien  <jfbastien@apple.com>

        Support jsc shell builtin `read`
        https://bugs.webkit.org/show_bug.cgi?id=161662

        Reviewed by Keith Miller.

        The jsc shell currently supports a `readFile` method which returns
        a string. SpiderMonkey's js shell and V8's d8 shell both support
        similar file-to-string functions, as well as a
        binary-file-to-Uint8Array function. jsc should support a similar
        binary file method to simplify testing, including testing of
        WebAssembly blobs.

        Emscripten's shell.js (which is also used for some WebAssembly
        things) has a polyfill [1] for a builtin called `read`. jsc should
        therefore have a builtin with the same name if we want things to
        "Just Work".

          [1]: https://github.com/kripken/emscripten/blob/5f0918409a1407dd168f57cfa34b109cd1770a8a/src/shell.js#L138

        * jsc.cpp:
        (GlobalObject::finishCreation): add `read`, make `readFile` take up to 2 arguments.
        (functionReadFile): support binary files, as per SpiderMonkey.
        * runtime/Error.h:
        (JSC::throwVMError): convenience function, I'll add more uses in a follow-up
        * runtime/JSTypedArrays.cpp:
        (JSC::createUint8TypedArray): JS private export of JSUint8Array::create.
        * runtime/JSTypedArrays.h: expose private export.

2016-09-12  Skachkov Oleksandr  <gskachkov@gmail.com>

        ES6: Classes: Should be allowed to create a static method with name "arguments"
        https://bugs.webkit.org/show_bug.cgi?id=152985

        Reviewed by Keith Miller.

        Current patch covered 16.2 Forbidden Extensions - first topic 
        (https://tc39.github.io/ecma262/#sec-forbidden-extensions) ECMAScript Functions 
        should not have own properties named "caller" or "arguments".
        Also added possibility to declare static methods and getters with 
        name 'arguments' and 'caller' for classes. i.e.:
        class A { static arguments() { return 'value'; } }
        A.arguments() === 'value';
        To implement this patch 'caller' and 'arguments' were put to the FunctionPrototype
        object. Also was changed approach to init throwTypeErrorArgumentsCalleeAndCallerGetterSetter
        property from Lazy to common because it necessary to use execState during init of the accessors 
        properties.

        * runtime/Executable.h:
        * runtime/FunctionPrototype.cpp:
        (JSC::FunctionPrototype::initRestrictedProperties):
        (JSC::FunctionPrototype::addFunctionProperties): Deleted.
        * runtime/FunctionPrototype.h:
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::getOwnPropertySlot):
        (JSC::JSFunction::getOwnNonIndexPropertyNames):
        (JSC::JSFunction::put):
        (JSC::JSFunction::deleteProperty):
        (JSC::JSFunction::defineOwnProperty):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::throwTypeErrorArgumentsCalleeAndCallerGetterSetter):

2016-09-12  Filip Pizlo  <fpizlo@apple.com>

        MarkedBlock should be able to use flipIfNecessary() as the "I'm not empty" trigger
        https://bugs.webkit.org/show_bug.cgi?id=161869

        Reviewed by Saam Barati.
        
        In bug 161581, I'm going to use flipIfNecessary() during marking to trigger the "I'm not
        empty" hook, which will set a bit in the markingNotEmpty bitvector.
        
        For this to work, we need to ensure that nobody else uses flipIfNecessary() during marking.
        If anyone else does it but they aren't marking new objects, then this prevents
        flipIfNecessary() from triggering when the first object is marked, which means we won't
        always detect when a block became non-empty.
        
        I addressed this by adding a isMarking flag, and asserting in flipIfNecessary() that the flag
        isn't set. flipIfNecessaryDuringMarking() is used only on the marking path, so that code
        knows that it can trigger something like noteMarked(). The only places that were using
        flipIfNecessary() should have been using needsFlip() anyway.

        * heap/CellContainer.h:
        * heap/CellContainerInlines.h:
        (JSC::CellContainer::needsFlip):
        * heap/Heap.cpp:
        (JSC::Heap::markRoots):
        (JSC::Heap::beginMarking):
        (JSC::Heap::endMarking):
        (JSC::Heap::clearLivenessData): Deleted.
        (JSC::Heap::converge): Deleted.
        (JSC::Heap::resetVisitors): Deleted.
        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::testAndSetMarked):
        * heap/LargeAllocation.h:
        (JSC::LargeAllocation::flipIfNecessaryDuringMarking):
        (JSC::LargeAllocation::flipIfNecessaryConcurrently): Deleted.
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::flipIfNecessarySlow):
        (JSC::MarkedBlock::flipIfNecessaryDuringMarkingSlow):
        (JSC::MarkedBlock::flipIfNecessaryConcurrentlySlow): Deleted.
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::flipIfNecessaryDuringMarking):
        (JSC::MarkedBlock::Handle::flipIfNecessaryDuringMarking):
        (JSC::MarkedBlock::flipIfNecessaryConcurrently): Deleted.
        (JSC::MarkedBlock::Handle::flipIfNecessaryConcurrently): Deleted.
        * heap/MarkedSpace.h:
        (JSC::MarkedSpace::isMarking):
        (JSC::MarkedSpace::setIsMarking):
        (JSC::MarkedSpace::largeAllocationsForThisCollectionSize): Deleted.
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
        * heap/WeakBlock.cpp:
        (JSC::WeakBlock::visit):

2016-09-12  Saam Barati  <sbarati@apple.com>

        HashMapImpl should take into account m_deleteCount in its load factor and it should be able to rehash the table to be smaller
        https://bugs.webkit.org/show_bug.cgi?id=161640

        Reviewed by Geoffrey Garen.

        HashMapImpl now takes into account m_deleteCount in its load factor.
        It now knows how to rehash to either decrease its capacity, stay at
        the same capacity, or increase its capacity. The reason we can sometimes
        stay at the same capacity is that we can reduce the load factor enough
        by rehashing that growing isn't warranted. The reason for this is that
        anytime we rehash, we remove all deleted sentinels from the buffer.
        Therefore, staying at the same same capacity, when there are deleted entries,
        can still reduce the load factor because it removes all deleted sentinels.

        * runtime/HashMapImpl.h:
        (JSC::HashMapBuffer::create):
        (JSC::HashMapBuffer::reset):
        (JSC::HashMapImpl::HashMapImpl):
        (JSC::HashMapImpl::add):
        (JSC::HashMapImpl::remove):
        (JSC::HashMapImpl::size):
        (JSC::HashMapImpl::clear):
        (JSC::HashMapImpl::approximateSize):
        (JSC::HashMapImpl::shouldRehashAfterAdd):
        (JSC::HashMapImpl::shouldShrink):
        (JSC::HashMapImpl::rehash):
        (JSC::HashMapImpl::checkConsistency):
        (JSC::HashMapImpl::makeAndSetNewBuffer):
        (JSC::HashMapImpl::assertBufferIsEmpty):

2016-09-12  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Use GetArrayLength for JSArray.length even when the array type is undecided
        https://bugs.webkit.org/show_bug.cgi?id=161671

        Reviewed by Geoffrey Garen.

        UndecidedShape is a type with storage. When we allocate an uninitialized JSArray,
        it gets a butterfly with its length.
        When we were querying that length, we were generating a generic GetById with inline cache.

        This patch adds the missing bits to treat Undecided like the other types with storage.

        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::canBecomeGetArrayLength):
        (JSC::DFG::ArrayMode::refine):
        * dfg/DFGArrayMode.h:
        (JSC::DFG::ArrayMode::usesButterfly):
        (JSC::DFG::ArrayMode::lengthNeedsStorage):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::checkArray):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileGetArrayLength):

2016-09-12  Yusuke Suzuki  <utatane.tea@gmail.com>

        [DFG][FTL] Add ArithTan
        https://bugs.webkit.org/show_bug.cgi?id=161857

        Reviewed by Filip Pizlo.

        While ArithSin and ArithCos are supported, ArithTan is not supported yet.
        And we also find that Math.tan is included in MotionMark's Multiply benchmark.

        This patch adds ArithTan support in DFG and FTL. And it also cleans up the
        existing ArithSin, ArithCos, and ArithLog compilations by unifying them.
        The microbenchmark shows the 9% perf improvement.

            tan    322.4819+-0.3766     ^    295.8700+-0.3094        ^ definitely 1.0899x faster

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithDoubleUnaryOp):
        (JSC::DFG::SpeculativeJIT::compileArithCos):
        (JSC::DFG::SpeculativeJIT::compileArithTan):
        (JSC::DFG::SpeculativeJIT::compileArithSin):
        (JSC::DFG::SpeculativeJIT::compileArithLog):
        * 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::compileArithTan):
        * ftl/FTLOutput.cpp:
        (JSC::FTL::Output::doubleTan):
        * ftl/FTLOutput.h:
        * runtime/Intrinsic.h:
        * runtime/MathObject.cpp:
        (JSC::MathObject::finishCreation):

2016-09-12  Saam Barati  <sbarati@apple.com>

        MapHash should do constant folding when it has a constant argument and its legal to hash that value
        https://bugs.webkit.org/show_bug.cgi?id=161639

        Reviewed by Filip Pizlo.

        We now constant fold the MapHash node. We're careful to not resolve
        ropes from the compiler thread, and to only hash strings if they're
        not too large. The microbenchmark I added runs about 12% faster with
        this patch.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * runtime/HashMapImpl.h:
        (JSC::wangsInt64Hash):
        (JSC::jsMapHash):
        (JSC::concurrentJSMapHash):

2016-09-11  Filip Pizlo  <fpizlo@apple.com>

        DFG::forAllKilledOperands() could use a faster bitvector scan in the same-inline-stack fast path
        https://bugs.webkit.org/show_bug.cgi?id=161849

        Reviewed by Saam Barati.
        
        This is a fairly obvious change. This turns a loop that would query each bit individually
        into a loop that will process a word at a time. I would expect a very tiny progression in
        DFG compile times.
        
        This also gave me an opportunity to test and fix the new FastBitVector functionality.

        * dfg/DFGForAllKills.h:
        (JSC::DFG::forAllKilledOperands):

2016-09-11  Filip Pizlo  <fpizlo@apple.com>

        FastBitVector should have efficient and easy-to-use vector-vector operations
        https://bugs.webkit.org/show_bug.cgi?id=161847

        Reviewed by Saam Barati.
        
        Adapt existing users of FastBitVector to the new API.

        * bytecode/BytecodeLivenessAnalysis.cpp:
        (JSC::BytecodeLivenessAnalysis::computeKills):
        (JSC::BytecodeLivenessAnalysis::dumpResults):
        * bytecode/BytecodeLivenessAnalysisInlines.h:
        (JSC::operandThatIsNotAlwaysLiveIsLive):
        (JSC::BytecodeLivenessPropagation<DerivedAnalysis>::stepOverInstruction):
        (JSC::BytecodeLivenessPropagation<DerivedAnalysis>::runLivenessFixpoint):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::validate):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::flushForTerminal):
        * dfg/DFGForAllKills.h:
        (JSC::DFG::forAllKilledOperands):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
        * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
        (JSC::DFG::LiveCatchVariablePreservationPhase::willCatchException):
        (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlock):
        * dfg/DFGNaturalLoops.cpp:
        (JSC::DFG::NaturalLoops::NaturalLoops):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::cleanMustHandleValuesIfNecessary):

2016-09-10  Chris Dumez  <cdumez@apple.com>

        parseHTMLInteger() should take a StringView in parameter
        https://bugs.webkit.org/show_bug.cgi?id=161669

        Reviewed by Ryosuke Niwa.

        * runtime/DateConversion.cpp:
        (JSC::formatDateTime):
        Explicitly construct a String from the const WCHAR* on Windows because
        it is ambiguous otherwise now that there is a StringBuilder::append()
        overload taking an AtomicString in.

2016-09-08  Keith Miller  <keith_miller@apple.com>

        WASM should support if-then-else
        https://bugs.webkit.org/show_bug.cgi?id=161778

        Reviewed by Michael Saboff.

        This patch makes some major changes to the way that the WASM
        function parser works. First, the control stack has been moved
        from the parser's context to the parser itself. This simplifies
        the way that the parser works and allows us to make the decoder
        iterative rather than recursive. Since the control stack has been
        moved to the parser, any context operation that refers to some
        block now receives that block by reference.

        For any if block, regardless of whether or not it is an
        if-then-else or not, we will allocate both the entire control flow
        diamond. This is not a major issue in the if-then case since B3
        will immediately cleanup these blocks. In order to support if-then
        and if-then-else we needed to be able to distinguish what the type
        of the top block on the control stack is. This will be necessary
        when validating the else opcode in the future. In the B3 IR
        generator we decide to the type of the block strictly by the
        shape.

        Currently, if blocks don't handle passed and returned stack values
        correctly. I plan to fix this when I add support for the block
        signatures. See: https://github.com/WebAssembly/design/pull/765

        * testWASM.cpp:
        (runWASMTests):
        * wasm/WASMB3IRGenerator.cpp:
        (dumpProcedure):
        (JSC::WASM::parseAndCompile):
        * wasm/WASMB3IRGenerator.h:
        * wasm/WASMFunctionParser.h:
        (JSC::WASM::FunctionParser<Context>::parseBlock):
        (JSC::WASM::FunctionParser<Context>::parseExpression):
        (JSC::WASM::FunctionParser<Context>::parseUnreachableExpression):
        * wasm/WASMOps.h:

2016-09-09  Filip Pizlo  <fpizlo@apple.com>

        jsc.cpp should call initializeMainThread() to make sure that GC thread assertions work
        https://bugs.webkit.org/show_bug.cgi?id=161801

        Reviewed by Keith Miller.
        
        The GC has debug assertions that certain things don't happen on GC threads. Those assertions
        are no-ops unless initializeGCThreads() is called, and I think the most canonical way to do
        that is to call initializeMainThread().

        * jsc.cpp:
        (jscmain):

2016-09-09  Saam Barati  <sbarati@apple.com>

        Make hasOwnProperty ALWAYS_INLINE
        https://bugs.webkit.org/show_bug.cgi?id=161775

        Reviewed by Ryosuke Niwa.

        Speedometer spends around 2.5% of its time in hasOwnProperty.
        Let's reduce the overhead of calling that function by marking
        it as inline. Also, it's likely that the function will call into
        JSObject::getOwnPropertySlot. I added a check to see if that's
        the function we're calling, if it is, we do a direct call instead
        of an indirect call.

        * runtime/JSObject.cpp:
        (JSC::JSObject::hasOwnProperty): Deleted.
        * runtime/JSObjectInlines.h:
        (JSC::JSObject::hasOwnProperty):

2016-09-09  Filip Pizlo  <fpizlo@apple.com>

        HashMapImpl needs to m_buffer.clear() in its constructor
        https://bugs.webkit.org/show_bug.cgi?id=161796

        Reviewed by Keith Miller.
        
        This is the second time that I'm fixing a bug because AuxiliaryBarrier does not initialize
        itself. That seemed like a good idea because maybe sometimes the user knows better how to
        initialize it. But, it's not worth it if it's a constant source of bugs.
        
        So, I'm fixing it for good by making AuxiliaryBarrier::AuxiliaryBarrier() initialize its
        m_value.

        * runtime/AuxiliaryBarrier.h:
        (JSC::AuxiliaryBarrier::AuxiliaryBarrier):
        * runtime/DirectArguments.cpp:
        (JSC::DirectArguments::DirectArguments):

2016-09-09  Youenn Fablet  <youenn@apple.com>

        ASSERTION FAILED: promise.inherits(JSPromise::info())
        https://bugs.webkit.org/show_bug.cgi?id=161632
        <rdar://problem/28184743>

        Reviewed by Mark Lam.

        * runtime/JSPromiseDeferred.cpp:
        (JSC::JSPromiseDeferred::create): Returning null if promise object is not created.

2016-09-08  Filip Pizlo  <fpizlo@apple.com>

        Heap::isMarked() shouldn't pay the price of concurrent lazy flipping
        https://bugs.webkit.org/show_bug.cgi?id=161760

        Reviewed by Mark Lam.
        
        To fix a race condition in marking, I made Heap::isMarked() and Heap::isLive() atomic by
        using flipIfNecessaryConcurrently() instead of flipIfNecessary().
        
        This introduces three unnecessary overheads:
        
        - isLive() is not called by marking, so that change was not necessary.
        
        - isMarked() gets calls many times outside of marking, so it shouldn't always do the
          concurrent thing. This adds isMarkedConcurrently() for use in marking, and reverts
          isMarked().
        
        - isMarked() and isMarkedConcurrently() don't actually have to do the lazy flip. They can
          return false if the flip is necessary.
        
        I added a bunch of debug assertions to make sure that isLive() and isMarked() are not called
        during marking.
        
        If we needed to, we could remove most of the calls to isMarkedConcurrently(). As a kind of
        optimization, CodeBlock does an initial fixpoint iteration during marking, and so all of the
        code called from CodeBlock's fixpoint iterator needs to use isMarkedConcurrently(). But we
        could probably arrange for CodeBlock only do fixpoint iterating during the weak reference
        thing.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::visitWeakly):
        (JSC::CodeBlock::shouldJettisonDueToOldAge):
        (JSC::shouldMarkTransition):
        (JSC::CodeBlock::propagateTransitions):
        (JSC::CodeBlock::determineLiveness):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::propagateTransitions):
        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::isLive):
        (JSC::Heap::isMarked):
        (JSC::Heap::isMarkedConcurrently):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::flipIfNecessarySlow):
        (JSC::MarkedBlock::flipIfNecessaryConcurrentlySlow):
        (JSC::MarkedBlock::needsFlip):
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::needsFlip):
        (JSC::MarkedBlock::flipIfNecessary):
        (JSC::MarkedBlock::flipIfNecessaryConcurrently):
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::appendToMarkStack):
        (JSC::SlotVisitor::markAuxiliary):
        (JSC::SlotVisitor::visitChildren):
        * runtime/Structure.cpp:
        (JSC::Structure::isCheapDuringGC):
        (JSC::Structure::markIfCheap):

2016-09-08  Saam Barati  <sbarati@apple.com>

        We should inline operationConvertJSValueToBoolean into JIT code
        https://bugs.webkit.org/show_bug.cgi?id=161729

        Reviewed by Filip Pizlo.

        This patch introduces an AssemblyHelpers emitter function
        that replaces operationConvertJSValueToBoolean. This operation
        was showing up when I was doing performance analysis for the
        speedometer benchmark. I saw that it was spending about 1% of
        its time in this function. Hopefully this patch can help us speedup
        up speedometer by a little bit.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compileLogicalNot):
        (JSC::DFG::SpeculativeJIT::emitBranch):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compileLogicalNot):
        (JSC::DFG::SpeculativeJIT::emitBranch):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::emitConvertValueToBoolean):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitAllocateDestructibleObject): Deleted.
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_jfalse):
        (JSC::JIT::emit_op_jtrue):
        (JSC::JIT::emitSlow_op_jfalse): Deleted.
        (JSC::JIT::emitSlow_op_jtrue): Deleted.
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_jfalse):
        (JSC::JIT::emit_op_jtrue):
        (JSC::JIT::emitSlow_op_jfalse): Deleted.
        (JSC::JIT::emitSlow_op_jtrue): Deleted.
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:

2016-09-08  Chris Dumez  <cdumez@apple.com>

        Align proto getter / setter behavior with other browsers
        https://bugs.webkit.org/show_bug.cgi?id=161455

        Reviewed by Saam Barati.

        Drop allowsAccessFrom from the methodTable and delegate cross-origin
        checking to the DOM bindings for [[SetPrototypeOf]] / [[GetPrototypeOf]].
        This is more consistent with other operations (e.g. [[GetOwnProperty]]).

        * jsc.cpp:
        * runtime/JSGlobalObject.cpp:
        * runtime/JSGlobalObject.h:
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncProtoGetter):
        (JSC::globalFuncProtoSetter):
        (JSC::globalFuncBuiltinLog): Deleted.
        * runtime/JSGlobalObjectFunctions.h:
        * runtime/JSObject.cpp:
        (JSC::JSObject::setPrototypeWithCycleCheck):
        Remove check added in r197648. This check was added to match
        the latest EcmaScript spec:
        - https://tc39.github.io/ecma262/#sec-ordinarysetprototypeof (step 8)
        This check allowed for [[Prototype]] chain cycles if the prototype
        chain includes objects that do not use the ordinary object definitions
        for [[GetPrototypeOf]] and [[SetPrototypeOf]].
        The issue is that the rest of our code base does not properly handle
        such cycles and we can end up in infinite loops. This became obvious
        because this patch updates Window / Location so that they no longer
        use the default [[GetPrototypeOf]] / [[SetPrototypeOf]]. If I do not
        remove this check, I get an infinite loop in
        Structure::anyObjectInChainMayInterceptIndexedAccesses(), which is
        called from JSObject::setPrototypeDirect(), when running the following
        layout test:
        - html/browsers/history/the-location-interface/allow_prototype_cycle_through_location.sub.html
        I filed https://bugs.webkit.org/show_bug.cgi?id=161534 to track this
        issue.

        * runtime/JSObject.h:
        (JSC::JSObject::getArrayLength): Deleted.
        * runtime/JSProxy.cpp:
        (JSC::JSProxy::setPrototype):
        (JSC::JSProxy::getPrototype):
        * runtime/JSProxy.h:
        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorGetPrototypeOf):
        (JSC::objectConstructorSetPrototypeOf):
        (JSC::objectConstructorGetOwnPropertyDescriptor): Deleted.
        (JSC::objectConstructorGetOwnPropertyDescriptors): Deleted.
        * runtime/ObjectConstructor.h:
        * runtime/ReflectObject.cpp:
        (JSC::reflectObjectGetPrototypeOf):
        (JSC::reflectObjectSetPrototypeOf):

2016-09-08  Filip Pizlo  <fpizlo@apple.com>

        Remove CopiedSpace and use MarkedSpace instead
        https://bugs.webkit.org/show_bug.cgi?id=159658

        Reviewed by Keith Miller.
        
        This removes the final client of CopiedSpace, the overrides array of DirectArguments. That
        is a simple change.
        
        Then this stubs out some remaining internal debugging code that referenced CopiedSpace in
        JSDollarVM and HeapVerifier. I filed FIXMEs to restore that debugging functionality.
        
        The rest of this patch is deleting CopiedSpace.

        * API/JSObjectRef.cpp:
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGOperations.cpp:
        * heap/ConservativeRoots.cpp:
        (JSC::ConservativeRoots::genericAddPointer):
        * heap/CopiedAllocator.h: Removed.
        * heap/CopiedBlock.cpp: Removed.
        * heap/CopiedBlock.h: Removed.
        * heap/CopiedBlockInlines.h: Removed.
        * heap/CopiedSpace.cpp: Removed.
        * heap/CopiedSpace.h: Removed.
        * heap/CopiedSpaceInlines.h: Removed.
        * heap/CopyBarrier.h: Removed.
        * heap/CopyToken.h: Removed.
        * heap/CopyVisitor.cpp: Removed.
        * heap/CopyVisitor.h: Removed.
        * heap/CopyVisitorInlines.h: Removed.
        * heap/CopyWorkList.h: Removed.
        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::isPagedOut):
        (JSC::Heap::updateObjectCounts):
        (JSC::Heap::size):
        (JSC::Heap::capacity):
        (JSC::Heap::collectImpl):
        (JSC::Heap::stopAllocation):
        (JSC::Heap::updateAllocationLimits):
        (JSC::Heap::copyBackingStores): Deleted.
        (JSC::Heap::threadBytesCopied): Deleted.
        * heap/Heap.h:
        (JSC::Heap::objectSpace):
        (JSC::Heap::allocatorForAuxiliaryData):
        (JSC::Heap::storageSpace): Deleted.
        (JSC::Heap::storageAllocator): Deleted.
        * heap/HeapCellInlines.h:
        * heap/HeapInlines.h:
        (JSC::Heap::tryAllocateStorage): Deleted.
        (JSC::Heap::tryReallocateStorage): Deleted.
        * heap/HeapVerifier.cpp:
        (JSC::HeapVerifier::verifyButterflyIsInStorageSpace):
        (JSC::HeapVerifier::reportObject):
        (JSC::getButterflyDetails): Deleted.
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::copyLater): Deleted.
        * heap/SlotVisitor.h:
        * jit/AssemblyHelpers.h:
        * jit/JITOpcodes.cpp:
        * jsc.cpp:
        * runtime/ArrayConstructor.cpp:
        * runtime/ArrayPrototype.cpp:
        * runtime/Butterfly.h:
        * runtime/ButterflyInlines.h:
        (JSC::Butterfly::createUninitializedDuringCollection): Deleted.
        * runtime/ClassInfo.h:
        * runtime/DirectArguments.cpp:
        (JSC::DirectArguments::visitChildren):
        (JSC::DirectArguments::overrideThings):
        (JSC::DirectArguments::copyBackingStore): Deleted.
        * runtime/DirectArguments.h:
        * runtime/JSArray.cpp:
        * runtime/JSCell.cpp:
        (JSC::JSCell::copyBackingStore): Deleted.
        * runtime/JSCell.h:
        * runtime/JSLexicalEnvironment.h:
        * runtime/JSObject.cpp:
        * runtime/JSTypedArrays.cpp:
        * runtime/LiteralParser.cpp:
        * runtime/ObjectConstructor.cpp:
        * runtime/RegExpObject.cpp:
        * runtime/StringPrototype.cpp:
        * runtime/WeakMapData.cpp:
        * tools/JSDollarVMPrototype.cpp:
        (JSC::JSDollarVMPrototype::isInStorageSpace):

2016-09-08  Filip Pizlo  <fpizlo@apple.com>

        Heap version should be 32-bit
        https://bugs.webkit.org/show_bug.cgi?id=161751

        Reviewed by Mark Lam.
        
        32-bit devices are probably getting hurt by the 64-bit version number. The reason why I made
        it 64-bit initially is so that I wouldn't have to worry about wrap-around. But wrap-around is
        easy to handle.

        * heap/CellContainer.h:
        * heap/CellContainerInlines.h:
        (JSC::CellContainer::flipIfNecessary):
        * heap/ConservativeRoots.cpp:
        (JSC::ConservativeRoots::genericAddPointer):
        (JSC::ConservativeRoots::genericAddSpan):
        * heap/ConservativeRoots.h:
        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::testAndSetMarked):
        * heap/HeapUtil.h:
        (JSC::HeapUtil::findGCObjectPointersForMarking):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::MarkedBlock):
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::flipIfNecessary):
        (JSC::MarkedBlock::flipIfNecessaryConcurrently):
        (JSC::MarkedBlock::Handle::flipIfNecessary):
        (JSC::MarkedBlock::Handle::flipIfNecessaryConcurrently):
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::flip):
        * heap/MarkedSpace.h:
        (JSC::MarkedSpace::version):
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::SlotVisitor):
        * heap/SlotVisitor.h:

2016-09-08  Mark Lam  <mark.lam@apple.com>

        Add support for a ternary sub32 emitter for ARM64 and 32-bit ARM.
        https://bugs.webkit.org/show_bug.cgi?id=161724

        Reviewed by Filip Pizlo.

        ARM architectures support ternary sub instructions.  We should make use of them
        in emitAllocateWithNonNullAllocator().

        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::sub32):
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::sub32):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::sub32):
        * assembler/MacroAssemblerSH4.h:
        (JSC::MacroAssemblerSH4::sub32):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::sub32):
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::testTernarySubInstructionSelection):
        (JSC::B3::run):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator):

2016-09-08  Filip Pizlo  <fpizlo@apple.com>

        Move JSMap/JSSet over to Auxiliary MarkedSpace
        https://bugs.webkit.org/show_bug.cgi?id=161744

        Reviewed by Saam Barati.
        
        This moves the buffer out of CopiedSpace and into Auxiliary MarkedSpace.
        
        Also removes MapData.h/MapDataInlines.h since they are not used anywhere, but they still
        speak of CopiedSpace.
        
        This is a purely mechanical change.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/CopyToken.h:
        * runtime/HashMapImpl.cpp:
        (JSC::HashMapImpl<HashMapBucket>::visitChildren):
        (JSC::HashMapImpl<HashMapBucket>::copyBackingStore): Deleted.
        * runtime/HashMapImpl.h:
        (JSC::HashMapBuffer::create):
        * runtime/JSMapIterator.cpp:
        * runtime/JSMapIterator.h:
        * runtime/JSSetIterator.cpp:
        * runtime/JSSetIterator.h:
        * runtime/MapBase.cpp:
        * runtime/MapData.h: Removed.
        * runtime/MapDataInlines.h: Removed.
        * runtime/MapPrototype.cpp:
        * runtime/SetConstructor.cpp:
        * runtime/SetPrototype.cpp:
        * runtime/VM.cpp:

2016-09-06  Filip Pizlo  <fpizlo@apple.com>

        Typed arrays should use MarkedSpace instead of CopiedSpace
        https://bugs.webkit.org/show_bug.cgi?id=161100

        Reviewed by Geoffrey Garen.
        
        This moves typed array backing stores out of CopiedSpace and into Auxiliary MarkedSpace.
        
        This is a purely mechanical change since Auxiliary MarkedSpace already knows how to do
        everything that typed arrays want.

        * dfg/DFGOperations.cpp:
        (JSC::DFG::newTypedArrayWithSize):
        * dfg/DFGOperations.h:
        (JSC::DFG::operationNewTypedArrayWithSizeForType):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNewTypedArray):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        (JSC::DFG::SpeculativeJIT::emitAllocateBasicStorage): Deleted.
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
        (JSC::FTL::DFG::LowerDFGToB3::initializeArrayElements):
        (JSC::FTL::DFG::LowerDFGToB3::splatWords):
        (JSC::FTL::DFG::LowerDFGToB3::allocateBasicStorageAndGetEnd): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::allocateBasicStorage): Deleted.
        * heap/CopyToken.h:
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::markAuxiliary):
        * jit/JITOperations.h:
        * runtime/JSArrayBufferView.cpp:
        (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
        (JSC::JSArrayBufferView::JSArrayBufferView):
        * runtime/JSArrayBufferView.h:
        * runtime/JSGenericTypedArrayView.h:
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::createWithFastVector):
        (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren):
        (JSC::JSGenericTypedArrayView<Adaptor>::slowDownAndWasteMemory):
        (JSC::JSGenericTypedArrayView<Adaptor>::copyBackingStore): Deleted.

2016-09-08  Per Arne Vollan  <pvollan@apple.com>

        [Win64] Compile fixes.
        https://bugs.webkit.org/show_bug.cgi?id=161682

        Reviewed by Brent Fulgham.

        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * jit/JITCall.cpp:
        (JSC::JIT::compileOpCall):
        * runtime/ArrayConventions.cpp:
        (JSC::clearArrayMemset):

2016-09-08  Per Arne Vollan  <pvollan@apple.com>

        [Win] Exception fuzz tests fail
        https://bugs.webkit.org/show_bug.cgi?id=140928

        Reviewed by Mark Lam.

        Flush stdout when throwing the exception to make sure the output comes before output in the exception handler.
        The tests depend on the output to stdout being written in the correct order.

        * runtime/ExceptionFuzz.cpp:
        (JSC::doExceptionFuzzing):

2016-09-07  Simon Fraser  <simon.fraser@apple.com>

        Enable the <meter> element on iOS
        https://bugs.webkit.org/show_bug.cgi?id=161714
        rdar://problem/8978410

        Reviewed by Tim Horton.

        Define ENABLE_METER_ELEMENT unconditionally now.

        * Configurations/FeatureDefines.xcconfig:

2016-09-07  Joseph Pecoraro  <pecoraro@apple.com>

        Modernize Debugger to use nullptr
        https://bugs.webkit.org/show_bug.cgi?id=161718

        Reviewed by Mark Lam.

        * debugger/Debugger.cpp:
        (JSC::Debugger::Debugger):
        (JSC::Debugger::~Debugger):
        (JSC::Debugger::detach):
        (JSC::Debugger::stepOutOfFunction):
        (JSC::Debugger::updateCallFrameAndPauseIfNeeded):
        * debugger/Debugger.h:

2016-09-07  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Remove always false case in Debugger
        https://bugs.webkit.org/show_bug.cgi?id=161717

        Reviewed by Brian Burg.

        * debugger/Debugger.cpp:
        (JSC::Debugger::didExecuteProgram):
        We would have earlier returned a few statements ago if this case was true.
        And we would have crashed in the previous statement if this case was true.

2016-09-07  Yusuke Suzuki  <utatane.tea@gmail.com>

        Unreviewed, build fix after r205569

        Tweak CMakeLists.txt

        * CMakeLists.txt:

2016-09-07  Mark Lam  <mark.lam@apple.com>

        Add CatchScope and force all exception checks to be via ThrowScope or CatchScope.
        https://bugs.webkit.org/show_bug.cgi?id=161498

        Reviewed by Geoffrey Garen.

        This patch refactors the ThrowScope class, and introduces a base ExceptionScope
        that ThrowScope extends.  A CatchScope which extends the ExceptionScope is also
        introduced.

        ENABLE(THROW_SCOPE_VERIFICATION) is now renamed to ENABLE(EXCEPTION_SCOPE_VERIFICATION)
        which is a more suitable name now.

        Note: exception scope verification is still disabled by default.  There are still
        many places that need to be fixed up or re-expressed in a way that is friendly
        to the verification.  I'll address those in subsequent patches.

        After this patch, the code will statically enforce that:
        1. all calls to throwException() go through a ThrowScope.
        2. all calls to clearException() go through a CatchScope.
        3. all exception checks go through an ExceptionScope in the form of a ThrowScope
           or CatchScope.

        A Summary of how to use ExceptionScopes
        =======================================
        1. If a function can throw a JS exception, it should declare a ThrowScope at the
           top of the function (as early as possible).

        2. If a function can clear JS exceptions, it should declare a CatchScope at the
           top of the function (as early as possible).

        Declaring a ThrowScope in a function means that the function may throw an exception
        that its caller will have to handle.  Declaring a CatchScope in a function means
        that the function intends to clear pending exceptions before returning to its
        caller. 

        For more details, see the notes below.
        
        Everything you may want to know about ExceptionScopes
        =====================================================
        ExceptionScope verification works to simulate exception throws and detect cases
        where exception checks are missing.  The notes below will cover:

            1. The VM::m_needExceptionCheck bit
            2. ThrowScopes and CatchScopes
            3. Verification of needed exception checks
            3. Checking Exceptions
            4. Simulating throws
            5. Using ThrowScope::release()
            6. Checking exceptions with ThrowScope::exception() / CatchScope::exception()
            7. Checking exceptions by checking callee results
            8. Debugging verification errors

        1. The VM::m_needExceptionCheck bit

           The VM has a m_needExceptionCheck bit that indicates when an exception may be
           thrown.  You can think of the m_needExceptionCheck bit being set as a simulated
           throw.

        2. ThrowScopes and CatchScopes

           Only ThrowScopes may throwException.  Only CatchScopes may catchException.

           Every throw site must declare a ThrowScope instance using DECLARE_THROW_SCOPE
           at the top of its function (as early as possible) e.g.
 
                void foo(...)
                {
                    auto scope = DECLARE_THROW_SCOPE(vm);
                    ...
                    throwException(exec, scope, ...);
                }

           Note: by convention, every throw helper function must take a ThrowScope argument
           instead of instantiating its own ThrowScope.  This allows the throw to be
           attributed to the client code rather than the throw helper itself.

           Every catch site (i.e. a site that calls clearException()) must declare a
           CatchScope instance using DECLARE_CATCH_SCOPE at the top of its function.

           If a function can both throw or clear exceptions, then the ThrowScope should
           be declared first so that it can simulate a throw to the function's caller.

           Note: ThrowScope and CatchScope both extend ExceptionScope so that ThrowScopes
           can be aware if there's an enclosing CatchScope between it and the point where
           C++ code returns to JS code.  This is needed to determine if the ThrowScope
           should simulate a re-throw or not.  See (4) below for more details on returning
           to JS code.

        3. Verification of needed exception checks

           a. On construction, each ThrowScope and CatchScope will verify that
              VM::m_needExceptionCheck is not set.
 
              This ensures that the caller of the current function has checked for exceptions
              where needed before doing more work which lead to calling the current function.

           b. On destruction, each ThrowScope and CatchScope will verify that
              VM::m_needExceptionCheck is not set. This verification will be skipped if
              the ThrowScope has been released (see (5) below).

              This ensures that the function that owns this exception scope is not missing
              any exception checks before returning.

           c. When throwing an exception, the ThrowScope will verify that VM::m_needExceptionCheck
              is not already set, unless it's been ask to rethrow the same Exception object.

        4. Simulating throws

           Throws are simulated by setting the m_needExceptionCheck bit.

           The bit will only be set in the ThrowScope destructor except when the ThrowScope
           detects the caller is a LLInt or JIT function.  LLInt or JIT functions will always
           check for exceptions after a host C++ function returns to it.  However, they will
           not clear the m_needExceptionCheck bit.

           Hence, if the ThrowScope destructor detects the caller is a LLInt or JIT function,
           it will just skip the setting of the bit.

           Note: it is not needed nor correct to set the m_needExceptionCheck bit in the
           throwException methods.  This is because, in practice, we always return
           immediately after throwing an exception.  It doesn't make sense to set the bit in
           the throw just to have to clear it immediately after before we do verification in
           the ThrowScope destructor.

        5. Using ThrowScope::release()

           Calling release() means that the scope is released from its obligation to
           verify the VM::m_needExceptionCheck bit on destruction.

           release() should only be used at the bottom of a function if:

           a. This function is going to let its caller check and handle the exception, e.g.

                void foo(...)
                {
                    auto scope = DECLARE_THROW_SCOPE(vm);
                    auto result = goo(); // may throw.

                    ... // Code that will are not affected by a pending exceptions.

                    scope.release(); // tell the ThrowScope that the caller will handle the exception.
                    return result;
                }

           b. This function is going to do a tail call that may throw.

                void foo(...)
                {
                    auto scope = DECLARE_THROW_SCOPE(vm);
                    ...
                    scope.release(); // tell the ThrowScope that the caller will handle the exception.
                    return goo(); // may throw.
                }

              release() should not be used in code paths that branch. For example:

                void foo(...)
                {
                    auto scope = DECLARE_THROW_SCOPE(vm);

                    auto result = goo1(); // may throw.
                    scope.release(); // WRONG !!! Don't do this.
                    if (result)
                        return;

                    result = goo2(); // may throw.
                    ...
                    return result;
                }

            The above will result in a verification error in goo2()'s ThrowScope.  The
            proper way to fix this verification is to do either (6) or (7) below.

         6. Checking exceptions with ThrowScope::exception() / CatchScope::exception()

            ThrowScope/CatchScope::exception() returns the thrown Exception object if
            there is one pending.  Else, it returns nullptr.

            It also clears the m_needExceptionCheck bit thereby indicating that we've
            satisfied the needed exception check.  For example,

                void foo(...)
                {
                    auto scope = DECLARE_THROW_SCOPE(vm);

                    auto result = goo1(); // may throw.
                    if (scope.exception())
                        return;

                    result = goo2(); // may throw.
                    ...
                    return result;
                }

            But sometimes, for optimization reasons, we may choose to test the result of
            the callee function instead doing a load of the VM exception value.  See (7)
            below.

         7. Checking exceptions by checking callee results

            This approach should only be applied when it makes a difference to performance.
            If we need to do this, we should add an ASSERT() that invokes the scope's
            exception() method to verify the result.  Since exception scope verification
            is only done on DEBUG builds, this ASSERT will satisfy the verification
            requirements without impacting performance.  For example,

                void foo(...)
                {
                    auto scope = DECLARE_THROW_SCOPE(vm);

                    bool failed = goo1(); // may throw.
                    ASSERT(!!scope.exception() == failed)
                    if (failed)
                        return;

                    result = goo2(); // may throw.
                    ...
                    return result;
                }

         8. Debugging verification errors

            a. When verification fails, you will see a message followed by an assertion
               failure.  For example:

            ERROR: Unchecked JS exception:
                This scope can throw a JS exception: setUpCall @ /Volumes/Data/ws6/OpenSource/Source/JavaScriptCore/llint/LLIntSlowPaths.cpp:1245
                    (ExceptionScope::m_recursionDepth was ...)
                But the exception was unchecked as of this scope: varargsSetup @ /Volumes/Data/ws6/OpenSource/Source/JavaScriptCore/llint/LLIntSlowPaths.cpp:1398
                    (ExceptionScope::m_recursionDepth was ...)
                [ backtrace here ]

               The message tells you that failure was detected at in varargsSetup() at
               LLIntSlowPaths.cpp line 1398, and that the missing exception check should
               have happened somewhere between the call to setUpCall() at LLIntSlowPaths.cpp
               line 1245 and it.

               If that is insufficient information, you can ...

            b. Dump simulated throws

               Re-run the test case with JSC_dumpSimulatedThrows=true.  You will also see
               back traces at each simulated throw.

            c. Narrowing down the source of a simulated throw

               Another technique for narrowing down the source of simulated throws is by
               further dividing a function to smaller regions by separating each region
               with additional local throw scopes.  For example,

                ... // Region 1
                { auto scope = DECLARE_THROW_SCOPE(vm); }
                ... // Region 2
                { auto scope = DECLARE_THROW_SCOPE(vm); }
                ... // Region 3

        * API/APIUtils.h:
        (handleExceptionIfNeeded):
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bindings/ScriptFunctionCall.cpp:
        (Deprecated::ScriptFunctionCall::call):
        * bindings/ScriptValue.cpp:
        (Deprecated::ScriptValue::toString):
        * debugger/Debugger.cpp:
        (JSC::Debugger::pauseIfNeeded):
        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::evaluateWithScopeExtension):
        * dfg/DFGOSRExitCompiler.cpp:
        * dfg/DFGOperations.cpp:
        (JSC::DFG::operationPutByValInternal):
        * inspector/InjectedScriptManager.cpp:
        (Inspector::InjectedScriptManager::createInjectedScript):
        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::reportAPIException):
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
        (Inspector::JSInjectedScriptHost::getInternalProperties):
        (Inspector::JSInjectedScriptHost::weakMapEntries):
        (Inspector::JSInjectedScriptHost::weakSetEntries):
        (Inspector::JSInjectedScriptHost::iteratorEntries):
        * inspector/JSJavaScriptCallFrame.cpp:
        (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension):
        * inspector/ScriptCallStackFactory.cpp:
        (Inspector::extractSourceInformationFromException):
        * interpreter/CachedCall.h:
        (JSC::CachedCall::CachedCall):
        * interpreter/CallFrame.h:
        (JSC::ExecState::clearException): Deleted.
        (JSC::ExecState::exception): Deleted.
        (JSC::ExecState::hadException): Deleted.
        (JSC::ExecState::lastException): Deleted.
        (JSC::ExecState::clearLastException): Deleted.
        * interpreter/Interpreter.cpp:
        (JSC::eval):
        (JSC::sizeOfVarargs):
        (JSC::notifyDebuggerOfUnwinding):
        (JSC::Interpreter::unwind):
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        (JSC::Interpreter::prepareForRepeatCall):
        (JSC::Interpreter::debug):
        * interpreter/Interpreter.h:
        (JSC::SuspendExceptionScope::SuspendExceptionScope):
        * interpreter/ShadowChicken.cpp:
        (JSC::ShadowChicken::functionsOnStack):
        * jit/JITCode.cpp:
        (JSC::JITCode::execute):
        * jit/JITExceptions.cpp:
        (JSC::genericUnwind):
        * jit/JITOperations.cpp:
        (JSC::getByVal):
        * jsc.cpp:
        (WTF::ImpureGetter::getOwnPropertySlot):
        (GlobalObject::moduleLoaderResolve):
        (GlobalObject::moduleLoaderFetch):
        (functionCreateElement):
        (functionRun):
        (functionRunString):
        (functionLoad):
        (functionLoadString):
        (functionReadFile):
        (functionCheckSyntax):
        (functionSetRandomSeed):
        (functionLoadModule):
        (functionCreateBuiltin):
        (functionCheckModuleSyntax):
        (functionGenerateHeapSnapshot):
        (functionSamplingProfilerStackTraces):
        (dumpException):
        (checkUncaughtException):
        (runWithScripts):
        (runInteractive):
        * llint/LLIntExceptions.cpp:
        (JSC::LLInt::returnToThrow):
        (JSC::LLInt::callToThrow):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * profiler/ProfilerBytecodeSequence.cpp:
        (JSC::Profiler::BytecodeSequence::addSequenceProperties):
        * profiler/ProfilerCompilation.cpp:
        (JSC::Profiler::Compilation::toJS):
        * profiler/ProfilerDatabase.cpp:
        (JSC::Profiler::Database::toJS):
        * profiler/ProfilerOSRExitSite.cpp:
        (JSC::Profiler::OSRExitSite::toJS):
        * profiler/ProfilerOriginStack.cpp:
        (JSC::Profiler::OriginStack::toJS):
        * runtime/ArrayPrototype.cpp:
        (JSC::speciesConstructArray):
        (JSC::shift):
        (JSC::unshift):
        (JSC::arrayProtoFuncToString):
        (JSC::arrayProtoFuncToLocaleString):
        (JSC::slowJoin):
        (JSC::fastJoin):
        (JSC::arrayProtoFuncJoin):
        (JSC::arrayProtoFuncPop):
        (JSC::arrayProtoFuncPush):
        (JSC::arrayProtoFuncReverse):
        (JSC::arrayProtoFuncShift):
        (JSC::arrayProtoFuncSlice):
        (JSC::arrayProtoFuncSplice):
        (JSC::arrayProtoFuncUnShift):
        (JSC::arrayProtoFuncIndexOf):
        (JSC::arrayProtoFuncLastIndexOf):
        (JSC::moveElements):
        (JSC::concatAppendOne):
        (JSC::arrayProtoPrivateFuncConcatMemcpy):
        * runtime/BooleanConstructor.cpp:
        (JSC::constructWithBooleanConstructor):
        * runtime/CallData.cpp:
        (JSC::call):
        * runtime/CatchScope.cpp: Added.
        (JSC::CatchScope::CatchScope):
        (JSC::CatchScope::~CatchScope):
        * runtime/CatchScope.h: Added.
        (JSC::CatchScope::clearException):
        (JSC::CatchScope::CatchScope):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::opIn):
        * runtime/CommonSlowPathsExceptions.cpp:
        (JSC::CommonSlowPaths::interpreterThrowInCaller):
        * runtime/Completion.cpp:
        (JSC::evaluate):
        (JSC::rejectPromise):
        (JSC::loadAndEvaluateModule):
        (JSC::loadModule):
        * runtime/ConsoleObject.cpp:
        (JSC::consoleProtoFuncAssert):
        (JSC::consoleProtoFuncProfile):
        (JSC::consoleProtoFuncProfileEnd):
        (JSC::consoleProtoFuncTakeHeapSnapshot):
        (JSC::consoleProtoFuncTime):
        (JSC::consoleProtoFuncTimeEnd):
        * runtime/DateConstructor.cpp:
        (JSC::constructDate):
        (JSC::dateParse):
        * runtime/DatePrototype.cpp:
        (JSC::dateProtoFuncToPrimitiveSymbol):
        (JSC::dateProtoFuncToJSON):
        * runtime/ErrorConstructor.cpp:
        (JSC::Interpreter::constructWithErrorConstructor):
        * runtime/ErrorInstance.cpp:
        (JSC::ErrorInstance::sanitizedToString):
        * runtime/ErrorPrototype.cpp:
        (JSC::errorProtoFuncToString):
        * runtime/ExceptionEventLocation.cpp: Added.
        (WTF::printInternal):
        * runtime/ExceptionEventLocation.h: Copied from Source/JavaScriptCore/runtime/ThrowScopeLocation.h.
        (JSC::ExceptionEventLocation::ExceptionEventLocation):
        (JSC::ThrowScopeLocation::ThrowScopeLocation): Deleted.
        * runtime/ExceptionHelpers.h:
        * runtime/ExceptionScope.cpp: Added.
        (JSC::ExceptionScope::ExceptionScope):
        (JSC::ExceptionScope::~ExceptionScope):
        * runtime/ExceptionScope.h: Added.
        (JSC::ExceptionScope::vm):
        (JSC::ExceptionScope::recursionDepth):
        (JSC::ExceptionScope::exception):
        (JSC::ExceptionScope::ExceptionScope):
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * runtime/FunctionPrototype.cpp:
        (JSC::functionProtoFuncBind):
        * runtime/GenericArgumentsInlines.h:
        (JSC::GenericArguments<Type>::copyToArguments):
        * runtime/GetterSetter.cpp:
        (JSC::callGetter):
        * runtime/InspectorInstrumentationObject.cpp:
        (JSC::inspectorInstrumentationObjectLog):
        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::createSubclassStructure):
        * runtime/IntlCollator.cpp:
        (JSC::IntlCollator::initializeCollator):
        (JSC::IntlCollator::createCollator):
        (JSC::IntlCollator::resolvedOptions):
        * runtime/IntlCollatorConstructor.cpp:
        (JSC::constructIntlCollator):
        (JSC::IntlCollatorConstructorFuncSupportedLocalesOf):
        * runtime/IntlCollatorPrototype.cpp:
        (JSC::IntlCollatorFuncCompare):
        (JSC::IntlCollatorPrototypeGetterCompare):
        * runtime/IntlDateTimeFormat.cpp:
        (JSC::toDateTimeOptionsAnyDate):
        (JSC::IntlDateTimeFormat::initializeDateTimeFormat):
        (JSC::IntlDateTimeFormat::resolvedOptions):
        (JSC::IntlDateTimeFormat::format):
        * runtime/IntlDateTimeFormatConstructor.cpp:
        (JSC::constructIntlDateTimeFormat):
        (JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf):
        * runtime/IntlDateTimeFormatPrototype.cpp:
        (JSC::IntlDateTimeFormatFuncFormatDateTime):
        (JSC::IntlDateTimeFormatPrototypeGetterFormat):
        * runtime/IntlNumberFormat.cpp:
        (JSC::IntlNumberFormat::initializeNumberFormat):
        (JSC::IntlNumberFormat::createNumberFormat):
        (JSC::IntlNumberFormat::resolvedOptions):
        * runtime/IntlNumberFormatConstructor.cpp:
        (JSC::constructIntlNumberFormat):
        (JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf):
        * runtime/IntlNumberFormatPrototype.cpp:
        (JSC::IntlNumberFormatFuncFormatNumber):
        (JSC::IntlNumberFormatPrototypeGetterFormat):
        * runtime/IntlObject.cpp:
        (JSC::intlBooleanOption):
        (JSC::intlStringOption):
        (JSC::intlNumberOption):
        (JSC::canonicalizeLocaleList):
        (JSC::supportedLocales):
        * runtime/IntlObjectInlines.h:
        (JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor):
        * runtime/IteratorOperations.cpp:
        (JSC::iteratorNext):
        (JSC::iteratorStep):
        (JSC::iteratorClose):
        (JSC::iteratorForIterable):
        * runtime/IteratorOperations.h:
        (JSC::forEachInIterable):
        * runtime/JSArray.cpp:
        (JSC::JSArray::pop):
        (JSC::JSArray::push):
        (JSC::JSArray::copyToArguments):
        * runtime/JSArrayBufferConstructor.cpp:
        (JSC::constructArrayBuffer):
        * runtime/JSArrayBufferPrototype.cpp:
        (JSC::arrayBufferProtoFuncSlice):
        * runtime/JSArrayInlines.h:
        (JSC::getLength):
        (JSC::toLength):
        * runtime/JSBoundFunction.cpp:
        (JSC::getBoundFunctionStructure):
        (JSC::JSBoundFunction::create):
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::putToPrimitive):
        (JSC::JSValue::putToPrimitiveByIndex):
        (JSC::JSValue::toStringSlowCase):
        * runtime/JSCJSValueInlines.h:
        (JSC::toPreferredPrimitiveType):
        (JSC::JSValue::getPropertySlot):
        (JSC::JSValue::equalSlowCaseInline):
        * runtime/JSDataViewPrototype.cpp:
        (JSC::getData):
        (JSC::setData):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::setFunctionName):
        * runtime/JSGenericTypedArrayView.h:
        (JSC::JSGenericTypedArrayView::setIndex):
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::constructGenericTypedArrayViewFromIterator):
        (JSC::constructGenericTypedArrayViewWithArguments):
        (JSC::constructGenericTypedArrayView):
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::speciesConstruct):
        (JSC::genericTypedArrayViewProtoFuncCopyWithin):
        (JSC::genericTypedArrayViewProtoFuncIncludes):
        (JSC::genericTypedArrayViewProtoFuncIndexOf):
        (JSC::genericTypedArrayViewProtoFuncJoin):
        (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
        (JSC::genericTypedArrayViewProtoFuncSlice):
        (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
        * runtime/JSGlobalObject.h:
        (JSC::constructEmptyArray):
        (JSC::constructArray):
        (JSC::constructArrayNegativeIndexed):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncEval):
        * runtime/JSJob.cpp:
        (JSC::JSJobMicrotask::run):
        * runtime/JSModuleEnvironment.cpp:
        (JSC::JSModuleEnvironment::getOwnPropertySlot):
        * runtime/JSModuleLoader.cpp:
        (JSC::JSModuleLoader::fetch):
        * runtime/JSModuleNamespaceObject.cpp:
        (JSC::JSModuleNamespaceObject::finishCreation):
        (JSC::JSModuleNamespaceObject::getOwnPropertySlot):
        * runtime/JSModuleRecord.cpp:
        (JSC::JSModuleRecord::instantiateDeclarations):
        * runtime/JSONObject.cpp:
        (JSC::Stringifier::Stringifier):
        (JSC::Stringifier::stringify):
        (JSC::Stringifier::toJSON):
        (JSC::Stringifier::appendStringifiedValue):
        (JSC::Stringifier::Holder::appendNextProperty):
        (JSC::Walker::walk):
        (JSC::JSONProtoFuncParse):
        * runtime/JSObject.cpp:
        (JSC::ordinarySetSlow):
        (JSC::JSObject::setPrototypeWithCycleCheck):
        (JSC::callToPrimitiveFunction):
        (JSC::JSObject::ordinaryToPrimitive):
        (JSC::JSObject::defaultHasInstance):
        (JSC::JSObject::getPropertyNames):
        (JSC::JSObject::toNumber):
        (JSC::JSObject::toString):
        (JSC::JSObject::defineOwnNonIndexProperty):
        (JSC::JSObject::getGenericPropertyNames):
        (JSC::JSObject::getMethod):
        * runtime/JSObjectInlines.h:
        (JSC::createListFromArrayLike):
        (JSC::JSObject::getPropertySlot):
        (JSC::JSObject::getNonIndexPropertySlot):
        * runtime/JSPromiseConstructor.cpp:
        (JSC::constructPromise):
        * runtime/JSPropertyNameEnumerator.h:
        (JSC::propertyNameEnumerator):
        * runtime/JSPropertyNameIterator.cpp:
        (JSC::JSPropertyNameIterator::create):
        * runtime/JSScope.cpp:
        (JSC::isUnscopable):
        (JSC::JSScope::resolve):
        * runtime/JSString.cpp:
        (JSC::JSString::equalSlowCase):
        * runtime/JSStringJoiner.cpp:
        (JSC::JSStringJoiner::join):
        * runtime/LiteralParser.cpp:
        (JSC::LiteralParser<CharType>::parse):
        * runtime/MapConstructor.cpp:
        (JSC::constructMap):
        * runtime/MathObject.cpp:
        (JSC::mathProtoFuncClz32):
        (JSC::mathProtoFuncHypot):
        (JSC::mathProtoFuncIMul):
        * runtime/ModuleLoaderPrototype.cpp:
        (JSC::moduleLoaderPrototypeParseModule):
        (JSC::moduleLoaderPrototypeRequestedModules):
        (JSC::moduleLoaderPrototypeModuleDeclarationInstantiation):
        * runtime/NativeErrorConstructor.cpp:
        (JSC::Interpreter::constructWithNativeErrorConstructor):
        * runtime/NumberConstructor.cpp:
        (JSC::constructWithNumberConstructor):
        * runtime/ObjectConstructor.cpp:
        (JSC::constructObject):
        (JSC::objectConstructorGetPrototypeOf):
        (JSC::objectConstructorSetPrototypeOf):
        (JSC::objectConstructorGetOwnPropertyDescriptor):
        (JSC::objectConstructorGetOwnPropertyDescriptors):
        (JSC::objectConstructorGetOwnPropertyNames):
        (JSC::objectConstructorGetOwnPropertySymbols):
        (JSC::objectConstructorKeys):
        (JSC::ownEnumerablePropertyKeys):
        (JSC::toPropertyDescriptor):
        (JSC::objectConstructorDefineProperty):
        (JSC::defineProperties):
        (JSC::objectConstructorSeal):
        (JSC::objectConstructorFreeze):
        (JSC::objectConstructorIsSealed):
        (JSC::objectConstructorIsFrozen):
        (JSC::objectConstructorIsExtensible):
        (JSC::ownPropertyKeys):
        * runtime/ObjectConstructor.h:
        (JSC::constructObjectFromPropertyDescriptor):
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncHasOwnProperty):
        (JSC::objectProtoFuncIsPrototypeOf):
        (JSC::objectProtoFuncDefineGetter):
        (JSC::objectProtoFuncDefineSetter):
        (JSC::objectProtoFuncLookupGetter):
        (JSC::objectProtoFuncLookupSetter):
        (JSC::objectProtoFuncPropertyIsEnumerable):
        (JSC::objectProtoFuncToLocaleString):
        (JSC::objectProtoFuncToString):
        * runtime/Operations.cpp:
        (JSC::jsAddSlowCase):
        * runtime/Options.h:
        * runtime/PropertyDescriptor.cpp:
        (JSC::PropertyDescriptor::slowGetterSetter):
        * runtime/ProxyConstructor.cpp:
        (JSC::makeRevocableProxy):
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::toStringName):
        (JSC::performProxyGet):
        (JSC::ProxyObject::performGet):
        (JSC::ProxyObject::performInternalMethodGetOwnProperty):
        (JSC::ProxyObject::performHasProperty):
        (JSC::ProxyObject::performPut):
        (JSC::ProxyObject::putByIndexCommon):
        (JSC::performProxyCall):
        (JSC::performProxyConstruct):
        (JSC::ProxyObject::performDelete):
        (JSC::ProxyObject::performPreventExtensions):
        (JSC::ProxyObject::performIsExtensible):
        (JSC::ProxyObject::performDefineOwnProperty):
        (JSC::ProxyObject::performGetOwnPropertyNames):
        (JSC::ProxyObject::performSetPrototype):
        (JSC::ProxyObject::performGetPrototype):
        * runtime/ReflectObject.cpp:
        (JSC::reflectObjectConstruct):
        (JSC::reflectObjectDefineProperty):
        (JSC::reflectObjectGet):
        (JSC::reflectObjectGetOwnPropertyDescriptor):
        (JSC::reflectObjectIsExtensible):
        (JSC::reflectObjectPreventExtensions):
        (JSC::reflectObjectSet):
        (JSC::reflectObjectSetPrototypeOf):
        * runtime/RegExpConstructor.cpp:
        (JSC::toFlags):
        (JSC::regExpCreate):
        (JSC::constructRegExp):
        * runtime/RegExpConstructor.h:
        (JSC::isRegExp):
        * runtime/RegExpObject.cpp:
        (JSC::collectMatches):
        (JSC::RegExpObject::matchGlobal):
        * runtime/RegExpPrototype.cpp:
        (JSC::regExpProtoFuncCompile):
        (JSC::flagsString):
        (JSC::regExpProtoFuncToString):
        (JSC::regExpProtoGetterFlags):
        (JSC::regExpProtoFuncSearchFast):
        (JSC::regExpProtoFuncSplitFast):
        * runtime/SetConstructor.cpp:
        (JSC::constructSet):
        * runtime/StringConstructor.cpp:
        (JSC::stringFromCodePoint):
        (JSC::constructWithStringConstructor):
        * runtime/StringObject.cpp:
        (JSC::StringObject::defineOwnProperty):
        * runtime/StringPrototype.cpp:
        (JSC::replaceUsingRegExpSearch):
        (JSC::operationStringProtoFuncReplaceRegExpEmptyStr):
        (JSC::replaceUsingStringSearch):
        (JSC::replace):
        (JSC::stringProtoFuncReplaceUsingRegExp):
        (JSC::stringProtoFuncReplaceUsingStringSearch):
        (JSC::stringProtoFuncCodePointAt):
        (JSC::stringProtoFuncSlice):
        (JSC::stringProtoFuncSplitFast):
        (JSC::stringProtoFuncSubstr):
        (JSC::stringProtoFuncSubstring):
        (JSC::stringProtoFuncLocaleCompare):
        (JSC::toLocaleCase):
        (JSC::stringProtoFuncBig):
        (JSC::stringProtoFuncSmall):
        (JSC::stringProtoFuncBlink):
        (JSC::stringProtoFuncBold):
        (JSC::stringProtoFuncFixed):
        (JSC::stringProtoFuncItalics):
        (JSC::stringProtoFuncStrike):
        (JSC::stringProtoFuncSub):
        (JSC::stringProtoFuncSup):
        (JSC::stringProtoFuncFontcolor):
        (JSC::stringProtoFuncFontsize):
        (JSC::stringProtoFuncAnchor):
        (JSC::stringProtoFuncLink):
        (JSC::trimString):
        (JSC::stringProtoFuncStartsWith):
        (JSC::stringProtoFuncEndsWith):
        (JSC::stringIncludesImpl):
        (JSC::stringProtoFuncIncludes):
        (JSC::builtinStringIncludesInternal):
        (JSC::stringProtoFuncNormalize):
        * runtime/SymbolConstructor.cpp:
        (JSC::symbolConstructorFor):
        * runtime/TemplateRegistry.cpp:
        (JSC::TemplateRegistry::getTemplateObject):
        * runtime/ThrowScope.cpp:
        (JSC::ThrowScope::ThrowScope):
        (JSC::ThrowScope::~ThrowScope):
        (JSC::ThrowScope::throwException):
        (JSC::ThrowScope::simulateThrow):
        (JSC::ThrowScope::printIfNeedCheck): Deleted.
        (JSC::ThrowScope::verifyExceptionCheckNeedIsSatisfied): Deleted.
        * runtime/ThrowScope.h:
        (JSC::ThrowScope::release):
        (JSC::ThrowScope::ThrowScope):
        (JSC::ThrowScope::throwException):
        (JSC::ThrowScope::vm): Deleted.
        (JSC::ThrowScope::exception): Deleted.
        * runtime/ThrowScopeLocation.h: Removed.
        * runtime/VM.cpp:
        (JSC::VM::verifyExceptionCheckNeedIsSatisfied):
        * runtime/VM.h:
        (JSC::VM::exception):
        (JSC::VM::clearException):
        (JSC::VM::setException): Deleted.
        * runtime/WeakMapConstructor.cpp:
        (JSC::constructWeakMap):
        * runtime/WeakSetConstructor.cpp:
        (JSC::constructWeakSet):
        * tools/JSDollarVMPrototype.cpp:
        (JSC::functionPrint):

2016-09-07  Andy VanWagoner  <thetalecrafter@gmail.com>

        [INTL] some valid language tags cause errors in Intl constructors
        https://bugs.webkit.org/show_bug.cgi?id=161672

        Reviewed by Mark Lam.

        Fix private use tag parsing to match spec, allowing single character parts.
        https://www.rfc-editor.org/rfc/bcp/bcp47.txt

        ```
        privateuse    = "x" 1*("-" (1*8alphanum))
        ```

        * runtime/IntlObject.cpp:
        (JSC::privateUseLangTag): Allow singleton parts in private use tag.

2016-09-07  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Remove a couple of useless forward declaration
        https://bugs.webkit.org/show_bug.cgi?id=161676

        Reviewed by Mark Lam.

        JITMathICForwards.h should take care of declarating the Math ICs.

        * bytecode/CodeBlock.h:
        * jit/JITOperations.h:

2016-09-07  Filip Pizlo  <fpizlo@apple.com>

        Make emitAllocateWithNonNullAllocator's sub32() disallow-scratch-friendly
        https://bugs.webkit.org/show_bug.cgi?id=161706

        Reviewed by Geoffrey Garen.
        
        You can't sub32(Addr, Reg) on not-x86 without using a scratch register. So, on those CPUs, we
        have to do something different.

        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator):

2016-09-07  Michael Catanzaro  <mcatanzaro@igalia.com>

        Unreviewed CMake build fix after r205552

        * CMakeLists.txt:

2016-09-03  Keith Miller  <keith_miller@apple.com>

        Add support for WASM Loops and Branches
        https://bugs.webkit.org/show_bug.cgi?id=161569

        Reviewed by Benjamin Poulain.

        This patch adds support for loops and branches to WASM. In order
        to support loops, we needed to change the way the B3IRGenerator
        tracked control information. Now, the control data holds three
        pieces of information: The continuation block, the loop branch
        target, and variables exiting the block. Whenever we branch to
        some control point we first check if it is a loop by checking that
        the loop branch target is non-null. If the branch is not targeting
        a loop, we map the stack values to the associated B3 variables for
        that stack slot.

        Another interesting thing of note is that we now only allocate the
        continuation basic block lazily. This is beneficial when the
        continuation would just fall through to another block anyway. For
        example, in code like: (block ... (block (add 1 2) end) end) the
        continuation for the inner block just falls through to the outer
        block's continuation so we don't need an extra block.

        * B3CallingConventions.cpp:
        (JSC::B3::jscCallingConvention): Deleted.
        * B3CallingConventions.h:
        (JSC::B3::CallingConvention::CallingConvention): Deleted.
        (JSC::B3::CallingConvention::iterate): Deleted.
        (JSC::B3::nextJSCOffset): Deleted.
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3Type.h:
        * testWASM.cpp:
        (runWASMTests):
        * wasm/WASMB3IRGenerator.cpp:
        (JSC::WASM::B3IRGenerator::LazyBlock::LazyBlock):
        (JSC::WASM::B3IRGenerator::LazyBlock::operator bool):
        (JSC::WASM::B3IRGenerator::LazyBlock::get):
        (JSC::WASM::B3IRGenerator::LazyBlock::dump):
        (JSC::WASM::B3IRGenerator::ControlData::ControlData):
        (JSC::WASM::B3IRGenerator::ControlData::dump):
        (JSC::WASM::B3IRGenerator::ControlData::targetBlockForBranch):
        (JSC::WASM::B3IRGenerator::ControlData::isLoop):
        (JSC::WASM::B3IRGenerator::addLocal):
        (JSC::WASM::B3IRGenerator::addArguments):
        (JSC::WASM::B3IRGenerator::setLocal):
        (JSC::WASM::B3IRGenerator::addBlock):
        (JSC::WASM::B3IRGenerator::addLoop):
        (JSC::WASM::B3IRGenerator::endBlock):
        (JSC::WASM::B3IRGenerator::addReturn):
        (JSC::WASM::B3IRGenerator::addBranch):
        (JSC::WASM::B3IRGenerator::initializeIncommingTypes):
        (JSC::WASM::B3IRGenerator::unifyValuesWithBlock):
        (JSC::WASM::B3IRGenerator::controlDataForLevel):
        (JSC::WASM::B3IRGenerator::dumpGraphAndControlStack):
        (JSC::WASM::parseAndCompile):
        (JSC::WASM::B3IRGenerator::unifyValuesWithLevel): Deleted.
        (JSC::WASM::B3IRGenerator::stackForControlLevel): Deleted.
        (JSC::WASM::B3IRGenerator::blockForControlLevel): Deleted.
        * wasm/WASMCallingConvention.cpp: Renamed from Source/JavaScriptCore/B3CallingConventions.cpp.
        (JSC::WASM::jscCallingConvention):
        * wasm/WASMCallingConvention.h: Renamed from Source/JavaScriptCore/B3CallingConventions.h.
        (JSC::WASM::CallingConvention::CallingConvention):
        (JSC::WASM::CallingConvention::iterate):
        (JSC::WASM::nextJSCOffset):
        * wasm/WASMFormat.h:
        (JSC::WASM::toB3Type):
        (JSC::WASM::isValueType):
        * wasm/WASMFunctionParser.h:
        (JSC::WASM::FunctionParser<Context>::parse):
        (JSC::WASM::FunctionParser<Context>::parseExpression):
        * wasm/WASMModuleParser.cpp:
        (JSC::WASM::ModuleParser::parseFunctionTypes):
        * wasm/WASMOps.h:

2016-09-07  Youenn Fablet  <youenn@apple.com>

        [Streams API] Separate compile flag for ReadableStream and WritableStream
        https://bugs.webkit.org/show_bug.cgi?id=161044

        Reviewed by Alex Christensen.

        Moving from STREAMS_API to READABLE_STREAM_API and WRITABLE_STREAM_API compilation flags.
        Updated builtin test to cover the case of @conditional taking ENABLE(XX) || ENABLE(YY) flag.

        * Configurations/FeatureDefines.xcconfig:
        * Scripts/tests/builtins/WebCore-GuardedInternalBuiltin-Separate.js:
        * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCoreJSBuiltins.h-result:

2016-09-07  Csaba Osztrogonác  <ossy@webkit.org>

        Fix the ENABLE(WEBASSEMBLY) build on Linux
        https://bugs.webkit.org/show_bug.cgi?id=161685

        Unreviewed buildfix.

        * wasm/JSWASMModule.cpp:

2016-09-06  Saam Barati  <sbarati@apple.com>

        ProxyObject's structure should not have ObjectPrototype as its prototype and it should not have special behavior for intercepting "__proto__"
        https://bugs.webkit.org/show_bug.cgi?id=161558

        Reviewed by Benjamin Poulain.

        ProxyObject had ObjectPrototype as its direct prototype.
        This could lead to infinite loops when doing a getDirectPrototype()
        loop.

        Fixing this bug revealed another bug, which I made when implementing Proxy.
        We should not special case "__proto__" in get and set for Proxy Object's
        hooks. "__proto__" should just go through the normal set and get path.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/ProxyObject.cpp:
        (JSC::performProxyGet):
        (JSC::ProxyObject::put):

2016-09-06  Yusuke Suzuki  <utatane.tea@gmail.com>

        Make JSC::PrivateName copyable
        https://bugs.webkit.org/show_bug.cgi?id=161666

        Reviewed by Ryosuke Niwa.

        Define the custom copy constructor to make PrivateName copyable while using Ref<SymbolImpl>.
        And since the custom copy constructor deletes the default move constructor, we explcitly define
        it by `= default;`.

        * runtime/PrivateName.h:
        (JSC::PrivateName::PrivateName):

2016-09-06  Daniel Bates  <dabates@apple.com>

        [iOS] Build fails in JSCLLIntOffsetsExtractor - Ad Hoc code signing is not allowed with SDK 'Simulator - iOS 10.0'
        https://bugs.webkit.org/show_bug.cgi?id=161296

        Reviewed by Dan Bernstein.

        Allow ad-hoc code signing when building JavaScriptCore command line tools for simulator
        with the iOS 10 beta SDK.

        * Configurations/Base.xcconfig:

2016-09-06  Saam Barati  <sbarati@apple.com>

        Unreviewed build fix for 32-bit platforms after r205520.

        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation): Deleted.

2016-09-06  Saam Barati  <sbarati@apple.com>

        Member call on NULL pointer in JavaScriptCore/dfg/DFGAbstractInterpretterInlines.h
        https://bugs.webkit.org/show_bug.cgi?id=160870

        Reviewed by Darin Adler.

        Credit goes to Jonathan Bedard for finding this bug using the undefined
        behavior sanitizer.

        The rule for MaterializeNewObject inside AI was assuming that the graph
        is in SSA form. This used to be true when MaterializeNewObject was only
        inserted by the allocation sinking phase. However, Filip added more uses
        of MaterializeNewObject in his RegExp constant folding patch. This fixes
        the bug by using the structure set inside the Node's OpInfo rather than
        generating it from m_phiChildren inside AI.

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

2016-09-06  Saam Barati  <sbarati@apple.com>

        Make JSMap and JSSet faster
        https://bugs.webkit.org/show_bug.cgi?id=160989

        Reviewed by Filip Pizlo.

        This patch revamps how we implement Map and Set. It uses
        a new hash map implementation. The hash map uses linear
        probing and it uses Wang's 64 bit hash function for JSValues
        that aren't strings. Strings use StringImpl's hash function.
        The reason I wanted to roll our own HashTable is twofold:
        I didn't want to inline WTF::HashMap's implementation into our
        JIT, since that seems error prone and unmaintainable. Also, I wanted
        a different structure for hash map buckets where buckets also exist in
        a linked list.

        The reason for making buckets part of a linked list is that iteration
        is now simple. Iteration works by just traversing a linked list.
        This design also allows for a simple implementation when doing iteration
        while the hash table is mutating. Whenever we remove a bucket from
        the hash table, it is removed from the list, meaning items in the
        list don't point to it. However, the removed bucket will still point
        to things that are either in the list, or have also been removed.
        e.g, from a removed bucket, you can always follow pointers until you
        either find an item in the list, or you find the tail of the list.
        This is a really nice property because it means that a Map or Set
        does not need to reason about the all the iterators that point
        into its list. Also, whenever we add items to the Map or Set, we
        hijack the tail as the new item, and make the new item point to a newly
        created tail. This means that any iterator that pointed to the "tail" now
        points to non-tail items. This makes the implementation of adding things
        to the Map/Set while iterating easy.

        I also made Map.prototype.get, Map.prototype.has, and Set.prototype.has
        into intrinsics in the DFG. The IR can now reason about hash map
        operations and can even do CSE over Wang's hash function, hash map
        bucket lookups, hash map bucket loads, and testing if a key is in
        the hash table. This makes code patterns for Map like so, super fast
        in the FTL, since we will only be doing a single hash and hash bucket lookup:

        ```
        function getKeyIfPresent(map, key) {
            if (map.has(key))
                return map.get(key);
        }
        ```

        This patch is roughly an 8% speedup on ES6SampleBench.


        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::not64):
        * bytecode/SpeculatedType.cpp:
        (JSC::speculationFromClassInfo):
        * bytecode/SpeculatedType.h:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::execute):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGEdge.h:
        (JSC::DFG::Edge::shift):
        (JSC::DFG::Edge::makeWord):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGHeapLocation.h:
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasHeapPrediction):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::SafeToExecuteEdge::operator()):
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::speculateMapObject):
        (JSC::DFG::SpeculativeJIT::speculateSetObject):
        (JSC::DFG::SpeculativeJIT::speculate):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGUseKind.cpp:
        (WTF::printInternal):
        * dfg/DFGUseKind.h:
        (JSC::DFG::typeFilterFor):
        (JSC::DFG::isCell):
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileMapHash):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucket):
        (JSC::FTL::DFG::LowerDFGToB3::compileLoadFromJSMapBucket):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsNonEmptyMapBucket):
        (JSC::FTL::DFG::LowerDFGToB3::lowMapObject):
        (JSC::FTL::DFG::LowerDFGToB3::lowSetObject):
        (JSC::FTL::DFG::LowerDFGToB3::lowMapBucket):
        (JSC::FTL::DFG::LowerDFGToB3::speculate):
        (JSC::FTL::DFG::LowerDFGToB3::speculateMapObject):
        (JSC::FTL::DFG::LowerDFGToB3::speculateSetObject):
        (JSC::FTL::DFG::LowerDFGToB3::setMapBucket):
        (JSC::FTL::DFG::LowerDFGToB3::lowRegExpObject): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::lowStorage): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::speculateRegExpObject): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::setStorage): Deleted.
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::wangsInt64Hash):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitAllocateDestructibleObject): Deleted.
        * jit/JITOperations.h:
        * parser/ModuleAnalyzer.cpp:
        (JSC::ModuleAnalyzer::ModuleAnalyzer):
        * runtime/HashMapImpl.cpp: Added.
        (JSC::HashMapBucket<Data>::visitChildren):
        (JSC::HashMapImpl<HashMapBucket>::visitChildren):
        (JSC::HashMapImpl<HashMapBucket>::copyBackingStore):
        * runtime/HashMapImpl.h: Added.
        (JSC::HashMapBucket::selectStructure):
        (JSC::HashMapBucket::createStructure):
        (JSC::HashMapBucket::create):
        (JSC::HashMapBucket::HashMapBucket):
        (JSC::HashMapBucket::setNext):
        (JSC::HashMapBucket::setPrev):
        (JSC::HashMapBucket::setKey):
        (JSC::HashMapBucket::setValue):
        (JSC::HashMapBucket::key):
        (JSC::HashMapBucket::value):
        (JSC::HashMapBucket::next):
        (JSC::HashMapBucket::prev):
        (JSC::HashMapBucket::deleted):
        (JSC::HashMapBucket::setDeleted):
        (JSC::HashMapBucket::offsetOfKey):
        (JSC::HashMapBucket::offsetOfValue):
        (JSC::HashMapBuffer::allocationSize):
        (JSC::HashMapBuffer::buffer):
        (JSC::HashMapBuffer::create):
        (JSC::areKeysEqual):
        (JSC::normalizeMapKey):
        (JSC::jsMapHash):
        (JSC::HashMapImpl::selectStructure):
        (JSC::HashMapImpl::createStructure):
        (JSC::HashMapImpl::create):
        (JSC::HashMapImpl::HashMapImpl):
        (JSC::HashMapImpl::buffer):
        (JSC::HashMapImpl::finishCreation):
        (JSC::HashMapImpl::emptyValue):
        (JSC::HashMapImpl::isEmpty):
        (JSC::HashMapImpl::deletedValue):
        (JSC::HashMapImpl::isDeleted):
        (JSC::HashMapImpl::findBucket):
        (JSC::HashMapImpl::get):
        (JSC::HashMapImpl::has):
        (JSC::HashMapImpl::add):
        (JSC::HashMapImpl::remove):
        (JSC::HashMapImpl::size):
        (JSC::HashMapImpl::clear):
        (JSC::HashMapImpl::bufferSizeInBytes):
        (JSC::HashMapImpl::offsetOfBuffer):
        (JSC::HashMapImpl::offsetOfCapacity):
        (JSC::HashMapImpl::head):
        (JSC::HashMapImpl::tail):
        (JSC::HashMapImpl::approximateSize):
        (JSC::HashMapImpl::findBucketAlreadyHashedAndNormalized):
        (JSC::HashMapImpl::rehash):
        (JSC::HashMapImpl::makeAndSetNewBuffer):
        * runtime/Intrinsic.h:
        * runtime/JSCJSValue.h:
        * runtime/JSCJSValueInlines.h:
        (JSC::sameValue):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSMap.cpp:
        (JSC::JSMap::destroy): Deleted.
        (JSC::JSMap::estimatedSize): Deleted.
        (JSC::JSMap::visitChildren): Deleted.
        (JSC::JSMap::copyBackingStore): Deleted.
        (JSC::JSMap::has): Deleted.
        (JSC::JSMap::size): Deleted.
        (JSC::JSMap::get): Deleted.
        (JSC::JSMap::set): Deleted.
        (JSC::JSMap::clear): Deleted.
        (JSC::JSMap::remove): Deleted.
        * runtime/JSMap.h:
        (JSC::JSMap::createStructure):
        (JSC::JSMap::create):
        (JSC::JSMap::get):
        (JSC::JSMap::set):
        (JSC::JSMap::JSMap):
        (JSC::JSMap::Entry::key): Deleted.
        (JSC::JSMap::Entry::value): Deleted.
        (JSC::JSMap::Entry::visitChildren): Deleted.
        (JSC::JSMap::Entry::setKey): Deleted.
        (JSC::JSMap::Entry::setKeyWithoutWriteBarrier): Deleted.
        (JSC::JSMap::Entry::setValue): Deleted.
        (JSC::JSMap::Entry::clear): Deleted.
        * runtime/JSMapIterator.cpp:
        (JSC::JSMapIterator::finishCreation):
        (JSC::JSMapIterator::visitChildren):
        (JSC::JSMapIterator::clone):
        * runtime/JSMapIterator.h:
        (JSC::JSMapIterator::advanceIter):
        (JSC::JSMapIterator::next):
        (JSC::JSMapIterator::nextKeyValue):
        (JSC::JSMapIterator::JSMapIterator):
        (JSC::JSMapIterator::setIterator):
        (JSC::JSMapIterator::finish): Deleted.
        (JSC::JSMapIterator::iteratorData): Deleted.
        * runtime/JSModuleLoader.cpp:
        (JSC::JSModuleLoader::finishCreation):
        * runtime/JSModuleLoader.h:
        (JSC::JSModuleLoader::create):
        * runtime/JSModuleRecord.cpp:
        (JSC::JSModuleRecord::finishCreation):
        * runtime/JSModuleRecord.h:
        (JSC::JSModuleRecord::create):
        * runtime/JSSet.cpp:
        (JSC::JSSet::destroy): Deleted.
        (JSC::JSSet::estimatedSize): Deleted.
        (JSC::JSSet::visitChildren): Deleted.
        (JSC::JSSet::copyBackingStore): Deleted.
        (JSC::JSSet::has): Deleted.
        (JSC::JSSet::size): Deleted.
        (JSC::JSSet::add): Deleted.
        (JSC::JSSet::clear): Deleted.
        (JSC::JSSet::remove): Deleted.
        * runtime/JSSet.h:
        (JSC::JSSet::createStructure):
        (JSC::JSSet::create):
        (JSC::JSSet::add):
        (JSC::JSSet::JSSet):
        (JSC::JSSet::Entry::key): Deleted.
        (JSC::JSSet::Entry::value): Deleted.
        (JSC::JSSet::Entry::visitChildren): Deleted.
        (JSC::JSSet::Entry::setKey): Deleted.
        (JSC::JSSet::Entry::setKeyWithoutWriteBarrier): Deleted.
        (JSC::JSSet::Entry::setValue): Deleted.
        (JSC::JSSet::Entry::clear): Deleted.
        * runtime/JSSetIterator.cpp:
        (JSC::JSSetIterator::finishCreation):
        (JSC::JSSetIterator::visitChildren):
        (JSC::JSSetIterator::clone):
        * runtime/JSSetIterator.h:
        (JSC::JSSetIterator::advanceIter):
        (JSC::JSSetIterator::next):
        (JSC::JSSetIterator::JSSetIterator):
        (JSC::JSSetIterator::setIterator):
        (JSC::JSSetIterator::finish): Deleted.
        (JSC::JSSetIterator::iteratorData): Deleted.
        * runtime/JSType.h:
        * runtime/MapBase.cpp: Added.
        (JSC::MapBase<HashMapBucketType>::visitChildren):
        (JSC::MapBase<HashMapBucketType>::estimatedSize):
        * runtime/MapBase.h: Added.
        (JSC::MapBase::size):
        (JSC::MapBase::has):
        (JSC::MapBase::clear):
        (JSC::MapBase::remove):
        (JSC::MapBase::findBucket):
        (JSC::MapBase::offsetOfHashMapImpl):
        (JSC::MapBase::impl):
        (JSC::MapBase::finishCreation):
        (JSC::MapBase::MapBase):
        * runtime/MapConstructor.cpp:
        (JSC::constructMap):
        * runtime/MapIteratorPrototype.cpp:
        (JSC::MapIteratorPrototypeFuncNext):
        * runtime/MapPrototype.cpp:
        (JSC::MapPrototype::finishCreation):
        (JSC::getMap):
        (JSC::privateFuncIsMap):
        (JSC::privateFuncMapIteratorNext):
        * runtime/PropertyDescriptor.cpp:
        (JSC::sameValue): Deleted.
        * runtime/PropertyDescriptor.h:
        * runtime/SetConstructor.cpp:
        (JSC::constructSet):
        * runtime/SetIteratorPrototype.cpp:
        (JSC::SetIteratorPrototypeFuncNext):
        * runtime/SetPrototype.cpp:
        (JSC::SetPrototype::finishCreation):
        (JSC::getSet):
        (JSC::privateFuncSetIteratorNext):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2016-09-06  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Make ArithClz32 work with Cell arguments
        https://bugs.webkit.org/show_bug.cgi?id=161369

        Reviewed by Geoffrey Garen.

        ArithClz32 was already working with all primitive types
        thanks to the magic of ValueToInt32.
        This patch adds support for cell arguments through a function
        call.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithClz32):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileArithClz32):

2016-09-06  Mark Lam  <mark.lam@apple.com>

        Gardening: change to use old header guard to appease Win EWS.

        Not reviewed.

        * runtime/AuxiliaryBarrier.h:

2016-09-06  Commit Queue  <commit-queue@webkit.org>

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

        This change broke the Windows build (Requested by ryanhaddad
        on #webkit).

        Reverted changeset:

        "Typed arrays should use MarkedSpace instead of CopiedSpace"
        https://bugs.webkit.org/show_bug.cgi?id=161100
        http://trac.webkit.org/changeset/205494

2016-09-06  Commit Queue  <commit-queue@webkit.org>

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

        Broke the iOS device build (Requested by ryanhaddad on
        #webkit).

        Reverted changeset:

        "Make JSMap and JSSet faster"
        https://bugs.webkit.org/show_bug.cgi?id=160989
        http://trac.webkit.org/changeset/205504

2016-09-06  Saam Barati  <sbarati@apple.com>

        Make JSMap and JSSet faster
        https://bugs.webkit.org/show_bug.cgi?id=160989

        Reviewed by Filip Pizlo.

        This patch revamps how we implement Map and Set. It uses
        a new hash map implementation. The hash map uses linear
        probing and it uses Wang's 64 bit hash function for JSValues
        that aren't strings. Strings use StringImpl's hash function.
        The reason I wanted to roll our own HashTable is twofold:
        I didn't want to inline WTF::HashMap's implementation into our
        JIT, since that seems error prone and unmaintainable. Also, I wanted
        a different structure for hash map buckets where buckets also exist in
        a linked list.

        The reason for making buckets part of a linked list is that iteration
        is now simple. Iteration works by just traversing a linked list.
        This design also allows for a simple implementation when doing iteration
        while the hash table is mutating. Whenever we remove a bucket from
        the hash table, it is removed from the list, meaning items in the
        list don't point to it. However, the removed bucket will still point
        to things that are either in the list, or have also been removed.
        e.g, from a removed bucket, you can always follow pointers until you
        either find an item in the list, or you find the tail of the list.
        This is a really nice property because it means that a Map or Set
        does not need to reason about the all the iterators that point
        into its list. Also, whenever we add items to the Map or Set, we
        hijack the tail as the new item, and make the new item point to a newly
        created tail. This means that any iterator that pointed to the "tail" now
        points to non-tail items. This makes the implementation of adding things
        to the Map/Set while iterating easy.

        I also made Map.prototype.get, Map.prototype.has, and Set.prototype.has
        into intrinsics in the DFG. The IR can now reason about hash map
        operations and can even do CSE over Wang's hash function, hash map
        bucket lookups, hash map bucket loads, and testing if a key is in
        the hash table. This makes code patterns for Map like so, super fast
        in the FTL, since we will only be doing a single hash and hash bucket lookup:

        ```
        function getKeyIfPresent(map, key) {
            if (map.has(key))
                return map.get(key);
        }
        ```

        This patch is roughly an 8% speedup on ES6SampleBench.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/SpeculatedType.cpp:
        (JSC::speculationFromClassInfo):
        * bytecode/SpeculatedType.h:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::execute):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGEdge.h:
        (JSC::DFG::Edge::shift):
        (JSC::DFG::Edge::makeWord):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGHeapLocation.h:
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasHeapPrediction):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::SafeToExecuteEdge::operator()):
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::speculateMapObject):
        (JSC::DFG::SpeculativeJIT::speculateSetObject):
        (JSC::DFG::SpeculativeJIT::speculate):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGUseKind.cpp:
        (WTF::printInternal):
        * dfg/DFGUseKind.h:
        (JSC::DFG::typeFilterFor):
        (JSC::DFG::isCell):
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileMapHash):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucket):
        (JSC::FTL::DFG::LowerDFGToB3::compileLoadFromJSMapBucket):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsNonEmptyMapBucket):
        (JSC::FTL::DFG::LowerDFGToB3::lowMapObject):
        (JSC::FTL::DFG::LowerDFGToB3::lowSetObject):
        (JSC::FTL::DFG::LowerDFGToB3::lowMapBucket):
        (JSC::FTL::DFG::LowerDFGToB3::speculate):
        (JSC::FTL::DFG::LowerDFGToB3::speculateMapObject):
        (JSC::FTL::DFG::LowerDFGToB3::speculateSetObject):
        (JSC::FTL::DFG::LowerDFGToB3::setMapBucket):
        (JSC::FTL::DFG::LowerDFGToB3::lowRegExpObject): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::lowStorage): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::speculateRegExpObject): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::setStorage): Deleted.
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::wangsInt64Hash):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitAllocateDestructibleObject): Deleted.
        * jit/JITOperations.h:
        * parser/ModuleAnalyzer.cpp:
        (JSC::ModuleAnalyzer::ModuleAnalyzer):
        * runtime/HashMapImpl.cpp: Added.
        (JSC::HashMapBucket<Data>::visitChildren):
        (JSC::HashMapImpl<HashMapBucket>::visitChildren):
        (JSC::HashMapImpl<HashMapBucket>::copyBackingStore):
        * runtime/HashMapImpl.h: Added.
        (JSC::HashMapBucket::selectStructure):
        (JSC::HashMapBucket::createStructure):
        (JSC::HashMapBucket::create):
        (JSC::HashMapBucket::HashMapBucket):
        (JSC::HashMapBucket::setNext):
        (JSC::HashMapBucket::setPrev):
        (JSC::HashMapBucket::setKey):
        (JSC::HashMapBucket::setValue):
        (JSC::HashMapBucket::key):
        (JSC::HashMapBucket::value):
        (JSC::HashMapBucket::next):
        (JSC::HashMapBucket::prev):
        (JSC::HashMapBucket::deleted):
        (JSC::HashMapBucket::setDeleted):
        (JSC::HashMapBucket::offsetOfKey):
        (JSC::HashMapBucket::offsetOfValue):
        (JSC::HashMapBuffer::allocationSize):
        (JSC::HashMapBuffer::buffer):
        (JSC::HashMapBuffer::create):
        (JSC::areKeysEqual):
        (JSC::normalizeMapKey):
        (JSC::jsMapHash):
        (JSC::HashMapImpl::selectStructure):
        (JSC::HashMapImpl::createStructure):
        (JSC::HashMapImpl::create):
        (JSC::HashMapImpl::HashMapImpl):
        (JSC::HashMapImpl::buffer):
        (JSC::HashMapImpl::finishCreation):
        (JSC::HashMapImpl::emptyValue):
        (JSC::HashMapImpl::isEmpty):
        (JSC::HashMapImpl::deletedValue):
        (JSC::HashMapImpl::isDeleted):
        (JSC::HashMapImpl::findBucket):
        (JSC::HashMapImpl::get):
        (JSC::HashMapImpl::has):
        (JSC::HashMapImpl::add):
        (JSC::HashMapImpl::remove):
        (JSC::HashMapImpl::size):
        (JSC::HashMapImpl::clear):
        (JSC::HashMapImpl::bufferSizeInBytes):
        (JSC::HashMapImpl::offsetOfBuffer):
        (JSC::HashMapImpl::offsetOfCapacity):
        (JSC::HashMapImpl::head):
        (JSC::HashMapImpl::tail):
        (JSC::HashMapImpl::approximateSize):
        (JSC::HashMapImpl::findBucketAlreadyHashedAndNormalized):
        (JSC::HashMapImpl::rehash):
        (JSC::HashMapImpl::makeAndSetNewBuffer):
        * runtime/Intrinsic.h:
        * runtime/JSCJSValue.h:
        * runtime/JSCJSValueInlines.h:
        (JSC::sameValue):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSMap.cpp:
        (JSC::JSMap::destroy): Deleted.
        (JSC::JSMap::estimatedSize): Deleted.
        (JSC::JSMap::visitChildren): Deleted.
        (JSC::JSMap::copyBackingStore): Deleted.
        (JSC::JSMap::has): Deleted.
        (JSC::JSMap::size): Deleted.
        (JSC::JSMap::get): Deleted.
        (JSC::JSMap::set): Deleted.
        (JSC::JSMap::clear): Deleted.
        (JSC::JSMap::remove): Deleted.
        * runtime/JSMap.h:
        (JSC::JSMap::createStructure):
        (JSC::JSMap::create):
        (JSC::JSMap::get):
        (JSC::JSMap::set):
        (JSC::JSMap::JSMap):
        (JSC::JSMap::Entry::key): Deleted.
        (JSC::JSMap::Entry::value): Deleted.
        (JSC::JSMap::Entry::visitChildren): Deleted.
        (JSC::JSMap::Entry::setKey): Deleted.
        (JSC::JSMap::Entry::setKeyWithoutWriteBarrier): Deleted.
        (JSC::JSMap::Entry::setValue): Deleted.
        (JSC::JSMap::Entry::clear): Deleted.
        * runtime/JSMapIterator.cpp:
        (JSC::JSMapIterator::finishCreation):
        (JSC::JSMapIterator::visitChildren):
        (JSC::JSMapIterator::clone):
        * runtime/JSMapIterator.h:
        (JSC::JSMapIterator::advanceIter):
        (JSC::JSMapIterator::next):
        (JSC::JSMapIterator::nextKeyValue):
        (JSC::JSMapIterator::JSMapIterator):
        (JSC::JSMapIterator::setIterator):
        (JSC::JSMapIterator::finish): Deleted.
        (JSC::JSMapIterator::iteratorData): Deleted.
        * runtime/JSModuleLoader.cpp:
        (JSC::JSModuleLoader::finishCreation):
        * runtime/JSModuleLoader.h:
        (JSC::JSModuleLoader::create):
        * runtime/JSModuleRecord.cpp:
        (JSC::JSModuleRecord::finishCreation):
        * runtime/JSModuleRecord.h:
        (JSC::JSModuleRecord::create):
        * runtime/JSSet.cpp:
        (JSC::JSSet::destroy): Deleted.
        (JSC::JSSet::estimatedSize): Deleted.
        (JSC::JSSet::visitChildren): Deleted.
        (JSC::JSSet::copyBackingStore): Deleted.
        (JSC::JSSet::has): Deleted.
        (JSC::JSSet::size): Deleted.
        (JSC::JSSet::add): Deleted.
        (JSC::JSSet::clear): Deleted.
        (JSC::JSSet::remove): Deleted.
        * runtime/JSSet.h:
        (JSC::JSSet::createStructure):
        (JSC::JSSet::create):
        (JSC::JSSet::add):
        (JSC::JSSet::JSSet):
        (JSC::JSSet::Entry::key): Deleted.
        (JSC::JSSet::Entry::value): Deleted.
        (JSC::JSSet::Entry::visitChildren): Deleted.
        (JSC::JSSet::Entry::setKey): Deleted.
        (JSC::JSSet::Entry::setKeyWithoutWriteBarrier): Deleted.
        (JSC::JSSet::Entry::setValue): Deleted.
        (JSC::JSSet::Entry::clear): Deleted.
        * runtime/JSSetIterator.cpp:
        (JSC::JSSetIterator::finishCreation):
        (JSC::JSSetIterator::visitChildren):
        (JSC::JSSetIterator::clone):
        * runtime/JSSetIterator.h:
        (JSC::JSSetIterator::advanceIter):
        (JSC::JSSetIterator::next):
        (JSC::JSSetIterator::JSSetIterator):
        (JSC::JSSetIterator::setIterator):
        (JSC::JSSetIterator::finish): Deleted.
        (JSC::JSSetIterator::iteratorData): Deleted.
        * runtime/JSType.h:
        * runtime/MapBase.cpp: Added.
        (JSC::MapBase<HashMapBucketType>::visitChildren):
        (JSC::MapBase<HashMapBucketType>::estimatedSize):
        * runtime/MapBase.h: Added.
        (JSC::MapBase::size):
        (JSC::MapBase::has):
        (JSC::MapBase::clear):
        (JSC::MapBase::remove):
        (JSC::MapBase::findBucket):
        (JSC::MapBase::offsetOfHashMapImpl):
        (JSC::MapBase::impl):
        (JSC::MapBase::finishCreation):
        (JSC::MapBase::MapBase):
        * runtime/MapConstructor.cpp:
        (JSC::constructMap):
        * runtime/MapIteratorPrototype.cpp:
        (JSC::MapIteratorPrototypeFuncNext):
        * runtime/MapPrototype.cpp:
        (JSC::MapPrototype::finishCreation):
        (JSC::getMap):
        (JSC::privateFuncIsMap):
        (JSC::privateFuncMapIteratorNext):
        * runtime/PropertyDescriptor.cpp:
        (JSC::sameValue): Deleted.
        * runtime/PropertyDescriptor.h:
        * runtime/SetConstructor.cpp:
        (JSC::constructSet):
        * runtime/SetIteratorPrototype.cpp:
        (JSC::SetIteratorPrototypeFuncNext):
        * runtime/SetPrototype.cpp:
        (JSC::SetPrototype::finishCreation):
        (JSC::getSet):
        (JSC::privateFuncSetIteratorNext):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2016-09-06  Filip Pizlo  <fpizlo@apple.com>

        Typed arrays should use MarkedSpace instead of CopiedSpace
        https://bugs.webkit.org/show_bug.cgi?id=161100

        Reviewed by Geoffrey Garen.
        
        This moves typed array backing stores out of CopiedSpace and into Auxiliary MarkedSpace.
        
        This is a purely mechanical change since Auxiliary MarkedSpace already knows how to do
        everything that typed arrays want.

        * dfg/DFGOperations.cpp:
        (JSC::DFG::newTypedArrayWithSize):
        * dfg/DFGOperations.h:
        (JSC::DFG::operationNewTypedArrayWithSizeForType):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNewTypedArray):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        (JSC::DFG::SpeculativeJIT::emitAllocateBasicStorage): Deleted.
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
        (JSC::FTL::DFG::LowerDFGToB3::initializeArrayElements):
        (JSC::FTL::DFG::LowerDFGToB3::splatWords):
        (JSC::FTL::DFG::LowerDFGToB3::allocateBasicStorageAndGetEnd): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::allocateBasicStorage): Deleted.
        * heap/CopyToken.h:
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::markAuxiliary):
        * jit/JITOperations.h:
        * runtime/JSArrayBufferView.cpp:
        (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
        (JSC::JSArrayBufferView::JSArrayBufferView):
        * runtime/JSArrayBufferView.h:
        * runtime/JSGenericTypedArrayView.h:
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::createWithFastVector):
        (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren):
        (JSC::JSGenericTypedArrayView<Adaptor>::slowDownAndWasteMemory):
        (JSC::JSGenericTypedArrayView<Adaptor>::copyBackingStore): Deleted.

2016-09-06  Michael Catanzaro  <mcatanzaro@igalia.com>

        Silence GCC warning spam introduced in r205462

        Rubber-stamped by Filip Pizlo.

        * bytecode/Opcode.h:
        (JSC::padOpcodeName):

2016-09-05  Filip Pizlo  <fpizlo@apple.com>

        Heap::isMarked() should use concurrent lazy flipping
        https://bugs.webkit.org/show_bug.cgi?id=161613

        Reviewed by Michael Catanzaro.
        
        I found out about this race condition via
        https://bugs.webkit.org/show_bug.cgi?id=160125#c233.
        
        The problem is that we use isMarked, and maybe even isLive, inside the concurrent mark
        phase. So, they need to lazy-flip in a non-racy way.

        * heap/HeapInlines.h:
        (JSC::Heap::isLive):
        (JSC::Heap::isMarked):

2016-09-05  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, reset generator test results after the butterflies.

        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
        * Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCoreJSBuiltins.h-result:

2016-09-05  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix cloop build.

        * bytecode/SuperSampler.cpp:

2016-08-31  Filip Pizlo  <fpizlo@apple.com>

        Butterflies should be allocated in Auxiliary MarkedSpace instead of CopiedSpace and we should rewrite as much of the GC as needed to make this not a regression
        https://bugs.webkit.org/show_bug.cgi?id=160125

        Reviewed by Geoffrey Garen and Keith Miller.

        In order to make the GC concurrent (bug 149432), we would either need to enable concurrent
        copying or we would need to not copy. Concurrent copying carries a 1-2% throughput overhead
        from the barriers alone. Considering that MarkedSpace does a decent job of avoiding
        fragmentation, it's unlikely that it's worth paying 1-2% throughput for copying. So, we want
        to get rid of copied space. This change moves copied space's biggest client over to marked
        space.
        
        Moving butterflies to marked space means having them use the new Auxiliary HeapCell
        allocation path. This is a fairly mechanical change, but it caused performance regressions
        everywhere, so this change also fixes MarkedSpace's performance issues.
        
        At a high level the mechanical changes are:
        
        - We use AuxiliaryBarrier instead of CopyBarrier.
        
        - We use tryAllocateAuxiliary instead of tryAllocateStorage. I got rid of the silly
          CheckedBoolean stuff, since it's so much more trouble than it's worth.
        
        - The JITs have to emit inlined marked space allocations instead of inline copy space
          allocations.
        
        - Everyone has to get used to zeroing their butterflies after allocation instead of relying
          on them being pre-zeroed by the GC. Copied space would zero things for you, while marked
          space doesn't.
        
        That's about 1/3 of this change. But this led to performance problems, which I fixed with
        optimizations that amounted to a major MarkedSpace rewrite:
        
        - MarkedSpace always causes internal fragmentation for array allocations because the vector
          length we choose when we resize usually leads to a cell size that doesn't correspond to any
          size class. I got around this by making array allocations usually round up vectorLength to
          the maximum allowed by the size class that we would have allocated in. Also,
          ensureLengthSlow() and friends first make sure that the requested length can't just be
          fulfilled with the current allocation size. This safeguard means that not every array
          allocation has to do size class queries. For example, the fast path of new Array(length)
          never does any size class queries, under the assumption that (1) the speed gained from
          avoiding an ensureLengthSlow() call, which then just changes the vectorLength by doing the
          size class query, is too small to offset the speed lost by doing the query on every
          allocation and (2) new Array(length) is a pretty good hint that resizing is not very
          likely.
        
        - Size classes in MarkedSpace were way too precise, which led to external fragmentation. This
          changes MarkedSpace size classes to use a linear progression for very small sizes followed
          by a geometric progression that naturally transitions to a hyperbolic progression. We want
          hyperbolic sizes when we get close to blockSize: for example the largest size we want is
          payloadSize / 2 rounded down, to ensure we get exactly two cells with minimal slop. The
          next size down should be payloadSize / 3 rounded down, and so on. After the last precise
          size (80 bytes), we proceed using a geometric progression, but round up each size to
          minimize slop at the end of the block. This naturally causes the geometric progression to
          turn hyperbolic for large sizes. The size class configuration happens at VM start-up, so
          it can be controlled with runtime options. I found that a base of 1.4 works pretty well.
        
        - Large allocations caused massive internal fragmentation, since the smallest large
          allocation had to use exactly blockSize, and the largest small allocation used
          blockSize / 2. The next size up - the first large allocation size to require two blocks -
          also had 50% internal fragmentation. This is because we required large allocations to be
          blockSize aligned, so that MarkedBlock::blockFor() would work. I decided to rewrite all of
          that. Cells no longer have to be owned by a MarkedBlock. They can now alternatively be
          owned by a LargeAllocation. These two things are abstracted as CellContainer. You know that
          a cell is owned by a LargeAllocation if the MarkedBlock::atomSize / 2 bit is set.
          Basically, large allocations are deliberately misaligned by 8 bytes. This actually works
          out great since (1) typed arrays won't use large allocations anyway since they have their
          own malloc fallback and (2) large array butterflies already have a 8 byte header, which
          means that the 8 byte base misalignment aligns the large array payload on a 16 byte
          boundary. I took extreme care to make sure that the isLargeAllocation bit checks are as
          rare as possible; for example, ExecState::vm() skips the check because we know that callees
          must be small allocations. It's also possible to use template tricks to do one check for
          cell container kind, and then invoke a function specialized for MarkedBlock or a function
          specialized for LargeAllocation. LargeAllocation includes stubs for all MarkedBlock methods
          that get used from functions that are template-specialized like this. That's mostly to
          speed up the GC marking code. Most other code can use CellContainer API or HeapCell API
          directly. That's another thing: HeapCell, the common base of JSCell and auxiliary
          allocations, is now smart enough to do a lot of things for you, like HeapCell::vm(),
          HeapCell::heap(), HeapCell::isLargeAllocation(), and HeapCell::cellContainer(). The size
          cutoff for large allocations is runtime-configurable, so long as you don't choose something
          so small that callees end up large. I found that 400 bytes is roughly optimal. This means
          that the MarkedBlock size classes end up being:
          
          16, 32, 48, 64, 80, 112, 160, 224, 320
          
          The next size class would have been 432, but that's above the 400 byte cutoff. All of this
          is configurable with --sizeClassProgression and --largeAllocationCutoff. You can see what
          size classes you end up with by doing --dumpSizeClasses=true.
        
        - Copied space uses 64KB blocks, while marked space used to use 16KB blocks. Allocating a lot
          of stuff in 16KB blocks was slower than allocating it in 64KB blocks because the GC had a
          lot of per-block overhead. I removed this overhead: It's now 2x faster to scan all
          MarkedBlocks because the list that contains the interesting meta-data is allocated on the
          side, for better locality during a sequential walk. It's no longer necessary to scan
          MarkedBlocks to find WeakSets, since the sets of WeakSets for eden scan and full scan are
          maintained on-the-fly. It's no longer necessary to scan all MarkedBlocks to clear mark
          bits because we now use versioned mark bits: to clear then, just increment the 64-bit
          heap version. It's no longer necessary to scan retired MarkedBlocks while allocating
          because marking retires them on-the-fly. It's no longer necessary to sort all blocks in
          the IncrementalSweeper's snapshot because blocks now know if they are in the snapshot. Put
          together, these optimizations allowed me to reduce block size to 16KB without losing much
          performance. There is some small perf loss on JetStream/splay, but not enough to hurt
          JetStream overall. I tried reducing block sizes further, to 4KB, since that is a
          progression on membuster. That's not possible yet, since there is still enough per-block
          overhead yet that such a reduction hurts JetStream too much. I filed a bug about improving
          this further: https://bugs.webkit.org/show_bug.cgi?id=161581.
        
        - Even after all of that, copying butterflies was still faster because it allowed us to skip
          sweeping dead space. A good GC allocates over dead bytes without explicitly freeing them,
          so the GC pause is O(size of live), not O(size of live + dead). O(dead) is usually much
          larger than O(live), especially in an eden collection. Copying satisfies this premise while
          mark+sweep does not. So, I invented a new kind of allocator: bump'n'pop. Previously, our
          MarkedSpace allocator was a freelist pop. That's simple and easy to inline but requires
          that we walk the block to build a free list. This means walking dead space. The new
          allocator allows totally free MarkedBlocks to simply set up a bump-pointer arena instead.
          The allocator is a hybrid of bump-pointer and freelist pop. It tries bump first. The bump
          pointer always bumps by cellSize, so the result of filling a block with bumping looks as if
          we had used freelist popping to fill it. Additionally, each MarkedBlock now has a bit to
          quickly tell if the block is entirely free. This makes sweeping O(1) whenever a MarkedBlock
          is completely empty, which is the common case because of the generational hypothesis: the
          number of objects that survive an eden collection is a tiny fraction of the number of
          objects that had been allocated, and this fraction is so small that there are typically
          fewer than one survivors per MarkedBlock. This change was enough to make this change a net
          win over tip-of-tree.
        
        - FTL now shares the same allocation fast paths as everything else, which is great, because
          bump'n'pop has gnarly control flow. We don't really want B3 to have to think about that
          control flow, since it won't be able to improve the machine code we write ourselves. GC
          fast paths are best written in assembly. So, I've empowered B3 to have even better support
          for Patchpoint terminals. It's now totally fine for a Patchpoint terminal to be non-Void.
          So, the new FTL allocation fast paths are just Patchpoint terminals that call through to
          AssemblyHelpers::emitAllocate(). B3 still reasons about things like constant-folding the
          size class calculation and constant-hoisting the allocator. Also, I gave the FTL the
          ability to constant-fold some allocator logic (in case we first assume that we're doing a
          variable-length allocation but then realize that the length is known). I think it makes
          sense to have constant folding rules in FTL::Output, or whatever the B3 IR builder is,
          since this makes lowering easier (you can constant fold during lowering more easily) and it
          reduces the amount of malloc traffic. In the future, we could teach B3 how to better
          constant-fold this code. That would require allowing loads to be constant-folded, which is
          doable but hella tricky.
        
        - It used to be that if a logical object allocation required two physical allocations (first
          the butterfly and then the cell), then the JIT would emit the code in such a way that a
          failure in the second fast path would cause us to forget the successful first physical
          allocation. This was pointlessly wasteful. It turns out that it's very cheap to devote a
          register to storing either the butterfly or null, because the butterfly register is anyway
          going to be free inside the first allocation. The only overhead here is zeroing the
          butterfly register. With that in place, we can just pass the butterfly-or-null to the slow
          path, which can then either allocate a butterfly or not. So now we never waste a successful
          allocation. This patch implements such a solution both in DFG (where it's easy to do this
          since we control registers already) and in FTL (where it's annoying, because mutable
          "butterfly-or-null" variables are hard to say in SSA; also I realized that we had code
          duplicated the JSArray allocation utility, so I deduplicated it). This came up because in
          one version of this patch, this wastage would resonate with some Kraken benchmark: the
          benchmark would always allocate N small things followed by one bigger thing. The problem
          was I accidentally adjusted the various fixed overheads in MarkedBlock in such a way that
          the JSObject size class, which both the small and big thing shared for their cell, could
          hold exactly N cells per MarkedBlock. Then the benchmark would always call slow path when
          it allocated the big thing. So, it would end up having to allocate the big thing's large
          butterfly twice, every single time! Ouch!
        
        - It used to be that we zeroed CopiedBlocks using memset, and so array allocations enjoyed
          amortization of the cost of zeroing. This doesn't work anymore - it's now up to the client
          of the allocator to initialize the object to whatever state they need. It used to be that
          we would just use a dumb loop. I initially changed this so that we would end up in memset
          for large allocations, but this didn't actually help performance that much. I got a much
          better result by playing with different memsets written in assembly. First I wrote one
          using non-temporal stores. That was a small speed-up over memset. Then I tried the classic
          "rep stos" approach, and holy cow that version was fast. It's a ~20% speed-up on array
          allocation microbenchmarks. So, this patch adds code paths to do "rep stos" on x86_64, or
          memset, or use a loop, as appropriate, for both "contiguous" arrays (holes are zero) and
          double arrays (holes are PNaN). Note that the JIT always emits either a loop or a flat slab
          of stores (if the size is known), but those paths in the JIT won't trigger for
          NewArrayWithSize() if the size is large, since that takes us to the
          operationNewArrayWithSize() slow path, which calls into JSArray::create(). That's why the
          optimizations here are all in JSArray::create() - that's the hot place for large arrays
          that need to be filled with holes.
        
        All of this put together gives us neutral perf on JetStream,  membuster, and PLT3, a ~1%
        regression on Speedometer, and up to a 4% regression Kraken. The Kraken regression is
        because Kraken was allocating exactly 1024 element arrays at a rate of 400MB/sec. This is a
        best-case scenario for bump allocation. I think that we should fix bmalloc to make up the
        difference, but take the hit for now because it's a crazy corner case. By comparison, the
        alternative approach of using a copy barrier would have cost us 1-2%. That's the real
        apples-to-apples comparison if your premise is that we should have a concurrent GC. After we
        finish removing copied space, we will be barrier-ready for concurrent GC: we already have a
        marking barrier and we simply won't need a copying barrier. This change gets us there for
        the purposes of our benchmarks, since the remaining clients of copied space are not very
        important. On the other hand, if we keep copying, then getting barrier-ready would mean
        adding back the copy barrier, which costs more perf.
        
        We might get bigger speed-ups once we remove CopiedSpace altogether. That requires moving
        typed arrays and a few other weird things over to Aux MarkedSpace.
        
        This also includes some header sanitization. The introduction of AuxiliaryBarrier, HeapCell,
        and CellContainer meant that I had to include those files from everywhere. Fortunately,
        just including JSCInlines.h (instead of manually including the files that includes) is
        usually enough. So, I made most of JSC's cpp files include JSCInlines.h, which is something
        that we were already basically doing. In places where JSCInlines.h would be too much, I just
        included HeapInlines.h. This got weird, because we previously included HeapInlines.h from
        JSObject.h. That's bad because it led to some circular dependencies, so I fixed it - but that
        meant having to manually include HeapInlines.h from the places that previously got it
        implicitly via JSObject.h. But that led to more problems for some reason: I started getting
        build errors because non-JSC files were having trouble including Opcode.h. That's just silly,
        since Opcode.h is meant to be an internal JSC header. So, I made it an internal header and
        made it impossible to include it from outside JSC. This was a lot of work, but it was
        necessary to get the patch to build on all ports. It's also a net win. There were many places
        in WebCore that were transitively including a *ton* of JSC headers just because of the
        JSObject.h->HeapInlines.h edge and a bunch of dependency edges that arose from some public
        (for WebCore) JSC headers needing Interpreter.h or Opcode.h for bad reasons.

        * API/JSManagedValue.mm:
        (-[JSManagedValue initWithValue:]):
        * API/JSTypedArray.cpp:
        * API/ObjCCallbackFunction.mm:
        * API/tests/testapi.mm:
        (testObjectiveCAPI):
        (testWeakValue): Deleted.
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Scripts/builtins/builtins_generate_combined_implementation.py:
        (BuiltinsCombinedImplementationGenerator.generate_secondary_header_includes):
        * Scripts/builtins/builtins_generate_internals_wrapper_implementation.py:
        (BuiltinsInternalsWrapperImplementationGenerator.generate_secondary_header_includes):
        * Scripts/builtins/builtins_generate_separate_implementation.py:
        (BuiltinsSeparateImplementationGenerator.generate_secondary_header_includes):
        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::JumpList::link):
        (JSC::AbstractMacroAssembler::JumpList::linkTo):
        * assembler/MacroAssembler.h:
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::add32):
        * assembler/MacroAssemblerCodeRef.cpp: Added.
        (JSC::MacroAssemblerCodePtr::createLLIntCodePtr):
        (JSC::MacroAssemblerCodePtr::dumpWithName):
        (JSC::MacroAssemblerCodePtr::dump):
        (JSC::MacroAssemblerCodeRef::createLLIntCodeRef):
        (JSC::MacroAssemblerCodeRef::dump):
        * assembler/MacroAssemblerCodeRef.h:
        (JSC::MacroAssemblerCodePtr::createLLIntCodePtr): Deleted.
        (JSC::MacroAssemblerCodePtr::dumpWithName): Deleted.
        (JSC::MacroAssemblerCodePtr::dump): Deleted.
        (JSC::MacroAssemblerCodeRef::createLLIntCodeRef): Deleted.
        (JSC::MacroAssemblerCodeRef::dump): Deleted.
        * b3/B3BasicBlock.cpp:
        (JSC::B3::BasicBlock::appendBoolConstant):
        * b3/B3BasicBlock.h:
        * b3/B3DuplicateTails.cpp:
        * b3/B3StackmapGenerationParams.h:
        * b3/testb3.cpp:
        (JSC::B3::testPatchpointTerminalReturnValue):
        (JSC::B3::run):
        * bindings/ScriptValue.cpp:
        * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
        * bytecode/BytecodeBasicBlock.cpp:
        * bytecode/BytecodeLivenessAnalysis.cpp:
        * bytecode/BytecodeUseDef.h:
        * bytecode/CallLinkInfo.cpp:
        (JSC::CallLinkInfo::callTypeFor):
        * bytecode/CallLinkInfo.h:
        (JSC::CallLinkInfo::callTypeFor): Deleted.
        * bytecode/CallLinkStatus.cpp:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::clearLLIntGetByIdCache):
        (JSC::CodeBlock::predictedMachineCodeSize):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::jitCodeMap): Deleted.
        (JSC::clearLLIntGetByIdCache): Deleted.
        * bytecode/ExecutionCounter.h:
        * bytecode/Instruction.h:
        * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
        * bytecode/ObjectAllocationProfile.h:
        (JSC::ObjectAllocationProfile::isNull):
        (JSC::ObjectAllocationProfile::initialize):
        * bytecode/Opcode.h:
        (JSC::padOpcodeName):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generateImpl):
        (JSC::PolymorphicAccess::regenerate):
        * bytecode/PolymorphicAccess.h:
        * bytecode/PreciseJumpTargets.cpp:
        * bytecode/StructureStubInfo.cpp:
        * bytecode/StructureStubInfo.h:
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::vm): Deleted.
        * bytecode/UnlinkedCodeBlock.h:
        * bytecode/UnlinkedInstructionStream.cpp:
        * bytecode/UnlinkedInstructionStream.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
        (JSC::DFG::SpeculativeJIT::compileMakeRope):
        (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
        (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::emitAllocateJSCell):
        (JSC::DFG::SpeculativeJIT::emitAllocateJSObject):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLCompile.cpp:
        * ftl/FTLJITFinalizer.cpp:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateDirectArguments):
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateRest):
        (JSC::FTL::DFG::LowerDFGToB3::allocateArrayWithSize):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize):
        (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
        (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
        (JSC::FTL::DFG::LowerDFGToB3::initializeArrayElements):
        (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorageWithSizeImpl):
        (JSC::FTL::DFG::LowerDFGToB3::allocateHeapCell):
        (JSC::FTL::DFG::LowerDFGToB3::allocateCell):
        (JSC::FTL::DFG::LowerDFGToB3::allocateObject):
        (JSC::FTL::DFG::LowerDFGToB3::allocatorForSize):
        (JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedObject):
        (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
        (JSC::FTL::DFG::LowerDFGToB3::compileAllocateArrayWithSize): Deleted.
        * ftl/FTLOutput.cpp:
        (JSC::FTL::Output::constBool):
        (JSC::FTL::Output::add):
        (JSC::FTL::Output::shl):
        (JSC::FTL::Output::aShr):
        (JSC::FTL::Output::lShr):
        (JSC::FTL::Output::zeroExt):
        (JSC::FTL::Output::equal):
        (JSC::FTL::Output::notEqual):
        (JSC::FTL::Output::above):
        (JSC::FTL::Output::aboveOrEqual):
        (JSC::FTL::Output::below):
        (JSC::FTL::Output::belowOrEqual):
        (JSC::FTL::Output::greaterThan):
        (JSC::FTL::Output::greaterThanOrEqual):
        (JSC::FTL::Output::lessThan):
        (JSC::FTL::Output::lessThanOrEqual):
        (JSC::FTL::Output::select):
        (JSC::FTL::Output::appendSuccessor):
        (JSC::FTL::Output::addIncomingToPhi):
        * ftl/FTLOutput.h:
        * ftl/FTLValueFromBlock.h:
        (JSC::FTL::ValueFromBlock::operator bool):
        (JSC::FTL::ValueFromBlock::ValueFromBlock): Deleted.
        * ftl/FTLWeightedTarget.h:
        (JSC::FTL::WeightedTarget::frequentedBlock):
        * heap/CellContainer.h: Added.
        (JSC::CellContainer::CellContainer):
        (JSC::CellContainer::operator bool):
        (JSC::CellContainer::isMarkedBlock):
        (JSC::CellContainer::isLargeAllocation):
        (JSC::CellContainer::markedBlock):
        (JSC::CellContainer::largeAllocation):
        * heap/CellContainerInlines.h: Added.
        (JSC::CellContainer::isMarked):
        (JSC::CellContainer::isMarkedOrNewlyAllocated):
        (JSC::CellContainer::noteMarked):
        (JSC::CellContainer::cellSize):
        (JSC::CellContainer::weakSet):
        (JSC::CellContainer::flipIfNecessary):
        * heap/ConservativeRoots.cpp:
        (JSC::ConservativeRoots::ConservativeRoots):
        (JSC::ConservativeRoots::~ConservativeRoots):
        (JSC::ConservativeRoots::grow):
        (JSC::ConservativeRoots::genericAddPointer):
        (JSC::ConservativeRoots::genericAddSpan):
        * heap/ConservativeRoots.h:
        (JSC::ConservativeRoots::roots):
        * heap/CopyToken.h:
        * heap/FreeList.cpp: Added.
        (JSC::FreeList::dump):
        * heap/FreeList.h: Added.
        (JSC::FreeList::FreeList):
        (JSC::FreeList::list):
        (JSC::FreeList::bump):
        (JSC::FreeList::operator==):
        (JSC::FreeList::operator!=):
        (JSC::FreeList::operator bool):
        (JSC::FreeList::allocationWillFail):
        (JSC::FreeList::allocationWillSucceed):
        * heap/GCTypeMap.h: Added.
        (JSC::GCTypeMap::operator[]):
        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::lastChanceToFinalize):
        (JSC::Heap::finalizeUnconditionalFinalizers):
        (JSC::Heap::markRoots):
        (JSC::Heap::copyBackingStores):
        (JSC::Heap::gatherStackRoots):
        (JSC::Heap::gatherJSStackRoots):
        (JSC::Heap::gatherScratchBufferRoots):
        (JSC::Heap::clearLivenessData):
        (JSC::Heap::visitSmallStrings):
        (JSC::Heap::visitConservativeRoots):
        (JSC::Heap::removeDeadCompilerWorklistEntries):
        (JSC::Heap::gatherExtraHeapSnapshotData):
        (JSC::Heap::removeDeadHeapSnapshotNodes):
        (JSC::Heap::visitProtectedObjects):
        (JSC::Heap::visitArgumentBuffers):
        (JSC::Heap::visitException):
        (JSC::Heap::visitStrongHandles):
        (JSC::Heap::visitHandleStack):
        (JSC::Heap::visitSamplingProfiler):
        (JSC::Heap::traceCodeBlocksAndJITStubRoutines):
        (JSC::Heap::converge):
        (JSC::Heap::visitWeakHandles):
        (JSC::Heap::updateObjectCounts):
        (JSC::Heap::clearUnmarkedExecutables):
        (JSC::Heap::deleteUnmarkedCompiledCode):
        (JSC::Heap::collectAllGarbage):
        (JSC::Heap::collect):
        (JSC::Heap::collectWithoutAnySweep):
        (JSC::Heap::collectImpl):
        (JSC::Heap::suspendCompilerThreads):
        (JSC::Heap::willStartCollection):
        (JSC::Heap::flushOldStructureIDTables):
        (JSC::Heap::flushWriteBarrierBuffer):
        (JSC::Heap::stopAllocation):
        (JSC::Heap::prepareForMarking):
        (JSC::Heap::reapWeakHandles):
        (JSC::Heap::pruneStaleEntriesFromWeakGCMaps):
        (JSC::Heap::sweepArrayBuffers):
        (JSC::MarkedBlockSnapshotFunctor::MarkedBlockSnapshotFunctor):
        (JSC::MarkedBlockSnapshotFunctor::operator()):
        (JSC::Heap::snapshotMarkedSpace):
        (JSC::Heap::deleteSourceProviderCaches):
        (JSC::Heap::notifyIncrementalSweeper):
        (JSC::Heap::writeBarrierCurrentlyExecutingCodeBlocks):
        (JSC::Heap::resetAllocators):
        (JSC::Heap::updateAllocationLimits):
        (JSC::Heap::didFinishCollection):
        (JSC::Heap::resumeCompilerThreads):
        (JSC::Zombify::visit):
        (JSC::Heap::forEachCodeBlockImpl):
        * heap/Heap.h:
        (JSC::Heap::allocatorForObjectWithoutDestructor):
        (JSC::Heap::allocatorForObjectWithDestructor):
        (JSC::Heap::allocatorForAuxiliaryData):
        (JSC::Heap::jitStubRoutines):
        (JSC::Heap::codeBlockSet):
        (JSC::Heap::storageAllocator): Deleted.
        * heap/HeapCell.h:
        (JSC::HeapCell::isZapped): Deleted.
        * heap/HeapCellInlines.h: Added.
        (JSC::HeapCell::isLargeAllocation):
        (JSC::HeapCell::cellContainer):
        (JSC::HeapCell::markedBlock):
        (JSC::HeapCell::largeAllocation):
        (JSC::HeapCell::heap):
        (JSC::HeapCell::vm):
        (JSC::HeapCell::cellSize):
        (JSC::HeapCell::allocatorAttributes):
        (JSC::HeapCell::destructionMode):
        (JSC::HeapCell::cellKind):
        * heap/HeapInlines.h:
        (JSC::Heap::heap):
        (JSC::Heap::isLive):
        (JSC::Heap::isMarked):
        (JSC::Heap::testAndSetMarked):
        (JSC::Heap::setMarked):
        (JSC::Heap::cellSize):
        (JSC::Heap::forEachCodeBlock):
        (JSC::Heap::allocateObjectOfType):
        (JSC::Heap::subspaceForObjectOfType):
        (JSC::Heap::allocatorForObjectOfType):
        (JSC::Heap::allocateAuxiliary):
        (JSC::Heap::tryAllocateAuxiliary):
        (JSC::Heap::tryReallocateAuxiliary):
        (JSC::Heap::isPointerGCObject): Deleted.
        (JSC::Heap::isValueGCObject): Deleted.
        * heap/HeapOperation.cpp: Added.
        (WTF::printInternal):
        * heap/HeapOperation.h:
        * heap/HeapUtil.h: Added.
        (JSC::HeapUtil::findGCObjectPointersForMarking):
        (JSC::HeapUtil::isPointerGCObjectJSCell):
        (JSC::HeapUtil::isValueGCObject):
        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::sweepNextBlock):
        * heap/IncrementalSweeper.h:
        * heap/LargeAllocation.cpp: Added.
        (JSC::LargeAllocation::tryCreate):
        (JSC::LargeAllocation::LargeAllocation):
        (JSC::LargeAllocation::lastChanceToFinalize):
        (JSC::LargeAllocation::shrink):
        (JSC::LargeAllocation::visitWeakSet):
        (JSC::LargeAllocation::reapWeakSet):
        (JSC::LargeAllocation::flip):
        (JSC::LargeAllocation::isEmpty):
        (JSC::LargeAllocation::sweep):
        (JSC::LargeAllocation::destroy):
        (JSC::LargeAllocation::dump):
        * heap/LargeAllocation.h: Added.
        (JSC::LargeAllocation::fromCell):
        (JSC::LargeAllocation::cell):
        (JSC::LargeAllocation::isLargeAllocation):
        (JSC::LargeAllocation::heap):
        (JSC::LargeAllocation::vm):
        (JSC::LargeAllocation::weakSet):
        (JSC::LargeAllocation::clearNewlyAllocated):
        (JSC::LargeAllocation::isNewlyAllocated):
        (JSC::LargeAllocation::isMarked):
        (JSC::LargeAllocation::isMarkedOrNewlyAllocated):
        (JSC::LargeAllocation::isLive):
        (JSC::LargeAllocation::hasValidCell):
        (JSC::LargeAllocation::cellSize):
        (JSC::LargeAllocation::aboveLowerBound):
        (JSC::LargeAllocation::belowUpperBound):
        (JSC::LargeAllocation::contains):
        (JSC::LargeAllocation::attributes):
        (JSC::LargeAllocation::flipIfNecessary):
        (JSC::LargeAllocation::flipIfNecessaryConcurrently):
        (JSC::LargeAllocation::testAndSetMarked):
        (JSC::LargeAllocation::setMarked):
        (JSC::LargeAllocation::clearMarked):
        (JSC::LargeAllocation::noteMarked):
        (JSC::LargeAllocation::headerSize):
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::MarkedAllocator):
        (JSC::MarkedAllocator::isPagedOut):
        (JSC::MarkedAllocator::retire):
        (JSC::MarkedAllocator::filterNextBlock):
        (JSC::MarkedAllocator::setNextBlockToSweep):
        (JSC::MarkedAllocator::tryAllocateWithoutCollectingImpl):
        (JSC::MarkedAllocator::tryAllocateWithoutCollecting):
        (JSC::MarkedAllocator::allocateSlowCase):
        (JSC::MarkedAllocator::tryAllocateSlowCase):
        (JSC::MarkedAllocator::allocateSlowCaseImpl):
        (JSC::blockHeaderSize):
        (JSC::MarkedAllocator::blockSizeForBytes):
        (JSC::MarkedAllocator::tryAllocateBlock):
        (JSC::MarkedAllocator::addBlock):
        (JSC::MarkedAllocator::removeBlock):
        (JSC::MarkedAllocator::stopAllocating):
        (JSC::MarkedAllocator::reset):
        (JSC::MarkedAllocator::lastChanceToFinalize):
        (JSC::MarkedAllocator::setFreeList):
        (JSC::isListPagedOut): Deleted.
        (JSC::MarkedAllocator::tryAllocateHelper): Deleted.
        (JSC::MarkedAllocator::tryPopFreeList): Deleted.
        (JSC::MarkedAllocator::tryAllocate): Deleted.
        (JSC::MarkedAllocator::allocateBlock): Deleted.
        * heap/MarkedAllocator.h:
        (JSC::MarkedAllocator::takeLastActiveBlock):
        (JSC::MarkedAllocator::offsetOfFreeList):
        (JSC::MarkedAllocator::offsetOfCellSize):
        (JSC::MarkedAllocator::tryAllocate):
        (JSC::MarkedAllocator::allocate):
        (JSC::MarkedAllocator::forEachBlock):
        (JSC::MarkedAllocator::offsetOfFreeListHead): Deleted.
        (JSC::MarkedAllocator::MarkedAllocator): Deleted.
        (JSC::MarkedAllocator::init): Deleted.
        (JSC::MarkedAllocator::stopAllocating): Deleted.
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::tryCreate):
        (JSC::MarkedBlock::Handle::Handle):
        (JSC::MarkedBlock::Handle::~Handle):
        (JSC::MarkedBlock::MarkedBlock):
        (JSC::MarkedBlock::Handle::specializedSweep):
        (JSC::MarkedBlock::Handle::sweep):
        (JSC::MarkedBlock::Handle::sweepHelperSelectScribbleMode):
        (JSC::MarkedBlock::Handle::sweepHelperSelectStateAndSweepMode):
        (JSC::MarkedBlock::Handle::unsweepWithNoNewlyAllocated):
        (JSC::SetNewlyAllocatedFunctor::SetNewlyAllocatedFunctor):
        (JSC::SetNewlyAllocatedFunctor::operator()):
        (JSC::MarkedBlock::Handle::stopAllocating):
        (JSC::MarkedBlock::Handle::lastChanceToFinalize):
        (JSC::MarkedBlock::Handle::resumeAllocating):
        (JSC::MarkedBlock::Handle::zap):
        (JSC::MarkedBlock::Handle::forEachFreeCell):
        (JSC::MarkedBlock::flipIfNecessary):
        (JSC::MarkedBlock::Handle::flipIfNecessary):
        (JSC::MarkedBlock::flipIfNecessarySlow):
        (JSC::MarkedBlock::flipIfNecessaryConcurrentlySlow):
        (JSC::MarkedBlock::clearMarks):
        (JSC::MarkedBlock::assertFlipped):
        (JSC::MarkedBlock::needsFlip):
        (JSC::MarkedBlock::Handle::needsFlip):
        (JSC::MarkedBlock::Handle::willRemoveBlock):
        (JSC::MarkedBlock::Handle::didConsumeFreeList):
        (JSC::MarkedBlock::markCount):
        (JSC::MarkedBlock::Handle::isEmpty):
        (JSC::MarkedBlock::clearHasAnyMarked):
        (JSC::MarkedBlock::noteMarkedSlow):
        (WTF::printInternal):
        (JSC::MarkedBlock::create): Deleted.
        (JSC::MarkedBlock::destroy): Deleted.
        (JSC::MarkedBlock::callDestructor): Deleted.
        (JSC::MarkedBlock::specializedSweep): Deleted.
        (JSC::MarkedBlock::sweep): Deleted.
        (JSC::MarkedBlock::sweepHelper): Deleted.
        (JSC::MarkedBlock::stopAllocating): Deleted.
        (JSC::MarkedBlock::clearMarksWithCollectionType): Deleted.
        (JSC::MarkedBlock::lastChanceToFinalize): Deleted.
        (JSC::MarkedBlock::resumeAllocating): Deleted.
        (JSC::MarkedBlock::didRetireBlock): Deleted.
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::VoidFunctor::returnValue):
        (JSC::MarkedBlock::CountFunctor::CountFunctor):
        (JSC::MarkedBlock::CountFunctor::count):
        (JSC::MarkedBlock::CountFunctor::returnValue):
        (JSC::MarkedBlock::Handle::hasAnyNewlyAllocated):
        (JSC::MarkedBlock::Handle::isOnBlocksToSweep):
        (JSC::MarkedBlock::Handle::setIsOnBlocksToSweep):
        (JSC::MarkedBlock::Handle::state):
        (JSC::MarkedBlock::needsDestruction):
        (JSC::MarkedBlock::handle):
        (JSC::MarkedBlock::Handle::block):
        (JSC::MarkedBlock::firstAtom):
        (JSC::MarkedBlock::atoms):
        (JSC::MarkedBlock::isAtomAligned):
        (JSC::MarkedBlock::Handle::cellAlign):
        (JSC::MarkedBlock::blockFor):
        (JSC::MarkedBlock::Handle::allocator):
        (JSC::MarkedBlock::Handle::heap):
        (JSC::MarkedBlock::Handle::vm):
        (JSC::MarkedBlock::vm):
        (JSC::MarkedBlock::Handle::weakSet):
        (JSC::MarkedBlock::weakSet):
        (JSC::MarkedBlock::Handle::shrink):
        (JSC::MarkedBlock::Handle::visitWeakSet):
        (JSC::MarkedBlock::Handle::reapWeakSet):
        (JSC::MarkedBlock::Handle::cellSize):
        (JSC::MarkedBlock::cellSize):
        (JSC::MarkedBlock::Handle::attributes):
        (JSC::MarkedBlock::attributes):
        (JSC::MarkedBlock::Handle::needsDestruction):
        (JSC::MarkedBlock::Handle::destruction):
        (JSC::MarkedBlock::Handle::cellKind):
        (JSC::MarkedBlock::Handle::markCount):
        (JSC::MarkedBlock::Handle::size):
        (JSC::MarkedBlock::atomNumber):
        (JSC::MarkedBlock::flipIfNecessary):
        (JSC::MarkedBlock::flipIfNecessaryConcurrently):
        (JSC::MarkedBlock::Handle::flipIfNecessary):
        (JSC::MarkedBlock::Handle::flipIfNecessaryConcurrently):
        (JSC::MarkedBlock::Handle::flipForEdenCollection):
        (JSC::MarkedBlock::assertFlipped):
        (JSC::MarkedBlock::Handle::assertFlipped):
        (JSC::MarkedBlock::isMarked):
        (JSC::MarkedBlock::testAndSetMarked):
        (JSC::MarkedBlock::Handle::isNewlyAllocated):
        (JSC::MarkedBlock::Handle::setNewlyAllocated):
        (JSC::MarkedBlock::Handle::clearNewlyAllocated):
        (JSC::MarkedBlock::Handle::isMarkedOrNewlyAllocated):
        (JSC::MarkedBlock::isMarkedOrNewlyAllocated):
        (JSC::MarkedBlock::Handle::isLive):
        (JSC::MarkedBlock::isAtom):
        (JSC::MarkedBlock::Handle::isLiveCell):
        (JSC::MarkedBlock::Handle::forEachCell):
        (JSC::MarkedBlock::Handle::forEachLiveCell):
        (JSC::MarkedBlock::Handle::forEachDeadCell):
        (JSC::MarkedBlock::Handle::needsSweeping):
        (JSC::MarkedBlock::Handle::isAllocated):
        (JSC::MarkedBlock::Handle::isMarked):
        (JSC::MarkedBlock::Handle::isFreeListed):
        (JSC::MarkedBlock::hasAnyMarked):
        (JSC::MarkedBlock::noteMarked):
        (WTF::MarkedBlockHash::hash):
        (JSC::MarkedBlock::FreeList::FreeList): Deleted.
        (JSC::MarkedBlock::allocator): Deleted.
        (JSC::MarkedBlock::heap): Deleted.
        (JSC::MarkedBlock::shrink): Deleted.
        (JSC::MarkedBlock::visitWeakSet): Deleted.
        (JSC::MarkedBlock::reapWeakSet): Deleted.
        (JSC::MarkedBlock::willRemoveBlock): Deleted.
        (JSC::MarkedBlock::didConsumeFreeList): Deleted.
        (JSC::MarkedBlock::markCount): Deleted.
        (JSC::MarkedBlock::isEmpty): Deleted.
        (JSC::MarkedBlock::destruction): Deleted.
        (JSC::MarkedBlock::cellKind): Deleted.
        (JSC::MarkedBlock::size): Deleted.
        (JSC::MarkedBlock::capacity): Deleted.
        (JSC::MarkedBlock::setMarked): Deleted.
        (JSC::MarkedBlock::clearMarked): Deleted.
        (JSC::MarkedBlock::isNewlyAllocated): Deleted.
        (JSC::MarkedBlock::setNewlyAllocated): Deleted.
        (JSC::MarkedBlock::clearNewlyAllocated): Deleted.
        (JSC::MarkedBlock::isLive): Deleted.
        (JSC::MarkedBlock::isLiveCell): Deleted.
        (JSC::MarkedBlock::forEachCell): Deleted.
        (JSC::MarkedBlock::forEachLiveCell): Deleted.
        (JSC::MarkedBlock::forEachDeadCell): Deleted.
        (JSC::MarkedBlock::needsSweeping): Deleted.
        (JSC::MarkedBlock::isAllocated): Deleted.
        (JSC::MarkedBlock::isMarkedOrRetired): Deleted.
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::initializeSizeClassForStepSize):
        (JSC::MarkedSpace::MarkedSpace):
        (JSC::MarkedSpace::~MarkedSpace):
        (JSC::MarkedSpace::lastChanceToFinalize):
        (JSC::MarkedSpace::allocate):
        (JSC::MarkedSpace::tryAllocate):
        (JSC::MarkedSpace::allocateLarge):
        (JSC::MarkedSpace::tryAllocateLarge):
        (JSC::MarkedSpace::sweep):
        (JSC::MarkedSpace::sweepLargeAllocations):
        (JSC::MarkedSpace::zombifySweep):
        (JSC::MarkedSpace::resetAllocators):
        (JSC::MarkedSpace::visitWeakSets):
        (JSC::MarkedSpace::reapWeakSets):
        (JSC::MarkedSpace::stopAllocating):
        (JSC::MarkedSpace::prepareForMarking):
        (JSC::MarkedSpace::resumeAllocating):
        (JSC::MarkedSpace::isPagedOut):
        (JSC::MarkedSpace::freeBlock):
        (JSC::MarkedSpace::freeOrShrinkBlock):
        (JSC::MarkedSpace::shrink):
        (JSC::MarkedSpace::clearNewlyAllocated):
        (JSC::VerifyMarked::operator()):
        (JSC::MarkedSpace::flip):
        (JSC::MarkedSpace::objectCount):
        (JSC::MarkedSpace::size):
        (JSC::MarkedSpace::capacity):
        (JSC::MarkedSpace::addActiveWeakSet):
        (JSC::MarkedSpace::didAddBlock):
        (JSC::MarkedSpace::didAllocateInBlock):
        (JSC::MarkedSpace::forEachAllocator): Deleted.
        (JSC::VerifyMarkedOrRetired::operator()): Deleted.
        (JSC::MarkedSpace::clearMarks): Deleted.
        * heap/MarkedSpace.h:
        (JSC::MarkedSpace::sizeClassToIndex):
        (JSC::MarkedSpace::indexToSizeClass):
        (JSC::MarkedSpace::version):
        (JSC::MarkedSpace::blocksWithNewObjects):
        (JSC::MarkedSpace::largeAllocations):
        (JSC::MarkedSpace::largeAllocationsNurseryOffset):
        (JSC::MarkedSpace::largeAllocationsOffsetForThisCollection):
        (JSC::MarkedSpace::largeAllocationsForThisCollectionBegin):
        (JSC::MarkedSpace::largeAllocationsForThisCollectionEnd):
        (JSC::MarkedSpace::largeAllocationsForThisCollectionSize):
        (JSC::MarkedSpace::forEachLiveCell):
        (JSC::MarkedSpace::forEachDeadCell):
        (JSC::MarkedSpace::allocatorFor):
        (JSC::MarkedSpace::destructorAllocatorFor):
        (JSC::MarkedSpace::auxiliaryAllocatorFor):
        (JSC::MarkedSpace::allocateWithoutDestructor):
        (JSC::MarkedSpace::allocateWithDestructor):
        (JSC::MarkedSpace::allocateAuxiliary):
        (JSC::MarkedSpace::tryAllocateAuxiliary):
        (JSC::MarkedSpace::forEachBlock):
        (JSC::MarkedSpace::forEachAllocator):
        (JSC::MarkedSpace::optimalSizeFor):
        (JSC::MarkedSpace::didAddBlock): Deleted.
        (JSC::MarkedSpace::didAllocateInBlock): Deleted.
        (JSC::MarkedSpace::objectCount): Deleted.
        (JSC::MarkedSpace::size): Deleted.
        (JSC::MarkedSpace::capacity): Deleted.
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::SlotVisitor):
        (JSC::SlotVisitor::didStartMarking):
        (JSC::SlotVisitor::reset):
        (JSC::SlotVisitor::append):
        (JSC::SlotVisitor::appendJSCellOrAuxiliary):
        (JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
        (JSC::SlotVisitor::appendToMarkStack):
        (JSC::SlotVisitor::markAuxiliary):
        (JSC::SlotVisitor::noteLiveAuxiliaryCell):
        (JSC::SlotVisitor::visitChildren):
        * heap/SlotVisitor.h:
        * heap/WeakBlock.cpp:
        (JSC::WeakBlock::create):
        (JSC::WeakBlock::WeakBlock):
        (JSC::WeakBlock::visit):
        (JSC::WeakBlock::reap):
        * heap/WeakBlock.h:
        (JSC::WeakBlock::disconnectContainer):
        (JSC::WeakBlock::disconnectMarkedBlock): Deleted.
        * heap/WeakSet.cpp:
        (JSC::WeakSet::~WeakSet):
        (JSC::WeakSet::sweep):
        (JSC::WeakSet::shrink):
        (JSC::WeakSet::addAllocator):
        * heap/WeakSet.h:
        (JSC::WeakSet::container):
        (JSC::WeakSet::setContainer):
        (JSC::WeakSet::WeakSet):
        (JSC::WeakSet::visit):
        (JSC::WeakSet::shrink): Deleted.
        * heap/WeakSetInlines.h:
        (JSC::WeakSet::allocate):
        * inspector/InjectedScriptManager.cpp:
        * inspector/JSGlobalObjectInspectorController.cpp:
        * inspector/JSJavaScriptCallFrame.cpp:
        * inspector/ScriptDebugServer.cpp:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        * interpreter/CachedCall.h:
        (JSC::CachedCall::CachedCall):
        * interpreter/Interpreter.cpp:
        (JSC::loadVarargs):
        (JSC::StackFrame::sourceID): Deleted.
        (JSC::StackFrame::sourceURL): Deleted.
        (JSC::StackFrame::functionName): Deleted.
        (JSC::StackFrame::computeLineAndColumn): Deleted.
        (JSC::StackFrame::toString): Deleted.
        * interpreter/Interpreter.h:
        (JSC::StackFrame::isNative): Deleted.
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator):
        (JSC::AssemblyHelpers::emitAllocate):
        (JSC::AssemblyHelpers::emitAllocateJSCell):
        (JSC::AssemblyHelpers::emitAllocateJSObject):
        (JSC::AssemblyHelpers::emitAllocateJSObjectWithKnownSize):
        (JSC::AssemblyHelpers::emitAllocateVariableSized):
        * jit/GCAwareJITStubRoutine.cpp:
        (JSC::GCAwareJITStubRoutine::GCAwareJITStubRoutine):
        * jit/JIT.cpp:
        (JSC::JIT::compileCTINativeCall):
        (JSC::JIT::link):
        * jit/JIT.h:
        (JSC::JIT::compileCTINativeCall): Deleted.
        * jit/JITExceptions.cpp:
        (JSC::genericUnwind):
        * jit/JITExceptions.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_new_object):
        (JSC::JIT::emitSlow_op_new_object):
        (JSC::JIT::emit_op_create_this):
        (JSC::JIT::emitSlow_op_create_this):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_new_object):
        (JSC::JIT::emitSlow_op_new_object):
        (JSC::JIT::emit_op_create_this):
        (JSC::JIT::emitSlow_op_create_this):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitWriteBarrier):
        * jit/JITThunks.cpp:
        * jit/JITThunks.h:
        * jsc.cpp:
        (functionDescribeArray):
        (main):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LLIntExceptions.cpp:
        * llint/LLIntThunks.cpp:
        * llint/LLIntThunks.h:
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter.cpp:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * parser/ModuleAnalyzer.cpp:
        * parser/NodeConstructors.h:
        * parser/Nodes.h:
        * profiler/ProfilerBytecode.cpp:
        * profiler/ProfilerBytecode.h:
        * profiler/ProfilerBytecodeSequence.cpp:
        * runtime/ArrayConventions.h:
        (JSC::indexingHeaderForArrayStorage):
        (JSC::baseIndexingHeaderForArrayStorage):
        (JSC::indexingHeaderForArray): Deleted.
        (JSC::baseIndexingHeaderForArray): Deleted.
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncSplice):
        (JSC::concatAppendOne):
        (JSC::arrayProtoPrivateFuncConcatMemcpy):
        * runtime/ArrayStorage.h:
        (JSC::ArrayStorage::vectorLength):
        (JSC::ArrayStorage::totalSizeFor):
        (JSC::ArrayStorage::totalSize):
        (JSC::ArrayStorage::availableVectorLength):
        (JSC::ArrayStorage::optimalVectorLength):
        (JSC::ArrayStorage::sizeFor): Deleted.
        * runtime/AuxiliaryBarrier.h: Added.
        (JSC::AuxiliaryBarrier::AuxiliaryBarrier):
        (JSC::AuxiliaryBarrier::clear):
        (JSC::AuxiliaryBarrier::get):
        (JSC::AuxiliaryBarrier::slot):
        (JSC::AuxiliaryBarrier::operator bool):
        (JSC::AuxiliaryBarrier::setWithoutBarrier):
        * runtime/AuxiliaryBarrierInlines.h: Added.
        (JSC::AuxiliaryBarrier<T>::AuxiliaryBarrier):
        (JSC::AuxiliaryBarrier<T>::set):
        * runtime/Butterfly.h:
        * runtime/ButterflyInlines.h:
        (JSC::Butterfly::availableContiguousVectorLength):
        (JSC::Butterfly::optimalContiguousVectorLength):
        (JSC::Butterfly::createUninitialized):
        (JSC::Butterfly::growArrayRight):
        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::createEmpty):
        * runtime/CommonSlowPathsExceptions.cpp:
        * runtime/CommonSlowPathsExceptions.h:
        * runtime/DataView.cpp:
        * runtime/DirectArguments.h:
        * runtime/ECMAScriptSpecInternalFunctions.cpp:
        * runtime/Error.cpp:
        * runtime/Error.h:
        * runtime/ErrorInstance.cpp:
        * runtime/ErrorInstance.h:
        * runtime/Exception.cpp:
        * runtime/Exception.h:
        * runtime/GeneratorFrame.cpp:
        * runtime/GeneratorPrototype.cpp:
        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::InternalFunction):
        * runtime/IntlCollator.cpp:
        * runtime/IntlCollatorConstructor.cpp:
        * runtime/IntlCollatorPrototype.cpp:
        * runtime/IntlDateTimeFormat.cpp:
        * runtime/IntlDateTimeFormatConstructor.cpp:
        * runtime/IntlDateTimeFormatPrototype.cpp:
        * runtime/IntlNumberFormat.cpp:
        * runtime/IntlNumberFormatConstructor.cpp:
        * runtime/IntlNumberFormatPrototype.cpp:
        * runtime/IntlObject.cpp:
        * runtime/IteratorPrototype.cpp:
        * runtime/JSArray.cpp:
        (JSC::JSArray::tryCreateUninitialized):
        (JSC::JSArray::setLengthWritable):
        (JSC::JSArray::unshiftCountSlowCase):
        (JSC::JSArray::setLengthWithArrayStorage):
        (JSC::JSArray::appendMemcpy):
        (JSC::JSArray::setLength):
        (JSC::JSArray::pop):
        (JSC::JSArray::push):
        (JSC::JSArray::fastSlice):
        (JSC::JSArray::shiftCountWithArrayStorage):
        (JSC::JSArray::shiftCountWithAnyIndexingType):
        (JSC::JSArray::unshiftCountWithArrayStorage):
        (JSC::JSArray::fillArgList):
        (JSC::JSArray::copyToArguments):
        * runtime/JSArray.h:
        (JSC::createContiguousArrayButterfly):
        (JSC::createArrayButterfly):
        (JSC::JSArray::create):
        (JSC::JSArray::tryCreateUninitialized): Deleted.
        * runtime/JSArrayBufferView.h:
        * runtime/JSCInlines.h:
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::dumpInContextAssumingStructure):
        * runtime/JSCallee.cpp:
        (JSC::JSCallee::JSCallee):
        * runtime/JSCell.cpp:
        (JSC::JSCell::estimatedSize):
        * runtime/JSCell.h:
        (JSC::JSCell::cellStateOffset): Deleted.
        * runtime/JSCellInlines.h:
        (JSC::ExecState::vm):
        (JSC::JSCell::classInfo):
        (JSC::JSCell::callDestructor):
        (JSC::JSCell::vm): Deleted.
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::create):
        (JSC::JSFunction::allocateAndInitializeRareData):
        (JSC::JSFunction::initializeRareData):
        (JSC::JSFunction::getOwnPropertySlot):
        (JSC::JSFunction::put):
        (JSC::JSFunction::deleteProperty):
        (JSC::JSFunction::defineOwnProperty):
        (JSC::JSFunction::setFunctionName):
        (JSC::JSFunction::reifyLength):
        (JSC::JSFunction::reifyName):
        (JSC::JSFunction::reifyLazyPropertyIfNeeded):
        (JSC::JSFunction::reifyBoundNameIfNeeded):
        * runtime/JSFunction.h:
        * runtime/JSFunctionInlines.h:
        (JSC::JSFunction::createWithInvalidatedReallocationWatchpoint):
        (JSC::JSFunction::JSFunction):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::slowDownAndWasteMemory):
        * runtime/JSInternalPromise.cpp:
        * runtime/JSInternalPromiseConstructor.cpp:
        * runtime/JSInternalPromiseDeferred.cpp:
        * runtime/JSInternalPromisePrototype.cpp:
        * runtime/JSJob.cpp:
        * runtime/JSMapIterator.cpp:
        * runtime/JSModuleNamespaceObject.cpp:
        * runtime/JSModuleRecord.cpp:
        * runtime/JSObject.cpp:
        (JSC::JSObject::visitButterfly):
        (JSC::JSObject::notifyPresenceOfIndexedAccessors):
        (JSC::JSObject::createInitialIndexedStorage):
        (JSC::JSObject::createInitialUndecided):
        (JSC::JSObject::createInitialInt32):
        (JSC::JSObject::createInitialDouble):
        (JSC::JSObject::createInitialContiguous):
        (JSC::JSObject::createArrayStorage):
        (JSC::JSObject::createInitialArrayStorage):
        (JSC::JSObject::convertUndecidedToInt32):
        (JSC::JSObject::convertUndecidedToContiguous):
        (JSC::JSObject::convertUndecidedToArrayStorage):
        (JSC::JSObject::convertInt32ToDouble):
        (JSC::JSObject::convertInt32ToArrayStorage):
        (JSC::JSObject::convertDoubleToArrayStorage):
        (JSC::JSObject::convertContiguousToArrayStorage):
        (JSC::JSObject::putByIndexBeyondVectorLength):
        (JSC::JSObject::putDirectIndexBeyondVectorLength):
        (JSC::JSObject::getNewVectorLength):
        (JSC::JSObject::increaseVectorLength):
        (JSC::JSObject::ensureLengthSlow):
        (JSC::JSObject::growOutOfLineStorage):
        (JSC::JSObject::copyButterfly): Deleted.
        (JSC::JSObject::copyBackingStore): Deleted.
        * runtime/JSObject.h:
        (JSC::JSObject::globalObject):
        (JSC::JSObject::putDirectInternal):
        (JSC::JSObject::setStructureAndReallocateStorageIfNecessary): Deleted.
        * runtime/JSObjectInlines.h:
        * runtime/JSPromise.cpp:
        * runtime/JSPromiseConstructor.cpp:
        * runtime/JSPromiseDeferred.cpp:
        * runtime/JSPromisePrototype.cpp:
        * runtime/JSPropertyNameIterator.cpp:
        * runtime/JSScope.cpp:
        (JSC::JSScope::resolve):
        * runtime/JSScope.h:
        (JSC::JSScope::globalObject):
        (JSC::JSScope::vm): Deleted.
        * runtime/JSSetIterator.cpp:
        * runtime/JSStringIterator.cpp:
        * runtime/JSTemplateRegistryKey.cpp:
        * runtime/JSTypedArrayViewConstructor.cpp:
        * runtime/JSTypedArrayViewPrototype.cpp:
        * runtime/JSWeakMap.cpp:
        * runtime/JSWeakSet.cpp:
        * runtime/MapConstructor.cpp:
        * runtime/MapIteratorPrototype.cpp:
        * runtime/MapPrototype.cpp:
        * runtime/NativeErrorConstructor.cpp:
        * runtime/NativeStdFunctionCell.cpp:
        * runtime/Operations.h:
        (JSC::scribbleFreeCells):
        (JSC::scribble):
        * runtime/Options.h:
        * runtime/PropertyTable.cpp:
        * runtime/ProxyConstructor.cpp:
        * runtime/ProxyObject.cpp:
        * runtime/ProxyRevoke.cpp:
        * runtime/RegExp.cpp:
        (JSC::RegExp::match):
        (JSC::RegExp::matchConcurrently):
        (JSC::RegExp::matchCompareWithInterpreter):
        * runtime/RegExp.h:
        * runtime/RegExpConstructor.h:
        * runtime/RegExpInlines.h:
        (JSC::RegExp::matchInline):
        * runtime/RegExpMatchesArray.h:
        (JSC::tryCreateUninitializedRegExpMatchesArray):
        (JSC::createRegExpMatchesArray):
        * runtime/RegExpPrototype.cpp:
        (JSC::genericSplit):
        * runtime/RuntimeType.cpp:
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::processUnverifiedStackTraces):
        * runtime/SetConstructor.cpp:
        * runtime/SetIteratorPrototype.cpp:
        * runtime/SetPrototype.cpp:
        * runtime/StackFrame.cpp: Added.
        (JSC::StackFrame::sourceID):
        (JSC::StackFrame::sourceURL):
        (JSC::StackFrame::functionName):
        (JSC::StackFrame::computeLineAndColumn):
        (JSC::StackFrame::toString):
        * runtime/StackFrame.h: Added.
        (JSC::StackFrame::isNative):
        * runtime/StringConstructor.cpp:
        * runtime/StringIteratorPrototype.cpp:
        * runtime/StructureInlines.h:
        (JSC::Structure::propertyTable):
        * runtime/TemplateRegistry.cpp:
        * runtime/TestRunnerUtils.cpp:
        (JSC::finalizeStatsAtEndOfTesting):
        * runtime/TestRunnerUtils.h:
        * runtime/TypeProfilerLog.cpp:
        * runtime/TypeSet.cpp:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::ensureStackCapacityForCLoop):
        (JSC::VM::isSafeToRecurseSoftCLoop):
        * runtime/VM.h:
        * runtime/VMEntryScope.h:
        * runtime/VMInlines.h:
        (JSC::VM::ensureStackCapacityFor):
        (JSC::VM::isSafeToRecurseSoft):
        * runtime/WeakMapConstructor.cpp:
        * runtime/WeakMapData.cpp:
        * runtime/WeakMapPrototype.cpp:
        * runtime/WeakSetConstructor.cpp:
        * runtime/WeakSetPrototype.cpp:
        * testRegExp.cpp:
        (testOneRegExp):
        * tools/JSDollarVM.cpp:
        * tools/JSDollarVMPrototype.cpp:
        (JSC::JSDollarVMPrototype::isInObjectSpace):

2016-09-04  Commit Queue  <commit-queue@webkit.org>

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

        Many bots see inspector test failures, rolling out now and
        investigating later. (Requested by brrian on #webkit).

        Reverted changeset:

        "Web Inspector: unify Main.html and Test.html sources and
        generate different copies with the preprocessor"
        https://bugs.webkit.org/show_bug.cgi?id=161212
        http://trac.webkit.org/changeset/205415

2016-09-01  Brian Burg  <bburg@apple.com>

        Web Inspector: unify Main.html and Test.html sources and generate different copies with the preprocessor
        https://bugs.webkit.org/show_bug.cgi?id=161212
        <rdar://problem/28017961>

        Reviewed by Joseph Pecoraro.

        * CMakeLists.txt: Remove some unnecessary MAKE_DIRECTORY commands.

2016-09-03  Joseph Pecoraro  <pecoraro@apple.com>

        Use ASCIILiteral in some more places
        https://bugs.webkit.org/show_bug.cgi?id=161557

        Reviewed by Darin Adler.

        * runtime/TypeSet.h:
        (JSC::StructureShape::setConstructorName):

2016-09-01  Michael Saboff  <msaboff@apple.com>

        Import Chakra tests to JSC
        https://bugs.webkit.org/show_bug.cgi?id=154697

        Reviewed by Saam Barati.

        Added --dumpException option to jsc command line utility to dump uncaught exception
        text even for the last exception that matches --exception.  This is used to
        check the exception text for a text that is expected to end on an exception.
        Chakra has several tests of this form and does the same thing when such a test
        ends with an exception.  Tests that rely on this behavior have had their expected
        output updated for JSC specific text.

        * jsc.cpp:

2016-09-02  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Remove some more useless cases from FTL Capabilities
        https://bugs.webkit.org/show_bug.cgi?id=161466

        Reviewed by Geoffrey Garen.

        Some cases do not make sense:
        -In: Fixup only generate CellUse.
        -PutByIdXXX: same.
        -GetIndexedPropertyStorage: those cases are the only ones supported
         by DFG. We would have crashed in SpeculativeJIT if other modes
         were generated.

        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compilePutById):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage):
        (JSC::FTL::DFG::LowerDFGToB3::compileIn):

2016-09-02  Chris Dumez  <cdumez@apple.com>

        Unreviewed, roll out r205354 because it caused JSC test failures

        * jsc.cpp:
        * runtime/JSGlobalObject.cpp:
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::allowsAccessFrom):
        (JSC::JSGlobalObject::setDebugger): Deleted.
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::GlobalFuncProtoGetterFunctor::GlobalFuncProtoGetterFunctor):
        (JSC::GlobalFuncProtoGetterFunctor::result):
        (JSC::GlobalFuncProtoGetterFunctor::operator()):
        (JSC::globalFuncProtoGetter):
        (JSC::GlobalFuncProtoSetterFunctor::GlobalFuncProtoSetterFunctor):
        (JSC::GlobalFuncProtoSetterFunctor::allowsAccess):
        (JSC::GlobalFuncProtoSetterFunctor::operator()):
        (JSC::checkProtoSetterAccessAllowed):
        (JSC::globalFuncProtoSetter):
        * runtime/JSGlobalObjectFunctions.h:
        * runtime/JSObject.cpp:
        (JSC::JSObject::setPrototypeWithCycleCheck):
        (JSC::JSObject::allowsAccessFrom):
        * runtime/JSObject.h:
        * runtime/JSProxy.cpp:
        * runtime/JSProxy.h:
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructorGetPrototypeOfFunctor::ObjectConstructorGetPrototypeOfFunctor):
        (JSC::ObjectConstructorGetPrototypeOfFunctor::result):
        (JSC::ObjectConstructorGetPrototypeOfFunctor::operator()):
        (JSC::objectConstructorGetPrototypeOf):
        (JSC::objectConstructorSetPrototypeOf):
        * runtime/ObjectConstructor.h:
        * runtime/ReflectObject.cpp:
        (JSC::reflectObjectGetPrototypeOf):
        (JSC::reflectObjectSetPrototypeOf):

2016-09-02  Caio Lima  <ticaiolima@gmail.com>

        Register usage optimization in mathIC when LHS and RHS are constants isn't configured correctly
        https://bugs.webkit.org/show_bug.cgi?id=160802

        Reviewed by Saam Barati.

        This patch is fixing a broken mechanism of MathIC that avoids allocate
        a register to LHS or RHS if one of these operands are proven as valid
        constant for JIT*Generator. In previous implementation, even if the
        JIT*Generator was not using an operand register because it was proven as a
        constant, compileMathIC and emitICFast were allocating a register for
        it. This was broken because mathIC->isLeftOperandValidConstant and
        mathIC->isLeftOperandValidConstant were being called before its Generator be
        properly initialized. We changed this mechanism to enable Generators write
        their validConstant rules using static methods isLeftOperandValidConstant(SnippetOperand)
        and isRightOperandValidConstant(SnippetOperand).

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileMathIC):
        * jit/JITAddGenerator.h:
        (JSC::JITAddGenerator::JITAddGenerator):
        (JSC::JITAddGenerator::isLeftOperandValidConstant):
        (JSC::JITAddGenerator::isRightOperandValidConstant):
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emitMathICFast):
        * jit/JITMathIC.h:
        * jit/JITMulGenerator.h:
        (JSC::JITMulGenerator::JITMulGenerator):
        (JSC::JITMulGenerator::isLeftOperandValidConstant):
        (JSC::JITMulGenerator::isRightOperandValidConstant):
        * jit/JITSubGenerator.h:
        (JSC::JITSubGenerator::isLeftOperandValidConstant):
        (JSC::JITSubGenerator::isRightOperandValidConstant):

2016-09-02  JF Bastien  <jfbastien@apple.com>

        GetByValWithThis: fix opInfo in DFG creation
        https://bugs.webkit.org/show_bug.cgi?id=161541

        Reviewed by Saam Barati.

        super-get-by-val-with-this-monomorphic might be 1.0148x faster after this change.

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

2016-09-02  Chris Dumez  <cdumez@apple.com>

        Object.preventExtensions() should throw cross-origin
        https://bugs.webkit.org/show_bug.cgi?id=161486

        Reviewed by Geoffrey Garen.

        Update JSProxy to forward preventExtensions() calls to its target.

        * runtime/JSProxy.cpp:
        (JSC::JSProxy::preventExtensions):
        * runtime/JSProxy.h:

2016-09-02  Chris Dumez  <cdumez@apple.com>

        Align proto getter / setter behavior with other browsers
        https://bugs.webkit.org/show_bug.cgi?id=161455

        Reviewed by Mark Lam.

        Drop allowsAccessFrom from the methodTable and delegate cross-origin
        checking to the DOM bindings for [[SetPrototypeOf]] / [[GetPrototypeOf]].
        This is more consistent with other operations (e.g. [[GetOwnProperty]]).

        * jsc.cpp:
        * runtime/JSGlobalObject.cpp:
        * runtime/JSGlobalObject.h:
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncProtoGetter):
        (JSC::globalFuncProtoSetter):
        (JSC::globalFuncBuiltinLog): Deleted.
        * runtime/JSGlobalObjectFunctions.h:
        * runtime/JSObject.h:
        (JSC::JSObject::getArrayLength): Deleted.
        * runtime/JSProxy.cpp:
        (JSC::JSProxy::setPrototype):
        (JSC::JSProxy::getPrototype):
        * runtime/JSProxy.h:
        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorGetPrototypeOf):
        (JSC::objectConstructorSetPrototypeOf):
        (JSC::objectConstructorGetOwnPropertyDescriptor): Deleted.
        (JSC::objectConstructorGetOwnPropertyDescriptors): Deleted.
        * runtime/ObjectConstructor.h:
        * runtime/ReflectObject.cpp:
        (JSC::reflectObjectGetPrototypeOf):
        (JSC::reflectObjectSetPrototypeOf):

        * runtime/JSObject.cpp:
        (JSC::JSObject::setPrototypeWithCycleCheck):
        Comment out check added in r197648. This check was added to match
        the latest EcmaScript spec:
        - https://tc39.github.io/ecma262/#sec-ordinarysetprototypeof (step 8)
        This check allowed for [[Prototype]] chain cycles if the prototype
        chain includes objects that do not use the ordinary object definitions
        for [[GetPrototypeOf]] and [[SetPrototypeOf]].
        The issue is that the rest of our code base does not properly handle
        such cycles and we can end up in infinite loops. This became obvious
        because this patch updates Window / Location so that they no longer
        use the default [[GetPrototypeOf]] / [[SetPrototypeOf]]. If I do not
        comment out this check, I get an infinite loop in
        Structure::anyObjectInChainMayInterceptIndexedAccesses(), which is
        called from JSObject::setPrototypeDirect(), when running the following
        layout test:
        - html/browsers/history/the-location-interface/allow_prototype_cycle_through_location.sub.html
        I filed https://bugs.webkit.org/show_bug.cgi?id=161534 to track this
        issue.

2016-09-01  Yusuke Suzuki  <utatane.tea@gmail.com>

        Add toJS for JSC::PrivateName
        https://bugs.webkit.org/show_bug.cgi?id=161522

        Reviewed by Ryosuke Niwa.

        Add the export annotation.
        And we perform refactoring RefPtr<SymbolImpl> => Ref<SymbolImpl> for PrivateName,
        since PrivateName never holds null SymbolImpl pointer. And along with this change,
        we changed SymbolImpl* to SymbolImpl& in PrivateName::uid() callers.

        * runtime/Completion.cpp:
        (JSC::createSymbolForEntryPointModule):
        * runtime/IdentifierInlines.h:
        (JSC::Identifier::fromUid):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::setFunctionName):
        * runtime/PrivateName.h:
        (JSC::PrivateName::PrivateName):
        (JSC::PrivateName::uid): Ugly const_cast. But const annotation is meaningless for SymbolImpl.
        StringImpl should be observed as an immutable object. (Of course, its hash members etc. are mutable.
        But most of the users (One of the exceptions is the concurrent JIT compiling thread!) should not care about this.)
        (JSC::PrivateName::operator==):
        (JSC::PrivateName::operator!=):
        * runtime/PropertyName.h:
        (JSC::PropertyName::PropertyName):
        * runtime/Symbol.cpp:
        (JSC::Symbol::finishCreation):
        * runtime/Symbol.h:
        * runtime/SymbolConstructor.cpp:
        (JSC::symbolConstructorKeyFor):

2016-09-01  Dan Bernstein  <mitz@apple.com>

        Build fix.

        * Configurations/FeatureDefines.xcconfig:

2016-09-01  JF Bastien  <jfbastien@apple.com>

        jsc: fix cmake build missing symbol getPropertySlot
        https://bugs.webkit.org/show_bug.cgi?id=161521

        Reviewed by Saam Barati.

        * runtime/IntlDateTimeFormat.cpp: include JSCInlines.h
        * runtime/IntlNumberFormat.cpp: include JSCInlines.h

2016-09-01  JF Bastien  <jfbastien@apple.com>

        jsc: provide printErr()
        https://bugs.webkit.org/show_bug.cgi?id=161513

        Reviewed by Mark Lam.

        * jsc.cpp:
        (GlobalObject::finishCreation):
        (printInternal): renamed from functionPrint, add error checking
        (functionPrintStdOut): punt to printInternal
        (functionPrintStdErr): punt to printInternal
        (functionPrint): Deleted.

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

        Move some JSObject and JSArray inline functions to their respective Inlines.h files.
        https://bugs.webkit.org/show_bug.cgi?id=161499

        Reviewed by Saam Barati.

        This is just a refactoring patch to move some inline functions to their Inlines.h
        files.  This will be needed to enable https://bugs.webkit.org/show_bug.cgi?id=161498
        later.

        * bindings/ScriptValue.cpp:
        * interpreter/Interpreter.cpp:
        * runtime/IntlDateTimeFormatPrototype.cpp:
        * runtime/IntlNumberFormatPrototype.cpp:
        * runtime/JSArray.cpp:
        * runtime/JSArray.h:
        (JSC::getLength): Deleted.
        (JSC::toLength): Deleted.
        * runtime/JSArrayInlines.h:
        (JSC::JSArray::mergeIndexingTypeForCopying):
        (JSC::JSArray::canFastCopy):
        (JSC::getLength):
        (JSC::toLength):
        * runtime/JSInternalPromise.cpp:
        * runtime/JSInternalPromiseDeferred.cpp:
        * runtime/JSJob.cpp:
        * runtime/JSModuleRecord.cpp:
        * runtime/JSObject.h:
        (JSC::JSObject::getPropertySlot): Deleted.
        (JSC::JSObject::getNonIndexPropertySlot): Deleted.
        * runtime/JSObjectInlines.h:
        (JSC::JSObject::getPropertySlot):
        (JSC::JSObject::getNonIndexPropertySlot):
        * runtime/JSPromiseDeferred.cpp:
        * runtime/JSTypedArrayViewPrototype.cpp:
        * runtime/MapConstructor.cpp:
        * runtime/SamplingProfiler.cpp:
        * runtime/SetConstructor.cpp:
        * runtime/WeakMapConstructor.cpp:
        * runtime/WeakSetConstructor.cpp:

2016-09-01  JF Bastien  <jfbastien@apple.com>

        GetByIdWithThis/GetByValWithThis should have ValueProfiles so that they can predict their result types
        https://bugs.webkit.org/show_bug.cgi?id=160922

        Reviewed by Keith Miller.

        Add value profiling to GetBy{Id,Val}WithThis.

        * bytecode/BytecodeList.json:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::finishCreation):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitGetById):
        (JSC::BytecodeGenerator::emitGetByVal):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasHeapPrediction):
        * dfg/DFGPredictionPropagationPhase.cpp:
        * llint/LowLevelInterpreter.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):

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

        WASM functions should be able to use arguments
        https://bugs.webkit.org/show_bug.cgi?id=161471

        Reviewed by Benjamin Poulain.

        This patch does a couple of changes:

        1) Adds a new Calling Convention class for B3. This class is used to make it easy to specify the calling convention of a function. In particular it knows which arguments are in registers and which ones should be on the stack. For now, nothing uses the argument registers, in the future we will use these for WASM and/or JS. Additonally, it knows the callee save registers for any given function. The main advantage of this class is that it makes it easy to iterate over the arguments of your function without having to worry about the details of the calling convention you are using.

        2) Makes the WASM calling convention the same as the JS one. Currently, the CodeBlock, CodeOrigin, and Callee are all 0. Since they have no value. Additionally, since we call into WASM from C++ through vmEntryToJavaScript, if there are no arguments to the callee we insert a null pointer as the first argument.

        3) Since WASM expects the arguments to be mapped to function locals we map the argument stack slots to variables immediately after the function prologue.

        * B3CallingConventions.cpp: Copied from Source/JavaScriptCore/llint/LLIntThunks.h.
        (JSC::B3::jscCallingConvention):
        * B3CallingConventions.h: Added.
        (JSC::B3::CallingConvention::CallingConvention):
        (JSC::B3::CallingConvention::iterate):
        (JSC::B3::nextJSCOffset):
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * interpreter/ProtoCallFrame.h:
        * llint/LLIntThunks.cpp:
        (JSC::vmEntryToWASM):
        * llint/LLIntThunks.h:
        * testWASM.cpp:
        (invoke):
        (box):
        (runWASMTests):
        * wasm/WASMB3IRGenerator.cpp:
        (JSC::WASM::B3IRGenerator::addLocal):
        (JSC::WASM::B3IRGenerator::addArguments):
        (JSC::WASM::B3IRGenerator::getLocal):
        * wasm/WASMFormat.h:
        * wasm/WASMFunctionParser.h:
        (JSC::WASM::FunctionParser<Context>::FunctionParser):
        (JSC::WASM::FunctionParser<Context>::parseExpression):
        * wasm/WASMModuleParser.cpp:
        (JSC::WASM::ModuleParser::parseFunctionTypes):
        (JSC::WASM::ModuleParser::parseFunctionSignatures):
        * wasm/WASMModuleParser.h:
        * wasm/WASMOps.h:

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

        Rename WASM classes dropping the WASM prefix
        https://bugs.webkit.org/show_bug.cgi?id=161500

        Reviewed by Mark Lam.

        Having to write WASM::WASMModule seems silly. Also, this patch
        merges WASMFunctionReturnType and WASMValueType into one type
        that is a typedef of B3::Type. Using B3::Type as the WASM
        primitive type makes it trivial to convert a Vector of WASM
        types into a Vector of B3 types.

        * b3/B3Type.h:
        * wasm/JSWASMModule.h:
        (JSC::JSWASMModule::signatures):
        (JSC::JSWASMModule::functionImports):
        (JSC::JSWASMModule::functionImportSignatures):
        (JSC::JSWASMModule::globalVariableTypes):
        (JSC::JSWASMModule::functionDeclarations):
        (JSC::JSWASMModule::functionPointerTables):
        * wasm/WASMB3IRGenerator.cpp:
        (JSC::WASM::toB3Op):
        (JSC::WASM::B3IRGenerator::addLocal):
        (JSC::WASM::B3IRGenerator::unaryOp):
        (JSC::WASM::B3IRGenerator::binaryOp):
        (JSC::WASM::B3IRGenerator::addConstant):
        (JSC::WASM::parseAndCompile):
        * wasm/WASMB3IRGenerator.h:
        * wasm/WASMFormat.h:
        * wasm/WASMFunctionParser.h:
        (JSC::WASM::FunctionParser<Context>::FunctionParser):
        (JSC::WASM::FunctionParser<Context>::parse):
        (JSC::WASM::FunctionParser<Context>::parseBlock):
        (JSC::WASM::FunctionParser<Context>::parseExpression):
        (JSC::WASM::WASMFunctionParser<Context>::WASMFunctionParser): Deleted.
        (JSC::WASM::WASMFunctionParser<Context>::parse): Deleted.
        (JSC::WASM::WASMFunctionParser<Context>::parseBlock): Deleted.
        (JSC::WASM::WASMFunctionParser<Context>::parseExpression): Deleted.
        * wasm/WASMModuleParser.cpp:
        (JSC::WASM::ModuleParser::parse):
        (JSC::WASM::ModuleParser::parseFunctionTypes):
        (JSC::WASM::ModuleParser::parseFunctionSignatures):
        (JSC::WASM::ModuleParser::parseFunctionDefinitions):
        (JSC::WASM::WASMModuleParser::parse): Deleted.
        (JSC::WASM::WASMModuleParser::parseFunctionTypes): Deleted.
        (JSC::WASM::WASMModuleParser::parseFunctionSignatures): Deleted.
        (JSC::WASM::WASMModuleParser::parseFunctionDefinitions): Deleted.
        * wasm/WASMModuleParser.h:
        (JSC::WASM::ModuleParser::ModuleParser):
        (JSC::WASM::ModuleParser::functionInformation):
        (JSC::WASM::WASMModuleParser::WASMModuleParser): Deleted.
        (JSC::WASM::WASMModuleParser::functionInformation): Deleted.
        * wasm/WASMOps.h:
        * wasm/WASMParser.h:
        (JSC::WASM::Parser::Parser):
        (JSC::WASM::Parser::consumeCharacter):
        (JSC::WASM::Parser::consumeString):
        (JSC::WASM::Parser::parseUInt32):
        (JSC::WASM::Parser::parseUInt7):
        (JSC::WASM::Parser::parseVarUInt1):
        (JSC::WASM::Parser::parseValueType):
        (JSC::WASM::WASMParser::WASMParser): Deleted.
        (JSC::WASM::WASMParser::consumeCharacter): Deleted.
        (JSC::WASM::WASMParser::consumeString): Deleted.
        (JSC::WASM::WASMParser::parseUInt32): Deleted.
        (JSC::WASM::WASMParser::parseUInt7): Deleted.
        (JSC::WASM::WASMParser::parseVarUInt1): Deleted.
        (JSC::WASM::WASMParser::parseValueType): Deleted.
        * wasm/WASMPlan.cpp:
        (JSC::WASM::Plan::Plan):
        * wasm/WASMSections.cpp:
        (JSC::WASM::Sections::lookup):
        (JSC::WASM::WASMSections::lookup): Deleted.
        * wasm/WASMSections.h:
        (JSC::WASM::Sections::validateOrder):
        (JSC::WASM::WASMSections::validateOrder): Deleted.

2016-09-01  Filip Pizlo  <fpizlo@apple.com>

        ObjectAllocationSinkingPhase::insertOSRHintsForUpdate() fails to emit updated hints in some cases
        https://bugs.webkit.org/show_bug.cgi?id=161492

        Reviewed by Mark Lam.
        
        If you materialize a sunken object that is referenced from another sunken object, then you
        have to emit a PutHint to tell OSR that the latter object now refers to a materialized
        object rather than to the old sunken one.
        
        The ObjectAllocationSinkingPhase totally knows how to do this, but for some reason it only
        did it when the PromotedLocationDescriptor for the field used for referring to the other
        object is !neededForMaterialization(), i.e. it's a NamedPropertyPLoc or a ClosureVarPLoc.
        I can sort of imagine why we thought that would be right - neededForMaterialization() means
        it's a special meta-data field initialized on construction. But just because it's immutable
        and special doesn't mean that materialization can't change its physical representation.
        Removing the requirement that it's !neededForMaterialization() fixes the test and doesn't
        regress anything.

        * dfg/DFGObjectAllocationSinkingPhase.cpp:

2016-09-01  Chris Dumez  <cdumez@apple.com>

        Unreviewed, rolling out r205297.

        Caused some JSC test failures

        Reverted changeset:

        "Align cross-origin proto getter / setter behavior with the
        specification"
        https://bugs.webkit.org/show_bug.cgi?id=161455
        http://trac.webkit.org/changeset/205297

2016-09-01  Chris Dumez  <cdumez@apple.com>

        Align cross-origin proto getter / setter behavior with the specification
        https://bugs.webkit.org/show_bug.cgi?id=161455

        Reviewed by Mark Lam.

        Align cross-origin proto getter / setter behavior with the specification:

        The setter should throw a TypeError:
        - https://html.spec.whatwg.org/#windowproxy-setprototypeof
        - https://html.spec.whatwg.org/#location-setprototypeof
        - https://tc39.github.io/ecma262/#sec-object.setprototypeof (step 5)

        The getter should return null:
        - https://html.spec.whatwg.org/#windowproxy-getprototypeof
        - https://html.spec.whatwg.org/#location-getprototypeof

        I have verified that this aligns our behavior with Firefox and Chrome.

        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::GlobalFuncProtoGetterFunctor::operator()):
        (JSC::globalFuncProtoSetter):

2016-09-01  Csaba Osztrogonác  <ossy@webkit.org>

        Unreviewed ARM buildfix after r205283.

        * assembler/ARMAssembler.h:
        (JSC::ARMAssembler::patchableJumpSize):
        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::patchableJumpSize):

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

        JITMathIC was misusing maxJumpReplacementSize
        https://bugs.webkit.org/show_bug.cgi?id=161356
        <rdar://problem/28065560>

        Reviewed by Benjamin Poulain.

        JITMathIC was assuming that maxJumpReplacementSize is the size
        you'd get if you emitted a patchableJump() using the macro assembler.
        This is not true, however. It happens to be true on arm64, x86 and x86-64,
        however, it is not true on armv7. This patch introduces an alternative to
        maxJumpReplacementSize called patchableJumpSize, and switches JITMathIC
        to use that number instead.

        * assembler/ARM64Assembler.h:
        (JSC::ARM64Assembler::patchableJumpSize):
        (JSC::ARM64Assembler::maxJumpReplacementSize): Deleted.
        * assembler/ARMv7Assembler.h:
        (JSC::ARMv7Assembler::patchableJumpSize):
        (JSC::ARMv7Assembler::maxJumpReplacementSize): Deleted.
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::patchableJumpSize):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::patchableJumpSize):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::patchableJumpSize):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::patchableJumpSize):
        (JSC::X86Assembler::maxJumpReplacementSize): Deleted.
        * jit/JITMathIC.h:
        (JSC::JITMathIC::generateInline):

2016-08-31  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Add initiator parameter to module pipeline
        https://bugs.webkit.org/show_bug.cgi?id=161470

        Reviewed by Saam Barati.

        The fetching semantics of the <script type="module"> tag has per module-tag context.
        For example, "nonce", "crossorigin" etc. attributes are shared in the fetching requests
        issued from the module-tag. To transfer this information, we add a new parameter "initiator"
        to the module loader pipeline. We are planning to transfer information by this parameter.

        At the same time, we also perform some clean up.

        - Use arrow function in ModuleLoaderPrototype.js.
        - Rename "ResolveDependencies" to "Satisfy" to align to the loader spec.

        * builtins/ModuleLoaderPrototype.js:
        (newRegistryEntry):
        (commitInstantiated):
        (requestFetch):
        (requestTranslate):
        (requestInstantiate):
        (requestSatisfy):
        (requestInstantiateAll):
        (requestLink):
        (moduleEvaluation):
        (provide):
        (loadAndEvaluateModule):
        (requestResolveDependencies.): Deleted.
        (requestResolveDependencies): Deleted.
        (requestReady): Deleted.
        (link): Deleted.
        (loadModule): Deleted.
        (linkAndEvaluateModule): Deleted.
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * jsc.cpp:
        (GlobalObject::moduleLoaderResolve):
        (GlobalObject::moduleLoaderFetch):
        * runtime/Completion.cpp:
        (JSC::loadAndEvaluateModule):
        (JSC::loadModule):
        (JSC::linkAndEvaluateModule):
        * runtime/Completion.h:
        * runtime/JSGlobalObject.h:
        * runtime/JSModuleLoader.cpp:
        (JSC::JSModuleLoader::loadAndEvaluateModule):
        (JSC::JSModuleLoader::loadModule):
        (JSC::JSModuleLoader::linkAndEvaluateModule):
        (JSC::JSModuleLoader::resolve):
        (JSC::JSModuleLoader::fetch):
        (JSC::JSModuleLoader::translate):
        (JSC::JSModuleLoader::instantiate):
        (JSC::JSModuleLoader::evaluate):
        * runtime/JSModuleLoader.h:
        * runtime/ModuleLoaderPrototype.cpp:
        (JSC::moduleLoaderPrototypeResolve):
        (JSC::moduleLoaderPrototypeFetch):
        (JSC::moduleLoaderPrototypeTranslate):
        (JSC::moduleLoaderPrototypeInstantiate):
        (JSC::moduleLoaderPrototypeEvaluate):

2016-08-31  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] linking and evaluating the modules are done in a sync manner
        https://bugs.webkit.org/show_bug.cgi?id=161467

        Reviewed by Saam Barati.

        While the fetching and the other stages are done in an asynchronous manner,
        linking and evaluating are done in a sync manner.
        Just return the result value and do not wrap them with the internal promise.

        * builtins/ModuleLoaderPrototype.js:
        (linkAndEvaluateModule):
        * runtime/Completion.cpp:
        (JSC::linkAndEvaluateModule):
        * runtime/Completion.h:
        * runtime/JSModuleLoader.cpp:
        (JSC::JSModuleLoader::linkAndEvaluateModule):
        * runtime/JSModuleLoader.h:

2016-08-31  Yusuke Suzuki  <utatane.tea@gmail.com>

        stress/random-53bit.js.ftl-no-cjit-no-inline-validate sometimes fails
        https://bugs.webkit.org/show_bug.cgi?id=161436

        Reviewed by Filip Pizlo.

        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionGetRandomSeed):
        (functionSetRandomSeed):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::weakRandom):
        (JSC::JSGlobalObject::weakRandomInteger): Deleted.

2016-08-31  Chris Dumez  <cdumez@apple.com>

        Object.getPrototypeOf() should return null cross-origin
        https://bugs.webkit.org/show_bug.cgi?id=161393

        Reviewed by Geoffrey Garen.

        Object.getPrototypeOf() should return null cross-origin:
        - https://html.spec.whatwg.org/#windowproxy-getprototypeof
        - https://html.spec.whatwg.org/#location-getprototypeof

        Firefox and Chrome return null. However, WebKit was returning undefined.

        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructorGetPrototypeOfFunctor::operator()):

2016-08-31  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] AbstractValue can contain padding which is not zero-filled
        https://bugs.webkit.org/show_bug.cgi?id=161427

        Reviewed by Saam Barati.

        We checked that AbstractValue is zero-filled when initializing it to ensure
        that zero-filled memory can be used as the initialized AbstractValue.
        However, since the size of SpeculatedType becomes 64bit, AbstractValue can have
        padding now. And this padding is not ensured that it is initialized with zeros.
        So debug assertion fails when building with GCC.

        This patch changes the strategy. Instead of checking the initialized
        AbstractValue is zero-filled, we ensure that zero-filled AbstractValue can be
        considered to be equal to the initialized AbstractValue.

        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::ensureCanInitializeWithZeros):
        * dfg/DFGAbstractValue.h:
        (JSC::DFG::AbstractValue::AbstractValue):

2016-08-31  Brady Eidson  <beidson@apple.com>

        WK2 Gamepad provider on iOS.
        https://bugs.webkit.org/show_bug.cgi?id=161412

        Reviewed by Tim Horton.

        * Configurations/FeatureDefines.xcconfig:

2016-08-30  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Some arith nodes are too pessimistic with the types supported on the fast path
        https://bugs.webkit.org/show_bug.cgi?id=161410

        Reviewed by Geoffrey Garen.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        DoubleRep is able to convert numbers, undefined, booleans and null.
        I was too pessimistic when I gated the double implementations
        on number-or-boolean speculation. We can just let DoubleRep convert
        the other cases as long as it is not a Cell.

2016-08-30  Chris Dumez  <cdumez@apple.com>

        Unreviewed, fix build after r205205.

        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorSetPrototypeOf):

2016-08-30  Chris Dumez  <cdumez@apple.com>

        Object.setPrototypeOf() should throw when used on a cross-origin Window / Location object
        https://bugs.webkit.org/show_bug.cgi?id=161396

        Reviewed by Ryosuke Niwa.

        Object.setPrototypeOf() should throw when used on a cross-origin Window / Location object:
        - https://html.spec.whatwg.org/#windowproxy-setprototypeof
        - https://html.spec.whatwg.org/#location-setprototypeof
        - https://tc39.github.io/ecma262/#sec-object.setprototypeof (step 5)

        Firefox and Chrome already throw. However, WebKit merely ignores the call and logs an error message.

        Note that technically, we should also throw in the same origin case.
        However, not all browsers agree on this yet so I haven't not changed
        the behavior for the same origin case.

        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorSetPrototypeOf):

2016-08-30  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Clean up the remaining compare nodes in FTLCapabilities
        https://bugs.webkit.org/show_bug.cgi?id=161400

        Reviewed by Geoffrey Garen.

        It looks like we implemented all the cases without realizing it.

        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compare):

2016-08-30  Mark Lam  <mark.lam@apple.com>

        Introduce the ThrowScope and force every throw site to instantiate a ThrowScope.
        https://bugs.webkit.org/show_bug.cgi?id=161171

        Reviewed by Filip Pizlo and Geoffrey Garen.

        This is the first step towards having a mechanism (using the ThrowScope) to
        verify that we're properly checking for exceptions in all the needed places.
        See comments at the top of ThrowScope.cpp for details on how the ThrowScope works.

        This patch only introduces the ThrowScope, and changes all throw sites to throw
        using a ThrowScope instance.  VM::throwException() functions are now private, and
        cannot be accessed directly.  All throws must now go through a ThrowScope.

        Verification is disabled for the moment until we can fix all the verification
        failures that will show up.

        I also did a smoke test of the ThrowScope mechanisms by running verification on
        the JSTests/stress/op-add-exceptions.js test with a local build with verification
        turned on.

        Performance is neutral on aggregate with this patch.

        Misc other changes:
        - deleted the unused CALL_THROW() macro from LLIntSlowPaths.cpp.
        - moved createListFromArrayLike() from JSObject.h to JSObjectInlines.h.

        * API/APICallbackFunction.h:
        (JSC::APICallbackFunction::call):
        (JSC::APICallbackFunction::construct):
        * API/JSCallbackObjectFunctions.h:
        (JSC::JSCallbackObject<Parent>::getOwnPropertySlot):
        (JSC::JSCallbackObject<Parent>::defaultValue):
        (JSC::JSCallbackObject<Parent>::put):
        (JSC::JSCallbackObject<Parent>::putByIndex):
        (JSC::JSCallbackObject<Parent>::deleteProperty):
        (JSC::JSCallbackObject<Parent>::construct):
        (JSC::JSCallbackObject<Parent>::customHasInstance):
        (JSC::JSCallbackObject<Parent>::call):
        (JSC::JSCallbackObject<Parent>::getStaticValue):
        (JSC::JSCallbackObject<Parent>::staticFunctionGetter):
        (JSC::JSCallbackObject<Parent>::callbackGetter):
        * API/JSTypedArray.cpp:
        (createTypedArray):
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGOperations.cpp:
        (JSC::DFG::newTypedArrayWithSize):
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
        * inspector/JSInjectedScriptHostPrototype.cpp:
        (Inspector::jsInjectedScriptHostPrototypeAttributeEvaluate):
        (Inspector::jsInjectedScriptHostPrototypeFunctionInternalConstructorName):
        (Inspector::jsInjectedScriptHostPrototypeFunctionIsHTMLAllCollection):
        (Inspector::jsInjectedScriptHostPrototypeFunctionWeakMapSize):
        (Inspector::jsInjectedScriptHostPrototypeFunctionWeakMapEntries):
        (Inspector::jsInjectedScriptHostPrototypeFunctionWeakSetSize):
        (Inspector::jsInjectedScriptHostPrototypeFunctionWeakSetEntries):
        (Inspector::jsInjectedScriptHostPrototypeFunctionIteratorEntries):
        (Inspector::jsInjectedScriptHostPrototypeFunctionEvaluateWithScopeExtension):
        (Inspector::jsInjectedScriptHostPrototypeFunctionSubtype):
        (Inspector::jsInjectedScriptHostPrototypeFunctionFunctionDetails):
        (Inspector::jsInjectedScriptHostPrototypeFunctionGetInternalProperties):
        * inspector/JSJavaScriptCallFrame.cpp:
        (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension):
        * inspector/JSJavaScriptCallFramePrototype.cpp:
        (Inspector::jsJavaScriptCallFramePrototypeFunctionEvaluateWithScopeExtension):
        (Inspector::jsJavaScriptCallFramePrototypeFunctionScopeDescriptions):
        (Inspector::jsJavaScriptCallFrameAttributeCaller):
        (Inspector::jsJavaScriptCallFrameAttributeSourceID):
        (Inspector::jsJavaScriptCallFrameAttributeLine):
        (Inspector::jsJavaScriptCallFrameAttributeColumn):
        (Inspector::jsJavaScriptCallFrameAttributeFunctionName):
        (Inspector::jsJavaScriptCallFrameAttributeScopeChain):
        (Inspector::jsJavaScriptCallFrameAttributeThisObject):
        (Inspector::jsJavaScriptCallFrameAttributeType):
        (Inspector::jsJavaScriptCallFrameIsTailDeleted):
        * interpreter/CachedCall.h:
        (JSC::CachedCall::CachedCall):
        * interpreter/Interpreter.cpp:
        (JSC::eval):
        (JSC::sizeOfVarargs):
        (JSC::sizeFrameForForwardArguments):
        (JSC::sizeFrameForVarargs):
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        (JSC::Interpreter::prepareForRepeatCall):
        * jit/JITOperations.cpp:
        * jsc.cpp:
        (WTF::CustomGetter::customGetter):
        (WTF::RuntimeArray::lengthGetter):
        (functionCreateElement):
        (functionRun):
        (functionRunString):
        (functionLoad):
        (functionLoadString):
        (functionReadFile):
        (functionCheckSyntax):
        (functionTransferArrayBuffer):
        (functionLoadModule):
        (functionCheckModuleSyntax):
        (functionSamplingProfilerStackTraces):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (JSC::LLInt::getByVal):
        (JSC::LLInt::handleHostCall):
        (JSC::LLInt::setUpCall):
        (JSC::LLInt::llint_throw_stack_overflow_error):
        * runtime/ArrayConstructor.cpp:
        (JSC::constructArrayWithSizeQuirk):
        * runtime/ArrayConstructor.h:
        (JSC::isArray):
        * runtime/ArrayPrototype.cpp:
        (JSC::shift):
        (JSC::unshift):
        (JSC::arrayProtoFuncToString):
        (JSC::arrayProtoFuncPop):
        (JSC::arrayProtoFuncReverse):
        (JSC::arrayProtoFuncSplice):
        (JSC::concatAppendOne):
        (JSC::arrayProtoPrivateFuncConcatMemcpy):
        * runtime/BooleanPrototype.cpp:
        (JSC::booleanProtoFuncToString):
        (JSC::booleanProtoFuncValueOf):
        * runtime/CommonSlowPaths.cpp:
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::opIn):
        * runtime/CommonSlowPathsExceptions.cpp:
        (JSC::CommonSlowPaths::interpreterThrowInCaller):
        * runtime/ConstructData.cpp:
        (JSC::construct):
        * runtime/DatePrototype.cpp:
        (JSC::formateDateInstance):
        (JSC::dateProtoFuncToISOString):
        (JSC::dateProtoFuncToLocaleString):
        (JSC::dateProtoFuncToLocaleDateString):
        (JSC::dateProtoFuncToLocaleTimeString):
        (JSC::dateProtoFuncToPrimitiveSymbol):
        (JSC::dateProtoFuncGetTime):
        (JSC::dateProtoFuncGetFullYear):
        (JSC::dateProtoFuncGetUTCFullYear):
        (JSC::dateProtoFuncGetMonth):
        (JSC::dateProtoFuncGetUTCMonth):
        (JSC::dateProtoFuncGetDate):
        (JSC::dateProtoFuncGetUTCDate):
        (JSC::dateProtoFuncGetDay):
        (JSC::dateProtoFuncGetUTCDay):
        (JSC::dateProtoFuncGetHours):
        (JSC::dateProtoFuncGetUTCHours):
        (JSC::dateProtoFuncGetMinutes):
        (JSC::dateProtoFuncGetUTCMinutes):
        (JSC::dateProtoFuncGetSeconds):
        (JSC::dateProtoFuncGetUTCSeconds):
        (JSC::dateProtoFuncGetMilliSeconds):
        (JSC::dateProtoFuncGetUTCMilliseconds):
        (JSC::dateProtoFuncGetTimezoneOffset):
        (JSC::dateProtoFuncSetTime):
        (JSC::setNewValueFromTimeArgs):
        (JSC::setNewValueFromDateArgs):
        (JSC::dateProtoFuncSetYear):
        (JSC::dateProtoFuncGetYear):
        (JSC::dateProtoFuncToJSON):
        * runtime/Error.cpp:
        (JSC::throwConstructorCannotBeCalledAsFunctionTypeError):
        (JSC::throwTypeError):
        (JSC::throwSyntaxError):
        * runtime/Error.h:
        (JSC::throwRangeError):
        (JSC::throwVMError):
        (JSC::throwVMTypeError):
        (JSC::throwVMRangeError):
        (JSC::StrictModeTypeErrorFunction::constructThrowTypeError):
        (JSC::StrictModeTypeErrorFunction::callThrowTypeError):
        * runtime/ErrorPrototype.cpp:
        (JSC::errorProtoFuncToString):
        * runtime/ExceptionFuzz.cpp:
        (JSC::doExceptionFuzzing):
        * runtime/ExceptionHelpers.cpp:
        (JSC::throwOutOfMemoryError):
        (JSC::throwStackOverflowError):
        (JSC::throwTerminatedExecutionException):
        * runtime/ExceptionHelpers.h:
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::newCodeBlockFor):
        (JSC::EvalExecutable::create):
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunction):
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * runtime/FunctionPrototype.cpp:
        (JSC::functionProtoFuncToString):
        (JSC::functionProtoFuncBind):
        * runtime/GetterSetter.cpp:
        (JSC::callSetter):
        * runtime/IntlCollator.cpp:
        (JSC::IntlCollator::compareStrings):
        * runtime/IntlCollatorPrototype.cpp:
        (JSC::IntlCollatorPrototypeGetterCompare):
        (JSC::IntlCollatorPrototypeFuncResolvedOptions):
        * runtime/IntlDateTimeFormat.cpp:
        (JSC::IntlDateTimeFormat::initializeDateTimeFormat):
        (JSC::IntlDateTimeFormat::format):
        * runtime/IntlDateTimeFormatPrototype.cpp:
        (JSC::IntlDateTimeFormatPrototypeGetterFormat):
        (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
        * runtime/IntlNumberFormat.cpp:
        (JSC::IntlNumberFormat::initializeNumberFormat):
        (JSC::IntlNumberFormat::formatNumber):
        * runtime/IntlNumberFormatPrototype.cpp:
        (JSC::IntlNumberFormatPrototypeGetterFormat):
        (JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
        * runtime/IntlObject.cpp:
        (JSC::intlStringOption):
        (JSC::intlNumberOption):
        (JSC::canonicalizeLocaleList):
        (JSC::lookupSupportedLocales):
        * runtime/IteratorOperations.cpp:
        (JSC::iteratorNext):
        (JSC::iteratorClose):
        (JSC::createIteratorResultObject):
        (JSC::iteratorForIterable):
        * runtime/JSArray.cpp:
        (JSC::JSArray::defineOwnProperty):
        (JSC::JSArray::put):
        (JSC::JSArray::appendMemcpy):
        (JSC::JSArray::setLength):
        (JSC::JSArray::pop):
        (JSC::JSArray::push):
        (JSC::JSArray::unshiftCountWithArrayStorage):
        (JSC::JSArray::unshiftCountWithAnyIndexingType):
        * runtime/JSArrayBufferConstructor.cpp:
        (JSC::constructArrayBuffer):
        (JSC::callArrayBuffer):
        * runtime/JSArrayBufferPrototype.cpp:
        (JSC::arrayBufferProtoFuncSlice):
        * runtime/JSCInlines.h:
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::toObjectSlowCase):
        (JSC::JSValue::synthesizePrototype):
        (JSC::JSValue::putToPrimitive):
        (JSC::JSValue::putToPrimitiveByIndex):
        (JSC::JSValue::toStringSlowCase):
        * runtime/JSCJSValueInlines.h:
        (JSC::toPreferredPrimitiveType):
        (JSC::JSValue::requireObjectCoercible):
        * runtime/JSDataView.cpp:
        (JSC::JSDataView::create):
        * runtime/JSDataViewPrototype.cpp:
        (JSC::getData):
        (JSC::setData):
        (JSC::dataViewProtoGetterBuffer):
        (JSC::dataViewProtoGetterByteLength):
        (JSC::dataViewProtoGetterByteOffset):
        * runtime/JSFunction.cpp:
        (JSC::callHostFunctionAsConstructor):
        (JSC::JSFunction::callerGetter):
        (JSC::JSFunction::put):
        (JSC::JSFunction::defineOwnProperty):
        * runtime/JSGenericTypedArrayView.h:
        (JSC::JSGenericTypedArrayView::setIndex):
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::constructGenericTypedArrayViewFromIterator):
        (JSC::constructGenericTypedArrayViewWithArguments):
        (JSC::constructGenericTypedArrayView):
        (JSC::callGenericTypedArrayView):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::create):
        (JSC::JSGenericTypedArrayView<Adaptor>::createUninitialized):
        (JSC::JSGenericTypedArrayView<Adaptor>::validateRange):
        (JSC::JSGenericTypedArrayView<Adaptor>::throwNeuteredTypedArrayTypeError):
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::speciesConstruct):
        (JSC::genericTypedArrayViewProtoFuncSet):
        (JSC::genericTypedArrayViewProtoFuncCopyWithin):
        (JSC::genericTypedArrayViewProtoFuncIncludes):
        (JSC::genericTypedArrayViewProtoFuncIndexOf):
        (JSC::genericTypedArrayViewProtoFuncJoin):
        (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
        (JSC::genericTypedArrayViewProtoGetterFuncBuffer):
        (JSC::genericTypedArrayViewProtoGetterFuncLength):
        (JSC::genericTypedArrayViewProtoGetterFuncByteLength):
        (JSC::genericTypedArrayViewProtoGetterFuncByteOffset):
        (JSC::genericTypedArrayViewProtoFuncReverse):
        (JSC::genericTypedArrayViewPrivateFuncSort):
        (JSC::genericTypedArrayViewProtoFuncSlice):
        (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::createEvalCodeBlock):
        (JSC::JSGlobalObject::createModuleProgramCodeBlock):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::encode):
        (JSC::decode):
        (JSC::globalFuncEval):
        (JSC::globalFuncThrowTypeError):
        (JSC::globalFuncThrowTypeErrorArgumentsCalleeAndCaller):
        (JSC::globalFuncProtoGetter):
        (JSC::globalFuncProtoSetter):
        * runtime/JSModuleEnvironment.cpp:
        (JSC::JSModuleEnvironment::put):
        * runtime/JSModuleNamespaceObject.cpp:
        (JSC::JSModuleNamespaceObject::getOwnPropertySlot):
        (JSC::JSModuleNamespaceObject::put):
        (JSC::JSModuleNamespaceObject::putByIndex):
        (JSC::JSModuleNamespaceObject::defineOwnProperty):
        (JSC::moduleNamespaceObjectSymbolIterator):
        * runtime/JSModuleRecord.cpp:
        (JSC::JSModuleRecord::getModuleNamespace):
        (JSC::JSModuleRecord::link):
        (JSC::JSModuleRecord::instantiateDeclarations):
        * runtime/JSONObject.cpp:
        (JSC::Stringifier::appendStringifiedValue):
        (JSC::Walker::walk):
        (JSC::JSONProtoFuncParse):
        (JSC::JSONProtoFuncStringify):
        * runtime/JSObject.cpp:
        (JSC::JSObject::setPrototypeWithCycleCheck):
        (JSC::callToPrimitiveFunction):
        (JSC::JSObject::ordinaryToPrimitive):
        (JSC::JSObject::hasInstance):
        (JSC::JSObject::defaultHasInstance):
        (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes):
        (JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage):
        (JSC::validateAndApplyPropertyDescriptor):
        (JSC::JSObject::getMethod):
        * runtime/JSObject.h:
        (JSC::createListFromArrayLike): Deleted.
        * runtime/JSObjectInlines.h:
        (JSC::createListFromArrayLike):
        (JSC::JSObject::putInline):
        * runtime/JSPromiseConstructor.cpp:
        (JSC::constructPromise):
        (JSC::callPromise):
        * runtime/JSPropertyNameIterator.cpp:
        (JSC::propertyNameIteratorFuncNext):
        * runtime/JSString.cpp:
        (JSC::JSRopeString::outOfMemory):
        * runtime/JSStringBuilder.h:
        (JSC::JSStringBuilder::build):
        (JSC::jsMakeNontrivialString):
        * runtime/JSStringJoiner.cpp:
        (JSC::JSStringJoiner::joinedLength):
        (JSC::JSStringJoiner::join):
        * runtime/JSStringJoiner.h:
        (JSC::JSStringJoiner::JSStringJoiner):
        * runtime/JSSymbolTableObject.h:
        (JSC::symbolTablePut):
        * runtime/JSTypedArrayViewConstructor.cpp:
        (JSC::constructTypedArrayView):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::typedArrayViewPrivateFuncLength):
        (JSC::typedArrayViewPrivateFuncSort):
        (JSC::typedArrayViewProtoFuncSet):
        (JSC::typedArrayViewProtoFuncCopyWithin):
        (JSC::typedArrayViewProtoFuncIncludes):
        (JSC::typedArrayViewProtoFuncLastIndexOf):
        (JSC::typedArrayViewProtoFuncIndexOf):
        (JSC::typedArrayViewProtoFuncJoin):
        (JSC::typedArrayViewProtoGetterFuncBuffer):
        (JSC::typedArrayViewProtoGetterFuncLength):
        (JSC::typedArrayViewProtoGetterFuncByteLength):
        (JSC::typedArrayViewProtoGetterFuncByteOffset):
        (JSC::typedArrayViewProtoFuncReverse):
        (JSC::typedArrayViewPrivateFuncSubarrayCreate):
        (JSC::typedArrayViewProtoFuncSlice):
        * runtime/MapConstructor.cpp:
        (JSC::callMap):
        (JSC::constructMap):
        * runtime/MapDataInlines.h:
        (JSC::JSIterator>::ensureSpaceForAppend):
        * runtime/MapIteratorPrototype.cpp:
        (JSC::MapIteratorPrototypeFuncNext):
        * runtime/MapPrototype.cpp:
        (JSC::getMap):
        (JSC::mapProtoFuncValues):
        (JSC::mapProtoFuncEntries):
        (JSC::mapProtoFuncKeys):
        * runtime/ModuleLoaderPrototype.cpp:
        (JSC::moduleLoaderPrototypeParseModule):
        * runtime/NullSetterFunction.cpp:
        (JSC::callReturnUndefined):
        * runtime/NumberPrototype.cpp:
        (JSC::numberProtoFuncToExponential):
        (JSC::numberProtoFuncToFixed):
        (JSC::numberProtoFuncToPrecision):
        (JSC::numberProtoFuncToString):
        (JSC::numberProtoFuncToLocaleString):
        (JSC::numberProtoFuncValueOf):
        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorSetPrototypeOf):
        (JSC::toPropertyDescriptor):
        (JSC::objectConstructorDefineProperty):
        (JSC::objectConstructorDefineProperties):
        (JSC::objectConstructorCreate):
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncDefineGetter):
        (JSC::objectProtoFuncDefineSetter):
        (JSC::objectProtoFuncToString):
        * runtime/Operations.h:
        (JSC::jsString):
        (JSC::jsStringFromRegisterArray):
        (JSC::jsStringFromArguments):
        * runtime/ProxyConstructor.cpp:
        (JSC::makeRevocableProxy):
        (JSC::proxyRevocableConstructorThrowError):
        (JSC::constructProxyObject):
        (JSC::callProxy):
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::finishCreation):
        (JSC::performProxyGet):
        (JSC::ProxyObject::performInternalMethodGetOwnProperty):
        (JSC::ProxyObject::performHasProperty):
        (JSC::ProxyObject::getOwnPropertySlotCommon):
        (JSC::ProxyObject::performPut):
        (JSC::performProxyCall):
        (JSC::performProxyConstruct):
        (JSC::ProxyObject::performDelete):
        (JSC::ProxyObject::performPreventExtensions):
        (JSC::ProxyObject::performIsExtensible):
        (JSC::ProxyObject::performDefineOwnProperty):
        (JSC::ProxyObject::performGetOwnPropertyNames):
        (JSC::ProxyObject::performSetPrototype):
        (JSC::ProxyObject::performGetPrototype):
        * runtime/ReflectObject.cpp:
        (JSC::reflectObjectConstruct):
        (JSC::reflectObjectDefineProperty):
        (JSC::reflectObjectEnumerate):
        (JSC::reflectObjectGet):
        (JSC::reflectObjectGetOwnPropertyDescriptor):
        (JSC::reflectObjectGetPrototypeOf):
        (JSC::reflectObjectIsExtensible):
        (JSC::reflectObjectOwnKeys):
        (JSC::reflectObjectPreventExtensions):
        (JSC::reflectObjectSet):
        (JSC::reflectObjectSetPrototypeOf):
        * runtime/RegExpConstructor.cpp:
        (JSC::toFlags):
        (JSC::regExpCreate):
        * runtime/RegExpObject.cpp:
        (JSC::collectMatches):
        * runtime/RegExpObject.h:
        (JSC::RegExpObject::setLastIndex):
        * runtime/RegExpPrototype.cpp:
        (JSC::regExpProtoFuncTestFast):
        (JSC::regExpProtoFuncExec):
        (JSC::regExpProtoFuncMatchFast):
        (JSC::regExpProtoFuncCompile):
        (JSC::regExpProtoFuncToString):
        (JSC::regExpProtoGetterGlobal):
        (JSC::regExpProtoGetterIgnoreCase):
        (JSC::regExpProtoGetterMultiline):
        (JSC::regExpProtoGetterSticky):
        (JSC::regExpProtoGetterUnicode):
        (JSC::regExpProtoGetterFlags):
        (JSC::regExpProtoGetterSource):
        (JSC::regExpProtoFuncSplitFast):
        * runtime/Reject.h:
        (JSC::reject):
        * runtime/SetConstructor.cpp:
        (JSC::callSet):
        (JSC::constructSet):
        * runtime/SetIteratorPrototype.cpp:
        (JSC::SetIteratorPrototypeFuncNext):
        * runtime/SetPrototype.cpp:
        (JSC::getSet):
        (JSC::setProtoFuncValues):
        (JSC::setProtoFuncEntries):
        * runtime/SparseArrayValueMap.cpp:
        (JSC::SparseArrayValueMap::putEntry):
        (JSC::SparseArrayEntry::put):
        * runtime/StringConstructor.cpp:
        (JSC::stringFromCodePoint):
        * runtime/StringObject.cpp:
        (JSC::StringObject::put):
        (JSC::StringObject::putByIndex):
        * runtime/StringPrototype.cpp:
        (JSC::jsSpliceSubstrings):
        (JSC::jsSpliceSubstringsWithSeparators):
        (JSC::repeatCharacter):
        (JSC::replace):
        (JSC::stringProtoFuncToString):
        (JSC::stringProtoFuncCharAt):
        (JSC::stringProtoFuncCharCodeAt):
        (JSC::stringProtoFuncCodePointAt):
        (JSC::stringProtoFuncConcat):
        (JSC::stringProtoFuncIndexOf):
        (JSC::stringProtoFuncLastIndexOf):
        (JSC::stringProtoFuncSlice):
        (JSC::stringProtoFuncSubstr):
        (JSC::stringProtoFuncSubstring):
        (JSC::stringProtoFuncToLowerCase):
        (JSC::stringProtoFuncToUpperCase):
        (JSC::stringProtoFuncLocaleCompare):
        (JSC::toLocaleCase):
        (JSC::stringProtoFuncBig):
        (JSC::stringProtoFuncSmall):
        (JSC::stringProtoFuncBlink):
        (JSC::stringProtoFuncBold):
        (JSC::stringProtoFuncFixed):
        (JSC::stringProtoFuncItalics):
        (JSC::stringProtoFuncStrike):
        (JSC::stringProtoFuncSub):
        (JSC::stringProtoFuncSup):
        (JSC::stringProtoFuncFontcolor):
        (JSC::stringProtoFuncFontsize):
        (JSC::stringProtoFuncAnchor):
        (JSC::stringProtoFuncLink):
        (JSC::trimString):
        (JSC::stringProtoFuncStartsWith):
        (JSC::stringProtoFuncEndsWith):
        (JSC::stringProtoFuncIncludes):
        (JSC::stringProtoFuncIterator):
        (JSC::normalize):
        (JSC::stringProtoFuncNormalize):
        * runtime/StringRecursionChecker.cpp:
        (JSC::StringRecursionChecker::throwStackOverflowError):
        * runtime/Symbol.cpp:
        (JSC::Symbol::toNumber):
        * runtime/SymbolConstructor.cpp:
        (JSC::symbolConstructorKeyFor):
        * runtime/SymbolPrototype.cpp:
        (JSC::symbolProtoFuncToString):
        (JSC::symbolProtoFuncValueOf):
        * runtime/ThrowScope.cpp: Added.
        (JSC::ThrowScope::ThrowScope):
        (JSC::ThrowScope::~ThrowScope):
        (JSC::ThrowScope::throwException):
        (JSC::ThrowScope::printIfNeedCheck):
        (JSC::ThrowScope::simulateThrow):
        (JSC::ThrowScope::verifyExceptionCheckNeedIsSatisfied):
        * runtime/ThrowScope.h: Added.
        (JSC::ThrowScope::vm):
        (JSC::ThrowScope::exception):
        (JSC::ThrowScope::release):
        (JSC::ThrowScope::ThrowScope):
        (JSC::ThrowScope::throwException):
        (JSC::throwException):
        * runtime/ThrowScopeLocation.h: Added.
        (JSC::ThrowScopeLocation::ThrowScopeLocation):
        * runtime/VM.h:
        * runtime/VMEntryScope.h:
        (JSC::VMEntryScope::vm):
        * runtime/WeakMapConstructor.cpp:
        (JSC::callWeakMap):
        (JSC::constructWeakMap):
        * runtime/WeakMapPrototype.cpp:
        (JSC::getWeakMapData):
        (JSC::protoFuncWeakMapSet):
        * runtime/WeakSetConstructor.cpp:
        (JSC::callWeakSet):
        (JSC::constructWeakSet):
        * runtime/WeakSetPrototype.cpp:
        (JSC::getWeakMapData):
        (JSC::protoFuncWeakSetAdd):

2016-08-30  Alex Christensen  <achristensen@webkit.org>

        Fix WebInspectorUI in internal Windows build
        https://bugs.webkit.org/show_bug.cgi?id=161221
        rdar://problem/28019023

        Reviewed by Brent Fulgham and Joseph Pecoraro.

        * JavaScriptCore.vcxproj/JavaScriptCore.proj:

2016-08-29  Joseph Pecoraro  <pecoraro@apple.com>

        REGRESSION(r202568): Web Inspector: Expanding Array Prototype in Console shows no properties
        https://bugs.webkit.org/show_bug.cgi?id=161263
        <rdar://problem/28035849>

        Reviewed by Matt Baker.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.prototype._propertyDescriptors):
        Previously we only took the "numeric index fast path" if an object was
        array like with length > 100. When we dropped the length check we
        ended up breaking our display of Array prototype, because [].__proto__
        is an array instance. Get it back by just doing a check of length > 0.
        We may want to address this differently in the future by knowing if
        we are getting properties for a prototype or not.

2016-08-29  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Clean up FTL Capabilities for CompareEq
        https://bugs.webkit.org/show_bug.cgi?id=161353

        Reviewed by Geoffrey Garen.

        It looks like we already have code for every case.
        This patch removes the tests from FTLCapabilities
        and move the generic case last as usual.

        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareEq):

2016-08-29  Keith Miller  <keith_miller@apple.com>

        Fix toStringName for Proxies and add support for normal instances
        https://bugs.webkit.org/show_bug.cgi?id=161275

        Reviewed by Saam Barati.

        toStringName on proxies needs to follow the chain of proxies until it finds a non-proxy target.
        Additionally, there are a couple of other classes that need to return "Object" for their
        toStringName. Since this isn't tested by test262 I will propose a new test there.

        * runtime/ClassInfo.h:
        * runtime/JSArrayBufferView.cpp:
        (JSC::JSArrayBufferView::toStringName):
        * runtime/JSArrayBufferView.h:
        * runtime/JSCell.cpp:
        (JSC::JSCell::toStringName):
        * runtime/JSCell.h:
        * runtime/JSMap.cpp:
        (JSC::JSMap::toStringName):
        * runtime/JSMap.h:
        * runtime/JSObject.cpp:
        (JSC::JSObject::toStringName):
        * runtime/JSObject.h:
        * runtime/JSSet.cpp:
        (JSC::JSSet::destroy):
        (JSC::JSSet::toStringName):
        * runtime/JSSet.h:
        * runtime/JSWeakMap.cpp:
        (JSC::JSWeakMap::toStringName):
        * runtime/JSWeakMap.h:
        * runtime/JSWeakSet.cpp:
        (JSC::JSWeakSet::toStringName):
        * runtime/JSWeakSet.h:
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncToString):
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::toStringName):
        * runtime/ProxyObject.h:
        * runtime/SymbolObject.cpp:
        (JSC::SymbolObject::toStringName):
        * runtime/SymbolObject.h:
        (JSC::SymbolObject::internalValue):

2016-08-29  Youenn Fablet  <youenn@apple.com>

        [Fetch API] Response cloning should structureClone when teeing Response stream
        https://bugs.webkit.org/show_bug.cgi?id=161147

        Reviewed by Darin Adler.

        * builtins/BuiltinNames.h: Adding ArrayBuffer and isView identifiers.
        * runtime/JSArrayBufferConstructor.cpp:
        (JSC::JSArrayBufferConstructor::finishCreation): Adding @isView as private method.
        * runtime/JSDataView.h: Exporting create method.

2016-08-29  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Improve ArithAbs with polymorphic input
        https://bugs.webkit.org/show_bug.cgi?id=161286

        Reviewed by Saam Barati.

        This is similar to the previous patches: if we have polymorphic
        input, do a function call.

        I also discovered a few problems with the tests and fixed them:
        -I forgot to add NodeMustGenerate to the previous nodes I changed.
         They could have been eliminated by DCE.
        -ArithAbs was always exiting if the input types do not include numbers.
         The cause was the node was using isInt32OrBooleanSpeculationForArithmetic()
         instead of isInt32OrBooleanSpeculation(). The test of
         isInt32OrBooleanSpeculationForArithmetic() only verify the input does not
         contains double or int52. If we were in that case, we were always speculating
         Int32. That always fails and we were recompiling the same code over and over.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        Now that we have toNumberFromPrimitive(), we can improve constant folding here :)

        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasResult):
        (JSC::DFG::Node::hasHeapPrediction):
        (JSC::DFG::Node::hasInt32Result): Deleted.
        The accessor hasInt32Result() was unused.

        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithAbs):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileArithAbs):

2016-08-28  Saam Barati  <sbarati@apple.com>

        Make SpeculatedType a 64-bit integer
        https://bugs.webkit.org/show_bug.cgi?id=161268

        Reviewed by Filip Pizlo and Benjamin Poulain.

        I'm going to introduce two new types into this and we only
        have room for one in 32-bits. So, this patch widens SpeculatedType
        to 64 bits. This also pulls this information through the DFG where
        we needed to change DFGNode to support this.

        * bytecode/SpeculatedType.h:
        * dfg/DFGNode.cpp:
        (JSC::DFG::Node::convertToPutHint):
        (JSC::DFG::Node::promotedLocationDescriptor):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::Node):
        (JSC::DFG::Node::convertToCheckStructure):
        (JSC::DFG::Node::constant):
        (JSC::DFG::Node::convertToConstant):
        (JSC::DFG::Node::convertToConstantStoragePointer):
        (JSC::DFG::Node::convertToPutStack):
        (JSC::DFG::Node::convertToGetStack):
        (JSC::DFG::Node::convertToGetByOffset):
        (JSC::DFG::Node::convertToMultiGetByOffset):
        (JSC::DFG::Node::convertToPutByOffset):
        (JSC::DFG::Node::convertToMultiPutByOffset):
        (JSC::DFG::Node::convertToPhantomNewObject):
        (JSC::DFG::Node::convertToPhantomNewFunction):
        (JSC::DFG::Node::convertToPhantomNewGeneratorFunction):
        (JSC::DFG::Node::convertToPhantomCreateActivation):
        (JSC::DFG::Node::convertToGetLocal):
        (JSC::DFG::Node::lazyJSValue):
        (JSC::DFG::Node::initializationValueForActivation):
        (JSC::DFG::Node::tryGetVariableAccessData):
        (JSC::DFG::Node::variableAccessData):
        (JSC::DFG::Node::unlinkedLocal):
        (JSC::DFG::Node::unlinkedMachineLocal):
        (JSC::DFG::Node::stackAccessData):
        (JSC::DFG::Node::phi):
        (JSC::DFG::Node::identifierNumber):
        (JSC::DFG::Node::getPutInfo):
        (JSC::DFG::Node::accessorAttributes):
        (JSC::DFG::Node::newArrayBufferData):
        (JSC::DFG::Node::indexingType):
        (JSC::DFG::Node::typedArrayType):
        (JSC::DFG::Node::inlineCapacity):
        (JSC::DFG::Node::scopeOffset):
        (JSC::DFG::Node::capturedArgumentsOffset):
        (JSC::DFG::Node::variablePointer):
        (JSC::DFG::Node::callVarargsData):
        (JSC::DFG::Node::loadVarargsData):
        (JSC::DFG::Node::targetBytecodeOffsetDuringParsing):
        (JSC::DFG::Node::targetBlock):
        (JSC::DFG::Node::branchData):
        (JSC::DFG::Node::switchData):
        (JSC::DFG::Node::getHeapPrediction):
        (JSC::DFG::Node::cellOperand):
        (JSC::DFG::Node::watchpointSet):
        (JSC::DFG::Node::storagePointer):
        (JSC::DFG::Node::uidOperand):
        (JSC::DFG::Node::typeInfoOperand):
        (JSC::DFG::Node::transition):
        (JSC::DFG::Node::structureSet):
        (JSC::DFG::Node::structure):
        (JSC::DFG::Node::storageAccessData):
        (JSC::DFG::Node::multiGetByOffsetData):
        (JSC::DFG::Node::multiPutByOffsetData):
        (JSC::DFG::Node::objectMaterializationData):
        (JSC::DFG::Node::arrayMode):
        (JSC::DFG::Node::arithMode):
        (JSC::DFG::Node::arithRoundingMode):
        (JSC::DFG::Node::setArithRoundingMode):
        (JSC::DFG::Node::executionCounter):
        (JSC::DFG::Node::typeLocation):
        (JSC::DFG::Node::basicBlockLocation):
        (JSC::DFG::Node::numberOfArgumentsToSkip):
        (JSC::DFG::Node::OpInfoWrapper::OpInfoWrapper):
        (JSC::DFG::Node::OpInfoWrapper::operator=):
        * dfg/DFGOpInfo.h:
        (JSC::DFG::OpInfo::OpInfo):
        * dfg/DFGPromotedHeapLocation.h:
        (JSC::DFG::PromotedLocationDescriptor::imm1):
        (JSC::DFG::PromotedLocationDescriptor::imm2):

2016-08-27  Don Olmstead  <don.olmstead@am.sony.com>

        Unused cxxabi.h include in JSGlobalObjectInspectorController.cpp
        https://bugs.webkit.org/show_bug.cgi?id=161120

        Reviewed by Darin Adler.

        * inspector/JSGlobalObjectInspectorController.cpp:

2016-08-26  Sam Weinig  <sam@webkit.org>

        Remove support for ENABLE_LEGACY_WEB_AUDIO
        https://bugs.webkit.org/show_bug.cgi?id=161262

        Reviewed by Anders Carlsson.

        * Configurations/FeatureDefines.xcconfig:
        Remove ENABLE_LEGACY_WEB_AUDIO

2016-08-26  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Implement CompareStrictEq(String, Untyped) in FTL
        https://bugs.webkit.org/show_bug.cgi?id=161229

        Reviewed by Geoffrey Garen.

        Add (String, Untyped) uses to FTL CompareStrictEq.
        This was the last use type not implemented, the node is fully
        supported by FTL after this patch.

        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
        (JSC::FTL::DFG::LowerDFGToB3::compileStringToUntypedStrictEquality):

        (JSC::FTL::DFG::LowerDFGToB3::nonSpeculativeCompare):
        Remove the type checks when possible.

2016-08-26  Johan K. Jensen  <johan_jensen@apple.com>

        Web Inspector: Frontend should have access to Resource Timing information
        https://bugs.webkit.org/show_bug.cgi?id=160095

        Reviewed by Alex Christensen.

        Rename ResourceTiming property.

        * inspector/protocol/Network.json:
        Rename navigationStart to startTime so it's applicable
        for all resources and not just the main resource.

2016-08-25  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Provide a way to clear an IndexedDB object store
        https://bugs.webkit.org/show_bug.cgi?id=161167
        <rdar://problem/27996932>

        Reviewed by Brian Burg.

        * inspector/protocol/IndexedDB.json:
        Cleanup the protocol file.

2016-08-26  Devin Rousso  <dcrousso+webkit@gmail.com>

        Web Inspector: Some CSS selectors in the UI aren't escaped
        https://bugs.webkit.org/show_bug.cgi?id=151378

        Reviewed by Joseph Pecoraro.

        Change ElementData from sending a className string to using an array of
        classes, allowing for proper escaping of each class value.

        * inspector/protocol/OverlayTypes.json:

2016-08-26  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: ScriptProfilerAgent and HeapAgent should do less work when frontend disconnects
        https://bugs.webkit.org/show_bug.cgi?id=161213
        <rdar://problem/28017986>

        Reviewed by Brian Burg.

        * inspector/agents/InspectorHeapAgent.cpp:
        (Inspector::InspectorHeapAgent::willDestroyFrontendAndBackend):
        Don't take a final snapshot when disconnecting.

        * inspector/agents/InspectorScriptProfilerAgent.cpp:
        (Inspector::InspectorScriptProfilerAgent::willDestroyFrontendAndBackend):
        (Inspector::InspectorScriptProfilerAgent::stopSamplingWhenDisconnecting):
        * inspector/agents/InspectorScriptProfilerAgent.h:
        * runtime/SamplingProfiler.h:
        Don't process samples when disconnecting.

2016-08-26  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: HeapProfiler/ScriptProfiler do not destruct safely when JSContext is destroyed
        https://bugs.webkit.org/show_bug.cgi?id=161027
        <rdar://problem/27871349>

        Reviewed by Mark Lam.

        For JSContext inspection, when a frontend connects keep the target alive.
        This means ref'ing the JSGlobalObject / VM when the first frontend
        connects and deref'ing when the last frontend disconnects.

        * inspector/JSGlobalObjectInspectorController.h:
        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::globalObjectDestroyed):
        (Inspector::JSGlobalObjectInspectorController::disconnectAllFrontends): Deleted.
        Now that frontends keep the global object alive, when the global object
        is destroyed that must mean that no frontends exist. Remove the now
        stale code path.

        (Inspector::JSGlobalObjectInspectorController::connectFrontend):
        (Inspector::JSGlobalObjectInspectorController::disconnectFrontend):
        Ref the target when the first frontend connects, deref when the last disconnects.

2016-08-26  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] newPromiseCapabilities should check the given argument is constructor
        https://bugs.webkit.org/show_bug.cgi?id=161226

        Reviewed by Mark Lam.

        Use @isConstructor.

        * builtins/PromiseOperations.js:

2016-08-25  Keith Miller  <keith_miller@apple.com>

        toString called on proxies returns incorrect tag
        https://bugs.webkit.org/show_bug.cgi?id=161111

        Reviewed by Benjamin Poulain.

        This patch adds a new Method table function toStringName. This function
        is used by Object.prototype.toString to create the string tag that it
        inserts. Right now it only changes the stringification of proxy objects.
        In future patches I plan to make it work for other classes of objects as
        well.

        * runtime/ClassInfo.h:
        * runtime/JSCell.cpp:
        (JSC::JSCell::toStringName):
        * runtime/JSCell.h:
        * runtime/JSObject.cpp:
        (JSC::JSObject::toStringName):
        * runtime/JSObject.h:
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncToString):
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::toStringName):
        * runtime/ProxyObject.h:

2016-08-26  Csaba Osztrogonác  <ossy@webkit.org>

        Fix the ENABLE(WEBASSEMBLY) build on Linux
        https://bugs.webkit.org/show_bug.cgi?id=161197

        Reviewed by Mark Lam.

        * CMakeLists.txt:
        * b3/B3Common.cpp:
        (JSC::B3::shouldDumpIR):
        * shell/CMakeLists.txt:
        * wasm/JSWASMModule.h:
        * wasm/WASMB3IRGenerator.cpp:
        (JSC::WASM::toB3Op):
        * wasm/WASMB3IRGenerator.h:
        * wasm/WASMFormat.h:
        * wasm/WASMFunctionParser.h:
        * wasm/WASMModuleParser.cpp:
        (JSC::WASM::WASMModuleParser::parseFunctionTypes):
        * wasm/WASMModuleParser.h:
        * wasm/WASMParser.h:
        * wasm/WASMPlan.cpp:
        * wasm/WASMPlan.h:
        * wasm/WASMSections.cpp:

2016-08-26  Per Arne Vollan  <pvollan@apple.com>

        [Win] Compile fix.
        https://bugs.webkit.org/show_bug.cgi?id=161235

        Reviewed by Brent Fulgham.

        YarrPattern::errorMessage has inconsistent dll linkage.

        * yarr/YarrPattern.h:

2016-08-25  Alex Christensen  <achristensen@webkit.org>

        CMake build fix.

        * ForwardingHeaders/JavaScriptCore/JSObjectRefPrivate.h: Added.
        This is needed for the internal Windows build.

2016-08-25  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Clean up the abstract interpreter for cos/sin/sqrt/fround/log
        https://bugs.webkit.org/show_bug.cgi?id=161181

        Reviewed by Geoffrey Garen.

        All the nodes are doing the exact same thing with a single
        difference: how to process constants. I made that into a separate
        function called from each node.

        I also generalized the constant-to-number code of DoubleRep
        to make it available for all those nodes.

        * dfg/DFGAbstractInterpreter.h:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeDoubleUnaryOpEffects):
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::toNumberFromPrimitive):
        * runtime/JSCJSValue.h:

2016-08-25  Yusuke Suzuki  <utatane.tea@gmail.com>

        [DFG][FTL] Implement ES6 Generators in DFG / FTL
        https://bugs.webkit.org/show_bug.cgi?id=152723

        Reviewed by Filip Pizlo.

        This patch introduces DFG and FTL support for ES6 generators.
        ES6 generator is compiled by the BytecodeGenerator. But at the last phase, BytecodeGenerator performs "generatorification" onto the unlinked code.
        In BytecodeGenerator phase, we just emit op_yield for each yield point. And we don't emit any generator related switch, save, and resume sequences
        here. Those are emitted by the generatorification phase.

        So the graph is super simple! Before the generatorification, the graph looks like this.

             op_enter -> ...... -> op_yield -> ..... -> op_yield -> ...

        Roughly speaking, in the generatorification phase, we turn out which variables should be saved and resumed at each op_yield.
        This is done by liveness analysis. After that, we convert op_yield to the sequence of "op_put_to_scope", "op_ret", and "op_get_from_scope".
        op_put_to_scope and op_get_from_scope sequences are corresponding to the save and resume sequences. We set up the scope for the generator frame and
        perform op_put_to_scope and op_get_from_scope onto it. The live registers are saved and resumed over the generator's next() calls by using this
        special generator frame scope. And we also set up the global switch for the generator.

        In the generatorification phase,

        1. We construct the BytecodeGraph from the unlinked instructions. This constructs the basic blocks, and it is used in the subsequent analysis.
        2. We perform the analysis onto the unlinked code. We extract the live variables at each op_yield.
        3. We insert the get_from_scope and put_to_scope at each op_yield. Which registers should be saved and resumed is offered by (2).
           Then, clip the op_yield themselves. And we also insert the switch_imm. The jump targets of this switch are just after this op_switch_imm and each op_yield point.

        One interesting point is the try-range. We split the try-range at the op_yield point in BytecodeGenerator phase.
        This drops the hacky thing that is introduced in [1].
        If the try-range covers the resume sequences, the exception handler's use-registers are incorrectly transferred to the entry block.
        For example,

            handler uses r2
                                                             try-range
            label:(entry block can jump here)                 ^
                r1 = get_from_scope # resume sequence starts  | use r2 is transferred to the entry block!
                r2 = get_from_scope                           |
                starts usual sequences                        |
                ...                                           |

        Handler's r2 use should be considered at the `r1 = get_from_scope` point.
        Previously, we handle this edge case by treating op_resume specially in the liveness analysis[1].
        To drop this workaround, we split the try-range not to cover this resume sequence.

            handler uses r2
                                                             try-range
            label:(entry block can jump here)
                r1 = get_from_scope # resume sequence starts
                r2 = get_from_scope
                starts usual sequences                        ^ try-range should start from here.
                ...                                           |

        OK. Let's show the detailed example.

            1. First, there is the normal bytecode sequence. Here, | represents the offsets, and [] represents the bytecodes.

                bytecodes   | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] |
                try-range   <----------------------------------->

            2. When we emit the op_yield in the bytecode generator, we carefully split the try-range.

                bytecodes   | [ ] | [ ] | [op_yield] | [ ] | [ ] | [ ] |
                try-range   <----------->            <----------------->

            3. And in the generatorification phase, we insert the switch's jump target and save & resume sequences. And we also drop op_yield.

                        Insert save seq  Insert resume seq
                        before op_yield. after op_yield's point.
                                       v v
                bytecodes   | [ ] | [ ] | [op_yield] | [ ] | [ ] | [ ] |
                try-range   <----------->     ^      <----------------->
                                        ^     |
                             Jump to here.    Drop this op_yield.

            4. The final layout is the following.

                bytecodes   | [ ] | [ ][save seq][op_ret] | [resume seq] | [ ] | [ ] | [ ] |
                try-range   <----------------------------->               <---------------->
                                                          ^
                                              Jump to here.

        The rewriting done by the BytecodeRewriter is executed in a batch manner. Since these modification changes the basic blocks and size of unlinked instructions,
        BytecodeRewriter also performs the offset adjustment for UnlinkedCodeBlock. So, this rewriting is performed onto the BytecodeGraph rather than BytecodeBasicBlock.
        The reason why we take this design is simple: we don't want to newly create the basic blocks and opcodes for this early phase like DFG. Instead, we perform the
        modification and adjustment to the unlinked instructions and UnlinkedCodeBlock in a in-place manner.

        Bytecode rewriting functionality is offered by BytecodeRewriter. BytecodeRewriter allows us to insert any bytecodes to any places
        in a in-place manner. BytecodeRewriter handles the original bytecode offsets as labels. And you can insert bytecodes before and after
        these labels. You can also insert any jumps to any places. When you insert jumps, you need to specify jump target with this labels.
        These labels (original bytecode offsets) are automatically converted to the appropriate offsets by BytecodeRewriter.

        After that phase, the data flow of the generator-saved-and-resumed-registers are explicitly represented by the get_from_scope and put_to_scope.
        And the switch is inserted to represent the actual control flow for the generator. And op_yield is removed. Since we use the existing bytecodes (op_switch_imm, op_put_to_scope
        op_ret, and op_get_from_scope), DFG and FTL changes are not necessary. This patch also drops data structures and implementations for the old generator,
        op_resume, op_save implementations and GeneratorFrame.

        Note that this patch does not leverage the recent multi entrypoints support in B3. After this patch is introduced, we will submit a new patch that leverages the multi
        entrypoints for generator's resume and sees the performance gain.

        Microbenchmarks related to generators show up to 2.9x improvements.

                                                        Baseline                  Patched

            generator-fib                          102.0116+-3.2880     ^     34.9670+-0.2221        ^ definitely 2.9174x faster
            generator-sunspider-access-nsieve        5.8596+-0.0371     ^      4.9051+-0.0720        ^ definitely 1.1946x faster
            generator-with-several-types           332.1478+-4.2425     ^    124.6642+-2.4826        ^ definitely 2.6643x faster

            <geometric>                             58.2998+-0.7758     ^     27.7425+-0.2577        ^ definitely 2.1015x faster

        In ES6SampleBench's Basic, we can observe 41% improvement (Macbook Pro).

            Baseline:
                Geometric Mean Result: 133.55 ms +- 4.49 ms

                Benchmark    First Iteration        Worst 2%               Steady State
                Air          54.03 ms +- 7.51 ms    29.06 ms +- 3.13 ms    2276.59 ms +- 61.17 ms
                Basic        30.18 ms +- 1.86 ms    18.85 ms +- 0.45 ms    2851.16 ms +- 41.87 ms

            Patched:
                Geometric Mean Result: 121.78 ms +- 3.96 ms

                Benchmark    First Iteration        Worst 2%               Steady State
                Air          52.09 ms +- 6.89 ms    29.59 ms +- 3.16 ms    2239.90 ms +- 54.60 ms
                Basic        29.28 ms +- 1.46 ms    16.26 ms +- 0.66 ms    2025.15 ms +- 38.56 ms

        [1]: https://bugs.webkit.org/show_bug.cgi?id=159281

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/GeneratorPrototype.js:
        (globalPrivate.generatorResume):
        * bytecode/BytecodeBasicBlock.cpp:
        (JSC::BytecodeBasicBlock::shrinkToFit):
        (JSC::BytecodeBasicBlock::computeImpl):
        (JSC::BytecodeBasicBlock::compute):
        (JSC::isBranch): Deleted.
        (JSC::isUnconditionalBranch): Deleted.
        (JSC::isTerminal): Deleted.
        (JSC::isThrow): Deleted.
        (JSC::linkBlocks): Deleted.
        (JSC::computeBytecodeBasicBlocks): Deleted.
        * bytecode/BytecodeBasicBlock.h:
        (JSC::BytecodeBasicBlock::isEntryBlock):
        (JSC::BytecodeBasicBlock::isExitBlock):
        (JSC::BytecodeBasicBlock::leaderOffset):
        (JSC::BytecodeBasicBlock::totalLength):
        (JSC::BytecodeBasicBlock::offsets):
        (JSC::BytecodeBasicBlock::successors):
        (JSC::BytecodeBasicBlock::index):
        (JSC::BytecodeBasicBlock::addSuccessor):
        (JSC::BytecodeBasicBlock::BytecodeBasicBlock):
        (JSC::BytecodeBasicBlock::addLength):
        (JSC::BytecodeBasicBlock::leaderBytecodeOffset): Deleted.
        (JSC::BytecodeBasicBlock::totalBytecodeLength): Deleted.
        (JSC::BytecodeBasicBlock::bytecodeOffsets): Deleted.
        (JSC::BytecodeBasicBlock::addBytecodeLength): Deleted.
        * bytecode/BytecodeGeneratorification.cpp: Added.
        (JSC::BytecodeGeneratorification::BytecodeGeneratorification):
        (JSC::BytecodeGeneratorification::graph):
        (JSC::BytecodeGeneratorification::yields):
        (JSC::BytecodeGeneratorification::enterPoint):
        (JSC::BytecodeGeneratorification::storageForGeneratorLocal):
        (JSC::GeneratorLivenessAnalysis::GeneratorLivenessAnalysis):
        (JSC::GeneratorLivenessAnalysis::computeDefsForBytecodeOffset):
        (JSC::GeneratorLivenessAnalysis::computeUsesForBytecodeOffset):
        (JSC::GeneratorLivenessAnalysis::run):
        (JSC::BytecodeGeneratorification::run):
        (JSC::performGeneratorification):
        * bytecode/BytecodeGeneratorification.h: Copied from Source/JavaScriptCore/bytecode/BytecodeLivenessAnalysisInlines.h.
        * bytecode/BytecodeGraph.h: Added.
        (JSC::BytecodeGraph::codeBlock):
        (JSC::BytecodeGraph::instructions):
        (JSC::BytecodeGraph::basicBlocksInReverseOrder):
        (JSC::BytecodeGraph::blockContainsBytecodeOffset):
        (JSC::BytecodeGraph::findBasicBlockForBytecodeOffset):
        (JSC::BytecodeGraph::findBasicBlockWithLeaderOffset):
        (JSC::BytecodeGraph::size):
        (JSC::BytecodeGraph::at):
        (JSC::BytecodeGraph::operator[]):
        (JSC::BytecodeGraph::begin):
        (JSC::BytecodeGraph::end):
        (JSC::BytecodeGraph::first):
        (JSC::BytecodeGraph::last):
        (JSC::BytecodeGraph<Block>::BytecodeGraph):
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeLivenessAnalysis.cpp:
        (JSC::BytecodeLivenessAnalysis::BytecodeLivenessAnalysis):
        (JSC::BytecodeLivenessAnalysis::computeDefsForBytecodeOffset):
        (JSC::BytecodeLivenessAnalysis::computeUsesForBytecodeOffset):
        (JSC::BytecodeLivenessAnalysis::getLivenessInfoAtBytecodeOffset):
        (JSC::BytecodeLivenessAnalysis::computeFullLiveness):
        (JSC::BytecodeLivenessAnalysis::computeKills):
        (JSC::BytecodeLivenessAnalysis::dumpResults):
        (JSC::BytecodeLivenessAnalysis::compute):
        (JSC::isValidRegisterForLiveness): Deleted.
        (JSC::getLeaderOffsetForBasicBlock): Deleted.
        (JSC::findBasicBlockWithLeaderOffset): Deleted.
        (JSC::blockContainsBytecodeOffset): Deleted.
        (JSC::findBasicBlockForBytecodeOffset): Deleted.
        (JSC::stepOverInstruction): Deleted.
        (JSC::computeLocalLivenessForBytecodeOffset): Deleted.
        (JSC::computeLocalLivenessForBlock): Deleted.
        (JSC::BytecodeLivenessAnalysis::runLivenessFixpoint): Deleted.
        * bytecode/BytecodeLivenessAnalysis.h:
        * bytecode/BytecodeLivenessAnalysisInlines.h:
        (JSC::isValidRegisterForLiveness):
        (JSC::BytecodeLivenessPropagation<DerivedAnalysis>::stepOverInstruction):
        (JSC::BytecodeLivenessPropagation<DerivedAnalysis>::computeLocalLivenessForBytecodeOffset):
        (JSC::BytecodeLivenessPropagation<DerivedAnalysis>::computeLocalLivenessForBlock):
        (JSC::BytecodeLivenessPropagation<DerivedAnalysis>::getLivenessInfoAtBytecodeOffset):
        (JSC::BytecodeLivenessPropagation<DerivedAnalysis>::runLivenessFixpoint):
        * bytecode/BytecodeRewriter.cpp: Added.
        (JSC::BytecodeRewriter::applyModification):
        (JSC::BytecodeRewriter::execute):
        (JSC::BytecodeRewriter::adjustJumpTargetsInFragment):
        (JSC::BytecodeRewriter::insertImpl):
        (JSC::BytecodeRewriter::adjustJumpTarget):
        * bytecode/BytecodeRewriter.h: Added.
        (JSC::BytecodeRewriter::InsertionPoint::InsertionPoint):
        (JSC::BytecodeRewriter::InsertionPoint::operator<):
        (JSC::BytecodeRewriter::InsertionPoint::operator==):
        (JSC::BytecodeRewriter::Insertion::length):
        (JSC::BytecodeRewriter::Fragment::Fragment):
        (JSC::BytecodeRewriter::Fragment::appendInstruction):
        (JSC::BytecodeRewriter::BytecodeRewriter):
        (JSC::BytecodeRewriter::insertFragmentBefore):
        (JSC::BytecodeRewriter::insertFragmentAfter):
        (JSC::BytecodeRewriter::removeBytecode):
        (JSC::BytecodeRewriter::graph):
        (JSC::BytecodeRewriter::adjustAbsoluteOffset):
        (JSC::BytecodeRewriter::adjustJumpTarget):
        (JSC::BytecodeRewriter::calculateDifference):
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::handlerForIndex):
        (JSC::CodeBlock::shrinkToFit):
        (JSC::CodeBlock::valueProfileForBytecodeOffset):
        (JSC::CodeBlock::livenessAnalysisSlow):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::isConstantRegisterIndex):
        (JSC::CodeBlock::livenessAnalysis):
        (JSC::CodeBlock::liveCalleeLocalsAtYield): Deleted.
        * bytecode/HandlerInfo.h:
        (JSC::HandlerInfoBase::handlerForIndex):
        * bytecode/Opcode.h:
        (JSC::isBranch):
        (JSC::isUnconditionalBranch):
        (JSC::isTerminal):
        (JSC::isThrow):
        * bytecode/PreciseJumpTargets.cpp:
        (JSC::getJumpTargetsForBytecodeOffset):
        (JSC::computePreciseJumpTargetsInternal):
        (JSC::computePreciseJumpTargets):
        (JSC::recomputePreciseJumpTargets):
        (JSC::findJumpTargetsForBytecodeOffset):
        * bytecode/PreciseJumpTargets.h:
        * bytecode/PreciseJumpTargetsInlines.h: Added.
        (JSC::extractStoredJumpTargetsForBytecodeOffset):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::handlerForBytecodeOffset):
        (JSC::UnlinkedCodeBlock::handlerForIndex):
        (JSC::UnlinkedCodeBlock::applyModification):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedStringJumpTable::offsetForValue):
        (JSC::UnlinkedCodeBlock::numCalleeLocals):
        * bytecode/VirtualRegister.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitComplexPopScopes):
        (JSC::prepareJumpTableForStringSwitch):
        (JSC::BytecodeGenerator::emitYieldPoint):
        (JSC::BytecodeGenerator::emitSave): Deleted.
        (JSC::BytecodeGenerator::emitResume): Deleted.
        (JSC::BytecodeGenerator::emitGeneratorStateLabel): Deleted.
        (JSC::BytecodeGenerator::beginGenerator): Deleted.
        (JSC::BytecodeGenerator::endGenerator): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::generatorStateRegister):
        (JSC::BytecodeGenerator::generatorValueRegister):
        (JSC::BytecodeGenerator::generatorResumeModeRegister):
        (JSC::BytecodeGenerator::generatorFrameRegister):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::FunctionNode::emitBytecode):
        * dfg/DFGOperations.cpp:
        * interpreter/Interpreter.cpp:
        (JSC::findExceptionHandler):
        (JSC::GetCatchHandlerFunctor::operator()):
        (JSC::UnwindFunctor::operator()):
        * interpreter/Interpreter.h:
        * interpreter/InterpreterInlines.h: Copied from Source/JavaScriptCore/bytecode/PreciseJumpTargets.h.
        (JSC::Interpreter::getOpcodeID):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_save): Deleted.
        (JSC::JIT::emit_op_resume): Deleted.
        * llint/LowLevelInterpreter.asm:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseInner):
        (JSC::Parser<LexerType>::parseGeneratorFunctionSourceElements):
        (JSC::Parser<LexerType>::createGeneratorParameters):
        * parser/Parser.h:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL): Deleted.
        * runtime/CommonSlowPaths.h:
        * runtime/GeneratorFrame.cpp: Removed.
        (JSC::GeneratorFrame::GeneratorFrame): Deleted.
        (JSC::GeneratorFrame::finishCreation): Deleted.
        (JSC::GeneratorFrame::createStructure): Deleted.
        (JSC::GeneratorFrame::create): Deleted.
        (JSC::GeneratorFrame::save): Deleted.
        (JSC::GeneratorFrame::resume): Deleted.
        (JSC::GeneratorFrame::visitChildren): Deleted.
        * runtime/GeneratorFrame.h: Removed.
        (JSC::GeneratorFrame::locals): Deleted.
        (JSC::GeneratorFrame::localAt): Deleted.
        (JSC::GeneratorFrame::offsetOfLocals): Deleted.
        (JSC::GeneratorFrame::allocationSizeForLocals): Deleted.
        * runtime/JSGeneratorFunction.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2016-08-25  JF Bastien  <jfbastien@apple.com>

        TryGetById should have a ValueProfile so that it can predict its output type
        https://bugs.webkit.org/show_bug.cgi?id=160921

        Reviewed by Saam Barati.

        Add a ValueProfile to TryGetById, and make sure DFG picks it up.

        A microbenchmark for perfectly predicted computation shows a 20%
        runtime reduction with no hit if the prediction goes polymorphic.

        * bytecode/BytecodeList.json:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::finishCreation):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitTryGetById):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasHeapPrediction):
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_try_get_by_id):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_try_get_by_id):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:

2016-08-25  Csaba Osztrogonác  <ossy@webkit.org>

        generate-js-builtins.py should generate platform independent files
        https://bugs.webkit.org/show_bug.cgi?id=161196

        Reviewed by Mark Lam.

        * Scripts/generate-js-builtins.py: Files should be processed in fixed order.

2016-08-25  Caio Lima  <ticaiolima@gmail.com>

        NewRegexp should not prevent inlining
        https://bugs.webkit.org/show_bug.cgi?id=154808

        Reviewed by Geoffrey Garen.

        In this patch we are changing the current mechanism used to represent
        RegExp in NewRegexp nodes. We are changing the use of a index
        pointing to RegExp in
        CodeBlock->m_unlinkedCodeBlock->m_rareData->m_regexps as the operand of
        NewRegexp node to RegExp address as the operand. To make sure that RegExp* is
        pointing to a valid object, we are using m_graph.freezeStrong
        mechanism.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasCellOperand):
        (JSC::DFG::Node::hasRegexpIndex): Deleted.
        (JSC::DFG::Node::regexpIndex): Deleted.
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp):

2016-08-24  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Make FRound work with any type
        https://bugs.webkit.org/show_bug.cgi?id=161129

        Reviewed by Geoffrey Garen.

        Math.fround() does nothing with arguments past the first one
        (https://tc39.github.io/ecma262/#sec-math.fround).
        We can unify ArithFRound with the other single-input intrinsics.

        Everything else is same old: if the input type is not a number,
        be pessimistic about everything and do a C call.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithFRound):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileArithFRound):

2016-08-24  Andreas Kling  <akling@apple.com>

        Shrink DFG::OSRExit a bit.
        <https://webkit.org/b/161169>

        Reviewed by Geoffrey Garen.

        Rearrange the members of OSRExitBase and DFG::OSRExit to save 16 bytes per instance.

        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::OSRExit):
        * dfg/DFGOSRExit.h:
        * dfg/DFGOSRExitBase.h:
        (JSC::DFG::OSRExitBase::OSRExitBase):

2016-08-24  Ryan Haddad  <ryanhaddad@apple.com>

        Rebaseline builtins-generator-tests since r204854 was rolled out.

        Unreviewed test gardening.

        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
        * Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCoreJSBuiltins.h-result:

2016-08-24  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Move generic data structures out of B3
        https://bugs.webkit.org/show_bug.cgi?id=161155

        Reviewed by Saam Barati.

        Move B3's good generic data structures to WTF.
        They can be used for the other kind of basic blocks and nodes.
        For example, the generator patch[1] will make BytecodeBasicBlock usable with these structures.

        [1]: https://bugs.webkit.org/show_bug.cgi?id=152723

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3BasicBlockUtils.h:
        * b3/B3BlockWorklist.h:
        * b3/B3CFG.h:
        * b3/B3DuplicateTails.cpp:
        * b3/B3FixSSA.cpp:
        * b3/B3FixSSA.h:
        * b3/B3IndexMap.h:
        (JSC::B3::IndexMap::IndexMap): Deleted.
        (JSC::B3::IndexMap::resize): Deleted.
        (JSC::B3::IndexMap::clear): Deleted.
        (JSC::B3::IndexMap::size): Deleted.
        (JSC::B3::IndexMap::operator[]): Deleted.
        * b3/B3IndexSet.h:
        (JSC::B3::IndexSet::IndexSet): Deleted.
        (JSC::B3::IndexSet::add): Deleted.
        (JSC::B3::IndexSet::addAll): Deleted.
        (JSC::B3::IndexSet::remove): Deleted.
        (JSC::B3::IndexSet::contains): Deleted.
        (JSC::B3::IndexSet::size): Deleted.
        (JSC::B3::IndexSet::isEmpty): Deleted.
        (JSC::B3::IndexSet::Iterable::Iterable): Deleted.
        (JSC::B3::IndexSet::Iterable::iterator::iterator): Deleted.
        (JSC::B3::IndexSet::Iterable::iterator::operator*): Deleted.
        (JSC::B3::IndexSet::Iterable::iterator::operator++): Deleted.
        (JSC::B3::IndexSet::Iterable::iterator::operator==): Deleted.
        (JSC::B3::IndexSet::Iterable::iterator::operator!=): Deleted.
        (JSC::B3::IndexSet::Iterable::begin): Deleted.
        (JSC::B3::IndexSet::Iterable::end): Deleted.
        (JSC::B3::IndexSet::values): Deleted.
        (JSC::B3::IndexSet::indices): Deleted.
        (JSC::B3::IndexSet::dump): Deleted.
        * b3/B3LowerToAir.cpp:
        * b3/B3PhiChildren.h:
        * b3/B3Procedure.h:
        (JSC::B3::Procedure::iterator::iterator): Deleted.
        (JSC::B3::Procedure::iterator::operator*): Deleted.
        (JSC::B3::Procedure::iterator::operator++): Deleted.
        (JSC::B3::Procedure::iterator::operator==): Deleted.
        (JSC::B3::Procedure::iterator::operator!=): Deleted.
        (JSC::B3::Procedure::iterator::findNext): Deleted.
        * b3/B3ReduceDoubleToFloat.cpp:
        * b3/B3ReduceStrength.cpp:
        * b3/B3SSACalculator.h:
        * b3/B3UseCounts.h:
        * b3/air/AirCode.h:
        * b3/air/AirEliminateDeadCode.cpp:
        * b3/air/AirFixObviousSpills.cpp:
        * b3/air/AirFixPartialRegisterStalls.cpp:
        * b3/air/AirGenerate.cpp:
        * b3/air/AirGenerationContext.h:
        * b3/air/AirLiveness.h:
        * b3/air/AirSpillEverything.cpp:

2016-08-24  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, roll out r204901, r204897, r204866, r204856, r204854.

        * API/JSTypedArray.cpp:
        * API/ObjCCallbackFunction.mm:
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Scripts/builtins/builtins_generate_combined_implementation.py:
        (BuiltinsCombinedImplementationGenerator.generate_secondary_header_includes):
        * Scripts/builtins/builtins_generate_internals_wrapper_implementation.py:
        (BuiltinsInternalsWrapperImplementationGenerator.generate_secondary_header_includes):
        * Scripts/builtins/builtins_generate_separate_implementation.py:
        (BuiltinsSeparateImplementationGenerator.generate_secondary_header_includes):
        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::JumpList::link):
        (JSC::AbstractMacroAssembler::JumpList::linkTo):
        * assembler/MacroAssembler.h:
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::add32):
        * assembler/MacroAssemblerCodeRef.cpp: Removed.
        * assembler/MacroAssemblerCodeRef.h:
        (JSC::MacroAssemblerCodePtr::createLLIntCodePtr):
        (JSC::MacroAssemblerCodePtr::dumpWithName):
        (JSC::MacroAssemblerCodePtr::dump):
        (JSC::MacroAssemblerCodeRef::createLLIntCodeRef):
        (JSC::MacroAssemblerCodeRef::dump):
        * b3/B3BasicBlock.cpp:
        (JSC::B3::BasicBlock::appendBoolConstant): Deleted.
        * b3/B3BasicBlock.h:
        * b3/B3DuplicateTails.cpp:
        * b3/B3StackmapGenerationParams.h:
        * b3/testb3.cpp:
        (JSC::B3::run):
        (JSC::B3::testPatchpointTerminalReturnValue): Deleted.
        * bindings/ScriptValue.cpp:
        * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
        * bytecode/BytecodeBasicBlock.cpp:
        * bytecode/BytecodeLivenessAnalysis.cpp:
        * bytecode/BytecodeUseDef.h:
        * bytecode/CallLinkInfo.cpp:
        (JSC::CallLinkInfo::callTypeFor): Deleted.
        * bytecode/CallLinkInfo.h:
        (JSC::CallLinkInfo::callTypeFor):
        * bytecode/CallLinkStatus.cpp:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::clearLLIntGetByIdCache): Deleted.
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::jitCodeMap):
        (JSC::clearLLIntGetByIdCache):
        * bytecode/Instruction.h:
        * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
        * bytecode/ObjectAllocationProfile.h:
        (JSC::ObjectAllocationProfile::isNull):
        (JSC::ObjectAllocationProfile::initialize):
        * bytecode/Opcode.h:
        (JSC::padOpcodeName):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generateImpl):
        (JSC::PolymorphicAccess::regenerate):
        * bytecode/PolymorphicAccess.h:
        * bytecode/PreciseJumpTargets.cpp:
        * bytecode/StructureStubInfo.cpp:
        * bytecode/StructureStubInfo.h:
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::vm):
        * bytecode/UnlinkedCodeBlock.h:
        * bytecode/UnlinkedInstructionStream.cpp:
        * bytecode/UnlinkedInstructionStream.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
        (JSC::DFG::SpeculativeJIT::compileMakeRope):
        (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
        (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::emitAllocateJSCell):
        (JSC::DFG::SpeculativeJIT::emitAllocateJSObject):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLCompile.cpp:
        * ftl/FTLJITFinalizer.cpp:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateDirectArguments):
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateRest):
        (JSC::FTL::DFG::LowerDFGToB3::compileAllocateArrayWithSize):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize):
        (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
        (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
        (JSC::FTL::DFG::LowerDFGToB3::initializeArrayElements):
        (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorageWithSizeImpl):
        (JSC::FTL::DFG::LowerDFGToB3::allocateCell):
        (JSC::FTL::DFG::LowerDFGToB3::allocateObject):
        (JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedObject):
        (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
        (JSC::FTL::DFG::LowerDFGToB3::allocateArrayWithSize): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::allocateHeapCell): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::allocatorForSize): Deleted.
        * ftl/FTLOutput.cpp:
        (JSC::FTL::Output::constBool):
        (JSC::FTL::Output::add):
        (JSC::FTL::Output::shl):
        (JSC::FTL::Output::aShr):
        (JSC::FTL::Output::lShr):
        (JSC::FTL::Output::zeroExt):
        (JSC::FTL::Output::equal):
        (JSC::FTL::Output::notEqual):
        (JSC::FTL::Output::above):
        (JSC::FTL::Output::aboveOrEqual):
        (JSC::FTL::Output::below):
        (JSC::FTL::Output::belowOrEqual):
        (JSC::FTL::Output::greaterThan):
        (JSC::FTL::Output::greaterThanOrEqual):
        (JSC::FTL::Output::lessThan):
        (JSC::FTL::Output::lessThanOrEqual):
        (JSC::FTL::Output::select):
        (JSC::FTL::Output::addIncomingToPhi):
        (JSC::FTL::Output::appendSuccessor): Deleted.
        * ftl/FTLOutput.h:
        * ftl/FTLValueFromBlock.h:
        (JSC::FTL::ValueFromBlock::ValueFromBlock):
        (JSC::FTL::ValueFromBlock::operator bool): Deleted.
        * ftl/FTLWeightedTarget.h:
        (JSC::FTL::WeightedTarget::frequentedBlock): Deleted.
        * heap/CellContainer.h: Removed.
        * heap/CellContainerInlines.h: Removed.
        * heap/ConservativeRoots.cpp:
        (JSC::ConservativeRoots::ConservativeRoots):
        (JSC::ConservativeRoots::~ConservativeRoots):
        (JSC::ConservativeRoots::grow):
        (JSC::ConservativeRoots::genericAddPointer):
        (JSC::ConservativeRoots::genericAddSpan):
        * heap/ConservativeRoots.h:
        (JSC::ConservativeRoots::roots):
        * heap/CopyToken.h:
        * heap/FreeList.cpp: Removed.
        * heap/FreeList.h: Removed.
        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::lastChanceToFinalize):
        (JSC::Heap::finalizeUnconditionalFinalizers):
        (JSC::Heap::markRoots):
        (JSC::Heap::copyBackingStores):
        (JSC::Heap::gatherStackRoots):
        (JSC::Heap::gatherJSStackRoots):
        (JSC::Heap::gatherScratchBufferRoots):
        (JSC::Heap::clearLivenessData):
        (JSC::Heap::visitSmallStrings):
        (JSC::Heap::visitConservativeRoots):
        (JSC::Heap::removeDeadCompilerWorklistEntries):
        (JSC::Heap::gatherExtraHeapSnapshotData):
        (JSC::Heap::removeDeadHeapSnapshotNodes):
        (JSC::Heap::visitProtectedObjects):
        (JSC::Heap::visitArgumentBuffers):
        (JSC::Heap::visitException):
        (JSC::Heap::visitStrongHandles):
        (JSC::Heap::visitHandleStack):
        (JSC::Heap::visitSamplingProfiler):
        (JSC::Heap::traceCodeBlocksAndJITStubRoutines):
        (JSC::Heap::converge):
        (JSC::Heap::visitWeakHandles):
        (JSC::Heap::updateObjectCounts):
        (JSC::Heap::clearUnmarkedExecutables):
        (JSC::Heap::deleteUnmarkedCompiledCode):
        (JSC::Heap::collectAllGarbage):
        (JSC::Heap::collect):
        (JSC::Heap::collectImpl):
        (JSC::Heap::suspendCompilerThreads):
        (JSC::Heap::willStartCollection):
        (JSC::Heap::flushOldStructureIDTables):
        (JSC::Heap::flushWriteBarrierBuffer):
        (JSC::Heap::stopAllocation):
        (JSC::Heap::reapWeakHandles):
        (JSC::Heap::pruneStaleEntriesFromWeakGCMaps):
        (JSC::Heap::sweepArrayBuffers):
        (JSC::Heap::snapshotMarkedSpace):
        (JSC::Heap::deleteSourceProviderCaches):
        (JSC::Heap::notifyIncrementalSweeper):
        (JSC::Heap::writeBarrierCurrentlyExecutingCodeBlocks):
        (JSC::Heap::resetAllocators):
        (JSC::Heap::updateAllocationLimits):
        (JSC::Heap::didFinishCollection):
        (JSC::Heap::resumeCompilerThreads):
        (JSC::Zombify::visit):
        (JSC::Heap::collectWithoutAnySweep): Deleted.
        (JSC::Heap::prepareForMarking): Deleted.
        (JSC::Heap::forEachCodeBlockImpl): Deleted.
        * heap/Heap.h:
        (JSC::Heap::allocatorForObjectWithoutDestructor):
        (JSC::Heap::allocatorForObjectWithDestructor):
        (JSC::Heap::storageAllocator):
        (JSC::Heap::jitStubRoutines):
        (JSC::Heap::codeBlockSet):
        (JSC::Heap::allocatorForAuxiliaryData): Deleted.
        * heap/HeapCell.h:
        (JSC::HeapCell::isZapped):
        * heap/HeapCellInlines.h: Removed.
        * heap/HeapInlines.h:
        (JSC::Heap::heap):
        (JSC::Heap::isLive):
        (JSC::Heap::isMarked):
        (JSC::Heap::testAndSetMarked):
        (JSC::Heap::setMarked):
        (JSC::Heap::forEachCodeBlock):
        (JSC::Heap::allocateObjectOfType):
        (JSC::Heap::subspaceForObjectOfType):
        (JSC::Heap::allocatorForObjectOfType):
        (JSC::Heap::isPointerGCObject):
        (JSC::Heap::isValueGCObject):
        (JSC::Heap::cellSize): Deleted.
        (JSC::Heap::allocateAuxiliary): Deleted.
        (JSC::Heap::tryAllocateAuxiliary): Deleted.
        (JSC::Heap::tryReallocateAuxiliary): Deleted.
        * heap/HeapUtil.h: Removed.
        * heap/LargeAllocation.cpp: Removed.
        * heap/LargeAllocation.h: Removed.
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::retire):
        (JSC::MarkedAllocator::tryAllocateHelper):
        (JSC::MarkedAllocator::tryPopFreeList):
        (JSC::MarkedAllocator::tryAllocate):
        (JSC::MarkedAllocator::allocateSlowCase):
        (JSC::MarkedAllocator::allocateBlock):
        (JSC::MarkedAllocator::addBlock):
        (JSC::MarkedAllocator::removeBlock):
        (JSC::MarkedAllocator::reset):
        (JSC::MarkedAllocator::MarkedAllocator): Deleted.
        (JSC::MarkedAllocator::tryAllocateWithoutCollectingImpl): Deleted.
        (JSC::MarkedAllocator::tryAllocateWithoutCollecting): Deleted.
        (JSC::MarkedAllocator::tryAllocateSlowCase): Deleted.
        (JSC::MarkedAllocator::allocateSlowCaseImpl): Deleted.
        (JSC::blockHeaderSize): Deleted.
        (JSC::MarkedAllocator::blockSizeForBytes): Deleted.
        (JSC::MarkedAllocator::tryAllocateBlock): Deleted.
        (JSC::MarkedAllocator::setFreeList): Deleted.
        * heap/MarkedAllocator.h:
        (JSC::MarkedAllocator::offsetOfFreeListHead):
        (JSC::MarkedAllocator::MarkedAllocator):
        (JSC::MarkedAllocator::init):
        (JSC::MarkedAllocator::allocate):
        (JSC::MarkedAllocator::stopAllocating):
        (JSC::MarkedAllocator::offsetOfFreeList): Deleted.
        (JSC::MarkedAllocator::offsetOfCellSize): Deleted.
        (JSC::MarkedAllocator::tryAllocate): Deleted.
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::create):
        (JSC::MarkedBlock::MarkedBlock):
        (JSC::MarkedBlock::callDestructor):
        (JSC::MarkedBlock::specializedSweep):
        (JSC::MarkedBlock::sweep):
        (JSC::MarkedBlock::sweepHelper):
        (JSC::MarkedBlock::stopAllocating):
        (JSC::MarkedBlock::clearMarksWithCollectionType):
        (JSC::MarkedBlock::resumeAllocating):
        (JSC::MarkedBlock::didRetireBlock):
        (JSC::MarkedBlock::tryCreate): Deleted.
        (JSC::MarkedBlock::sweepHelperSelectScribbleMode): Deleted.
        (JSC::MarkedBlock::sweepHelperSelectStateAndSweepMode): Deleted.
        (JSC::MarkedBlock::forEachFreeCell): Deleted.
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::FreeList::FreeList):
        (JSC::MarkedBlock::isEmpty):
        (JSC::MarkedBlock::setHasAnyMarked): Deleted.
        (JSC::MarkedBlock::hasAnyMarked): Deleted.
        (JSC::MarkedBlock::clearHasAnyMarked): Deleted.
        (JSC::MarkedBlock::cellAlign): Deleted.
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::MarkedSpace):
        (JSC::MarkedSpace::lastChanceToFinalize):
        (JSC::MarkedSpace::sweep):
        (JSC::MarkedSpace::zombifySweep):
        (JSC::MarkedSpace::resetAllocators):
        (JSC::MarkedSpace::visitWeakSets):
        (JSC::MarkedSpace::reapWeakSets):
        (JSC::MarkedSpace::forEachAllocator):
        (JSC::MarkedSpace::stopAllocating):
        (JSC::MarkedSpace::resumeAllocating):
        (JSC::MarkedSpace::isPagedOut):
        (JSC::MarkedSpace::shrink):
        (JSC::MarkedSpace::clearNewlyAllocated):
        (JSC::MarkedSpace::clearMarks):
        (JSC::MarkedSpace::initializeSizeClassForStepSize): Deleted.
        (JSC::MarkedSpace::allocate): Deleted.
        (JSC::MarkedSpace::tryAllocate): Deleted.
        (JSC::MarkedSpace::allocateLarge): Deleted.
        (JSC::MarkedSpace::tryAllocateLarge): Deleted.
        (JSC::MarkedSpace::sweepLargeAllocations): Deleted.
        (JSC::MarkedSpace::prepareForMarking): Deleted.
        (JSC::MarkedSpace::objectCount): Deleted.
        (JSC::MarkedSpace::size): Deleted.
        (JSC::MarkedSpace::capacity): Deleted.
        * heap/MarkedSpace.h:
        (JSC::MarkedSpace::blocksWithNewObjects):
        (JSC::MarkedSpace::forEachLiveCell):
        (JSC::MarkedSpace::forEachDeadCell):
        (JSC::MarkedSpace::allocatorFor):
        (JSC::MarkedSpace::destructorAllocatorFor):
        (JSC::MarkedSpace::auxiliaryAllocatorFor):
        (JSC::MarkedSpace::allocateWithoutDestructor):
        (JSC::MarkedSpace::allocateWithDestructor):
        (JSC::MarkedSpace::allocateAuxiliary):
        (JSC::MarkedSpace::forEachBlock):
        (JSC::MarkedSpace::objectCount):
        (JSC::MarkedSpace::size):
        (JSC::MarkedSpace::capacity):
        (JSC::MarkedSpace::sizeClassToIndex): Deleted.
        (JSC::MarkedSpace::indexToSizeClass): Deleted.
        (JSC::MarkedSpace::largeAllocations): Deleted.
        (JSC::MarkedSpace::largeAllocationsNurseryOffset): Deleted.
        (JSC::MarkedSpace::largeAllocationsOffsetForThisCollection): Deleted.
        (JSC::MarkedSpace::largeAllocationsForThisCollectionBegin): Deleted.
        (JSC::MarkedSpace::largeAllocationsForThisCollectionEnd): Deleted.
        (JSC::MarkedSpace::largeAllocationsForThisCollectionSize): Deleted.
        (JSC::MarkedSpace::tryAllocateAuxiliary): Deleted.
        (JSC::MarkedSpace::forEachAllocator): Deleted.
        (JSC::MarkedSpace::optimalSizeFor): Deleted.
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::didStartMarking):
        (JSC::SlotVisitor::reset):
        (JSC::SlotVisitor::append):
        (JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
        (JSC::SlotVisitor::appendToMarkStack):
        (JSC::SlotVisitor::visitChildren):
        (JSC::SlotVisitor::appendJSCellOrAuxiliary): Deleted.
        (JSC::SlotVisitor::markAuxiliary): Deleted.
        (JSC::SlotVisitor::noteLiveAuxiliaryCell): Deleted.
        * heap/SlotVisitor.h:
        * heap/WeakBlock.cpp:
        (JSC::WeakBlock::create):
        (JSC::WeakBlock::WeakBlock):
        (JSC::WeakBlock::visit):
        (JSC::WeakBlock::reap):
        * heap/WeakBlock.h:
        (JSC::WeakBlock::disconnectMarkedBlock):
        (JSC::WeakBlock::disconnectContainer): Deleted.
        * heap/WeakSet.cpp:
        (JSC::WeakSet::sweep):
        (JSC::WeakSet::addAllocator):
        * heap/WeakSet.h:
        (JSC::WeakSet::WeakSet):
        * heap/WeakSetInlines.h:
        (JSC::WeakSet::allocate):
        * inspector/InjectedScriptManager.cpp:
        * inspector/JSGlobalObjectInspectorController.cpp:
        * inspector/JSJavaScriptCallFrame.cpp:
        * inspector/ScriptDebugServer.cpp:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        * interpreter/CachedCall.h:
        (JSC::CachedCall::CachedCall):
        * interpreter/Interpreter.cpp:
        (JSC::StackFrame::sourceID):
        (JSC::StackFrame::sourceURL):
        (JSC::StackFrame::functionName):
        (JSC::loadVarargs):
        (JSC::StackFrame::computeLineAndColumn):
        (JSC::StackFrame::toString):
        * interpreter/Interpreter.h:
        (JSC::StackFrame::isNative):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitAllocate):
        (JSC::AssemblyHelpers::emitAllocateJSCell):
        (JSC::AssemblyHelpers::emitAllocateJSObject):
        (JSC::AssemblyHelpers::emitAllocateJSObjectWithKnownSize):
        (JSC::AssemblyHelpers::emitAllocateVariableSized):
        (JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator): Deleted.
        * jit/GCAwareJITStubRoutine.cpp:
        (JSC::GCAwareJITStubRoutine::GCAwareJITStubRoutine):
        * jit/JIT.cpp:
        (JSC::JIT::compileCTINativeCall): Deleted.
        * jit/JIT.h:
        (JSC::JIT::compileCTINativeCall):
        * jit/JITExceptions.cpp:
        (JSC::genericUnwind): Deleted.
        * jit/JITExceptions.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_new_object):
        (JSC::JIT::emitSlow_op_new_object):
        (JSC::JIT::emit_op_create_this):
        (JSC::JIT::emitSlow_op_create_this):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_new_object):
        (JSC::JIT::emitSlow_op_new_object):
        (JSC::JIT::emit_op_create_this):
        (JSC::JIT::emitSlow_op_create_this):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitWriteBarrier):
        * jit/JITThunks.cpp:
        * jit/JITThunks.h:
        * jsc.cpp:
        (functionDescribeArray):
        (main):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LLIntExceptions.cpp:
        * llint/LLIntThunks.cpp:
        * llint/LLIntThunks.h:
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter.cpp:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * parser/ModuleAnalyzer.cpp:
        * parser/NodeConstructors.h:
        * parser/Nodes.h:
        * profiler/ProfilerBytecode.cpp:
        * profiler/ProfilerBytecode.h:
        * profiler/ProfilerBytecodeSequence.cpp:
        * runtime/ArrayConventions.h:
        (JSC::indexingHeaderForArray):
        (JSC::baseIndexingHeaderForArray):
        (JSC::indexingHeaderForArrayStorage): Deleted.
        (JSC::baseIndexingHeaderForArrayStorage): Deleted.
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncSplice):
        (JSC::concatAppendOne):
        (JSC::arrayProtoPrivateFuncConcatMemcpy):
        * runtime/ArrayStorage.h:
        (JSC::ArrayStorage::vectorLength):
        (JSC::ArrayStorage::sizeFor):
        (JSC::ArrayStorage::totalSizeFor): Deleted.
        (JSC::ArrayStorage::totalSize): Deleted.
        (JSC::ArrayStorage::availableVectorLength): Deleted.
        (JSC::ArrayStorage::optimalVectorLength): Deleted.
        * runtime/AuxiliaryBarrier.h: Removed.
        * runtime/AuxiliaryBarrierInlines.h: Removed.
        * runtime/Butterfly.h:
        * runtime/ButterflyInlines.h:
        (JSC::Butterfly::createUninitialized):
        (JSC::Butterfly::growArrayRight):
        (JSC::Butterfly::availableContiguousVectorLength): Deleted.
        (JSC::Butterfly::optimalContiguousVectorLength): Deleted.
        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::createEmpty):
        * runtime/CommonSlowPathsExceptions.cpp:
        * runtime/CommonSlowPathsExceptions.h:
        * runtime/DataView.cpp:
        * runtime/DirectArguments.h:
        * runtime/ECMAScriptSpecInternalFunctions.cpp:
        * runtime/Error.cpp:
        * runtime/Error.h:
        * runtime/ErrorInstance.cpp:
        * runtime/ErrorInstance.h:
        * runtime/Exception.cpp:
        * runtime/Exception.h:
        * runtime/GeneratorFrame.cpp:
        * runtime/GeneratorPrototype.cpp:
        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::InternalFunction):
        * runtime/IntlCollator.cpp:
        * runtime/IntlCollatorConstructor.cpp:
        * runtime/IntlCollatorPrototype.cpp:
        * runtime/IntlDateTimeFormat.cpp:
        * runtime/IntlDateTimeFormatConstructor.cpp:
        * runtime/IntlDateTimeFormatPrototype.cpp:
        * runtime/IntlNumberFormat.cpp:
        * runtime/IntlNumberFormatConstructor.cpp:
        * runtime/IntlNumberFormatPrototype.cpp:
        * runtime/IntlObject.cpp:
        * runtime/IteratorPrototype.cpp:
        * runtime/JSArray.cpp:
        (JSC::JSArray::setLengthWritable):
        (JSC::JSArray::unshiftCountSlowCase):
        (JSC::JSArray::setLengthWithArrayStorage):
        (JSC::JSArray::appendMemcpy):
        (JSC::JSArray::setLength):
        (JSC::JSArray::pop):
        (JSC::JSArray::push):
        (JSC::JSArray::fastSlice):
        (JSC::JSArray::shiftCountWithArrayStorage):
        (JSC::JSArray::shiftCountWithAnyIndexingType):
        (JSC::JSArray::unshiftCountWithArrayStorage):
        (JSC::JSArray::fillArgList):
        (JSC::JSArray::copyToArguments):
        (JSC::JSArray::tryCreateUninitialized): Deleted.
        * runtime/JSArray.h:
        (JSC::createContiguousArrayButterfly):
        (JSC::createArrayButterfly):
        (JSC::JSArray::create):
        (JSC::JSArray::tryCreateUninitialized):
        * runtime/JSArrayBufferView.h:
        * runtime/JSCInlines.h:
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::dumpInContextAssumingStructure):
        * runtime/JSCallee.cpp:
        (JSC::JSCallee::JSCallee):
        * runtime/JSCell.cpp:
        (JSC::JSCell::estimatedSize):
        * runtime/JSCell.h:
        (JSC::JSCell::cellStateOffset):
        * runtime/JSCellInlines.h:
        (JSC::JSCell::vm):
        (JSC::ExecState::vm):
        (JSC::JSCell::classInfo):
        (JSC::JSCell::callDestructor): Deleted.
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::create):
        (JSC::JSFunction::allocateAndInitializeRareData):
        (JSC::JSFunction::initializeRareData):
        (JSC::JSFunction::getOwnPropertySlot):
        (JSC::JSFunction::put):
        (JSC::JSFunction::deleteProperty):
        (JSC::JSFunction::defineOwnProperty):
        (JSC::JSFunction::setFunctionName):
        (JSC::JSFunction::reifyLength):
        (JSC::JSFunction::reifyName):
        (JSC::JSFunction::reifyLazyPropertyIfNeeded):
        (JSC::JSFunction::reifyBoundNameIfNeeded):
        * runtime/JSFunction.h:
        * runtime/JSFunctionInlines.h:
        (JSC::JSFunction::createWithInvalidatedReallocationWatchpoint):
        (JSC::JSFunction::JSFunction):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::slowDownAndWasteMemory):
        * runtime/JSInternalPromise.cpp:
        * runtime/JSInternalPromiseConstructor.cpp:
        * runtime/JSInternalPromiseDeferred.cpp:
        * runtime/JSInternalPromisePrototype.cpp:
        * runtime/JSJob.cpp:
        * runtime/JSMapIterator.cpp:
        * runtime/JSModuleNamespaceObject.cpp:
        * runtime/JSModuleRecord.cpp:
        * runtime/JSObject.cpp:
        (JSC::JSObject::copyButterfly):
        (JSC::JSObject::visitButterfly):
        (JSC::JSObject::copyBackingStore):
        (JSC::JSObject::notifyPresenceOfIndexedAccessors):
        (JSC::JSObject::createInitialIndexedStorage):
        (JSC::JSObject::createInitialUndecided):
        (JSC::JSObject::createInitialInt32):
        (JSC::JSObject::createInitialDouble):
        (JSC::JSObject::createInitialContiguous):
        (JSC::JSObject::createArrayStorage):
        (JSC::JSObject::createInitialArrayStorage):
        (JSC::JSObject::convertUndecidedToInt32):
        (JSC::JSObject::convertUndecidedToContiguous):
        (JSC::JSObject::convertUndecidedToArrayStorage):
        (JSC::JSObject::convertInt32ToDouble):
        (JSC::JSObject::convertInt32ToArrayStorage):
        (JSC::JSObject::convertDoubleToArrayStorage):
        (JSC::JSObject::convertContiguousToArrayStorage):
        (JSC::JSObject::putByIndexBeyondVectorLength):
        (JSC::JSObject::putDirectIndexBeyondVectorLength):
        (JSC::JSObject::getNewVectorLength):
        (JSC::JSObject::increaseVectorLength):
        (JSC::JSObject::ensureLengthSlow):
        (JSC::JSObject::growOutOfLineStorage):
        * runtime/JSObject.h:
        (JSC::JSObject::putDirectInternal):
        (JSC::JSObject::setStructureAndReallocateStorageIfNecessary):
        (JSC::JSObject::globalObject): Deleted.
        * runtime/JSObjectInlines.h:
        * runtime/JSPromise.cpp:
        * runtime/JSPromiseConstructor.cpp:
        * runtime/JSPromiseDeferred.cpp:
        * runtime/JSPromisePrototype.cpp:
        * runtime/JSPropertyNameIterator.cpp:
        * runtime/JSScope.cpp:
        (JSC::JSScope::resolve):
        * runtime/JSScope.h:
        (JSC::JSScope::vm):
        (JSC::JSScope::globalObject): Deleted.
        * runtime/JSSetIterator.cpp:
        * runtime/JSStringIterator.cpp:
        * runtime/JSTemplateRegistryKey.cpp:
        * runtime/JSTypedArrayViewConstructor.cpp:
        * runtime/JSTypedArrayViewPrototype.cpp:
        * runtime/JSWeakMap.cpp:
        * runtime/JSWeakSet.cpp:
        * runtime/MapConstructor.cpp:
        * runtime/MapIteratorPrototype.cpp:
        * runtime/MapPrototype.cpp:
        * runtime/NativeErrorConstructor.cpp:
        * runtime/NativeStdFunctionCell.cpp:
        * runtime/Operations.h:
        (JSC::scribbleFreeCells): Deleted.
        (JSC::scribble): Deleted.
        * runtime/Options.h:
        * runtime/PropertyTable.cpp:
        * runtime/ProxyConstructor.cpp:
        * runtime/ProxyObject.cpp:
        * runtime/ProxyRevoke.cpp:
        * runtime/RegExp.cpp:
        (JSC::RegExp::match):
        (JSC::RegExp::matchConcurrently):
        (JSC::RegExp::matchCompareWithInterpreter):
        * runtime/RegExp.h:
        * runtime/RegExpConstructor.h:
        * runtime/RegExpInlines.h:
        (JSC::RegExp::matchInline):
        * runtime/RegExpMatchesArray.h:
        (JSC::tryCreateUninitializedRegExpMatchesArray):
        (JSC::createRegExpMatchesArray):
        * runtime/RegExpPrototype.cpp:
        (JSC::genericSplit):
        * runtime/RuntimeType.cpp:
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::processUnverifiedStackTraces):
        * runtime/SetConstructor.cpp:
        * runtime/SetIteratorPrototype.cpp:
        * runtime/SetPrototype.cpp:
        * runtime/StackFrame.cpp: Removed.
        * runtime/StackFrame.h: Removed.
        * runtime/StringConstructor.cpp:
        * runtime/StringIteratorPrototype.cpp:
        * runtime/TemplateRegistry.cpp:
        * runtime/TestRunnerUtils.cpp:
        (JSC::finalizeStatsAtEndOfTesting): Deleted.
        * runtime/TestRunnerUtils.h:
        * runtime/TypeProfilerLog.cpp:
        * runtime/TypeSet.cpp:
        * runtime/VM.cpp:
        (JSC::VM::ensureStackCapacityForCLoop): Deleted.
        (JSC::VM::isSafeToRecurseSoftCLoop): Deleted.
        * runtime/VM.h:
        * runtime/VMEntryScope.h:
        * runtime/VMInlines.h:
        (JSC::VM::ensureStackCapacityFor):
        (JSC::VM::isSafeToRecurseSoft):
        * runtime/WeakMapConstructor.cpp:
        * runtime/WeakMapData.cpp:
        * runtime/WeakMapPrototype.cpp:
        * runtime/WeakSetConstructor.cpp:
        * runtime/WeakSetPrototype.cpp:
        * testRegExp.cpp:
        (testOneRegExp):
        * tools/JSDollarVM.cpp:
        * tools/JSDollarVMPrototype.cpp:
        (JSC::JSDollarVMPrototype::isInObjectSpace):

2016-08-23  Filip Pizlo  <fpizlo@apple.com>

        js/regress/put-by-id-transition-with-indexing-header.html and svg/carto.net/window.svg fail in debug after r204854
        https://bugs.webkit.org/show_bug.cgi?id=161115

        Reviewed by Keith Miller.
        
        There were two small goofs.

        * bytecode/ObjectAllocationProfile.h:
        (JSC::ObjectAllocationProfile::isNull): The new policy is that the allocator can be null. So now the way you tell if the profile is null is by checking the structure.
        * jit/JITOperations.cpp: This was using DeferGC, which is now definitely wrong. It forces the GC to happen when the structure and butterfly are mismatched. It's better for the GC to happen before we put the butterfly in the object.

2016-08-24  Filip Pizlo  <fpizlo@apple.com>

        AssemblyHelpers::emitAllocateWithNonNullAllocator() crashes in the FTL on ARM64
        https://bugs.webkit.org/show_bug.cgi?id=161138
        rdar://problem/27985868

        Reviewed by Saam Barati.
        
        The FTL expects that this method can be used with scratch registers disallowed, but it
        uses addPtr(Addr, Reg).

        The solution is to only use addPtr(Addr, Reg) on x86.

        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator):

2016-08-24  Skachkov Oleksandr  <gskachkov@gmail.com>

        [ES2016] Allow assignment in for-in head in not-strict mode
        https://bugs.webkit.org/show_bug.cgi?id=160955

        Reviewed by Saam Barati.

        This patch allow make assignment in for..in head in not-strict mode, 
        according to the spec https://tc39.github.io/ecma262/#sec-initializers-in-forin-statement-heads

        * bytecompiler/NodesCodegen.cpp:
        (JSC::ForInNode::emitLoopHeader):
        (JSC::ForInNode::emitMultiLoopBytecode):
        * parser/Nodes.h:
        (JSC::ExpressionNode::isAssignResolveNode):
        (JSC::AssignResolveNode::identifier):
        (JSC::ExpressionNode::isResolveNode): Deleted.
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseForStatement):

2016-08-23  Saam Barati  <sbarati@apple.com>

        It should be easy to run ES6SampleBench from the jsc shell
        https://bugs.webkit.org/show_bug.cgi?id=161085

        Reviewed by Yusuke Suzuki.

        This patch adds a new function called `runString` to the shell.
        It takes in a string, and executes it in a new global object.
        Then, it returns the global object it executed the code in.
        This allows the code to stash some kind of a result on the global,
        and then have the caller of `runString` extract the result.

        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionRunString):

2016-08-23  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Make ArithLog works with any type
        https://bugs.webkit.org/show_bug.cgi?id=161110

        Reviewed by Geoffrey Garen.

        Same old: if the type is not a number, assume the worst in every
        phase and generate a fallback function call.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithLog):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileArithLog):

2016-08-23  Ryan Haddad  <ryanhaddad@apple.com>

        Rebaseline builtins-generator-tests after r204854.

        Unreviewed test gardening.

        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
        * Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCoreJSBuiltins.h-result:

2016-08-23  Keith Miller  <keith_miller@apple.com>

        %TypedArray%.prototype.slice needs to check that the source and destination have not been detached.
        https://bugs.webkit.org/show_bug.cgi?id=161031
        <rdar://problem/27937019>

        Reviewed by Geoffrey Garen.

        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::speciesConstruct):
        (JSC::genericTypedArrayViewProtoFuncSlice):

2016-08-23  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION(204854): ASan is unhappy
        https://bugs.webkit.org/show_bug.cgi?id=161109

        Reviewed by Geoffrey Garen.
        
        I messed up RegExpConstructor: it ends up being a callee and a large allocation.
        
        This fixes it to not be a large allocation.

        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::InternalFunction):
        * runtime/RegExp.cpp:
        (JSC::RegExp::match):
        (JSC::RegExp::matchConcurrently):
        (JSC::RegExp::matchCompareWithInterpreter):
        * runtime/RegExp.h:
        * runtime/RegExpConstructor.h:
        * runtime/RegExpInlines.h:
        (JSC::RegExp::matchInline):
        * runtime/RegExpPrototype.cpp:
        (JSC::genericSplit):
        * testRegExp.cpp:
        (testOneRegExp):

2016-08-23  Saam Barati  <sbarati@apple.com>

        strict mode eval should not fire the var injection watch point
        https://bugs.webkit.org/show_bug.cgi?id=161104

        Reviewed by Geoffrey Garen.

        Strict mode eval can't do any variable injections. It was
        an oversight that we fired the var injection watchpoint when
        the eval is in strict mode.

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):

2016-07-24  Filip Pizlo  <fpizlo@apple.com>

        Spilling of constant tmps should make it easier for the spill code optimizer to rematerialize the constant
        https://bugs.webkit.org/show_bug.cgi?id=160150
        
        Reviewed by Benjamin Poulain.
        
        When we spill in-place for admitsStack()==true, we prevent rematerialization if that
        argument doesn't also admit immediates (which it almost certainly won't do).  So, we
        prevent remat.
        
        This fixes the issue by avoiding in-place spilling for warm uses of constants. I don't
        know if this helps performance, but I do know that it make the codegen for
        bigswitch-indirect-symbol look a lot better. Prior to this change, the prolog would have
        a constant materialization for each symbol that function used, and then it would spill
        that constant. This removes all of that yucky code.
        
        This also changes how IRC detects constant Tmps. Previously we would say that a Tmp is a
        constant if the number of const defs was equal to the number of defs. But it's possible
        for each of the const defs to produce a different value. This is unlikely considering
        how B3->Air lowering works and how our SSA works - each def would have its own register.
        But, regardless, this picks a more precise way of detecting constants: the number of
        const defs must be 1 and the number of defs must be 1.
        
        * b3/air/AirIteratedRegisterCoalescing.cpp:
        
2016-08-23  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix CLoop build.
        
        This fixes the CLoop build while still ensuring that Interpreter.h is a project header.

        * llint/LowLevelInterpreter.cpp:
        * runtime/VM.cpp:
        (JSC::VM::ensureStackCapacityForCLoop):
        (JSC::VM::isSafeToRecurseSoftCLoop):
        * runtime/VM.h:
        * runtime/VMInlines.h:
        (JSC::VM::ensureStackCapacityFor):
        (JSC::VM::isSafeToRecurseSoft):

2016-08-22  Filip Pizlo  <fpizlo@apple.com>

        Butterflies should be allocated in Auxiliary MarkedSpace instead of CopiedSpace and we should rewrite as much of the GC as needed to make this not a regression
        https://bugs.webkit.org/show_bug.cgi?id=160125

        Reviewed by Geoffrey Garen.

        In order to make the GC concurrent (bug 149432), we would either need to enable concurrent
        copying or we would need to not copy. Concurrent copying carries a 1-2% throughput overhead
        from the barriers alone. Considering that MarkedSpace does a decent job of avoiding
        fragmentation, it's unlikely that it's worth paying 1-2% throughput for copying. So, we want
        to get rid of copied space. This change moves copied space's biggest client over to marked
        space.
        
        Moving butterflies to marked space means having them use the new Auxiliary HeapCell
        allocation path. This is a fairly mechanical change, but it caused performance regressions
        everywhere, so this change also fixes MarkedSpace's performance issues.
        
        At a high level the mechanical changes are:
        
        - We use AuxiliaryBarrier instead of CopyBarrier.
        
        - We use tryAllocateAuxiliary instead of tryAllocateStorage. I got rid of the silly
          CheckedBoolean stuff, since it's so much more trouble than it's worth.
        
        - The JITs have to emit inlined marked space allocations instead of inline copy space
          allocations.
        
        - Everyone has to get used to zeroing their butterflies after allocation instead of relying
          on them being pre-zeroed by the GC. Copied space would zero things for you, while marked
          space doesn't.
        
        That's about 1/3 of this change. But this led to performance problems, which I fixed with
        optimizations that amounted to a major MarkedSpace rewrite:
        
        - MarkedSpace always causes internal fragmentation for array allocations because the vector
          length we choose when we resize usually leads to a cell size that doesn't correspond to any
          size class. I got around this by making array allocations usually round up vectorLength to
          the maximum allowed by the size class that we would have allocated in. Also,
          ensureLengthSlow() and friends first make sure that the requested length can't just be
          fulfilled with the current allocation size. This safeguard means that not every array
          allocation has to do size class queries. For example, the fast path of new Array(length)
          never does any size class queries, under the assumption that (1) the speed gained from
          avoiding an ensureLengthSlow() call, which then just changes the vectorLength by doing the
          size class query, is too small to offset the speed lost by doing the query on every
          allocation and (2) new Array(length) is a pretty good hint that resizing is not very
          likely.
        
        - Size classes in MarkedSpace were way too precise, which led to external fragmentation. This
          changes MarkedSpace size classes to use a linear progression for very small sizes followed
          by a geometric progression that naturally transitions to a hyperbolic progression. We want
          hyperbolic sizes when we get close to blockSize: for example the largest size we want is
          payloadSize / 2 rounded down, to ensure we get exactly two cells with minimal slop. The
          next size down should be payloadSize / 3 rounded down, and so on. After the last precise
          size (80 bytes), we proceed using a geometric progression, but round up each size to
          minimize slop at the end of the block. This naturally causes the geometric progression to
          turn hyperbolic for large sizes. The size class configuration happens at VM start-up, so
          can be controlled with runtime options. I found that a base of 1.4 works pretty well.
        
        - Large allocations caused massive internal fragmentation, since the smallest large
          allocation had to use exactly blockSize, and the largest small allocation used
          blockSize / 2. The next size up - the first large allocation size to require two blocks -
          also had 50% internal fragmentation. This is because we required large allocations to be
          blockSize aligned, so that MarkedBlock::blockFor() would work. I decided to rewrite all of
          that. Cells no longer have to be owned by a MarkedBlock. They can now alternatively be
          owned by a LargeAllocation. These two things are abstracted as CellContainer. You know that
          a cell is owned by a LargeAllocation if the MarkedBlock::atomSize / 2 bit is set.
          Basically, large allocations are deliberately misaligned by 8 bytes. This actually works
          out great since (1) typed arrays won't use large allocations anyway since they have their
          own malloc fallback and (2) large array butterflies already have a 8 byte header, which
          means that the 8 byte base misalignment aligns the large array payload on a 16 byte
          boundary. I took extreme care to make sure that the isLargeAllocation bit checks are as
          rare as possible; for example, ExecState::vm() skips the check because we know that callees
          must be small allocations. It's also possible to use template tricks to do one check for
          cell container kind, and then invoke a function specialized for MarkedBlock or a function
          specialized for LargeAllocation. LargeAllocation includes stubs for all MarkedBlock methods
          that get used from functions that are template-specialized like this. That's mostly to
          speed up the GC marking code. Most other code can use CellContainer API or HeapCell API
          directly. That's another thing: HeapCell, the common base of JSCell and auxiliary
          allocations, is now smart enough to do a lot of things for you, like HeapCell::vm(),
          HeapCell::heap(), HeapCell::isLargeAllocation(), and HeapCell::cellContainer(). The size
          cutoff for large allocations is runtime-configurable, so long as you don't choose something
          so small that callees end up large. I found that 400 bytes is roughly optimal. This means
          that the MarkedBlock size classes end up being:
          
          16, 32, 48, 64, 80, 112, 160, 224, 320
          
          The next size class would have been 432, but that's above the 400 byte cutoff. All of this
          is configurable with --sizeClassProgression and --largeAllocationCutoff. You can see what
          size classes you end up with by doing --dumpSizeClasses=true.
        
        - Copied space uses 64KB blocks, while marked space used to use 16KB blocks. Allocating a lot
          of stuff in 16KB blocks is slower than allocating it in 64KB blocks. I got more speed from
          changing MarkedBlock::blockSize to 64KB. This would have been a space fail before, but now
          that we have LargeAllocation, it ends up being an overall win.
        
        - Even after all of that, copying butterflies was still faster because it allowed us to skip
          sweeping dead space. A good GC allocates over dead bytes without explicitly freeing them,
          so the GC pause is O(size of live), not O(size of live + dead). O(dead) is usually much
          larger than O(live), especially in an eden collection. Copying satisfies this premise while
          mark+sweep does not. So, I invented a new kind of allocator: bump'n'pop. Previously, our
          MarkedSpace allocator was a freelist pop. That's simple and easy to inline but requires
          that we walk the block to build a free list. This means walking dead space. The new
          allocator allows totally free MarkedBlocks to simply set up a bump-pointer arena instead.
          The allocator is a hybrid of bump-pointer and freelist pop. It tries bump first. The bump
          pointer always bumps by cellSize, so the result of filling a block with bumping looks as if
          we had used freelist popping to fill it. Additionally, each MarkedBlock now has a bit to
          quickly tell if the block is entirely free. This makes sweeping O(1) whenever a MarkedBlock
          is completely empty, which is the common case because of the generational hypothesis: the
          number of objects that survive an eden collection is a tiny fraction of the number of
          objects that had been allocated, and this fraction is so small that there are typically
          fewer than one survivors per MarkedBlock. This change was enough to make this change a net
          win over tip-of-tree.
        
        - FTL now shares the same allocation fast paths as everything else, which is great, because
          bump'n'pop has gnarly control flow. We don't really want B3 to have to think about that
          control flow, since it won't be able to improve the machine code we write ourselves. GC
          fast paths are best written in assembly. So, I've empowered B3 to have even better support
          for Patchpoint terminals. It's now totally fine for a Patchpoint terminal to be non-Void.
          So, the new FTL allocation fast paths are just Patchpoint terminals that call through to
          AssemblyHelpers::emitAllocate(). B3 still reasons about things like constant-folding the
          size class calculation and constant-hoisting the allocator. Also, I gave the FTL the
          ability to constant-fold some allocator logic (in case we first assume that we're doing a
          variable-length allocation but then realize that the length is known). I think it makes
          sense to have constant folding rules in FTL::Output, or whatever the B3 IR builder is,
          since this makes lowering easier (you can constant fold during lowering more easily) and it
          reduces the amount of malloc traffic. In the future, we could teach B3 how to better
          constant-fold this code. That would require allowing loads to be constant-folded, which is
          doable but hella tricky.
        
        All of this put together gives us neutral perf on JetStream, Speedometer, and PLT3. SunSpider
        sometimes gets penalized depending on how you run it. By comparison, the alternative approach
        of using a copy barrier would have cost us 1-2%. That's the real apples-to-apples comparison
        if your premise is that we should have a concurrent GC. After we finish removing copied
        space, we will be barrier-ready for concurrent GC: we already have a marking barrier and we
        simply won't need a copying barrier. This change gets us there for the purposes of our
        benchmarks, since the remaining clients of copied space are not very important. On the other
        hand, if we keep copying, then getting barrier-ready would mean adding back the copy barrier,
        which costs more perf.
        
        We might get bigger speed-ups once we remove CopiedSpace altogether. That requires moving
        typed arrays and a few other weird things over to Aux MarkedSpace.
        
        This also includes some header sanitization. The introduction of AuxiliaryBarrier, HeapCell,
        and CellContainer meant that I had to include those files from everywhere. Fortunately,
        just including JSCInlines.h (instead of manually including the files that includes) is
        usually enough. So, I made most of JSC's cpp files include JSCInlines.h, which is something
        that we were already basically doing. In places where JSCInlines.h would be too much, I just
        included HeapInlines.h. This got weird, because we previously included HeapInlines.h from
        JSObject.h. That's bad because it led to some circular dependencies, so I fixed it - but that
        meant having to manually include HeapInlines.h from the places that previously got it
        implicitly via JSObject.h. But that led to more problems for some reason: I started getting
        build errors because non-JSC files were having trouble including Opcode.h. That's just silly,
        since Opcode.h is meant to be an internal JSC header. So, I made it an internal header and
        made it impossible to include it from outside JSC. This was a lot of work, but it was
        necessary to get the patch to build on all ports. It's also a net win. There were many places
        in WebCore that were transitively including a *ton* of JSC headers just because of the
        JSObject.h->HeapInlines.h edge and a bunch of dependency edges that arose from some public
        (for WebCore) JSC headers needing Interpreter.h or Opcode.h for bad reasons.

        * API/JSTypedArray.cpp:
        * API/ObjCCallbackFunction.mm:
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Scripts/builtins/builtins_generate_combined_implementation.py:
        (BuiltinsCombinedImplementationGenerator.generate_secondary_header_includes):
        * Scripts/builtins/builtins_generate_internals_wrapper_implementation.py:
        (BuiltinsInternalsWrapperImplementationGenerator.generate_secondary_header_includes):
        * Scripts/builtins/builtins_generate_separate_implementation.py:
        (BuiltinsSeparateImplementationGenerator.generate_secondary_header_includes):
        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::JumpList::JumpList):
        (JSC::AbstractMacroAssembler::JumpList::link):
        (JSC::AbstractMacroAssembler::JumpList::linkTo):
        (JSC::AbstractMacroAssembler::JumpList::append):
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::add32):
        * b3/B3BasicBlock.cpp:
        (JSC::B3::BasicBlock::appendIntConstant):
        (JSC::B3::BasicBlock::appendBoolConstant):
        (JSC::B3::BasicBlock::clearSuccessors):
        * b3/B3BasicBlock.h:
        * b3/B3DuplicateTails.cpp:
        * b3/B3StackmapGenerationParams.h:
        * b3/testb3.cpp:
        (JSC::B3::testBranchBitAndImmFusion):
        (JSC::B3::testPatchpointTerminalReturnValue):
        (JSC::B3::zero):
        (JSC::B3::run):
        * bindings/ScriptValue.cpp:
        * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
        * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
        * bytecode/ObjectAllocationProfile.h:
        (JSC::ObjectAllocationProfile::initialize):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generateImpl):
        * bytecode/StructureStubInfo.cpp:
        * dfg/DFGOperations.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
        (JSC::DFG::SpeculativeJIT::compileMakeRope):
        (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
        (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::emitAllocateJSCell):
        (JSC::DFG::SpeculativeJIT::emitAllocateJSObject):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLCompile.cpp:
        * ftl/FTLJITFinalizer.cpp:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateDirectArguments):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize):
        (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
        (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
        (JSC::FTL::DFG::LowerDFGToB3::initializeArrayElements):
        (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorageWithSizeImpl):
        (JSC::FTL::DFG::LowerDFGToB3::emitRightShiftSnippet):
        (JSC::FTL::DFG::LowerDFGToB3::allocateHeapCell):
        (JSC::FTL::DFG::LowerDFGToB3::storeStructure):
        (JSC::FTL::DFG::LowerDFGToB3::allocateCell):
        (JSC::FTL::DFG::LowerDFGToB3::allocateObject):
        (JSC::FTL::DFG::LowerDFGToB3::allocatorForSize):
        (JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedObject):
        (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
        * ftl/FTLOutput.cpp:
        (JSC::FTL::Output::constBool):
        (JSC::FTL::Output::constInt32):
        (JSC::FTL::Output::add):
        (JSC::FTL::Output::shl):
        (JSC::FTL::Output::aShr):
        (JSC::FTL::Output::lShr):
        (JSC::FTL::Output::zeroExt):
        (JSC::FTL::Output::equal):
        (JSC::FTL::Output::notEqual):
        (JSC::FTL::Output::above):
        (JSC::FTL::Output::aboveOrEqual):
        (JSC::FTL::Output::below):
        (JSC::FTL::Output::belowOrEqual):
        (JSC::FTL::Output::greaterThan):
        (JSC::FTL::Output::greaterThanOrEqual):
        (JSC::FTL::Output::lessThan):
        (JSC::FTL::Output::lessThanOrEqual):
        (JSC::FTL::Output::select):
        (JSC::FTL::Output::unreachable):
        (JSC::FTL::Output::appendSuccessor):
        (JSC::FTL::Output::speculate):
        (JSC::FTL::Output::addIncomingToPhi):
        * ftl/FTLOutput.h:
        * ftl/FTLValueFromBlock.h:
        (JSC::FTL::ValueFromBlock::ValueFromBlock):
        (JSC::FTL::ValueFromBlock::operator bool):
        (JSC::FTL::ValueFromBlock::value):
        (JSC::FTL::ValueFromBlock::block):
        * ftl/FTLWeightedTarget.h:
        (JSC::FTL::WeightedTarget::target):
        (JSC::FTL::WeightedTarget::weight):
        (JSC::FTL::WeightedTarget::frequentedBlock):
        * heap/CellContainer.h: Added.
        (JSC::CellContainer::CellContainer):
        (JSC::CellContainer::operator bool):
        (JSC::CellContainer::isMarkedBlock):
        (JSC::CellContainer::isLargeAllocation):
        (JSC::CellContainer::markedBlock):
        (JSC::CellContainer::largeAllocation):
        * heap/CellContainerInlines.h: Added.
        (JSC::CellContainer::isMarkedOrRetired):
        (JSC::CellContainer::isMarked):
        (JSC::CellContainer::isMarkedOrNewlyAllocated):
        (JSC::CellContainer::setHasAnyMarked):
        (JSC::CellContainer::cellSize):
        (JSC::CellContainer::weakSet):
        * heap/ConservativeRoots.cpp:
        (JSC::ConservativeRoots::ConservativeRoots):
        (JSC::ConservativeRoots::~ConservativeRoots):
        (JSC::ConservativeRoots::grow):
        (JSC::ConservativeRoots::genericAddPointer):
        (JSC::ConservativeRoots::genericAddSpan):
        * heap/ConservativeRoots.h:
        (JSC::ConservativeRoots::size):
        (JSC::ConservativeRoots::roots):
        * heap/CopyToken.h:
        * heap/FreeList.cpp: Added.
        (JSC::FreeList::dump):
        * heap/FreeList.h: Added.
        (JSC::FreeList::FreeList):
        (JSC::FreeList::list):
        (JSC::FreeList::bump):
        (JSC::FreeList::operator==):
        (JSC::FreeList::operator!=):
        (JSC::FreeList::operator bool):
        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::finalizeUnconditionalFinalizers):
        (JSC::Heap::markRoots):
        (JSC::Heap::copyBackingStores):
        (JSC::Heap::gatherStackRoots):
        (JSC::Heap::gatherJSStackRoots):
        (JSC::Heap::gatherScratchBufferRoots):
        (JSC::Heap::clearLivenessData):
        (JSC::Heap::visitSmallStrings):
        (JSC::Heap::visitConservativeRoots):
        (JSC::Heap::removeDeadCompilerWorklistEntries):
        (JSC::Heap::gatherExtraHeapSnapshotData):
        (JSC::Heap::removeDeadHeapSnapshotNodes):
        (JSC::Heap::visitProtectedObjects):
        (JSC::Heap::visitArgumentBuffers):
        (JSC::Heap::visitException):
        (JSC::Heap::visitStrongHandles):
        (JSC::Heap::visitHandleStack):
        (JSC::Heap::visitSamplingProfiler):
        (JSC::Heap::traceCodeBlocksAndJITStubRoutines):
        (JSC::Heap::converge):
        (JSC::Heap::visitWeakHandles):
        (JSC::Heap::updateObjectCounts):
        (JSC::Heap::clearUnmarkedExecutables):
        (JSC::Heap::deleteUnmarkedCompiledCode):
        (JSC::Heap::collectAllGarbage):
        (JSC::Heap::collect):
        (JSC::Heap::collectWithoutAnySweep):
        (JSC::Heap::collectImpl):
        (JSC::Heap::suspendCompilerThreads):
        (JSC::Heap::willStartCollection):
        (JSC::Heap::flushOldStructureIDTables):
        (JSC::Heap::flushWriteBarrierBuffer):
        (JSC::Heap::stopAllocation):
        (JSC::Heap::reapWeakHandles):
        (JSC::Heap::pruneStaleEntriesFromWeakGCMaps):
        (JSC::Heap::sweepArrayBuffers):
        (JSC::Heap::snapshotMarkedSpace):
        (JSC::Heap::deleteSourceProviderCaches):
        (JSC::Heap::notifyIncrementalSweeper):
        (JSC::Heap::writeBarrierCurrentlyExecutingCodeBlocks):
        (JSC::Heap::resetAllocators):
        (JSC::Heap::updateAllocationLimits):
        (JSC::Heap::didFinishCollection):
        (JSC::Heap::resumeCompilerThreads):
        (JSC::Zombify::visit):
        * heap/Heap.h:
        (JSC::Heap::subspaceForObjectDestructor):
        (JSC::Heap::subspaceForAuxiliaryData):
        (JSC::Heap::allocatorForObjectWithoutDestructor):
        (JSC::Heap::allocatorForObjectWithDestructor):
        (JSC::Heap::allocatorForAuxiliaryData):
        (JSC::Heap::storageAllocator):
        * heap/HeapCell.h:
        (JSC::HeapCell::zap):
        (JSC::HeapCell::isZapped):
        * heap/HeapCellInlines.h: Added.
        (JSC::HeapCell::isLargeAllocation):
        (JSC::HeapCell::cellContainer):
        (JSC::HeapCell::markedBlock):
        (JSC::HeapCell::largeAllocation):
        (JSC::HeapCell::heap):
        (JSC::HeapCell::vm):
        (JSC::HeapCell::cellSize):
        (JSC::HeapCell::allocatorAttributes):
        (JSC::HeapCell::destructionMode):
        (JSC::HeapCell::cellKind):
        * heap/HeapInlines.h:
        (JSC::Heap::isCollecting):
        (JSC::Heap::heap):
        (JSC::Heap::isLive):
        (JSC::Heap::isMarked):
        (JSC::Heap::testAndSetMarked):
        (JSC::Heap::setMarked):
        (JSC::Heap::cellSize):
        (JSC::Heap::writeBarrier):
        (JSC::Heap::allocateWithoutDestructor):
        (JSC::Heap::allocateObjectOfType):
        (JSC::Heap::subspaceForObjectOfType):
        (JSC::Heap::allocatorForObjectOfType):
        (JSC::Heap::allocateAuxiliary):
        (JSC::Heap::tryAllocateAuxiliary):
        (JSC::Heap::tryReallocateAuxiliary):
        (JSC::Heap::tryAllocateStorage):
        (JSC::Heap::didFreeBlock):
        (JSC::Heap::isPointerGCObject): Deleted.
        (JSC::Heap::isValueGCObject): Deleted.
        * heap/HeapUtil.h: Added.
        (JSC::HeapUtil::findGCObjectPointersForMarking):
        (JSC::HeapUtil::isPointerGCObjectJSCell):
        (JSC::HeapUtil::isValueGCObject):
        * heap/LargeAllocation.cpp: Added.
        (JSC::LargeAllocation::tryCreate):
        (JSC::LargeAllocation::LargeAllocation):
        (JSC::LargeAllocation::lastChanceToFinalize):
        (JSC::LargeAllocation::shrink):
        (JSC::LargeAllocation::visitWeakSet):
        (JSC::LargeAllocation::reapWeakSet):
        (JSC::LargeAllocation::clearMarks):
        (JSC::LargeAllocation::clearMarksWithCollectionType):
        (JSC::LargeAllocation::isEmpty):
        (JSC::LargeAllocation::sweep):
        (JSC::LargeAllocation::destroy):
        (JSC::LargeAllocation::dump):
        * heap/LargeAllocation.h: Added.
        (JSC::LargeAllocation::fromCell):
        (JSC::LargeAllocation::cell):
        (JSC::LargeAllocation::isLargeAllocation):
        (JSC::LargeAllocation::heap):
        (JSC::LargeAllocation::vm):
        (JSC::LargeAllocation::weakSet):
        (JSC::LargeAllocation::clearNewlyAllocated):
        (JSC::LargeAllocation::isNewlyAllocated):
        (JSC::LargeAllocation::isMarked):
        (JSC::LargeAllocation::isMarkedOrNewlyAllocated):
        (JSC::LargeAllocation::isLive):
        (JSC::LargeAllocation::hasValidCell):
        (JSC::LargeAllocation::cellSize):
        (JSC::LargeAllocation::aboveLowerBound):
        (JSC::LargeAllocation::belowUpperBound):
        (JSC::LargeAllocation::contains):
        (JSC::LargeAllocation::attributes):
        (JSC::LargeAllocation::testAndSetMarked):
        (JSC::LargeAllocation::setMarked):
        (JSC::LargeAllocation::clearMarked):
        (JSC::LargeAllocation::setHasAnyMarked):
        (JSC::LargeAllocation::headerSize):
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::MarkedAllocator):
        (JSC::isListPagedOut):
        (JSC::MarkedAllocator::isPagedOut):
        (JSC::MarkedAllocator::retire):
        (JSC::MarkedAllocator::tryAllocateWithoutCollectingImpl):
        (JSC::MarkedAllocator::tryAllocateWithoutCollecting):
        (JSC::MarkedAllocator::allocateSlowCase):
        (JSC::MarkedAllocator::tryAllocateSlowCase):
        (JSC::MarkedAllocator::allocateSlowCaseImpl):
        (JSC::blockHeaderSize):
        (JSC::MarkedAllocator::blockSizeForBytes):
        (JSC::MarkedAllocator::tryAllocateBlock):
        (JSC::MarkedAllocator::addBlock):
        (JSC::MarkedAllocator::removeBlock):
        (JSC::MarkedAllocator::reset):
        (JSC::MarkedAllocator::lastChanceToFinalize):
        (JSC::MarkedAllocator::setFreeList):
        (JSC::MarkedAllocator::tryAllocateHelper): Deleted.
        (JSC::MarkedAllocator::tryPopFreeList): Deleted.
        (JSC::MarkedAllocator::tryAllocate): Deleted.
        (JSC::MarkedAllocator::allocateBlock): Deleted.
        * heap/MarkedAllocator.h:
        (JSC::MarkedAllocator::destruction):
        (JSC::MarkedAllocator::cellKind):
        (JSC::MarkedAllocator::heap):
        (JSC::MarkedAllocator::takeLastActiveBlock):
        (JSC::MarkedAllocator::offsetOfFreeList):
        (JSC::MarkedAllocator::offsetOfCellSize):
        (JSC::MarkedAllocator::tryAllocate):
        (JSC::MarkedAllocator::allocate):
        (JSC::MarkedAllocator::stopAllocating):
        (JSC::MarkedAllocator::resumeAllocating):
        (JSC::MarkedAllocator::offsetOfFreeListHead): Deleted.
        (JSC::MarkedAllocator::MarkedAllocator): Deleted.
        (JSC::MarkedAllocator::init): Deleted.
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::tryCreate):
        (JSC::MarkedBlock::MarkedBlock):
        (JSC::MarkedBlock::specializedSweep):
        (JSC::MarkedBlock::sweep):
        (JSC::MarkedBlock::sweepHelperSelectResetMode):
        (JSC::MarkedBlock::sweepHelperSelectStateAndSweepMode):
        (JSC::MarkedBlock::stopAllocating):
        (JSC::MarkedBlock::clearMarksWithCollectionType):
        (JSC::MarkedBlock::lastChanceToFinalize):
        (JSC::MarkedBlock::resumeAllocating):
        (JSC::MarkedBlock::didRetireBlock):
        (JSC::MarkedBlock::forEachFreeCell):
        (JSC::MarkedBlock::create): Deleted.
        (JSC::MarkedBlock::callDestructor): Deleted.
        (JSC::MarkedBlock::sweepHelper): Deleted.
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::VoidFunctor::returnValue):
        (JSC::MarkedBlock::setHasAnyMarked):
        (JSC::MarkedBlock::hasAnyMarked):
        (JSC::MarkedBlock::clearHasAnyMarked):
        (JSC::MarkedBlock::firstAtom):
        (JSC::MarkedBlock::isAtomAligned):
        (JSC::MarkedBlock::cellAlign):
        (JSC::MarkedBlock::blockFor):
        (JSC::MarkedBlock::isEmpty):
        (JSC::MarkedBlock::cellSize):
        (JSC::MarkedBlock::isMarkedOrRetired):
        (JSC::MarkedBlock::FreeList::FreeList): Deleted.
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::initializeSizeClassForStepSize):
        (JSC::MarkedSpace::MarkedSpace):
        (JSC::MarkedSpace::lastChanceToFinalize):
        (JSC::MarkedSpace::allocateLarge):
        (JSC::MarkedSpace::tryAllocateLarge):
        (JSC::MarkedSpace::sweep):
        (JSC::MarkedSpace::sweepABit):
        (JSC::MarkedSpace::sweepLargeAllocations):
        (JSC::MarkedSpace::zombifySweep):
        (JSC::MarkedSpace::resetAllocators):
        (JSC::MarkedSpace::visitWeakSets):
        (JSC::MarkedSpace::reapWeakSets):
        (JSC::MarkedSpace::stopAllocating):
        (JSC::MarkedSpace::resumeAllocating):
        (JSC::MarkedSpace::isPagedOut):
        (JSC::MarkedSpace::shrink):
        (JSC::MarkedSpace::clearNewlyAllocated):
        (JSC::MarkedSpace::clearMarks):
        (JSC::MarkedSpace::didFinishIterating):
        (JSC::MarkedSpace::objectCount):
        (JSC::MarkedSpace::size):
        (JSC::MarkedSpace::capacity):
        (JSC::MarkedSpace::forEachAllocator): Deleted.
        * heap/MarkedSpace.h:
        (JSC::MarkedSpace::sizeClassIndex):
        (JSC::MarkedSpace::subspaceForObjectsWithDestructor):
        (JSC::MarkedSpace::subspaceForObjectsWithoutDestructor):
        (JSC::MarkedSpace::subspaceForAuxiliaryData):
        (JSC::MarkedSpace::blocksWithNewObjects):
        (JSC::MarkedSpace::largeAllocations):
        (JSC::MarkedSpace::largeAllocationsNurseryOffset):
        (JSC::MarkedSpace::largeAllocationsOffsetForThisCollection):
        (JSC::MarkedSpace::largeAllocationsForThisCollectionBegin):
        (JSC::MarkedSpace::largeAllocationsForThisCollectionEnd):
        (JSC::MarkedSpace::largeAllocationsForThisCollectionSize):
        (JSC::MarkedSpace::forEachLiveCell):
        (JSC::MarkedSpace::forEachDeadCell):
        (JSC::MarkedSpace::allocatorFor):
        (JSC::MarkedSpace::destructorAllocatorFor):
        (JSC::MarkedSpace::auxiliaryAllocatorFor):
        (JSC::MarkedSpace::allocate):
        (JSC::MarkedSpace::tryAllocate):
        (JSC::MarkedSpace::allocateWithoutDestructor):
        (JSC::MarkedSpace::allocateWithDestructor):
        (JSC::MarkedSpace::allocateAuxiliary):
        (JSC::MarkedSpace::tryAllocateAuxiliary):
        (JSC::MarkedSpace::forEachBlock):
        (JSC::MarkedSpace::didAllocateInBlock):
        (JSC::MarkedSpace::forEachAllocator):
        (JSC::MarkedSpace::forEachSubspace):
        (JSC::MarkedSpace::optimalSizeFor):
        (JSC::MarkedSpace::objectCount): Deleted.
        (JSC::MarkedSpace::size): Deleted.
        (JSC::MarkedSpace::capacity): Deleted.
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::didStartMarking):
        (JSC::SlotVisitor::reset):
        (JSC::SlotVisitor::clearMarkStack):
        (JSC::SlotVisitor::append):
        (JSC::SlotVisitor::appendJSCellOrAuxiliary):
        (JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
        (JSC::SlotVisitor::appendToMarkStack):
        (JSC::SlotVisitor::markAuxiliary):
        (JSC::SlotVisitor::noteLiveAuxiliaryCell):
        (JSC::SetCurrentCellScope::SetCurrentCellScope):
        (JSC::SlotVisitor::visitChildren):
        * heap/SlotVisitor.h:
        * heap/WeakBlock.cpp:
        (JSC::WeakBlock::create):
        (JSC::WeakBlock::destroy):
        (JSC::WeakBlock::WeakBlock):
        (JSC::WeakBlock::visit):
        (JSC::WeakBlock::reap):
        * heap/WeakBlock.h:
        (JSC::WeakBlock::disconnectContainer):
        (JSC::WeakBlock::disconnectMarkedBlock): Deleted.
        * heap/WeakSet.cpp:
        (JSC::WeakSet::sweep):
        (JSC::WeakSet::addAllocator):
        * heap/WeakSet.h:
        (JSC::WeakSet::WeakSet):
        * heap/WeakSetInlines.h:
        (JSC::WeakSet::allocate):
        * inspector/InjectedScriptManager.cpp:
        * inspector/JSGlobalObjectInspectorController.cpp:
        * inspector/JSJavaScriptCallFrame.cpp:
        * inspector/ScriptDebugServer.cpp:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        * interpreter/CachedCall.h:
        (JSC::CachedCall::CachedCall):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitAllocate):
        (JSC::AssemblyHelpers::emitAllocateJSCell):
        (JSC::AssemblyHelpers::emitAllocateJSObject):
        (JSC::AssemblyHelpers::emitAllocateJSObjectWithKnownSize):
        (JSC::AssemblyHelpers::emitAllocateVariableSized):
        * 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):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitWriteBarrier):
        * jsc.cpp:
        (functionDescribeArray):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * parser/ModuleAnalyzer.cpp:
        * runtime/ArrayConventions.h:
        (JSC::indexIsSufficientlyBeyondLengthForSparseMap):
        (JSC::indexingHeaderForArrayStorage):
        (JSC::baseIndexingHeaderForArrayStorage):
        (JSC::indexingHeaderForArray): Deleted.
        (JSC::baseIndexingHeaderForArray): Deleted.
        * runtime/ArrayStorage.h:
        (JSC::ArrayStorage::length):
        (JSC::ArrayStorage::setLength):
        (JSC::ArrayStorage::vectorLength):
        (JSC::ArrayStorage::setVectorLength):
        (JSC::ArrayStorage::copyHeaderFromDuringGC):
        (JSC::ArrayStorage::sizeFor):
        (JSC::ArrayStorage::totalSizeFor):
        (JSC::ArrayStorage::totalSize):
        (JSC::ArrayStorage::availableVectorLength):
        (JSC::ArrayStorage::optimalVectorLength):
        * runtime/AuxiliaryBarrier.h: Added.
        (JSC::AuxiliaryBarrier::AuxiliaryBarrier):
        (JSC::AuxiliaryBarrier::clear):
        (JSC::AuxiliaryBarrier::get):
        (JSC::AuxiliaryBarrier::slot):
        (JSC::AuxiliaryBarrier::operator bool):
        (JSC::AuxiliaryBarrier::setWithoutBarrier):
        * runtime/AuxiliaryBarrierInlines.h: Added.
        (JSC::AuxiliaryBarrier<T>::AuxiliaryBarrier):
        (JSC::AuxiliaryBarrier<T>::set):
        * runtime/Butterfly.h:
        (JSC::Butterfly::fromBase):
        (JSC::Butterfly::fromPointer):
        * runtime/ButterflyInlines.h:
        (JSC::Butterfly::availableContiguousVectorLength):
        (JSC::Butterfly::optimalContiguousVectorLength):
        (JSC::Butterfly::createUninitialized):
        (JSC::Butterfly::growArrayRight):
        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::createEmpty):
        * runtime/DataView.cpp:
        * runtime/DirectArguments.h:
        * runtime/ECMAScriptSpecInternalFunctions.cpp:
        * runtime/GeneratorFrame.cpp:
        * runtime/GeneratorPrototype.cpp:
        * runtime/IntlCollator.cpp:
        * runtime/IntlCollatorConstructor.cpp:
        * runtime/IntlCollatorPrototype.cpp:
        * runtime/IntlDateTimeFormat.cpp:
        * runtime/IntlDateTimeFormatConstructor.cpp:
        * runtime/IntlDateTimeFormatPrototype.cpp:
        * runtime/IntlNumberFormat.cpp:
        * runtime/IntlNumberFormatConstructor.cpp:
        * runtime/IntlNumberFormatPrototype.cpp:
        * runtime/JSArray.cpp:
        (JSC::createArrayButterflyInDictionaryIndexingMode):
        (JSC::JSArray::tryCreateUninitialized):
        (JSC::JSArray::setLengthWritable):
        (JSC::JSArray::unshiftCountSlowCase):
        (JSC::JSArray::setLengthWithArrayStorage):
        (JSC::JSArray::appendMemcpy):
        (JSC::JSArray::setLength):
        (JSC::JSArray::pop):
        (JSC::JSArray::push):
        (JSC::JSArray::fastSlice):
        (JSC::JSArray::shiftCountWithArrayStorage):
        (JSC::JSArray::shiftCountWithAnyIndexingType):
        (JSC::JSArray::unshiftCountWithArrayStorage):
        (JSC::JSArray::fillArgList):
        (JSC::JSArray::copyToArguments):
        * runtime/JSArray.h:
        (JSC::createContiguousArrayButterfly):
        (JSC::createArrayButterfly):
        (JSC::JSArray::create):
        (JSC::JSArray::tryCreateUninitialized): Deleted.
        * runtime/JSArrayBufferView.h:
        * runtime/JSCInlines.h:
        * runtime/JSCJSValue.cpp:
        * runtime/JSCallee.cpp:
        * runtime/JSCell.cpp:
        (JSC::JSCell::estimatedSize):
        (JSC::JSCell::copyBackingStore):
        * runtime/JSCell.h:
        (JSC::JSCell::cellStateOffset):
        * runtime/JSCellInlines.h:
        (JSC::JSCell::visitChildren):
        (JSC::ExecState::vm):
        (JSC::JSCell::canUseFastGetOwnProperty):
        (JSC::JSCell::classInfo):
        (JSC::JSCell::toBoolean):
        (JSC::JSCell::pureToBoolean):
        (JSC::JSCell::callDestructor):
        (JSC::JSCell::vm): Deleted.
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::create):
        (JSC::JSFunction::allocateAndInitializeRareData):
        (JSC::JSFunction::initializeRareData):
        (JSC::JSFunction::getOwnPropertySlot):
        (JSC::JSFunction::put):
        (JSC::JSFunction::deleteProperty):
        (JSC::JSFunction::defineOwnProperty):
        (JSC::JSFunction::setFunctionName):
        (JSC::JSFunction::reifyLength):
        (JSC::JSFunction::reifyName):
        (JSC::JSFunction::reifyLazyPropertyIfNeeded):
        (JSC::JSFunction::reifyBoundNameIfNeeded):
        * runtime/JSFunction.h:
        * runtime/JSFunctionInlines.h:
        (JSC::JSFunction::createWithInvalidatedReallocationWatchpoint):
        (JSC::JSFunction::JSFunction):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::slowDownAndWasteMemory):
        * runtime/JSInternalPromise.cpp:
        * runtime/JSInternalPromiseConstructor.cpp:
        * runtime/JSInternalPromiseDeferred.cpp:
        * runtime/JSInternalPromisePrototype.cpp:
        * runtime/JSJob.cpp:
        * runtime/JSMapIterator.cpp:
        * runtime/JSModuleNamespaceObject.cpp:
        * runtime/JSModuleRecord.cpp:
        * runtime/JSObject.cpp:
        (JSC::getClassPropertyNames):
        (JSC::JSObject::visitButterfly):
        (JSC::JSObject::visitChildren):
        (JSC::JSObject::heapSnapshot):
        (JSC::JSObject::notifyPresenceOfIndexedAccessors):
        (JSC::JSObject::createInitialIndexedStorage):
        (JSC::JSObject::createInitialUndecided):
        (JSC::JSObject::createInitialInt32):
        (JSC::JSObject::createInitialDouble):
        (JSC::JSObject::createInitialContiguous):
        (JSC::JSObject::createArrayStorage):
        (JSC::JSObject::createInitialArrayStorage):
        (JSC::JSObject::convertUndecidedToInt32):
        (JSC::JSObject::convertUndecidedToContiguous):
        (JSC::JSObject::convertUndecidedToArrayStorage):
        (JSC::JSObject::convertInt32ToDouble):
        (JSC::JSObject::convertInt32ToArrayStorage):
        (JSC::JSObject::convertDoubleToArrayStorage):
        (JSC::JSObject::convertContiguousToArrayStorage):
        (JSC::JSObject::putByIndexBeyondVectorLength):
        (JSC::JSObject::putDirectIndexBeyondVectorLength):
        (JSC::JSObject::putDirectNativeFunctionWithoutTransition):
        (JSC::JSObject::getNewVectorLength):
        (JSC::JSObject::increaseVectorLength):
        (JSC::JSObject::ensureLengthSlow):
        (JSC::JSObject::growOutOfLineStorage):
        (JSC::JSObject::copyButterfly): Deleted.
        (JSC::JSObject::copyBackingStore): Deleted.
        * runtime/JSObject.h:
        (JSC::JSObject::initializeIndex):
        (JSC::JSObject::globalObject):
        (JSC::JSObject::putDirectInternal):
        (JSC::JSObject::putOwnDataProperty):
        (JSC::JSObject::setStructureAndReallocateStorageIfNecessary): Deleted.
        * runtime/JSObjectInlines.h:
        * runtime/JSPromise.cpp:
        * runtime/JSPromiseConstructor.cpp:
        * runtime/JSPromiseDeferred.cpp:
        * runtime/JSPromisePrototype.cpp:
        * runtime/JSPropertyNameIterator.cpp:
        * runtime/JSScope.cpp:
        (JSC::JSScope::resolve):
        * runtime/JSScope.h:
        (JSC::JSScope::globalObject):
        (JSC::Register::operator=):
        (JSC::JSScope::vm): Deleted.
        * runtime/JSSetIterator.cpp:
        * runtime/JSStringIterator.cpp:
        * runtime/JSTemplateRegistryKey.cpp:
        * runtime/JSTypedArrayViewConstructor.cpp:
        * runtime/JSTypedArrayViewPrototype.cpp:
        * runtime/JSWeakMap.cpp:
        * runtime/JSWeakSet.cpp:
        * runtime/MapConstructor.cpp:
        * runtime/MapPrototype.cpp:
        * runtime/NativeStdFunctionCell.cpp:
        * runtime/Operations.h:
        (JSC::jsAdd):
        (JSC::resetFreeCellsBadly):
        (JSC::resetBadly):
        * runtime/Options.h:
        * runtime/PropertyTable.cpp:
        * runtime/ProxyConstructor.cpp:
        * runtime/ProxyObject.cpp:
        * runtime/ProxyRevoke.cpp:
        * runtime/RegExpMatchesArray.h:
        (JSC::tryCreateUninitializedRegExpMatchesArray):
        (JSC::createRegExpMatchesArray):
        * runtime/RuntimeType.cpp:
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::processUnverifiedStackTraces):
        * runtime/SetConstructor.cpp:
        * runtime/SetPrototype.cpp:
        * runtime/TemplateRegistry.cpp:
        * runtime/TypeProfilerLog.cpp:
        * runtime/TypeSet.cpp:
        * runtime/WeakMapConstructor.cpp:
        * runtime/WeakMapData.cpp:
        * runtime/WeakMapPrototype.cpp:
        * runtime/WeakSetConstructor.cpp:
        * runtime/WeakSetPrototype.cpp:
        * tools/JSDollarVMPrototype.cpp:
        (JSC::JSDollarVMPrototype::isInObjectSpace):
        (JSC::JSDollarVMPrototype::isInStorageSpace):

2016-08-23  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Make Math.cos() and Math.sin() work with any argument type
        https://bugs.webkit.org/show_bug.cgi?id=161069

        Reviewed by Geoffrey Garen.

        Same as the ArithSqrt patch: add a generic path if the argument
        is not a number.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithCos):
        (JSC::DFG::SpeculativeJIT::compileArithSin):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileArithSin):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithCos):

2016-08-23  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Module namespace object's Symbol.iterator method should only accept module namespace objects
        https://bugs.webkit.org/show_bug.cgi?id=161097

        Reviewed by Keith Miller.

        * runtime/JSModuleNamespaceObject.cpp:
        (JSC::moduleNamespaceObjectSymbolIterator):

2016-08-22  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Modules' `export default function/class` should be declaration
        https://bugs.webkit.org/show_bug.cgi?id=160499

        Reviewed by Saam Barati.

        Previously, we parsed the following cases as FunctionExpression and ClassExpression.

            ```
            export default function () { }
            export default class { }
            ```

        But, as per ES6 spec, the above `function ...` and `class ...` parts should be parsed
        as function declaration and class declaration. This has big difference; the instantiation
        of the function declarations are done in the function prologue.

        In this patch, we correctly parse the above cases as declaration. To handle no-named
        declarations, we add a new flag, DeclarationDefaultContext. This indicates [Default]
        flag in the ES6 spec's BNF.

        Furthermore, this patch also fixes the following name related bugs.

        1. The bug related to "export default"'s function name. If the name is not provided (like the above case), the name of the function becomes
        "default", not "*default*". This is special handling in ES6 spec. We handle this in JSFunction's reifyName.

        2. `class Hello { hello hello() { } }` is accepted. We introduced FunctionRequirements::Unnamed and fix this bug.

        * parser/ModuleScopeData.h:
        (JSC::ModuleScopeData::exportBinding):
        Exported names are already guranteed uniqueness by m_exportedNames. Not necessary to use set here. Use vector instead.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFunctionInfo):
        If we pass FunctionRequirements::NoRequirements, we need to initialize functionInfo.name / classInfo.className
        with the default fallback name. For example, in the above `export default` case, we initialize it with `*default*`.

        (JSC::Parser<LexerType>::parseFunctionDeclaration):
        (JSC::Parser<LexerType>::parseClassDeclaration):
        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parseExportDeclaration):
        (JSC::Parser<LexerType>::parsePropertyMethod):
        (JSC::Parser<LexerType>::parseGetterSetter):
        (JSC::Parser<LexerType>::parseClassExpression):
        (JSC::Parser<LexerType>::parseFunctionExpression):
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        (JSC::Parser<LexerType>::parseArrowFunctionExpression):
        * parser/Parser.h:
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::reifyName):

2016-08-23  Saam Barati  <sbarati@apple.com>

        JIT::updateTopCallframe() in the baseline JIT should use PC instead of PC+1
        https://bugs.webkit.org/show_bug.cgi?id=158955

        Reviewed by Mark Lam.

        This will make the baseline JIT consistent with the rest of the tiers.

        * jit/JITInlines.h:
        (JSC::JIT::updateTopCallFrame):

2016-08-22  Per Arne Vollan  <pvollan@apple.com>

        [Win] Warning fix.
        https://bugs.webkit.org/show_bug.cgi?id=161043

        Reviewed by Mark Lam.

        Ignore warning about bit shift by too large amount.

        * jit/PCToCodeOriginMap.cpp:

2016-08-22  Keith Miller  <keith_miller@apple.com>

        Actually enable the WASM build.
        https://bugs.webkit.org/show_bug.cgi?id=160933

        Reviewed by Geoffrey Garen.

        Fix bug where we assumed that every frame would have a CodeBlock.

        * inspector/ScriptCallStackFactory.cpp:
        (Inspector::CreateScriptCallStackFunctor::operator()):

2016-08-22  Ryosuke Niwa  <rniwa@webkit.org>

        Rename CustomElementsRegistry to CustomElementRegistry
        https://bugs.webkit.org/show_bug.cgi?id=161028

        Reviewed by Darin Adler.

        Added customElements and CustomElementRegistry to the common identifiers list as they're used on JSDOMWindow
        to hide window.customElements and CustomElementRegistry interface behind a runtime flag.

        * runtime/CommonIdentifiers.h:

2016-08-22  Mark Lam  <mark.lam@apple.com>

        Remove dead code.
        https://bugs.webkit.org/show_bug.cgi?id=161049

        Reviewed by Michael Saboff.

        * runtime/VM.h:
        - Deleted unused friend class ClearExceptionScope.

2016-08-22  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Module should not allow HTML comments
        https://bugs.webkit.org/show_bug.cgi?id=161041

        Reviewed by Saam Barati.

        ES6 Modules intentionally disable HTML comments[1].

        [1]: https://tc39.github.io/ecma262/#sec-html-like-comments

        * API/JSScriptRef.cpp:
        (parseScript):
        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createExecutable):
        * bytecode/EvalCodeCache.h:
        (JSC::EvalCodeCache::CacheKey::CacheKey):
        * bytecode/ExecutableInfo.h:
        (JSC::ExecutableInfo::ExecutableInfo):
        (JSC::ExecutableInfo::commentMode):
        (JSC::ExecutableInfo::superBinding): Deleted.
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::commentMode):
        (JSC::UnlinkedCodeBlock::superBinding): Deleted.
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::generateUnlinkedFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::commentMode):
        (JSC::BytecodeGenerator::makeFunction):
        (JSC::BytecodeGenerator::superBinding): Deleted.
        * parser/Lexer.cpp:
        (JSC::Lexer<T>::Lexer):
        (JSC::Lexer<T>::lex):
        * parser/Lexer.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::Parser):
        * parser/Parser.h:
        (JSC::parse):
        * parser/ParserModes.h:
        * parser/SourceCodeKey.h:
        (JSC::SourceCodeFlags::SourceCodeFlags):
        (JSC::SourceCodeKey::SourceCodeKey):
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getProgramCodeBlock):
        (JSC::CodeCache::getEvalCodeBlock):
        (JSC::CodeCache::getModuleProgramCodeBlock):
        (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
        * runtime/CodeCache.h:
        * runtime/Completion.cpp:
        (JSC::checkSyntax):
        (JSC::checkModuleSyntax):
        * runtime/Executable.cpp:
        (JSC::ProgramExecutable::checkSyntax):
        * runtime/Executable.h:
        * runtime/ModuleLoaderPrototype.cpp:
        (JSC::moduleLoaderPrototypeParseModule):

2016-08-21  Yusuke Suzuki  <utatane.tea@gmail.com>

        [DFG] Should not fixup AnyIntUse in 32_64
        https://bugs.webkit.org/show_bug.cgi?id=161029

        Reviewed by Saam Barati.

        DFG fixup phase uses AnyIntUse even in 32bit DFG. This patch removes this incorrect filtering.
        If the 32bit DFG see the TypeAnyInt, it should fallback to the NumberUse case.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):

2016-08-21  Yusuke Suzuki  <utatane.tea@gmail.com>

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

        32bit is OK. DFGSpeculativeJIT64.cpp shortcut also need some cares.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):

2016-08-21  Yusuke Suzuki  <utatane.tea@gmail.com>

        [DFG] Should not fixup AnyIntUse in 32_64
        https://bugs.webkit.org/show_bug.cgi?id=161029

        Reviewed by Saam Barati.

        DFG fixup phase uses AnyIntUse even in 32bit DFG. This patch removes this incorrect filtering.
        If the 32bit DFG see the TypeAnyInt, it should fallback to the NumberUse case.

        And this patch also fixes the case that the type set only contains TypeNumber. Previously,
        we used NumberUse edge filtering. But it misses AnyInt logging: While the NumberUse filter
        passes both TypeAnyInt and TypeNumber, the type set only logged TypeNumber.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):

2016-08-20  Brian Burg  <bburg@apple.com>

        Remote Inspector: some methods don't need to be marked virtual anymore
        https://bugs.webkit.org/show_bug.cgi?id=161033

        Reviewed by Darin Adler.

        This probably happened when this code was last refactored and moved around.

        * inspector/remote/RemoteConnectionToTarget.h:

2016-08-19  Sam Weinig  <sam@webkit.org>

        Location.ancestorOrigins should return a FrozenArray<USVString>
        https://bugs.webkit.org/show_bug.cgi?id=161018

        Reviewed by Ryosuke Niwa and Chris Dumez.

        * runtime/ObjectConstructor.h:
        (JSC::objectConstructorFreeze):
        Export objectConstructorFreeze so it can be used to freeze DOM FrozenArrays.

2016-08-19  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] ArithSqrt should work with any argument type
        https://bugs.webkit.org/show_bug.cgi?id=160954

        Reviewed by Saam Barati.

        Previsouly, ArithSqrt would always OSR Exit if the argument
        is not typed Integer, Double, or Boolean.
        Since we can't recover by generalizing to those, we continuously
        OSR Exit and recompile the same code over and over again.

        This patch introduces a fallback to handle the remaining types.

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

        * dfg/DFGMayExit.cpp:
        This is somewhat unrelated. While discussing the design of this
        with Filip, we decided not to use ToNumber+ArithSqrt despite
        the guarantee that ToNumber does not OSR Exit.
        Since it does not OSR Exit, we should say so in mayExitImpl().

        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithSqrt):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileArithSqrt):

2016-08-19  Joseph Pecoraro  <pecoraro@apple.com>

        Make custom Error properties (line, column, sourceURL) configurable and writable
        https://bugs.webkit.org/show_bug.cgi?id=160984
        <rdar://problem/27905979>

        Reviewed by Saam Barati.

        * runtime/Error.cpp:
        (JSC::addErrorInfoAndGetBytecodeOffset):
        (JSC::addErrorInfo):

2016-08-19  Joseph Pecoraro  <pecoraro@apple.com>

        Remove empty files and empty namespace blocks
        https://bugs.webkit.org/show_bug.cgi?id=160990

        Reviewed by Alex Christensen.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/ValueProfile.cpp: Removed.
        * runtime/WatchdogMac.cpp: Removed.
        * runtime/WatchdogNone.cpp: Removed.

        * runtime/StringIteratorPrototype.cpp:
        Remove empty namespace block.

        * runtime/JSDestructibleObject.h:
        Drive-by add missing copyright.

2016-08-19  Per Arne Vollan  <pvollan@apple.com>

        [Win] Warning fix.
        https://bugs.webkit.org/show_bug.cgi?id=160995

        Avoid setting unknown compile option on source file.

        Reviewed by Anders Carlsson.

        * CMakeLists.txt:

2016-08-18  Mark Lam  <mark.lam@apple.com>

        ScopedArguments is using the wrong owner object for a write barrier.
        https://bugs.webkit.org/show_bug.cgi?id=160976
        <rdar://problem/27328506>

        Reviewed by Keith Miller.

        * runtime/ScopedArguments.h:
        (JSC::ScopedArguments::setIndexQuickly):

2016-08-18  Mark Lam  <mark.lam@apple.com>

        Add LLINT probe() macro for X86_64.
        https://bugs.webkit.org/show_bug.cgi?id=160968

        Reviewed by Geoffrey Garen.

        * llint/LowLevelInterpreter.asm:

2016-08-18  Mark Lam  <mark.lam@apple.com>

        Remove unused SlotVisitor::append() variant.
        https://bugs.webkit.org/show_bug.cgi?id=160961

        Reviewed by Saam Barati.

        * heap/SlotVisitor.h:
        * jit/JITWriteBarrier.h:
        (JSC::JITWriteBarrier::get):
        (JSC::SlotVisitor::append): Deleted.

2016-08-18  Saam Barati  <sbarati@apple.com>

        Make @Array(size) a bytecode intrinsic
        https://bugs.webkit.org/show_bug.cgi?id=160867

        Reviewed by Mark Lam.

        There were a few places in the code where we were emitting `@Array(size)`
        or `new @Array(size)`. Since we have a bytecode operation that already
        represents this, called new_array_with_size, it's faster to just make a
        bytecode intrinsic for the this operation. This patch does that and
        the intrinsic is called `@newArrayWithSize`. This might be around a
        1% speedup on ES6 sample bench, but it's within the noise. This is just
        a good bytecode operation to have because it's common enough to
        create arrays and it's good to make that fast in all tiers.

        * builtins/ArrayConstructor.js:
        (of):
        (from):
        * builtins/ArrayPrototype.js:
        (filter):
        (map):
        (sort.stringSort):
        (sort):
        (concatSlowPath):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_isObject):
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_newArrayWithSize):

2016-08-18  Rawinder Singh  <rawinder.singh-webkit@cisra.canon.com.au>

        [web-animations] Add Animatable, AnimationEffect, KeyframeEffect and Animation interface
        https://bugs.webkit.org/show_bug.cgi?id=156096

        Reviewed by Dean Jackson.

        Adds:
        - Animatable interface and implementation of getAnimations in Element.
        - Interface and implementation for Document getAnimations method.
        - AnimationEffect interface and class stub.
        - KeyframeEffect interface and constructor implementation.
        - 'Animation' interface, constructor and query methods for effect and timeline.
        - Remove runtime condition on Web animation interfaces (compile time flag is specified).

        * runtime/CommonIdentifiers.h:

2016-08-17  Keith Miller  <keith_miller@apple.com>

        Add WASM support for i64 simple opcodes.
        https://bugs.webkit.org/show_bug.cgi?id=160928

        Reviewed by Michael Saboff.

        This patch also removes the unsigned int32 mod operator, which is not supported by B3 yet.

        * wasm/WASMB3IRGenerator.cpp:
        (JSC::WASM::toB3Op):
        (JSC::WASM::B3IRGenerator::unaryOp):
        * wasm/WASMFunctionParser.h:
        (JSC::WASM::WASMFunctionParser<Context>::parseExpression):
        * wasm/WASMOps.h:

2016-08-17  JF Bastien  <jfbastien@apple.com>

        We allow assignments to const variables when in a for-in/for-of loop
        https://bugs.webkit.org/show_bug.cgi?id=156673

        Reviewed by Filip Pizlo.

        for-in and for-of weren't checking whether iteration variable from
        parent scopes were const. Assigning to such variables should
        throw, but used not to.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::ForInNode::emitLoopHeader):
        (JSC::ForOfNode::emitBytecode):

2016-08-17  Geoffrey Garen  <ggaren@apple.com>

        Fixed a potential bug in MarkedArgumentBuffer.
        https://bugs.webkit.org/show_bug.cgi?id=160948
        <rdar://problem/27889416>

        Reviewed by Oliver Hunt.

        I haven't been able to produce an observable test case after some trying.

        * runtime/ArgList.cpp:
        (JSC::MarkedArgumentBuffer::addMarkSet): New helper function -- I broke
        this out from existing code for clarity, but the behavior is the same.

        (JSC::MarkedArgumentBuffer::expandCapacity): Ditto.

        (JSC::MarkedArgumentBuffer::slowAppend): Always addMarkSet() on the slow
        path. This is faster than the old linear scan, and I think it might
        avoid cases the old scan could miss.

        * runtime/ArgList.h:
        (JSC::MarkedArgumentBuffer::append): Account for the case where someone
        has called clear() or removeLast().

        (JSC::MarkedArgumentBuffer::mallocBase): No behavior change -- but it's
        clearer to test the buffers directly instead of inferring what they
        might be based on capacity.

2016-08-17  Mark Lam  <mark.lam@apple.com>

        Remove an invalid assertion in the DFG backend's GetById emitter.
        https://bugs.webkit.org/show_bug.cgi?id=160925
        <rdar://problem/27248961>

        Reviewed by Filip Pizlo.

        The DFG backend's GetById assertion that the node's prediction not be SpecNone
        is just plain wrong.  It assumes that we can never have a GetById node without a
        type prediction, but this is not true.  The following test case proves otherwise:

            function foo() {
                "use strict";
                return --arguments["callee"];
            }

        Will remove the assertion.  Nothing else needs to change as the DFG is working
        correctly without the assertion.

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

2016-08-16  Mark Lam  <mark.lam@apple.com>

        Heap::collectAllGarbage() should work with JSC_useImmortalObjects=true.
        https://bugs.webkit.org/show_bug.cgi?id=160917

        Reviewed by Filip Pizlo.

        If we do an synchronous GC when JSC_useImmortalObjects=true, we'll get a
        RELEASE_ASSERT failure:

            $ JSC_useImmortalObjects=true jsc
            >>> gc()
            Trace/BPT trap: 5

        This is because Heap::collectAllGarbage() is doing an explicit sweep of the
        MarkedSpace, and the sweeper is expecting to see no RetiredBlocks.  However, we
        make objects immortal by retiring their blocks.  As a result, there is a mismatch
        in expectancy.

        The fix is simply to not run the sweeper when JSC_useImmortalObjects=true.

        * heap/Heap.cpp:
        (JSC::Heap::collectAllGarbage):

2016-08-16  Keith Miller  <keith_miller@apple.com>

        Add WASM I32 simple operators.
        https://bugs.webkit.org/show_bug.cgi?id=160914

        Reviewed by Benjamin Poulain.

        This patch adds support for the i32 simple binary operators.

        * wasm/WASMB3IRGenerator.cpp:
        (JSC::WASM::toB3Op):
        (JSC::WASM::B3IRGenerator::binaryOp):
        * wasm/WASMFunctionParser.h:
        (JSC::WASM::WASMFunctionParser<Context>::parseExpression):
        * wasm/WASMOps.h:

2016-08-15  Ryosuke Niwa  <rniwa@webkit.org>

        Conversion to sequence<T> is broken for iterable objects
        https://bugs.webkit.org/show_bug.cgi?id=160801

        Reviewed by Darin Adler.

        Export functions used to iterate over iterable objects.

        * runtime/IteratorOperations.h:
        (JSC::forEachInIterable):

2016-08-15  Benjamin Poulain  <bpoulain@apple.com>

        [Regression 204203-204210] 32-bit ASSERTION FAILED: !m_data[index].name.isValid()
        https://bugs.webkit.org/show_bug.cgi?id=160881

        Reviewed by Mark Lam.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        We were trying to set the result of the Identity node to the same
        value as the source of the Identity.
        That is pretty messed up.

2016-08-15  Saam Barati  <sbarati@apple.com>

        Web Inspector: Introduce a method to enable code coverage profiler without enabling type profiler
        https://bugs.webkit.org/show_bug.cgi?id=160750
        <rdar://problem/27793469>

        Reviewed by Joseph Pecoraro.

        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::disableTypeProfiler):
        (Inspector::InspectorRuntimeAgent::enableControlFlowProfiler):
        (Inspector::InspectorRuntimeAgent::disableControlFlowProfiler):
        (Inspector::InspectorRuntimeAgent::setTypeProfilerEnabledState):
        (Inspector::InspectorRuntimeAgent::setControlFlowProfilerEnabledState):
        * inspector/agents/InspectorRuntimeAgent.h:
        * inspector/protocol/Runtime.json:

2016-08-15  Saam Barati  <sbarati@apple.com>

        Array.prototype.map builtin should go on the fast path when constructor===@Array
        https://bugs.webkit.org/show_bug.cgi?id=160836

        Reviewed by Keith Miller.

        In the FTL, we were not compiling the result array in Array.prototype.map
        efficiently when the result array should use the Array constructor
        (which is the common case). We used to compile it as:
        x: JSConstant(Array)
        y: Construct(@x, ...)
        instead of
        y: NewArrayWithSize(...)

        This patch changes the builtin to go down the fast path when certain
        conditions are met. Often, the check to go down the fast path will
        be constant folded because we always create a normal array from the
        Array constructor.

        This is around a 5% speedup on ES6 Sample Bench.

        I also made similar changes for Array.prototype.filter
        and Array.prototype.concat on its slow path.

        * builtins/ArrayPrototype.js:

2016-08-15  Mark Lam  <mark.lam@apple.com>

        Make JSValue::strictEqual() handle failures to resolve JSRopeStrings.
        https://bugs.webkit.org/show_bug.cgi?id=160832
        <rdar://problem/27577556>

        Reviewed by Geoffrey Garen.

        Currently, JSValue::strictEqualSlowCaseInline() (and peers) will blindly try to
        access the StringImpl of a JSRopeString that fails to resolve its rope.  As a
        result, we'll crash with null pointer dereferences.

        We can fix this by introducing a JSString::equal() method that will do the
        equality comparison, but is aware of the potential failures to resolve ropes.
        JSValue::strictEqualSlowCaseInline() (and peers) will now call JSString::equal()
        instead of accessing the underlying StringImpl directly.

        Also added some exception checks.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * jit/JITOperations.cpp:
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncIndexOf):
        (JSC::arrayProtoFuncLastIndexOf):
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::equalSlowCaseInline):
        (JSC::JSValue::strictEqualSlowCaseInline):
        * runtime/JSString.cpp:
        (JSC::JSString::equalSlowCase):
        * runtime/JSString.h:
        * runtime/JSStringInlines.h: Added.
        (JSC::JSString::equal):

2016-08-15  Keith Miller  <keith_miller@apple.com>

        Implement WASM Parser and B3 IR generator
        https://bugs.webkit.org/show_bug.cgi?id=160681

        Reviewed by Benjamin Poulain.

        This patch adds the skeleton for a WebAssembly pipeline. The
        pipeline is designed in order to make it easy to have as much of
        the compilation process threaded as possible. The flow of the
        pipeline roughly goes as follows:

        1) Create a WASMPlan with the VM and a Vector of the
        assembly. Currently the plan will process all the work
        synchronously, however, in the future this can be offloaded to
        other threads.

        2) The plan will run the WASMModuleParser, which collates all the
        information needed to compile each module function
        independently. Since, we are still in the early phases, the only
        information is the starting and ending byte of the function's
        body. The module parser, however, still scans both and
        semi-validates the type and the function sections.

        3) Each function is decoded and compiled. In the future this
        should also include a opcode validation phase. The
        WASMFunctionParser is templatized so that a validator should be
        able to use most of the same code the B3 IR generator does.

        4) When the plan has finished it will fill a Vector of
        B3::Compilation objects that correspond to the respective function
        in the WASM module.


        The current testing plan for the modules is to inline the the
        binary generated by the spec's OCaml prototype. The inlined binary
        is passed to a WASMPlan then invoked to check the result of the
        function. In the future we should add a more robust testing
        infrastructure.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * testWASM.cpp:
        (printUsageStatement):
        (CommandLine::parseArguments):
        (invoke):
        (runWASMTests):
        (main):
        * wasm/JSWASMModule.h:
        (JSC::JSWASMModule::globalVariableTypes):
        * wasm/WASMB3IRGenerator.cpp: Added.
        (JSC::WASM::B3IRGenerator::B3IRGenerator):
        (JSC::WASM::B3IRGenerator::addLocal):
        (JSC::WASM::B3IRGenerator::binaryOp):
        (JSC::WASM::B3IRGenerator::addConstant):
        (JSC::WASM::B3IRGenerator::addBlock):
        (JSC::WASM::B3IRGenerator::endBlock):
        (JSC::WASM::B3IRGenerator::addReturn):
        (JSC::WASM::B3IRGenerator::unify):
        (JSC::WASM::B3IRGenerator::initializeIncommingTypes):
        (JSC::WASM::B3IRGenerator::unifyValuesWithLevel):
        (JSC::WASM::B3IRGenerator::stackForControlLevel):
        (JSC::WASM::B3IRGenerator::blockForControlLevel):
        (JSC::WASM::parseAndCompile):
        * wasm/WASMB3IRGenerator.h: Copied from Source/WTF/wtf/DataLog.h.
        * wasm/WASMFormat.h:
        * wasm/WASMFunctionParser.h: Added.
        (JSC::WASM::WASMFunctionParser<Context>::WASMFunctionParser):
        (JSC::WASM::WASMFunctionParser<Context>::parse):
        (JSC::WASM::WASMFunctionParser<Context>::parseBlock):
        (JSC::WASM::WASMFunctionParser<Context>::parseExpression):
        * wasm/WASMModuleParser.cpp: Added.
        (JSC::WASM::WASMModuleParser::parse):
        (JSC::WASM::WASMModuleParser::parseFunctionTypes):
        (JSC::WASM::WASMModuleParser::parseFunctionSignatures):
        (JSC::WASM::WASMModuleParser::parseFunctionDefinitions):
        * wasm/WASMModuleParser.h: Copied from Source/WTF/wtf/DataLog.h.
        (JSC::WASM::WASMModuleParser::WASMModuleParser):
        (JSC::WASM::WASMModuleParser::functionInformation):
        * wasm/WASMOps.h: Copied from Source/WTF/wtf/DataLog.h.
        * wasm/WASMParser.h: Added.
        (JSC::WASM::WASMParser::parseVarUInt32):
        (JSC::WASM::WASMParser::WASMParser):
        (JSC::WASM::WASMParser::consumeCharacter):
        (JSC::WASM::WASMParser::consumeString):
        (JSC::WASM::WASMParser::parseUInt32):
        (JSC::WASM::WASMParser::parseUInt7):
        (JSC::WASM::WASMParser::parseVarUInt1):
        (JSC::WASM::WASMParser::parseValueType):
        * wasm/WASMPlan.cpp: Copied from Source/WTF/wtf/DataLog.h.
        (JSC::WASM::Plan::Plan):
        * wasm/WASMPlan.h: Copied from Source/WTF/wtf/DataLog.h.
        * wasm/WASMSections.cpp: Copied from Source/WTF/wtf/DataLog.h.
        (JSC::WASM::WASMSections::lookup):
        * wasm/WASMSections.h: Copied from Source/WTF/wtf/DataLog.h.
        (JSC::WASM::WASMSections::validateOrder):

2016-08-15  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] B3 Neg opcode should support float
        https://bugs.webkit.org/show_bug.cgi?id=160795

        Reviewed by Geoffrey Garen.

        This is required to implement WASM f32.neg opcode.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::negateFloat):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3ReduceDoubleToFloat.cpp:
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::testNegDouble):
        (JSC::B3::testNegFloat):
        (JSC::B3::testNegFloatWithUselessDoubleConversion):
        (JSC::B3::run):

2016-08-15  Joseph Pecoraro  <pecoraro@apple.com>

        Use #pragma once in inspector headers
        https://bugs.webkit.org/show_bug.cgi?id=160861

        Reviewed by Mark Lam.

        * inspector/*.h:

2016-08-15  Daniel Bates  <dabates@apple.com>

        Cannot build WebKit for iOS device using Xcode 7.3/iOS 9.3 public SDK due to missing
        private frameworks and libraries
        https://bugs.webkit.org/show_bug.cgi?id=155931
        <rdar://problem/25807989>

        Reviewed by Dan Bernstein.

        Add directory WebKitLibraries/WebKitPrivateFrameworkStubs/iOS/X to the framework search path
        where X is the major version of the active iOS SDK.

        * Configurations/Base.xcconfig:

2016-08-15  Joseph Pecoraro  <pecoraro@apple.com>

        Reduce includes of Debugger.h
        https://bugs.webkit.org/show_bug.cgi?id=160827

        Reviewed by Mark Lam.

        * API/JSTypedArray.cpp:
        * bytecode/UnlinkedCodeBlock.h:
        * bytecode/UnlinkedFunctionExecutable.cpp:
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        * dfg/DFGPlan.cpp:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        * dfg/DFGSpeculativeJIT64.cpp:
        * ftl/FTLJITCode.h:
        * inspector/ScriptCallStackFactory.cpp:
        * inspector/agents/InspectorDebuggerAgent.h:
        * jit/JITOpcodes.cpp:
        * jit/JITOpcodes32_64.cpp:
        * jit/JITOperations.cpp:
        * llint/LLIntOffsetsExtractor.cpp:
        * parser/Nodes.cpp:
        * parser/Parser.cpp:
        * parser/Parser.h:
        * runtime/Completion.cpp:
        * runtime/Executable.cpp:
        * runtime/Executable.h:
        * runtime/FunctionConstructor.cpp:
        * runtime/SamplingProfiler.cpp:
        * runtime/SamplingProfiler.h:
        * runtime/VMEntryScope.cpp:

2016-08-15  Joseph Pecoraro  <pecoraro@apple.com>

        Remove unused includes of wtf headers
        https://bugs.webkit.org/show_bug.cgi?id=160839

        Reviewed by Alex Christensen.

        * Lots of files.

2016-08-13  Per Arne Vollan  <pvollan@apple.com>

        [Win] Warning fixes.
        https://bugs.webkit.org/show_bug.cgi?id=160803

        Reviewed by Brent Fulgham.

        Initialize local variables.

        * jit/JIT.cpp:
        (JSC::JIT::compileWithoutLinking):
        * runtime/Error.cpp:
        (JSC::addErrorInfoAndGetBytecodeOffset):

2016-08-12  Joseph Pecoraro  <pecoraro@apple.com>

        Remove always true JSC::Debugger::needPauseHandling virtual method
        https://bugs.webkit.org/show_bug.cgi?id=160822

        Reviewed by Mark Lam.

        All subclasses return true for this method. Just remove the method.

        * debugger/Debugger.cpp:
        (JSC::Debugger::pauseIfNeeded):
        * inspector/ScriptDebugServer.h:

2016-08-12  Saam Barati  <sbarati@apple.com>

        Inline store loop for CopyRest in DFG and FTL for certain array modes
        https://bugs.webkit.org/show_bug.cgi?id=159612

        Reviewed by Filip Pizlo.

        This patch changes the old copy_rest bytecode to actually allocate the rest array itself.
        The bytecode is now called create_rest with an analogous CreateRest node in the DFG/FTL.
        This allows the bytecode to be in control of what type of indexingType the array is allocated
        with. We always allocate using ArrayWithContiguous storage unless we're havingABadTime().
        This also makes allocating and writing into the array fast. On the fast path, the DFG/FTL
        JIT will fast allocate the array and its storage, and we will do a memmove from the rest
        region of arguments into the array's storage.

        I'm seeing a 1-2% speedup on ES6SampleBench, and about a 2x speedup
        on micro benchmarks that just test rest creation speed.

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitRestParameter):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
        (JSC::DFG::CallArrayAllocatorWithVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableSizeSlowPathGenerator):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::uses):
        (JSC::DFG::Graph::isWatchingHavingABadTimeWatchpoint):
        (JSC::DFG::Graph::compilation):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::numberOfArgumentsToSkip):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCreateClonedArguments):
        (JSC::DFG::SpeculativeJIT::compileCreateRest):
        (JSC::DFG::SpeculativeJIT::compileGetRestLength):
        (JSC::DFG::SpeculativeJIT::compileCopyRest): Deleted.
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::compileArithRandom):
        (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::compileArithRandom):
        (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateClonedArguments):
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateRest):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetRestLength):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayBuffer):
        (JSC::FTL::DFG::LowerDFGToB3::compileAllocateArrayWithSize):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize):
        (JSC::FTL::DFG::LowerDFGToB3::compileCopyRest): Deleted.
        * interpreter/CallFrame.h:
        (JSC::ExecState::addressOfArgumentsStart):
        (JSC::ExecState::argument):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_argument_count):
        (JSC::JIT::emit_op_create_rest):
        (JSC::JIT::emit_op_copy_rest): Deleted.
        * jit/JITOperations.h:
        * llint/LowLevelInterpreter.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:

2016-08-12  Ryosuke Niwa  <rniwa@webkit.org>

        Add a helper class for enumerating elements in an iterable object
        https://bugs.webkit.org/show_bug.cgi?id=160800

        Reviewed by Benjamin Poulain.

        Added iteratorForIterable which provides an abstraction for iterating over an iterable object,
        and deployed it in the constructors of Set, WeakSet, Map, and WeakMap.

        Also added a helper function iteratorForIterable, which retrieves the iterator out of an iterable object.

        * runtime/IteratorOperations.cpp:
        (JSC::iteratorForIterable): Added.
        * runtime/IteratorOperations.h:
        (JSC::forEachInIterable): Added.
        * runtime/MapConstructor.cpp:
        (JSC::constructMap):
        * runtime/SetConstructor.cpp:
        (JSC::constructSet):
        * runtime/WeakMapConstructor.cpp:
        (JSC::constructWeakMap):
        * runtime/WeakSetConstructor.cpp:
        (JSC::constructWeakSet):

2016-08-12  Joseph Pecoraro  <pecoraro@apple.com>

        Remove unused includes of RefCountedLeakCounter.h
        https://bugs.webkit.org/show_bug.cgi?id=160817

        Reviewed by Mark Lam.

        * parser/Nodes.cpp:
        * runtime/Structure.cpp:

2016-08-12  Pranjal Jumde  <pjumde@apple.com>

        ASSERTION FAILED: : line >= firstLine in BytecodeGenerator::emitExpressionInfo.
        https://bugs.webkit.org/show_bug.cgi?id=160535
        <rdar://problem/27328151>
        
        Reviewed by Saam Barati.

        lineNumber from the savePoint was not being restored before calling next() causing discrepancy in the offset and line for the token

        * parser/Parser.h:
        (JSC::Parser::restoreLexerState):

2016-08-12  Skachkov Oleksandr  <gskachkov@gmail.com>

        [ES2016] Implement Object.entries
        https://bugs.webkit.org/show_bug.cgi?id=160412

        Reviewed by Saam Barati.

        This patch adds entries function to Object that returns list of 
        key+values pairs. Patch did according to the point of
        spec https://tc39.github.io/ecma262/#sec-object.entries

        * builtins/ObjectConstructor.js:
        (globalPrivate.enumerableOwnProperties):
        (entries):
        * runtime/ObjectConstructor.cpp:

2016-08-11  Mark Lam  <mark.lam@apple.com>

        OverridesHasInstance should not branch across register allocations.
        https://bugs.webkit.org/show_bug.cgi?id=160792
        <rdar://problem/27361778>

        Reviewed by Benjamin Poulain.

        The OverrideHasInstance node has a branch test that is emitted conditionally.
        It also has a bug where it allocated a register after this branch, which is not
        allowed and would fail an assertion introduced in https://trac.webkit.org/r145931.
        From the ChangeLog for r145931:

        "This [assertion that register allocations are not branched around] protects
        against the case where an allocation could have spilled register contents to free
        up a register and that spill only occurs on one path of many through the code.
        A subsequent fill of the spilled register may load garbage."

        Because the branch isn't always emitted, this bug has gone unnoticed until now.
        This patch fixes this issue by pre-allocating the registers before emitting the
        branch in OverrideHasInstance.

        Note: this issue is only present in DFGSpeculativeJIT64.cpp.  The 32-bit version
        is doing it right.

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

2016-08-11  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Make B3 Return opcode work without arguments
        https://bugs.webkit.org/show_bug.cgi?id=160787

        Reviewed by Keith Miller.

        We need a way to create functions that do not return values.

        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::retVoid):
        * b3/B3BasicBlock.cpp:
        (JSC::B3::BasicBlock::appendNewControlValue):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3Validate.cpp:
        * b3/B3Value.h:
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::testReturnVoid):
        (JSC::B3::run):

2016-08-11  Mark Lam  <mark.lam@apple.com>

        Gardening: fix gcc builds after r204387. 

        Not reviewed.

        Apparently, gcc is not sophisticated enough to realize that the end of the
        function is unreachable, and is wrongly complaining about "control reaches end of
        non-void function".  I'm restoring the RELEASE_ASSERT_NOT_REACHED() and return
        statement at the end of MarkedBlock::sweepHelper() to appease gcc.

        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::sweepHelper):

2016-08-11  Alex Christensen  <achristensen@webkit.org>

        Use StringBuilder::appendLiteral when possible don't append result of makeString
        https://bugs.webkit.org/show_bug.cgi?id=160772

        Reviewed by Sam Weinig.

        * API/tests/ExecutionTimeLimitTest.cpp:
        (testExecutionTimeLimit):
        * API/tests/PingPongStackOverflowTest.cpp:
        (PingPongStackOverflowObject_hasInstance):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ArrayPatternNode::toString):
        (JSC::RestParameterNode::toString):
        * runtime/ErrorInstance.cpp:
        (JSC::ErrorInstance::sanitizedToString):
        * runtime/Options.cpp:
        (JSC::Options::dumpOption):

2016-08-11  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Revert most of r203808
        https://bugs.webkit.org/show_bug.cgi?id=160784

        Reviewed by Geoffrey Garen.

        Switching to fastMalloc() caused regressions on Jetstream and Octane
        on MacBook Air. I was able to get back some of it in the following
        patches but the tests that never go to FTL are still regressed.

        This patch revert r203808 except of the node index.
        Nodes are allocated with the custom allocator like before but they are
        now also kept in a table, addressed by the node index.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3SparseCollection.h:
        (JSC::B3::SparseCollection::packIndices): Deleted.
        * dfg/DFGAllocator.h: Added.
        (JSC::DFG::Allocator::Region::size):
        (JSC::DFG::Allocator::Region::headerSize):
        (JSC::DFG::Allocator::Region::numberOfThingsPerRegion):
        (JSC::DFG::Allocator::Region::data):
        (JSC::DFG::Allocator::Region::isInThisRegion):
        (JSC::DFG::Allocator::Region::regionFor):
        (JSC::DFG::Allocator<T>::Allocator):
        (JSC::DFG::Allocator<T>::~Allocator):
        (JSC::DFG::Allocator<T>::allocate):
        (JSC::DFG::Allocator<T>::free):
        (JSC::DFG::Allocator<T>::freeAll):
        (JSC::DFG::Allocator<T>::reset):
        (JSC::DFG::Allocator<T>::indexOf):
        (JSC::DFG::Allocator<T>::allocatorOf):
        (JSC::DFG::Allocator<T>::bumpAllocate):
        (JSC::DFG::Allocator<T>::freeListAllocate):
        (JSC::DFG::Allocator<T>::allocateSlow):
        (JSC::DFG::Allocator<T>::freeRegionsStartingAt):
        (JSC::DFG::Allocator<T>::startBumpingIn):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compileImpl):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::Graph):
        (JSC::DFG::Graph::~Graph):
        (JSC::DFG::Graph::addNodeToMapByIndex):
        (JSC::DFG::Graph::deleteNode):
        (JSC::DFG::Graph::packNodeIndices):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::addNode):
        (JSC::DFG::Graph::maxNodeCount):
        (JSC::DFG::Graph::nodeAt):
        * dfg/DFGLongLivedState.cpp: Added.
        (JSC::DFG::LongLivedState::LongLivedState):
        (JSC::DFG::LongLivedState::~LongLivedState):
        (JSC::DFG::LongLivedState::shrinkToFit):
        * dfg/DFGLongLivedState.h: Added.
        * dfg/DFGNode.h:
        * dfg/DFGNodeAllocator.h: Added.
        (operator new ):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThread):
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGPlan.h:
        * dfg/DFGWorklist.cpp:
        (JSC::DFG::Worklist::runThread):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2016-08-11  Mark Lam  <mark.lam@apple.com>

        The jsc shell's Element host constructor should throw if it fails to construct an object.
        https://bugs.webkit.org/show_bug.cgi?id=160773
        <rdar://problem/27328608>

        Reviewed by Saam Barati.

        The Element object is a test object provided in the jsc shell for testing use only.
        JavaScriptCore expects host constructors to either throw an error or return a
        constructed object.  Element has a host constructor that did not obey this contract.
        As a result, the following statement will fail a RELEASE_ASSERT:

            new (Element.bind())

        This is now fixed.

        * jsc.cpp:
        (functionCreateElement):

2016-08-11  Mark Lam  <mark.lam@apple.com>

        Disallow synchronous sweeping for eden GCs.
        https://bugs.webkit.org/show_bug.cgi?id=160716

        Reviewed by Geoffrey Garen.

        * heap/Heap.cpp:
        (JSC::Heap::collectAllGarbage):
        (JSC::Heap::collectAndSweep): Deleted.
        * heap/Heap.h:
        (JSC::Heap::collectAllGarbage): Deleted.
        - No need for a separate collectAndSweep() anymore since we only call it for
          FullCollections.
        - Since we've already swept all the blocks, I cleared m_blockSnapshot so that the
          IncrementalSweeper can bail earlier when it runs later.

        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::sweepHelper):
        - Removed the unreachable return statement.

        * heap/MarkedBlock.h:
        - Document what "Retired" means.

        * tools/JSDollarVMPrototype.cpp:
        (JSC::JSDollarVMPrototype::edenGC):

2016-08-11  Per Arne Vollan  <pvollan@apple.com>

        [Win] Warning fix.
        https://bugs.webkit.org/show_bug.cgi?id=160734

        Reviewed by Sam Weinig.

        Add static cast from int to uint32_t.

        * bytecode/ArithProfile.h:

2016-08-10  Michael Saboff  <msaboff@apple.com>

        Baseline GetByVal and PutByVal for cache ID stubs need to handle exceptions
        https://bugs.webkit.org/show_bug.cgi?id=160749

        Reviewed by Filip Pizlo.

        We were emitting "callOperation()" calls in emitGetByValWithCachedId() and
        emitPutByValWithCachedId() without linking the exception checks created by the
        code emitted.  This manifested itself in various ways depending on the processor.
        This is due to what the destination is for an unlinked branch.  On X86, an unlinked
        branch goes tot he next instructions.  On ARM64, we end up with an infinite loop
        as we branch to the same instruction.  On ARM we branch to 0 as the branch is to
        an absolute address of 0.

        Now we save the exception handler address for the original generated function and
        link the exception cases for these by-val stubs to this handler.

        * bytecode/ByValInfo.h:
        (JSC::ByValInfo::ByValInfo): Added the address of the exception handler we should
        link to.

        * jit/JIT.cpp:
        (JSC::JIT::link): Compute the linked exception handler address and pass it to
        the ByValInfo constructor.
        (JSC::JIT::privateCompileExceptionHandlers): Make sure that we generate the
        exception handler if we have any by-val handlers.

        * jit/JIT.h:
        Added a label for the exception handler.  We'll link this later for the
        by value handlers.

        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::privateCompileGetByValWithCachedId):
        (JSC::JIT::privateCompilePutByValWithCachedId):
        Link exception branches to the exception handler for the main function.

2016-08-10  Mark Lam  <mark.lam@apple.com>

        DFG's flushForTerminal() needs to add PhantomLocals for bytecode live locals.
        https://bugs.webkit.org/show_bug.cgi?id=160755
        <rdar://problem/27488507>

        Reviewed by Filip Pizlo.

        If the DFG sees that an inlined function will result in an OSR exit every time,
        it will treat all downstream blocks as dead.  However, it still needs to keep
        locals that are alive in the bytecode alive for the compiled function so that
        those locals are properly written to the stack by the OSR exit ramp.

        The existing code neglected to do this.  This patch remedies this issue.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::flushDirect):
        (JSC::DFG::ByteCodeParser::addFlushOrPhantomLocal):
        (JSC::DFG::ByteCodeParser::phantomLocalDirect):
        (JSC::DFG::ByteCodeParser::flushForTerminal):

2016-08-09  Skachkov Oleksandr  <gskachkov@gmail.com>

        [ES2016] Implement Object.values
        https://bugs.webkit.org/show_bug.cgi?id=160410

        Reviewed by Saam Barati, Yusuke Suzuki.

        This patch adds values function to Object that return list of 
        own values of the object. Patch did according to the point of 
        spec http://tc39.github.io/ecma262/#sec-object.values
        
        Also patch adds generic builtin intrinsic constants: 
        @IterationKindKey/@IterationKindValue/@IterationKindKeyValue 
        that is used in  EnumerableOwnProperties to set Kind of operation  
        and replace own IterationKind enums in following iterators: 
        ArrayIterator, MapIterator, and SetIterator 

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/ObjectConstructor.js:
        (globalPrivate.enumerableOwnProperties):
        (values):
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::getInternalProperties):
        * runtime/ArrayIteratorPrototype.h:
        * runtime/IterationKind.h: Copied from Source/JavaScriptCore/builtins/ObjectConstructor.js.
        * runtime/JSMapIterator.h:
        (JSC::JSMapIterator::create):
        (JSC::JSMapIterator::next):
        (JSC::JSMapIterator::kind):
        (JSC::JSMapIterator::JSMapIterator):
        * runtime/JSSetIterator.h:
        (JSC::JSSetIterator::create):
        (JSC::JSSetIterator::next):
        (JSC::JSSetIterator::kind):
        (JSC::JSSetIterator::JSSetIterator):
        * runtime/MapPrototype.cpp:
        (JSC::mapProtoFuncValues):
        (JSC::mapProtoFuncEntries):
        (JSC::mapProtoFuncKeys):
        (JSC::privateFuncMapIterator):
        * runtime/ObjectConstructor.cpp:
        * runtime/SetPrototype.cpp:
        (JSC::setProtoFuncValues):
        (JSC::setProtoFuncEntries):
        (JSC::privateFuncSetIterator):

2016-08-10  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Speed up SparseCollection & related maps
        https://bugs.webkit.org/show_bug.cgi?id=160733

        Reviewed by Saam Barati.

        On MBA, Graph::addNode() shows up in profiles due to SparseCollection::add().
        This is unfortunate.

        The first improvement is to build the new unique_ptr in the empty slot
        instead of moving a new value into it.

        Previously, the code would load the previous value, test if it is null
        then invoke the destructor and finally fastFree(). The initial test
        obviously fails so that's a whole bunch of code that is never executed.

        With the new code, we just have a store.

        I also removed the bounds checking on our maps based on node index.
        Those bounds checks are never eliminated by clang because the index
        is always loaded from memory instead of being computed.
        There are unfortunately too many nodes processed and the bounds checks
        get costly.

        * b3/B3SparseCollection.h:
        (JSC::B3::SparseCollection::add):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::abstractValuesCache):
        * dfg/DFGInPlaceAbstractState.h:

2016-08-10  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Remove some useless code I left when rewriting CSE's large maps
        https://bugs.webkit.org/show_bug.cgi?id=160720

        Reviewed by Michael Saboff.

        * dfg/DFGCSEPhase.cpp:
        The maps m_worldMap && m_sideStateMap are useless. They come from the previous
        iteration that had weaker constraints.

        Also move m_heapMap after m_fallbackStackMap since that is the order
        in which they are used in the algorithm.

2016-08-10  Benjamin Poulain  <bpoulain@apple.com>

        Remove AbstractInterpreter::executeEdges(unsigned), it is no longer used anywhere
        https://bugs.webkit.org/show_bug.cgi?id=160708

        Reviewed by Mark Lam.

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

2016-08-10  Simon Fraser  <simon.fraser@apple.com>

        Sort the feature flags in the FEATURE_DEFINES lines
        https://bugs.webkit.org/show_bug.cgi?id=160742

        Reviewed by Anders Carlsson.

        * Configurations/FeatureDefines.xcconfig:

2016-08-10  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Add ModuleLoaderPrototype and move methods to it
        https://bugs.webkit.org/show_bug.cgi?id=160633

        Reviewed by Saam Barati.

        In the future, we need to add the ability to create the new Loader object (by users).
        So rather than holding all the methods in the ModuleLoaderObject instance, moving them
        to ModuleLoaderPrototype and create the default JSModuleLoader instance is better.

        No behavior change.

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/ModuleLoaderObject.js:
        (setStateToMax): Deleted.
        (newRegistryEntry): Deleted.
        (ensureRegistered): Deleted.
        (forceFulfillPromise): Deleted.
        (fulfillFetch): Deleted.
        (fulfillTranslate): Deleted.
        (fulfillInstantiate): Deleted.
        (commitInstantiated): Deleted.
        (instantiation): Deleted.
        (requestFetch): Deleted.
        (requestTranslate): Deleted.
        (requestInstantiate): Deleted.
        (requestResolveDependencies.): Deleted.
        (requestResolveDependencies): Deleted.
        (requestInstantiateAll): Deleted.
        (requestLink): Deleted.
        (requestReady): Deleted.
        (link): Deleted.
        (moduleEvaluation): Deleted.
        (provide): Deleted.
        (loadAndEvaluateModule): Deleted.
        (loadModule): Deleted.
        (linkAndEvaluateModule): Deleted.
        * builtins/ModuleLoaderPrototype.js: Renamed from Source/JavaScriptCore/builtins/ModuleLoaderObject.js.
        (setStateToMax):
        (newRegistryEntry):
        (ensureRegistered):
        (forceFulfillPromise):
        (fulfillFetch):
        (fulfillTranslate):
        (fulfillInstantiate):
        (commitInstantiated):
        (instantiation):
        (requestFetch):
        (requestTranslate):
        (requestInstantiate):
        (requestResolveDependencies.):
        (requestResolveDependencies):
        (requestInstantiateAll):
        (requestLink):
        (requestReady):
        (link):
        (moduleEvaluation):
        (provide):
        (loadAndEvaluateModule):
        (loadModule):
        (linkAndEvaluateModule):
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        * jsc.cpp:
        (GlobalObject::moduleLoaderResolve):
        (GlobalObject::moduleLoaderFetch):
        * runtime/Completion.cpp:
        (JSC::loadAndEvaluateModule):
        (JSC::loadModule):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::moduleLoader):
        (JSC::JSGlobalObject::moduleLoaderStructure):
        * runtime/JSModuleLoader.cpp: Added.
        (JSC::JSModuleLoader::JSModuleLoader):
        (JSC::JSModuleLoader::finishCreation):
        (JSC::printableModuleKey):
        (JSC::JSModuleLoader::provide):
        (JSC::JSModuleLoader::loadAndEvaluateModule):
        (JSC::JSModuleLoader::loadModule):
        (JSC::JSModuleLoader::linkAndEvaluateModule):
        (JSC::JSModuleLoader::resolve):
        (JSC::JSModuleLoader::fetch):
        (JSC::JSModuleLoader::translate):
        (JSC::JSModuleLoader::instantiate):
        (JSC::JSModuleLoader::evaluate):
        * runtime/JSModuleLoader.h: Copied from Source/JavaScriptCore/runtime/ModuleLoaderObject.h.
        (JSC::JSModuleLoader::create):
        (JSC::JSModuleLoader::createStructure):
        * runtime/JSModuleRecord.h:
        * runtime/ModuleLoaderObject.cpp: Removed.
        (JSC::ModuleLoaderObject::ModuleLoaderObject): Deleted.
        (JSC::ModuleLoaderObject::finishCreation): Deleted.
        (JSC::printableModuleKey): Deleted.
        (JSC::ModuleLoaderObject::provide): Deleted.
        (JSC::ModuleLoaderObject::loadAndEvaluateModule): Deleted.
        (JSC::ModuleLoaderObject::loadModule): Deleted.
        (JSC::ModuleLoaderObject::linkAndEvaluateModule): Deleted.
        (JSC::ModuleLoaderObject::resolve): Deleted.
        (JSC::ModuleLoaderObject::fetch): Deleted.
        (JSC::ModuleLoaderObject::translate): Deleted.
        (JSC::ModuleLoaderObject::instantiate): Deleted.
        (JSC::ModuleLoaderObject::evaluate): Deleted.
        (JSC::moduleLoaderObjectParseModule): Deleted.
        (JSC::moduleLoaderObjectRequestedModules): Deleted.
        (JSC::moduleLoaderObjectModuleDeclarationInstantiation): Deleted.
        (JSC::moduleLoaderObjectResolve): Deleted.
        (JSC::moduleLoaderObjectFetch): Deleted.
        (JSC::moduleLoaderObjectTranslate): Deleted.
        (JSC::moduleLoaderObjectInstantiate): Deleted.
        (JSC::moduleLoaderObjectEvaluate): Deleted.
        * runtime/ModuleLoaderObject.h:
        (JSC::ModuleLoaderObject::create): Deleted.
        (JSC::ModuleLoaderObject::createStructure): Deleted.
        * runtime/ModuleLoaderPrototype.cpp: Added.
        (JSC::ModuleLoaderPrototype::ModuleLoaderPrototype):
        (JSC::moduleLoaderPrototypeParseModule):
        (JSC::moduleLoaderPrototypeRequestedModules):
        (JSC::moduleLoaderPrototypeModuleDeclarationInstantiation):
        (JSC::moduleLoaderPrototypeResolve):
        (JSC::moduleLoaderPrototypeFetch):
        (JSC::moduleLoaderPrototypeTranslate):
        (JSC::moduleLoaderPrototypeInstantiate):
        (JSC::moduleLoaderPrototypeEvaluate):
        * runtime/ModuleLoaderPrototype.h: Renamed from Source/JavaScriptCore/runtime/ModuleLoaderObject.h.
        (JSC::ModuleLoaderPrototype::create):
        (JSC::ModuleLoaderPrototype::createStructure):

2016-08-09  Saam Barati  <sbarati@apple.com>

        JSBoundFunction should lazily generate its name string
        https://bugs.webkit.org/show_bug.cgi?id=160678
        <rdar://problem/27043194>

        Reviewed by Mark Lam.

        We were eagerly allocating the BoundFunction's 'name' string
        by prepending the "bound " prefix. This patch makes the 'name'
        string creation lazy like we do with ordinary JSFunctions.

        This is a 25% speedup on the microbenchmark I added that measures
        bound function creation speed. Hopefully this also helps us recover
        from a 1% Speedometer regression that was introduced in the original
        bound function "bound " prefixing patch.

        * runtime/JSBoundFunction.cpp:
        (JSC::JSBoundFunction::create):
        (JSC::JSBoundFunction::JSBoundFunction):
        (JSC::JSBoundFunction::finishCreation):
        * runtime/JSBoundFunction.h:
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::finishCreation):
        (JSC::JSFunction::getOwnPropertySlot):
        (JSC::JSFunction::getOwnNonIndexPropertyNames):
        (JSC::JSFunction::put):
        (JSC::JSFunction::deleteProperty):
        (JSC::JSFunction::defineOwnProperty):
        (JSC::JSFunction::reifyLazyPropertyIfNeeded):
        (JSC::JSFunction::reifyBoundNameIfNeeded):
        * runtime/JSFunction.h:

2016-08-09  George Ruan  <gruan@apple.com>

        Implement functionality of media capture on iOS
        https://bugs.webkit.org/show_bug.cgi?id=158945
        <rdar://problem/26893343>

        Reviewed by Tim Horton.

        * Configurations/FeatureDefines.xcconfig: Enable media capture feature
        for iOS.

2016-08-09  Saam Barati  <sbarati@apple.com>

        Parser<LexerType>::parseFunctionInfo() has the wrong info about captured vars when a function is not cached.
        https://bugs.webkit.org/show_bug.cgi?id=160671
        <rdar://problem/27756112>

        Reviewed by Mark Lam.

        There was a bug in our captured variable analysis when a function has a default
        parameter expression that is a function that captures something from the parent scope.
        The bug was that we were relying on the SourceProviderCache to succeed for the
        analysis to work. This is obviously wrong. I've fixed this to work regardless
        of getting a cache hit. To prevent future bugs that rely on the success of the
        SourceProviderCache, I've made the validate testing mode disable the SourceProviderCache

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFunctionInfo):
        * parser/Parser.h:
        (JSC::Scope::setInnerArrowFunctionUsesEvalAndUseArgumentsIfNeeded):
        (JSC::Scope::addClosedVariableCandidateUnconditionally):
        (JSC::Scope::collectFreeVariables):
        * runtime/Options.h:

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

        ASSERTION FAILED: hasInlineStorage() in JSFinalObject::visitChildren().
        https://bugs.webkit.org/show_bug.cgi?id=160666

        Reviewed by Keith Miller.

        This assertion is benign.  JSFinalObject::visitChildren() calls
        JSObject::inlineStorage() to get a pointer to the object's inline storage, and
        later passes it to visitor.appendValuesHidden() with a previously computed
        storageSize.  When storageSize is 0, appendValuesHidden() ends up doing nothing.
        However, before we get there, JSObject::inlineStorage() will be asserting
        hasInlineStorage() and this assertion will fail when storageSize is 0.

        We can fix this assertion failure by simply adding a storageSize check before
        calling hasInlineStorage() and visitor.appendValuesHidden().

        * runtime/JSObject.cpp:
        (JSC::JSFinalObject::visitChildren):

2016-08-08  Brian Burg  <bburg@apple.com>

        Web Inspector: clean up prefixing of Automation protocol generated files
        https://bugs.webkit.org/show_bug.cgi?id=160635
        <rdar://problem/27735327>

        Reviewed by Timothy Hatcher.

        Introduce different settings for the 'protocol group' name for C++ vs. Objective-C.

        Use 'WD' as the prefix for generated Objective-C frontend dispatchers and helpers.
        Continue using 'Automation' as the prefix for generated C++ backend dispatchers.

        * inspector/scripts/codegen/cpp_generator.py:
        (CppGenerator.protocol_name):
        * inspector/scripts/codegen/generate_objc_protocol_type_conversions_implementation.py:
        (ObjCProtocolTypeConversionsImplementationGenerator.generate_output):
        (ObjCProtocolTypeConversionsImplementationGenerator._generate_type_factory_category_interface):
        (ObjCProtocolTypeConversionsImplementationGenerator._generate_type_factory_category_implementation):
        Adjust the class name. Generate one category per protocol domain to keep it easy to read.

        * inspector/scripts/codegen/models.py:
        * inspector/scripts/codegen/objc_generator.py:
        (ObjCGenerator.protocol_name):

        * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
        * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
        * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
        * inspector/scripts/tests/expected/enum-values.json-result:
        * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
        * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
        * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
        * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
        * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
        * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
        Rebaseline test results.

2016-08-07  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Module namespace object should not allow unset IC
        https://bugs.webkit.org/show_bug.cgi?id=160553

        Reviewed by Saam Barati.

        Previously, module namespace object accidentally allow "unset IC". But this "unsetness" does not rely on
        the structure. We should disable inline caching onto the namespace object. Once it is needed, we should
        create the special caching for namespace object like the following: it should be similar to monomorphic IC,
        but it caches the object itself instead of the structure. It checks the object itself (And in DFG, it should be
        CheckCell) and loads the value from the target module environment directly[1].

        And this patch also set setIsTaintedByProxy for the module namespace object to notify to the caller that
        this object has impure ::getOwnPropertySlot. Then this function is now renamed to setIsTaintedByOpaqueObject.

        We drop the hack in JSModuleNamespaceObject::getOwnPropertySlot since we already introduced InternalMethodType
        for ProxyObject. Previously we cannot distinguish ::HasProperty and ::GetOwnProperty. So not to throw any
        errors for ::HasProperty case, we used slot.setCustom to delay the observable operation.
        But, this hack lacks the support for hasOwnProperty: hasOwnProperty uses [[GetOwnProperty]], so it should throw an error.
        However the previous implementation does not throw an error since the delayed observable part (custom function part) is
        skipped in hasOwnProperty implementation. We now remove this custom property hack and fix the corresponding failure
        in test262.

        [1]: https://bugs.webkit.org/show_bug.cgi?id=160590

        * jit/JITOperations.cpp:
        * runtime/ArrayPrototype.cpp:
        (JSC::getProperty):
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::constructGenericTypedArrayViewWithArguments):
        * runtime/JSModuleNamespaceObject.cpp:
        (JSC::JSModuleNamespaceObject::getOwnPropertySlot):
        (JSC::callbackGetter): Deleted.
        * runtime/JSModuleNamespaceObject.h:
        * runtime/PropertySlot.cpp:
        (JSC::PropertySlot::getPureResult):
        * runtime/PropertySlot.h:
        (JSC::PropertySlot::PropertySlot):
        (JSC::PropertySlot::setIsTaintedByOpaqueObject):
        (JSC::PropertySlot::isTaintedByOpaqueObject):
        (JSC::PropertySlot::setIsTaintedByProxy): Deleted.
        (JSC::PropertySlot::isTaintedByProxy): Deleted.
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::getOwnPropertySlotCommon):

2016-08-05  Keith Miller  <keith_miller@apple.com>

        Add LEBDecoder and tests
        https://bugs.webkit.org/show_bug.cgi?id=160625

        Reviewed by Benjamin Poulain.

        Adds a new target testWASM that is currently used to test the LEB decoder.
        In the future, if we add more support for WASM we will put more tests
        here.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * testWASM.cpp: Added.
        (CommandLine::CommandLine):
        (printUsageStatement):
        (CommandLine::parseArguments):
        (runLEBTests):
        (main):

2016-08-05  Keith Miller  <keith_miller@apple.com>

        32-bit JSC test failure: stress/instanceof-late-constant-folding.js
        https://bugs.webkit.org/show_bug.cgi?id=160620

        Reviewed by Filip Pizlo.

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

2016-08-05  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Remove the first LocalCSE
        https://bugs.webkit.org/show_bug.cgi?id=160615

        Reviewed by Saam Barati.

        LocalCSE is the most expensive phase in DFG (excluding FTL).

        The combination of two LocalCSEs does not seem to pay for its cost.
        Doing a single LocalCSE is always after ConstantFolding and StrengthReduction
        is always a win on my machine.

        * dfg/DFGCleanUpPhase.cpp:
        (JSC::DFG::CleanUpPhase::run):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):

2016-08-05  Saam Barati  <sbarati@apple.com>

        various math operations don't properly check for an exception after calling toNumber() on the lhs
        https://bugs.webkit.org/show_bug.cgi?id=160154

        Reviewed by Mark Lam.

        We must check for an exception after calling toNumber() on the lhs
        because this can throw an exception. If we called toNumber() on
        the rhs without first checking for an exception after the toNumber()
        on the lhs, this can lead us to execute effectful code or deviate
        from the standard in subtle ways. I fixed this bug in various places
        by always checking for an exception after calling toNumber() on the
        lhs for the various bit and arithmetic operations.

        This patch also found a commutativity bug inside DFGStrengthReduction.
        We could end up commuting the lhs and rhs of say an "|" expression
        even when the lhs/rhs may not be numbers. This is wrong because
        executing toNumber() on the lhs/rhs has strict ordering guarantees
        by the specification and is observable by user programs.

        * dfg/DFGOperations.cpp:
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleCommutativity):
        * jit/JITOperations.cpp:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/Operations.cpp:
        (JSC::jsAddSlowCase):

2016-08-05  Michael Saboff  <msaboff@apple.com>

        compilePutByValForIntTypedArray() has a slow path in the middle of its processing
        https://bugs.webkit.org/show_bug.cgi?id=160614

        Reviewed by Keith Miller.

        In compilePutByValForIntTypedArray() we were calling out to the slow path
        operationToInt32() and then returning back to the middle of code to finish
        the processing of writing the value to the array.  When we make the slow
        path call, we trash any temporary registers that have been allocated.
        In general slow path calls should finish the operation in progress and
        continue processing at the beginning of the next node.

        This was discovered while working on the register argument changes, when
        we SpeculateStrictInt32Operand on the value child node.  That child node's
        value was live in register with a spill format of DataFormatJSInt32.  In that
        case we allocate a new temporary register and copy just the lower 32 bits from
        the child register to the new temp register.  That temp register gets trashed
        when we make the operationToInt32() slow path call.

        I spent some time trying to devise a test with the current code base and wasn't
        successful.  This case is tested with the register argument changes in progress.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):

2016-08-05  Saam Barati  <sbarati@apple.com>

        Assertion failure when accessing TDZ variable in catch through eval
        https://bugs.webkit.org/show_bug.cgi?id=160554

        Reviewed by Mark Lam and Keith Miller.

        When we were calculating the variables under TDZ from a JSScope,
        the algorithm was not taking into account that a catch scope
        has variables under TDZ.

        * runtime/JSScope.cpp:
        (JSC::JSScope::collectVariablesUnderTDZ):

2016-08-05  Keith Miller  <keith_miller@apple.com>

        Delete out of date WASM code.
        https://bugs.webkit.org/show_bug.cgi?id=160603

        Reviewed by Saam Barati.

        This patch removes a bunch of the wasm files that we are unlikey to use
        with the newer wasm spec. If we end up needing any of the deleted code
        later we can restore it at that time.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * jit/JITOperations.cpp:
        * jsc.cpp:
        (GlobalObject::finishCreation): Deleted.
        (functionLoadWebAssembly): Deleted.
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::setUpCall): Deleted.
        * runtime/Executable.cpp:
        (JSC::WebAssemblyExecutable::prepareForExecution): Deleted.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init): Deleted.
        (JSC::JSGlobalObject::visitChildren): Deleted.
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::wasmModuleStructure): Deleted.
        * wasm/WASMConstants.h: Removed.
        * wasm/WASMFunctionB3IRGenerator.h: Removed.
        (JSC::WASMFunctionB3IRGenerator::MemoryAddress::MemoryAddress): Deleted.
        (JSC::WASMFunctionB3IRGenerator::startFunction): Deleted.
        (JSC::WASMFunctionB3IRGenerator::endFunction): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildSetLocal): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildSetGlobal): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildReturn): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildImmediateI32): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildImmediateF32): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildImmediateF64): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildGetLocal): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildGetGlobal): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildConvertType): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildLoad): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildStore): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildUnaryI32): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildUnaryF32): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildUnaryF64): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildBinaryI32): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildBinaryF32): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildBinaryF64): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildRelationalI32): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildRelationalF32): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildRelationalF64): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildMinOrMaxI32): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildMinOrMaxF64): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildCallInternal): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildCallIndirect): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildCallImport): Deleted.
        (JSC::WASMFunctionB3IRGenerator::appendExpressionList): Deleted.
        (JSC::WASMFunctionB3IRGenerator::discard): Deleted.
        (JSC::WASMFunctionB3IRGenerator::linkTarget): Deleted.
        (JSC::WASMFunctionB3IRGenerator::jumpToTarget): Deleted.
        (JSC::WASMFunctionB3IRGenerator::jumpToTargetIf): Deleted.
        (JSC::WASMFunctionB3IRGenerator::startLoop): Deleted.
        (JSC::WASMFunctionB3IRGenerator::endLoop): Deleted.
        (JSC::WASMFunctionB3IRGenerator::startSwitch): Deleted.
        (JSC::WASMFunctionB3IRGenerator::endSwitch): Deleted.
        (JSC::WASMFunctionB3IRGenerator::startLabel): Deleted.
        (JSC::WASMFunctionB3IRGenerator::endLabel): Deleted.
        (JSC::WASMFunctionB3IRGenerator::breakTarget): Deleted.
        (JSC::WASMFunctionB3IRGenerator::continueTarget): Deleted.
        (JSC::WASMFunctionB3IRGenerator::breakLabelTarget): Deleted.
        (JSC::WASMFunctionB3IRGenerator::continueLabelTarget): Deleted.
        (JSC::WASMFunctionB3IRGenerator::buildSwitch): Deleted.
        * wasm/WASMFunctionCompiler.h: Removed.
        (JSC::operationConvertJSValueToInt32): Deleted.
        (JSC::operationConvertJSValueToDouble): Deleted.
        (JSC::operationDiv): Deleted.
        (JSC::operationMod): Deleted.
        (JSC::operationUnsignedDiv): Deleted.
        (JSC::operationUnsignedMod): Deleted.
        (JSC::operationConvertUnsignedInt32ToDouble): Deleted.
        (JSC::sizeOfMemoryType): Deleted.
        (JSC::WASMFunctionCompiler::MemoryAddress::MemoryAddress): Deleted.
        (JSC::WASMFunctionCompiler::WASMFunctionCompiler): Deleted.
        (JSC::WASMFunctionCompiler::startFunction): Deleted.
        (JSC::WASMFunctionCompiler::endFunction): Deleted.
        (JSC::WASMFunctionCompiler::buildSetLocal): Deleted.
        (JSC::WASMFunctionCompiler::buildSetGlobal): Deleted.
        (JSC::WASMFunctionCompiler::buildReturn): Deleted.
        (JSC::WASMFunctionCompiler::buildImmediateI32): Deleted.
        (JSC::WASMFunctionCompiler::buildImmediateF32): Deleted.
        (JSC::WASMFunctionCompiler::buildImmediateF64): Deleted.
        (JSC::WASMFunctionCompiler::buildGetLocal): Deleted.
        (JSC::WASMFunctionCompiler::buildGetGlobal): Deleted.
        (JSC::WASMFunctionCompiler::buildConvertType): Deleted.
        (JSC::WASMFunctionCompiler::buildLoad): Deleted.
        (JSC::WASMFunctionCompiler::buildStore): Deleted.
        (JSC::WASMFunctionCompiler::buildUnaryI32): Deleted.
        (JSC::WASMFunctionCompiler::buildUnaryF32): Deleted.
        (JSC::WASMFunctionCompiler::buildUnaryF64): Deleted.
        (JSC::WASMFunctionCompiler::buildBinaryI32): Deleted.
        (JSC::WASMFunctionCompiler::buildBinaryF32): Deleted.
        (JSC::WASMFunctionCompiler::buildBinaryF64): Deleted.
        (JSC::WASMFunctionCompiler::buildRelationalI32): Deleted.
        (JSC::WASMFunctionCompiler::buildRelationalF32): Deleted.
        (JSC::WASMFunctionCompiler::buildRelationalF64): Deleted.
        (JSC::WASMFunctionCompiler::buildMinOrMaxI32): Deleted.
        (JSC::WASMFunctionCompiler::buildMinOrMaxF64): Deleted.
        (JSC::WASMFunctionCompiler::buildCallInternal): Deleted.
        (JSC::WASMFunctionCompiler::buildCallIndirect): Deleted.
        (JSC::WASMFunctionCompiler::buildCallImport): Deleted.
        (JSC::WASMFunctionCompiler::appendExpressionList): Deleted.
        (JSC::WASMFunctionCompiler::discard): Deleted.
        (JSC::WASMFunctionCompiler::linkTarget): Deleted.
        (JSC::WASMFunctionCompiler::jumpToTarget): Deleted.
        (JSC::WASMFunctionCompiler::jumpToTargetIf): Deleted.
        (JSC::WASMFunctionCompiler::startLoop): Deleted.
        (JSC::WASMFunctionCompiler::endLoop): Deleted.
        (JSC::WASMFunctionCompiler::startSwitch): Deleted.
        (JSC::WASMFunctionCompiler::endSwitch): Deleted.
        (JSC::WASMFunctionCompiler::startLabel): Deleted.
        (JSC::WASMFunctionCompiler::endLabel): Deleted.
        (JSC::WASMFunctionCompiler::breakTarget): Deleted.
        (JSC::WASMFunctionCompiler::continueTarget): Deleted.
        (JSC::WASMFunctionCompiler::breakLabelTarget): Deleted.
        (JSC::WASMFunctionCompiler::continueLabelTarget): Deleted.
        (JSC::WASMFunctionCompiler::buildSwitch): Deleted.
        (JSC::WASMFunctionCompiler::localAddress): Deleted.
        (JSC::WASMFunctionCompiler::temporaryAddress): Deleted.
        (JSC::WASMFunctionCompiler::appendCall): Deleted.
        (JSC::WASMFunctionCompiler::appendCallWithExceptionCheck): Deleted.
        (JSC::WASMFunctionCompiler::emitNakedCall): Deleted.
        (JSC::WASMFunctionCompiler::appendCallSetResult): Deleted.
        (JSC::WASMFunctionCompiler::callOperation): Deleted.
        (JSC::WASMFunctionCompiler::boxArgumentsAndAdjustStackPointer): Deleted.
        (JSC::WASMFunctionCompiler::callAndUnboxResult): Deleted.
        (JSC::WASMFunctionCompiler::convertValueToInt32): Deleted.
        (JSC::WASMFunctionCompiler::convertValueToDouble): Deleted.
        (JSC::WASMFunctionCompiler::convertDoubleToValue): Deleted.
        * wasm/WASMFunctionParser.cpp: Removed.
        (JSC::nameOfType): Deleted.
        (JSC::WASMFunctionParser::checkSyntax): Deleted.
        (JSC::WASMFunctionParser::compile): Deleted.
        (JSC::WASMFunctionParser::parseFunction): Deleted.
        (JSC::WASMFunctionParser::parseLocalVariables): Deleted.
        (JSC::WASMFunctionParser::parseStatement): Deleted.
        (JSC::WASMFunctionParser::parseReturnStatement): Deleted.
        (JSC::WASMFunctionParser::parseBlockStatement): Deleted.
        (JSC::WASMFunctionParser::parseIfStatement): Deleted.
        (JSC::WASMFunctionParser::parseIfElseStatement): Deleted.
        (JSC::WASMFunctionParser::parseWhileStatement): Deleted.
        (JSC::WASMFunctionParser::parseDoStatement): Deleted.
        (JSC::WASMFunctionParser::parseLabelStatement): Deleted.
        (JSC::WASMFunctionParser::parseBreakStatement): Deleted.
        (JSC::WASMFunctionParser::parseBreakLabelStatement): Deleted.
        (JSC::WASMFunctionParser::parseContinueStatement): Deleted.
        (JSC::WASMFunctionParser::parseContinueLabelStatement): Deleted.
        (JSC::WASMFunctionParser::parseSwitchStatement): Deleted.
        (JSC::WASMFunctionParser::parseExpression): Deleted.
        (JSC::WASMFunctionParser::parseExpressionI32): Deleted.
        (JSC::WASMFunctionParser::parseConstantPoolIndexExpressionI32): Deleted.
        (JSC::WASMFunctionParser::parseImmediateExpressionI32): Deleted.
        (JSC::WASMFunctionParser::parseUnaryExpressionI32): Deleted.
        (JSC::WASMFunctionParser::parseBinaryExpressionI32): Deleted.
        (JSC::WASMFunctionParser::parseRelationalI32ExpressionI32): Deleted.
        (JSC::WASMFunctionParser::parseRelationalF32ExpressionI32): Deleted.
        (JSC::WASMFunctionParser::parseRelationalF64ExpressionI32): Deleted.
        (JSC::WASMFunctionParser::parseMinOrMaxExpressionI32): Deleted.
        (JSC::WASMFunctionParser::parseExpressionF32): Deleted.
        (JSC::WASMFunctionParser::parseConstantPoolIndexExpressionF32): Deleted.
        (JSC::WASMFunctionParser::parseImmediateExpressionF32): Deleted.
        (JSC::WASMFunctionParser::parseUnaryExpressionF32): Deleted.
        (JSC::WASMFunctionParser::parseBinaryExpressionF32): Deleted.
        (JSC::WASMFunctionParser::parseExpressionF64): Deleted.
        (JSC::WASMFunctionParser::parseConstantPoolIndexExpressionF64): Deleted.
        (JSC::WASMFunctionParser::parseImmediateExpressionF64): Deleted.
        (JSC::WASMFunctionParser::parseUnaryExpressionF64): Deleted.
        (JSC::WASMFunctionParser::parseBinaryExpressionF64): Deleted.
        (JSC::WASMFunctionParser::parseMinOrMaxExpressionF64): Deleted.
        (JSC::WASMFunctionParser::parseExpressionVoid): Deleted.
        (JSC::WASMFunctionParser::parseGetLocalExpression): Deleted.
        (JSC::WASMFunctionParser::parseGetGlobalExpression): Deleted.
        (JSC::WASMFunctionParser::parseSetLocal): Deleted.
        (JSC::WASMFunctionParser::parseSetGlobal): Deleted.
        (JSC::WASMFunctionParser::parseMemoryAddress): Deleted.
        (JSC::WASMFunctionParser::parseLoad): Deleted.
        (JSC::WASMFunctionParser::parseStore): Deleted.
        (JSC::WASMFunctionParser::parseCallArguments): Deleted.
        (JSC::WASMFunctionParser::parseCallInternal): Deleted.
        (JSC::WASMFunctionParser::parseCallIndirect): Deleted.
        (JSC::WASMFunctionParser::parseCallImport): Deleted.
        (JSC::WASMFunctionParser::parseConditional): Deleted.
        (JSC::WASMFunctionParser::parseComma): Deleted.
        (JSC::WASMFunctionParser::parseConvertType): Deleted.
        * wasm/WASMFunctionParser.h: Removed.
        (JSC::WASMFunctionParser::WASMFunctionParser): Deleted.
        * wasm/WASMFunctionSyntaxChecker.h: Removed.
        (JSC::WASMFunctionSyntaxChecker::MemoryAddress::MemoryAddress): Deleted.
        (JSC::WASMFunctionSyntaxChecker::startFunction): Deleted.
        (JSC::WASMFunctionSyntaxChecker::endFunction): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildSetLocal): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildSetGlobal): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildReturn): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildImmediateI32): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildImmediateF32): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildImmediateF64): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildGetLocal): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildGetGlobal): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildConvertType): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildLoad): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildStore): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildUnaryI32): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildUnaryF32): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildUnaryF64): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildBinaryI32): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildBinaryF32): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildBinaryF64): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildRelationalI32): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildRelationalF32): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildRelationalF64): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildMinOrMaxI32): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildMinOrMaxF64): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildCallInternal): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildCallImport): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildCallIndirect): Deleted.
        (JSC::WASMFunctionSyntaxChecker::appendExpressionList): Deleted.
        (JSC::WASMFunctionSyntaxChecker::discard): Deleted.
        (JSC::WASMFunctionSyntaxChecker::linkTarget): Deleted.
        (JSC::WASMFunctionSyntaxChecker::jumpToTarget): Deleted.
        (JSC::WASMFunctionSyntaxChecker::jumpToTargetIf): Deleted.
        (JSC::WASMFunctionSyntaxChecker::startLoop): Deleted.
        (JSC::WASMFunctionSyntaxChecker::endLoop): Deleted.
        (JSC::WASMFunctionSyntaxChecker::startSwitch): Deleted.
        (JSC::WASMFunctionSyntaxChecker::endSwitch): Deleted.
        (JSC::WASMFunctionSyntaxChecker::startLabel): Deleted.
        (JSC::WASMFunctionSyntaxChecker::endLabel): Deleted.
        (JSC::WASMFunctionSyntaxChecker::breakTarget): Deleted.
        (JSC::WASMFunctionSyntaxChecker::continueTarget): Deleted.
        (JSC::WASMFunctionSyntaxChecker::breakLabelTarget): Deleted.
        (JSC::WASMFunctionSyntaxChecker::continueLabelTarget): Deleted.
        (JSC::WASMFunctionSyntaxChecker::buildSwitch): Deleted.
        (JSC::WASMFunctionSyntaxChecker::stackHeight): Deleted.
        (JSC::WASMFunctionSyntaxChecker::updateTempStackHeight): Deleted.
        (JSC::WASMFunctionSyntaxChecker::updateTempStackHeightForCall): Deleted.
        * wasm/WASMModuleParser.cpp: Removed.
        (JSC::WASMModuleParser::WASMModuleParser): Deleted.
        (JSC::WASMModuleParser::parse): Deleted.
        (JSC::WASMModuleParser::parseModule): Deleted.
        (JSC::WASMModuleParser::parseConstantPoolSection): Deleted.
        (JSC::WASMModuleParser::parseSignatureSection): Deleted.
        (JSC::WASMModuleParser::parseFunctionImportSection): Deleted.
        (JSC::WASMModuleParser::parseGlobalSection): Deleted.
        (JSC::WASMModuleParser::parseFunctionDeclarationSection): Deleted.
        (JSC::WASMModuleParser::parseFunctionPointerTableSection): Deleted.
        (JSC::WASMModuleParser::parseFunctionDefinitionSection): Deleted.
        (JSC::WASMModuleParser::parseFunctionDefinition): Deleted.
        (JSC::WASMModuleParser::parseExportSection): Deleted.
        (JSC::WASMModuleParser::getImportedValue): Deleted.
        (JSC::parseWebAssembly): Deleted.
        * wasm/WASMModuleParser.h: Removed.
        * wasm/WASMReader.cpp: Removed.
        (JSC::WASMReader::readUInt32): Deleted.
        (JSC::WASMReader::readFloat): Deleted.
        (JSC::WASMReader::readDouble): Deleted.
        (JSC::WASMReader::readCompactInt32): Deleted.
        (JSC::WASMReader::readCompactUInt32): Deleted.
        (JSC::WASMReader::readString): Deleted.
        (JSC::WASMReader::readType): Deleted.
        (JSC::WASMReader::readExpressionType): Deleted.
        (JSC::WASMReader::readExportFormat): Deleted.
        (JSC::WASMReader::readByte): Deleted.
        (JSC::WASMReader::readOpStatement): Deleted.
        (JSC::WASMReader::readOpExpressionI32): Deleted.
        (JSC::WASMReader::readOpExpressionF32): Deleted.
        (JSC::WASMReader::readOpExpressionF64): Deleted.
        (JSC::WASMReader::readOpExpressionVoid): Deleted.
        (JSC::WASMReader::readVariableTypes): Deleted.
        (JSC::WASMReader::readOp): Deleted.
        (JSC::WASMReader::readSwitchCase): Deleted.
        * wasm/WASMReader.h: Removed.
        (JSC::WASMReader::WASMReader): Deleted.
        (JSC::WASMReader::offset): Deleted.
        (JSC::WASMReader::setOffset): Deleted.

2016-08-05  Keith Miller  <keith_miller@apple.com>

        Fix 32-bit OverridesHasInstance in the DFG.
        https://bugs.webkit.org/show_bug.cgi?id=160600

        Reviewed by Mark Lam.

        In https://trac.webkit.org/changeset/204140, we fixed an issue where the DFG might
        do the wrong thing if it proved that the Symbol.hasInstance value for a constructor
        was a constant late in compilation. That fix was ommited from the 32-bit version,
        causing the new test to fail.

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

2016-08-04  Saam Barati  <sbarati@apple.com>

        Restore CodeBlock jettison code to jettison when a CodeBlock has been alive for a long time
        https://bugs.webkit.org/show_bug.cgi?id=151241

        Reviewed by Benjamin Poulain.

        This patch rolls back in the jettisoning policy from https://bugs.webkit.org/show_bug.cgi?id=149727.
        We can now jettison a CodeBlock when it has been alive for a long time
        and is only pointed to by its owner executable. I haven't been able to get this
        patch to crash on anything it used to crash on, so I suspect we've fixed the bugs that
        were causing this before. I've also added some stress options for this feature that
        will cause us to either eagerly old-age jettison or to old-age jettison whenever it's legal.
        These options helped me find a bug where we would ask an Executable to create a CodeBlock,
        and then the Executable would do some other allocations, causing a GC, immediately causing
        the CodeBlock to jettison. There is a small chance that this was the bug we were seeing before,
        however, it's unlikely given that the previous timing metrics require at least 5 second between
        compiling to jettisoning.

        This patch also enables the stress options for various modes
        of JSC stress tests.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::shouldJettisonDueToWeakReference):
        (JSC::timeToLive):
        (JSC::CodeBlock::shouldJettisonDueToOldAge):
        * interpreter/CallFrame.h:
        (JSC::ExecState::callee):
        (JSC::ExecState::unsafeCallee):
        (JSC::ExecState::codeBlock):
        (JSC::ExecState::addressOfCodeBlock):
        (JSC::ExecState::unsafeCodeBlock):
        (JSC::ExecState::scope):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        (JSC::Interpreter::prepareForRepeatCall):
        * jit/JITOperations.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::setUpCall):
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::installCode):
        (JSC::setupJIT):
        (JSC::ScriptExecutable::prepareForExecutionImpl):
        * runtime/Executable.h:
        (JSC::ScriptExecutable::prepareForExecution):
        * runtime/Options.h:

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

        [ES6] JSModuleNamespaceObject's Symbol.iterator function should have name
        https://bugs.webkit.org/show_bug.cgi?id=160549

        Reviewed by Saam Barati.

        ES6 Module's namespace[Symbol.iterator] function should have the name, "[Symbol.iterator]".

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

2016-08-04  Keith Miller  <keith_miller@apple.com>

        ASSERTION FAILED: !hasInstanceValueNode->isCellConstant() || defaultHasInstanceFunction == hasInstanceValueNode->asCell()
        https://bugs.webkit.org/show_bug.cgi?id=160562
        <rdar://problem/27704825>

        Reviewed by Mark Lam.

        This patch fixes an issue where we would emit incorrect code in the DFG when constant folding would
        convert a GetByOffset into a constant late in compilation. Additionally, it removes invalid assertions
        associated with the assumption that this could not happen.

        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileOverridesHasInstance): Deleted.

2016-08-04  Keith Miller  <keith_miller@apple.com>

        Remove unused intrinsic member of NativeExecutable
        https://bugs.webkit.org/show_bug.cgi?id=160560

        Reviewed by Saam Barati.

        NativeExecutable has an Intrinsic member. It appears that this member is never
        used. Instead we use the Intrinsic member NativeExecutable's super class,
        ExecutableBase.

        * runtime/Executable.h:

2016-08-04  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Speed up InPlaceAbstractState::endBasicBlock()
        https://bugs.webkit.org/show_bug.cgi?id=160539

        Reviewed by Mark Lam.

        This patch does small improvements to our handling
        of value propagation to the successors.

        One key insight is that using HashMap to map Nodes
        to Value in valuesAtTail is too inefficient at the scale
        we use it. Instead, I reuse our existing mapping
        from every Node to its value, abstracted by forNode().

        Since we are not going to use the mapping after endBasicBlock()
        I can replace whatever we had there. The next beginBasicBlock()
        will setup the new value as needed.

        In endBasicBlock(), valuesAtTail is now a vector of all values live
        at tail. For each node, I merge the previous live at tail with
        the new value, then replace the value in the mapping.
        Liveness Analysis guarantees we won't have duplicates there which
        make the replacement sound.

        Next, when propagating, I take the vector of values lives at head
        and use the global node->value mapping to find its new abstract value.
        Again, Liveness Analysis guarantees I won't find a value live at head
        that was not replaced by the merging at tail of the predecessor.

        All our live lists have become vectors instead of HashTable.
        The mapping from Node to Value is always done by array indexing.
        Same big-O, much smaller constant.

        * dfg/DFGAtTailAbstractState.cpp:
        (JSC::DFG::AtTailAbstractState::AtTailAbstractState):
        (JSC::DFG::AtTailAbstractState::createValueForNode):
        (JSC::DFG::AtTailAbstractState::forNode):
        * dfg/DFGAtTailAbstractState.h:
        I did not look much into this state, I just made it equivalent
        to the previous mapping.

        * dfg/DFGBasicBlock.h:
        * dfg/DFGCFAPhase.cpp:
        (JSC::DFG::CFAPhase::performBlockCFA):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::InPlaceAbstractState::endBasicBlock):

        (JSC::DFG::InPlaceAbstractState::mergeStateAtTail):
        AbstractValue is big enough that we really don't want to copy it twice.

        (JSC::DFG::InPlaceAbstractState::merge):
        (JSC::DFG::setLiveValues): Deleted.
        * dfg/DFGInPlaceAbstractState.h:

        * dfg/DFGPhiChildren.h:
        This is heap allocated by AbstractInterpreter. It should use fastMalloc().

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

        [ES7] Update features.json for exponentiation expression
        https://bugs.webkit.org/show_bug.cgi?id=160541

        Reviewed by Mark Lam.

        * features.json:

2016-08-03  Chris Dumez  <cdumez@apple.com>

        Drop DocumentType.internalSubset attribute
        https://bugs.webkit.org/show_bug.cgi?id=160530

        Reviewed by Alex Christensen.

        Drop DocumentType.internalSubset attribute.

        * inspector/protocol/DOM.json:

2016-08-03  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Improve the memory locality of DFG Node's AbstractValues
        https://bugs.webkit.org/show_bug.cgi?id=160443

        Reviewed by Mark Lam.

        The AbstractInterpreter spends a lot of time on memory operations
        for AbstractValues. This patch attempts to improve the situation
        by putting the values closer together in memory.

        First, AbstractValue is moved out of DFG::Node and it kept in
        a vector addressed by node indices.

        I initially moved them to InPlaceAbstractState but I quickly discovered
        initializing the values in the vector was costly.
        I moved the vector to Graph as a cache shared by every instantiation of
        InPlaceAbstractState. It is mainly there to avoid constructors and destructors
        of AbstractValue. The patch of https://bugs.webkit.org/show_bug.cgi?id=160370
        should also help eventually.

        I instrumented CFA to find how packed is SparseCollection.
        The answer is it can be very sparse, which is bad for CFA.
        I added packIndices() to repack the collection before running
        liveness since that's where we start using the memory intensively.
        This is a measurable improvement but it implies we can no longer
        keep indices on a side channel between phases since they may change.

        * b3/B3SparseCollection.h:
        (JSC::B3::SparseCollection::packIndices):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::packNodeIndices):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::abstractValuesCache):
        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::InPlaceAbstractState::InPlaceAbstractState):
        * dfg/DFGInPlaceAbstractState.h:
        (JSC::DFG::InPlaceAbstractState::forNode):
        * dfg/DFGLivenessAnalysisPhase.cpp:
        (JSC::DFG::performLivenessAnalysis):
        * dfg/DFGNode.h:

2016-08-03  Caitlin Potter  <caitp@igalia.com>

        Clarify SyntaxErrors around yield and unskip tests
        https://bugs.webkit.org/show_bug.cgi?id=158460

        Reviewed by Saam Barati.

        Fix and unskip tests which erroneously asserted that `yield` is not a
        valid BindingIdentifier, and improve error message for YieldExpressions
        occuring in Arrow formal parameters.

        * parser/Parser.cpp:
        (JSC::Scope::MaybeParseAsGeneratorForScope::MaybeParseAsGeneratorForScope):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseYieldExpression):
        * parser/Parser.h:

2016-08-03  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION(r203368): broke some test262 tests
        https://bugs.webkit.org/show_bug.cgi?id=160479

        Reviewed by Mark Lam.
        
        The optimization in r203368 overlooked a subtle detail: freezing should not set ReadOnly on
        Accessor properties.

        * runtime/Structure.cpp:
        (JSC::Structure::nonPropertyTransition):
        * runtime/StructureTransitionTable.h:
        (JSC::setsDontDeleteOnAllProperties):
        (JSC::setsReadOnlyOnNonAccessorProperties):
        (JSC::setsReadOnlyOnAllProperties): Deleted.

2016-08-03  Csaba Osztrogonác  <ossy@webkit.org>

        Lacking support on a arm-traditional disassembler.
        https://bugs.webkit.org/show_bug.cgi?id=123717

        Reviewed by Mark Lam.

        * CMakeLists.txt:
        * disassembler/ARMLLVMDisassembler.cpp: Added, based on pre r196729 LLVMDisassembler, but it is ARM traditional only now.
        (JSC::tryToDisassemble):

2016-08-03  Saam Barati  <sbarati@apple.com>

        Implement nested rest destructuring w.r.t the ES7 spec
        https://bugs.webkit.org/show_bug.cgi?id=160423

        Reviewed by Filip Pizlo.

        The spec has updated the BindingRestElement grammar production to be:
        BindingRestElement:
           BindingIdentifier
           BindingingPattern.

        It used to only allow BindingIdentifier in the grammar production.
        I've updated our engine to account for this. The semantics are exactly
        what you'd expect.  For example:
        `let [a, ...[b, ...c]] = expr();`
        means that we create an array for the first rest element `...[b, ...c]`
        and then perform the binding of `[b, ...c]` to that array. And so on, 
        applied recursively through the pattern.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::RestParameterNode::collectBoundIdentifiers):
        (JSC::RestParameterNode::toString):
        (JSC::RestParameterNode::bindValue):
        (JSC::RestParameterNode::emit):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createBindingLocation):
        (JSC::ASTBuilder::createRestParameter):
        (JSC::ASTBuilder::createAssignmentElement):
        * parser/NodeConstructors.h:
        (JSC::AssignmentElementNode::AssignmentElementNode):
        (JSC::RestParameterNode::RestParameterNode):
        (JSC::DestructuringAssignmentNode::DestructuringAssignmentNode):
        * parser/Nodes.h:
        (JSC::RestParameterNode::name): Deleted.
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseDestructuringPattern):
        (JSC::Parser<LexerType>::parseFormalParameters):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::operatorStackPop):

2016-08-03  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Fix Windows build after r204065

        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::observeTransitions):
        AbstractValue is bigger on Windows for an unknown reason.

2016-08-02  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Fix 32bits jsc after r204065

        Default constructed JSValue() are not equal to zero in 32bits.

        * dfg/DFGAbstractValue.h:
        (JSC::DFG::AbstractValue::AbstractValue):

2016-08-02  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Simplify the initialization of AbstractValue in the AbstractInterpreter
        https://bugs.webkit.org/show_bug.cgi?id=160370

        Reviewed by Saam Barati.

        We use a ton of AbstractValue to run the Abstract Interpreter.

        When we set up the initial values, the compiler sets
        a zero on a first word, a one on a second word, and a zero
        again on a third word.
        Since no vector or double-store can deal with 3 words, unrolling
        is done by repeating those instructions.

        The reason for the one was TinyPtrSet. It needed a flag for
        empty value to identify the set as thin. I flipped the flag to "fat"
        to make sure TinyPtrSet is initialized to zero.

        With that done, I just had to clean some places to make
        the initialization shorter.
        It makes the binary easier to follow but this does not help with
        the bigger problem: the time spent per block on Abstract Interpreter.

        * bytecode/Operands.h:
        The traits were useless, no client code defines it.

        (JSC::Operands::Operands):
        (JSC::Operands::ensureLocals):
        Because of the size of the function, llvm is not inlining it.
        We were literally loading 3 registers from memory and storing
        them in the vector.
        Now that AbstractValue has a VectorTraits, we should just rely
        on the memset of Vector when possible.

        (JSC::Operands::getLocal):
        (JSC::Operands::setArgumentFirstTime):
        (JSC::Operands::setLocalFirstTime):
        (JSC::Operands::clear):
        (JSC::OperandValueTraits::defaultValue): Deleted.
        (JSC::OperandValueTraits::isEmptyForDump): Deleted.
        * bytecode/OperandsInlines.h:
        (JSC::Operands<T>::dumpInContext):
        (JSC::Operands<T>::dump):
        (JSC::Traits>::dumpInContext): Deleted.
        (JSC::Traits>::dump): Deleted.
        * dfg/DFGAbstractValue.cpp:
        * dfg/DFGAbstractValue.h:
        (JSC::DFG::AbstractValue::AbstractValue):

2016-08-02  Saam Barati  <sbarati@apple.com>

        update a class extending null w.r.t the ES7 spec
        https://bugs.webkit.org/show_bug.cgi?id=160417

        Reviewed by Keith Miller.

        When a class extends null, it should not be marked as a derived class.
        This was changed in the ES2016 spec, and this patch makes the needed
        changes in JSC to follow the spec. This allows classes to extend
        null and have their default constructor invoked without throwing an exception.
        This also prevents |this| from being under TDZ at the start of the constructor.
        Because ES6 allows arbitrary expressions in the `class <ident> extends <expr>`
        syntax, we don't know statically if a constructor is extending null or not.
        Therefore, we don't always know statically if it's a base or derived constructor.
        I solved this by putting a boolean on the constructor function under a private
        symbol named isDerivedConstructor when doing class construction. We only need
        to put this boolean on constructors that may extend null. Constructors that are
        declared in a class with no extends syntax can tell statically that they are a base constructor.

        I've also renamed the ConstructorKind::Derived enum value to be
        ConstructorKind::Extends to better indicate that we can't answer
        the "am I a derived constructor?" question statically.

        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createDefaultConstructor):
        * builtins/BuiltinNames.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
        (JSC::BytecodeGenerator::emitReturn):
        (JSC::BytecodeGenerator::emitLoadArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::ensureThis):
        (JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::makeFunction):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::EvalFunctionCallNode::emitBytecode):
        (JSC::FunctionCallValueNode::emitBytecode):
        (JSC::FunctionNode::emitBytecode):
        (JSC::ClassExprNode::emitBytecode):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::Parser):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parseMemberExpression):
        * parser/ParserModes.h:

2016-08-02  Enrica Casucci  <enrica@apple.com>

        Allow building with content filtering disabled.
        https://bugs.webkit.org/show_bug.cgi?id=160454

        Reviewed by Simon Fraser.

        * Configurations/FeatureDefines.xcconfig:

2016-08-02  Csaba Osztrogonác  <ossy@webkit.org>

        [ARM] Disable Inline Caching on ARMv7 traditional until proper fix
        https://bugs.webkit.org/show_bug.cgi?id=159759

        Reviewed by Saam Barati.

        * jit/JITMathIC.h:
        (JSC::JITMathIC::generateInline):

2016-08-01  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION (r203990): JSC Debug test stress/arity-check-ftl-throw.js failing
        https://bugs.webkit.org/show_bug.cgi?id=160438

        Reviewed by Mark Lam.
        
        In r203990 I fixed a bug where CommonSlowPaths.h/arityCheckFor() was basically failing at
        catching stack overflow due to large parameter count. It would only catch regular old stack
        overflow, like if the frame pointer was already past the limit.
        
        This had a secondary problem: unfortunately all of our tests for what happens when you overflow
        the stack due to large parameter count were not going down that path at all, so we haven't had
        test coverage for this in ages.  There were bugs in all tiers of the engine when handling this
        case.

        We need to be able to roll back the topCallFrame on paths that are meant to throw an exception
        from the caller. Otherwise, we'd crash in StackVisitor because it would see a busted stack
        frame. Rolling back like this "just works" except when the caller is the VM entry frame. I had
        some choices here. I could have forced anyone who is rolling back to always skip VM entry
        frames. They can't do it in a way that changes the value of VM::topVMEntryFrame, which is what
        a stack frame roll back normally does, since exception unwinding needs to see the current value
        of topVMEntryFrame. So, we have a choice to either try to magically avoid all of the paths that
        look at topCallFrame, or give topCallFrame a state that unambiguously signals that we are
        sitting right on top of a VM entry frame without having succeeded at making a JS call. The only
        place that really needs to know is StackVisitor, which wants to start scanning at topCallFrame.
        To signal this, I could have either made topCallFrame point to the real top JS call frame
        without also rolling back topVMEntryFrame, or I could make topCallFrame == topVMEntryFrame. The
        latter felt somehow cleaner. I filed a bug (https://bugs.webkit.org/show_bug.cgi?id=160441) for
        converting topCallFrame to a void*, which would give us a chance to harden the rest of the
        engine against this case.
        
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::StackVisitor):
        We may do ShadowChicken processing, which invokes StackVisitor, when we have topCallFrame
        pointing at topVMEntryFrame. This teaches StackVisitor how to handle this case. I believe that
        StackVisitor is the only place that needs to be taught about this at this time, because it's
        one of the few things that access topCallFrame along this special path.
        
        * jit/JITOperations.cpp: Roll back the top call frame.
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL): Roll back the top call frame.

2016-08-01  Benjamin Poulain  <bpoulain@apple.com>

        [JSC][ARM64] Fix branchTest32/64 taking an immediate as mask
        https://bugs.webkit.org/show_bug.cgi?id=160439

        Reviewed by Filip Pizlo.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::branchTest64):
        * b3/air/AirOpcode.opcodes:
        Fix the ARM64 codegen to lower BitImm64 without using a scratch register.

2016-07-22  Filip Pizlo  <fpizlo@apple.com>

        [B3] Fusing immediates into test instructions should work again
        https://bugs.webkit.org/show_bug.cgi?id=160073

        Reviewed by Sam Weinig.

        When we introduced BitImm, we forgot to change the Branch(BitAnd(value, constant))
        fusion.  This emits test instructions, so it should use BitImm for the constant.  But it
        was still using Imm!  This meant that isValidForm() always returned false.
        
        This fixes the code path to use BitImm, and turns off our use of BitImm64 on x86 since
        it provides no benefit on x86 and has some risk (the code appears to play fast and loose
        with the scratch register).
        
        This is not an obvious progression on anything, so I added comprehensive tests to
        testb3, which check that we selected the optimal instruction in a variety of situations.
        We should add more tests like this!

        Rolling this back in after fixing ARM64. The bug was that branchTest32|64 on ARM64 doesn't
        actually support BitImm or BitImm64, at least not yet. Disabling that in AirOpcodes makes
        this patch not a regression on ARM64. That change was reviewed by Benjamin Poulain.

        * b3/B3BasicBlock.h:
        (JSC::B3::BasicBlock::successorBlock):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::createGenericCompare):
        * b3/B3LowerToAir.h:
        * b3/air/AirArg.cpp:
        (JSC::B3::Air::Arg::isRepresentableAs):
        (JSC::B3::Air::Arg::usesTmp):
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::isRepresentableAs):
        (JSC::B3::Air::Arg::castToType):
        (JSC::B3::Air::Arg::asNumber):
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::size):
        (JSC::B3::Air::Code::at):
        * b3/air/AirOpcode.opcodes:
        * b3/air/AirValidate.h:
        * b3/air/opcode_generator.rb:
        * b3/testb3.cpp:
        (JSC::B3::compile):
        (JSC::B3::compileAndRun):
        (JSC::B3::lowerToAirForTesting):
        (JSC::B3::testSomeEarlyRegister):
        (JSC::B3::testBranchBitAndImmFusion):
        (JSC::B3::zero):
        (JSC::B3::run):

2016-08-01  Filip Pizlo  <fpizlo@apple.com>

        Rationalize varargs stack overflow checks
        https://bugs.webkit.org/show_bug.cgi?id=160425

        Reviewed by Michael Saboff.

        * ftl/FTLLink.cpp:
        (JSC::FTL::link): AboveOrEqual 0 is a tautology. The code meant GreaterThanOrEqual, since the error code is -1.
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::arityCheckFor): Use roundUpToMultipleOf(), which is almost certainly what we meant when we said %.

2016-08-01  Saam Barati  <sbarati@apple.com>

        Sub should be a Math IC
        https://bugs.webkit.org/show_bug.cgi?id=160270

        Reviewed by Mark Lam.

        This makes Sub an IC like Mul and Add. I'm seeing the following
        improvements of average Sub size on Unity and JetStream:

                   |   JetStream  |  Unity 3D  |
             ------| -------------|--------------
              Old  |   202 bytes  |  205 bytes |
             ------| -------------|--------------
              New  |   134  bytes |  134 bytes |
             ------------------------------------

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::addJITMulIC):
        (JSC::CodeBlock::addJITSubIC):
        (JSC::CodeBlock::findStubInfo):
        (JSC::CodeBlock::dumpMathICStats):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::stubInfoBegin):
        (JSC::CodeBlock::stubInfoEnd):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithSub):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub):
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_sub):
        (JSC::JIT::emitSlow_op_sub):
        (JSC::JIT::emit_op_pow):
        * jit/JITMathIC.h:
        * jit/JITMathICForwards.h:
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITSubGenerator.cpp:
        (JSC::JITSubGenerator::generateInline):
        (JSC::JITSubGenerator::generateFastPath):
        * jit/JITSubGenerator.h:
        (JSC::JITSubGenerator::JITSubGenerator):
        (JSC::JITSubGenerator::isLeftOperandValidConstant):
        (JSC::JITSubGenerator::isRightOperandValidConstant):
        (JSC::JITSubGenerator::arithProfile):
        (JSC::JITSubGenerator::didEmitFastPath): Deleted.
        (JSC::JITSubGenerator::endJumpList): Deleted.
        (JSC::JITSubGenerator::slowPathJumpList): Deleted.

2016-08-01  Keith Miller  <keith_miller@apple.com>

        We should not keep the JavaScript tests inside the Source/JavaScriptCore/ directory.
        https://bugs.webkit.org/show_bug.cgi?id=160372

        Rubber stamped by Geoffrey Garen.

        This patch moves all the JavaScript tests from Source/JavaScriptCore/tests to
        a new top level directory, JSTests. Having the tests in the Source directory
        was both confusing an inconvenient for people that just want to checkout the
        source code of WebKit. Since there is no other obvious place to put all the
        JavaScript tests a new top level directory seemed the most sensible.

        * tests/: Deleted.

2016-07-31  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Should check Test262Error correctly
        https://bugs.webkit.org/show_bug.cgi?id=159862

        Reviewed by Saam Barati.

        Test262Error in the harness does not have "name" property.
        Rather than checking "name" property, peforming `instanceof` is better to check the class of the exception.

        * jsc.cpp:
        (checkUncaughtException):
        * runtime/JSObject.h:
        * tests/test262.yaml:

2016-07-31  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Module binding can be exported by multiple names
        https://bugs.webkit.org/show_bug.cgi?id=160343

        Reviewed by Saam Barati.

        ES6 Module can export the same local binding by using multiple names.
        For example,

            ```
            var value = 42;

            export { value };
            export { value as value2 };
            ```

        Currently, we only allowed one local binding to be exported with one name. So, in the above case,
        the local binding "value" is exported as "value2" and "value" name is not exported. This is wrong.

        To fix this issue, we collect the correspondence (local name => exported name) to the local bindings
        in the parser. Previously, we only maintained the exported local bindings in the parser. And utilize
        this information when creating the export entries in ModuleAnalyzer.

        And this patch also moves ModuleScopeData from the Scope object to the Parser class since exported
        names should be managed per-module, not per-scope.

        This change fixes several test262 failures.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * parser/ModuleAnalyzer.cpp:
        (JSC::ModuleAnalyzer::exportVariable):
        (JSC::ModuleAnalyzer::analyze):
        (JSC::ModuleAnalyzer::exportedBinding): Deleted.
        (JSC::ModuleAnalyzer::declareExportAlias): Deleted.
        * parser/ModuleAnalyzer.h:
        * parser/ModuleScopeData.h: Copied from Source/JavaScriptCore/parser/ModuleAnalyzer.h.
        (JSC::ModuleScopeData::create):
        (JSC::ModuleScopeData::exportedBindings):
        (JSC::ModuleScopeData::exportName):
        (JSC::ModuleScopeData::exportBinding):
        * parser/Nodes.cpp:
        (JSC::ProgramNode::ProgramNode):
        (JSC::ModuleProgramNode::ModuleProgramNode):
        (JSC::EvalNode::EvalNode):
        (JSC::FunctionNode::FunctionNode):
        * parser/Nodes.h:
        (JSC::ModuleProgramNode::moduleScopeData):
        * parser/NodesAnalyzeModule.cpp:
        (JSC::ExportDefaultDeclarationNode::analyzeModule):
        (JSC::ExportNamedDeclarationNode::analyzeModule): Deleted.
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::Parser):
        (JSC::Parser<LexerType>::parseModuleSourceElements):
        (JSC::Parser<LexerType>::parseVariableDeclarationList):
        (JSC::Parser<LexerType>::createBindingPattern):
        (JSC::Parser<LexerType>::parseFunctionDeclaration):
        (JSC::Parser<LexerType>::parseClassDeclaration):
        (JSC::Parser<LexerType>::parseExportSpecifier):
        (JSC::Parser<LexerType>::parseExportDeclaration):
        * parser/Parser.h:
        (JSC::Parser::exportName):
        (JSC::Parser<LexerType>::parse):
        (JSC::ModuleScopeData::create): Deleted.
        (JSC::ModuleScopeData::exportedBindings): Deleted.
        (JSC::ModuleScopeData::exportName): Deleted.
        (JSC::ModuleScopeData::exportBinding): Deleted.
        (JSC::Scope::Scope): Deleted.
        (JSC::Scope::setSourceParseMode): Deleted.
        (JSC::Scope::moduleScopeData): Deleted.
        (JSC::Scope::setIsModule): Deleted.
        * tests/modules/aliased-names.js: Added.
        * tests/modules/aliased-names/main.js: Added.
        (change):
        * tests/stress/modules-syntax-error-with-names.js:
        (export.Cocoa):
        (SyntaxError.Cannot.export.a.duplicate.name):
        * tests/test262.yaml:

2016-07-30  Mark Lam  <mark.lam@apple.com>

        Assertion failure while setting the length of an ArrayClass array.
        https://bugs.webkit.org/show_bug.cgi?id=160381
        <rdar://problem/27328703>

        Reviewed by Filip Pizlo.

        When setting large length values, we're currently treating ArrayClass as a
        ContiguousIndexingType array.  This results in an assertion failure.  This is
        now fixed.

        There are currently only 2 places where we create arrays with indexing type
        ArrayClass: ArrayPrototype and RuntimeArray.  The fix in JSArray:;setLength()
        takes care of ArrayPrototype.

        RuntimeArray already checks for the setting of its length property, and will
        throw a RangeError.  Hence, there's no change is needed for the RuntimeArray.
        Instead, I added some test cases ensure that the check and throw behavior does
        not change without notice.

        * runtime/JSArray.cpp:
        (JSC::JSArray::setLength):
        * tests/stress/array-setLength-on-ArrayClass-with-large-length.js: Added.
        (toString):
        (assertEqual):
        * tests/stress/array-setLength-on-ArrayClass-with-small-length.js: Added.
        (toString):
        (assertEqual):

2016-07-29  Keith Miller  <keith_miller@apple.com>

        TypedArray super constructor has some incompatabilities
        https://bugs.webkit.org/show_bug.cgi?id=160369

        Reviewed by Filip Pizlo.

        This patch fixes the length proprety of the TypedArray super constructor.
        Additionally, the TypedArray super constructor should no longer be callable.

        Also, this patch fixes the expected result of some test262 tests.

        * runtime/JSTypedArrayViewConstructor.cpp:
        (JSC::JSTypedArrayViewConstructor::finishCreation):
        (JSC::constructTypedArrayView):
        (JSC::JSTypedArrayViewConstructor::getCallData):
        * tests/test262.yaml:

2016-07-29  Jonathan Bedard  <jbedard@apple.com>

        Undefined Behavior in JSValue cast from NaN
        https://bugs.webkit.org/show_bug.cgi?id=160322

        Reviewed by Mark Lam.

        JSValues can be constructed from doubles, and in some cases, are deliberately constructed with NaN values.

        In circumstances where NaN is bound through the default JSValue constructor, however, an undefined conversion
        to int32_t occurs.  While the subsequent if statement should fail and construct the JSValue through the explicit
        double constructor, given that the deliberate use of NaN is fairly common, it seems that the jsNaN() function
        should immediately call the explicit double constructor both for efficiency and to prevent inadvertent
        suppressing of any other bugs which may be instantiating a JSValue with a NaN double.

        * runtime/JSCJSValueInlines.h:
        (JSC::jsNaN): Explicit double construction for NaN JSValues to avoid undefined behavior.

2016-07-29  Michael Saboff  <msaboff@apple.com>

        Refactor DFG::Node::hasLocal() to accessesStack()
        https://bugs.webkit.org/show_bug.cgi?id=160357

        Reviewed by Filip Pizlo.

        Refactoring in preparation for using register arguments for JavaScript calls.

        Renamed Node::hasLocal() to Node::accessesStack() and changed all uses accordingly.
        Also changed uses of Node::hasVariableAccessData() to accessesStack() where that
        use guards stack operation logic associated with the Node's VariableAccessData.

        The hasVariableAccessData() check now implies no more than the node has a
        VariableAccessData and nothing about its use of that data to coordinate stack   
        accesses.

        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
        * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
        (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlock):
        * dfg/DFGMaximalFlushInsertionPhase.cpp:
        (JSC::DFG::MaximalFlushInsertionPhase::treatRegularBlock):
        (JSC::DFG::MaximalFlushInsertionPhase::treatRootBlock):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::containsMovHint):
        (JSC::DFG::Node::accessesStack):
        (JSC::DFG::Node::hasLocal): Deleted.
        * dfg/DFGPredictionInjectionPhase.cpp:
        (JSC::DFG::PredictionInjectionPhase::run):
        * dfg/DFGValidate.cpp:

2016-07-29  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Use the same data structures for DFG and Air Liveness Analysis
        https://bugs.webkit.org/show_bug.cgi?id=160346

        Reviewed by Geoffrey Garen.

        In Air, we minimized memory accesses during liveness analysis
        with a couple of tricks:
        -Use a single Sparse Set ADT for the live value of each block.
        -Manipulate compact positive indices instead of hashing values.

        This patch brings the same ideas to DFG.

        This patch still uses the same fixpoint algorithms.
        The reason is Edge's KillStatus used by other phases. We cannot
        use a block-boundary liveness algorithm and update KillStatus
        simultaneously. It's something I'll probably revisit at some point.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::forAllValues):
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::dump):
        * dfg/DFGBasicBlock.h:
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::maxNodeCount):
        (JSC::DFG::Graph::nodeAt):
        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::setLiveValues):
        (JSC::DFG::InPlaceAbstractState::endBasicBlock):
        * dfg/DFGLivenessAnalysisPhase.cpp:
        (JSC::DFG::LivenessAnalysisPhase::LivenessAnalysisPhase):
        (JSC::DFG::LivenessAnalysisPhase::run):
        (JSC::DFG::LivenessAnalysisPhase::processBlock):
        (JSC::DFG::LivenessAnalysisPhase::addChildUse):
        (JSC::DFG::LivenessAnalysisPhase::process): Deleted.

2016-07-29  Yusuke Suzuki  <utatane.tea@gmail.com>

        Unreviewed, ByValInfo is only used in JIT enabled environments
        https://bugs.webkit.org/show_bug.cgi?id=158908

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::stronglyVisitStrongReferences):

2016-07-28  Yusuke Suzuki  <utatane.tea@gmail.com>

        JSC::Symbol should be hash-consed
        https://bugs.webkit.org/show_bug.cgi?id=158908

        Reviewed by Filip Pizlo.

        Previously, SymbolImpls held by symbols represent identity of symbols.
        When we check the equality between symbols, we need to load SymbolImpls of symbols and compare them.

        This patch performs hash-consing onto the symbols. We cache symbols in per-VM's SymbolImpl-keyed WeakGCMap.
        When creating a new symbol from SymbolImpl, we first query to this map and reuse the previously created symbol
        if it is found. This ensures that one-on-one correspondence between SymbolImpl and symbol. So now, we can use
        pointer-comparison to query the equality of symbols.

        This change drops SymbolImpl loads when checking the equality. Furthermore, we can use DFG CheckCell to symbol
        when we would like to ensure that the given value is the expected symbol. This cleans up GetByVal's symbol-keyd
        caching. Then, we changed CheckIdent to CheckStringIdent since it only checks the string case now. The symbol
        case is handled by CheckCell.

        Additionally, this patch also cleans up Map / Set implementation since we can use the logic for JSCell to symbols.

        The performance effects in the related benchmarks are the followings.

                                                               baseline                   patch

            bigswitch-indirect-symbol-or-undefined         85.6214+-1.0063     ^     63.0522+-0.8615        ^ definitely 1.3579x faster
            bigswitch-indirect-symbol                      84.9653+-0.6258     ^     80.4900+-0.8008        ^ definitely 1.0556x faster
            fold-put-by-val-with-symbol-to-multi-put-by-offset
                                                            9.4396+-0.3726            9.2941+-0.3311          might be 1.0157x faster
            inlined-put-by-val-with-symbol-transition
                                                           49.5477+-0.2401     ?     49.7533+-0.3369        ?
            get-by-val-with-symbol-self-or-proto           11.9740+-0.0798     ?     12.1706+-0.2723        ? might be 1.0164x slower
            get-by-val-with-symbol-quadmorphic-check-structure-elimination-simple
                                                            4.1364+-0.0841            4.0872+-0.0925          might be 1.0120x faster
            put-by-val-with-symbol                         11.3709+-0.0223           11.3613+-0.0264
            get-by-val-with-symbol-proto-or-self           11.8984+-0.0706     ?     11.9030+-0.0787        ?
            polymorphic-put-by-val-with-symbol             31.4176+-0.0558           31.3825+-0.0447
            implicit-bigswitch-indirect-symbol             61.3115+-0.6577     ^     58.0098+-0.1212        ^ definitely 1.0569x faster
            get-by-val-with-symbol-bimorphic-check-structure-elimination-simple
                                                            3.3139+-0.0565     ^      2.9947+-0.0732        ^ definitely 1.1066x faster
            get-by-val-with-symbol-chain-from-try-block
                                                            2.2316+-0.0179            2.2137+-0.0210
            get-by-val-with-symbol-bimorphic-check-structure-elimination
                                                           10.6031+-0.2216     ^     10.0939+-0.1977        ^ definitely 1.0504x faster
            get-by-val-with-symbol-check-structure-elimination
                                                            8.5576+-0.1521     ^      7.7107+-0.1308        ^ definitely 1.1098x faster
            put-by-val-with-symbol-slightly-polymorphic
                                                            3.1957+-0.0538     ^      2.9181+-0.0708        ^ definitely 1.0951x faster
            put-by-val-with-symbol-replace-and-transition
                                                           11.8253+-0.0757     ^     11.6590+-0.0351        ^ definitely 1.0143x faster

            <geometric>                                    13.3911+-0.0527     ^     12.7376+-0.0457        ^ definitely 1.0513x faster

        * bytecode/ByValInfo.h:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::stronglyVisitStrongReferences):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * 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::hasUidOperand):
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileSymbolEquality):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleSymbolEquality):
        (JSC::DFG::SpeculativeJIT::compileCheckStringIdent):
        (JSC::DFG::SpeculativeJIT::extractStringImplFromBinarySymbols): Deleted.
        (JSC::DFG::SpeculativeJIT::compileCheckIdent): Deleted.
        (JSC::DFG::SpeculativeJIT::compileSymbolUntypedEquality): Deleted.
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compileSymbolUntypedEquality):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compileSymbolUntypedEquality):
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileCheckStringIdent):
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
        (JSC::FTL::DFG::LowerDFGToB3::compileCheckIdent): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::lowSymbolUID): Deleted.
        * jit/JIT.h:
        * jit/JITOperations.cpp:
        (JSC::tryGetByValOptimize):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitGetByValWithCachedId):
        (JSC::JIT::emitPutByValWithCachedId):
        (JSC::JIT::emitByValIdentifierCheck):
        (JSC::JIT::privateCompileGetByValWithCachedId):
        (JSC::JIT::privateCompilePutByValWithCachedId):
        (JSC::JIT::emitIdentifierCheck): Deleted.
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emitGetByValWithCachedId):
        (JSC::JIT::emitPutByValWithCachedId):
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::dumpInContextAssumingStructure):
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::equalSlowCaseInline):
        (JSC::JSValue::strictEqualSlowCaseInline): Deleted.
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::setFunctionName):
        * runtime/MapData.h:
        * runtime/MapDataInlines.h:
        (JSC::JSIterator>::clear): Deleted.
        (JSC::JSIterator>::find): Deleted.
        (JSC::JSIterator>::add): Deleted.
        (JSC::JSIterator>::remove): Deleted.
        (JSC::JSIterator>::replaceAndPackBackingStore): Deleted.
        * runtime/Symbol.cpp:
        (JSC::Symbol::finishCreation):
        (JSC::Symbol::create):
        * runtime/Symbol.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        * tests/stress/symbol-equality-over-gc.js: Added.
        (shouldBe):
        (test):

2016-07-28  Mark Lam  <mark.lam@apple.com>

        ASSERTION FAILED in errorProtoFuncToString() when Error name is a single char string.
        https://bugs.webkit.org/show_bug.cgi?id=160324
        <rdar://problem/27389572>

        Reviewed by Keith Miller.

        The issue is that errorProtoFuncToString() was using jsNontrivialString() to
        generate the error string even when the name string can be a single character
        string.  This is incorrect.  We should be using jsString() instead.

        * runtime/ErrorPrototype.cpp:
        (JSC::errorProtoFuncToString):
        * tests/stress/errors-with-simple-names-or-messages-should-not-crash-toString.js: Added.

2016-07-28  Michael Saboff  <msaboff@apple.com>

        ARM64: Fused left shift with a right shift can create NaNs from integers
        https://bugs.webkit.org/show_bug.cgi?id=160329

        Reviewed by Geoffrey Garen.

        When we fuse a left shift and a right shift of integers where the shift amounts
        are the same and the size of the quantity being shifted is 8 bits, we rightly
        generate a sign extend byte instruction.  On ARM64, we were sign extending
        to a 64 bit quantity, when we really wanted to sign extend to a 32 bit quantity.

        Checking the ARM64 marco assembler and we were extending to 64 bits for all
        four combinations of zero / sign and 8 / 16 bits.
        
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::zeroExtend16To32):
        (JSC::MacroAssemblerARM64::signExtend16To32):
        (JSC::MacroAssemblerARM64::zeroExtend8To32):
        (JSC::MacroAssemblerARM64::signExtend8To32):
        * tests/stress/regress-160329.js: New test added.
        (narrow):

2016-07-28  Mark Lam  <mark.lam@apple.com>

        StringView should have an explicit m_is8Bit field.
        https://bugs.webkit.org/show_bug.cgi?id=160282
        <rdar://problem/27327943>

        Reviewed by Benjamin Poulain.

        * tests/stress/string-joining-long-strings-should-not-crash.js: Added.
        (catch):

2016-07-28  Csaba Osztrogonác  <ossy@webkit.org>

        [ARM] Typo fix after r121885
        https://bugs.webkit.org/show_bug.cgi?id=160288

        Reviewed by Zoltan Herczeg.

        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::maxJumpReplacementSize):

2016-07-28  Csaba Osztrogonác  <ossy@webkit.org>

        64-bit alignment check isn't necessary in ARMAssembler::prepareExecutableCopy after r202214
        https://bugs.webkit.org/show_bug.cgi?id=159711

        Reviewed by Mark Lam.

        * assembler/ARMAssembler.cpp:
        (JSC::ARMAssembler::prepareExecutableCopy):

2016-07-27  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Remove some unused code from FTL
        https://bugs.webkit.org/show_bug.cgi?id=160285

        Reviewed by Mark Lam.

        All the liveness and swapping is done inside B3,
        this code is no longer needed.

        * dfg/DFGEdge.h:
        (JSC::DFG::Edge::doesNotKill): Deleted.
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::doesKill): Deleted.

2016-07-27  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] DFG::Node should not have its own allocator
        https://bugs.webkit.org/show_bug.cgi?id=160098

        Reviewed by Geoffrey Garen.

        We need some design changes for DFG::Node:
        -Accessing the index must be fast. B3 uses indices for sets
         and maps, it is a lot faster than hashing pointers.
        -We should be able to subclass DFG::Node to specialize it.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGAllocator.h: Removed.
        (JSC::DFG::Allocator::Region::size): Deleted.
        (JSC::DFG::Allocator::Region::headerSize): Deleted.
        (JSC::DFG::Allocator::Region::numberOfThingsPerRegion): Deleted.
        (JSC::DFG::Allocator::Region::data): Deleted.
        (JSC::DFG::Allocator::Region::isInThisRegion): Deleted.
        (JSC::DFG::Allocator::Region::regionFor): Deleted.
        (JSC::DFG::Allocator<T>::Allocator): Deleted.
        (JSC::DFG::Allocator<T>::~Allocator): Deleted.
        (JSC::DFG::Allocator<T>::allocate): Deleted.
        (JSC::DFG::Allocator<T>::free): Deleted.
        (JSC::DFG::Allocator<T>::freeAll): Deleted.
        (JSC::DFG::Allocator<T>::reset): Deleted.
        (JSC::DFG::Allocator<T>::indexOf): Deleted.
        (JSC::DFG::Allocator<T>::allocatorOf): Deleted.
        (JSC::DFG::Allocator<T>::bumpAllocate): Deleted.
        (JSC::DFG::Allocator<T>::freeListAllocate): Deleted.
        (JSC::DFG::Allocator<T>::allocateSlow): Deleted.
        (JSC::DFG::Allocator<T>::freeRegionsStartingAt): Deleted.
        (JSC::DFG::Allocator<T>::startBumpingIn): Deleted.
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::addToGraph):
        * dfg/DFGCPSRethreadingPhase.cpp:
        (JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
        (JSC::DFG::CPSRethreadingPhase::addPhiSilently):
        * dfg/DFGCleanUpPhase.cpp:
        (JSC::DFG::CleanUpPhase::run):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::run):
        * dfg/DFGConstantHoistingPhase.cpp:
        * dfg/DFGDCEPhase.cpp:
        (JSC::DFG::DCEPhase::fixupBlock):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compileImpl):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::Graph):
        (JSC::DFG::Graph::deleteNode):
        (JSC::DFG::Graph::killBlockAndItsContents):
        (JSC::DFG::Graph::~Graph): Deleted.
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::addNode):
        * dfg/DFGLICMPhase.cpp:
        (JSC::DFG::LICMPhase::attemptHoist):
        * dfg/DFGLongLivedState.cpp: Removed.
        (JSC::DFG::LongLivedState::LongLivedState): Deleted.
        (JSC::DFG::LongLivedState::~LongLivedState): Deleted.
        (JSC::DFG::LongLivedState::shrinkToFit): Deleted.
        * dfg/DFGLongLivedState.h: Removed.
        * dfg/DFGNode.cpp:
        (JSC::DFG::Node::index): Deleted.
        * dfg/DFGNode.h:
        (JSC::DFG::Node::index):
        * dfg/DFGNodeAllocator.h: Removed.
        (operator new ): Deleted.
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThread):
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGPlan.h:
        * dfg/DFGSSAConversionPhase.cpp:
        (JSC::DFG::SSAConversionPhase::run):
        * dfg/DFGWorklist.cpp:
        (JSC::DFG::Worklist::runThread):
        * runtime/VM.cpp:
        (JSC::VM::VM): Deleted.
        * runtime/VM.h:

2016-07-27  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Fix a bunch of use-after-free of DFG::Node
        https://bugs.webkit.org/show_bug.cgi?id=160228

        Reviewed by Mark Lam.

        FTL had a few places where we use a node after it has been
        deleted. The dangling pointers come from the SSA liveness information
        kept on the basic blocks.

        This patch fixes the issues I could find and adds liveness invalidation
        to help finding dependencies like these.

        * dfg/DFGBasicBlock.h:
        (JSC::DFG::BasicBlock::SSAData::invalidate):

        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::run):
        Constant folding phase was deleting nodes in the loop over basic blocks.
        The problem is the deleted nodes can be referenced by other blocks.
        When the abstract interpreter was manipulating the abstract values of those
        it was doing so on the dead nodes.

        * dfg/DFGConstantHoistingPhase.cpp:
        Just invalidation. Nothing wrong here since the useless nodes were
        kept live while iterating the blocks.

        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::killBlockAndItsContents):
        (JSC::DFG::Graph::killUnreachableBlocks):
        (JSC::DFG::Graph::invalidateNodeLiveness):

        * dfg/DFGGraph.h:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        We had a lot of use-after-free in LCIM because we were using the stale
        live nodes deleted by previous phases.

2016-07-27  Keith Miller  <keith_miller@apple.com>

        concatAppendOne should allocate using the indexing type of the array if it cannot merge
        https://bugs.webkit.org/show_bug.cgi?id=160261
        <rdar://problem/27530122>

        Reviewed by Mark Lam.

        Before, if we could not merge the indexing types for copying, we would allocate the
        the array as ArrayWithUndecided. Instead, we should allocate an array with the original
        array's indexing type.

        * runtime/ArrayPrototype.cpp:
        (JSC::concatAppendOne):
        * tests/stress/concat-append-one-with-sparse-array.js: Added.

2016-07-27  Saam Barati  <sbarati@apple.com>

        We don't optimize for-in properly in baseline JIT (maybe other JITs too) with an object with symbols
        https://bugs.webkit.org/show_bug.cgi?id=160211
        <rdar://problem/27572612>

        Reviewed by Geoffrey Garen.

        The fast for-in iteration mode assumes all inline/out-of-line properties
        can be iterated in linear order. This is not true if we have Symbols
        because Symbols should not be iterated by for-in.

        * runtime/Structure.cpp:
        (JSC::Structure::add):
        * tests/stress/symbol-should-not-break-for-in.js: Added.
        (assert):
        (foo):

2016-07-27  Mark Lam  <mark.lam@apple.com>

        The second argument for Function.prototype.apply should be array-like or null/undefined.
        https://bugs.webkit.org/show_bug.cgi?id=160212
        <rdar://problem/27328525>

        Reviewed by Filip Pizlo.

        The spec for Function.prototype.apply says its second argument can only be null,
        undefined, or must be array-like.  See
        https://tc39.github.io/ecma262/#sec-function.prototype.apply and
        https://tc39.github.io/ecma262/#sec-createlistfromarraylike.

        Our previous implementation was not handling this correctly for SymbolType.
        This is now fixed.

        * interpreter/Interpreter.cpp:
        (JSC::sizeOfVarargs):
        * tests/stress/apply-second-argument-must-be-array-like.js: Added.

2016-07-27  Saam Barati  <sbarati@apple.com>

        MathICs should be able to emit only a jump along the inline path when they don't have any type data
        https://bugs.webkit.org/show_bug.cgi?id=160110

        Reviewed by Mark Lam.

        This patch allows for MathIC fast-path generation to be delayed.
        We delay when we don't see any observed type information for
        the lhs/rhs operand, which implies that the MathIC has never
        executed. This is profitable for two main reasons:
        1. If the math operation never executes, we emit much less code.
        2. Once we get type information for the lhs/rhs, we can emit better code.

        To implement this, we just emit a jump to the slow path call
        that will repatch on first execution.

        New data for add:
                   |   JetStream  |  Unity 3D  |
             ------| -------------|--------------
              Old  |   148 bytes  |  143 bytes |
             ------| -------------|--------------
              New  |   116  bytes |  113 bytes |
             ------------------------------------

        New data for mul:
                   |   JetStream  |  Unity 3D  |
             ------| -------------|--------------
              Old  |   210 bytes  |  185 bytes |
             ------| -------------|--------------
              New  |   170  bytes |  137 bytes |
             ------------------------------------

        * jit/JITAddGenerator.cpp:
        (JSC::JITAddGenerator::generateInline):
        * jit/JITAddGenerator.h:
        (JSC::JITAddGenerator::isLeftOperandValidConstant):
        (JSC::JITAddGenerator::isRightOperandValidConstant):
        (JSC::JITAddGenerator::arithProfile):
        * jit/JITMathIC.h:
        (JSC::JITMathIC::generateInline):
        (JSC::JITMathIC::generateOutOfLine):
        (JSC::JITMathIC::finalizeInlineCode):
        * jit/JITMathICInlineResult.h:
        * jit/JITMulGenerator.cpp:
        (JSC::JITMulGenerator::generateInline):
        * jit/JITMulGenerator.h:
        (JSC::JITMulGenerator::isLeftOperandValidConstant):
        (JSC::JITMulGenerator::isRightOperandValidConstant):
        (JSC::JITMulGenerator::arithProfile):
        * jit/JITOperations.cpp:

2016-07-26  Saam Barati  <sbarati@apple.com>

        rollout r203666
        https://bugs.webkit.org/show_bug.cgi?id=160226

        Unreviewed rollout.

        * b3/B3BasicBlock.h:
        (JSC::B3::BasicBlock::successorBlock):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::createGenericCompare):
        * b3/B3LowerToAir.h:
        * b3/air/AirArg.cpp:
        (JSC::B3::Air::Arg::isRepresentableAs):
        (JSC::B3::Air::Arg::usesTmp):
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::isRepresentableAs):
        (JSC::B3::Air::Arg::asNumber):
        (JSC::B3::Air::Arg::castToType): Deleted.
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::size):
        (JSC::B3::Air::Code::at):
        * b3/air/AirOpcode.opcodes:
        * b3/air/AirValidate.h:
        * b3/air/opcode_generator.rb:
        * b3/testb3.cpp:
        (JSC::B3::compileAndRun):
        (JSC::B3::testSomeEarlyRegister):
        (JSC::B3::zero):
        (JSC::B3::run):
        (JSC::B3::lowerToAirForTesting): Deleted.
        (JSC::B3::testBranchBitAndImmFusion): Deleted.

2016-07-26  Caitlin Potter  <caitp@igalia.com>

        [JSC] Object.getOwnPropertyDescriptors should not add undefined props to result
        https://bugs.webkit.org/show_bug.cgi?id=159409

        Reviewed by Geoffrey Garen.

        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorGetOwnPropertyDescriptors):
        * tests/es6.yaml:
        * tests/es6/Object_static_methods_Object.getOwnPropertyDescriptors-proxy.js:
        (testPropertiesIndexedSetterOnPrototypeThrows.set get var): Deleted.
        (testPropertiesIndexedSetterOnPrototypeThrows): Deleted.
        * tests/stress/Object_static_methods_Object.getOwnPropertyDescriptors-proxy.js: Renamed from Source/JavaScriptCore/tests/es6/Object_static_methods_Object.getOwnPropertyDescriptors-proxy.js.
        * tests/stress/Object_static_methods_Object.getOwnPropertyDescriptors.js: Renamed from Source/JavaScriptCore/tests/es6/Object_static_methods_Object.getOwnPropertyDescriptors.js.

2016-07-26  Mark Lam  <mark.lam@apple.com>

        Remove unused DEBUG_WITH_BREAKPOINT configuration.
        https://bugs.webkit.org/show_bug.cgi?id=160203

        Reviewed by Keith Miller.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitDebugHook):

2016-07-25  Benjamin Poulain  <benjamin@webkit.org>

        Unreviewed, rolling out r203703.

        It breaks some internal tests

        Reverted changeset:

        "[JSC] DFG::Node should not have its own allocator"
        https://bugs.webkit.org/show_bug.cgi?id=160098
        http://trac.webkit.org/changeset/203703

2016-07-25  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] DFG::Node should not have its own allocator
        https://bugs.webkit.org/show_bug.cgi?id=160098

        Reviewed by Geoffrey Garen.

        We need some design changes for DFG::Node:
        -Accessing the index must be fast. B3 uses indices for sets
         and maps, it is a lot faster than hashing pointers.
        -We should be able to subclass DFG::Node to specialize it.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGAllocator.h: Removed.
        (JSC::DFG::Allocator::Region::size): Deleted.
        (JSC::DFG::Allocator::Region::headerSize): Deleted.
        (JSC::DFG::Allocator::Region::numberOfThingsPerRegion): Deleted.
        (JSC::DFG::Allocator::Region::data): Deleted.
        (JSC::DFG::Allocator::Region::isInThisRegion): Deleted.
        (JSC::DFG::Allocator::Region::regionFor): Deleted.
        (JSC::DFG::Allocator<T>::Allocator): Deleted.
        (JSC::DFG::Allocator<T>::~Allocator): Deleted.
        (JSC::DFG::Allocator<T>::allocate): Deleted.
        (JSC::DFG::Allocator<T>::free): Deleted.
        (JSC::DFG::Allocator<T>::freeAll): Deleted.
        (JSC::DFG::Allocator<T>::reset): Deleted.
        (JSC::DFG::Allocator<T>::indexOf): Deleted.
        (JSC::DFG::Allocator<T>::allocatorOf): Deleted.
        (JSC::DFG::Allocator<T>::bumpAllocate): Deleted.
        (JSC::DFG::Allocator<T>::freeListAllocate): Deleted.
        (JSC::DFG::Allocator<T>::allocateSlow): Deleted.
        (JSC::DFG::Allocator<T>::freeRegionsStartingAt): Deleted.
        (JSC::DFG::Allocator<T>::startBumpingIn): Deleted.
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::addToGraph):
        * dfg/DFGCPSRethreadingPhase.cpp:
        (JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
        (JSC::DFG::CPSRethreadingPhase::addPhiSilently):
        * dfg/DFGCleanUpPhase.cpp:
        (JSC::DFG::CleanUpPhase::run):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::run):
        * dfg/DFGConstantHoistingPhase.cpp:
        * dfg/DFGDCEPhase.cpp:
        (JSC::DFG::DCEPhase::fixupBlock):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compileImpl):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::Graph):
        (JSC::DFG::Graph::deleteNode):
        (JSC::DFG::Graph::killBlockAndItsContents):
        (JSC::DFG::Graph::~Graph): Deleted.
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::addNode):
        * dfg/DFGLICMPhase.cpp:
        (JSC::DFG::LICMPhase::attemptHoist):
        * dfg/DFGLongLivedState.cpp: Removed.
        (JSC::DFG::LongLivedState::LongLivedState): Deleted.
        (JSC::DFG::LongLivedState::~LongLivedState): Deleted.
        (JSC::DFG::LongLivedState::shrinkToFit): Deleted.
        * dfg/DFGLongLivedState.h: Removed.
        * dfg/DFGNode.cpp:
        (JSC::DFG::Node::index): Deleted.
        * dfg/DFGNode.h:
        (JSC::DFG::Node::index):
        * dfg/DFGNodeAllocator.h: Removed.
        (operator new ): Deleted.
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThread):
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGPlan.h:
        * dfg/DFGSSAConversionPhase.cpp:
        (JSC::DFG::SSAConversionPhase::run):
        * dfg/DFGWorklist.cpp:
        (JSC::DFG::Worklist::runThread):
        * runtime/VM.cpp:
        (JSC::VM::VM): Deleted.
        * runtime/VM.h:

2016-07-25  Filip Pizlo  <fpizlo@apple.com>

        AssemblyHelpers should own all of the cell allocation methods
        https://bugs.webkit.org/show_bug.cgi?id=160171

        Reviewed by Saam Barati.
        
        Prior to this change we had some code in DFGSpeculativeJIT.h and some code in JIT.h that
        did cell allocation.
        
        This change moves all of that code into AssemblyHelpers.h.

        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::emitAllocateJSCell):
        (JSC::DFG::SpeculativeJIT::emitAllocateJSObject):
        (JSC::DFG::SpeculativeJIT::emitAllocateJSObjectWithKnownSize):
        (JSC::DFG::SpeculativeJIT::emitAllocateVariableSizedJSObject):
        (JSC::DFG::SpeculativeJIT::emitAllocateDestructibleObject):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitAllocate):
        (JSC::AssemblyHelpers::emitAllocateJSCell):
        (JSC::AssemblyHelpers::emitAllocateJSObject):
        (JSC::AssemblyHelpers::emitAllocateJSObjectWithKnownSize):
        (JSC::AssemblyHelpers::emitAllocateVariableSized):
        (JSC::AssemblyHelpers::emitAllocateVariableSizedJSObject):
        (JSC::AssemblyHelpers::emitAllocateDestructibleObject):
        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::isOperandConstantChar):
        (JSC::JIT::emitValueProfilingSite):
        (JSC::JIT::emitAllocateJSObject): 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):

2016-07-25  Saam Barati  <sbarati@apple.com>

        MathICs should be able to take and dump stats about code size
        https://bugs.webkit.org/show_bug.cgi?id=160148

        Reviewed by Filip Pizlo.

        This will make testing changes on MathIC going forward much easier.
        We will be able to easily see if modifications to MathIC will lead
        to us generating smaller code. We now only dump average size when we
        regenerate any MathIC. This works out for large tests/pages, but is not
        great for testing small programs. We can add more dump points later if
        we find that we want to dump stats while running small small programs.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::jitSoon):
        (JSC::CodeBlock::dumpMathICStats):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::isStrictMode):
        (JSC::CodeBlock::ecmaMode):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileMathIC):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileMathIC):
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emitMathICFast):
        (JSC::JIT::emitMathICSlow):
        * jit/JITMathIC.h:
        (JSC::JITMathIC::finalizeInlineCode):
        (JSC::JITMathIC::codeSize):
        * jit/JITOperations.cpp:

2016-07-25  Saam Barati  <sbarati@apple.com>

        op_mul/ArithMul(Untyped,Untyped) should be an IC
        https://bugs.webkit.org/show_bug.cgi?id=160108

        Reviewed by Mark Lam.

        This patch makes Mul a type based IC in much the same way that we made
        Add a type-based IC. I implemented Mul in the same way. I abstracted the
        implementation of the Add IC in the various JITs to allow for it to
        work over arbitrary IC snippets. This will make adding Div/Sub/Pow in the
        future easy. This patch also adds a new boolean argument to the various
        snippet generateFastPath() methods to indicate if we should emit result profiling.
        I added this because we want this profiling to be emitted for Mul in
        the baseline, but not in the DFG. We used to indicate this through passing
        in a nullptr for the ArithProfile, but we no longer do that in the upper
        JIT tiers. So we are passing an explicit request from the JIT tier about
        whether or not it's worth it for the IC to emit profiling.

        We now emit much less code for Mul. Here is some data on the average
        Mul snippet/IC size:

                   |   JetStream  |  Unity 3D  |
             ------| -------------|--------------
              Old  |  ~280 bytes  | ~280 bytes |
             ------| -------------|--------------
              New  |   210  bytes |  185 bytes |
             ------------------------------------

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::addJITAddIC):
        (JSC::CodeBlock::addJITMulIC):
        (JSC::CodeBlock::findStubInfo):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::stubInfoBegin):
        (JSC::CodeBlock::stubInfoEnd):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::GPRTemporary::adopt):
        (JSC::DFG::FPRTemporary::FPRTemporary):
        (JSC::DFG::SpeculativeJIT::compileValueAdd):
        (JSC::DFG::SpeculativeJIT::compileMathIC):
        (JSC::DFG::SpeculativeJIT::compileArithMul):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        (JSC::DFG::GPRTemporary::GPRTemporary):
        (JSC::DFG::GPRTemporary::operator=):
        (JSC::DFG::FPRTemporary::~FPRTemporary):
        (JSC::DFG::FPRTemporary::fpr):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileToThis):
        (JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
        (JSC::FTL::DFG::LowerDFGToB3::compileMathIC):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithMul):
        * jit/JIT.h:
        (JSC::JIT::getSlowCase):
        * jit/JITAddGenerator.cpp:
        (JSC::JITAddGenerator::generateInline):
        (JSC::JITAddGenerator::generateFastPath):
        * jit/JITAddGenerator.h:
        (JSC::JITAddGenerator::JITAddGenerator):
        (JSC::JITAddGenerator::isLeftOperandValidConstant):
        (JSC::JITAddGenerator::isRightOperandValidConstant):
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_add):
        (JSC::JIT::emitSlow_op_add):
        (JSC::JIT::emitMathICFast):
        (JSC::JIT::emitMathICSlow):
        (JSC::JIT::emit_op_mul):
        (JSC::JIT::emitSlow_op_mul):
        (JSC::JIT::emit_op_sub):
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITMathIC.h:
        (JSC::JITMathIC::slowPathStartLocation):
        (JSC::JITMathIC::slowPathCallLocation):
        (JSC::JITMathIC::isLeftOperandValidConstant):
        (JSC::JITMathIC::isRightOperandValidConstant):
        (JSC::JITMathIC::generateInline):
        (JSC::JITMathIC::generateOutOfLine):
        * jit/JITMathICForwards.h:
        * jit/JITMulGenerator.cpp:
        (JSC::JITMulGenerator::generateInline):
        (JSC::JITMulGenerator::generateFastPath):
        * jit/JITMulGenerator.h:
        (JSC::JITMulGenerator::JITMulGenerator):
        (JSC::JITMulGenerator::isLeftOperandValidConstant):
        (JSC::JITMulGenerator::isRightOperandValidConstant):
        (JSC::JITMulGenerator::didEmitFastPath): Deleted.
        (JSC::JITMulGenerator::endJumpList): Deleted.
        (JSC::JITMulGenerator::slowPathJumpList): Deleted.
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:

2016-07-25  Darin Adler  <darin@apple.com>

        Speed up make process slightly by improving "list of files" idiom
        https://bugs.webkit.org/show_bug.cgi?id=160164

        Reviewed by Mark Lam.

        * DerivedSources.make: Change rules that build lists of files to only run when
        DerivedSources.make has been modified since the last time they were run. Since the
        list of files are inside this file, this is safe, and this is faster than always
        comparing and regenerating the file containing the list of files each time.

2016-07-24  Youenn Fablet  <youenn@apple.com>

        [Fetch API] Request should be created with any HeadersInit data
        https://bugs.webkit.org/show_bug.cgi?id=159672

        Reviewed by Sam Weinig.

        * Scripts/builtins/builtins_generator.py:
        (WK_lcfirst): Synchronized with CodeGenerator.pm version.

2016-07-24  Filip Pizlo  <fpizlo@apple.com>

        B3 should support multiple entrypoints
        https://bugs.webkit.org/show_bug.cgi?id=159391

        Reviewed by Saam Barati.
        
        This teaches B3 how to compile procedures with multiple entrypoints in the best way ever.
        
        Multiple entrypoints are useful. We could use them to reduce the cost of compiling OSR
        entrypoints. We could use them to implement better try/catch.
        
        Multiple entrypoints are hard to support. All of the code that assumed that the root block
        is the entrypoint would have to be changed. Transformations like moveConstants() would have
        to do crazy things if the existence of multiple entrypoints prevented it from finding a
        single common dominator.
        
        Therefore, we want to add multiple entrypoints without actually teaching the compiler that
        there is such a thing. That's sort of what this change does.
        
        This adds a new opcode to both B3 and Air called EntrySwitch. It's a terminal that takes
        one or more successors and no value children. The number of successors must match
        Procedure::numEntrypoints(), which could be arbitrarily large. The semantics of EntrySwitch
        are:
        
        - Each of the entrypoints sets a hidden Entry variable to that entrypoint's index and jumps
          to the procedure's root block.
        
        - An EntrySwitch is a switch statement over this hidden Entry variable.
        
        The way that we actually implement this is that Air has a very late phase - after all
        register and stack layout - that clones all code where the Entry variable is live; i.e all
        code in the closure over predecessors of all blocks that do EntrySwitch.
        
        Usually, you would use this by creating an EntrySwitch in the root block, but you don't
        have to do that. Just remember that the code before EntrySwitch gets cloned for each
        entrypoint. We allow cloning of an arbitrarily large amount of code because restricting it,
        and so restricing the placement of EntrySwitches, would be unelegant. It would be hard to
        preserve this invariant. For example we wouldn't be able to lower any value before an
        EntrySwitch to a control flow diamond.
        
        This patch gives us an easy-to-use way to use B3 to compile code with multiple entrypoints.
        Inside the compiler, only code that runs very late in Air has to know about this feature.
        We get the best of both worlds!
        
        Also, I finally got rid of the requirement that you explicitly cast BasicBlock* to
        FrequentedBlock. I can no longer remember why I thought that was a good idea. Removing it
        doesn't cause any problems and it makes code easier to write.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3BasicBlockUtils.h:
        (JSC::B3::updatePredecessorsAfter):
        (JSC::B3::clearPredecessors):
        (JSC::B3::recomputePredecessors):
        * b3/B3FrequencyClass.h:
        (JSC::B3::maxFrequency):
        * b3/B3Generate.h:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3MoveConstants.cpp:
        * b3/B3Opcode.cpp:
        (WTF::printInternal):
        * b3/B3Opcode.h:
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::isFastConstant):
        (JSC::B3::Procedure::entrypointLabel):
        (JSC::B3::Procedure::addDataSection):
        * b3/B3Procedure.h:
        (JSC::B3::Procedure::numEntrypoints):
        (JSC::B3::Procedure::setNumEntrypoints):
        (JSC::B3::Procedure::setLastPhaseName):
        * b3/B3Validate.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::effects):
        (JSC::B3::Value::typeFor):
        * b3/B3Value.h:
        * b3/air/AirCode.cpp:
        (JSC::B3::Air::Code::cCallSpecial):
        (JSC::B3::Air::Code::isEntrypoint):
        (JSC::B3::Air::Code::resetReachability):
        (JSC::B3::Air::Code::dump):
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::setFrameSize):
        (JSC::B3::Air::Code::numEntrypoints):
        (JSC::B3::Air::Code::entrypoints):
        (JSC::B3::Air::Code::entrypoint):
        (JSC::B3::Air::Code::setEntrypoints):
        (JSC::B3::Air::Code::entrypointLabel):
        (JSC::B3::Air::Code::setEntrypointLabels):
        (JSC::B3::Air::Code::calleeSaveRegisters):
        * b3/air/AirCustom.h:
        (JSC::B3::Air::PatchCustom::isTerminal):
        (JSC::B3::Air::PatchCustom::hasNonArgEffects):
        (JSC::B3::Air::PatchCustom::hasNonArgNonControlEffects):
        (JSC::B3::Air::PatchCustom::generate):
        (JSC::B3::Air::CommonCustomBase::hasNonArgEffects):
        (JSC::B3::Air::CCallCustom::forEachArg):
        (JSC::B3::Air::ColdCCallCustom::forEachArg):
        (JSC::B3::Air::ShuffleCustom::forEachArg):
        (JSC::B3::Air::EntrySwitchCustom::forEachArg):
        (JSC::B3::Air::EntrySwitchCustom::isValidFormStatic):
        (JSC::B3::Air::EntrySwitchCustom::isValidForm):
        (JSC::B3::Air::EntrySwitchCustom::admitsStack):
        (JSC::B3::Air::EntrySwitchCustom::isTerminal):
        (JSC::B3::Air::EntrySwitchCustom::hasNonArgNonControlEffects):
        (JSC::B3::Air::EntrySwitchCustom::generate):
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::prepareForGeneration):
        (JSC::B3::Air::generate):
        * b3/air/AirLowerEntrySwitch.cpp: Added.
        (JSC::B3::Air::lowerEntrySwitch):
        * b3/air/AirLowerEntrySwitch.h: Added.
        * b3/air/AirOpcode.opcodes:
        * b3/air/AirOptimizeBlockOrder.cpp:
        (JSC::B3::Air::blocksInOptimizedOrder):
        * b3/air/AirSpecial.cpp:
        (JSC::B3::Air::Special::isTerminal):
        (JSC::B3::Air::Special::hasNonArgEffects):
        (JSC::B3::Air::Special::hasNonArgNonControlEffects):
        * b3/air/AirSpecial.h:
        * b3/air/AirValidate.cpp:
        * b3/air/opcode_generator.rb:
        * b3/testb3.cpp:

2016-07-24  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix broken test. I don't know why I goofed this up without seeing it before landing.

        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::run):

2016-07-22  Filip Pizlo  <fpizlo@apple.com>

        [B3] Fusing immediates into test instructions should work again
        https://bugs.webkit.org/show_bug.cgi?id=160073

        Reviewed by Sam Weinig.

        When we introduced BitImm, we forgot to change the Branch(BitAnd(value, constant))
        fusion.  This emits test instructions, so it should use BitImm for the constant.  But it
        was still using Imm!  This meant that isValidForm() always returned false.
        
        This fixes the code path to use BitImm, and turns off our use of BitImm64 on x86 since
        it provides no benefit on x86 and has some risk (the code appears to play fast and loose
        with the scratch register).
        
        This is not an obvious progression on anything, so I added comprehensive tests to
        testb3, which check that we selected the optimal instruction in a variety of situations.
        We should add more tests like this!

        * b3/B3BasicBlock.h:
        (JSC::B3::BasicBlock::successorBlock):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::createGenericCompare):
        * b3/B3LowerToAir.h:
        * b3/air/AirArg.cpp:
        (JSC::B3::Air::Arg::isRepresentableAs):
        (JSC::B3::Air::Arg::usesTmp):
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::isRepresentableAs):
        (JSC::B3::Air::Arg::castToType):
        (JSC::B3::Air::Arg::asNumber):
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::size):
        (JSC::B3::Air::Code::at):
        * b3/air/AirOpcode.opcodes:
        * b3/air/AirValidate.h:
        * b3/air/opcode_generator.rb:
        * b3/testb3.cpp:
        (JSC::B3::compile):
        (JSC::B3::compileAndRun):
        (JSC::B3::lowerToAirForTesting):
        (JSC::B3::testSomeEarlyRegister):
        (JSC::B3::testBranchBitAndImmFusion):
        (JSC::B3::zero):
        (JSC::B3::run):

2016-07-24  Yusuke Suzuki  <utatane.tea@gmail.com>

        Unreviewed, update the exponentiation expression error message
        https://bugs.webkit.org/show_bug.cgi?id=159969

        Follow up patch for r203499.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseBinaryExpression):
        * tests/stress/pow-expects-update-expression-on-lhs.js:
        (throw.new.Error):

2016-07-24  Darin Adler  <darin@apple.com>

        Adding a new WebCore JavaScript built-in source file does not trigger rebuild of WebCoreJSBuiltins*
        https://bugs.webkit.org/show_bug.cgi?id=160115

        Reviewed by Youenn Fablet.

        * make-generated-sources.sh: Removed. Was unused.

2016-07-23  Commit Queue  <commit-queue@webkit.org>

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

        It broke make-based builds (Requested by youenn on #webkit).

        Reverted changeset:

        "[Fetch API] Request should be created with any HeadersInit
        data"
        https://bugs.webkit.org/show_bug.cgi?id=159672
        http://trac.webkit.org/changeset/203641

2016-07-23  Youenn Fablet  <youenn@apple.com>

        [Fetch API] Request should be created with any HeadersInit data
        https://bugs.webkit.org/show_bug.cgi?id=159672

        Reviewed by Sam Weinig.

        * Scripts/builtins/builtins_generator.py:
        (WK_lcfirst): Synchronized with CodeGenerator.pm version.

2016-07-21  Filip Pizlo  <fpizlo@apple.com>

        Teach MarkedSpace how to allocate auxiliary storage
        https://bugs.webkit.org/show_bug.cgi?id=160053

        Reviewed by Sam Weinig.
        
        Previously, we had two kinds of subspaces in MarkedSpace: destructor and non-destructor. This
        was described using "bool needsDestruction" that would get passed around. We'd iterate over
        these spaces using duplicated code - one loop for destructors and one for non-destructors, or
        a single loop that does one thing for destructors and one for non-destructors.
        
        But now we want a third subspace: non-destructor non-JSCell, aka Auxiliary.
        
        So, this changes all of the reflection and iteration over subspaces to use functors, so that
        the looping is written once and reused. Most places don't even have to know that there is a
        third subspace; they just know that they must do things for each subspace, for each
        allocator, or for each block - and the functor magic handles it for you.
        
        To make this somewhat nice, this change also fixes how we describe subspaces. Instead of a
        bool, we now have AllocatorAttributes, which is a struct. If we ever add more subspaces, we
        can add fields to AllocatorAttributes to describe how those subspaces differ. For now it just
        contains two properties: a DestructionMode and a HeapCell::Kind. The DesctructionMode
        replaces bool needsDestruction. I deliberately used a non-class enum to avoid tautologies.
        DestructionMode has two members: NeedsDestruction and DoesNotNeedDestruction. I almost went
        with DestructionMode::Needed and DestructionMode::NotNeeded, but I felt like that involves
        more typing and doesn't actually avoid any kind of namespace issues.
        
        This is intended to have no behavior change other than the addition of a totally unused
        space, which should always be empty. So hopefully it doesn't cost anything.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/AllocatorAttributes.cpp: Added.
        (JSC::AllocatorAttributes::dump):
        * heap/AllocatorAttributes.h: Added.
        (JSC::AllocatorAttributes::AllocatorAttributes):
        * heap/DestructionMode.cpp: Added.
        (WTF::printInternal):
        * heap/DestructionMode.h: Added.
        * heap/Heap.h:
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::allocateBlock):
        (JSC::MarkedAllocator::addBlock):
        * heap/MarkedAllocator.h:
        (JSC::MarkedAllocator::cellSize):
        (JSC::MarkedAllocator::attributes):
        (JSC::MarkedAllocator::needsDestruction):
        (JSC::MarkedAllocator::destruction):
        (JSC::MarkedAllocator::cellKind):
        (JSC::MarkedAllocator::heap):
        (JSC::MarkedAllocator::takeLastActiveBlock):
        (JSC::MarkedAllocator::MarkedAllocator):
        (JSC::MarkedAllocator::init):
        (JSC::MarkedAllocator::allocate):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::create):
        (JSC::MarkedBlock::destroy):
        (JSC::MarkedBlock::MarkedBlock):
        (JSC::MarkedBlock::callDestructor):
        (JSC::MarkedBlock::sweep):
        (JSC::MarkedBlock::stopAllocating):
        (JSC::MarkedBlock::didRetireBlock):
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::cellSize):
        (JSC::MarkedBlock::attributes):
        (JSC::MarkedBlock::needsDestruction):
        (JSC::MarkedBlock::destruction):
        (JSC::MarkedBlock::cellKind):
        (JSC::MarkedBlock::size):
        (JSC::MarkedBlock::forEachCell):
        (JSC::MarkedBlock::forEachLiveCell):
        (JSC::MarkedBlock::forEachDeadCell):
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::MarkedSpace):
        (JSC::MarkedSpace::~MarkedSpace):
        (JSC::MarkedSpace::lastChanceToFinalize):
        (JSC::MarkedSpace::resetAllocators):
        (JSC::MarkedSpace::forEachAllocator):
        (JSC::MarkedSpace::stopAllocating):
        (JSC::MarkedSpace::resumeAllocating):
        (JSC::MarkedSpace::isPagedOut):
        (JSC::MarkedSpace::freeBlock):
        (JSC::MarkedSpace::shrink):
        (JSC::MarkedSpace::clearNewlyAllocated):
        (JSC::clearNewlyAllocatedInBlock): Deleted.
        * heap/MarkedSpace.h:
        (JSC::MarkedSpace::subspaceForObjectsWithDestructor):
        (JSC::MarkedSpace::subspaceForObjectsWithoutDestructor):
        (JSC::MarkedSpace::subspaceForAuxiliaryData):
        (JSC::MarkedSpace::allocatorFor):
        (JSC::MarkedSpace::destructorAllocatorFor):
        (JSC::MarkedSpace::auxiliaryAllocatorFor):
        (JSC::MarkedSpace::allocateWithoutDestructor):
        (JSC::MarkedSpace::allocateWithDestructor):
        (JSC::MarkedSpace::allocateAuxiliary):
        (JSC::MarkedSpace::forEachBlock):
        (JSC::MarkedSpace::didAddBlock):
        (JSC::MarkedSpace::capacity):
        (JSC::MarkedSpace::forEachSubspace):

2016-07-22  Saam Barati  <sbarati@apple.com>

        REGRESSION(r203537): It made many tests crash on ARMv7 Linux platforms
        https://bugs.webkit.org/show_bug.cgi?id=160082

        Reviewed by Keith Miller.

        We were improperly linking the Jump in the link buffer.
        It caused us to be linking against the executable address
        which always has bit 0 set. We shouldn't be doing that.
        This patch fixes this, by using the same idiom that
        PolymorphicAccess uses to link a jump to out of line code.

        * jit/JITMathIC.h:
        (JSC::JITMathIC::generateOutOfLine):

2016-07-22  Commit Queue  <commit-queue@webkit.org>

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

        Caused CLoop tests to fail with assertions (Requested by
        perarne on #webkit).

        Reverted changeset:

        "[Win] jsc.exe sometimes never exits."
        https://bugs.webkit.org/show_bug.cgi?id=158073
        http://trac.webkit.org/changeset/203603

2016-07-22  Per Arne Vollan  <pvollan@apple.com>

        [Win] jsc.exe sometimes never exits.
        https://bugs.webkit.org/show_bug.cgi?id=158073

        Reviewed by Mark Lam.

        Make sure the VM is deleted after the test has finished. This will gracefully stop the sampling profiler thread,
        and give the thread the opportunity to release the machine thread lock aquired in SamplingProfiler::takeSample.  
        If the sampling profiler thread was terminated while holding the machine thread lock, the machine thread will
        not be able to grab the lock afterwards. 
 
        * jsc.cpp:
        (jscmain):

2016-07-22  Per Arne Vollan  <pvollan@apple.com>

        Fix the Windows 64-bit build after r203537
        https://bugs.webkit.org/show_bug.cgi?id=160080

        Reviewed by Csaba Osztrogonác.

        Added new version of setupArgumentsWithExecState method.

        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgumentsWithExecState):

2016-07-22  Csaba Osztrogonác  <ossy@webkit.org>

        [ARM] Unreviewed EABI buildfix after r203537.

        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgumentsWithExecState): Added.

2016-07-22  Youenn Fablet  <youenn@apple.com>

        run-builtins-generator-tests should be able to test WebCore builtins wrapper with more than one file
        https://bugs.webkit.org/show_bug.cgi?id=159921

        Reviewed by Brian Burg.

        Updated built-in generator to generate only wrapper files when passed the --wrappers-only option.
        When this option is used, wrapper files are generated but no individual file is generated.
        When this option is not used, individual files are generated but not wrapper file is generated.
        This allows the builtin generator test runner to generate a single WebCore-Wrappers.h-result generated for all
        WebCore test files, like used for real in WebCore.
        Previously wrapper code was generated individually for each WebCore test file.

        Added new built-in test file to cover the case of concatenating several guards in generated WebCore wrapper files.

        * Scripts/generate-js-builtins.py:
        (concatenated_output_filename): Compute a decent name for wrapper files in case of test mode.
        (generate_bindings_for_builtins_files): When --wrappers-only is activated, this generates only the wrapper files, not the individual files.
        * Scripts/tests/builtins/WebCore-AnotherGuardedInternalBuiltin-Separate.js: Added.
        * Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.js-result: Added.
        * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result: Removed wrapper code.
        * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result: Ditto.
        * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result: Ditto.
        * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result: Ditto.
        * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result: Removed wrapper code.
        * Scripts/tests/builtins/expected/WebCoreJSBuiltins.h-result: Added, contains wrapper code for all WebCore valid test cases.

2016-07-21  Saam Barati  <sbarati@apple.com>

        callOperation(.) variants in the DFG that explicitly take a tag/payload register should take a JSValueRegs instead
        https://bugs.webkit.org/show_bug.cgi?id=160007

        Reviewed by Filip Pizlo.

        This patch is the first step in my plan to remove all callOperation(.) variants
        in the various JITs and to unify them using a couple template variations.
        The steps are as follows:
        1. Replace all explicit tag/payload pairs with JSValueRegs in the DFG
        2. Replace all explicit tag/payload pairs with JSValueRegs in the baseline
        3. remove callOperation(.) variants and teach setupArgumentsWithExecState
           about JSValueRegs.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
        (JSC::DFG::SpeculativeJIT::compileValueAdd):
        (JSC::DFG::SpeculativeJIT::compileGetDynamicVar):
        (JSC::DFG::SpeculativeJIT::compilePutDynamicVar):
        (JSC::DFG::SpeculativeJIT::compilePutAccessorByVal):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetById):
        (JSC::DFG::SpeculativeJIT::cachedPutById):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
        (JSC::DFG::CompareAndBoxBooleanSlowPathGenerator::generateInternal):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compileLogicalNot):
        (JSC::DFG::SpeculativeJIT::emitBranch):
        (JSC::DFG::SpeculativeJIT::compile):

2016-07-21  Saam Barati  <sbarati@apple.com>

        op_add/ValueAdd should be an IC in all JIT tiers
        https://bugs.webkit.org/show_bug.cgi?id=159649

        Reviewed by Benjamin Poulain.

        This patch makes Add an IC inside all JIT tiers. It does so in a
        simple, but effective, way. We will try to generate an int+int add
        that will repatch itself if its type checks fail. Sometimes though,
        we have runtime type data saying that the add won't be int+int.
        In those cases, we will just generate a full snippet that doesn't patch itself.
        Other times, we may generate no inline code and defer to making a C call. A lot
        of this patch is just refactoring ResultProfile into what we're now calling ArithProfile.
        ArithProfile does everything ResultProfile used to do, and more. It records simple type
        data about the LHS/RHS operands it sees. This allows us to determine if an op_add
        has only seen int+int operands, etc. ArithProfile will also contain the ResultType
        for the LHS/RHS that the parser feeds into op_add. ArithProfile now fits into 32-bits.
        This means instead of having a side table like we did for ResultProfile, we just
        inject the ArithProfile into the bytecode instruction stream. This makes asking
        for ArithProfile faster; we no longer need to lock around this operation.

        The size of an Add has gone down on average, but we can still do better.
        We still generate a lot of code because we generate calls to the slow path.
        I think we can make this better by moving the slow path to a shared thunk
        system. This patch mostly lays the foundation for future improvements to Add,
        and a framework to move all other arithmetic operations to be typed-based ICs.

        Here is some data I took on the average op_add/ValueAdd size on various benchmarks:
                   |   JetStream  |  Speedometer |  Unity 3D  |
             ------| -------------|-----------------------------
              Old  |  189 bytes   |  169 bytes   |  192 bytes |
             ------| -------------|-----------------------------
              New  |  148 bytes   |  124 bytes   |  143 bytes |
             ---------------------------------------------------

        Making an arithmetic IC is now easy. The JITMathIC class will hold a snippet
        generator as a member variable. To make a snippet an IC, you need to implement
        a generateInline(.) method, which generates the inline IC. Then, you need to
        generate the IC where you used to generate the snippet. When generating the
        IC, we need to inform JITMathIC of various data like we do with StructureStubInfo.
        We need to tell it about where the slow path starts, where the slow path call is, etc.
        When generating a JITMathIC, it may tell you that it didn't generate any code inline.
        This is a request to the user of JITMathIC to just generate a C call along the
        fast path. JITMathIC may also have the snippet tell it to just generate the full
        snippet instead of the int+int path along the fast path.

        In subsequent patches, we can improve upon how we decide to generate int+int or
        the full snippet. I tried to get clever by having double+double, double+int, int+double,
        fast paths, but they didn't work out nearly as well as the int+int fast path. I ended up
        generating a lot of code when I did this and ended up using more memory than just generating
        the full snippet. There is probably some way we can be clever and generate specialized fast
        paths that are more successful than what I tried implementing, but I think that's worth deferring
        this to follow up patches once the JITMathIC foundation has landed.

        This patch also fixes a bug inside the slow path lambdas in the DFG.
        Before, it was not legal to emit an exception check inside them. Now,
        it is. So it's now easy to define arbitrary late paths using the DFG
        slow path lambda API.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/ArithProfile.cpp: Added.
        (JSC::ArithProfile::emitObserveResult):
        (JSC::ArithProfile::shouldEmitSetDouble):
        (JSC::ArithProfile::emitSetDouble):
        (JSC::ArithProfile::shouldEmitSetNonNumber):
        (JSC::ArithProfile::emitSetNonNumber):
        (WTF::printInternal):
        * bytecode/ArithProfile.h: Added.
        (JSC::ObservedType::ObservedType):
        (JSC::ObservedType::sawInt32):
        (JSC::ObservedType::isOnlyInt32):
        (JSC::ObservedType::sawNumber):
        (JSC::ObservedType::isOnlyNumber):
        (JSC::ObservedType::sawNonNumber):
        (JSC::ObservedType::isOnlyNonNumber):
        (JSC::ObservedType::isEmpty):
        (JSC::ObservedType::bits):
        (JSC::ObservedType::withInt32):
        (JSC::ObservedType::withNumber):
        (JSC::ObservedType::withNonNumber):
        (JSC::ObservedType::withoutNonNumber):
        (JSC::ObservedType::operator==):
        (JSC::ArithProfile::ArithProfile):
        (JSC::ArithProfile::fromInt):
        (JSC::ArithProfile::lhsResultType):
        (JSC::ArithProfile::rhsResultType):
        (JSC::ArithProfile::lhsObservedType):
        (JSC::ArithProfile::rhsObservedType):
        (JSC::ArithProfile::setLhsObservedType):
        (JSC::ArithProfile::setRhsObservedType):
        (JSC::ArithProfile::tookSpecialFastPath):
        (JSC::ArithProfile::didObserveNonInt32):
        (JSC::ArithProfile::didObserveDouble):
        (JSC::ArithProfile::didObserveNonNegZeroDouble):
        (JSC::ArithProfile::didObserveNegZeroDouble):
        (JSC::ArithProfile::didObserveNonNumber):
        (JSC::ArithProfile::didObserveInt32Overflow):
        (JSC::ArithProfile::didObserveInt52Overflow):
        (JSC::ArithProfile::setObservedNonNegZeroDouble):
        (JSC::ArithProfile::setObservedNegZeroDouble):
        (JSC::ArithProfile::setObservedNonNumber):
        (JSC::ArithProfile::setObservedInt32Overflow):
        (JSC::ArithProfile::setObservedInt52Overflow):
        (JSC::ArithProfile::addressOfBits):
        (JSC::ArithProfile::observeResult):
        (JSC::ArithProfile::lhsSawInt32):
        (JSC::ArithProfile::lhsSawNumber):
        (JSC::ArithProfile::lhsSawNonNumber):
        (JSC::ArithProfile::rhsSawInt32):
        (JSC::ArithProfile::rhsSawNumber):
        (JSC::ArithProfile::rhsSawNonNumber):
        (JSC::ArithProfile::observeLHSAndRHS):
        (JSC::ArithProfile::bits):
        (JSC::ArithProfile::hasBits):
        (JSC::ArithProfile::setBit):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpRareCaseProfile):
        (JSC::CodeBlock::dumpArithProfile):
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::addStubInfo):
        (JSC::CodeBlock::addJITAddIC):
        (JSC::CodeBlock::findStubInfo):
        (JSC::CodeBlock::resetJITData):
        (JSC::CodeBlock::shrinkToFit):
        (JSC::CodeBlock::dumpValueProfiles):
        (JSC::CodeBlock::rareCaseProfileCountForBytecodeOffset):
        (JSC::CodeBlock::arithProfileForBytecodeOffset):
        (JSC::CodeBlock::arithProfileForPC):
        (JSC::CodeBlock::couldTakeSpecialFastCase):
        (JSC::CodeBlock::dumpResultProfile): Deleted.
        (JSC::CodeBlock::resultProfileForBytecodeOffset): Deleted.
        (JSC::CodeBlock::specialFastCaseProfileCountForBytecodeOffset): Deleted.
        (JSC::CodeBlock::ensureResultProfile): Deleted.
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::stubInfoBegin):
        (JSC::CodeBlock::stubInfoEnd):
        (JSC::CodeBlock::couldTakeSlowCase):
        (JSC::CodeBlock::numberOfResultProfiles): Deleted.
        * bytecode/MethodOfGettingAValueProfile.cpp:
        (JSC::MethodOfGettingAValueProfile::emitReportValue):
        * bytecode/MethodOfGettingAValueProfile.h:
        (JSC::MethodOfGettingAValueProfile::MethodOfGettingAValueProfile):
        * bytecode/ValueProfile.cpp:
        (JSC::ResultProfile::emitDetectNumericness): Deleted.
        (JSC::ResultProfile::emitSetDouble): Deleted.
        (JSC::ResultProfile::emitSetNonNumber): Deleted.
        (WTF::printInternal): Deleted.
        * bytecode/ValueProfile.h:
        (JSC::getRareCaseProfileBytecodeOffset):
        (JSC::ResultProfile::ResultProfile): Deleted.
        (JSC::ResultProfile::bytecodeOffset): Deleted.
        (JSC::ResultProfile::specialFastPathCount): Deleted.
        (JSC::ResultProfile::didObserveNonInt32): Deleted.
        (JSC::ResultProfile::didObserveDouble): Deleted.
        (JSC::ResultProfile::didObserveNonNegZeroDouble): Deleted.
        (JSC::ResultProfile::didObserveNegZeroDouble): Deleted.
        (JSC::ResultProfile::didObserveNonNumber): Deleted.
        (JSC::ResultProfile::didObserveInt32Overflow): Deleted.
        (JSC::ResultProfile::didObserveInt52Overflow): Deleted.
        (JSC::ResultProfile::setObservedNonNegZeroDouble): Deleted.
        (JSC::ResultProfile::setObservedNegZeroDouble): Deleted.
        (JSC::ResultProfile::setObservedNonNumber): Deleted.
        (JSC::ResultProfile::setObservedInt32Overflow): Deleted.
        (JSC::ResultProfile::setObservedInt52Overflow): Deleted.
        (JSC::ResultProfile::addressOfFlags): Deleted.
        (JSC::ResultProfile::addressOfSpecialFastPathCount): Deleted.
        (JSC::ResultProfile::detectNumericness): Deleted.
        (JSC::ResultProfile::hasBits): Deleted.
        (JSC::ResultProfile::setBit): Deleted.
        (JSC::getResultProfileBytecodeOffset): Deleted.
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitBinaryOp):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::makeSafe):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::exceptionCheck):
        * dfg/DFGSlowPathGenerator.h:
        (JSC::DFG::SlowPathGenerator::generate):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::addSlowPathGenerator):
        (JSC::DFG::SpeculativeJIT::runSlowPathGenerators):
        (JSC::DFG::SpeculativeJIT::compileValueAdd):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::silentSpillAllRegistersImpl):
        (JSC::DFG::SpeculativeJIT::silentSpillAllRegisters):
        (JSC::DFG::SpeculativeJIT::callOperation):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
        (JSC::FTL::DFG::LowerDFGToB3::compileStrCat):
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgumentsWithExecState):
        (JSC::CCallHelpers::setupArguments):
        * jit/JIT.h:
        * jit/JITAddGenerator.cpp:
        (JSC::JITAddGenerator::generateInline):
        (JSC::JITAddGenerator::generateFastPath):
        * jit/JITAddGenerator.h:
        (JSC::JITAddGenerator::JITAddGenerator):
        (JSC::JITAddGenerator::didEmitFastPath): Deleted.
        (JSC::JITAddGenerator::endJumpList): Deleted.
        (JSC::JITAddGenerator::slowPathJumpList): Deleted.
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_jless):
        (JSC::JIT::emitSlow_op_urshift):
        (JSC::getOperandTypes):
        (JSC::JIT::emit_op_add):
        (JSC::JIT::emitSlow_op_add):
        (JSC::JIT::emit_op_div):
        (JSC::JIT::emit_op_mul):
        (JSC::JIT::emitSlow_op_mul):
        (JSC::JIT::emit_op_sub):
        (JSC::JIT::emitSlow_op_sub):
        * jit/JITDivGenerator.cpp:
        (JSC::JITDivGenerator::generateFastPath):
        * jit/JITDivGenerator.h:
        (JSC::JITDivGenerator::JITDivGenerator):
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITMathIC.h: Added.
        (JSC::JITMathIC::doneLocation):
        (JSC::JITMathIC::slowPathStartLocation):
        (JSC::JITMathIC::slowPathCallLocation):
        (JSC::JITMathIC::generateInline):
        (JSC::JITMathIC::generateOutOfLine):
        (JSC::JITMathIC::finalizeInlineCode):
        * jit/JITMathICForwards.h: Added.
        * jit/JITMathICInlineResult.h: Added.
        * jit/JITMulGenerator.cpp:
        (JSC::JITMulGenerator::generateFastPath):
        * jit/JITMulGenerator.h:
        (JSC::JITMulGenerator::JITMulGenerator):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITSubGenerator.cpp:
        (JSC::JITSubGenerator::generateFastPath):
        * jit/JITSubGenerator.h:
        (JSC::JITSubGenerator::JITSubGenerator):
        * jit/Repatch.cpp:
        (JSC::readCallTarget):
        (JSC::ftlThunkAwareRepatchCall):
        (JSC::tryCacheGetByID):
        (JSC::repatchGetByID):
        (JSC::appropriateGenericPutByIdFunction):
        (JSC::tryCachePutByID):
        (JSC::repatchPutByID):
        (JSC::tryRepatchIn):
        (JSC::repatchIn):
        (JSC::linkSlowFor):
        (JSC::resetGetByID):
        (JSC::resetPutByID):
        (JSC::repatchCall): Deleted.
        * jit/Repatch.h:
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * parser/ResultType.h:
        (JSC::ResultType::ResultType):
        (JSC::ResultType::isInt32):
        (JSC::ResultType::definitelyIsNumber):
        (JSC::ResultType::definitelyIsString):
        (JSC::ResultType::definitelyIsBoolean):
        (JSC::ResultType::mightBeNumber):
        (JSC::ResultType::isNotNumber):
        (JSC::ResultType::forBitOp):
        (JSC::ResultType::bits):
        (JSC::OperandTypes::OperandTypes):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        (JSC::updateArithProfileForBinaryArithOp):
        (JSC::updateResultProfileForBinaryArithOp): Deleted.
        * tests/stress/op-add-exceptions.js: Added.
        (assert):
        (f1):
        (f2):
        (f3):
        (let.oException.valueOf):
        (foo):
        (ident):
        (bar):

2016-07-21  Csaba Osztrogonác  <ossy@webkit.org>

        Clarify testing mode names in run-jsc-stress-tests
        https://bugs.webkit.org/show_bug.cgi?id=160021

        Reviewed by Mark Lam.

        Default should mean really default, not default with disabled FTL, renamed
        - runMozillaTestDefault to runMozillaTestNoFTL
        - runMozillaTestDefaultFTL to runMozillaTestDefault
        - runDefault to runNoFTL
        - runDefaultFTL to runDefault
        - runLayoutTestDefault to runLayoutTestNoFTL
        - runLayoutTestDefaultFTL to runLayoutTestDefault
        - runNoisyTestDefault to runNoisyTestNoFTL
        - runNoisyTestDefaultFTL to runNoisyTestDefault

        * tests/mozilla/mozilla-tests.yaml:
        * tests/stress/lift-tdz-bypass-catch.js:
        * tests/stress/obscure-error-message-dont-crash.js:
        * tests/stress/shadow-chicken-disabled.js:

2016-07-20  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES7] Introduce exponentiation expression
        https://bugs.webkit.org/show_bug.cgi?id=159969

        Reviewed by Saam Barati.

        This patch implements the exponentiation expression, e.g. `x ** y`.
        The exponentiation expression is introduced in ECMA262 2016 and ECMA262 2016
        is already released. So this is not the draft spec.

        The exponentiation expression has 2 interesting points.

        1. Right associative

            To follow the Math expression, ** operator is right associative.
            When we execute `x ** y ** z`, this is handled as `x ** (y ** z)`, not `(x ** y) ** z`.
            This patch introduces the right associativity to the binary operator and handles it
            in the operator precedence parser in Parser.cpp.

        2. LHS of the exponentiation expression is UpdateExpression

            ExponentiationExpression[Yield]:
                UnaryExpression[?Yield]
                UpdateExpression[?Yield] ** ExponentiationExpression[?Yield]

            As we can see, the left hand side of the ExponentiationExpression is UpdateExpression, not UnaryExpression.
            It means that `+x ** y` becomes a syntax error. This is intentional. Without superscript in JS,
            `-x**y` is confusing between `-(x ** y)` and `(-x) ** y`. So ECMA262 intentionally avoids UnaryExpression here.
            If we need to use a negated value, we need to write parentheses explicitly e.g. `(-x) ** y`.
            In this patch, we ensure that the left hand side is not an unary expression by checking an operator in
            parseBinaryExpression. This works since `**` has the highest operator precedence in the binary operators.

        We introduce a new bytecode, op_pow. That simply works as similar as the other binary operators.
        And it is converted to ArithPow in DFG and handled in DFG and FTL.
        In this patch, we take the approach just introducing a new bytecode instead of calling Math.pow.
        This is because we would like to execute ToNumber in the caller side, not in the callee (Math.pow) side.
        And we don't want to compile ** into the following.

            lhsNumber = to_number (lhs)
            rhsNumber = to_number (rhs)
            call Math.pow(lhsNumber, rhsNumber)

        We ensure that this patch passes all the test262 tests related to the exponentiation expression.

        The only sensitive part to the performance is the parser changes.
        So we measured the code-load performance and it is neutral in my x64 Linux box (hanayamata).

            Collected 30 samples per benchmark/VM, with 30 VM invocations per benchmark. Emitted a call to
            gc() between sample measurements. Used 1 benchmark iteration per VM invocation for warm-up. Used
            the jsc-specific preciseTime() function to get microsecond-level timing. Reporting benchmark
            execution times with 95% confidence intervals in milliseconds.

                                     baseline                  patched

            closure              0.60499+-0.00250          0.60180+-0.00244
            jquery               7.89175+-0.02433    ?     7.91287+-0.04759       ?

            <geometric>          2.18499+-0.00523          2.18207+-0.00689         might be 1.0013x faster

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::emitReadModifyAssignment):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_pow):
        * llint/LowLevelInterpreter.asm:
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::operatorStackShouldReduce):
        (JSC::ASTBuilder::makePowNode):
        (JSC::ASTBuilder::makeMultNode):
        (JSC::ASTBuilder::makeDivNode):
        (JSC::ASTBuilder::makeModNode):
        (JSC::ASTBuilder::makeSubNode):
        (JSC::ASTBuilder::makeBinaryNode):
        (JSC::ASTBuilder::operatorStackHasHigherPrecedence): Deleted.
        * parser/Lexer.cpp:
        (JSC::Lexer<T>::lex):
        * parser/NodeConstructors.h:
        (JSC::PowNode::PowNode):
        * parser/Nodes.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseAssignmentExpression):
        (JSC::isUnaryOpExcludingUpdateOp):
        (JSC::Parser<LexerType>::parseBinaryExpression):
        (JSC::isUnaryOp): Deleted.
        * parser/ParserTokens.h:
        (JSC::isUpdateOp):
        (JSC::isUnaryOp):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::operatorStackPop):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        * tests/stress/pow-basics.js: Added.
        (valuesAreClose):
        (mathPowDoubleDouble1):
        (mathPowDoubleInt1):
        (test1):
        (mathPowDoubleDouble2):
        (mathPowDoubleInt2):
        (test2):
        (mathPowDoubleDouble3):
        (mathPowDoubleInt3):
        (test3):
        (mathPowDoubleDouble4):
        (mathPowDoubleInt4):
        (test4):
        (mathPowDoubleDouble5):
        (mathPowDoubleInt5):
        (test5):
        (mathPowDoubleDouble6):
        (mathPowDoubleInt6):
        (test6):
        (mathPowDoubleDouble7):
        (mathPowDoubleInt7):
        (test7):
        (mathPowDoubleDouble8):
        (mathPowDoubleInt8):
        (test8):
        (mathPowDoubleDouble9):
        (mathPowDoubleInt9):
        (test9):
        (mathPowDoubleDouble10):
        (mathPowDoubleInt10):
        (test10):
        (mathPowDoubleDouble11):
        (mathPowDoubleInt11):
        (test11):
        * tests/stress/pow-coherency.js: Added.
        (pow42):
        (build42AsDouble.opaqueAdd):
        (build42AsDouble):
        (powDouble42):
        (clobber):
        (pow42NoConstantFolding):
        (powDouble42NoConstantFolding):
        * tests/stress/pow-evaluation-order.js: Added.
        (shouldBe):
        (throw.new.Error):
        * tests/stress/pow-expects-update-expression-on-lhs.js: Added.
        (testSyntax):
        (testSyntaxError):
        (throw.new.Error):
        (let.token.of.tokens.testSyntax.pow):
        (testSyntax.pow):
        * tests/stress/pow-integer-exponent-fastpath.js: Added.
        (valuesAreClose):
        (mathPowDoubleDoubleTestExponentFifty):
        (mathPowDoubleIntTestExponentFifty):
        (testExponentFifty):
        (mathPowDoubleDoubleTestExponentTenThousands):
        (mathPowDoubleIntTestExponentTenThousands):
        (testExponentTenThousands):
        * tests/stress/pow-nan-behaviors.js: Added.
        (testIntegerBaseWithNaNExponentStatic):
        (mathPowIntegerBaseWithNaNExponentDynamic):
        (testIntegerBaseWithNaNExponentDynamic):
        (testFloatingPointBaseWithNaNExponentStatic):
        (mathPowFloatingPointBaseWithNaNExponentDynamic):
        (testFloatingPointBaseWithNaNExponentDynamic):
        (testNaNBaseStatic):
        (mathPowNaNBaseDynamic1):
        (mathPowNaNBaseDynamic2):
        (mathPowNaNBaseDynamic3):
        (mathPowNaNBaseDynamic4):
        (testNaNBaseDynamic):
        (infiniteExponentsStatic):
        (mathPowInfiniteExponentsDynamic1):
        (mathPowInfiniteExponentsDynamic2):
        (mathPowInfiniteExponentsDynamic3):
        (mathPowInfiniteExponentsDynamic4):
        (infiniteExponentsDynamic):
        * tests/stress/pow-simple.js: Added.
        (shouldBe):
        (throw.new.Error):
        * tests/stress/pow-stable-results.js: Added.
        (opaquePow):
        (isIdentical):
        * tests/stress/pow-to-number-should-be-executed-in-code-side.js: Added.
        (shouldBe):
        (throw.new.Error):
        * tests/stress/pow-with-constants.js: Added.
        (exponentIsZero):
        (testExponentIsZero):
        (exponentIsOne):
        (testExponentIsOne):
        (powUsedAsSqrt):
        (testPowUsedAsSqrt):
        (powUsedAsOneOverSqrt):
        (testPowUsedAsOneOverSqrt):
        (powUsedAsSquare):
        (testPowUsedAsSquare):
        (intIntConstantsSmallNumbers):
        (intIntConstantsLargeNumbers):
        (intIntSmallConstants):
        (intDoubleConstants):
        (doubleDoubleConstants):
        (doubleIntConstants):
        (testBaseAndExponentConstantLiterals):
        (exponentIsIntegerConstant):
        (testExponentIsIntegerConstant):
        (exponentIsDoubleConstant):
        (testExponentIsDoubleConstant):
        (exponentIsInfinityConstant):
        (testExponentIsInfinityConstant):
        (exponentIsNegativeInfinityConstant):
        (testExponentIsNegativeInfinityConstant):
        * tests/stress/pow-with-never-NaN-exponent.js: Added.
        (exponentIsNonNanDouble1):
        (exponentIsNonNanDouble2):
        (testExponentIsDoubleConstant):
        * tests/test262.yaml:

2016-07-18  Filip Pizlo  <fpizlo@apple.com>

        Switching on symbols should be fast
        https://bugs.webkit.org/show_bug.cgi?id=158892

        Reviewed by Keith Miller.
        
        This does two things: fixes some goofs in our lowering of symbol equality and adds a new phase
        to B3 to infer switch statements from linear chains of branches.
        
        This changes how we compile equality to Symbols to constant-fold the load of the Symbol's UID.
        This is necessary for making switches on Symbols inferrable. This also gives us the ability to
        efficiently compile strict equality comparisons of SymbolUse and UntypedUse.

        This adds a new phase to B3, which finds chains of branches that test for (in)equality on the
        same value and constants, and turns them into a Switch. This can turn O(n) code into
        O(log n) code, or even O(1) code if the switch cases are dense.
        
        This can make a big difference in JS. Say you write a switch in which the case statements are
        variable resolutions. The bytecode generator cannot use a bytecode switch in this case, since
        we're required to evaluate the resolutions in order. But in DFG IR, we will often turn those
        variable resolutions into constants, since we do that for any immutable singleton. This means
        that B3 will see a chain of Branches: the else case of one Branch will point to a basic block
        that does nothing but Branch on equality on the same value as the first Branch.

        The inference algorithm is quite simple. The basic building block is the ability to summarize
        a block's switch behavior. For a block that ends in a switch, this is just the collection of
        switch cases. For a block that ends in a branch, we recognize Branch(Equal(value, const)),
        Branch(NotEqual(value, const)), and Branch(value). Each of these are summarized as if they
        were one-case switches. We infer a new switch if both some block and its sole predecessor
        can be described as switches on the same value, nothing shady is going on (like loops), and
        the block in question does no work other than this switch. In that case, the block is killed
        and its cases (which we get from the summary) are added to the predecessor's switch. This
        algorithm runs to fixpoint.
        
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3Generate.cpp:
        (JSC::B3::generateToAir):
        * b3/B3InferSwitches.cpp: Added.
        (JSC::B3::inferSwitches):
        * b3/B3InferSwitches.h: Added.
        * b3/B3Procedure.h:
        (JSC::B3::Procedure::cfg):
        * b3/B3ReduceStrength.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::performSubstitution):
        (JSC::B3::Value::isFree):
        (JSC::B3::Value::dumpMeta):
        * b3/B3Value.h:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileCheckIdent):
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
        (JSC::FTL::DFG::LowerDFGToB3::lowSymbol):
        (JSC::FTL::DFG::LowerDFGToB3::lowSymbolUID):
        (JSC::FTL::DFG::LowerDFGToB3::lowNonNullObject):

2016-07-20  Filip Pizlo  <fpizlo@apple.com>

        FTL snippet generators should be able to request a different register for output and input
        https://bugs.webkit.org/show_bug.cgi?id=160010
        rdar://problem/27439330

        Reviewed by Saam Barati.
        
        The BitOr and BitXor snippet generators have problems if the register for the right input is
        the same as the register for the result. We could fix those generators, but I'm not convinced
        that the other snippet generators don't have this bug. So, the approach that this patch takes
        is to teach the FTL to request that B3 to use a different register for the result than for
        any input to the snippet patchpoint.
        
        Air already has the ability to let any instruction do an EarlyDef, which means exactly this.
        But B3 did not expose this via ValueRep. This patch exposes this in ValueRep as
        SomeEarlyRegister. That's most of the change.
        
        This adds a testb3 test for SomeEarlyRegister and a regression test for this particular
        problem. The regression test failed on trunk JSC before this.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3PatchpointSpecial.cpp:
        (JSC::B3::PatchpointSpecial::forEachArg):
        (JSC::B3::PatchpointSpecial::admitsStack):
        * b3/B3StackmapSpecial.cpp:
        (JSC::B3::StackmapSpecial::forEachArgImpl):
        (JSC::B3::StackmapSpecial::isArgValidForRep):
        * b3/B3Validate.cpp:
        * b3/B3ValueRep.cpp:
        (JSC::B3::ValueRep::addUsedRegistersTo):
        (JSC::B3::ValueRep::dump):
        (WTF::printInternal):
        * b3/B3ValueRep.h:
        (JSC::B3::ValueRep::ValueRep):
        (JSC::B3::ValueRep::reg):
        (JSC::B3::ValueRep::isAny):
        (JSC::B3::ValueRep::isReg):
        (JSC::B3::ValueRep::isSomeRegister): Deleted.
        * b3/testb3.cpp:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::emitBinarySnippet):
        (JSC::FTL::DFG::LowerDFGToB3::emitBinaryBitOpSnippet):
        (JSC::FTL::DFG::LowerDFGToB3::emitRightShiftSnippet):
        * tests/stress/ftl-bit-xor-right-result-interference.js: Added.

2016-07-20  Michael Saboff  <msaboff@apple.com>

        CrashOnOverflow in JSC::Yarr::YarrPatternConstructor::setupAlternativeOffsets
        https://bugs.webkit.org/show_bug.cgi?id=159954

        Reviewed by Benjamin Poulain.

        YarrPatternConstructor::setupAlternativeOffsets() is using the checked arithmetic class
        Checked<>, for offset calculations.  However the default use will just crash on
        overflow.  Instead we should stop processing and propagate the error up the call stack.

        Consolidated explicit error string with the common RegExp parsing error logic.
        Moved that logic to YarrPattern as that seems like a better common place to put it.

        * jit/JITOperations.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * tests/stress/regress-159954.js: New test.
        * yarr/YarrParser.h:
        (JSC::Yarr::Parser::CharacterClassParserDelegate::CharacterClassParserDelegate):
        (JSC::Yarr::Parser::CharacterClassParserDelegate::atomPatternCharacter):
        (JSC::Yarr::Parser::Parser):
        (JSC::Yarr::Parser::isIdentityEscapeAnError):
        (JSC::Yarr::Parser::parseEscape):
        (JSC::Yarr::Parser::parseCharacterClass):
        (JSC::Yarr::Parser::parseParenthesesBegin):
        (JSC::Yarr::Parser::parseParenthesesEnd):
        (JSC::Yarr::Parser::parseQuantifier):
        (JSC::Yarr::Parser::parseTokens):
        (JSC::Yarr::Parser::parse):
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::YarrPatternConstructor::disjunction):
        (JSC::Yarr::YarrPatternConstructor::setupDisjunctionOffsets):
        (JSC::Yarr::YarrPatternConstructor::setupOffsets):
        (JSC::Yarr::YarrPattern::errorMessage):
        (JSC::Yarr::YarrPattern::compile):
        * yarr/YarrPattern.h:
        (JSC::Yarr::YarrPattern::reset):

2016-07-19  Filip Pizlo  <fpizlo@apple.com>

        The default testing mode should not involve disabling the FTL JIT
        https://bugs.webkit.org/show_bug.cgi?id=159929

        Rubber stamped by Mark Lam and Saam Barati.
        
        Use the new powers to make some tests run only in the default configuration (i.e. FTL,
        concurrent JIT).

        * tests/mozilla/mozilla-tests.yaml:

2016-07-19  Keith Miller  <keith_miller@apple.com>

        Test262 should have a file with the revision and url
        https://bugs.webkit.org/show_bug.cgi?id=159937

        Reviewed by Mark Lam.

        The file.

        * tests/test262/test262-Revision.txt: Added.

2016-07-19  Anders Carlsson  <andersca@apple.com>

        WebCore-7602.1.42 fails to build: error: private field 'm_vm' is not used
        https://bugs.webkit.org/show_bug.cgi?id=159944
        rdar://problem/27420308

        Reviewed by Dan Bernstein.

        Wrap the m_vm declaration and initialization in conditional guards.

        * Scripts/builtins/builtins_generate_internals_wrapper_header.py:
        (generate_members):
        * Scripts/builtins/builtins_generate_internals_wrapper_implementation.py:
        (BuiltinsInternalsWrapperImplementationGenerator.generate_constructor):
        Add guards.

        * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
        Update expected results.

2016-07-19  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION (r203348-r203368): ASSERTION FAILED: from.isCell() && from.asCell()->JSCell::inherits(std::remove_pointer<To>::type::info())
        https://bugs.webkit.org/show_bug.cgi?id=159930

        Reviewed by Geoffrey Garen.
        
        The problem is that the 32-bit DFG can flush the scope register as an unboxed cell, but the
        Register::scope() method was causing us to assert that it's a JSValue with proper cell
        boxing. We could have forced the DFG to flush it as a boxed JSValue, but I don't think that
        would have made anything better. This fixes the issue by teaching Register::scope() that it
        might see unboxed cells.

        * runtime/JSScope.h:
        (JSC::Register::scope):
        (JSC::ExecState::lexicalGlobalObject):

2016-07-19  Filip Pizlo  <fpizlo@apple.com>

        B3 methods that mutate the successors array should take FrequentedBlock by value
        https://bugs.webkit.org/show_bug.cgi?id=159935

        Reviewed by Michael Saboff.
        
        This bug was found by ASan testing. setSuccessors() takes a const FrequentedBlock&, and the
        caller that caused the ASan crash was doing:

        block->setSuccessors(block->notTaken())

        So, inside setSuccessors(), after we resize() the successors array, the const
        FrequentedBlock& points to nonsense.

        The fix is to pass FrequentedBlock by value in all of these kinds of methods.
        
        No new tests, but ASan testing catches this instantly for anything that triggers CFG
        simplification in B3. So like half of our tests.

        * b3/B3BasicBlock.cpp:
        (JSC::B3::BasicBlock::clearSuccessors):
        (JSC::B3::BasicBlock::appendSuccessor):
        (JSC::B3::BasicBlock::setSuccessors):
        * b3/B3BasicBlock.h:
        (JSC::B3::BasicBlock::successors):
        (JSC::B3::BasicBlock::successorBlock):
        * b3/B3Value.cpp:
        (JSC::B3::Value::replaceWithPhi):
        (JSC::B3::Value::replaceWithJump):
        (JSC::B3::Value::replaceWithOops):
        * b3/B3Value.h:

2016-07-18  Joseph Pecoraro  <pecoraro@apple.com>

        Make builtin TypeErrors consistent
        https://bugs.webkit.org/show_bug.cgi?id=159899

        Reviewed by Keith Miller.

        Converge on the single TypeError for non-coercible this objects in builtins.
        Also update some other style to be more consistent with-in builtins.

        * builtins/ArrayIteratorPrototype.js:
        (next):
        * builtins/ArrayPrototype.js:
        (values):
        (keys):
        (entries):
        (reduce):
        (reduceRight):
        (every):
        (forEach):
        (filter):
        (map):
        (some):
        (fill):
        (find):
        (findIndex):
        (includes):
        (sort):
        (concatSlowPath):
        (copyWithin):
        * builtins/StringPrototype.js:
        (match):
        (repeat):
        (padStart):
        (padEnd):
        (intrinsic.StringPrototypeReplaceIntrinsic.replace):
        (localeCompare):
        (search):
        (split):
        * tests/es6/String.prototype_methods_String.prototype.padEnd.js:
        * tests/es6/String.prototype_methods_String.prototype.padStart.js:
        * tests/stress/array-iterators-next-error-messages.js:
        (catch):
        * tests/stress/array-iterators-next-with-call.js:
        * tests/stress/regexp-match.js:
        (shouldThrow):
        * tests/stress/regexp-search.js:
        (shouldThrow):

2016-07-17  Filip Pizlo  <fpizlo@apple.com>

        Implement table-based switches in B3/Air
        https://bugs.webkit.org/show_bug.cgi?id=151141

        Reviewed by Benjamin Poulain.

        If a switch statement gets large, it's better to express it as an indirect jump rather than
        using a binary switch (divide-and-conquer tree of comparisons leading to O(log n) branches to
        get to the switch case). When dealing with integer switches, FTL will already use the B3
        Switch and expect this to get lowered as efficiently as possible; it's a bug that B3 will
        always use a binary switch rather than indirect jumps. When dealing with switches over some
        more sophisticated types, we'd want FTL to build an indirect jump table itself and use
        something like a hashtable to feed it. In that case, there will be no B3 Switch; we'll want
        some way for the FTL to directly express an indirection jump when emitting B3.
        
        This implies that we want B3 to have the ability to lower Switch to indirect jumps and to
        expose those indirect jumps in IR so that the FTL could do its own indirect jumps for
        switches over more complicated things like strings. But indirect jumps are tough to express
        in IR. For example, the LLVM approach ("indirectbr" and "blockaddress", see
        http://blog.llvm.org/2010/01/address-of-label-and-indirect-branches.html) means that some
        control flow edges cannot be split. Indirectbr takes an address as input and jumps to it, and
        blockaddress lets you build jump tables out of basic block addresses. This means that the
        compiler can never change any successor of an indirectbr, since the client will have already
        arranged for that indirectbr to jump to exactly those successors. We don't want such
        restrictions in B3, since B3 relies on being able to break critical edges for SSA conversion.
        Also, indirectbr is not cloneable, which would break any hope of doing specialization-based
        transformations like we want to do for multiple entrypoints (bug 159391). The goal of this
        change is to let clients do indirect jumps without placing any restrictions on IR.
        
        The trick is to allow Patchpoints to be used as block terminals. Patchpoints already allow
        clients of B3 to emit whatever code they like. Patchpoints are friendly to B3's other
        transformations because the client of the patchpoint has to play along with whatever
        decisions B3 had made around the patchpoint: what registers got used, what the control flow
        looks like, etc. Patchpoints can even be cloned by B3, and the client has to accommodate this
        in their patchpoint generator. It turns out that using Patchpoints as terminals is quite
        natural. We accomplish this by moving the successor edges out of ControlValue and into
        BasicBlock, and removing ControlValue entirely. This way, any Value subclass can be a
        terminal. It was already true that a Value is a terminal if value->effects().terminal, which
        works great with Patchpoints since they control their effects via PatchpointValue::effects.
        You can make your Patchpoint into a terminal by placing it at the end of a block and doing:
        
        patchpoint->effects.terminal = true;
        
        A Patchpoints in terminal position gets access to additional API in StackmapGenerationParams.
        The generator can get a Box<Label> for each successor to its owning block. For example, to
        implement a jump-table-based switch, you would make your patchpoint take the table index as
        its sole input. Inside the generator, you allocate the jump table and emit a BaseIndex jump
        that uses the jump table pointer (which will be a constant known to the generator since it
        just allocated it) as the base and the patchpoint input as an index. The jump table can be
        populated by MacroAssemblerCodePtr's computed by installing a link task to resolve the labels
        to concrete locations. This change makes LowerMacros do such a lowering for Switches that can
        benefit from jump tables. This happens recursively: if the original Switch is too sparse, we
        will divide-and-conquer as before. If at any recursion step we find that the remaining cases
        are dense and large enough to profit from a jump table, then those cases will be lowered to a
        Patchpoint that does the table jump. This is a fun way to do stepwise lowering: LowerMacros
        is essentially pre-lowering the Switch directly to machine code, and wrapping that machine
        code in a Patchpoint so that the rest of the compiler doesn't have to know anything about
        what happened. I suspect that in the future we will want to do other pre-lowerings this way,
        whenever the B3 IR phases have some special knowledge about what machine code should be
        emitted and it would be annoying to drag that knowledge through the rest of the compiler.
        
        One downside of this change is that we used ControlValue in so many places. Most of this
        patch involves removing references to ControlValue. It would be less than 100kb if it wasn't
        for that. To make this a bit easier, I added "appendNewControlValue" methods to BasicBlock,
        which allocate a Value and set the successors as if you had done "appendNew<ControlValue>".
        This made for an easy search-and-replace in testb3 and FTLOutput. I filed bug 159440 to
        remove this ugly stopgap method.
        
        I think that we will also end up using this facility to extend our use of snippets. We
        already use shared snippet generators for the generic forms of arithmetic. We will probably
        also want to do this for generic forms of branches. This wouldn't have been possible prior to
        this change, since there would have been no way to emit a control snippet in FTL. Now we can
        emit control snippets using terminal patchpoints.

        This is a ~30% speed-up on microbenchmarks that have big switch statements (~60 cases). It's
        not a speed-up on mainstream benchmarks.
        
        This also adds a new test to testb3 for terminal Patchpoints, Get, and Set. The FTL does not
        currently use terminal Patchpoints directly, but we want this to be possible. It also doesn't
        use Get/Set directly even though we want this to be possible. It's important to test these
        since opcodes that result from lowering don't affect early phases, so we could have
        regressions in early phases related to these opcodes that wouldn't be caught by any JS test.
        So, this adds a very basic threaded interpreter to testb3 for a Brainfuck-style language, and
        tests it by having it run a program that prints the numbers 1..100 in a loop. Unlike a real
        threaded interpreter, it uses a common dispatch block rather than having dispatch at the
        terminus of each opcode. That's necessary because PolyJump is not cloneable. The state of the
        interpreter is represented using Variables that we Get and Set, so it tests Get/Set as well.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::jump):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::jump):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::jmp_m):
        * b3/B3BasicBlock.cpp:
        (JSC::B3::BasicBlock::append):
        (JSC::B3::BasicBlock::appendNonTerminal):
        (JSC::B3::BasicBlock::removeLast):
        (JSC::B3::BasicBlock::appendIntConstant):
        (JSC::B3::BasicBlock::clearSuccessors):
        (JSC::B3::BasicBlock::appendSuccessor):
        (JSC::B3::BasicBlock::setSuccessors):
        (JSC::B3::BasicBlock::replaceSuccessor):
        (JSC::B3::BasicBlock::addPredecessor):
        (JSC::B3::BasicBlock::deepDump):
        (JSC::B3::BasicBlock::appendNewControlValue):
        * b3/B3BasicBlock.h:
        (JSC::B3::BasicBlock::numSuccessors):
        (JSC::B3::BasicBlock::successor):
        (JSC::B3::BasicBlock::successors):
        (JSC::B3::BasicBlock::successorBlock):
        (JSC::B3::BasicBlock::successorBlocks):
        (JSC::B3::BasicBlock::numPredecessors):
        (JSC::B3::BasicBlock::predecessor):
        (JSC::B3::BasicBlock::frequency):
        * b3/B3BasicBlockInlines.h:
        (JSC::B3::BasicBlock::replaceLastWithNew):
        (JSC::B3::BasicBlock::taken):
        (JSC::B3::BasicBlock::notTaken):
        (JSC::B3::BasicBlock::fallThrough):
        (JSC::B3::BasicBlock::numSuccessors): Deleted.
        (JSC::B3::BasicBlock::successor): Deleted.
        (JSC::B3::BasicBlock::successors): Deleted.
        (JSC::B3::BasicBlock::successorBlock): Deleted.
        (JSC::B3::BasicBlock::successorBlocks): Deleted.
        * b3/B3BlockInsertionSet.cpp:
        (JSC::B3::BlockInsertionSet::splitForward):
        * b3/B3BreakCriticalEdges.cpp:
        (JSC::B3::breakCriticalEdges):
        * b3/B3CaseCollection.cpp: Added.
        (JSC::B3::CaseCollection::dump):
        * b3/B3CaseCollection.h: Added.
        (JSC::B3::CaseCollection::CaseCollection):
        (JSC::B3::CaseCollection::operator[]):
        (JSC::B3::CaseCollection::iterator::iterator):
        (JSC::B3::CaseCollection::iterator::operator*):
        (JSC::B3::CaseCollection::iterator::operator++):
        (JSC::B3::CaseCollection::iterator::operator==):
        (JSC::B3::CaseCollection::iterator::operator!=):
        (JSC::B3::CaseCollection::begin):
        (JSC::B3::CaseCollection::end):
        * b3/B3CaseCollectionInlines.h: Added.
        (JSC::B3::CaseCollection::fallThrough):
        (JSC::B3::CaseCollection::size):
        (JSC::B3::CaseCollection::at):
        * b3/B3CheckSpecial.cpp:
        (JSC::B3::CheckSpecial::CheckSpecial):
        (JSC::B3::CheckSpecial::hiddenBranch):
        * b3/B3Common.h:
        (JSC::B3::is64Bit):
        * b3/B3ControlValue.cpp: Removed.
        * b3/B3ControlValue.h: Removed.
        * b3/B3DataSection.cpp:
        (JSC::B3::DataSection::DataSection):
        * b3/B3DuplicateTails.cpp:
        * b3/B3FixSSA.cpp:
        * b3/B3FoldPathConstants.cpp:
        * b3/B3LowerMacros.cpp:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::run):
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3MathExtras.cpp:
        (JSC::B3::powDoubleInt32):
        * b3/B3Opcode.h:
        (JSC::B3::isConstant):
        (JSC::B3::isDefinitelyTerminal):
        * b3/B3PatchpointSpecial.cpp:
        (JSC::B3::PatchpointSpecial::generate):
        (JSC::B3::PatchpointSpecial::isTerminal):
        (JSC::B3::PatchpointSpecial::dumpImpl):
        * b3/B3PatchpointSpecial.h:
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::resetReachability):
        * b3/B3Procedure.h:
        (JSC::B3::Procedure::lastPhaseName):
        (JSC::B3::Procedure::byproducts):
        * b3/B3ReduceStrength.cpp:
        * b3/B3StackmapGenerationParams.cpp:
        (JSC::B3::StackmapGenerationParams::unavailableRegisters):
        (JSC::B3::StackmapGenerationParams::successorLabels):
        (JSC::B3::StackmapGenerationParams::fallsThroughToSuccessor):
        (JSC::B3::StackmapGenerationParams::proc):
        * b3/B3StackmapGenerationParams.h:
        (JSC::B3::StackmapGenerationParams::gpScratch):
        (JSC::B3::StackmapGenerationParams::fpScratch):
        * b3/B3SwitchValue.cpp:
        (JSC::B3::SwitchValue::~SwitchValue):
        (JSC::B3::SwitchValue::removeCase):
        (JSC::B3::SwitchValue::hasFallThrough):
        (JSC::B3::SwitchValue::setFallThrough):
        (JSC::B3::SwitchValue::appendCase):
        (JSC::B3::SwitchValue::dumpSuccessors):
        (JSC::B3::SwitchValue::dumpMeta):
        (JSC::B3::SwitchValue::cloneImpl):
        (JSC::B3::SwitchValue::SwitchValue):
        * b3/B3SwitchValue.h:
        (JSC::B3::SwitchValue::accepts):
        (JSC::B3::SwitchValue::caseValues):
        (JSC::B3::SwitchValue::cases):
        (JSC::B3::SwitchValue::fallThrough): Deleted.
        (JSC::B3::SwitchValue::size): Deleted.
        (JSC::B3::SwitchValue::at): Deleted.
        (JSC::B3::SwitchValue::operator[]): Deleted.
        (JSC::B3::SwitchValue::iterator::iterator): Deleted.
        (JSC::B3::SwitchValue::iterator::operator*): Deleted.
        (JSC::B3::SwitchValue::iterator::operator++): Deleted.
        (JSC::B3::SwitchValue::iterator::operator==): Deleted.
        (JSC::B3::SwitchValue::iterator::operator!=): Deleted.
        (JSC::B3::SwitchValue::begin): Deleted.
        (JSC::B3::SwitchValue::end): Deleted.
        * b3/B3Validate.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::replaceWithPhi):
        (JSC::B3::Value::replaceWithJump):
        (JSC::B3::Value::replaceWithOops):
        (JSC::B3::Value::dump):
        (JSC::B3::Value::deepDump):
        (JSC::B3::Value::dumpSuccessors):
        (JSC::B3::Value::negConstant):
        (JSC::B3::Value::typeFor):
        * b3/B3Value.h:
        * b3/air/AirCode.cpp:
        (JSC::B3::Air::Code::addFastTmp):
        (JSC::B3::Air::Code::addDataSection):
        (JSC::B3::Air::Code::jsHash):
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::isFastTmp):
        (JSC::B3::Air::Code::setLastPhaseName):
        * b3/air/AirCustom.h:
        (JSC::B3::Air::PatchCustom::shouldTryAliasingDef):
        (JSC::B3::Air::PatchCustom::isTerminal):
        (JSC::B3::Air::PatchCustom::hasNonArgNonControlEffects):
        (JSC::B3::Air::PatchCustom::generate):
        (JSC::B3::Air::CCallCustom::admitsStack):
        (JSC::B3::Air::CCallCustom::isTerminal):
        (JSC::B3::Air::CCallCustom::hasNonArgNonControlEffects):
        (JSC::B3::Air::ShuffleCustom::admitsStack):
        (JSC::B3::Air::ShuffleCustom::isTerminal):
        (JSC::B3::Air::ShuffleCustom::hasNonArgNonControlEffects):
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::generate):
        * b3/air/AirGenerationContext.h:
        * b3/air/AirInst.h:
        (JSC::B3::Air::Inst::hasNonControlEffects):
        * b3/air/AirSimplifyCFG.cpp:
        (JSC::B3::Air::simplifyCFG):
        * b3/air/AirSpecial.cpp:
        (JSC::B3::Air::Special::shouldTryAliasingDef):
        (JSC::B3::Air::Special::isTerminal):
        (JSC::B3::Air::Special::hasNonArgNonControlEffects):
        * b3/air/AirSpecial.h:
        * b3/air/AirValidate.cpp:
        * b3/air/opcode_generator.rb:
        * b3/testb3.cpp:
        * ftl/FTLLowerDFGToB3.cpp:
        * ftl/FTLOutput.cpp:
        (JSC::FTL::Output::jump):
        (JSC::FTL::Output::branch):
        (JSC::FTL::Output::ret):
        (JSC::FTL::Output::unreachable):
        (JSC::FTL::Output::speculate):
        (JSC::FTL::Output::trap):
        (JSC::FTL::Output::anchor):
        (JSC::FTL::Output::decrementSuperSamplerCount):
        (JSC::FTL::Output::addIncomingToPhi):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::constIntPtr):
        (JSC::FTL::Output::callWithoutSideEffects):
        (JSC::FTL::Output::switchInstruction):
        (JSC::FTL::Output::phi):
        (JSC::FTL::Output::addIncomingToPhi):

2016-07-18  Anders Carlsson  <andersca@apple.com>

        WebKit nightly fails to build on macOS Sierra
        https://bugs.webkit.org/show_bug.cgi?id=159902
        rdar://problem/27365672

        Reviewed by Tim Horton.

        * icu/unicode/ucurr.h: Added.
        Add ucurr.h from ICU.

2016-07-18  Michael Saboff  <msaboff@apple.com>

        ASSERTION FAILED: : (year >= 1970 && yearday >= 0) || (year < 1970 && yearday < 0) -- WTF/wtf/DateMath.cpp
        https://bugs.webkit.org/show_bug.cgi?id=159883

        Reviewed by Filip Pizlo.

        New test.

        * tests/stress/regress-159883.js: Added.

2016-07-12  Filip Pizlo  <fpizlo@apple.com>

        MarkedBlocks should know that they can be used for more than JSCells
        https://bugs.webkit.org/show_bug.cgi?id=159643

        Reviewed by Geoffrey Garen.
        
        This teaches the Heap that a MarkedBlock may hold either JSCells, or Auxiliary, which is
        not a JSCell. It teaches the heap and all of the things that walk the heap to ignore
        non-JSCells whenever they are looking for global objects, JSObjects, and things to trace
        for debugging or profiling. The idea is that we will be able to allocate butterflies and
        typed array backing stores as Auxiliary in MarkedSpace rather than allocating those things
        in CopiedSpace. That's what bug 159658 is all about.
        
        This gives us a new type, called HeapCell, which is just meant to be a class distinct from
        JSCell or any type we would use for Auxiliary. For convenience, JSCell is a subclass of
        HeapCell. HeapCell has an enum called HeapCell::Kind, which is either HeapCell::JSCell or
        HeapCell::Auxiliary. MarkedSpace no longer speaks of JSCells directly except when dealing
        with destruction.
        
        This change required doing a lot of stuff to all of those functor callbacks, since they
        now take HeapCell* instead of JSCell* and they take an extra HeapCell::Kind argument to
        tell them if they are dealing with JSCells or Auxiliary. I figured that this would be as
        good a time as any to convert those functors to being lambda-compatible. This means that
        operator() must be const. In some cases, converting the operator() to be const would have
        taken more work than just turning the whole thing into a lambda. Whenever this was the
        case, I converted the code to use lambdas. I left a lot of functors alone. In cases where
        the functor would benefit from being a lambda, for example because it would get rid of
        const_casts or mutables, I put in a FIXME referencing bug 159644.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * debugger/Debugger.cpp:
        (JSC::Debugger::SetSteppingModeFunctor::SetSteppingModeFunctor):
        (JSC::Debugger::SetSteppingModeFunctor::operator()):
        (JSC::Debugger::ToggleBreakpointFunctor::ToggleBreakpointFunctor):
        (JSC::Debugger::ToggleBreakpointFunctor::operator()):
        (JSC::Debugger::ClearCodeBlockDebuggerRequestsFunctor::ClearCodeBlockDebuggerRequestsFunctor):
        (JSC::Debugger::ClearCodeBlockDebuggerRequestsFunctor::operator()):
        (JSC::Debugger::ClearDebuggerRequestsFunctor::ClearDebuggerRequestsFunctor):
        (JSC::Debugger::ClearDebuggerRequestsFunctor::operator()):
        * heap/CodeBlockSet.h:
        (JSC::CodeBlockSet::iterate):
        * heap/HandleSet.h:
        (JSC::HandleNode::next):
        (JSC::HandleSet::forEachStrongHandle):
        * heap/Heap.cpp:
        (JSC::GatherHeapSnapshotData::GatherHeapSnapshotData):
        (JSC::GatherHeapSnapshotData::operator()):
        (JSC::RemoveDeadHeapSnapshotNodes::RemoveDeadHeapSnapshotNodes):
        (JSC::RemoveDeadHeapSnapshotNodes::operator()):
        (JSC::Heap::protectedGlobalObjectCount):
        (JSC::Heap::globalObjectCount):
        (JSC::Heap::protectedObjectCount):
        (JSC::Heap::protectedObjectTypeCounts):
        (JSC::Heap::objectTypeCounts):
        (JSC::Heap::deleteAllCodeBlocks):
        (JSC::MarkedBlockSnapshotFunctor::MarkedBlockSnapshotFunctor):
        (JSC::MarkedBlockSnapshotFunctor::operator()):
        (JSC::Zombify::visit):
        (JSC::Zombify::operator()):
        (JSC::Heap::zombifyDeadObjects):
        (JSC::Heap::flushWriteBarrierBuffer):
        * heap/Heap.h:
        (JSC::Heap::handleSet):
        (JSC::Heap::handleStack):
        * heap/HeapCell.cpp: Added.
        (WTF::printInternal):
        * heap/HeapCell.h: Added.
        (JSC::HeapCell::HeapCell):
        (JSC::HeapCell::zap):
        (JSC::HeapCell::isZapped):
        * heap/HeapInlines.h:
        (JSC::Heap::deprecatedReportExtraMemory):
        (JSC::Heap::forEachCodeBlock):
        (JSC::Heap::forEachProtectedCell):
        (JSC::Heap::allocateWithDestructor):
        * heap/HeapStatistics.cpp:
        (JSC::StorageStatistics::visit):
        (JSC::StorageStatistics::operator()):
        * heap/HeapVerifier.cpp:
        (JSC::GatherLiveObjFunctor::visit):
        (JSC::GatherLiveObjFunctor::operator()):
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::allocateBlock):
        (JSC::MarkedAllocator::addBlock):
        (JSC::MarkedAllocator::reset):
        (JSC::MarkedAllocator::lastChanceToFinalize):
        (JSC::LastChanceToFinalize::operator()): Deleted.
        * heap/MarkedAllocator.h:
        (JSC::MarkedAllocator::takeLastActiveBlock):
        (JSC::MarkedAllocator::resumeAllocating):
        (JSC::MarkedAllocator::forEachBlock):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::create):
        (JSC::MarkedBlock::destroy):
        (JSC::MarkedBlock::MarkedBlock):
        (JSC::MarkedBlock::callDestructor):
        (JSC::MarkedBlock::specializedSweep):
        (JSC::SetNewlyAllocatedFunctor::SetNewlyAllocatedFunctor):
        (JSC::SetNewlyAllocatedFunctor::operator()):
        (JSC::MarkedBlock::stopAllocating):
        (JSC::MarkedBlock::didRetireBlock):
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::CountFunctor::CountFunctor):
        (JSC::MarkedBlock::CountFunctor::count):
        (JSC::MarkedBlock::CountFunctor::returnValue):
        (JSC::MarkedBlock::needsDestruction):
        (JSC::MarkedBlock::cellKind):
        (JSC::MarkedBlock::size):
        (JSC::MarkedBlock::clearNewlyAllocated):
        (JSC::MarkedBlock::isMarkedOrNewlyAllocated):
        (JSC::MarkedBlock::isLive):
        (JSC::MarkedBlock::isLiveCell):
        (JSC::MarkedBlock::forEachCell):
        (JSC::MarkedBlock::forEachLiveCell):
        (JSC::MarkedBlock::forEachDeadCell):
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::MarkedSpace):
        (JSC::MarkedSpace::~MarkedSpace):
        (JSC::MarkedSpace::lastChanceToFinalize):
        (JSC::MarkedSpace::sweep):
        (JSC::MarkedSpace::zombifySweep):
        (JSC::MarkedSpace::resetAllocators):
        (JSC::MarkedSpace::visitWeakSets):
        (JSC::MarkedSpace::reapWeakSets):
        (JSC::MarkedSpace::forEachAllocator):
        (JSC::MarkedSpace::stopAllocating):
        (JSC::MarkedSpace::resumeAllocating):
        (JSC::MarkedSpace::isPagedOut):
        (JSC::MarkedSpace::shrink):
        (JSC::clearNewlyAllocatedInBlock):
        (JSC::MarkedSpace::clearNewlyAllocated):
        (JSC::MarkedSpace::clearMarks):
        (JSC::Free::Free): Deleted.
        (JSC::Free::operator()): Deleted.
        (JSC::FreeOrShrink::FreeOrShrink): Deleted.
        (JSC::FreeOrShrink::operator()): Deleted.
        (JSC::VisitWeakSet::VisitWeakSet): Deleted.
        (JSC::VisitWeakSet::operator()): Deleted.
        (JSC::ReapWeakSet::operator()): Deleted.
        (JSC::LastChanceToFinalize::operator()): Deleted.
        (JSC::StopAllocatingFunctor::operator()): Deleted.
        (JSC::ResumeAllocatingFunctor::operator()): Deleted.
        (JSC::ClearNewlyAllocated::operator()): Deleted.
        (JSC::VerifyNewlyAllocated::operator()): Deleted.
        * heap/MarkedSpace.h:
        (JSC::MarkedSpace::forEachLiveCell):
        (JSC::MarkedSpace::forEachDeadCell):
        (JSC::MarkedSpace::allocatorFor):
        (JSC::MarkedSpace::allocateWithDestructor):
        (JSC::MarkedSpace::forEachBlock):
        (JSC::MarkedSpace::didAddBlock):
        (JSC::MarkedSpace::objectCount):
        (JSC::MarkedSpace::size):
        (JSC::MarkedSpace::capacity):
        (JSC::ClearMarks::operator()): Deleted.
        (JSC::Sweep::operator()): Deleted.
        (JSC::ZombifySweep::operator()): Deleted.
        (JSC::MarkCount::operator()): Deleted.
        (JSC::Size::operator()): Deleted.
        * runtime/JSCell.h:
        (JSC::JSCell::zap): Deleted.
        (JSC::JSCell::isZapped): Deleted.
        * runtime/JSCellInlines.h:
        (JSC::allocateCell):
        (JSC::JSCell::isObject):
        (JSC::isZapped): Deleted.
        * runtime/JSGlobalObject.cpp:
        * tools/JSDollarVMPrototype.cpp:
        (JSC::CellAddressCheckFunctor::CellAddressCheckFunctor):
        (JSC::CellAddressCheckFunctor::operator()):

2016-07-18  Filip Pizlo  <fpizlo@apple.com>

        Repeatedly creating and destroying workers that enqueue DFG plans can outpace the DFG worklist, which then causes VM shutdown to stall, which then causes memory growth
        https://bugs.webkit.org/show_bug.cgi?id=159754

        Reviewed by Geoffrey Garen.
        
        If you create and destroy workers at a high rate and those workers enqueue some DFG plans
        that are still not compiled at the time that the worker is closed, then the closed workers
        end up stalling in VM::~VM waiting for the DFG worklist thread to finish those plans. Since
        we don't actually cancel the plans, it's easy to create a situation where the workers
        outpace the DFG worklist, especially if you create many workers at a time and each one
        finishes just after enqueueing those plans.
        
        The solution is to allow VM::~VM to remove plans from the DFG worklist that are related to
        that VM but aren't currently being worked on. That turns out to be an easy change.
        
        I have a test that repros this, but it's quite long-running. I call it workers/bomb.html. We
        may want to exclude it from test runs because of how long it takes.

        * dfg/DFGWorklist.cpp:
        (JSC::DFG::Worklist::removeDeadPlans):
        (JSC::DFG::Worklist::removeNonCompilingPlansForVM):
        (JSC::DFG::Worklist::queueLength):
        (JSC::DFG::Worklist::runThread):
        * dfg/DFGWorklist.h:
        * runtime/VM.cpp:
        (JSC::VM::~VM):

2016-07-17  Filip Pizlo  <fpizlo@apple.com>

        Object.preventExtensions/seal/freeze makes code much slower
        https://bugs.webkit.org/show_bug.cgi?id=143247

        Reviewed by Michael Saboff.
        
        This has been a huge pet peeve of mine for a long time, but I was always afraid of fixing
        it because I thought that it would be hard. Well, it looks like it's not hard at all.
        
        The problem is that you cannot mutate a structure that participates in transition caching.
        You can only clone the structure and mutate that one. But if you do this, you have to make
        a hard choice:
        
        1) Clone the structure without caching the transition. This is what the code did before
           this change. It's the most obvious choice, but it introduces an uncacheable transition
           that leads to an explosion of structures, which then breaks all inline caches.
        
        2) Perform one of the existing cacheable transitions. Cacheable transitions can either add
           properties or they can do one of the NonPropertyTransitions, which until now have been
           restricted to just IndexingType transitions. So, only adding transitions or making
           certain prescribed changes to the indexing type count as cacheable transitions.
        
        This change decouples NonPropertyTransition from IndexingType and adds three new kinds of
        transitions: PreventExtensions, Seal, and Freeze. We have to give any cacheable transition
        a name that fully disambiguates this transition from any other, so that the transition can
        be cached. Since we're already giving them names in an enum, I figured that the most
        pragmatic way to implement them is to have Structure::nonPropertyTransition() case on the
        NonPropertyTransition and implement all of the mutations associated with that transition.
        The alternative would have been to allow callers of nonPropertyTransition() to supply
        something like a lambda that describes the mutation, but this seemed awkward since each
        set of mutations has to anyway be tied to one of the NonPropertyTransition members.
        
        This is an enormous speed-up on microbenchmarks that use Object.preventExtensions(),
        Object.seal(), or Object.freeze(). I don't know if "real" benchmarks use these features
        and I don't really care. This should be fast.

        * runtime/JSObject.cpp:
        (JSC::JSObject::notifyPresenceOfIndexedAccessors):
        (JSC::JSObject::createInitialUndecided):
        (JSC::JSObject::createInitialInt32):
        (JSC::JSObject::createInitialDouble):
        (JSC::JSObject::createInitialContiguous):
        (JSC::JSObject::convertUndecidedToInt32):
        (JSC::JSObject::convertUndecidedToDouble):
        (JSC::JSObject::convertUndecidedToContiguous):
        (JSC::JSObject::convertInt32ToDouble):
        (JSC::JSObject::convertInt32ToContiguous):
        (JSC::JSObject::convertDoubleToContiguous):
        (JSC::JSObject::switchToSlowPutArrayStorage):
        * runtime/Structure.cpp:
        (JSC::Structure::suggestedArrayStorageTransition):
        (JSC::Structure::addPropertyTransition):
        (JSC::Structure::toUncacheableDictionaryTransition):
        (JSC::Structure::sealTransition):
        (JSC::Structure::freezeTransition):
        (JSC::Structure::preventExtensionsTransition):
        (JSC::Structure::takePropertyTableOrCloneIfPinned):
        (JSC::Structure::nonPropertyTransition):
        (JSC::Structure::pin):
        (JSC::Structure::pinForCaching):
        (JSC::Structure::allocateRareData):
        * runtime/Structure.h:
        * runtime/StructureTransitionTable.h:
        (JSC::toAttributes):
        (JSC::changesIndexingType):
        (JSC::newIndexingType):
        (JSC::preventsExtensions):
        (JSC::setsDontDeleteOnAllProperties):
        (JSC::setsReadOnlyOnAllProperties):

2016-07-17  Filip Pizlo  <fpizlo@apple.com>

        RegisterSet should use a Bitmap instead of a BitVector so that it never allocates memory and is trivial to copy
        https://bugs.webkit.org/show_bug.cgi?id=159863

        Reviewed by Saam Barati.
        
        Switch RegisterSet set to Bitmap because Bitmap doesn't ever allocate memory and can be
        assigned by memcpy. This should be a performance improvement for compiler code that does a
        lot of things with RegisterSet. For example, it's one of the fundamental data structures in
        Air. The previous use of BitVector meant that almost every operation on RegisterSet would
        have a slow path call. On ARM64, it would mean memory allocation for any RegisterSet that
        used all available registers.
        
        This meant adding even more GPR/FPR reflection to the MacroAssembler API: we now have consts
        called numGPRs and numFPRs. This is necessary to statically size the Bitmap in RegisterSet.
        
        Here's the breakdown of sizes of RegisterSet on different CPUs:
        
        x86-32: 8 bits (GPRs) + 8 bits (FPRs) + 1 bit (is deleted) = 1x uint32_t.
        x86-64: 16 bits + 16 bits + 1 bit = 2x uint32_t.
        ARMv7: 16 bits + 16 bits + 1 bit = 2x uint32_t.
        ARM64: 32 bits + 32 bits + 1 bit = 3x uint32_t.

        * assembler/MacroAssemblerARM.h:
        * assembler/MacroAssemblerARM64.h:
        * assembler/MacroAssemblerARMv7.h:
        * assembler/MacroAssemblerX86.h:
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::scratchRegister):
        * assembler/MacroAssemblerX86_64.h:
        * jit/RegisterSet.h:
        (JSC::RegisterSet::set):
        (JSC::RegisterSet::get):
        (JSC::RegisterSet::setAll):
        (JSC::RegisterSet::merge):
        (JSC::RegisterSet::filter):
        (JSC::RegisterSet::exclude):
        (JSC::RegisterSet::numberOfSetRegisters):
        (JSC::RegisterSet::RegisterSet):
        (JSC::RegisterSet::isEmptyValue):
        (JSC::RegisterSet::isDeletedValue):
        (JSC::RegisterSet::operator==):
        (JSC::RegisterSet::operator!=):
        (JSC::RegisterSet::hash):
        (JSC::RegisterSet::forEach):
        (JSC::RegisterSet::setMany):

2016-07-15  Filip Pizlo  <fpizlo@apple.com>

        DFG and FTL should support op_call_eval
        https://bugs.webkit.org/show_bug.cgi?id=159786

        Reviewed by Saam Barati.
        
        This adds support for op_call_eval in DFG and FTL by brute force:
        
        - There is now a CallEval() node type, which compiles exactly the same way that we do in
          baseline.
        
        - We teach the DFG and bytecode liveness that the scope register and 'this' are read by
          CallEval()/op_call_eval.
        
        We can compile eval quite well, except that right now we cannot inline functions that use
        eval. It would be nice to do that, but the payoff is probably smaller. "Don't inline users
        of eval" may even be an OK inlining heuristic. Not inlining users of eval allows me to
        reuse the baseline implementation, which is really great. Otherwise, I'd have to get rid
        of things like the rogue reads of scope register and 'this'.
        
        The goal here is to produce speed-ups for code that has functions that do both eval and
        some computational stuff. Obviously, we're not producing any benefit for the eval itself.
        But now the other stuff in a function that uses eval will get to participate in
        optimization.
        
        This is a huge speed-up on microbenchmarks.

        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::printCallOp):
        (JSC::CodeBlock::dumpBytecode):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::setLocal):
        (JSC::DFG::ByteCodeParser::setArgument):
        (JSC::DFG::ByteCodeParser::flush):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::needsScopeRegister):
        (JSC::DFG::Graph::needsFlushedThis):
        * dfg/DFGHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGHeapLocation.h:
        * dfg/DFGMayExit.cpp:
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasHeapPrediction):
        * dfg/DFGNodeType.h:
        * dfg/DFGOSRExitCompiler.cpp:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStackLayoutPhase.cpp:
        (JSC::DFG::StackLayoutPhase::run):
        * dfg/DFGWatchpointCollectionPhase.cpp:
        (JSC::DFG::WatchpointCollectionPhase::handle):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallEval):
        (JSC::FTL::DFG::LowerDFGToB3::compileLoadVarargs):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
        (JSC::AssemblyHelpers::emitDumbVirtualCall):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitTypeOf):
        * jit/JITCall.cpp:
        (JSC::JIT::compileCallEvalSlowCase):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::compileCallEvalSlowCase):
        * jit/JITOperations.cpp:
        * tests/stress/exit-then-eval.js: Added.
        (foo):
        * tests/stress/force-exit-then-eval-dfg.js: Added.
        (foo):
        * tests/stress/force-exit-then-eval.js: Added.
        (foo):

2016-07-12  Filip Pizlo  <fpizlo@apple.com>

        DFG should really support jneq_ptr
        https://bugs.webkit.org/show_bug.cgi?id=159700

        Reviewed by Keith Miller.
        
        Prior to this change, DFG statically speculated that jneq_ptr would always fall through. This
        meant that programs that called o.apply() or o.call() where apply or call weren't the
        expected ones (i.e. the function.prototype.apply/call) would rage-recompile forever.
        
        This adds profiling to jneq_ptr. We now know if it always falls through or sometimes doesn't.
        If it sometimes doesn't, we now emit an actual control flow diamond. I decided to add a new
        NodeType for "equal pointer", since none of the existing ones really captured that. For
        example, there was no way to express "equal pointer" for strings or symbols. We don't use it
        for that right now, but we might, and if we did, then it would be hugely surprising that the
        DFG interpreted this as value equality. So, the DFG now has CompareEqPtr, which means exactly
        what jneq_ptr means by "equal pointer".
        
        This is an enormous speed-up on microbenchmarks. I would assume that it's a speed-up on some
        real things, too, but I don't know that for a fact.

        * bytecode/BytecodeList.json:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitJumpIfNotFunctionCall):
        (JSC::BytecodeGenerator::emitJumpIfNotFunctionApply):
        (JSC::BytecodeGenerator::emitExpectedFunctionSnippet):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasCellOperand):
        * dfg/DFGNodeType.h:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileRecordRegExpCachedResult):
        (JSC::DFG::SpeculativeJIT::compileCompareEqPtr):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGValidate.cpp:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareEqPtr):
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareLess):
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEqConstant): Deleted.
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_jneq_ptr):
        (JSC::JIT::emit_op_eq):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_jneq_ptr):
        (JSC::JIT::emit_op_eq):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

2016-07-12  Filip Pizlo  <fpizlo@apple.com>

        OSR entry into DFG has problems with lexical scoping
        https://bugs.webkit.org/show_bug.cgi?id=159687

        Reviewed by Saam Barati.
        
        What a fun bug! It turns out that uses of lexical scoping, like "let", may sometimes cause us
        to not be able to OSR enter into a loop from baseline to DFG. The bug is in a mitigation for
        a different bug, which in turn had a mitigation for yet another bug, so the story here is a
        long one.
        
        DFG OSR entry has long had a mitigation for the following bug: the DFG bytecode parser may
        choose to make us always OSR exit at some instruction if it thinks that it doesn't have
        enough profiling for that instruction. We will do this if some kinds of put_by_id only
        execute once, for example. This causes problems for loopy benchmarks like this:
        
            put_by_id(something crazy);
            for (var i = 0; i < bigNumber; ++i) simpleMath;
        
        In this case, the put_by_id will have only executed once, and since it did something crazy
        that one time, the bytecode parser will replace it with ForceOSRExit.
        
        This creates an OSR entry bug: DFG CFA will then prove that the loop is unreachable, and will
        tell OSR entry that it's impossible to enter into that loop.
        
        We mitigated this bug a long time ago by recording mustHandleValues for loops at which we
        want to enter. We inject these values into DFG CFA and we force CFA to recognize that the
        loop is reachable even if CFA wanted to prove that it wasn't.
        
        But this leads to another bug: we need to scrape the values from the stack inside
        operationOptimize() and then we need to reason about them in the compiler. Some of those
        values may be garbage, which would cause pandemonium inside the compiler. We also mitigated
        this bug, by only recording the "vars", since those are guaranteed to be reset by op_enter.
        
        And that's where the lexical scoping bug happens: "let" bound variables aren't part of the
        "vars". DFG will see that they are live, but mustHandleValues will not have anything for
        those variables, so CFA will prove that the values are Bottom. Then OSR entry will always
        fail because no value is ever a subset of Bottom.
        
        The first part of the fix is to ensure that mustHandleValues record all of the values on the
        stack (i.e. within m_numCalleeLocals, rather than just m_numVars). But this creates a second
        problem: we may record garbage. This patch includes a better fix for the garbage: before
        touching mustHandleValues we run the bytecode liveness analysis and clear any values that are
        not live. This ensures that we clear the garbage.
        
        This is an enormous speed-up on microbenchmarks that use lexical scoping and have some crazy
        put_by_id in the lead-up to the hot loop.

        * dfg/DFGCFAPhase.cpp:
        (JSC::DFG::CFAPhase::run):
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        (JSC::DFG::Plan::checkLivenessAndVisitChildren):
        (JSC::DFG::Plan::cancel):
        (JSC::DFG::Plan::cleanMustHandleValuesIfNecessary):
        * dfg/DFGPlan.h:
        (JSC::DFG::Plan::canTierUpAndOSREnter):
        * jit/JITOperations.cpp:

2016-07-18  Youenn Fablet  <youenn@apple.com>

        REGRESSION(r202975): --minimal build is broken
        https://bugs.webkit.org/show_bug.cgi?id=159765

        Reviewed by Chris Dumez.

        Covered partially by builtin generated test code.

        Updating generator to add a global compilation guard around the code that generates all global internal properties.
        Split the generate_methods function in two, one dedicated to the visit method and the second one dedicated to
        the initialize method.

        * Scripts/builtins/builtins_generate_internals_wrapper_implementation.py:
        (BuiltinsInternalsWrapperImplementationGenerator.generate_section_for_object): Use splitted generation functions.
        (BuiltinsInternalsWrapperImplementationGenerator.generate_visit_method): Response to generate the visit method.
        (BuiltinsInternalsWrapperImplementationGenerator._generate_initialize_static_globals): Responsible to generate
        the code to initialize the internal globals. This code is put in a global compilation guard in case all
        internals are compiled out by specific builds.
        (BuiltinsInternalsWrapperImplementationGenerator):
        (BuiltinsInternalsWrapperImplementationGenerator.generate_initialize_method): Responsible to generate the
        initialize method.
        (BuiltinsInternalsWrapperImplementationGenerator.generate_methods): Deleted.
        * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result: Copyright change.
        * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result: Ditto.
        * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result: Ditto.
        * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result: Ditto.
        * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result: Reflects partially the built-in
        generator change.

2016-07-18  Keith Miller  <keith_miller@apple.com>

        Fix bad assertions in genericTypedArrayViewPrivateFuncSubarrayCreate
        https://bugs.webkit.org/show_bug.cgi?id=159882
        <rdar://problem/27327111>

        Reviewed by Mark Lam.

        According the spec toInteger can return values we don't consider ints.
        Such as, -0 and +/-Infinity. This broke some assertions in
        genericTypedArrayViewPrivateFuncSubarrayCreate.

        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
        * tests/stress/typedarray-subarray.js:

2016-07-16  Filip Pizlo  <fpizlo@apple.com>

        DFG CSE is broken for MultiGetByOffset
        https://bugs.webkit.org/show_bug.cgi?id=159858

        Reviewed by Saam Barati.
        
        This disabled CSE for MultiGetByOffset. I opened bug 159859 for the long-term fix, which
        would teach CSE (and other passes also) how to decay a removed MultiGetByOffset to a
        CheckStructure. Since we currently just decay MultiGetByOffset to Check, we forget the
        structure checks. So, if we CSE a MultiGetByOffset that checks for one set of structures with
        a heap access on the same property and base that checks for different structures, then we
        will forget some structure checks that we had previously. It's unsound to forget checks in
        DFG IR.
        
        This bug mostly manifested as a high-volume crash at Unreachable in FTL, because we'd prove
        that the code after the MultiGetByOffset was unreachable due to the structure checks and then
        CSE would remove everything but the Unreachable.

        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize): Remove the def() for MultiGetByOffset to disable CSE for this node for now.
        * tests/stress/cse-multi-get-by-offset-remove-checks.js: Added. This used to fail with FTL enabled.
        (Cons1):
        (Cons2):
        (Cons3):
        (foo):
        (bar):

2016-07-17  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Enable test262 module tests
        https://bugs.webkit.org/show_bug.cgi?id=159854

        Reviewed by Saam Barati.

        This patch enables test262 module tests. Before this patch, the modules tests in test262 do not work fine.
        This patch fixes the following 2 things.

        1. Test harness

            Before this patch, there is only one global switch "-m" in jsc shell. So we cannot load the test262 test harness before evaluating the module tests.
            This patch adds a new option, "--module-file=". It is similar to "--strict-file=". When we specify the file with "--module-file=", it is evaluated as
            a module, while the other files are evaluated by following the JSC's default manner. This option allows us to load the test harness files into the
            global context before loading the module tests.

        2. Module's asynchronous errors

            Before this patch, the errors caused in the module evaluation are not handled as the same to the usual sync files. In synchronous execution, we have
            "--exception=" option to pass the expected exception to the JSC shell. But this option does not work in the module evaluation.
            This patch correctly handles this expected exception in the module evaluation promise's fulfill and reject handlers.

        And we fix the YAML file. Now the recorded :fail and :normal are the correct test results for the module tests.

        * jsc.cpp:
        (Script::Script):
        (checkUncaughtException):
        (runWithScripts):
        (printUsageStatement):
        (CommandLine::parseArguments):
        (dumpException): Deleted.
        * tests/test262.yaml:

2016-07-17  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Mask TrustedImm32 to 8bit in MacroAssembler for 8bit operations
        https://bugs.webkit.org/show_bug.cgi?id=159334

        Reviewed by Filip Pizlo.

        Previously, in 8bit operations (like add8, compare8, test8, branch8, branchTest8 etc.),
        we require that the given TrustedImm32 is in range of 8bit. While achieving this in
        the manual MacroAssembler calling is easy, in Air, we don't guarantee that the higher bit
        of the 8bit argument is cleared. So the current assertions are invalid.

        This patch relaxes the above restriction. By removing this assertion,
        8bit operations can take arbitrary 32bit imms. And only lower 8bit are effective when
        emitting the code in these methods.

        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::branchTest8):
        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::store8):
        (JSC::MacroAssemblerARM::branch8):
        (JSC::MacroAssemblerARM::branchTest8):
        (JSC::MacroAssemblerARM::compare8):
        (JSC::MacroAssemblerARM::test8):
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::store8):
        (JSC::MacroAssemblerARM64::branch8):
        (JSC::MacroAssemblerARM64::branchTest8):
        (JSC::MacroAssemblerARM64::compare8):
        (JSC::MacroAssemblerARM64::test8):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::store8):
        (JSC::MacroAssemblerARMv7::branch8):
        (JSC::MacroAssemblerARMv7::branchTest8):
        (JSC::MacroAssemblerARMv7::compare8):
        (JSC::MacroAssemblerARMv7::test8):
        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::store8):
        (JSC::MacroAssemblerMIPS::branch8):
        (JSC::MacroAssemblerMIPS::compare8):
        (JSC::MacroAssemblerMIPS::branchTest8):
        (JSC::MacroAssemblerMIPS::test8):
        * assembler/MacroAssemblerSH4.h:
        (JSC::MacroAssemblerSH4::store8):
        (JSC::MacroAssemblerSH4::branchTest8):
        (JSC::MacroAssemblerSH4::branch8):
        (JSC::MacroAssemblerSH4::compare8):
        (JSC::MacroAssemblerSH4::test8):
        * assembler/MacroAssemblerX86.h:
        (JSC::MacroAssemblerX86::store8):
        (JSC::MacroAssemblerX86::branch8):
        (JSC::MacroAssemblerX86::branchTest8):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::add8):
        (JSC::MacroAssemblerX86Common::store8):
        (JSC::MacroAssemblerX86Common::branch8):
        (JSC::MacroAssemblerX86Common::branchTest8):
        (JSC::MacroAssemblerX86Common::compare8):
        (JSC::MacroAssemblerX86Common::test8):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::store8):
        (JSC::MacroAssemblerX86_64::branch8):
        (JSC::MacroAssemblerX86_64::branchTest8):

2016-07-16  Chris Dumez  <cdumez@apple.com>

        Unreviewed, rolling out r203318.

        Regressed most JS Benchmarks on MacBook Air by ~2% (7% on
        SunSpider)

        Reverted changeset:

        "[JSC] Change some parameters based on a random search"
        https://bugs.webkit.org/show_bug.cgi?id=158514
        http://trac.webkit.org/changeset/203318

2016-07-15  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Convert the remaining createOutOfMemoryError()+throwException() into throwOutOfMemoryError()
        https://bugs.webkit.org/show_bug.cgi?id=159665

        Reviewed by Saam Barati.

        * API/JSTypedArray.cpp:
        (createTypedArray):
        * runtime/Error.cpp:
        (JSC::createOutOfMemoryError):
        * runtime/Error.h:
        * runtime/ExceptionHelpers.cpp:
        (JSC::throwOutOfMemoryError):
        * runtime/JSArrayBufferConstructor.cpp:
        (JSC::constructArrayBuffer):
        * runtime/JSArrayBufferPrototype.cpp:
        (JSC::arrayBufferProtoFuncSlice):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::create):
        (JSC::JSGenericTypedArrayView<Adaptor>::createUninitialized):

2016-07-15  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Change some parameters based on a random search
        https://bugs.webkit.org/show_bug.cgi?id=158514

        Reviewed by Saam Barati.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::optimizationThresholdScalingFactor):
        * runtime/Options.h:

2016-07-15  Mark Lam  <mark.lam@apple.com>

        Assertion failures and crashes with missing TDZ checks for catch-node bindings.
        https://bugs.webkit.org/show_bug.cgi?id=158797

        Reviewed by Saam Barati.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitPushCatchScope):
        (JSC::BytecodeGenerator::emitPopCatchScope):
        * tests/stress/catch-clause-should-be-under-tdz1.js: Added.
        * tests/stress/catch-clause-should-be-under-tdz2.js: Added.
        * tests/stress/catch-clause-should-be-under-tdz3.js: Added.
        * tests/stress/catch-clause-should-be-under-tdz4.js: Added.
        * tests/stress/catch-clause-should-be-under-tdz5.js: Added.

2016-07-15  Geoffrey Garen  <ggaren@apple.com>

        Added a makeRef<T> helper
        https://bugs.webkit.org/show_bug.cgi?id=159835

        Reviewed by Andreas Kling.

        Anders told me to!

        * inspector/InjectedScriptHost.cpp:
        (Inspector::InjectedScriptHost::wrapper):

2016-07-15  Mark Lam  <mark.lam@apple.com>

        FunctionOverride's parseClause() needs to keep the CString instance in scope while its data is being used.
        https://bugs.webkit.org/show_bug.cgi?id=159828

        Reviewed by Saam Barati.

        Otherwise, we'll have a use after free.  This issue was caught when running an
        ASan debug build of testapi.

        * tools/FunctionOverrides.cpp:
        (JSC::parseClause):

2016-07-15  Keith Miller  <keith_miller@apple.com>

        %TypedArray%.prototype.indexOf is coercing non-integers or non-floats to numbers wrongly
        https://bugs.webkit.org/show_bug.cgi?id=159400

        Reviewed by Geoffrey Garen.

        This patch fixes coercion of non-numbers in indexOf/lastIndexOf.
        Additionally, this patch fixes an issue with includes where it
        would not check that the buffer remained non-neutered after
        calling the toInteger() function. Lastly, some extra release
        asserts have been added in some places to inform us of any issues
        in the future.

        Additionally, this patch changes bool toNativeFromDouble to
        Optional<Type> toNativeFromDoubleWithoutCoercion. This makes it a
        little clearer what the function does and also removes the return
        argument. The only behavior change is that the function no longer
        coerces non-numbers into numbers. That behavior was unused (maybe
        unintended), however.

        * runtime/JSGenericTypedArrayView.h:
        (JSC::JSGenericTypedArrayView::toAdaptorNativeFromValueWithoutCoercion):
        (JSC::JSGenericTypedArrayView::sort):
        (JSC::JSGenericTypedArrayView::toAdaptorNativeFromValue): Deleted.
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewProtoFuncCopyWithin):
        (JSC::genericTypedArrayViewProtoFuncIncludes):
        (JSC::genericTypedArrayViewProtoFuncIndexOf):
        (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
        * runtime/ToNativeFromValue.h:
        (JSC::toNativeFromValueWithoutCoercion):
        (JSC::toNativeFromValue): Deleted.
        * runtime/TypedArrayAdaptors.h:
        (JSC::IntegralTypedArrayAdaptor::toNativeFromInt32WithoutCoercion):
        (JSC::IntegralTypedArrayAdaptor::toNativeFromUint32WithoutCoercion):
        (JSC::IntegralTypedArrayAdaptor::toNativeFromDoubleWithoutCoercion):
        (JSC::FloatTypedArrayAdaptor::toNativeFromInt32WithoutCoercion):
        (JSC::FloatTypedArrayAdaptor::toNativeFromDoubleWithoutCoercion):
        (JSC::Uint8ClampedAdaptor::toNativeFromInt32WithoutCoercion):
        (JSC::Uint8ClampedAdaptor::toNativeFromDoubleWithoutCoercion):
        (JSC::IntegralTypedArrayAdaptor::toNativeFromInt32): Deleted.
        (JSC::IntegralTypedArrayAdaptor::toNativeFromUint32): Deleted.
        (JSC::IntegralTypedArrayAdaptor::toNativeFromDouble): Deleted.
        (JSC::FloatTypedArrayAdaptor::toNativeFromInt32): Deleted.
        (JSC::FloatTypedArrayAdaptor::toNativeFromDouble): Deleted.
        (JSC::Uint8ClampedAdaptor::toNativeFromInt32): Deleted.
        (JSC::Uint8ClampedAdaptor::toNativeFromDouble): Deleted.
        * tests/stress/resources/typedarray-test-helper-functions.js:
        * tests/stress/typedarray-functions-with-neutered.js:
        (callWithArgs):
        * tests/stress/typedarray-includes.js: Added.
        * tests/stress/typedarray-indexOf.js:
        * tests/stress/typedarray-lastIndexOf.js:

2016-07-15  Csaba Osztrogonác  <ossy@webkit.org>

        Add new functions to ARMAssembler after r202214
        https://bugs.webkit.org/show_bug.cgi?id=159713

        Reviewed by Saam Barati.

        * assembler/ARMAssembler.h:
        (JSC::ARMAssembler::fillNops):
        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::patchableBranch32):
        (JSC::MacroAssemblerARM::internalCompare32):

2016-07-15  Mark Lam  <mark.lam@apple.com>

        Stack overflow error for deeply nested classes.
        https://bugs.webkit.org/show_bug.cgi?id=157086

        Reviewed by Geoffrey Garen.

        Changed the StructureStubClearingWatchpoint destructor to iteratively destruct
        its chain of next StructureStubClearingWatchpoints instead of recursively doing
        so.

        The added deep-StructureStubClearingWatchpoint-destructor-recursion.js test
        produces a crash before the fix is applied, but takes about 14 minutes to run.
        Hence, it is skipped.

        * bytecode/StructureStubClearingWatchpoint.cpp:
        (JSC::StructureStubClearingWatchpoint::~StructureStubClearingWatchpoint):
        * tests/stress/deep-StructureStubClearingWatchpoint-destructor-recursion.js: Added.

2016-07-15  Csaba Osztrogonác  <ossy@webkit.org>

        Fix expectations in test262.yaml
        https://bugs.webkit.org/show_bug.cgi?id=159810

        Reviewed by Keith Miller.

        * tests/test262.yaml:

2016-07-15  Csaba Osztrogonác  <ossy@webkit.org>

        [ARM] Disable Inline Caching on ARMv7 traditional until proper fix
        https://bugs.webkit.org/show_bug.cgi?id=159759

        Reviewed by Saam Barati.

        * jit/Repatch.cpp:
        (JSC::forceICFailure):

2016-07-14  Keith Miller  <keith_miller@apple.com>

        Add Test262 test files and yaml

        Rubber Stamped by Benjamin Poulain.

        This patch adds all the test262 test files and the yaml that drives
        run-jsc-stress-tests.

        * tests/test262.yaml: Added. Yaml file to drive the test262 test suite with our driver.
        * tests/test262/LICENSE: Added. License for the test262 test suite.
        * tests/test262/harness/: Added. Harness directory for the test262 tests.
        * tests/test262/test/: Added. Directory with all the actual test files.

2016-07-14  Joseph Pecoraro  <pecoraro@apple.com>

        Return the correct value from Heap::externalMemorySize
        https://bugs.webkit.org/show_bug.cgi?id=159797
        <rdar://problem/27362446>

        Reviewed by Timothy Hatcher.

        * heap/Heap.h:
        (JSC::Heap::externalMemorySize):
        We should have been returning m_externalMemorySize which is a subset
        of m_extraMemorySize. In practice the difference can be small. A major
        difference in "extra memory size" may be from deprecated memory size
        and array buffer sizes.

2016-07-14  Saam Barati  <sbarati@apple.com>

        It should be a syntax error to have a 'use strict' directive inside a function that has a non-simple parameter list
        https://bugs.webkit.org/show_bug.cgi?id=159790
        <rdar://problem/27171636>

        Reviewed by Geoffrey Garen.

        Is is a syntax error for a function's parameter list to be non-simple
        and for the function to also contain a 'use strict' directive.

        See section 14.2.1 of the spec:
        https://tc39.github.io/ecma262/#sec-arrow-function-definitions-static-semantics-early-errors

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseSourceElements):
        (JSC::Parser<LexerType>::parseFormalParameters):
        * parser/Parser.h:
        (JSC::Scope::Scope):
        (JSC::Scope::strictMode):
        (JSC::Scope::isValidStrictMode):
        (JSC::Scope::shadowsArguments):
        (JSC::Scope::setHasNonSimpleParameterList):
        (JSC::Scope::hasNonSimpleParameterList):
        (JSC::Scope::copyCapturedVariablesToVector):

2016-07-14  Geoffrey Garen  <ggaren@apple.com>

        ASSERTION FAILED: : this != replacement()
        https://bugs.webkit.org/show_bug.cgi?id=159779

        Reviewed by Michael Saboff.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::jettison): If we jettison during GC, and our owner
        is dead, we choose not to replace ourselves. (See
        https://bugs.webkit.org/show_bug.cgi?id=159588.) So, it's possible to
        invalidate and still be our owner's CodeBlock. Relax our ASSERT to allow
        for this.

2016-07-14  Mark Lam  <mark.lam@apple.com>

        JSONObject Walker::walk must save array length before processing array elements.
        https://bugs.webkit.org/show_bug.cgi?id=153485

        Reviewed by Darin Adler and Michael Saboff.

        According to https://tc39.github.io/ecma262/#sec-internalizejsonproperty,
        JSON.parse() should cache the length of an array and use the cached length when
        iterating array elements (see section 24.3.1.1 2.b.iii).

        * runtime/JSONObject.cpp:
        (JSC::Walker::walk):
        * tests/stress/JSON-parse-should-cache-array-lengths.js: Added.
        (toString):
        (shouldBe):
        (test):
        (test2):

2016-07-14  Julien Brianceau  <jbriance@cisco.com>

        [mips] Handle properly unaligned halfword load
        https://bugs.webkit.org/show_bug.cgi?id=153226

        Reviewed by Michael Catanzaro.

        Waiting for the kernel to silently fix-up unaligned accesses is
        not efficient, so let's provide an implementation of load16Unaligned
        in mips macro assembler.

        Performance improvement seen with SunSpider's regexp-dna test.

        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::load16Unaligned):
        (JSC::MacroAssemblerMIPS::load32WithUnalignedHalfWords):

2016-07-14  Youenn Fablet  <youenn@apple.com>

        DOM value iterable interfaces should use Array prototype methods
        https://bugs.webkit.org/show_bug.cgi?id=159296

        Reviewed by Chris Dumez and Mark Lam.

        * JavaScriptCore.xcodeproj/project.pbxproj: Marking some header files as private so that they can be included in
        WebCore.
        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation): copying iterable methods (entries, forEach, keys and values) to private slots.

2016-07-13  Csaba Osztrogonác  <ossy@webkit.org>

        Fix the magic numbers for ARM traditional in InlineAccess.h
        https://bugs.webkit.org/show_bug.cgi?id=159708

        Reviewed by Saam Barati.

        * bytecode/InlineAccess.h:
        (JSC::InlineAccess::sizeForPropertyAccess):
        (JSC::InlineAccess::sizeForPropertyReplace):
        (JSC::InlineAccess::sizeForLengthAccess):

2016-07-13  Michael Saboff  <msaboff@apple.com>

        YARR uses mixture of int and unsigned values to index into subject string
        https://bugs.webkit.org/show_bug.cgi?id=159744

        Reviewed by Benjamin Poulain.

        In most cases, we refer to characters in subject strings using a negative index from the number of
        "checked" characters in a subject string.  The required length is compared against the actual length
        and then we use that required length as the checked amount.  For example, when matching the string of
        4 digits in the RegExp /abc \d{4}/, we know that need 8 characters in the subject string.  We refer
        to the digits part of the expression from an already checked index of 8 and use negative offsets of
        -4 through -1.  In many cases we used a signed int for the negative offsets.  There are other cases
        where we used unsigned values as the amount of negative offset to use when accessing subject characters.

        Changed all occurrances of character offsets to unsigned or Checked Arithmetic unsigned values.  Note
        that the pre-existing Checked class is used in other places to check for under/overflow with arithmetic
        operations.  Those unsigned offsets are always the number of characters before (negative) from the
        current checked character offset.  Also added some asserts for cases where arithmetic is not protected
        by other checks or with Checked<> wrapped values.

        In the case of the JIT, subject characters are accessed using base with scaled index and offset
        addressing.  The MacroAssembler provides this addressing using the BaseIndex struct.  The offset for
        this struct is a 32 bit signed quantity.  Since we only care about negative offsets, we really only
        have 31 bits.  Changed the generation of a BaseOffset address to handle the case when the offset and
        scaled combination will exceed the 31 bits of negative offset.  This is done by moving the base value
        into a temp register and biasing the temp base and offset to smaller values so that we can emit
        instructions that can reference characters without exceeding the 31 bits of negative offset.

        To abstract the character address generation, put the base with scaled index and offset into
        one function and used that function everywhere the YARR JIT wants to access subject characters.
        Also consilidated a few cases where we were generating inline what readCharacter() does.  Usually
        this was due to using a different index register.

        Added a new regression test.

        * tests/stress/regress-159744.js: Added regression test.
        (testRegExp):
        * yarr/YarrInterpreter.cpp:
        (JSC::Yarr::Interpreter::recordParenthesesMatch):
        (JSC::Yarr::Interpreter::resetMatches):
        (JSC::Yarr::Interpreter::matchParenthesesOnceEnd):
        (JSC::Yarr::Interpreter::backtrackParenthesesOnceEnd):
        (JSC::Yarr::ByteCompiler::closeBodyAlternative):
        (JSC::Yarr::ByteCompiler::atomParenthesesSubpatternEnd):
        (JSC::Yarr::ByteCompiler::atomParenthesesOnceEnd):
        (JSC::Yarr::ByteCompiler::atomParenthesesTerminalEnd):
        (JSC::Yarr::ByteCompiler::emitDisjunction):
        * yarr/YarrInterpreter.h:
        (JSC::Yarr::ByteTerm::ByteTerm):
        (JSC::Yarr::ByteTerm::BOL):
        (JSC::Yarr::ByteTerm::UncheckInput):
        (JSC::Yarr::ByteTerm::EOL):
        (JSC::Yarr::ByteTerm::WordBoundary):
        (JSC::Yarr::ByteTerm::BackReference):
        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::notAtEndOfInput):
        (JSC::Yarr::YarrGenerator::negativeOffsetIndexedAddress):
        (JSC::Yarr::YarrGenerator::readCharacter):
        (JSC::Yarr::YarrGenerator::jumpIfCharNotEquals):
        (JSC::Yarr::YarrGenerator::storeToFrame):
        (JSC::Yarr::YarrGenerator::generateAssertionBOL):
        (JSC::Yarr::YarrGenerator::backtrackAssertionBOL):
        (JSC::Yarr::YarrGenerator::generateAssertionEOL):
        (JSC::Yarr::YarrGenerator::matchAssertionWordchar):
        (JSC::Yarr::YarrGenerator::generateAssertionWordBoundary):
        (JSC::Yarr::YarrGenerator::generatePatternCharacterOnce):
        (JSC::Yarr::YarrGenerator::generatePatternCharacterFixed):
        (JSC::Yarr::YarrGenerator::generatePatternCharacterGreedy):
        (JSC::Yarr::YarrGenerator::backtrackPatternCharacterNonGreedy):
        (JSC::Yarr::YarrGenerator::generateCharacterClassOnce):
        (JSC::Yarr::YarrGenerator::generateCharacterClassFixed):
        (JSC::Yarr::YarrGenerator::generateCharacterClassGreedy):
        (JSC::Yarr::YarrGenerator::backtrackCharacterClassNonGreedy):
        (JSC::Yarr::YarrGenerator::generate):
        (JSC::Yarr::YarrGenerator::backtrack):
        (JSC::Yarr::YarrGenerator::YarrGenerator):
        * yarr/YarrPattern.h:
        (JSC::Yarr::PatternTerm::PatternTerm):

2016-07-13  Keith Miller  <keith_miller@apple.com>

        Crashes with detached ArrayBuffers
        https://bugs.webkit.org/show_bug.cgi?id=157088
        <rdar://problem/27327362>

        Reviewed by Filip Pizlo.

        TypedArray.prototype.fill was incorrect because it should perform
        ToNumber coercion each time it tries to store the
        object. Currently, we only perform the coercion once at the
        beginning of the loop. If we find that we need to improve the
        performance of this function, we can add a faster C++ path back
        that only handles the primitive case.

        This patch also moves the isNeutered() checks from put and
        putByIndex into setIndex. This fixes an issue where setIndex might
        store to a no longer valid offset.

        * builtins/TypedArrayPrototype.js:
        (globalPrivate.typedArrayClampArgumentToStartOrEnd):
        (fill):
        * runtime/JSGenericTypedArrayView.h:
        (JSC::JSGenericTypedArrayView::setIndexQuickly):
        (JSC::JSGenericTypedArrayView::setIndex):
        (JSC::JSGenericTypedArrayView::setRangeToValue): Deleted.
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::put): Deleted.
        (JSC::JSGenericTypedArrayView<Adaptor>::putByIndex): Deleted.
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewProtoFuncFill): Deleted.
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::JSTypedArrayViewPrototype::finishCreation):
        (JSC::typedArrayViewProtoFuncFill): Deleted.
        * tests/stress/typedarray-fill.js:
        * tests/stress/typedarray-functions-with-neutered.js:
        (defaultForArg):
        (test2):
        (checkArgumentsForType): Deleted.
        (checkArguments): Deleted.

2016-07-13  Michael Saboff  <msaboff@apple.com>

        Some bad unicode regex escapes aren't flagged as errors
        https://bugs.webkit.org/show_bug.cgi?id=158080

        Reviewed by Saam Barati.

        If we have a partial unicode escape, eg /\u{1/u or /\u12|abc/u, we
        didn't check for the closing '}' and processed the unicode escape with
        the hex value provided.  

        Added a check that we properly terminated a \u{} unicode escape.
        If we fail that check and there isn't a prior error, we record that we
        have an invalid unicode escape.  The next existing line in the code will
        terminate parsing and bubble up the error.

        * yarr/YarrParser.h:
        (JSC::Yarr::Parser::parseEscape):

2016-07-13  Chris Dumez  <cdumez@apple.com>

        Unreviewed, rolling out r203199.

        Broke the build

        Reverted changeset:

        "Crashes with detached ArrayBuffers"
        https://bugs.webkit.org/show_bug.cgi?id=157088
        http://trac.webkit.org/changeset/203199

2016-07-13  Keith Miller  <keith_miller@apple.com>

        Crashes with detached ArrayBuffers
        https://bugs.webkit.org/show_bug.cgi?id=157088
        <rdar://problem/27327362>

        Reviewed by Filip Pizlo.

        TypedArray.prototype.fill was incorrect because it should perform
        ToNumber coercion each time it tries to store the
        object. Currently, we only perform the coercion once at the
        beginning of the loop. If we find that we need to improve the
        performance of this function, we can add a faster C++ path back
        that only handles the primitive case.

        This patch also moves the isNeutered() checks from put and
        putByIndex into setIndex. This fixes an issue where setIndex might
        store to a no longer valid offset.

        * builtins/TypedArrayPrototype.js:
        (globalPrivate.typedArrayClampArgumentToStartOrEnd):
        (fill):
        * runtime/JSGenericTypedArrayView.h:
        (JSC::JSGenericTypedArrayView::setIndexQuickly):
        (JSC::JSGenericTypedArrayView::setIndex):
        (JSC::JSGenericTypedArrayView::setRangeToValue): Deleted.
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::put): Deleted.
        (JSC::JSGenericTypedArrayView<Adaptor>::putByIndex): Deleted.
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewProtoFuncFill): Deleted.
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::JSTypedArrayViewPrototype::finishCreation):
        (JSC::typedArrayViewProtoFuncFill): Deleted.
        * tests/stress/typedarray-fill.js:
        * tests/stress/typedarray-functions-with-neutered.js:
        (defaultForArg):
        (test2):
        (checkArgumentsForType): Deleted.
        (checkArguments): Deleted.

2016-07-13  Enrica Casucci  <enrica@apple.com>

        Update supported platforms in xcconfig files to match the sdk names.
        https://bugs.webkit.org/show_bug.cgi?id=159728

        Reviewed by Tim Horton.

        * Configurations/Base.xcconfig:

2016-07-13  Csaba Osztrogonác  <ossy@webkit.org>

        CLoop buildfix after r203142
        https://bugs.webkit.org/show_bug.cgi?id=159706

        Unreviewed buildfix.

        * interpreter/CLoopStack.cpp:
        (JSC::CLoopStack::isSafeToRecurse):
        * interpreter/CLoopStack.h:
        * interpreter/CLoopStackInlines.h:
        (JSC::CLoopStack::isSafeToRecurse): Deleted.

2016-07-12  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Array.prototype.join() fails some conformance tests
        https://bugs.webkit.org/show_bug.cgi?id=159657

        Reviewed by Saam Barati.

        There were a couple of failures:
        -separator.toString() was called *before* we get the length
         and process ToLength() on it.
        -We were using toUInt32() on length instead of ToLength(),
         failing on big integers and various negative numbers.

        Additionally, I replaced the "fast" ArrayStorage path
        by a fully generic implementation that does not depends on StringJoiner.

        The reason is StringJoiner was doing poorly on sparse objects
        in certain cases.
        If you have a sparse object with a length > INT_MAX but very few
        indices defined, and you join on the empty string, it should be possible
        to join the array (albeit very slowly). With StringJoiner, we fail
        because we try to allocate > INT_MAX empty strings in a contiguous vector.

        * runtime/ArrayPrototype.cpp:
        (JSC::slowJoin):
        (JSC::canUseFastJoin):
        (JSC::fastJoin):
        (JSC::arrayProtoFuncJoin):
        (JSC::join): Deleted.
        * runtime/JSArray.h:
        (JSC::toLength):

2016-07-12  Mark Lam  <mark.lam@apple.com>

        Gardening: C Loop build fix after r203142.

        Not reviewed.

        * interpreter/CLoopStackInlines.h:
        (JSC::CLoopStack::isSafeToRecurse):

2016-07-12  Commit Queue  <commit-queue@webkit.org>

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

        This change caused an existing LayoutTest to time out on debug
        testers (Requested by ryanhaddad on #webkit).

        Reverted changeset:

        "[JSC] Array.prototype.join() fails some conformance tests"
        https://bugs.webkit.org/show_bug.cgi?id=159657
        http://trac.webkit.org/changeset/203131

2016-07-12  Mark Lam  <mark.lam@apple.com>

        We should use different stack limits for stack checks from JS and host code.
        https://bugs.webkit.org/show_bug.cgi?id=159442
        <rdar://problem/26889188>

        Reviewed by Geoffrey Garen.

        We have 2 stack reservedZoneSizes:
        1. Options::softReservedZoneSize()
        2. Options::reservedZoneSize()

        Respectively, there are used to define 2 stack limits based on these reserved
        zone sizes:
        1. VM::m_softStackLimit
        2. VM::m_stackLimit

        Options::reservedZoneSize() is the amount of the stack space that JSC guarantees
        to the VM and client host code for it's use.  Host code that has well known
        stack usage characteristics (i.e. doesn't call arbitrary code) may do stack
        checks against the VM::m_stackLimit limit (which is computed using
        Options::reservedZoneSize()).

        Options::softReservedZoneSize() is a more conservative amount of reserved stack
        space.  This is used to compute the VM::m_softStackLimit limit.  Any code that
        is difficult to have its stack usage characterized (i.e. may call arbitrary code)
        may need more stack space for its work.  Hence, these should do stack checks
        against the VM::m_softStackLimit limit.

        JS code and host code that may call into JS code falls into the category of code
        that may call arbitrary code.  Hence, they should do stack checks against the
        VM::m_softStackLimit limit.

        Accordingly, the VM now provides 2 recursion check functions:

        1. VM::isSafeToRecurseSoft() will do a stack check against VM::m_softStackLimit.
           In addition, for C Loop builds, VM::isSafeToRecurseSoft() will also
           check the CLoopStack against VM::m_cloopStackLimit.

        2. VM::isSafeToRecurse() will do a stack check against VM::m_stackLimit.

        Also added a promise-infinite-recursion-should-not-crash.js test.

        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::emitNodeInTailPosition):
        (JSC::BytecodeGenerator::emitNodeInConditionContext):
        * interpreter/CLoopStack.cpp:
        (JSC::CLoopStack::grow):
        * interpreter/CLoopStack.h:
        (JSC::CLoopStack::size):
        * interpreter/CLoopStackInlines.h:
        (JSC::CLoopStack::ensureCapacityFor):
        (JSC::CLoopStack::isSafeToRecurse):
        (JSC::CLoopStack::topOfFrameFor):
        * interpreter/CachedCall.h:
        (JSC::CachedCall::CachedCall):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * parser/Parser.cpp:
        * runtime/Options.h:
        * runtime/ProxyObject.cpp:
        (JSC::performProxyGet):
        (JSC::ProxyObject::performInternalMethodGetOwnProperty):
        (JSC::ProxyObject::performHasProperty):
        (JSC::ProxyObject::getOwnPropertySlotCommon):
        (JSC::ProxyObject::performPut):
        (JSC::performProxyCall):
        (JSC::performProxyConstruct):
        (JSC::ProxyObject::performDelete):
        (JSC::ProxyObject::performPreventExtensions):
        (JSC::ProxyObject::performIsExtensible):
        (JSC::ProxyObject::performDefineOwnProperty):
        (JSC::ProxyObject::performGetOwnPropertyNames):
        (JSC::ProxyObject::performSetPrototype):
        (JSC::ProxyObject::performGetPrototype):
        * runtime/RegExp.cpp:
        (JSC::RegExp::finishCreation):
        (JSC::RegExp::compile):
        (JSC::RegExp::compileMatchOnly):
        * runtime/StringRecursionChecker.h:
        (JSC::StringRecursionChecker::performCheck):
        * runtime/VM.cpp:
        (JSC::VM::setStackPointerAtVMEntry):
        (JSC::VM::updateSoftReservedZoneSize):
        (JSC::preCommitStackMemory):
        (JSC::VM::updateStackLimits):
        (JSC::VM::updateStackLimit): Deleted.
        * runtime/VM.h:
        (JSC::VM::stackLimit):
        (JSC::VM::softStackLimit):
        (JSC::VM::addressOfSoftStackLimit):
        (JSC::VM::setCLoopStackLimit):
        (JSC::VM::isSafeToRecurse):
        (JSC::VM::lastStackTop):
        (JSC::VM::setException):
        * runtime/VMInlines.h:
        (JSC::VM::ensureStackCapacityFor):
        (JSC::VM::isSafeToRecurseSoft):
        (JSC::VM::shouldTriggerTermination):
        * tests/stress/promise-infinite-recursion-should-not-crash.js: Added.
        (testPromise):
        (promiseFunc):
        * yarr/YarrPattern.cpp:

2016-07-12  Per Arne Vollan  <pvollan@apple.com>

        [Win] Fix for build error when trying to version stamp dll.
        https://bugs.webkit.org/show_bug.cgi?id=159692

        Reviewed by Brent Fulgham.

        Use correct path to version stamp script.

        * CMakeLists.txt:

2016-07-12  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Array.prototype.join() fails some conformance tests
        https://bugs.webkit.org/show_bug.cgi?id=159657

        Reviewed by Saam Barati.

        There were a couple of failures:
        -separator.toString() was called *before* we get the length
         and process ToLength() on it.
        -We were using toUInt32() on length instead of ToLength(),
         failing on big integers and various negative numbers.

        Additionally, I replaced the "fast" ArrayStorage path
        by a fully generic implementation that does not depends on StringJoiner.

        The reason is StringJoiner was doing poorly on sparse objects
        in certain cases.
        If you have a sparse object with a length > INT_MAX but very few
        indices defined, and you join on the empty string, it should be possible
        to join the array (albeit very slowly). With StringJoiner, we fail
        because we try to allocate > INT_MAX empty strings in a contiguous vector.

        * runtime/ArrayPrototype.cpp:
        (JSC::slowJoin):
        (JSC::canUseFastJoin):
        (JSC::fastJoin):
        (JSC::arrayProtoFuncJoin):
        (JSC::join): Deleted.
        * runtime/JSArray.h:
        (JSC::toLength):

2016-07-12  Mark Lam  <mark.lam@apple.com>

        More stack limit and reserved zone renaming.
        https://bugs.webkit.org/show_bug.cgi?id=159690

        Rubber-stamped by Geoffrey Garen.

        We should rename the following:
            osStackLimitWithReserve => softStackLimit
            reservedZoneSize => softReservedZoneSize
            errorModeReservedZoneSize => reservedZoneSize

        * API/tests/PingPongStackOverflowTest.cpp:
        (testPingPongStackOverflow):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::lower):
        * interpreter/CLoopStack.cpp:
        (JSC::CLoopStack::CLoopStack):
        (JSC::CLoopStack::grow):
        (JSC::CLoopStack::releaseExcessCapacity):
        (JSC::CLoopStack::addToCommittedByteCount):
        (JSC::CLoopStack::setSoftReservedZoneSize):
        (JSC::CLoopStack::setReservedZoneSize): Deleted.
        * interpreter/CLoopStack.h:
        (JSC::CLoopStack::size):
        * interpreter/CLoopStackInlines.h:
        (JSC::CLoopStack::shrink):
        * jit/JIT.cpp:
        (JSC::JIT::compileWithoutLinking):
        * jit/SetupVarargsFrame.cpp:
        (JSC::emitSetupVarargsFrameFastCase):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/ErrorHandlingScope.cpp:
        (JSC::ErrorHandlingScope::ErrorHandlingScope):
        (JSC::ErrorHandlingScope::~ErrorHandlingScope):
        * runtime/ErrorHandlingScope.h:
        * runtime/Options.h:
        * runtime/RegExp.cpp:
        (JSC::RegExp::finishCreation):
        (JSC::RegExp::compile):
        (JSC::RegExp::compileMatchOnly):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::setStackPointerAtVMEntry):
        (JSC::VM::updateSoftReservedZoneSize):
        (JSC::VM::updateStackLimit):
        (JSC::VM::updateReservedZoneSize): Deleted.
        * runtime/VM.h:
        (JSC::VM::stackPointerAtVMEntry):
        (JSC::VM::softReservedZoneSize):
        (JSC::VM::softStackLimit):
        (JSC::VM::addressOfSoftStackLimit):
        (JSC::VM::cloopStackLimit):
        (JSC::VM::setCLoopStackLimit):
        (JSC::VM::isSafeToRecurse):
        (JSC::VM::reservedZoneSize): Deleted.
        (JSC::VM::osStackLimitWithReserve): Deleted.
        (JSC::VM::addressOfOSStackLimitWithReserve): Deleted.
        * runtime/VMInlines.h:
        (JSC::VM::ensureStackCapacityFor):
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::startFunction):

2016-07-12  Gyuyoung Kim  <gyuyoung.kim@webkit.org>

        Remove ENABLE_CSS3_TEXT_LINE_BREAK flag
        https://bugs.webkit.org/show_bug.cgi?id=159671

        Reviewed by Csaba Osztrogonác.

        ENABLE_CSS3_TEXT_LINE_BREAK feature was implemented without guards.
        https://bugs.webkit.org/show_bug.cgi?id=89235

        So this guard can be removed in build scripts.

        * Configurations/FeatureDefines.xcconfig:

2016-07-12  Per Arne Vollan  <pvollan@apple.com>

        [Win] DLLs are missing version information.
        https://bugs.webkit.org/show_bug.cgi?id=159349

        Reviewed by Brent Fulgham.

        Generate autoversion.h and run perl version stamp utility.

        * CMakeLists.txt:

2016-07-11  Caio Lima  <ticaiolima@gmail.com>

        ECMAScript 2016: %TypedArray%.prototype.includes implementation
        https://bugs.webkit.org/show_bug.cgi?id=159385

        Reviewed by Benjamin Poulain.

        This patch implements the ECMAScript 2016:
        %TypedArray%.prototype.includes
        following spec 22.2.3.14
        https://tc39.github.io/ecma262/2016/#sec-%typedarray%.prototype.includes

        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewProtoFuncIncludes):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::typedArrayViewProtoFuncIncludes):
        (JSC::JSTypedArrayViewPrototype::finishCreation):

2016-07-11  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Array.from() and Array.of() try to build objects even if "this" is not a constructor
        https://bugs.webkit.org/show_bug.cgi?id=159604

        Reviewed by Yusuke Suzuki.

        The spec says IsConstructor(), we were just checking if "this"
        is any function.

        * builtins/ArrayConstructor.js:
        (of):
        (from):

2016-07-11  Keith Miller  <keith_miller@apple.com>

        defineProperty on a index of a TypedArray should throw if configurable
        https://bugs.webkit.org/show_bug.cgi?id=159653

        Reviewed by Saam Barati.

        When I fixed this before I misread the spec and thought it said we
        should throw if the descriptor said the proprety is not
        configurable. This is the opposite. We should throw if the
        descriptor says the property is configurable.

        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
        * tests/stress/typedarray-access-monomorphic-neutered.js:
        * tests/stress/typedarray-access-neutered.js:
        * tests/stress/typedarray-configure-index.js: Added.
        (assert):
        (assertThrows):
        (makeDescriptor):
        (test):

2016-07-11  Saam Barati  <sbarati@apple.com>

        some paths in Array.prototype.splice don't account for the array not having certain indexed properties
        https://bugs.webkit.org/show_bug.cgi?id=159641
        <rdar://problem/27171999>

        Reviewed by Filip Pizlo and Keith Miller.

        Array.prototype.splice was incorrectly putting properties on
        the result array even if the |this| array didn't have those
        properties. This is not the behavior of the spec. However, this
        could also cause a crash because we can construct a program where
        we would putByIndex on a typed array where the value we are
        putting is JSValue(). This is bad because the typed array will
        try to convert JSValue() into an integer.

        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncSplice):
        * tests/stress/array-prototype-splice-making-typed-array.js: Added.
        (assert):
        (test):

2016-07-11  Mark Lam  <mark.lam@apple.com>

        Refactor JSStack to only be the stack data structure for the C Loop.
        https://bugs.webkit.org/show_bug.cgi?id=159545

        Reviewed by Geoffrey Garen.

        Changes made:
        1. Renamed JSStack to CLoopStack.
        2. Made all of CLoopStack code to conditional on #if !ENABLE(JIT) i.e. they will
           only be in effect for the C Loop build.
        3. Changed clients of JSStack to use new equivalent VM APIs:
            a. JSStack::ensureCapacityFor() => VM::ensureStackCapacityFor()
            b. JSStack::committedByteCount() => VM::committedStackByteCount()
        4. Made VM::updateReservedZoneSize() call CLoopStack::setReservedZoneSize()
           instead of calling it from all the clients of VM::updateReservedZoneSize().
        5. Removed all unnecessary references to JSStack.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/MaxFrameExtentForSlowPathCall.h:
        * bytecode/BytecodeConventions.h:
        * dfg/DFGGraph.h:
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):
        * ftl/FTLOSREntry.cpp:
        (JSC::FTL::prepareOSREntry):
        * heap/Heap.cpp:
        (JSC::Heap::finalizeUnconditionalFinalizers):
        (JSC::Heap::willStartIterating):
        (JSC::Heap::gatherJSStackRoots):
        (JSC::Heap::stack): Deleted.
        * heap/Heap.h:
        * interpreter/CLoopStack.cpp: Copied from Source/JavaScriptCore/interpreter/JSStack.cpp.
        (JSC::commitSize):
        (JSC::CLoopStack::CLoopStack):
        (JSC::CLoopStack::~CLoopStack):
        (JSC::CLoopStack::grow):
        (JSC::CLoopStack::gatherConservativeRoots):
        (JSC::CLoopStack::sanitizeStack):
        (JSC::CLoopStack::releaseExcessCapacity):
        (JSC::CLoopStack::addToCommittedByteCount):
        (JSC::CLoopStack::setReservedZoneSize):
        (JSC::CLoopStack::committedByteCount):
        (JSC::JSStack::JSStack): Deleted.
        (JSC::JSStack::~JSStack): Deleted.
        (JSC::JSStack::growSlowCase): Deleted.
        (JSC::JSStack::gatherConservativeRoots): Deleted.
        (JSC::JSStack::sanitizeStack): Deleted.
        (JSC::JSStack::releaseExcessCapacity): Deleted.
        (JSC::JSStack::addToCommittedByteCount): Deleted.
        (JSC::JSStack::setReservedZoneSize): Deleted.
        (JSC::JSStack::lowAddress): Deleted.
        (JSC::JSStack::highAddress): Deleted.
        (JSC::JSStack::committedByteCount): Deleted.
        * interpreter/CLoopStack.h: Copied from Source/JavaScriptCore/interpreter/JSStack.h.
        (JSC::CLoopStack::containsAddress):
        (JSC::CLoopStack::lowAddress):
        (JSC::CLoopStack::highAddress):
        (JSC::CLoopStack::reservationTop):
        (JSC::JSStack::containsAddress): Deleted.
        (JSC::JSStack::lowAddress): Deleted.
        (JSC::JSStack::highAddress): Deleted.
        (JSC::JSStack::reservationTop): Deleted.
        * interpreter/CLoopStackInlines.h: Copied from Source/JavaScriptCore/interpreter/JSStackInlines.h.
        (JSC::CLoopStack::ensureCapacityFor):
        (JSC::CLoopStack::topOfFrameFor):
        (JSC::CLoopStack::topOfStack):
        (JSC::CLoopStack::shrink):
        (JSC::CLoopStack::setCLoopStackLimit):
        (JSC::JSStack::ensureCapacityFor): Deleted.
        (JSC::JSStack::topOfFrameFor): Deleted.
        (JSC::JSStack::topOfStack): Deleted.
        (JSC::JSStack::shrink): Deleted.
        (JSC::JSStack::grow): Deleted.
        (JSC::JSStack::setCLoopStackLimit): Deleted.
        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::unsafeCallSiteIndex):
        (JSC::CallFrame::currentVPC):
        (JSC::CallFrame::stack): Deleted.
        * interpreter/CallFrame.h:
        (JSC::ExecState::callerFrameAndPC):
        (JSC::ExecState::unsafeCallerFrameAndPC):
        * interpreter/Interpreter.cpp:
        (JSC::sizeOfVarargs):
        (JSC::sizeFrameForForwardArguments):
        (JSC::sizeFrameForVarargs):
        (JSC::Interpreter::Interpreter):
        * interpreter/Interpreter.h:
        (JSC::Interpreter::cloopStack):
        (JSC::Interpreter::getOpcode):
        (JSC::Interpreter::isCallBytecode):
        (JSC::Interpreter::stack): Deleted.
        * interpreter/JSStack.cpp: Removed.
        * interpreter/JSStack.h: Removed.
        * interpreter/JSStackInlines.h: Removed.
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::dump):
        * jit/JIT.h:
        * jit/JITOperations.cpp:
        * jit/JSInterfaceJIT.h:
        * jit/SpecializedThunkJIT.h:
        * jit/ThunkGenerators.cpp:
        * llint/LLIntOffsetsExtractor.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (JSC::LLInt::llint_stack_check_at_vm_entry):
        * llint/LLIntThunks.cpp:
        * llint/LowLevelInterpreter.cpp:
        (JSC::CLoop::execute):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::arityCheckFor):
        * runtime/ErrorHandlingScope.cpp:
        (JSC::ErrorHandlingScope::ErrorHandlingScope):
        (JSC::ErrorHandlingScope::~ErrorHandlingScope):
        * runtime/JSGlobalObject.h:
        * runtime/MemoryStatistics.cpp:
        (JSC::globalMemoryStatistics):
        * runtime/StackAlignment.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::updateReservedZoneSize):
        (JSC::sanitizeStackForVM):
        (JSC::VM::committedStackByteCount):
        * runtime/VM.h:
        (JSC::VM::reservedZoneSize):
        (JSC::VM::osStackLimitWithReserve):
        (JSC::VM::addressOfOSStackLimitWithReserve):
        * runtime/VMInlines.h:
        (JSC::VM::ensureStackCapacityFor):
        (JSC::VM::shouldTriggerTermination):

2016-07-11  Keith Miller  <keith_miller@apple.com>

        STP TypedArray.subarray 5x slowdown compared to 9.1
        https://bugs.webkit.org/show_bug.cgi?id=156404
        <rdar://problem/26493032>

        Reviewed by Geoffrey Garen.

        This patch moves the species constructor work for
        %TypedArray%.prototype.subarray to a js wrapper. By moving the
        species constructor work to JS we are able to completely optimize
        it out in DFG. The actual work of creating a TypedArray is still
        done in C++ since we are able to avoid calling into the
        constructor, which is expensive. This patch also changes the error
        message when a %TypedArray%.prototype function is passed a non-typed
        array this value. Finally, we used to check that the this value
        had not been detached, however, this behavior was incorrect.

        * builtins/BuiltinNames.h:
        * builtins/TypedArrayPrototype.js:
        (globalPrivate.typedArraySpeciesConstructor):
        (subarray):
        * runtime/ConstructData.cpp:
        (JSC::construct):
        * runtime/ConstructData.h:
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
        (JSC::genericTypedArrayViewProtoFuncSubarray): Deleted.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::typedArrayViewPrivateFuncLength):
        (JSC::typedArrayViewPrivateFuncSubarrayCreate):
        (JSC::JSTypedArrayViewPrototype::finishCreation):
        (JSC::typedArrayViewProtoFuncSubarray): Deleted.
        * runtime/JSTypedArrayViewPrototype.h:

2016-07-11  Yusuke Suzuki  <utatane.tea@gmail.com>

        REGRESSION(r202992): JSC varargs tests are broken
        https://bugs.webkit.org/show_bug.cgi?id=159616

        Reviewed by Csaba Osztrogonác.

        The substitution miss in r202992 causes varargs tests failures in GTK port.

        * jit/SetupVarargsFrame.cpp:
        (JSC::emitSetupVarargsFrameFastCase):

2016-07-10  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Promise.{all,race} no longer use @@species
        https://bugs.webkit.org/show_bug.cgi?id=159615

        Reviewed by Keith Miller.

        As per the latest ES draft, Promise.{all,race} no longer use @@species.
        So, this patch drops FIXMEs.

        * builtins/PromiseConstructor.js:
        (all):
        (race):
        * tests/stress/ignore-promise-species.js: Added.
        (shouldBe):
        (DerivedPromise.prototype.get Symbol):
        (DerivedPromise):

2016-07-10  Commit Queue  <commit-queue@webkit.org>

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

        The JSC tests are breaking in elcapitan-debug-tests-jsc and
        elcapitan-release-tests-jsc (Requested by caiolima on
        #webkit).

        Reverted changeset:

        "ECMAScript 2016: %TypedArray%.prototype.includes
        implementation"
        https://bugs.webkit.org/show_bug.cgi?id=159385
        http://trac.webkit.org/changeset/203037

2016-07-10  Caio Lima  <ticaiolima@gmail.com>

        ECMAScript 2016: %TypedArray%.prototype.includes implementation
        https://bugs.webkit.org/show_bug.cgi?id=159385

        Reviewed by Benjamin Poulain.

        This patch implements the ECMAScript 2016:
        %TypedArray%.prototype.includes
        following spec 22.2.3.14
        https://tc39.github.io/ecma262/2016/#sec-%typedarray%.prototype.includes

        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewProtoFuncIncludes):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::typedArrayViewProtoFuncIncludes):
        (JSC::JSTypedArrayViewPrototype::finishCreation):

2016-07-09  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION(201900): validation failure for GetByOffset/PutByOffset in VALIDATE((node), node->child1().node() == node->child2().node() || node->child1()->result() == NodeResultStorage)
        https://bugs.webkit.org/show_bug.cgi?id=159603

        Reviewed by Keith Miller.
        
        This removes an incorrect validation rule and replaces it with a FIXME about how to make this
        aspect of IR easier to validate soundly.
        
        It's not valid to assert that two children of a node are the same. It should always be valid
        to take:
        
        Foo(@x, @x)
        
        and turn it into:
        
        a: ValueRep(@x)
        b: ValueRep(@x)
        Foo(@a, @b)
        
        or even something like:
        
        y: Identity(@y)
        Foo(@x, @y)
        
        That's because it should be possible to rewire any data flow edge something that produces an
        equivalent value.
        
        The validation rule that this patch removes meant that such rewirings were invalid on
        GetByOffset/PutByOffset. FixupPhase did such a rewiring sometimes.

        * dfg/DFGValidate.cpp:
        * tests/stress/get-by-offset-double.js: Added.

2016-07-09  Keith Miller  <keith_miller@apple.com>

        appendMemcpy might fail in concatAppendOne
        https://bugs.webkit.org/show_bug.cgi?id=159601
        <rdar://problem/27211300>

        Reviewed by Mark Lam.

        There are multiple reasons why we might fail appendMemcpy. One
        reason, which I suspect was the source of the crashes, is that one
        of the Array prototypes has an indexed property. This patch
        consolidates the two old cases by just creating an array then
        attempting to memcpy append. If that fails, we fall back to
        moveElements.

        * runtime/ArrayPrototype.cpp:
        (JSC::concatAppendOne):
        * tests/stress/concat-with-holesMustForwardToPrototype.js: Added.
        (arrayEq):

2016-07-09  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Fix the Template Raw Value of \ (escape) + LineTerminatorSequence
        https://bugs.webkit.org/show_bug.cgi?id=159595

        Reviewed by Yusuke Suzuki.

        The spec (https://tc39.github.io/ecma262/#sec-static-semantics-tv-and-trv)
        says:
        "The TRV of LineContinuation::\LineTerminatorSequence is the sequence
         consisting of the code unit value 0x005C followed by the code units
         of TRV of LineTerminatorSequence."
        
        We were not normalizing the LineTerminatorSequence in that case, but it should
        be as it is the TRV of LineTerminatorSequence.

        * parser/Lexer.cpp:
        (JSC::Lexer<T>::parseTemplateLiteral):
        * tests/stress/tagged-templates-raw-strings.js:

2016-07-08  Saam Barati  <sbarati@apple.com>

        We may add a ReadOnly property without setting the corresponding bit on Structure
        https://bugs.webkit.org/show_bug.cgi?id=159542
        <rdar://problem/27084591>

        Reviewed by Benjamin Poulain.

        The reason this usually is OK is due to happenstance. Often, instances that putDirectWithoutTransition
        also happen to have a static property table. Having a static property table causes the
        HasReadOnlyOrGetterSetterPropertiesExcludingProto on the structure to be set. However, 
        there are times where an object calls putDirectWithoutTransition, and it doesn't have a
        static property hash table. The fix is simple, putDirectWithTransition needs to set the
        HasReadOnlyOrGetterSetterPropertiesExcludingProto if it puts a ReadOnly property.

        * runtime/JSObject.h:
        (JSC::JSObject::putDirectWithoutTransition):
        * tests/stress/proper-property-store-with-prototype-property-that-is-not-writable.js: Added.
        (assert):

2016-07-08  Michael Saboff  <msaboff@apple.com>

        ASSERTION FAILED: Heap::isMarked(cell) in SlotVisitor::appendToMarkStack(JSC::JSCell *)
        https://bugs.webkit.org/show_bug.cgi?id=159588

        Reviewed by Geoffrey Garen.

        We were jettisoning a CodeBlock during GC that won't survive and its owning script
        won't survive either.  We can't install any code on the owning script as that involves
        a write barrier that will "pull" the script back into the remembered set.  Badness would
        ensue.  Added an early return in CodeBlock::jettison() when we are garbage collecting
        and the owning script isn't marked.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::jettison):

2016-07-08  Mark Lam  <mark.lam@apple.com>

        Move CallFrame header info from JSStack.h to CallFrame.h
        https://bugs.webkit.org/show_bug.cgi?id=159549

        Reviewed by Geoffrey Garen.

        CallFrame.h is a much better location for CallFrame header info.

        Replaced CallFrame::init() with ExecState::initGlobalExec() because normal
        CallFrames are setup by a different mechanism now.  Only the globalExec is still
        using it.  So, might as well change it to be specifically for the globalExec.

        Removed the use of JSStack::containsAddress() in ExecState::initGlobalExec()
        because it is not relevant to the globalExec.

        Also removed some unused code: JSStack::gatherConservativeRoots() and
        JSStack::sanitizeStack() is never called for JIT builds.

        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generateImpl):
        * bytecode/VirtualRegister.h:
        (JSC::VirtualRegister::isValid):
        (JSC::VirtualRegister::isLocal):
        (JSC::VirtualRegister::isArgument):
        (JSC::VirtualRegister::isHeader):
        (JSC::VirtualRegister::isConstant):
        (JSC::VirtualRegister::toLocal):
        (JSC::VirtualRegister::toArgument):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitCall):
        (JSC::BytecodeGenerator::emitConstruct):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::CallArguments::thisRegister):
        (JSC::CallArguments::argumentRegister):
        (JSC::CallArguments::stackOffset):
        (JSC::CallArguments::argumentCountIncludingThis):
        (JSC::CallArguments::argumentsNode):
        (JSC::BytecodeGenerator::registerFor):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::emitHomeObjectForCallee):
        (JSC::emitGetSuperFunctionForConstruct):
        (JSC::CallArguments::CallArguments):
        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGArgumentsUtilities.cpp:
        (JSC::DFG::argumentsInvolveStackSlot):
        (JSC::DFG::emitCodeToGetArgumentsArrayLength):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::get):
        (JSC::DFG::ByteCodeParser::findArgumentPositionForLocal):
        (JSC::DFG::ByteCodeParser::flush):
        (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
        (JSC::DFG::ByteCodeParser::getArgumentCount):
        (JSC::DFG::ByteCodeParser::inlineCall):
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::handleGetById):
        (JSC::DFG::ByteCodeParser::handlePutById):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::isLiveInBytecode):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compileEntry):
        (JSC::DFG::JITCompiler::compileSetupRegistersForEntry):
        (JSC::DFG::JITCompiler::compileFunction):
        * dfg/DFGJITCompiler.h:
        (JSC::DFG::JITCompiler::emitStoreCallSiteIndex):
        * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
        (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):
        * dfg/DFGOSRExitCompiler.cpp:
        (JSC::DFG::OSRExitCompiler::emitRestoreArguments):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::reifyInlinedCallFrames):
        * dfg/DFGOSRExitCompilerCommon.h:
        (JSC::DFG::adjustFrameAndStackInOSRExitCompilerThunk):
        * dfg/DFGPreciseLocalClobberize.h:
        (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitGetLength):
        (JSC::DFG::SpeculativeJIT::emitGetCallee):
        (JSC::DFG::SpeculativeJIT::emitGetArgumentStart):
        (JSC::DFG::SpeculativeJIT::compileCreateDirectArguments):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStackLayoutPhase.cpp:
        (JSC::DFG::StackLayoutPhase::run):
        * dfg/DFGThunks.cpp:
        (JSC::DFG::osrEntryThunkGenerator):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::lower):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetMyArgumentByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetCallee):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetArgumentCountIncludingThis):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetScope):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct):
        (JSC::FTL::DFG::LowerDFGToB3::compileTailCall):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
        (JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenPrologue):
        (JSC::FTL::DFG::LowerDFGToB3::getArgumentsLength):
        (JSC::FTL::DFG::LowerDFGToB3::getCurrentCallee):
        (JSC::FTL::DFG::LowerDFGToB3::getArgumentsStart):
        (JSC::FTL::DFG::LowerDFGToB3::callPreflight):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        * ftl/FTLSlowPathCall.h:
        (JSC::FTL::callOperation):
        * interpreter/CallFrame.cpp:
        (JSC::ExecState::initGlobalExec):
        (JSC::CallFrame::callSiteBitsAreBytecodeOffset):
        (JSC::CallFrame::callSiteAsRawBits):
        (JSC::CallFrame::unsafeCallSiteAsRawBits):
        (JSC::CallFrame::callSiteIndex):
        (JSC::CallFrame::setCurrentVPC):
        (JSC::CallFrame::callSiteBitsAsBytecodeOffset):
        * interpreter/CallFrame.h:
        (JSC::CallSiteIndex::CallSiteIndex):
        (JSC::ExecState::calleeAsValue):
        (JSC::ExecState::callee):
        (JSC::ExecState::unsafeCallee):
        (JSC::ExecState::codeBlock):
        (JSC::ExecState::unsafeCodeBlock):
        (JSC::ExecState::scope):
        (JSC::ExecState::setCallerFrame):
        (JSC::ExecState::setScope):
        (JSC::ExecState::argumentCount):
        (JSC::ExecState::argumentCountIncludingThis):
        (JSC::ExecState::argumentOffset):
        (JSC::ExecState::argumentOffsetIncludingThis):
        (JSC::ExecState::offsetFor):
        (JSC::ExecState::noCaller):
        (JSC::ExecState::setArgumentCountIncludingThis):
        (JSC::ExecState::setCallee):
        (JSC::ExecState::setCodeBlock):
        (JSC::ExecState::setReturnPC):
        (JSC::ExecState::argIndexForRegister):
        (JSC::ExecState::callerFrameAndPC):
        (JSC::ExecState::unsafeCallerFrameAndPC):
        (JSC::ExecState::init): Deleted.
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::dumpRegisters):
        * interpreter/Interpreter.h:
        (JSC::calleeFrameForVarargs):
        * interpreter/JSStack.h:
        (JSC::JSStack::containsAddress):
        (JSC::JSStack::gatherConservativeRoots): Deleted.
        (JSC::JSStack::sanitizeStack): Deleted.
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::jitAssertArgumentCountSane):
        (JSC::AssemblyHelpers::emitRandomThunk):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::restoreReturnAddressBeforeReturn):
        (JSC::AssemblyHelpers::emitGetFromCallFrameHeaderPtr):
        (JSC::AssemblyHelpers::emitGetFromCallFrameHeader32):
        (JSC::AssemblyHelpers::emitGetFromCallFrameHeader64):
        (JSC::AssemblyHelpers::emitPutToCallFrameHeader):
        (JSC::AssemblyHelpers::emitPutToCallFrameHeaderBeforePrologue):
        (JSC::AssemblyHelpers::emitPutPayloadToCallFrameHeaderBeforePrologue):
        (JSC::AssemblyHelpers::emitPutTagToCallFrameHeaderBeforePrologue):
        (JSC::AssemblyHelpers::calleeFrameSlot):
        * jit/CCallHelpers.cpp:
        (JSC::CCallHelpers::logShadowChickenProloguePacket):
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::prepareForTailCallSlow):
        * jit/CallFrameShuffler.cpp:
        (JSC::CallFrameShuffler::CallFrameShuffler):
        (JSC::CallFrameShuffler::dump):
        (JSC::CallFrameShuffler::extendFrameIfNeeded):
        (JSC::CallFrameShuffler::prepareForSlowPath):
        (JSC::CallFrameShuffler::prepareForTailCall):
        (JSC::CallFrameShuffler::prepareAny):
        * jit/CallFrameShuffler.h:
        (JSC::CallFrameShuffler::snapshot):
        (JSC::CallFrameShuffler::setCalleeJSValueRegs):
        (JSC::CallFrameShuffler::assumeCalleeIsCell):
        (JSC::CallFrameShuffler::numLocals):
        (JSC::CallFrameShuffler::getOld):
        (JSC::CallFrameShuffler::setOld):
        (JSC::CallFrameShuffler::firstOld):
        (JSC::CallFrameShuffler::lastOld):
        (JSC::CallFrameShuffler::isValidOld):
        (JSC::CallFrameShuffler::argCount):
        (JSC::CallFrameShuffler::getNew):
        * jit/JIT.cpp:
        (JSC::JIT::compileWithoutLinking):
        * jit/JIT.h:
        * jit/JITCall.cpp:
        (JSC::JIT::compileSetupVarargsFrame):
        (JSC::JIT::compileCallEvalSlowCase):
        (JSC::JIT::compileOpCall):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::compileSetupVarargsFrame):
        (JSC::JIT::compileCallEvalSlowCase):
        (JSC::JIT::compileOpCall):
        * jit/JITInlines.h:
        (JSC::JIT::getConstantOperand):
        (JSC::JIT::emitPutIntToCallFrameHeader):
        (JSC::JIT::updateTopCallFrame):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_get_scope):
        (JSC::JIT::emit_op_argument_count):
        (JSC::JIT::emit_op_get_rest_length):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::privateCompileCTINativeCall):
        (JSC::JIT::emit_op_get_scope):
        * jit/JSInterfaceJIT.h:
        (JSC::JSInterfaceJIT::emitJumpIfNotType):
        (JSC::JSInterfaceJIT::emitGetFromCallFrameHeaderPtr):
        (JSC::JSInterfaceJIT::emitPutToCallFrameHeader):
        (JSC::JSInterfaceJIT::emitPutCellToCallFrameHeader):
        * jit/SetupVarargsFrame.cpp:
        (JSC::emitSetVarargsFrame):
        (JSC::emitSetupVarargsFrameFastCase):
        * jit/SpecializedThunkJIT.h:
        (JSC::SpecializedThunkJIT::SpecializedThunkJIT):
        * jit/ThunkGenerators.cpp:
        (JSC::nativeForGenerator):
        (JSC::arityFixupGenerator):
        (JSC::boundThisNoArgsFunctionCallGenerator):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::genericCall):
        (JSC::LLInt::varargsSetup):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::arityCheckFor):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObject.h:
        * runtime/StackAlignment.h:
        (JSC::roundArgumentCountToAlignFrame):
        (JSC::roundLocalRegisterCountForFramePointerOffset):
        (JSC::logStackAlignmentRegisters):
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::startFunction):
        (JSC::WASMFunctionCompiler::endFunction):
        (JSC::WASMFunctionCompiler::boxArgumentsAndAdjustStackPointer):
        (JSC::WASMFunctionCompiler::callAndUnboxResult):
        * wasm/WASMFunctionSyntaxChecker.h:
        (JSC::WASMFunctionSyntaxChecker::updateTempStackHeightForCall):

2016-07-08  Chris Dumez  <cdumez@apple.com>

        Object.defineProperty() should maintain existing getter / setter if not overridden in the new descriptor
        https://bugs.webkit.org/show_bug.cgi?id=159576
        <rdar://problem/27242197>

        Reviewed by Mark Lam.

        Object.defineProperty() should maintain existing getter / setter if not
        overridden in the new descriptor. Previously, if the property is a had
        a custom getter / setter, and if the new descriptor only had a setter
        (or only a getter), JSC would clear the existing getter (or setter).
        This behavior did not match the EcmaScript specification or Firefox /
        Chrome. This patch fixes the issue.

        This fixes searching and search suggestions on www.iciba.com.

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

2016-07-08  Michael Saboff  <msaboff@apple.com>

        Dumping the object graph doesn't work with verbose GC logging
        https://bugs.webkit.org/show_bug.cgi?id=159569

        Reviewed by Mark Lam.

        The current object graph logging code tries to revisits the graph.  This doesn't work
        correctly and asking around it isn't used.  The only way to dump the true object graph
        is to log while we GC and that has obvious performance implications.
        Therefore I eliminated GCLogging::dumpObjectGraph() and related code.  

        * heap/GCLogging.cpp:
        (JSC::GCLogging::levelAsString):
        (JSC::LoggingFunctor::LoggingFunctor): Deleted.
        (JSC::LoggingFunctor::~LoggingFunctor): Deleted.
        (JSC::LoggingFunctor::operator()): Deleted.
        (JSC::LoggingFunctor::log): Deleted.
        (JSC::LoggingFunctor::reviveCells): Deleted.
        (JSC::LoggingFunctor::returnValue): Deleted.
        (JSC::GCLogging::dumpObjectGraph): Deleted.
        * heap/Heap.cpp:
        (JSC::Heap::didFinishCollection):

2016-07-08  Keith Miller  <keith_miller@apple.com>

        speculateTypedArrayIsNotNeutered has an inverted speculation
        https://bugs.webkit.org/show_bug.cgi?id=159571

        Reviewed by Mark Lam.

        For some confusing reason FTLLowerDFGToB3 takes the condition the
        speculation wants to be false. This issue caused
        typedarray-access-monomorphic-neutered.js to fail on the bots.

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

2016-07-08  Mark Lam  <mark.lam@apple.com>

        Rename jsCPUStackLimit to osStackLimitWithReserve and jsEmulatedStackLimit to cloopStackLimit.
        https://bugs.webkit.org/show_bug.cgi?id=159544

        Reviewed by Geoffrey Garen.

        This patch does the following refactoring:
        1. Rename jsCPUStackLimit to osStackLimitWithReserve.
        2. Rename jsEmulatedStackLimit to cloopStackLimit.
        2. Remove llintStackLimit (which previously is either an alias for
           jsCPUStackLimit or jsEmulatedStackLimit depending on whether we have a JIT or
           C Loop build).  Instead, we'll change the LLINT to conditionally use the
           osStackLimitWithReserve or cloopStackLimit.

        There are no semantic changes.

        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::lower):
        * interpreter/JSStack.cpp:
        (JSC::JSStack::JSStack):
        (JSC::JSStack::growSlowCase):
        (JSC::JSStack::lowAddress):
        (JSC::JSStack::highAddress):
        * interpreter/JSStack.h:
        * interpreter/JSStackInlines.h:
        (JSC::JSStack::ensureCapacityFor):
        (JSC::JSStack::shrink):
        (JSC::JSStack::grow):
        (JSC::JSStack::setCLoopStackLimit):
        (JSC::JSStack::setJSEmulatedStackLimit): Deleted.
        * jit/JIT.cpp:
        (JSC::JIT::compileWithoutLinking):
        * jit/SetupVarargsFrame.cpp:
        (JSC::emitSetupVarargsFrameFastCase):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/RegExp.cpp:
        (JSC::RegExp::finishCreation):
        (JSC::RegExp::compile):
        (JSC::RegExp::compileMatchOnly):
        * runtime/VM.cpp:
        (JSC::VM::updateStackLimit):
        * runtime/VM.h:
        (JSC::VM::reservedZoneSize):
        (JSC::VM::osStackLimitWithReserve):
        (JSC::VM::addressOfOSStackLimitWithReserve):
        (JSC::VM::cloopStackLimit):
        (JSC::VM::setCLoopStackLimit):
        (JSC::VM::isSafeToRecurse):
        (JSC::VM::jsCPUStackLimit): Deleted.
        (JSC::VM::addressOfJSCPUStackLimit): Deleted.
        (JSC::VM::jsEmulatedStackLimit): Deleted.
        (JSC::VM::setJSEmulatedStackLimit): Deleted.
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::startFunction):

2016-07-08  Commit Queue  <commit-queue@webkit.org>

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

        Caused build failure (Requested by perarne on #webkit).

        Reverted changeset:

        "[Win] DLLs are missing version information."
        https://bugs.webkit.org/show_bug.cgi?id=159349
        http://trac.webkit.org/changeset/202799

2016-07-08  Youenn Fablet  <youenn@apple.com>

        Built-in generator should generate files with a default copyright
        https://bugs.webkit.org/show_bug.cgi?id=159561

        Reviewed by Alex Christensen.

        * Scripts/builtins/builtins_model.py:
        (BuiltinsCollection._parse_copyright_lines): Adding default copyright to the parsed copyrights.
        * Scripts/builtins/builtins_templates.py:
        (BuiltinsGeneratorTemplates): Adding a default copyright.
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result: Rebasing with added default copyright.
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result: Ditto.
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result: Ditto.
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result: Ditto.
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result: Ditto.
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result: Ditto.
        * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result: Ditto.
        * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result: Ditto.
        * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result: Ditto.
        * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result: Ditto.
        * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result: Ditto.
        * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result: Ditto.


2016-07-08  Keith Miller  <keith_miller@apple.com>

        TypedArrays need more isNeutered checks.
        https://bugs.webkit.org/show_bug.cgi?id=159231

        Reviewed by Filip Pizlo.

        According to the ES6 spec if a user tries to get, set, or define a
        property on a neutered TypedArray we should throw an
        exception. Currently, if a user tries to get an out of bounds
        access on a TypedArray we will always OSR.  This makes handling
        the exception easy as all we need to do is make out of bounds gets
        in PolymorphicAccess go to the slow path, which will then throw
        the appropriate exception. For the case of set, we need ensure we
        don't OSR on each out of bounds put since, for some confusing
        reason, people do this.  Thus, for GetByVal in the DFG/FTL if the
        user accesses out of bounds we then need to check if the view has
        been neutered. If it is neutered then we will OSR.

        Additionally, this patch adds a bunch of isNeutered checks to
        various prototype functions for TypedArray, which are needed for
        correctness.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds):
        (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
        (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray):
        * dfg/DFGSpeculativeJIT.h:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal):
        (JSC::FTL::DFG::LowerDFGToB3::speculateTypedArrayIsNotNeutered):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitIntTypedArrayPutByVal):
        (JSC::JIT::emitFloatTypedArrayPutByVal):
        * runtime/JSArrayBufferView.h:
        * runtime/JSCJSValue.h:
        (JSC::encodedJSUndefined):
        (JSC::encodedJSValue):
        * runtime/JSGenericTypedArrayView.h:
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::throwNeuteredTypedArrayTypeError):
        (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
        (JSC::JSGenericTypedArrayView<Adaptor>::put):
        (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
        (JSC::JSGenericTypedArrayView<Adaptor>::deleteProperty):
        (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlotByIndex):
        (JSC::JSGenericTypedArrayView<Adaptor>::putByIndex):
        (JSC::JSGenericTypedArrayView<Adaptor>::deletePropertyByIndex):
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewProtoFuncCopyWithin):
        (JSC::genericTypedArrayViewProtoFuncFill):
        (JSC::genericTypedArrayViewProtoFuncIndexOf):
        (JSC::genericTypedArrayViewProtoFuncJoin):
        (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
        (JSC::genericTypedArrayViewProtoFuncSlice):
        (JSC::genericTypedArrayViewProtoFuncSubarray):
        * tests/stress/fold-typed-array-properties.js:
        * tests/stress/typedarray-access-monomorphic-neutered.js: Added.
        (check):
        (test):
        (testFTL):
        * tests/stress/typedarray-access-neutered.js: Added.
        (check):
        (test):
        * tests/stress/typedarray-functions-with-neutered.js:
        (defaultForArg):
        (callWithArgs):
        (checkArgumentsForType):
        (checkArguments):
        * tests/stress/typedarray-view-string-properties-neutered.js: Added.
        (call):
        (test):

2016-07-08  Youenn Fablet  <youenn@apple.com>

        Generate WebCore builtin wrapper files
        https://bugs.webkit.org/show_bug.cgi?id=159461

        Reviewed by Brian Burg.

        Updating builtin generator to generate wrapper files used in WebCore (See WebCore change log).
        Rebasing builtins generator test results according generator changes by activating wrapper file generation for
        WebCore builtins tests.

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Scripts/builtins/builtins.py: Adding new generators.
        * Scripts/builtins/builtins_generate_internals_wrapper_header.py: Added to generate WebCoreJSBuiltinInternals.h.
        * Scripts/builtins/builtins_generate_internals_wrapper_implementation.py: Added to generate WebCoreJSBuiltinInternals.cpp.
        * Scripts/builtins/builtins_generate_wrapper_header.py: Added to generate WebCoreJSBuiltins.h.
        * Scripts/builtins/builtins_generate_wrapper_implementation.py: Added to generate WebCoreJSBuiltins.cpp.
        * Scripts/generate-js-builtins.py: Adding new option to activate generation of the wrapper files.
        (generate_bindings_for_builtins_files):
        * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:

2016-07-07  Joseph Pecoraro  <pecoraro@apple.com>

        padStart/padEnd with Infinity produces unexpected result
        https://bugs.webkit.org/show_bug.cgi?id=159543

        Reviewed by Benjamin Poulain.

        * builtins/GlobalOperations.js:
        (globalPrivate.toLength):
        Fix style.

        * builtins/StringPrototype.js:
        (padStart):
        (padEnd):
        After all observable operations, and after empty string has been handled,
        throw an out of memory error if the resulting string would be greater
        than the maximum string size.

        * tests/es6/Object_static_methods_Object.getOwnPropertyDescriptors-proxy.js:
        (shouldThrow): Deleted.
        * tests/es6/Object_static_methods_Object.getOwnPropertyDescriptors.js:
        (shouldThrow):
        (testMeta):
        * tests/es6/String.prototype_methods_String.prototype.padEnd.js:
        (shouldThrow):
        (TestToLength):
        (TestMemoryLimits):
        (TestMeta): Deleted.
        * tests/es6/String.prototype_methods_String.prototype.padStart.js:
        (shouldThrow):
        (TestToLength):
        (TestMemoryLimits):
        Replace incorrect shouldThrow(..., errorType) with explicit shouldThrow(..., errorMessage).
        The old shouldThrow would incorrectly succeed if the expected error type was just "Error".
        Now we explicitly check the error message.

2016-07-07  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] String.prototype[Symbol.iterator] needs a name
        https://bugs.webkit.org/show_bug.cgi?id=159541

        Reviewed by Yusuke Suzuki.

        A man needs a name.
        Spec: https://tc39.github.io/ecma262/#sec-string.prototype-@@iterator

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

2016-07-07  Michael Saboff  <msaboff@apple.com>

        REGRESSION(184445): Need to insert a StoreBarrier when we don't know child's epoch
        https://bugs.webkit.org/show_bug.cgi?id=159537

        Reviewed by Benjamin Poulain.

        We weren't checking the case of a child node with a null epoch.  The problem surfaces
        when the base node of a PutByVal variant has a non-null epoch, because it represents an
        allocation in the current function, while the child of the same node has an unknown epoch.
        Added a check that the child node is not null before comparing the epochs of the base and
        child nodes.

        The added test creates the problem circumstance by doing a full GC to place an array in
        remembered space, allocating a new object followed by an eden GC.  The new object is
        only referenced by the array and therefore won't be visited Without the store barrier.
        The test may crash or more likely get the wrong answer with the bug.

        * dfg/DFGStoreBarrierInsertionPhase.cpp:
        * tests/stress/regress-159537.js: Added test.
        (MyNumber):
        (MyNumber.prototype.plusOne):
        (bar):
        (foo):
        (test):

2016-07-07  Joseph Pecoraro  <pecoraro@apple.com>

        Unexpected "Out of memory" error for "x".repeat(-1)
        https://bugs.webkit.org/show_bug.cgi?id=159529

        Reviewed by Benjamin Poulain.

        * builtins/StringPrototype.js:
        (globalPrivate.repeatSlowPath):
        (repeat):
        Move the @toInteger and range checking to the always path,
        since the spec does say it should always happen. Also remove
        the duplication of the fast path here.

        * runtime/StringPrototype.cpp:
        (JSC::repeatCharacter):
        Remove unused function.

        (JSC::stringProtoFuncRepeatCharacter):
        ASSERT if given a negative number. This is a private function
        only used internally.

        * tests/stress/string-repeat-edge-cases.js:
        (shouldThrow):
        Update expected error message.

2016-07-07  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Array.prototype[Symbol.unscopables] should have the "includes" property
        https://bugs.webkit.org/show_bug.cgi?id=159504

        Reviewed by Keith Miller.

        The property "includes" was missing.
        Spec: https://tc39.github.io/ecma262/#sec-array.prototype-@@unscopables

        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation):
        * tests/stress/unscopables.js:

2016-07-07  Saam Barati  <sbarati@apple.com>

        ToThis constant folding in DFG is incorrect when the structure indicates that toThis is overridden
        https://bugs.webkit.org/show_bug.cgi?id=159501
        <rdar://problem/27109354>

        Reviewed by Mark Lam.

        We *cannot* constant fold ToThis when the structure of an object
        indicates that toThis() is overridden. isToThisAnIdentity() inside
        AbstractInterpreterInlines accidentally wrote the opposite rule.
        The rule was written as we can constant fold ToThis only when
        toThis() is overridden. To fix the bug, we must write the rule
        as isToThisAnIdentity() can only be true as long as the structure
        set indicates that no structures override toThis().

        We could probably get more clever in the future and notice
        when we're dealing with a constant |this| values. For example,
        a ToThis might occur on a constant JSLexicalEnvironment. We could
        implement the rules of JSLexicalEnvironment's toThis() implementation
        inside AI/constant folding.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::isToThisAnIdentity):
        * tests/stress/to-this-on-constant-lexical-environment.js: Added.
        (foo.bar):
        (foo.inner):
        (foo):

2016-07-07  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Array.prototype.includes uses ToInt32 instead of ToInteger on the index argument
        https://bugs.webkit.org/show_bug.cgi?id=159505

        Reviewed by Mark Lam.

        The code was using (value)|0 which is effectively a ToInt32.
        This fails on large integers and +-Infinity.

        Spec: https://tc39.github.io/ecma262/#sec-array.prototype.includes

        * builtins/ArrayPrototype.js:
        (includes):

2016-07-07  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] String.prototype.normalize should have a length of zero
        https://bugs.webkit.org/show_bug.cgi?id=159506

        Reviewed by Yusuke Suzuki.

        Spec: https://tc39.github.io/ecma262/#sec-string.prototype.normalize
        The argument is optional, the length should be zero.

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

2016-07-07  Csaba Osztrogonác  <ossy@webkit.org>

        [ARMv7] REGRESSION(r197655): ASSERTION FAILED: (cond == Zero) || (cond == NonZero)
        https://bugs.webkit.org/show_bug.cgi?id=159419

        Reviewed by Benjamin Poulain.

        Allow Signed and PositiveOrZero conditions too because tst instruction updates N and Z flags.

        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::branchTest32):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::branchTest32): Add assertions to avoid possible bugs in the future.

2016-07-06  Youenn Fablet  <youenn@apple.com>

        Builtin generator should use pragma once for header files
        https://bugs.webkit.org/show_bug.cgi?id=159462

        Reviewed by Alex Christensen.

        * Scripts/builtins/builtins_generate_combined_header.py:
        (BuiltinsCombinedHeaderGenerator.generate_output): 
        * Scripts/builtins/builtins_generate_separate_header.py:
        (BuiltinsSeparateHeaderGenerator.generate_output):
        * Scripts/builtins/builtins_templates.py:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
        * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:

2016-07-06  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Unify how we throw TypeError from C++
        https://bugs.webkit.org/show_bug.cgi?id=159500

        Reviewed by Saam Barati.

        Throwing a TypeError is an uncommon case. We should minimize the impact
        on the call sites.

        This patch does that by:
        -Replace the 2 calls createTypeError()->throwException() by throwTypeError().
        -Use ASCIILiteral when possible.
        -Add an overload of throwTypeError() taking ASCIILiteral directly
         (that way, the String creation and destruction is done by the callee).

        On x86_64, this reduces the __TEXT__ segment by 29kb.

        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
        * inspector/JSJavaScriptCallFrame.cpp:
        (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        * jit/JITOperations.cpp:
        * runtime/DatePrototype.cpp:
        (JSC::dateProtoFuncToJSON):
        * runtime/Error.cpp:
        (JSC::throwConstructorCannotBeCalledAsFunctionTypeError):
        (JSC::throwTypeError):
        * runtime/Error.h:
        (JSC::throwVMTypeError):
        * runtime/JSArrayBufferPrototype.cpp:
        (JSC::arrayBufferProtoFuncSlice):
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::putToPrimitive):
        (JSC::JSValue::toStringSlowCase):
        * runtime/JSCJSValueInlines.h:
        (JSC::toPreferredPrimitiveType):
        * runtime/JSDataViewPrototype.cpp:
        (JSC::getData):
        (JSC::setData):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::defineOwnProperty):
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::constructGenericTypedArrayViewFromIterator):
        (JSC::constructGenericTypedArrayViewWithArguments):
        (JSC::constructGenericTypedArrayView):
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::speciesConstruct):
        (JSC::genericTypedArrayViewProtoFuncSet):
        (JSC::genericTypedArrayViewProtoFuncCopyWithin):
        (JSC::genericTypedArrayViewProtoFuncIndexOf):
        (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
        (JSC::genericTypedArrayViewProtoFuncSubarray):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncProtoGetter):
        (JSC::globalFuncProtoSetter):
        * runtime/JSONObject.cpp:
        (JSC::Stringifier::appendStringifiedValue):
        * runtime/JSObject.cpp:
        (JSC::JSObject::setPrototypeWithCycleCheck):
        (JSC::callToPrimitiveFunction):
        (JSC::JSObject::ordinaryToPrimitive):
        (JSC::JSObject::defaultHasInstance):
        (JSC::validateAndApplyPropertyDescriptor):
        * runtime/JSTypedArrayViewConstructor.cpp:
        (JSC::constructTypedArrayView):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::typedArrayViewPrivateFuncLength):
        (JSC::typedArrayViewProtoFuncSet):
        (JSC::typedArrayViewProtoFuncCopyWithin):
        (JSC::typedArrayViewProtoFuncFill):
        (JSC::typedArrayViewProtoFuncLastIndexOf):
        (JSC::typedArrayViewProtoFuncIndexOf):
        (JSC::typedArrayViewProtoFuncJoin):
        (JSC::typedArrayViewProtoGetterFuncBuffer):
        (JSC::typedArrayViewProtoGetterFuncLength):
        (JSC::typedArrayViewProtoGetterFuncByteLength):
        (JSC::typedArrayViewProtoGetterFuncByteOffset):
        (JSC::typedArrayViewProtoFuncReverse):
        (JSC::typedArrayViewProtoFuncSubarray):
        (JSC::typedArrayViewProtoFuncSlice):
        * runtime/ObjectConstructor.cpp:
        (JSC::toPropertyDescriptor):
        (JSC::objectConstructorDefineProperty):
        (JSC::objectConstructorDefineProperties):
        (JSC::objectConstructorCreate):
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncDefineGetter):
        (JSC::objectProtoFuncDefineSetter):
        * runtime/RegExpPrototype.cpp:
        (JSC::regExpProtoFuncCompile):
        * runtime/Symbol.cpp:
        (JSC::Symbol::toNumber):

2016-07-06  Saam Barati  <sbarati@apple.com>

        InlineAccess::sizeForLengthAccess() is wrong on some platforms because it should also consider "length" not being array length
        https://bugs.webkit.org/show_bug.cgi?id=159429

        Reviewed by Filip Pizlo.

        The calculation inside sizeForLengthAccess() was not taking into
        account that an access to a "length" property might not be an
        array length access. sizeForLengthAccess() should always have enough
        room for a regular self property accesses. This only changes how
        much of a nop sled we emit if array length access size is smaller
        than self access size. This matters on ARM64.

        * bytecode/InlineAccess.h:
        (JSC::InlineAccess::sizeForPropertyAccess):
        (JSC::InlineAccess::sizeForPropertyReplace):
        (JSC::InlineAccess::sizeForLengthAccess):

2016-07-06  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r198928 and r198985.
        https://bugs.webkit.org/show_bug.cgi?id=159478

        "It's breaking some websites" (Requested by saamyjoon on
        #webkit).

        Reverted changesets:

        "[ES6] Disallow var assignments in for-in loops"
        https://bugs.webkit.org/show_bug.cgi?id=155451
        http://trac.webkit.org/changeset/198928

        "Unreviewed, turn ES6 for-in loop test success"
        https://bugs.webkit.org/show_bug.cgi?id=155451
        http://trac.webkit.org/changeset/198985

2016-07-05  Mark Lam  <mark.lam@apple.com>

        Rename VM stack limit fields to better describe their purpose.
        https://bugs.webkit.org/show_bug.cgi?id=159451

        Reviewed by Keith Miller.

        This is in preparation for an upcoming patch that changes what stack limit values
        are used under various circumstances.  This patch aims to do some minimal work to
        rename the fields so that it will be easier to reason about the upcoming patch.
    
        In this patch, we make the following changes:

        1. Rename VM::m_stackLimit to VM::m_jsCPUStackLimit.

        2. VM::m_jsStackLimit used to have an overloaded meaning:
           a. For JIT builds, m_jsStackLimit is synonymous with m_stackLimit.
           b. For C Loop builds, m_jsStackLimit is a separate pointer that points to the
              emulated JS stack that the C Loop uses.

           In place of m_jsStackLimit, this patch introduces 2 new fields:
           VM::m_jsEmulatedStackLimit and VM::m_llintStackLimit.

           m_llintStackLimit is the limit that the LLInt assembly uses for its stack
           check.  m_llintStackLimit behaves like the old m_jsStackLimit in that:
           a. For JIT builds, m_llintStackLimit is synonymous with m_jsCPUStackLimit.
           b. For C Loop builds, m_llintStackLimit is synonymous with m_jsEmulatedStackLimit.

           m_jsEmulatedStackLimit is used for the emulated stack that the C Loop uses.

        3. Rename the following methods to match the above:
             VM::stackLimit() ==> VM::jsCPUStackLimit()
             VM::addressOfStackLimit() ==> VM::addressOfJSCPUStackLimit()
             VM::jsStackLimit() ==> VM::jsEmulatedStackLimit()
             VM::setJSStackLimit() ==> VM::setJSEmulatedStackLimit()
             JSStack::setStackLimit() ==> JSStack::setEmulatedStackLimit()

        4. With change (2) and (3), the limits will be used as follows:
           a. VM code doing stack recursion checks will only use m_jsCPUStackLimit.
           b. JIT code will only use m_jsCPUStackLimit.
           c. C Loop emulated stack code in JSStack will only use m_jsEmulatedStackLimit.
              Note: the part of JSStack that operates on a JIT build will use
                    m_jsCPUStackLimit as expected.
           d. LLINT assembly code will only use m_llintStackLimit.

        This patch only contains the above refactoring changes.  There is no behavior
        change.

        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::lower):
        * interpreter/JSStack.cpp:
        (JSC::JSStack::JSStack):
        (JSC::JSStack::growSlowCase):
        (JSC::JSStack::lowAddress):
        (JSC::JSStack::highAddress):
        * interpreter/JSStack.h:
        * interpreter/JSStackInlines.h:
        (JSC::JSStack::ensureCapacityFor):
        (JSC::JSStack::shrink):
        (JSC::JSStack::grow):
        (JSC::JSStack::setJSEmulatedStackLimit):
        (JSC::JSStack::setStackLimit): Deleted.
        * jit/JIT.cpp:
        (JSC::JIT::compileWithoutLinking):
        * jit/SetupVarargsFrame.cpp:
        (JSC::emitSetupVarargsFrameFastCase):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/RegExp.cpp:
        (JSC::RegExp::finishCreation):
        (JSC::RegExp::compile):
        (JSC::RegExp::compileMatchOnly):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::updateStackLimit):
        * runtime/VM.h:
        (JSC::VM::reservedZoneSize):
        (JSC::VM::jsCPUStackLimit):
        (JSC::VM::addressOfJSCPUStackLimit):
        (JSC::VM::jsEmulatedStackLimit):
        (JSC::VM::setJSEmulatedStackLimit):
        (JSC::VM::isSafeToRecurse):
        (JSC::VM::jsStackLimit): Deleted.
        (JSC::VM::setJSStackLimit): Deleted.
        (JSC::VM::stackLimit): Deleted.
        (JSC::VM::addressOfStackLimit): Deleted.
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::startFunction):

2016-07-05  Saam Barati  <sbarati@apple.com>

        StackVisitor::unwindToMachineCodeBlockFrame() may unwind past a VM entry frame when catching an exception and the frame has inlined tail calls
        https://bugs.webkit.org/show_bug.cgi?id=159448
        <rdar://problem/27084459>

        Reviewed by Mark Lam.

        Consider the following stack trace:
        (machine) foo -> VM entry frame -> (machine) bar -> (inlined tailcall) baz

        If an exception is thrown at 'baz', we will do exception unwinding,
        which will eventually call unwindToMachineCodeBlockFrame() which will call
        gotoNextFrame() on the 'baz' frame. The next logical frame for 'baz' is 'foo' because
        'bar' tail called 'baz' even though there is a machine frame for 'bar' on the stack.
        This is a bug. unwindToMachineCodeBlockFrame() should not care about the next
        logical frame, it just wants to move StackVisitor's state to the current machine
        frame. The bug here is that we would end up unwinding past the VM entry frame
        which can have all kinds of terrible consequences.

        This bug fixes unwindToMachineCodeBlockFrame() by having it not rely
        on gotoNextFrame() and instead using its own mechanism for setting
        the StackVisotor's state to the current machine frame.

        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::unwindToMachineCodeBlockFrame):
        * tests/stress/dont-unwind-past-vm-entry-frame.js: Added.
        (let.p.new.Proxy):
        (let.p.new.Proxy.apply):
        (bar):
        (let.good):
        (getItem):
        (start):

2016-07-05  Joseph Pecoraro  <pecoraro@apple.com>

        RELEASE_ASSERT(!thisObject) in ObjCCallbackFunctionImpl::call when calling JSExport ObjC Constructor without operator new
        https://bugs.webkit.org/show_bug.cgi?id=159446

        Reviewed by Mark Lam.

        Treat ObjC JSExport init constructors like ES6 Class Constructors
        and throw a TypeError when called without 'new'.

        * API/ObjCCallbackFunction.mm:
        (JSC::ObjCCallbackFunctionImpl::type):
        (JSC::objCCallbackFunctionCallAsFunction):
        When calling an init method as a function instead of construction
        throw a TypeError.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        Improve error message.

        * API/tests/testapi.mm:
        (testObjectiveCAPIMain):
        Test we get an exception when calling an ObjC constructor without 'new'.

2016-07-05  Mark Lam  <mark.lam@apple.com>

        Remove some unneeded #include "CachedCall.h".
        https://bugs.webkit.org/show_bug.cgi?id=159449

        Reviewed by Saam Barati.

        * runtime/ArrayPrototype.cpp:
        * runtime/JSArray.cpp:
        * runtime/MapPrototype.cpp:
        * runtime/SetPrototype.cpp:

2016-07-05  Geoffrey Garen  <ggaren@apple.com>

        Crash @ bankofamerica.com, University of Vienna
        https://bugs.webkit.org/show_bug.cgi?id=159439

        Reviewed by Saam Barati.

        * ftl/FTLLink.cpp:
        (JSC::FTL::link): Do check for stack overflow in the arity mismatch thunk
        because it can happen. Don't store a CallSiteIndex because we haven't
        stored a CodeBlock yet, and our stack frame is not fully constructed,
        so it would be an error for any client to try to load this value (and
        operationCallArityCheck does not load this value).

        * tests/stress/arity-check-ftl-throw.js: Added. New test case for stressing
        a stack overflow with arity mismatch. Sadly, after hours of fiddling, I
        can't seem to get this to fail in trunk. Still, it's good to have some
        more testing in this area.

2016-07-05  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] The prototype cycle checks throws the wrong error type
        https://bugs.webkit.org/show_bug.cgi?id=159393

        Reviewed by Geoffrey Garen.

        We were supposed to throw the TypeError:
        -https://tc39.github.io/ecma262/#sec-set-object.prototype.__proto__

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

2016-07-05  Saam Barati  <sbarati@apple.com>

        our parsing for "use strict" is wrong when we first parse other directives that are not "use strict" but are located in a place where "use strict" would be valid
        https://bugs.webkit.org/show_bug.cgi?id=159376
        <rdar://problem/27108773>

        Reviewed by Benjamin Poulain.

        Our strict mode detection algorithm used to break if we ever saw a directive
        that is not "use strict" but is syntactically located in a location where our
        parser looks for "use strict". It broke as follows:

        If a function started with a non "use strict" string literal, we will allow
        "use strict" to be in any arbitrary statement inside the top level block in
        the function body. For example, this meant that if we parsed a sequence of string
        literals, followed by arbitrary statements, followed by "use strict", we would parse
        the function as if it's in strict mode. This is the wrong behavior with respect to
        the spec. This has consequences in other ways that break invariants of the language.
        For example, we used to allow functions that are lexically nested inside what we deemed
        a strict function to be non-strict. This used to fire an assertion if we ever skipped over
        that function using the source provider cache, but it worked just fine in release builds.

        This patch fixes this bug.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseSourceElements):
        (JSC::Parser<LexerType>::parseStatement):
        * tests/stress/ensure-proper-strict-mode-parsing.js: Added.
        (foo.bar):
        (foo):
        (bar.foo):
        (bar):
        (bar.call.undefined.this.throw.new.Error.string_appeared_here.baz):
        (baz.call.undefined.undefined.throw.new.Error.string_appeared_here.jaz):
        (jaz.call.undefined.this.throw.new.Error.string_appeared_here.vaz):

2016-07-05  Saam Barati  <sbarati@apple.com>

        reportAbandonedObjectGraph should report abandoned bytes based on capacity() so it works even if a GC has never happened
        https://bugs.webkit.org/show_bug.cgi?id=159222
        <rdar://problem/27001991>

        Reviewed by Geoffrey Garen.

        When reportAbandonedObjectGraph() was called before the first GC, it used to
        not indicate to the GC timers that we have memory that needs to be collected
        because the calculation was based on m_sizeAfterLastCollect (which was zero).
        This patch makes the calculation based on capacity() which is a valid number
        even before the first GC.

        * heap/Heap.cpp:
        (JSC::Heap::reportAbandonedObjectGraph):
        (JSC::Heap::protect):
        (JSC::Heap::didAbandon): Deleted.
        * heap/Heap.h:
        (JSC::Heap::jitStubRoutines):

2016-07-05  Csaba Osztrogonác  <ossy@webkit.org>

        Typo fix after r202214
        https://bugs.webkit.org/show_bug.cgi?id=159416

        Reviewed by Saam Barati.

        * bytecode/InlineAccess.h:

2016-07-03  Per Arne Vollan  <pvollan@apple.com>

        [Win] DLLs are missing version information.
        https://bugs.webkit.org/show_bug.cgi?id=159349

        Reviewed by Brent Fulgham.

        Run perl version stamp utility.
        
        * CMakeLists.txt:

2016-07-01  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] MacroAssemblerX86::branch8 should accept unsigned 8bit value
        https://bugs.webkit.org/show_bug.cgi?id=159334

        Reviewed by Benjamin Poulain.

        As described in branchTest8 functions, byte in TrustedImm32 is not well defined.
        So the assertion here should be a little permissive; accepting -128 to 255.

        This assertion is originally fired when executing misc-bugs-847389-jpeg2000 benchmark in Debug build.
        So this patch includes misc-bugs-847389-jpeg2000 benchmark.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::branchTest8):
        (JSC::MacroAssemblerX86Common::branch8):
        * b3/testb3.cpp:
        (JSC::B3::testBranch8WithLoad8ZIndex):
        (JSC::B3::run):

2016-07-03  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] __lookupGetter__ and __lookupSetter__ should not ignore exceptions
        https://bugs.webkit.org/show_bug.cgi?id=159390

        Reviewed by Mark Lam.

        See:
        -https://tc39.github.io/ecma262/#sec-object.prototype.__lookupGetter__
        -https://tc39.github.io/ecma262/#sec-object.prototype.__lookupSetter__

        They are both supposed to be regular [[GetOwnProperty]].

        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncLookupGetter):
        (JSC::objectProtoFuncLookupSetter):

2016-07-03  Saam Barati  <sbarati@apple.com>

        BytecodeGenerator::getVariablesUnderTDZ is too conservative
        https://bugs.webkit.org/show_bug.cgi?id=159387

        Reviewed by Filip Pizlo.

        We were too conservative in the following type of programs:
        ```
        {
            {
                let x;
                ...
            }
            let x;
        }
        ```
        We used to report "x" as under TDZ when calling getVariablesUnderTDZ at the
        "...", even though "x" is not under TDZ. This patch removes this conservatism
        and makes the algorithm precise.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::getVariablesUnderTDZ):
        * bytecompiler/BytecodeGenerator.h:

2016-07-03  Filip Pizlo  <fpizlo@apple.com>

        FTL should refer to B3 types directly
        https://bugs.webkit.org/show_bug.cgi?id=159389

        Reviewed by Saam Barati.
        
        When we used LLVM, types were objects that were allocated by the LLVMContext. We had to
        remember pointers to them or else call through the C API every time we wanted the type. We
        stored the type pointers inside FTL::CommonValues.
        
        But in B3, types are just members of an enum. We don't have to remember pointers to them.
        
        This change replaces all prior uses of things like "m_out.int32" with just "Int32", and
        likewise for m_out.boolean, m_out.int64, m_out.intPtr, m_out.floatType, m_out.doubleType,
        and m_out.voidType.
        
        We still use FTL::CommonValues for common constants that we have pre-hoisted. Hopefully we
        will come up with a better story for those eventually, since that's still kinda ugly.

        * ftl/FTLCommonValues.cpp:
        (JSC::FTL::CommonValues::CommonValues):
        * ftl/FTLCommonValues.h:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::createPhiVariables):
        (JSC::FTL::DFG::LowerDFGToB3::compileDoubleRep):
        (JSC::FTL::DFG::LowerDFGToB3::compileBooleanToNumber):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor):
        (JSC::FTL::DFG::LowerDFGToB3::compileToThis):
        (JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
        (JSC::FTL::DFG::LowerDFGToB3::compileStrCat):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithMinOrMax):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithPow):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithRound):
        (JSC::FTL::DFG::LowerDFGToB3::compileArrayifyToStructure):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetById):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByIdWithThis):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByValWithThis):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutByIdWithThis):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutByValWithThis):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetArrayLength):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetMyArgumentByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutAccessorById):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutGetterSetterById):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutAccessorByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compileArrayPush):
        (JSC::FTL::DFG::LowerDFGToB3::compileArrayPop):
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateActivation):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateDirectArguments):
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateScopedArguments):
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateClonedArguments):
        (JSC::FTL::DFG::LowerDFGToB3::compileCopyRest):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetRestLength):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewObject):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArray):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayBuffer):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
        (JSC::FTL::DFG::LowerDFGToB3::compileToNumber):
        (JSC::FTL::DFG::LowerDFGToB3::compileToStringOrCallStringConstructor):
        (JSC::FTL::DFG::LowerDFGToB3::compileToPrimitive):
        (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
        (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
        (JSC::FTL::DFG::LowerDFGToB3::compileStringCharCodeAt):
        (JSC::FTL::DFG::LowerDFGToB3::compileStringFromCharCode):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByOffset):
        (JSC::FTL::DFG::LowerDFGToB3::compileMultiGetByOffset):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutByOffset):
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
        (JSC::FTL::DFG::LowerDFGToB3::compileLoadVarargs):
        (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs):
        (JSC::FTL::DFG::LowerDFGToB3::compileSwitch):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsString):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsJSArray):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsObject):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsObjectOrNull):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsFunction):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsRegExpObject):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsTypedArrayView):
        (JSC::FTL::DFG::LowerDFGToB3::compileTypeOf):
        (JSC::FTL::DFG::LowerDFGToB3::compileIn):
        (JSC::FTL::DFG::LowerDFGToB3::compileOverridesHasInstance):
        (JSC::FTL::DFG::LowerDFGToB3::compileCheckTypeInfoFlags):
        (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
        (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOfCustom):
        (JSC::FTL::DFG::LowerDFGToB3::compileCountExecution):
        (JSC::FTL::DFG::LowerDFGToB3::compileHasIndexedProperty):
        (JSC::FTL::DFG::LowerDFGToB3::compileHasGenericProperty):
        (JSC::FTL::DFG::LowerDFGToB3::compileHasStructureProperty):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetDirectPname):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetEnumerableLength):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetPropertyEnumerator):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetEnumeratorStructurePname):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetEnumeratorGenericPname):
        (JSC::FTL::DFG::LowerDFGToB3::compileToIndexString):
        (JSC::FTL::DFG::LowerDFGToB3::compileCheckStructureImmediate):
        (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
        (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation):
        (JSC::FTL::DFG::LowerDFGToB3::compileSetFunctionName):
        (JSC::FTL::DFG::LowerDFGToB3::numberOrNotCellToInt32):
        (JSC::FTL::DFG::LowerDFGToB3::checkInferredType):
        (JSC::FTL::DFG::LowerDFGToB3::initializeArrayElements):
        (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorage):
        (JSC::FTL::DFG::LowerDFGToB3::reallocatePropertyStorage):
        (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorageWithSizeImpl):
        (JSC::FTL::DFG::LowerDFGToB3::getById):
        (JSC::FTL::DFG::LowerDFGToB3::compare):
        (JSC::FTL::DFG::LowerDFGToB3::compileResolveScope):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetDynamicVar):
        (JSC::FTL::DFG::LowerDFGToB3::compareEqObjectOrOtherToObject):
        (JSC::FTL::DFG::LowerDFGToB3::speculateTruthyObject):
        (JSC::FTL::DFG::LowerDFGToB3::nonSpeculativeCompare):
        (JSC::FTL::DFG::LowerDFGToB3::stringsEqual):
        (JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedObject):
        (JSC::FTL::DFG::LowerDFGToB3::allocateObject):
        (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
        (JSC::FTL::DFG::LowerDFGToB3::ensureShadowChickenPacket):
        (JSC::FTL::DFG::LowerDFGToB3::boolify):
        (JSC::FTL::DFG::LowerDFGToB3::equalNullOrUndefined):
        (JSC::FTL::DFG::LowerDFGToB3::contiguousPutByValOutOfBounds):
        (JSC::FTL::DFG::LowerDFGToB3::buildSwitch):
        (JSC::FTL::DFG::LowerDFGToB3::switchStringSlow):
        (JSC::FTL::DFG::LowerDFGToB3::doubleToInt32):
        (JSC::FTL::DFG::LowerDFGToB3::sensibleDoubleToInt32):
        (JSC::FTL::DFG::LowerDFGToB3::strictInt52ToJSValue):
        (JSC::FTL::DFG::LowerDFGToB3::strictInt52ToInt52):
        (JSC::FTL::DFG::LowerDFGToB3::unboxInt32):
        (JSC::FTL::DFG::LowerDFGToB3::boxInt32):
        (JSC::FTL::DFG::LowerDFGToB3::isCellOrMisc):
        (JSC::FTL::DFG::LowerDFGToB3::unboxDouble):
        (JSC::FTL::DFG::LowerDFGToB3::boxDouble):
        (JSC::FTL::DFG::LowerDFGToB3::jsValueToStrictInt52):
        (JSC::FTL::DFG::LowerDFGToB3::doubleToStrictInt52):
        (JSC::FTL::DFG::LowerDFGToB3::convertDoubleToInt32):
        (JSC::FTL::DFG::LowerDFGToB3::callCheck):
        (JSC::FTL::DFG::LowerDFGToB3::crash):
        * ftl/FTLOutput.cpp:
        (JSC::FTL::Output::bitCast):

2016-07-02  Filip Pizlo  <fpizlo@apple.com>

        DFG LICM needs to go all-in on the idea that some loops can't be LICMed
        https://bugs.webkit.org/show_bug.cgi?id=159388

        Reviewed by Mark Lam.
        
        Some time ago I acknowledged that LICM required loops to meet certain requirements that
        may get broken by the time we do LICM, like that the terminal of the pre-header is ExitOK.
        It used to be that we just ignored that requirement and would hoist anyway, but since
        r189126 we've stopped hoisting out of loops that don't have ExitOK.  We also added tests
        for the case that the pre-header doesn't exist or is invalid.

        It turns out that this patch didn't go far enough: even though it made LICM avoid loops
        that had an invalid pre-header, the part that updated the AI state in nested loops still
        assumed that these loops had valid pre-headers.  We would crash in null dereference in
        that loop if a nested loop had an invalid pre-header.

        The fix is simple: don't update the AI state of nested loops that don't have pre-headers,
        since we won't try to hoist out of those loops anyway.

        * dfg/DFGLICMPhase.cpp:
        (JSC::DFG::LICMPhase::attemptHoist):
        * tests/stress/licm-no-pre-header-nested.js: Added. This would always crash before this fix.
        (foo):
        * tests/stress/licm-pre-header-cannot-exit-nested.js: Added. This was a failed attempt at a test, but I figure it's good to have weird code anyway.
        (foo):
        (valueOf):

2016-06-30  Filip Pizlo  <fpizlo@apple.com>

        Scopes that are not under TDZ should still push their variables onto the TDZ stack so that lifting TDZ doesn't bypass that scope
        https://bugs.webkit.org/show_bug.cgi?id=159332
        rdar://problem/27018958

        Reviewed by Saam Barati.
        
        This fixes an instacrash in this code:
        
            try{}catch(e){}print(e);let e;
        
        We lift TDZ for "e" in "catch (e){}", but since that scope doesn't push anything onto the
        TDZ stack, we lift TDZ from "let e".
        
        The problem is that we weren't tracking the set of variables that do not have TDZ. We need
        to track them to "block" the traversal that lifts TDZ. This change fixes this issue by
        using a map that tracks all known variables, and tells you if they are under TDZ or not.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::numParameters):
        * bytecode/CodeOrigin.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::Label::setLocation):
        (JSC::Variable::dump):
        (JSC::BytecodeGenerator::generate):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::pushLexicalScopeInternal):
        (JSC::BytecodeGenerator::popLexicalScope):
        (JSC::BytecodeGenerator::popLexicalScopeInternal):
        (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
        (JSC::BytecodeGenerator::variable):
        (JSC::BytecodeGenerator::needsTDZCheck):
        (JSC::BytecodeGenerator::liftTDZCheckIfPossible):
        (JSC::BytecodeGenerator::pushTDZVariables):
        (JSC::BytecodeGenerator::getVariablesUnderTDZ):
        (JSC::BytecodeGenerator::endGenerator):
        (WTF::printInternal):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::Variable::isConst):
        (JSC::Variable::setIsReadOnly):
        * interpreter/CallFrame.h:
        (JSC::ExecState::topOfFrame):
        * tests/stress/lift-tdz-bypass-catch.js: Added.
        (foo):
        (catch):

2016-07-01  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] RegExp.compile is not returning the regexp when it succeed
        https://bugs.webkit.org/show_bug.cgi?id=159381

        Reviewed by Mark Lam.

        Spec:
        -https://tc39.github.io/ecma262/#sec-regexp.prototype.compile
        -https://tc39.github.io/ecma262/#sec-regexpinitialize

        * runtime/RegExpPrototype.cpp:
        (JSC::regExpProtoFuncCompile):

2016-07-01  Saam Barati  <sbarati@apple.com>

        fix "ASSERTION FAILED: currentOffset() >= currentLineStartOffset()"
        https://bugs.webkit.org/show_bug.cgi?id=158572
        <rdar://problem/26884092>

        Reviewed by Mark Lam.

        There is a bug in our lexer when we notice the pattern:
        ```<return|continue|break|...etc> // some comment here```
        Our code will say that the token for the comment is a semicolon.
        This is the correct semantics, however, it would give the semicolon
        a start offset of the comment, but it will give its line start offset
        the newline after the comment.  This breaks the invariant in the lexer/parser
        that the offset for the current line starting point must be less than or equal to
        than the start offset of any token on that line. This invariant was broken because
        the line start offset was greater than the token start offset. To maintain this
        invariant, we claim that the semicolon token is located where the comment starts,
        and that its line start offset is the line start offset for the line with the
        comment on it.  There are other solutions that maintain this invariant, but this
        solution provides the best error messages.

        * parser/Lexer.cpp:
        (JSC::Lexer<T>::lex):
        * parser/Parser.h:
        (JSC::Parser::internalSaveLexerState):
        * tests/stress/obscure-error-message-dont-crash.js: Added.
        (try.eval.or.catch):

2016-07-01  Benjamin Poulain  <bpoulain@apple.com>

        __defineGetter__/__defineSetter__ should throw exceptions
        https://bugs.webkit.org/show_bug.cgi?id=142934

        Reviewed by Mark Lam.

        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncDefineGetter):
        (JSC::objectProtoFuncDefineSetter):

2016-07-01  Jon Davis  <jond@apple.com>

        Moved Web Animations and Resource Timing feature entries to WebCore.
        https://bugs.webkit.org/show_bug.cgi?id=159356

        Reviewed by Timothy Hatcher.

        * features.json:

2016-07-01  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Date.toGMTString should be the Date.toUTCString function
        https://bugs.webkit.org/show_bug.cgi?id=159318

        Reviewed by Mark Lam.

        See https://tc39.github.io/ecma262/#sec-date.prototype.togmtstring

        * runtime/DatePrototype.cpp:
        (JSC::DatePrototype::finishCreation):
        (JSC::dateProtoFuncToGMTString): Deleted.

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

        Update JSC_functionOverrides to handle the new SourceCode strings that have params.
        https://bugs.webkit.org/show_bug.cgi?id=159321

        Reviewed by Geoffrey Garen.

        And add tests so that this won't fail silently and bit rot anymore.

        * API/tests/FunctionOverridesTest.cpp: Added.
        (testFunctionOverrides):
        * API/tests/FunctionOverridesTest.h: Added.
        * API/tests/testapi-function-overrides.js: Added.
        * API/tests/testapi.c:
        (main):
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::link):
        * shell/PlatformWin.cmake:
        * tools/FunctionOverrides.cpp:
        (JSC::FunctionOverrides::FunctionOverrides):
        (JSC::FunctionOverrides::reinstallOverrides):
        (JSC::initializeOverrideInfo):
        (JSC::FunctionOverrides::initializeOverrideFor):
        * tools/FunctionOverrides.h:
        (JSC::FunctionOverrides::clear):

2016-07-01  Caio Lima  <ticaiolima@gmail.com>

        ES6: Implement HasRestrictedGlobalProperty when checking for global lexical tier conflicts
        https://bugs.webkit.org/show_bug.cgi?id=148763

        Reviewed by Saam Barati

        I've implemented the ES6 spec 8.1.1.4.14
        (http://www.ecma-international.org/ecma-262/6.0/index.html#sec-hasrestrictedglobalproperty)
        that defines when a global property can be shadowed.

        Added some test cases into global-lexical-redeclare-variable.js

        * runtime/Executable.cpp:
        (JSC::ProgramExecutable::initializeGlobalProperties):
        * tests/stress/global-lexical-redeclare-variable.js:
        (catch):
        * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/eighth.js: Added.
        * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/nineth.js: Added.
        * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/seventh.js: Added.
        * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/sixth.js:
        * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/tenth.js: Added.

2016-07-01  Youenn Fablet  <youennf@gmail.com>

        Add a runtime flag for DOM iterators
        https://bugs.webkit.org/show_bug.cgi?id=159300

        Reviewed by Alex Christensen.

        * runtime/CommonIdentifiers.h:

2016-06-30  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Wrong function name next to scope
        https://bugs.webkit.org/show_bug.cgi?id=158210
        <rdar://problem/26543093>

        Reviewed by Timothy Hatcher.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        Add DebuggerLocation. A helper for describing a unique location.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::setConstantRegisters):
        When compiled with debug info, add a SymbolTable rare data pointer
        back to the CodeBlock. This will be used later to get JSScope debug
        info if Web Inspector pauses.

        * runtime/SymbolTable.h:
        * runtime/SymbolTable.cpp:
        (JSC::SymbolTable::cloneScopePart):
        (JSC::SymbolTable::prepareForTypeProfiling):
        (JSC::SymbolTable::uniqueIDForVariable):
        (JSC::SymbolTable::uniqueIDForOffset):
        (JSC::SymbolTable::globalTypeSetForOffset):
        (JSC::SymbolTable::globalTypeSetForVariable):
        Rename rareData and include a CodeBlock pointer.

        (JSC::SymbolTable::rareDataCodeBlock):
        (JSC::SymbolTable::setRareDataCodeBlock):
        Setter and getter for the rare data. It should only be set once.

        (JSC::SymbolTable::visitChildren):
        Visit the rare data code block if we have one.

        * runtime/JSSymbolTableObject.h:
        * runtime/JSSymbolTableObject.cpp:
        (JSC::JSSymbolTableObject::deleteProperty):
        (JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames):
        Give JSSymbolTable its own class info. JSWithScope was unexpectedly
        inheriting from JSSymbolTable since it did not have its own and
        was using JSScope's class info. Also do a bit of cleanup.

        * debugger/DebuggerLocation.cpp: Added.
        (JSC::DebuggerLocation::DebuggerLocation):
        * debugger/DebuggerLocation.h: Added.
        (JSC::DebuggerLocation::DebuggerLocation):
        Construction from a ScriptExecutable.

        * runtime/JSScope.cpp:
        (JSC::JSScope::symbolTable):
        * runtime/JSScope.h:
        * debugger/DebuggerScope.h:
        * debugger/DebuggerScope.cpp:
        (JSC::DebuggerScope::name):
        (JSC::DebuggerScope::location):
        Name and location for a scope. This uses:
        JSScope -> SymbolTable -> CodeBlock -> Executable

        * inspector/protocol/Debugger.json:
        * inspector/InjectedScriptSource.js:
        (InjectedScript.CallFrameProxy.prototype._wrapScopeChain):
        (InjectedScript.CallFrameProxy._createScopeJson):
        * inspector/JSJavaScriptCallFrame.cpp:
        (Inspector::valueForScopeType):
        (Inspector::valueForScopeLocation):
        (Inspector::JSJavaScriptCallFrame::scopeDescriptions):
        (Inspector::JSJavaScriptCallFrame::scopeType): Deleted.
        * inspector/JSJavaScriptCallFrame.h:
        * inspector/JSJavaScriptCallFramePrototype.cpp:
        (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
        (Inspector::jsJavaScriptCallFramePrototypeFunctionScopeDescriptions):
        (Inspector::jsJavaScriptCallFramePrototypeFunctionScopeType): Deleted.
        Simplify this code to build the objects we will send across the protocol
        to descript a Scope.

2016-06-30  Saam Barati  <sbarati@apple.com>

        missing exception checks in arrayProtoFuncReverse
        https://bugs.webkit.org/show_bug.cgi?id=159319
        <rdar://problem/27083696>

        Reviewed by Filip Pizlo.

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

2016-06-30  Saam Barati  <sbarati@apple.com>

        get_by_id_with_this does not trigger a to_this in caller.
        https://bugs.webkit.org/show_bug.cgi?id=159226

        Reviewed by Keith Miller.

        This is a bug if the caller is in sloppy mode and the callee is in strict
        mode. This can't happen with ES6 classes because they're all in strict mode,
        but it can happen with method syntax on an object literal. The caller must
        to_this on |this| when it knows that it performs super property accesses.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * tests/stress/super-property-access-object-literal-to-this-2.js: Added.
        (assert):
        (test):
        (let.o1.get foo):
        (let.o2.a):
        (let.o2.aa):
        * tests/stress/super-property-access-object-literal-to-this.js: Added.
        (assert):
        (test):
        (let.o1.get foo):
        (let.o2.a):
        (let.o2.aa):
        (let.o2.b):
        (let.o2.bb):
        * tests/stress/super-property-access-to-this.js: Added.
        (assert):
        (test):
        (Base.prototype.get foo):
        (Base):
        (Child.prototype.a):
        (Child.prototype.b):
        (Child):

2016-06-30  Saam Barati  <sbarati@apple.com>

        We need to to_this when an inner arrow function uses 'this'
        https://bugs.webkit.org/show_bug.cgi?id=159290
        <rdar://problem/27058322>

        Reviewed by Geoffrey Garen.

        We put the |this| value into the closure object when there
        is an arrow function that uses |this|. However, an arrow function
        using |this| wasn't causing the creator of the closure that
        holds |this| to to_this its value before putting it in the
        closure. That's a huge bug because it means some arrow functions
        can capture the raw |this| value, which might be a JSLexicalEnvironment.
        This patch fixes this by adding an easy to check to see if any
        inner arrow functions use |this|, and if any do, it will to_this
        the |this| value.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * tests/stress/to-this-before-arrow-function-closes-over-this-that-starts-as-lexical-environment.js: Added.
        (assert):
        (obj):
        (foo.capture):
        (foo.wrapper.let.x.):
        (foo2.capture):
        (foo2.wrapper.let.x.):
        (foo2.wrapper.bar):

2016-06-29  Filip Pizlo  <fpizlo@apple.com>

        Generators violate bytecode liveness validation
        https://bugs.webkit.org/show_bug.cgi?id=159279

        Reviewed by Yusuke Suzuki.
        
        Fix a liveness bug found by Basic. The problem is that resume's intended liveness rule is:
        "live-in is just the token argument", but the liveness analysis thought that the rule was
        "live-in is live-out minus defs plus live-at-catch". Clearly these two rules are quite
        different. The way this sort of worked before is that we would define the defs of resume
        as being equal to our prediction of what the live-outs would be. We did this in the hope
        that we would subtract all live-outs. But, this misses the live-at-catch part. So, this
        change adds another hack to neutralize live-at-catch.
        
        This would make a lot more sense if we wrote a new liveness analysis that was just for
        generator conversion. It could reuse BytecodeUseDef but otherwise it would be a new thing.
        It would be easy to write crazy rules for save/resume in such an analysis, especially if
        that analysis rewrote the bytecode. We could then just have an op_yield that is a no-op.
        We would just record the live-outs of op_yield and use that for rewriting the code in terms
        of a switch statement.

        * bytecode/BytecodeLivenessAnalysis.cpp:
        (JSC::stepOverInstruction):
        (JSC::BytecodeLivenessAnalysis::dumpResults):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):

2016-06-30  Commit Queue  <commit-queue@webkit.org>

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

        The test for this change times out on mac-wk2 debug and caused
        an existing test to crash. (Requested by ryanhaddad on
        #webkit).

        Reverted changeset:

        "Web Inspector: Wrong function name next to scope"
        https://bugs.webkit.org/show_bug.cgi?id=158210
        http://trac.webkit.org/changeset/202659

2016-06-30  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Date.setYear() misses timeClip()
        https://bugs.webkit.org/show_bug.cgi?id=159289

        Reviewed by Geoffrey Garen.

        * runtime/DatePrototype.cpp:
        (JSC::dateProtoFuncSetYear):

2016-06-30  Joseph Pecoraro  <pecoraro@apple.com> and Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Implement isFinite / isNaN in JS and make DFG ToNumber accept non number values
        https://bugs.webkit.org/show_bug.cgi?id=154022

        Reviewed by Filip Pizlo.

        We aim at optimizing @toInteger operation.
        While it still has an unoptimized part[1], this patch should be a first step.

        We introduce the @toNumber builtin intrinsic operation.
        This converts the given value to the JS number by emitting op_to_number bytecode.
        Previously @toInteger called C++ @Number constructor for that purpose.

        And in DFG, op_to_number is converted to DFG ToNumber node.
        During DFG, we attempt to convert this to edge filtering and Identity, but if we fail,
        we just fall back to calling the C++ function.

        To utilize ToNumber in user-land side, we add a path attempting to convert Number constructor calls
        to ToNumber DFG nodes. This conversion is useful because `Number(value)` is used to convert a value to a number in JS.

        Before this patch, we emit simple edge filtering (NumberUse) instead of emitting DFG node like ToNumber for op_to_number.
        But emitting ToNumber is useful, because in the case of `Number(value)`, considering `value` may not be a number is reasonable.

        By leveraging @toNumber operation, we rewrite Number.{isFinite, isNaN}, global.{isFinite, isNaN} and @toInteger.

        ToNumber DFG node has a value profiling. This profiling is leveraged to determine the result number type of the ToNumber operation.
        This value profiling is provided from either NumberConstructor's call operation or op_to_number.

        The results (with the added performance tests) show that, while existing cases are performance neutral, the newly added cases gain the performance benefit.
        And ASMBench/n-body.c also shows stable ~2% progression.

        [1]: https://bugs.webkit.org/show_bug.cgi?id=153738

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/BuiltinNames.h:
        * builtins/GlobalObject.js:
        (globalPrivate.isFinite):
        (globalPrivate.isNaN):
        (globalPrivate.toInteger): Deleted.
        (globalPrivate.toLength): Deleted.
        (globalPrivate.isDictionary): Deleted.
        (globalPrivate.speciesGetter): Deleted.
        (globalPrivate.speciesConstructor): Deleted.
        * builtins/GlobalOperations.js: Copied from Source/JavaScriptCore/builtins/GlobalObject.js.
        (globalPrivate.toInteger):
        (globalPrivate.toLength):
        (globalPrivate.isDictionary):
        (globalPrivate.speciesGetter):
        (globalPrivate.speciesConstructor):
        * builtins/NumberConstructor.js: Added.
        (isFinite):
        (isNaN):
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecode/BytecodeList.json:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::finishCreation):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitUnaryOp):
        (JSC::BytecodeGenerator::emitUnaryOpProfiled):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::emitToNumber):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_toNumber):
        (JSC::UnaryPlusNode::emitBytecode):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGBackwardsPropagationPhase.cpp:
        (JSC::DFG::BackwardsPropagationPhase::propagate):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::attemptToInlineCall):
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        (JSC::DFG::ByteCodeParser::parseBlock):
        We use `getPrediction()` to retrieve the heap prediction from the to_number bytecode.
        According to the benchmark results, choosing `getPredictionWithoutOSRExit()` causes performance regression (1.5%) in kraken stanford-crypto-aes.

        * 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):
        (JSC::DFG::FixupPhase::fixupToNumber):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasHeapPrediction):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        Always on the heap prediction.

        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        As of 64bit version, we carefully manage the register reuse. The largest difference between 32bit and 64bit is
        `branchIfNotNumber()` requires the temporary register. We should not use the result registers for that since
        it may be reuse the argument registers and it can break the argument registers before using them to call the operation.
        Currently, we allocate the additional temporary register for that scratch register.

        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        Reuse the argument register for the result if possible. And manually decrement the use count in the middle of the node.
        This is similar technique used in ToPrimitive. Typically, the child of ToNumber is only used by this ToNumber node since
        we would like to perform the type conversion onto this child node here. So this careful register reuse effectively removes
        the spills to call the operation. The example of the actually emitted code is the following.

        76:<!2:loc11>     ToNumber(Untyped:@68, JS|MustGen|UseAsOther, DoubleimpurenanTopEmpty, R:World, W:Heap, Exits, ClobbersExit, bc#48)  predicting DoubleimpurenanTopEmpty
            0x7f986d5fe693: test %rax, %r14
            0x7f986d5fe696: jz 0x7f986d5fe6a1
            0x7f986d5fe69c: jmp 0x7f986d5fe6d1
            0x7f986d5fe6a1: mov %rax, %rsi
            0x7f986d5fe6a4: mov %rbp, %rdi
            0x7f986d5fe6a7: mov $0x2, 0x24(%rbp)
            0x7f986d5fe6ae: mov $0x7f98711ea5f0, %r11
            0x7f986d5fe6b8: call *%r11
            0x7f986d5fe6bb: mov $0x7f982d3f72d0, %r11
            0x7f986d5fe6c5: mov (%r11), %r11
            0x7f986d5fe6c8: test %r11, %r11
            0x7f986d5fe6cb: jnz 0x7f986d5fe88c

        It effectively removes the unnecessary spill to call the operation!

        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileToNumber):
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::branchIfNumber):
        (JSC::AssemblyHelpers::branchIfNotNumber):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_to_number):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_to_number):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * parser/Nodes.h:
        (JSC::UnaryOpNode::opcodeID):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncIsNaN): Deleted.
        (JSC::globalFuncIsFinite): Deleted.
        * runtime/JSGlobalObjectFunctions.h:
        * runtime/MathCommon.h:
        (JSC::maxSafeInteger):
        (JSC::minSafeInteger):
        * runtime/NumberConstructor.cpp:
        (JSC::NumberConstructor::finishCreation):
        (JSC::numberConstructorFuncIsFinite): Deleted.
        (JSC::numberConstructorFuncIsNaN): Deleted.
        * runtime/NumberConstructor.h:
        * tests/stress/Number-isNaN-basics.js: Added.
        (numberIsNaNOnInteger):
        (testNumberIsNaNOnIntegers):
        (verifyNumberIsNaNOnIntegerWithOtherTypes):
        (numberIsNaNOnDouble):
        (testNumberIsNaNOnDoubles):
        (verifyNumberIsNaNOnDoublesWithOtherTypes):
        (numberIsNaNNoArguments):
        (numberIsNaNTooManyArguments):
        (testNumberIsNaNOnConstants):
        (numberIsNaNStructTransition):
        (Number.isNaN):
        * tests/stress/global-is-finite.js: Added.
        (shouldBe):
        * tests/stress/global-is-nan.js: Added.
        (shouldBe):
        * tests/stress/global-isNaN-basics.js: Added.
        (isNaNOnInteger):
        (testIsNaNOnIntegers):
        (verifyIsNaNOnIntegerWithOtherTypes):
        (isNaNOnDouble):
        (testIsNaNOnDoubles):
        (verifyIsNaNOnDoublesWithOtherTypes):
        (verifyIsNaNOnCoercedTypes):
        (isNaNNoArguments):
        (isNaNTooManyArguments):
        (testIsNaNOnConstants):
        (isNaNTypeCoercionSideEffects):
        (i.value.isNaNTypeCoercionSideEffects.valueOf):
        (isNaNStructTransition):
        (isNaN):
        * tests/stress/number-is-finite.js: Added.
        (shouldBe):
        (test2):
        (test3):
        * tests/stress/number-is-nan.js: Added.
        (shouldBe):
        (test2):
        (test3):
        * tests/stress/to-number-basics.js: Added.
        (shouldBe):
        * tests/stress/to-number-convert-identity-without-execution.js: Added.
        (shouldBe):
        (object.valueOf):
        (valueOf):
        * tests/stress/to-number-int52.js: Added.
        (shouldBe):
        (object.valueOf):
        * tests/stress/to-number-intrinsic-convert-to-identity-without-execution.js: Added.
        (shouldBe):
        (object.valueOf):
        (valueOf):
        * tests/stress/to-number-intrinsic-int52.js: Added.
        (shouldBe):
        (object.valueOf):
        * tests/stress/to-number-intrinsic-object-without-execution.js: Added.
        (shouldBe):
        (object.valueOf):
        * tests/stress/to-number-intrinsic-value-profiling.js: Added.
        (shouldBe):
        (object.valueOf):
        * tests/stress/to-number-object-without-execution.js: Added.
        (shouldBe):
        (object.valueOf):
        * tests/stress/to-number-object.js: Added.
        (shouldBe):
        (test12):
        (object1.valueOf):
        (test2):
        (test22):
        (object2.valueOf):
        (test3):
        (test32):
        (object3.valueOf):
        * tests/stress/to-number-value-profiling.js: Added.
        (shouldBe):
        (object.valueOf):

2016-06-29  Benjamin Poulain  <benjamin@webkit.org>

        Fix the debug build after r202667

        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::JSTypedArrayViewPrototype::finishCreation):
        The putDirect was missing the Accessor flag for the GetterSetter.

2016-06-29  Michael Saboff  <msaboff@apple.com>

        REGRESSION(200114): Netflix app does not see ChromeCast
        https://bugs.webkit.org/show_bug.cgi?id=159287

        Reviewed by Benjamin Poulain.

        Change set 200114 changed the behavior of how we check for whether or not we
        wrap Objective C init methods in JavaScript constructors.  The prior method
        checked the version of JavaScriptCore that was linked with the application.
        If the application was not directly linked with JavaScriptCore the prior
        method indicated that we shouldn't create constructors.  The new method uses
        the SDK the application was compiled with.  Using the new method, an
        application compiled with iOS SDK 8.0 or greater would create constructors
        and not export init methods to JavaScript.  The problem is that an existing
        application that hasn't been recompiled will get a different answer using
        the new method.  We need to come up with a method that works in a compatible
        way with existing programs, but provides a newly compiled program with the
        "is built with SDK N or greater" check.
        
        Added back the prior check of the version of JavaScriptCore the program was
        directly linked against.  However we only use this check if we directly linked
        with JavaScriptCore.  Otherwise we fall through to check against the SDK the
        program was built with.  Changed the iOS SDK version we check
        against to be the new version of iOS, iOS 10.

        This provides compatible behavior for existing programs.  It may be the case
        that some of those programs may require changes when they are rebuilt with the
        iOS 10 SDK or later.

        * API/JSWrapperMap.mm:
        (supportsInitMethodConstructors):

2016-06-29  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Minor TypedArray fixes
        https://bugs.webkit.org/show_bug.cgi?id=159286

        Reviewed by Keith Miller.

        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
        See https://tc39.github.io/ecma262/#sec-%typedarray%

        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::typedArrayViewPrivateFuncLength):
        See https://tc39.github.io/ecma262/#sec-get-%typedarray%.prototype.length

        (JSC::typedArrayViewProtoGetterFuncToStringTag):
        Yep, that's odd.
        See https://tc39.github.io/ecma262/#sec-get-%typedarray%.prototype-@@tostringtag

        (JSC::JSTypedArrayViewPrototype::finishCreation):
        See the last paragraph of https://tc39.github.io/ecma262/#sec-ecmascript-standard-built-in-objects

2016-06-29  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: API View of Native DOM APIs looks poor (TypeErrors for native getters)
        https://bugs.webkit.org/show_bug.cgi?id=158334
        <rdar://problem/26615366>

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.prototype._getProperties):
        (InjectedScript.prototype._propertyDescriptors):
        Do not create fake value property descriptors for native accessors
        unless requested. This means, getProperties for a native prototype
        should return  accessors for native accessors just like it does
        for normal non-native accessors (getters/setters).

        (InjectedScript.prototype.getProperties):
        Do not produce fake value accessors for native accessors.

        (InjectedScript.prototype.getDisplayableProperties):
        (InjectedScript.RemoteObject.prototype._generatePreview):
        Do produce fake value accessors for native accessors.

2016-06-29  Saam barati  <sbarati@apple.com>

        JSGlobalLexicalEnvironment needs a toThis implementation
        https://bugs.webkit.org/show_bug.cgi?id=159285

        Reviewed by Mark Lam.

        This was a huge oversight of my original implementation. It gave users
        of the language direct access to the JSGlobalLexicalEnvironment object.

        * runtime/JSGlobalLexicalEnvironment.cpp:
        (JSC::JSGlobalLexicalEnvironment::isConstVariable):
        (JSC::JSGlobalLexicalEnvironment::toThis):
        * runtime/JSGlobalLexicalEnvironment.h:
        (JSC::JSGlobalLexicalEnvironment::isEmpty):
        * tests/stress/global-lexical-environment-to-this.js: Added.
        (assert):
        (let.f):
        (let.fStrict):

2016-06-29  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Wrong function name next to scope
        https://bugs.webkit.org/show_bug.cgi?id=158210
        <rdar://problem/26543093>

        Reviewed by Brian Burg.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        Add DebuggerLocation. A helper for describing a unique location.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::setConstantRegisters):
        When compiled with debug info, add a SymbolTable rare data pointer
        back to the CodeBlock. This will be used later to get JSScope debug
        info if Web Inspector pauses.

        * runtime/SymbolTable.h:
        * runtime/SymbolTable.cpp:
        (JSC::SymbolTable::cloneScopePart):
        (JSC::SymbolTable::prepareForTypeProfiling):
        (JSC::SymbolTable::uniqueIDForVariable):
        (JSC::SymbolTable::uniqueIDForOffset):
        (JSC::SymbolTable::globalTypeSetForOffset):
        (JSC::SymbolTable::globalTypeSetForVariable):
        Rename rareData and include a CodeBlock pointer.

        (JSC::SymbolTable::rareDataCodeBlock):
        (JSC::SymbolTable::setRareDataCodeBlock):
        Setter and getter for the rare data. It should only be set once.

        (JSC::SymbolTable::visitChildren):
        Visit the rare data code block if we have one.

        * debugger/DebuggerLocation.cpp: Added.
        (JSC::DebuggerLocation::DebuggerLocation):
        * debugger/DebuggerLocation.h: Added.
        (JSC::DebuggerLocation::DebuggerLocation):
        Construction from a ScriptExecutable.

        * runtime/JSScope.cpp:
        (JSC::JSScope::symbolTable):
        * runtime/JSScope.h:
        * debugger/DebuggerScope.h:
        * debugger/DebuggerScope.cpp:
        (JSC::DebuggerScope::name):
        (JSC::DebuggerScope::location):
        Name and location for a scope. This uses:
        JSScope -> SymbolTable -> CodeBlock -> Executable

        * inspector/protocol/Debugger.json:
        * inspector/InjectedScriptSource.js:
        (InjectedScript.CallFrameProxy.prototype._wrapScopeChain):
        (InjectedScript.CallFrameProxy._createScopeJson):
        * inspector/JSJavaScriptCallFrame.cpp:
        (Inspector::valueForScopeType):
        (Inspector::valueForScopeLocation):
        (Inspector::JSJavaScriptCallFrame::scopeDescriptions):
        (Inspector::JSJavaScriptCallFrame::scopeType): Deleted.
        * inspector/JSJavaScriptCallFrame.h:
        * inspector/JSJavaScriptCallFramePrototype.cpp:
        (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
        (Inspector::jsJavaScriptCallFramePrototypeFunctionScopeDescriptions):
        (Inspector::jsJavaScriptCallFramePrototypeFunctionScopeType): Deleted.
        Simplify this code to build the objects we will send across the protocol
        to descript a Scope.

2016-06-29  Saam barati  <sbarati@apple.com>

        We don't emit TDZ checks for call_eval
        https://bugs.webkit.org/show_bug.cgi?id=159277
        <rdar://problem/27018801>

        Reviewed by Benjamin Poulain.

        This is a problem if you're trying to call a TDZ variable
        that is named 'eval'.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::EvalFunctionCallNode::emitBytecode):
        * tests/stress/variable-named-eval-under-tdz.js: Added.
        (shouldThrowTDZ):
        (test):
        (test.foo):
        (throw.new.Error):

2016-06-29  Mark Lam  <mark.lam@apple.com>

        Add support for collecting cumulative LLINT stats via a JSC_llintStatsFile option.
        https://bugs.webkit.org/show_bug.cgi?id=159274

        Reviewed by Keith Miller.

        * jsc.cpp:
        (main):
        * llint/LLIntData.cpp:
        (JSC::LLInt::initialize):
        (JSC::LLInt::Data::finalizeStats):
        (JSC::LLInt::compareStats):
        (JSC::LLInt::Data::dumpStats):
        (JSC::LLInt::Data::ensureStats):
        (JSC::LLInt::Data::loadStats):
        (JSC::LLInt::Data::resetStats):
        (JSC::LLInt::Data::saveStats):
        * llint/LLIntData.h:
        (JSC::LLInt::Data::opcodeStats):
        * runtime/Options.cpp:
        (JSC::Options::isAvailable):
        (JSC::recomputeDependentOptions):
        (JSC::Options::initialize):
        * runtime/Options.h:

2016-06-29  Saam barati  <sbarati@apple.com>

        Destructuring variable declaration is missing a validation of the syntax of a sub production when there is a rhs
        https://bugs.webkit.org/show_bug.cgi?id=159267

        Reviewed by Mark Lam.

        We were parsing something without checking if it had a syntax error.
        This is wrong for many reasons, but it could actually cause a crash
        in a debug build if you parsed particular programs.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseVariableDeclarationList):

2016-06-29  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Show Shadow Root type in DOM Tree
        https://bugs.webkit.org/show_bug.cgi?id=159236
        <rdar://problem/27068521>

        Reviewed by Timothy Hatcher.

        * inspector/protocol/DOM.json:
        Include optional shadowRootType property for DOMNodes.

2016-06-29  Commit Queue  <commit-queue@webkit.org>

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

        patch is broken on arm (Requested by keith_miller on #webkit).

        Reverted changeset:

        "LLInt should support other types of prototype GetById
        caching."
        https://bugs.webkit.org/show_bug.cgi?id=158083
        http://trac.webkit.org/changeset/202627

2016-06-29  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Fix small issues of TypedArray prototype
        https://bugs.webkit.org/show_bug.cgi?id=159248

        Reviewed by Saam Barati.

        First, TypedArray's toString and Array's toString
        should be the same function.
        I moved the function to GlobalObject and each array type
        gets it as needed.

        Then TypedArray length was supposed to be configurable.
        I removed the "DontDelete" flag accordingly.

        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::arrayProtoToStringFunction):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::JSTypedArrayViewPrototype::finishCreation):

2016-06-29  Caio Lima  <ticaiolima@gmail.com>

        LLInt should support other types of prototype GetById caching.
        https://bugs.webkit.org/show_bug.cgi?id=158083

        Recently, we started supporting prototype load caching for get_by_id
        in the LLInt. This patch is expading the caching strategy to enable
        cache the prototype accessor and custom acessors.

        Similarly to the get_by_id_proto_load bytecode, we are adding new
        bytecodes called get_by_id_proto_accessor that uses the calculated
        offset of a object to call a getter function and get_by_id_proto_custom
        that stores the pointer to the custom function and call them directly
        from LowLevelInterpreter.

        Reviewed by Keith Miller

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::printGetByIdOp):
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::finalizeLLIntInlineCaches):
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFromLLInt):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::setupGetByIdPrototypeCache):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

2016-06-28  Commit Queue  <commit-queue@webkit.org>

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

        Caused all WKTR tests to fail on GuardMalloc and Production
        only for unknown reasons, investigating offline. (Requested by
        brrian on #webkit).

        Reverted changeset:

        "RunLoop::Timer should use constructor templates instead of
        class templates"
        https://bugs.webkit.org/show_bug.cgi?id=159153
        http://trac.webkit.org/changeset/202580

2016-06-28  Keith Miller  <keith_miller@apple.com>

        We should not crash there is a finally inside a for-in loop
        https://bugs.webkit.org/show_bug.cgi?id=159243
        <rdar://problem/27018910>

        Reviewed by Benjamin Poulain.

        Previously we would swap the m_forInContext with an empty vector
        then attempt to shrink the size of m_forInContext by the amount
        we expected. This meant that if there was more than one ForInContext
        on the stack and we wanted to pop exactly one off we would crash.
        This patch makes ForInContexts RefCounted so they can be duplicated
        into other vectors. It also has ForInContexts copy the entire stack
        rather than do the swap that we did before. This makes ForInContexts
        work the same as the other contexts.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitComplexPopScopes):
        (JSC::BytecodeGenerator::pushIndexedForInScope):
        (JSC::BytecodeGenerator::pushStructureForInScope):
        * bytecompiler/BytecodeGenerator.h:
        * tests/stress/finally-for-in.js: Added.
        (repeat):
        (createSimple):

2016-06-28  Saam Barati  <sbarati@apple.com>

        Assertion failure or crash when accessing let-variable in TDZ with eval with a function in it that returns let variable
        https://bugs.webkit.org/show_bug.cgi?id=158796
        <rdar://problem/26984659>

        Reviewed by Michael Saboff.

        There was a bug where some functions inside of an eval were
        omitting a necessary TDZ check. This obviously leads to bad
        things because a variable under TDZ is the null pointer.
        The eval's bytecode was generated with the correct TDZ set, but 
        it created all its functions before pushing that TDZ set onto
        the stack. That's a mistake. Those functions need to be created with
        that TDZ set. The solution is simple, the TDZ set that the eval
        is created with needs to be pushed onto the TDZ stack before
        the eval creates any functions.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * tests/stress/variable-under-tdz-eval-tricky.js: Added.
        (assert):
        (throw.new.Error):
        (assert.try.underTDZ):

2016-06-28  Michael Saboff  <msaboff@apple.com>

        REGRESSION (r200946): Improper backtracking from last alternative in sticky patterns
        https://bugs.webkit.org/show_bug.cgi?id=159233

        Reviewed by Mark Lam.

        Jump to fail exit code when the last alternative of a sticky pattern fails.

        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::backtrack):

2016-06-28  Saam Barati  <sbarati@apple.com>

        some Watchpoints' ::fireInternal method will call operations that might GC where the GC will cause the watchpoint itself to destruct
        https://bugs.webkit.org/show_bug.cgi?id=159198
        <rdar://problem/26302360>

        Reviewed by Filip Pizlo.

        Firing a watchpoint may cause a GC to happen. This GC could destroy various
        Watchpoints themselves while they're in the process of firing. It's not safe
        for most Watchpoints to be destructed while they're in the middle of firing.
        This GC could also destroy the WatchpointSet itself, and it's not in a safe
        state to be destroyed. WatchpointSet::fireAllWatchpoints now defers gc for a
        while. This prevents a GC from destructing any Watchpoints while they're
        in the process of firing. This bug was being hit by the stress GC bots
        because we would destruct a particular Watchpoint while it was firing,
        and then we would access its field after it had already been destroyed.
        This was causing all kinds of weird symptoms. Also, this was easier to
        catch when running with guard malloc because the first access after
        destruction would lead to a crash.

        * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        * bytecode/VariableWriteFireDetail.cpp:
        (JSC::VariableWriteFireDetail::dump):
        (JSC::VariableWriteFireDetail::touch):
        * bytecode/VariableWriteFireDetail.h:
        * bytecode/Watchpoint.cpp:
        (JSC::WatchpointSet::add):
        (JSC::WatchpointSet::fireAllSlow):
        (JSC::WatchpointSet::fireAllWatchpoints):
        (JSC::InlineWatchpointSet::add):
        (JSC::InlineWatchpointSet::fireAll):
        (JSC::InlineWatchpointSet::inflateSlow):
        * bytecode/Watchpoint.h:
        (JSC::WatchpointSet::startWatching):
        (JSC::WatchpointSet::fireAll):
        (JSC::WatchpointSet::touch):
        (JSC::WatchpointSet::invalidate):
        (JSC::WatchpointSet::isBeingWatched):
        (JSC::WatchpointSet::offsetOfState):
        (JSC::WatchpointSet::addressOfSetIsNotEmpty):
        (JSC::InlineWatchpointSet::startWatching):
        (JSC::InlineWatchpointSet::fireAll):
        (JSC::InlineWatchpointSet::invalidate):
        (JSC::InlineWatchpointSet::touch):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * dfg/DFGOperations.cpp:
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        * jit/JITOperations.cpp:
        * jsc.cpp:
        (WTF::Masquerader::create):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/ArrayBufferNeuteringWatchpoint.cpp:
        (JSC::ArrayBufferNeuteringWatchpoint::fireAll):
        * runtime/FunctionRareData.cpp:
        (JSC::FunctionRareData::clear):
        * runtime/InferredType.cpp:
        (JSC::InferredType::willStoreValueSlow):
        (JSC::InferredType::makeTopSlow):
        (JSC::InferredType::set):
        (JSC::InferredType::removeStructure):
        (JSC::InferredType::InferredStructureWatchpoint::fireInternal):
        * runtime/InferredValue.cpp:
        (JSC::InferredValue::notifyWriteSlow):
        (JSC::InferredValue::ValueCleanup::finalizeUnconditionally):
        * runtime/InferredValue.h:
        (JSC::InferredValue::notifyWrite):
        (JSC::InferredValue::invalidate):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::haveABadTime):
        * runtime/JSSymbolTableObject.h:
        (JSC::symbolTablePutTouchWatchpointSet):
        (JSC::symbolTablePutInvalidateWatchpointSet):
        * runtime/Structure.cpp:
        (JSC::Structure::didCachePropertyReplacement):
        (JSC::Structure::startWatchingInternalProperties):
        (JSC::DeferredStructureTransitionWatchpointFire::~DeferredStructureTransitionWatchpointFire):
        (JSC::DeferredStructureTransitionWatchpointFire::add):
        (JSC::Structure::didTransitionFromThisStructure):
        (JSC::Structure::prototypeForLookup):
        * runtime/StructureInlines.h:
        (JSC::Structure::didReplaceProperty):
        (JSC::Structure::propertyReplacementWatchpointSet):
        * runtime/SymbolTable.h:
        (JSC::SymbolTableEntry::isDontEnum):
        (JSC::SymbolTableEntry::disableWatching):
        * runtime/VM.cpp:
        (JSC::VM::addImpureProperty):
        (JSC::enableProfilerWithRespectToCount):

2016-06-28  Filip Pizlo  <fpizlo@apple.com>

        JSRopeString should use release asserts, not debug asserts, about substring bounds
        https://bugs.webkit.org/show_bug.cgi?id=159227

        Reviewed by Saam Barati.
        
        According to my experiments this change costs nothing.  That's not surprising since the
        most common way to construct a rope these days is inlined into the JIT, which does its own
        safety checks.  This makes us crash sooner rather than corrupting memory.

        * runtime/JSString.h:

2016-06-28  Brian Burg  <bburg@apple.com>

        RunLoop::Timer should use constructor templates instead of class templates
        https://bugs.webkit.org/show_bug.cgi?id=159153

        Reviewed by Alex Christensen.

        Remove the RunLoop::Timer class template argument, and pass its constructor
        a reference to `this` instead of a pointer to `this`.

        * inspector/agents/InspectorHeapAgent.cpp:
        (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):

2016-06-28  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: selectElement.options shows unexpected entries in console (named indexes beyond collection length)
        https://bugs.webkit.org/show_bug.cgi?id=159192

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.prototype.arrayIndexPropertyNames):
        Start with an empty array because we just push valid indexes.

        (InjectedScript.prototype._propertyDescriptors):
        Avoid the >100 length requirement, and always treat the
        array-like objects the same. The frontend currently
        doesn't show named indexes for arrays anyways, so they
        would have been unused.

2016-06-28  Per Arne Vollan  <pvollan@apple.com>

        [Win] Skip failing INTL test.
        https://bugs.webkit.org/show_bug.cgi?id=159141

        Reviewed by Brent Fulgham.

        INTL is not enabled on Windows.

        * tests/stress/intl-constructors-with-proxy.js:
        (shouldBe):

2016-06-28  Joonghun Park  <jh718.park@samsung.com>

        [JSC] Fix build break since r202502 - 2
        https://bugs.webkit.org/show_bug.cgi?id=159194

        Reviewed by Gyuyoung Kim.

        Fix about the error message below.
        error: control reaches end of non-void function [-Werror=return-type]

        * b3/B3TypeMap.h: add #pragma GCC diagnostic ignored "-Wreturn-type".

2016-06-28  Joonghun Park  <jh718.park@samsung.com>

        [JSC] Fix build break since r202502
        https://bugs.webkit.org/show_bug.cgi?id=159194

        Reviewed by Alex Christensen.

        Fix about the error message below.
        error: control reaches end of non-void function [-Werror=return-type]

        * b3/B3TypeMap.h:
        (JSC::B3::TypeMap::at): add missing ASSERT_NOT_REACHED().

2016-06-27  Keith Miller  <keith_miller@apple.com>

        Fix bad assert in StructureRareData::setObjectToStringValue
        https://bugs.webkit.org/show_bug.cgi?id=159171
        <rdar://problem/26987355>

        Reviewed by Mark Lam.

        We should not have expected the generateConditionsForPrototypePropertyHit would succeed.
        There are many reasons it might fail including that there is a proxy somewhere on the
        prototype chain of the object.

        * runtime/StructureRareData.cpp:
        (JSC::StructureRareData::setObjectToStringValue):
        * tests/stress/object-toString-with-proxy.js: Added.
        (get target):

2016-06-27  Filip Pizlo  <fpizlo@apple.com>

        Crashing at an unreachable code trap in FTL should give more information
        https://bugs.webkit.org/show_bug.cgi?id=159177

        Reviewed by Saam Barati.
        
        This stuffs information into registers so that we have some chance of seeing what happened
        by looking at the register dumps.

        * assembler/AbortReason.h:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::ftlUnreachable):
        (JSC::FTL::DFG::LowerDFGToB3::compileBlock):
        (JSC::FTL::DFG::LowerDFGToB3::crash):

2016-06-27  Filip Pizlo  <fpizlo@apple.com>

        Clean up resetting reachability in B3/Air
        https://bugs.webkit.org/show_bug.cgi?id=159170

        Reviewed by Geoffrey Garen.
        
        When I fixed bug 159165, I took the brute force approach. I still used the
        B3::resetReachability() method, and changed the callback to record the set of deleted values
        instead of deleting them eagerly. But this means tracking the set of deleted values, even
        though resetReachability() already internally tracks the set of deleted blocks. You can find
        out if a value is deleted by asking if its owning block was deleted.
        
        So, this change refactors B3::resetReachability() into a new helper called
        B3::recomputePredecessors(). This new helper skips the block deletion step, and lets the
        client delete blocks. This lets Air delete blocks the same way that it did before, and it
        lets B3 use the isBlockDead() method (which is a glorified proxy for
        block->predecessors().isEmpty()) to track which values are deleted. This allows B3 to turn
        Upsilons that point to dead Phis into Nops before deleting the blocks.
        
        This shouldn't affect performance or anything real. It just makes the code cleaner.

        * b3/B3BasicBlockUtils.h:
        (JSC::B3::updatePredecessorsAfter):
        (JSC::B3::recomputePredecessors):
        (JSC::B3::isBlockDead):
        (JSC::B3::resetReachability): Deleted.
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::resetReachability):
        (JSC::B3::Procedure::invalidateCFG):
        * b3/air/AirCode.cpp:
        (JSC::B3::Air::Code::resetReachability):
        (JSC::B3::Air::Code::dump):

2016-06-27  Brian Burg  <bburg@apple.com>

        Web Inspector: CRASH in backend at Inspector::HeapFrontendDispatcher::garbageCollected + 552 when closing frontend/inspected page
        https://bugs.webkit.org/show_bug.cgi?id=159075
        <rdar://problem/26094341>

        Reviewed by Filip Pizlo.

        This change caused JSC stress tests to all hit an assertion in RunLoop.
        We should use RunLoop::current() to create the RunLoop::Timer since JSC-only
        clients like testapi and jsc don't ever call initializeMainRunLoop().

        * inspector/agents/InspectorHeapAgent.cpp:
        (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):

2016-06-27  Filip Pizlo  <fpizlo@apple.com>

        B3::Procedure::resetReachability() can create dangling references from Upsilons to Phis
        https://bugs.webkit.org/show_bug.cgi?id=159165

        Reviewed by Mark Lam.
        
        You can delete an unreachable block that has a Phi but some prior block may still have an
        Upsilon pointing to that Phi. This can happen if the Upsilon precedes a Check that always
        exits or it can happen if we remove some successor of a block and this block had an Upsilon
        for one of the removed successors. These things are valid IR even if they are not canonical.
        Our policy for not-canonical-but-valid IR is that the compiler should still emit valid code
        in the end.
        
        The solution is to have Procedure::resetReachability() turn those Upsilons into Nops.

        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::resetReachability): Fix the bug.
        * b3/B3Validate.h:
        * b3/testb3.cpp:
        (JSC::B3::testResetReachabilityDanglingReference): Add a test. This always crashes prior to this change.
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::killUnreachableBlocks): Add a FIXME about a possible similar bug.

2016-06-27  Keith Miller  <keith_miller@apple.com>

        Add comment to Module feature in features.json
        https://bugs.webkit.org/show_bug.cgi?id=159159

        Reviewed by Saam Barati.

        * features.json:

2016-06-27  Keith Miller  <keith_miller@apple.com>

        Update features.json for ES6 completed features.
        https://bugs.webkit.org/show_bug.cgi?id=159152

        Reviewed by Mark Lam.

        * features.json:

2016-06-25  Filip Pizlo  <fpizlo@apple.com>

        B3 should not use Nops when deleting unreachable code
        https://bugs.webkit.org/show_bug.cgi?id=159120
        rdar://problem/26500743

        Reviewed by Michael Saboff.
        
        Prior to this change, transformations that obviated the need for some value could choose
        from these ways to kill it:
        
        - replaceWithIdentity() if we're replacing with another value.
        - replaceWithNop() if the type is Void or if we know that we'll fix any users of this
          value.
        - deleteValue() if the code is unreachable.
        
        The bug here is that reduceStrength() was being clever about how to get rid of a value.
        reduceStrength() may find a Check that must always exit. The goal is to remove any code
        dominated by the Check. But it would be awkward to eagerly delete all of the blocks
        dominated by this one. So this code took a much simpler approach: it would
        replaceWithNop() for all of the values in this block after the Check and it would replace
        the terminal with Oops.
        
        But this corrupts the IR in a subtle way: some of those values may have been non-Void but
        now they are Nops so they are Void. reduceStrength() will not yet realize that the blocks
        dominated by the one with the Check are unreachable, so it will run all sorts of
        optimizations on those blocks. This could have probably manifested as many different kinds
        of badness, but the way I found out about this issue was through a crash in
        IntRange::top(Type) when inlined into ReduceStrength::rangeFor(). We'd die in a switch
        statement over a child's type.
        
        We could fix this by making rangeFor() tolerate Void. But I think that this would be
        dangerous. There could easily be other places in reduceStrength() that assume that value's
        children are non-Void. So, this change fixes the Check optimization and adds mechanisms to
        prevent other optimizations from breaking the children-are-not-Void rule.
        
        This introduces two high-level changes:
        
        - It's no longer legal to replaceWithNop() if the value is not Void. This change alone
          would cause reduceStrength() to instacrash in its Check optimization. Almost all other
          uses of replaceWithNop() were already following this rule, so they were fine. One other
          place was using replaceWithNop() on non-Void values after arranging for them to no
          longer have any parents. That was changed to call replaceWithNopIgnoringType(), which
          doesn't have any type assertions.
        
        - For reduceStrength() there is a new Value::replaceWithBottom() method that works with
          Void or non-Void and behaves like you would want replaceWithNop() to behave: if you know
          that the code is unreachable then it produces something that is guaranteed to be deleted
          by later optimizations, and if it's not unreachable, then it's guaranteed to be compiled
          to something harmless and cheap. This means replacing the value with an identity that
          points to a bottom constant (the 0 for whatever type we have), or just replacing it with
          Nop if it's Void.
        
        This also adds a test case for the reason why we do this: we may have two blocks, where
        the first block unconditionally exits while dominating the second block. The second block
        references values in the part of the first block that is unreachable. In trunk, this test
        would assert in ReduceStrength::rangeFor() because the CheckAdd in the second block would
        reference a Nop in the first block.
        
        This fixes a high volume crash in ReduceStrength::rangeFor(). This crash was very
        confusing. Even though we were crashing at a RELEASE_ASSERT_NOT_REACHED() in a switch
        statement in IntRange::top(Type), clang was merging that trap with the trap it used for
        Vector OOB. The top of the stack in crash dumps looked like:
        
            JSC::B3::(anonymous namespace)::ReduceStrength::rangeFor(JSC::B3::Value*, unsigned int) + 4477 (Vector.h:655)
        
        Where Vector.h:655 is:
        
            OverflowHandler::overflowed();

        But this crash was not at Vector.h:655. It was at B3ReduceStrength.cpp:121. The two lines
        are both traps, so they got merged despite differences in debug info. This bug would have
        been so much easier to fix if I had the right line number.

        * b3/B3BottomProvider.h: Added. This is a utility for creating bottom values.
        (JSC::B3::BottomProvider::BottomProvider):
        (JSC::B3::BottomProvider::operator()):
        * b3/B3InsertionSet.cpp: Optimized adding bottom values a bit. We will no longer create pointless duplicates.
        (JSC::B3::InsertionSet::insertBottom):
        (JSC::B3::InsertionSet::execute):
        (JSC::B3::InsertionSet::bottomForType):
        * b3/B3InsertionSet.h:
        * b3/B3MoveConstants.cpp: Use replaceWithNopIgnoringType() because we *know* that we can replaceWithNop even for non-Void.
        * b3/B3Procedure.h:
        * b3/B3ReduceStrength.cpp: Use replaceWithBottom().
        * b3/B3ReduceStrength.h:
        * b3/B3TypeMap.h: I figured if I wrote type-casing code like this once then I'd never want to write it again.
        * b3/B3Value.cpp:
        (JSC::B3::Value::replaceWithIdentity):
        (JSC::B3::Value::replaceWithNop):
        (JSC::B3::Value::replaceWithNopIgnoringType):
        * b3/B3Value.h:
        * b3/B3ValueInlines.h:
        (JSC::B3::Value::replaceWithBottom): This is the new method of killing unreachable code.
        (JSC::B3::Value::as):
        * b3/testb3.cpp: Add new tests!
        (JSC::B3::testLateRegister):
        (JSC::B3::testReduceStrengthCheckBottomUseInAnotherBlock):
        (JSC::B3::zero):
        (JSC::B3::run):

2016-06-27  Joseph Pecoraro  <pecoraro@apple.com>

        REGRESSION: Web Inspector: Text search broken in resources with <CR>
        https://bugs.webkit.org/show_bug.cgi?id=159110
        <rdar://problem/27008485>

        Reviewed by Brian Burg.

        * inspector/ContentSearchUtilities.cpp:
        (Inspector::ContentSearchUtilities::lineEndings):
        The frontend moved to only treated newlines as line endings in
        the TextEditor. The backend however was looking for many
        different types of line endings (\r\n, \r, \n). This caused
        the line endings to ultimately differ between the frontend
        and the backend, so the frontend couldn't find the lines that
        the backend was claiming search results were on. Change the
        backend to only look for \n line endings.

2016-06-27  Brian Burg  <bburg@apple.com>

        Web Inspector: CRASH in backend at Inspector::HeapFrontendDispatcher::garbageCollected + 552 when closing frontend/inspected page
        https://bugs.webkit.org/show_bug.cgi?id=159075
        <rdar://problem/26094341>

        Reviewed by Timothy Hatcher.

        Move the asynchronous work to a task class that can be cancelled when the
        heap agent is reset, disabled or destroyed.

        * inspector/agents/InspectorHeapAgent.cpp:
        (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):
        (Inspector::SendGarbageCollectionEventsTask::addGarbageCollection):
        (Inspector::SendGarbageCollectionEventsTask::reset):
        (Inspector::SendGarbageCollectionEventsTask::timerFired):
        Added. This holds onto GarbageCollectionData that needs to be sent asynchronously.
        It uses the RunLoop variant of Timer and can queue multiple collections to be sent.
        The data vector is guarded with a lock so that garbageCollected() can safely add
        collection data from a non-main thread while the main thread sends out events.

        (Inspector::InspectorHeapAgent::InspectorHeapAgent):
        (Inspector::InspectorHeapAgent::~InspectorHeapAgent):
        (Inspector::InspectorHeapAgent::disable):
        Reset the task when disabling or tearing down the agent so the timer doesn't fire after destruction.

        (Inspector::InspectorHeapAgent::didGarbageCollect):
        Add the collection data to the task, which will dispatch an event for it asynchronously.

        * inspector/agents/InspectorHeapAgent.h:

2016-06-27  Michael Saboff  <msaboff@apple.com>

        ES6 Change: Unify handling of RegExp CharacterClassEscapes \w and \W and Word Asserts \b and \B
        https://bugs.webkit.org/show_bug.cgi?id=158505

        Reviewed by Geoffrey Garen.

        This change makes it so that the CharacterClassEscape \w matches the inverse of
        \W and vice versa for unicode, ignore case RegExp's.

        Before this change, both /\w/ui and /\W/ui RegExp's would match the characters
        k, K, s, S, \u017f (Latin Small Letter Long S) and \u212a (Kelvin Sign).
        This was due to how the ES6 standard defined matching of character classes
        specifically that the abstract operation "Canonicalize()" is called for the
        character to be matched AND for the characters in the character class we are
        matching against.  This change is to make \W always be the inverse of \w.
        It is still the case that the characters that match against \w changes
        depending on a regular expression's flags.

        The only real changes occur for regular expressions with both the unicode and
        ignore case flags set.  Updated the character class generator to make 
        nonwordUnicodeIgnoreCaseChar not include k, K, s, S, \u017f and \u212a.
        Changed BytecodePattern.wordcharCharacterClass to use the correct
        word character class for the flags.  Simplfied character class set up in
        in the pattern to use m_pattern.wordUnicodeIgnoreCaseCharCharacterClass and
        invert as appropriate when unicode and ignore case are both set.

        * create_regex_tables:
        * yarr/YarrInterpreter.h:
        (JSC::Yarr::BytecodePattern::BytecodePattern):
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::YarrPatternConstructor::atomBuiltInCharacterClass):

2016-06-25  Keith Miller  <keith_miller@apple.com>

        DFGByteCodeParsing does not handle calling the Object constructor with no arguments correctly
        https://bugs.webkit.org/show_bug.cgi?id=159117
        <rdar://problem/26996781>

        Reviewed by Saam Barati.

        DFGByteCodeParsing always assumed there would be an argument to the Object constructor.
        This is clearly not always the case and we should be able to handle it.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        * tests/stress/indirect-call-object-constructor-with-no-arguments.js: Added.
        (let.foo.Object.test):

2016-06-24  Filip Pizlo  <fpizlo@apple.com>

        B3 should die sooner if a Value has the wrong number of children
        https://bugs.webkit.org/show_bug.cgi?id=159108

        Reviewed by Mark Lam.
        
        I've been looking at a bug (rdar://problem/26500743) that's about a Vector OOB crash in
        ReduceStrength::rangeFor(). The only Vector accesses are to Value::m_children, and all of
        the accesses in rangeFor() are for child(0) or child(1) of binary arithmetic opcodes.
        Clearly those should never go out-of-bounds.
        
        Maybe we have horrible memory corruption. Or maybe some path creates a Value with the
        wrong number of children, and that path is not tested by any of our tests. This patch adds
        release assertions that will catch the latter.
        
        I've tested this a lot. It's not a regression on our benchmarks.

        * b3/B3Opcode.h:
        * b3/B3Value.cpp:
        (JSC::B3::Value::dumpMeta):
        (JSC::B3::Value::typeFor):
        (JSC::B3::Value::badOpcode):
        (JSC::B3::Value::checkOpcode): Deleted.
        * b3/B3Value.h:

2016-06-24  Mark Lam  <mark.lam@apple.com>

        [JSC] Error prototypes are called on remote scripts.
        https://bugs.webkit.org/show_bug.cgi?id=52192

        Reviewed by Keith Miller.

        Added a sanitizedToString() to the Error instance object so that it can be used
        to get an error string without invoking getters and proxies.

        * runtime/ErrorInstance.cpp:
        (JSC::ErrorInstance::finishCreation):
        (JSC::ErrorInstance::sanitizedToString):
        * runtime/ErrorInstance.h:
        (JSC::ErrorInstance::createStructure):
        (JSC::ErrorInstance::runtimeTypeForCause):
        (JSC::ErrorInstance::clearRuntimeTypeForCause):

2016-06-24  Commit Queue  <commit-queue@webkit.org>

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

        Introduced memory corruption crashes (Requested by ap on
        #webkit).

        Reverted changeset:

        "Web Inspector: CRASH in backend at
        Inspector::HeapFrontendDispatcher::garbageCollected + 552 when
        closing frontend/inspected page"
        https://bugs.webkit.org/show_bug.cgi?id=159075
        http://trac.webkit.org/changeset/202443

2016-06-24  Brian Burg  <bburg@apple.com>

        Web Inspector: CRASH in backend at Inspector::HeapFrontendDispatcher::garbageCollected + 552 when closing frontend/inspected page
        https://bugs.webkit.org/show_bug.cgi?id=159075
        <rdar://problem/26094341>

        Reviewed by Joseph Pecoraro.

        Move the asynchronous work to a task class that can be cancelled when the
        heap agent is reset, disabled or destroyed.

        * inspector/agents/InspectorHeapAgent.cpp:
        (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):
        (Inspector::SendGarbageCollectionEventsTask::addGarbageCollection):
        (Inspector::SendGarbageCollectionEventsTask::reset):
        (Inspector::SendGarbageCollectionEventsTask::timerFired):
        Added. This holds onto GarbageCollection objects that need to be sent asynchronously.
        It uses the RunLoop variant of Timer and can queue multiple pending objects to be sent.

        (Inspector::InspectorHeapAgent::InspectorHeapAgent):
        (Inspector::InspectorHeapAgent::~InspectorHeapAgent):
        (Inspector::InspectorHeapAgent::disable):
        Reset the task when disabling or tearing down the agent so the timer doesn't fire after destruction.

        (Inspector::InspectorHeapAgent::didGarbageCollect):
        Send the object to the task to be dispatched asynchronously.

        * inspector/agents/InspectorHeapAgent.h:

2016-06-24  Commit Queue  <commit-queue@webkit.org>

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

        Broke many JSC tests (Requested by ap on #webkit).

        Reverted changeset:

        "[JSC] Implement isFinite / isNaN in JS and make DFG ToNumber
        accept non number values"
        https://bugs.webkit.org/show_bug.cgi?id=154022
        http://trac.webkit.org/changeset/202413

2016-06-23  Benjamin Poulain  <bpoulain@apple.com>

        OOM Assertion failure in Array.prototype.toString
        https://bugs.webkit.org/show_bug.cgi?id=158793

        Reviewed by Saam Barati.

        JSString::create() taking a StringImpl was using a signed integer
        for the length of the string.
        The problem is StringImpl uses an unsigned integer. When a large string
        was passed to JSString, the signed integer would be negative and crash
        JSString.

        * runtime/JSString.h:
        (JSC::JSString::create):

2016-06-23  Joseph Pecoraro  <pecoraro@apple.com> and Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Implement isFinite / isNaN in JS and make DFG ToNumber accept non number values
        https://bugs.webkit.org/show_bug.cgi?id=154022

        Reviewed by Filip Pizlo.

        We aim at optimizing @toInteger operation.
        While it still has an unoptimized part[1], this patch should be a first step.

        We introduce the @toNumber builtin intrinsic operation.
        This converts the given value to the JS number by emitting op_to_number bytecode.
        Previously @toInteger called C++ @Number constructor for that purpose.

        And in DFG, op_to_number is converted to DFG ToNumber node.
        During DFG, we attempt to convert this to edge filtering and Identity, but if we fail,
        we just fall back to calling the C++ function.

        To utilize ToNumber in user-land side, we add a path attempting to convert Number constructor calls
        to ToNumber DFG nodes. This conversion is useful because `Number(value)` is used to convert a value to a number in JS.

        Before this patch, we emit simple edge filtering (NumberUse) instead of emitting DFG node like ToNumber for op_to_number.
        But emitting ToNumber is useful, because in the case of `Number(value)`, considering `value` may not be a number is reasonable.

        By leveraging @toNumber operation, we rewrite Number.{isFinite, isNaN}, global.{isFinite, isNaN} and @toInteger.

        ToNumber DFG node has a value profiling. This profiling is leveraged to determine the result number type of the ToNumber operation.
        This value profiling is provided from either NumberConstructor's call operation or op_to_number.

        The results (with the added performance tests) show that, while existing cases are performance neutral, the newly added cases gain the performance benefit.
        And ASMBench/n-body.c also shows stable ~2% progression.

        [1]: https://bugs.webkit.org/show_bug.cgi?id=153738

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/BuiltinNames.h:
        * builtins/GlobalObject.js:
        (globalPrivate.isFinite):
        (globalPrivate.isNaN):
        (globalPrivate.toInteger): Deleted.
        (globalPrivate.toLength): Deleted.
        (globalPrivate.isDictionary): Deleted.
        (globalPrivate.speciesGetter): Deleted.
        (globalPrivate.speciesConstructor): Deleted.
        * builtins/GlobalOperations.js: Copied from Source/JavaScriptCore/builtins/GlobalObject.js.
        (globalPrivate.toInteger):
        (globalPrivate.toLength):
        (globalPrivate.isDictionary):
        (globalPrivate.speciesGetter):
        (globalPrivate.speciesConstructor):
        * builtins/NumberConstructor.js: Added.
        (isFinite):
        (isNaN):
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecode/BytecodeList.json:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::finishCreation):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitUnaryOp):
        (JSC::BytecodeGenerator::emitUnaryOpProfiled):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::emitToNumber):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_toNumber):
        (JSC::UnaryPlusNode::emitBytecode):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::attemptToInlineCall):
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        (JSC::DFG::ByteCodeParser::parseBlock):
        We use `getPrediction()` to retrieve the heap prediction from the to_number bytecode.
        According to the benchmark results, choosing `getPredictionWithoutOSRExit()` causes performance regression (1.5%) in kraken stanford-crypto-aes.

        * 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):
        (JSC::DFG::FixupPhase::fixupToNumber):
        ToNumber tells its predicted type by its heap prediction. So the fixup phase need to consider about it.
        If the heap prediction is Int32, we should attempt to convert the child value to Int32.
        Without this, misc-bugs-847389-jpeg2000 in assorted tests poses 53% regression.

        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasHeapPrediction):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        Alway rely on the heap prediction.

        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        As of 64bit version, we carefully manage the register reuse. The largest difference between 32bit and 64bit is
        `branchIfNotNumber()` requires the temporary register. We should not use the result registers for that since
        it may be reuse the argument registers and it can break the argument registers before using them to call the operation.
        Currently, we allocate the additional temporary register for that scratch register.

        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        Reuse the argument register for the result if possible. And manually decrement the use count in the middle of the node.
        This is similar technique used in ToPrimitive. Typically, the child of ToNumber is only used by this ToNumber node since
        we would like to perform the type conversion onto this child node here. So this careful register reuse effectively removes
        the spills to call the operation. The example of the actually emitted code is the following.

        76:<!2:loc11>     ToNumber(Untyped:@68, JS|MustGen|UseAsOther, DoubleimpurenanTopEmpty, R:World, W:Heap, Exits, ClobbersExit, bc#48)  predicting DoubleimpurenanTopEmpty
            0x7f986d5fe693: test %rax, %r14
            0x7f986d5fe696: jz 0x7f986d5fe6a1
            0x7f986d5fe69c: jmp 0x7f986d5fe6d1
            0x7f986d5fe6a1: mov %rax, %rsi
            0x7f986d5fe6a4: mov %rbp, %rdi
            0x7f986d5fe6a7: mov $0x2, 0x24(%rbp)
            0x7f986d5fe6ae: mov $0x7f98711ea5f0, %r11
            0x7f986d5fe6b8: call *%r11
            0x7f986d5fe6bb: mov $0x7f982d3f72d0, %r11
            0x7f986d5fe6c5: mov (%r11), %r11
            0x7f986d5fe6c8: test %r11, %r11
            0x7f986d5fe6cb: jnz 0x7f986d5fe88c

        It effectively removes the unnecessary spill to call the operation!

        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileToNumber):
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::branchIfNumber):
        (JSC::AssemblyHelpers::branchIfNotNumber):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_to_number):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_to_number):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * parser/Nodes.h:
        (JSC::UnaryOpNode::opcodeID):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncIsNaN): Deleted.
        (JSC::globalFuncIsFinite): Deleted.
        * runtime/JSGlobalObjectFunctions.h:
        * runtime/MathCommon.h:
        (JSC::maxSafeInteger):
        (JSC::minSafeInteger):
        * runtime/NumberConstructor.cpp:
        (JSC::NumberConstructor::finishCreation):
        (JSC::numberConstructorFuncIsFinite): Deleted.
        (JSC::numberConstructorFuncIsNaN): Deleted.
        * runtime/NumberConstructor.h:
        * tests/stress/Number-isNaN-basics.js: Added.
        (numberIsNaNOnInteger):
        (testNumberIsNaNOnIntegers):
        (verifyNumberIsNaNOnIntegerWithOtherTypes):
        (numberIsNaNOnDouble):
        (testNumberIsNaNOnDoubles):
        (verifyNumberIsNaNOnDoublesWithOtherTypes):
        (numberIsNaNNoArguments):
        (numberIsNaNTooManyArguments):
        (testNumberIsNaNOnConstants):
        (numberIsNaNStructTransition):
        (Number.isNaN):
        * tests/stress/global-is-finite.js: Added.
        (shouldBe):
        * tests/stress/global-is-nan.js: Added.
        (shouldBe):
        * tests/stress/global-isNaN-basics.js: Added.
        (isNaNOnInteger):
        (testIsNaNOnIntegers):
        (verifyIsNaNOnIntegerWithOtherTypes):
        (isNaNOnDouble):
        (testIsNaNOnDoubles):
        (verifyIsNaNOnDoublesWithOtherTypes):
        (verifyIsNaNOnCoercedTypes):
        (isNaNNoArguments):
        (isNaNTooManyArguments):
        (testIsNaNOnConstants):
        (isNaNTypeCoercionSideEffects):
        (i.value.isNaNTypeCoercionSideEffects.valueOf):
        (isNaNStructTransition):
        (isNaN):
        * tests/stress/number-is-finite.js: Added.
        (shouldBe):
        (test2):
        (test3):
        * tests/stress/number-is-nan.js: Added.
        (shouldBe):
        (test2):
        (test3):
        * tests/stress/to-number-basics.js: Added.
        (shouldBe):
        * tests/stress/to-number-convert-identity-without-execution.js: Added.
        (shouldBe):
        (object.valueOf):
        (valueOf):
        * tests/stress/to-number-int52.js: Added.
        (shouldBe):
        (object.valueOf):
        * tests/stress/to-number-intrinsic-convert-to-identity-without-execution.js: Added.
        (shouldBe):
        (object.valueOf):
        (valueOf):
        * tests/stress/to-number-intrinsic-int52.js: Added.
        (shouldBe):
        (object.valueOf):
        * tests/stress/to-number-intrinsic-object-without-execution.js: Added.
        (shouldBe):
        (object.valueOf):
        * tests/stress/to-number-intrinsic-value-profiling.js: Added.
        (shouldBe):
        (object.valueOf):
        * tests/stress/to-number-object-without-execution.js: Added.
        (shouldBe):
        (object.valueOf):
        * tests/stress/to-number-object.js: Added.
        (shouldBe):
        (test12):
        (object1.valueOf):
        (test2):
        (test22):
        (object2.valueOf):
        (test3):
        (test32):
        (object3.valueOf):
        * tests/stress/to-number-value-profiling.js: Added.
        (shouldBe):
        (object.valueOf):

2016-06-23  Saam Barati  <sbarati@apple.com>

        DFGSpeculativeJIT's m_slowPathLambdas should restore the current node field and DFG OSR entry functions should use DeferGCForAWhile instead of DeferGC
        https://bugs.webkit.org/show_bug.cgi?id=159064
        <rdar://problem/26599119>

        Reviewed by Filip Pizlo.

        The DFG has a list of m_slowPathLambdas that are code generators it emits
        amongst its slow paths. These lambdas, however, did not update the m_currentNode field.
        This caused us to use whatever Node happened to be used as the currentNode at the time
        we call the slowPathLambda. This means the wrong CallSiteIndex was stored into the call
        frame when we made a call. This may lead to a crash if the CallSiteIndex corresponds to
        the wrong CodeOrigin. For example, the wrong CodeOrigin could have an InlineCallFrame with
        a calleeRecovery that will not be in sync with the current stack state. Trying
        to recover that callee will often lead to a crash. The solution is to update
        m_currentNode to the DFG::Node* it corresponds to when emitting these slowPathLambdas.

        I found this bug because we were inside this bad state when calling an operation
        that happened to have a DeferGC. When this DeferGC actually GCed, it would
        take a StackTrace, which would lead to a crash because we were updating
        ShadowChicken with vm.topCallFrame. It just so happened that the CallSiteIndex
        in the call frame in this program corresponded to an InlineCallFrame with a calleeRecover.
        However, this CallSiteIndex didn't correspond to the actual state of execution
        of the program. I'm adding new options to make reproducing DeferGC related
        bugs easier by making DeferGC force a GC according to some probability. To
        always have DeferGC force a GC, you can set that probability to 1.

        There is a second bug that I discovered after solving the above bug. We were
        using DeferGC instead of DeferGCForAWhile in the OSR entry related functions
        in the DFG. This would cause us to take a stack trace when the call frame was
        in an inconsistent state. For example, the operation would call FTL::prepareOSREntry,
        which would replace the DFG CodeBlock in the call frame with the FTL CodeBlock.
        However, we wouldn't update the CallSiteIndex to correspond to an FTL CallSiteIndex.
        This would lead to a crash when taking a stack trace. The solution is to prevent
        stack traces from being taken when the program is in this state by using
        DeferGCForAWhie instead of DeferGC.

        * dfg/DFGOperations.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::addSlowPathGenerator):
        (JSC::DFG::SpeculativeJIT::runSlowPathGenerators):
        * dfg/DFGSpeculativeJIT.h:
        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::collectIfNecessaryOrDefer):
        (JSC::Heap::collectAccordingToDeferGCProbability):
        (JSC::Heap::decrementDeferralDepthAndGCIfNeeded):
        (JSC::Heap::markListSet):
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):
        (JSC::Options::initialize):
        * runtime/Options.h:
        * tests/stress/slow-path-generator-updating-current-node-dfg.js: Added.
        (foo):
        (bar):

2016-06-23  Filip Pizlo  <fpizlo@apple.com>

        Failing baseline JIT compilation of a code block and then trying to compile it from OSR from DFG/FTL will corrupt the CodeBlock
        https://bugs.webkit.org/show_bug.cgi?id=158806

        Reviewed by Saam Barati.
        
        If we try to compile a CodeBlock that we already tried compiling in the past then we need
        to clean up the data structures that were partly filled in by the failed compile. That
        causes some races, since the DFG may be trying to parse those data structures while we are
        clearing them. This patch introduces such a clean-up (CodeBlock::resetJITData()) and fixes
        the races.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::getStubInfoMap):
        (JSC::CodeBlock::getCallLinkInfoMap):
        (JSC::CodeBlock::getByValInfoMap):
        (JSC::CodeBlock::getCallLinkInfoForBytecodeIndex):
        (JSC::CodeBlock::resetJITData):
        (JSC::CodeBlock::visitOSRExitTargets):
        (JSC::CodeBlock::setSteppingMode):
        (JSC::CodeBlock::addRareCaseProfile):
        (JSC::CodeBlock::rareCaseProfileForBytecodeOffset):
        (JSC::CodeBlock::rareCaseProfileCountForBytecodeOffset):
        (JSC::CodeBlock::resultProfileForBytecodeOffset):
        (JSC::CodeBlock::specialFastCaseProfileCountForBytecodeOffset):
        (JSC::CodeBlock::couldTakeSpecialFastCase):
        (JSC::CodeBlock::ensureResultProfile):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::getFromAllValueProfiles):
        (JSC::CodeBlock::numberOfRareCaseProfiles):
        (JSC::CodeBlock::numberOfResultProfiles):
        (JSC::CodeBlock::numberOfArrayProfiles):
        (JSC::CodeBlock::arrayProfiles):
        (JSC::CodeBlock::addRareCaseProfile): Deleted.
        (JSC::CodeBlock::specialFastCaseProfileCountForBytecodeOffset): Deleted.
        (JSC::CodeBlock::couldTakeSpecialFastCase): Deleted.
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::makeSafe):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
        * jit/JIT.cpp:
        (JSC::JIT::link):
        * jit/JITWorklist.cpp:
        (JSC::JITWorklist::compileNow):

2016-06-23  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Memory Timeline sometimes shows impossible value for bmalloc size (underflowed)
        https://bugs.webkit.org/show_bug.cgi?id=158110
        <rdar://problem/26498584>

        Reviewed by Andreas Kling.

        * heap/Heap.cpp:
        (JSC::Heap::willStartCollection):
        (JSC::Heap::didFinishCollection):
        * heap/Heap.h:
        (JSC::Heap::externalMemorySize):
        * heap/HeapInlines.h:
        (JSC::Heap::reportExternalMemoryVisited):
        Keep count of external memory we visit.

        * heap/SlotVisitor.h:
        * heap/SlotVisitorInlines.h:
        (JSC::SlotVisitor::reportExternalMemoryVisited):
        Report external memory visited like we do extra memory, since
        it will be some subset of extra memory that is external.

2016-06-23  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Snapshots should be cleared at some point
        https://bugs.webkit.org/show_bug.cgi?id=157907
        <rdar://problem/26373610>

        Reviewed by Timothy Hatcher.

        * heap/HeapSnapshotBuilder.h:
        * heap/HeapSnapshotBuilder.cpp:
        (JSC::HeapSnapshotBuilder::resetNextAvailableObjectIdentifier):
        Provide a way to reset the object identifier counter.

        * inspector/agents/InspectorHeapAgent.h:
        * inspector/agents/InspectorHeapAgent.cpp:
        (Inspector::InspectorHeapAgent::clearHeapSnapshots):
        Make clearHeapSnapshots protected, so it can be called from a
        a PageHeapAgent on page navigations.

2016-06-22  Saam barati  <sbarati@apple.com>

        TypeProfiler and TypeProfilerLog don't play nicely with the concurrent JIT
        https://bugs.webkit.org/show_bug.cgi?id=159037
        <rdar://problem/26935349>

        Reviewed by Benjamin Poulain.

        The primary focus of this patch is to make the concurrent
        baseline JIT work with the type profiler. We were clearing
        the type profiler log on the background baseline compiler
        thread which lead to bad things happening. This patch fixes
        this by processing the log before we launch the compile on
        a background thread.

        Secondly, I audited the type profiler code inside the DFG,
        and found that we were doing some racy things. I haven't
        seen any crashes because of these things, but it is possible
        that they exist. We were grabbing a RefPtr to a TypeSet,
        even though TypeSet was RefCounted and not ThreadSafeRefCounted.
        This patch makes TypeSet ThreadSafeRefCounted. We were
        also copying a StructureSet while the execution thread could
        be augmenting the StructureSet. This patch puts changes to 
        TypeSet's StructureSet behind a ConcurrentJITLock.

        I've also added two more large running tests that run with the
        type profiler enabled. These are here just to catch any major bugs
        in the type profiler implementation.

        * jit/JIT.cpp:
        (JSC::JIT::compileWithoutLinking):
        (JSC::JIT::privateCompile):
        (JSC::JIT::privateCompileExceptionHandlers):
        (JSC::JIT::doMainThreadPreparationBeforeCompile):
        (JSC::JIT::frameRegisterCountFor):
        * jit/JIT.h:
        (JSC::JIT::compile):
        * jit/JITWorklist.cpp:
        (JSC::JITWorklist::Plan::Plan):
        (JSC::JITWorklist::Plan::compileInThread):
        * runtime/TypeSet.cpp:
        (JSC::TypeSet::addTypeInformation):
        (JSC::TypeSet::invalidateCache):
        * runtime/TypeSet.h:
        (JSC::TypeSet::create):
        (JSC::TypeSet::isEmpty):
        (JSC::TypeSet::seenTypes):
        (JSC::TypeSet::structureSet):
        * tests/typeProfiler/deltablue-for-of.js: Added.
        * tests/typeProfiler/getter-richards.js: Added.

2016-06-22  Keith Miller  <keith_miller@apple.com>

        We should have a DFG intrinsic that checks if a value is a TypedArrayView
        https://bugs.webkit.org/show_bug.cgi?id=159048

        Reviewed by Saam Barati.

        This patch adds a new DFG Intrinsic that checks if a value is a TypedArrayView.
        The intrinsic, IsTypedArrayView, works in the same way that the other Is<insert-type>
        DFG nodes work. Additionally, a new builtin function isTypedArrayView has been added.
        These changes are needed to fix regressions in %TypedArray%.prototype.subarray.

        * builtins/BuiltinNames.h:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * 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/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileIsTypedArrayView):
        * 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::compileIsTypedArrayView):
        (JSC::FTL::DFG::LowerDFGToB3::isTypedArrayView):
        * runtime/Intrinsic.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::typedArrayViewPrivateFuncIsTypedArrayView):
        * runtime/JSTypedArrayViewPrototype.h:
        * tests/stress/istypedarrayview-intrinsic.js: Added.
        (makeFn):
        (typedArrays.forEach):
        (let.test):
        (test):

2016-06-21  Anders Carlsson  <andersca@apple.com>

        Fix build.

        * Configurations/FeatureDefines.xcconfig:

2016-06-21  Geoffrey Garen  <ggaren@apple.com>

        Options::useImmortalObjects is not safe for conservative GC
        https://bugs.webkit.org/show_bug.cgi?id=158999

        Reviewed by Geoffrey Garen.

        useImmortalObjects set the mark bit to keep an object from being
        reallocated. This had the negative side-effect of convincing the
        conservative marker that the object was a valid and live cell, which
        would cause us to visit garbage.

        * heap/Heap.cpp:
        (JSC::Heap::didFinishCollection):
        (JSC::Heap::resumeCompilerThreads):
        (JSC::Heap::setFullActivityCallback):
        (JSC::Heap::markDeadObjects): Deleted.
        * heap/Heap.h: Don't set the mark bit on a dead object. That's a bug in
        a conservative GC.

        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::retire): New helper.

        (JSC::MarkedAllocator::reset): Automatically retire old blocks when
        we're doing the immortal objects thing. This has the effect of
        preserving memory for debugging because we never recycle a previously
        allocated block.

2016-06-21  Anders Carlsson  <andersca@apple.com>

        Begin moving the Apple Pay code to the open source repository
        https://bugs.webkit.org/show_bug.cgi?id=158998

        Reviewed by Tim Horton.

        * Configurations/FeatureDefines.xcconfig:
        Add ENABLE_APPLE_PAY.

2016-06-21  Saam Barati  <sbarati@apple.com>

        CodeBlock::shrinkToFit is racy
        https://bugs.webkit.org/show_bug.cgi?id=158994
        <rdar://problem/26920212>

        Reviewed by Filip Pizlo.

        To see why this is racy, consider the following scenario:
        - CodeBlock A is link()ing its baseline compile.
        - CodeBlock B is inlining A, and asks A for a result profile in DFGBytecodeParser.
        - The race occurs when the link() step of the baseline compile calls shrinkToFit
          on its m_resultProfiles field without grabbing a lock. This leads to a bad
          time because the DFG compile will be reading from that vector as it's getting
          changed by the baseline link() method.

        This race has always existed, though the move to a concurrent baseline
        JIT has made it more likely to occur. The solution is to have CodeBlock::shrinkToFit
        grab its lock before shrinking the vector.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::shrinkToFit):

2016-06-21  David Kilzer  <ddkilzer@apple.com>

        Migrate testair & testb3 settings from Xcode project to ToolExecutable.xcconfig
        <https://webkit.org/b/158989>

        Reviewed by Andy Estes.

        * Configurations/ToolExecutable.xcconfig:
        (CODE_SIGN_ENTITLEMENTS_ios_testair): Add from Xcode project.
        * JavaScriptCore.xcodeproj/project.pbxproj:
        (CODE_SIGN_ENTITLEMENTS_ios_testair): Move to
        ToolExecutable.xcconfig.
        (PRODUCT_NAME): Remove.  This variable is already set for both
        testair and testb3 since those build configurations use
        ToolExecutable.xcconfig as a base.

2016-06-21  Saam Barati  <sbarati@apple.com>

        LLInt doesn't throw stack exception overflow from parent frame
        https://bugs.webkit.org/show_bug.cgi?id=158962
        <rdar://problem/26902188>

        Reviewed by Filip Pizlo.

        All JIT tiers will throw stack overflow exceptions from the parent frame.
        The LLInt, on the other hand, did not use to. I've changed the LLInt to be
        consistent with the JITs. The reason I found this bug is because we had a
        test that would give different results depending on if the function was compiled
        in the baseline or the LLInt. Since Filip recently landed the concurrent baseline
        JIT patch, this otherwise deterministic test became dependent on it being compiled
        in the LLInt or one of the JIT tiers. I've added a new test that is deterministic
        because it runs the test with --useJIT=false.

        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * tests/stress/llint-stack-overflow-location.js: Added.
        (stackTraceDescription):
        (foo):
        (catch):

2016-06-21  David Kilzer  <ddkilzer@apple.com>

        CODE_SIGN_ENTITLEMENTS should be applied to iOS Simulator builds
        <https://webkit.org/b/158990>
        <rdar://problem/26906273>

        Reviewed by Dan Bernstein.

        * Configurations/JSC.xcconfig:
        (CODE_SIGN_ENTITLEMENTS): Change [sdk=iphoneos*] to
        [sdk=iphone*] to apply setting to iOS Simulator as well.
        * Configurations/ToolExecutable.xcconfig:
        (CODE_SIGN_ENTITLEMENTS): Ditto.

2016-06-21  Keith Miller  <keith_miller@apple.com>

        It should be easy to add a private global helper function for builtins
        https://bugs.webkit.org/show_bug.cgi?id=158893

        Reviewed by Mark Lam.

        This patch does two things. First it moves all the builtin names
        out of CommonIdentifiers and into BuiltinNames. This means that
        adding a new function to the Builtins does not require rebuilding
        all of JavaScriptCore. This patch also adds a new decorator to our
        builtins @privateGlobal that will automatically put the function
        on the global object. The name of the property will be the same as
        the private name of the function.

        This patch, also, removes the JSArrayIterator.h/.cpp files
        as they no longer appear to be used in any real way. Finally,
        the builtins tests have been rebaselined. It appears this has
        not been done for a while so the expected files contain other
        changes.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Scripts/builtins/builtins_generate_combined_header.py:
        (BuiltinsCombinedHeaderGenerator.generate_output):
        (generate_section_for_code_name_macro):
        (generate_section_for_global_private_code_name_macro):
        * Scripts/builtins/builtins_model.py:
        (BuiltinFunction.__init__):
        (BuiltinFunction.fromString):
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
        * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
        * builtins/ArrayIteratorPrototype.js:
        * builtins/ArrayPrototype.js:
        * builtins/BuiltinNames.h:
        * builtins/GeneratorPrototype.js:
        * builtins/GlobalObject.js:
        * builtins/PromiseOperations.js:
        * builtins/RegExpPrototype.js:
        * builtins/StringPrototype.js:
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
        (JSC::BytecodeGenerator::expectedFunctionForIdentifier):
        (JSC::BytecodeGenerator::emitGetTemplateObject):
        (JSC::BytecodeGenerator::emitLoadNewTargetFromArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitLoadDerivedConstructorFromArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitPutNewTargetToArrowFunctionContextScope):
        (JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope):
        (JSC::BytecodeGenerator::emitGeneratorStateChange):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::emitHomeObjectForCallee):
        (JSC::emitPutHomeObject):
        (JSC::FunctionNode::emitBytecode):
        * dfg/DFGOperations.cpp:
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::subtype):
        (Inspector::JSInjectedScriptHost::getInternalProperties): Deleted.
        * parser/Lexer.cpp:
        (JSC::Lexer<LChar>::parseIdentifier):
        (JSC::Lexer<UChar>::parseIdentifier):
        * parser/Nodes.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::createGeneratorParameters):
        (JSC::Parser<LexerType>::parseExportDeclaration):
        * runtime/ArrayIteratorPrototype.cpp:
        * runtime/ArrayIteratorPrototype.h:
        * runtime/ArrayPrototype.cpp:
        * runtime/CommonIdentifiers.cpp:
        (JSC::CommonIdentifiers::CommonIdentifiers): Deleted.
        * runtime/CommonIdentifiers.h:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/IntlDateTimeFormat.cpp:
        * runtime/IntlDateTimeFormatPrototype.cpp:
        (JSC::IntlDateTimeFormatPrototypeGetterFormat):
        (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
        * runtime/IntlNumberFormatPrototype.cpp:
        (JSC::IntlNumberFormatPrototypeGetterFormat):
        (JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
        * runtime/IntlObjectInlines.h:
        (JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor):
        * runtime/JSArrayIterator.cpp: Removed.
        (JSC::JSArrayIterator::finishCreation): Deleted.
        (JSC::JSArrayIterator::kind): Deleted.
        (JSC::JSArrayIterator::iteratedValue): Deleted.
        * runtime/JSArrayIterator.h: Removed.
        (JSC::JSArrayIterator::createStructure): Deleted.
        (JSC::JSArrayIterator::create): Deleted.
        (JSC::JSArrayIterator::JSArrayIterator): Deleted.
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSInternalPromise.cpp:
        * runtime/JSInternalPromiseDeferred.cpp:
        (JSC::JSInternalPromiseDeferred::create):
        * runtime/JSPromise.cpp:
        (JSC::JSPromise::finishCreation):
        (JSC::JSPromise::result):
        * runtime/JSPromiseDeferred.cpp:
        (JSC::JSPromiseDeferred::create):
        * runtime/JSStringIterator.cpp:
        (JSC::JSStringIterator::finishCreation):
        (JSC::JSStringIterator::iteratedValue):
        (JSC::JSStringIterator::clone):
        * runtime/MapPrototype.cpp:
        (JSC::MapPrototype::finishCreation):
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructor::finishCreation):
        * runtime/ReflectObject.cpp:
        (JSC::ReflectObject::finishCreation):
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        * runtime/TypedArrayInlines.h:

2016-06-20  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Use bytecode intrinsic to expose Module's loading status to builtin JS
        https://bugs.webkit.org/show_bug.cgi?id=158871

        Reviewed by Sam Weinig.

        Now JSC has bytecode intrinsic system. Use it instead of exposing status values through the loader's properties.

        * builtins/ModuleLoaderObject.js:
        (newRegistryEntry):
        (fulfillFetch):
        (fulfillTranslate):
        (commitInstantiated):
        (requestFetch):
        (requestTranslate):
        (requestInstantiate):
        (requestResolveDependencies.):
        (requestResolveDependencies):
        (requestLink):
        (link):
        (provide):
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * runtime/ModuleLoaderObject.cpp:
        (JSC::ModuleLoaderObject::finishCreation): Deleted.

2016-06-20  Commit Queue  <commit-queue@webkit.org>

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

        breaks builds on the simulator (Requested by keith_mi_ on
        #webkit).

        Reverted changeset:

        "It should be easy to add a private global helper function for
        builtins"
        https://bugs.webkit.org/show_bug.cgi?id=158893
        http://trac.webkit.org/changeset/202248

2016-06-20  Keith Miller  <keith_miller@apple.com>

        It should be easy to add a private global helper function for builtins
        https://bugs.webkit.org/show_bug.cgi?id=158893

        Reviewed by Mark Lam.

        This patch does two things. First it moves all the builtin names
        out of CommonIdentifiers and into BuiltinNames. This means that
        adding a new function to the Builtins does not require rebuilding
        all of JavaScriptCore. This patch also adds a new decorator to our
        builtins @privateGlobal that will automatically put the function
        on the global object. The name of the property will be the same as
        the private name of the function.

        This patch, also, removes the JSArrayIterator.h/.cpp files
        as they no longer appear to be used in any real way. Finally,
        the builtins tests have been rebaselined. It appears this has
        not been done for a while so the expected files contain other
        changes.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Scripts/builtins/builtins_generate_combined_header.py:
        (BuiltinsCombinedHeaderGenerator.generate_output):
        (generate_section_for_code_name_macro):
        (generate_section_for_global_private_code_name_macro):
        * Scripts/builtins/builtins_model.py:
        (BuiltinFunction.__init__):
        (BuiltinFunction.fromString):
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
        * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
        * builtins/ArrayIteratorPrototype.js:
        * builtins/ArrayPrototype.js:
        * builtins/BuiltinNames.h:
        * builtins/GeneratorPrototype.js:
        * builtins/GlobalObject.js:
        * builtins/PromiseOperations.js:
        * builtins/RegExpPrototype.js:
        * builtins/StringPrototype.js:
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
        (JSC::BytecodeGenerator::expectedFunctionForIdentifier):
        (JSC::BytecodeGenerator::emitGetTemplateObject):
        (JSC::BytecodeGenerator::emitLoadNewTargetFromArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitLoadDerivedConstructorFromArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitPutNewTargetToArrowFunctionContextScope):
        (JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope):
        (JSC::BytecodeGenerator::emitGeneratorStateChange):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::emitHomeObjectForCallee):
        (JSC::emitPutHomeObject):
        (JSC::FunctionNode::emitBytecode):
        * dfg/DFGOperations.cpp:
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::subtype):
        (Inspector::JSInjectedScriptHost::getInternalProperties): Deleted.
        * parser/Lexer.cpp:
        (JSC::Lexer<LChar>::parseIdentifier):
        (JSC::Lexer<UChar>::parseIdentifier):
        * parser/Nodes.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::createGeneratorParameters):
        (JSC::Parser<LexerType>::parseExportDeclaration):
        * runtime/ArrayIteratorPrototype.cpp:
        * runtime/ArrayIteratorPrototype.h:
        * runtime/ArrayPrototype.cpp:
        * runtime/CommonIdentifiers.cpp:
        (JSC::CommonIdentifiers::CommonIdentifiers): Deleted.
        * runtime/CommonIdentifiers.h:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/IntlDateTimeFormat.cpp:
        * runtime/IntlDateTimeFormatPrototype.cpp:
        (JSC::IntlDateTimeFormatPrototypeGetterFormat):
        (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
        * runtime/IntlNumberFormatPrototype.cpp:
        (JSC::IntlNumberFormatPrototypeGetterFormat):
        (JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
        * runtime/IntlObjectInlines.h:
        (JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor):
        * runtime/JSArrayIterator.cpp: Removed.
        (JSC::JSArrayIterator::finishCreation): Deleted.
        (JSC::JSArrayIterator::kind): Deleted.
        (JSC::JSArrayIterator::iteratedValue): Deleted.
        * runtime/JSArrayIterator.h: Removed.
        (JSC::JSArrayIterator::createStructure): Deleted.
        (JSC::JSArrayIterator::create): Deleted.
        (JSC::JSArrayIterator::JSArrayIterator): Deleted.
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSInternalPromise.cpp:
        * runtime/JSInternalPromiseDeferred.cpp:
        (JSC::JSInternalPromiseDeferred::create):
        * runtime/JSPromise.cpp:
        (JSC::JSPromise::finishCreation):
        (JSC::JSPromise::result):
        * runtime/JSPromiseDeferred.cpp:
        (JSC::JSPromiseDeferred::create):
        * runtime/JSStringIterator.cpp:
        (JSC::JSStringIterator::finishCreation):
        (JSC::JSStringIterator::iteratedValue):
        (JSC::JSStringIterator::clone):
        * runtime/MapPrototype.cpp:
        (JSC::MapPrototype::finishCreation):
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructor::finishCreation):
        * runtime/ReflectObject.cpp:
        (JSC::ReflectObject::finishCreation):
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        * runtime/TypedArrayInlines.h:

2016-06-20  Filip Pizlo  <fpizlo@apple.com>

        LLInt64 Float64 get_by_val doesn't purify NaN
        https://bugs.webkit.org/show_bug.cgi?id=158956

        Reviewed by Michael Saboff.

        * llint/LowLevelInterpreter64.asm: Fix the bug.
        * tests/stress/float64-array-nan-inlined.js: Make this test also run in LLInt-only mode to catch this bug.

2016-06-20  Keith Rollin  <krollin@apple.com>

        Remove RefPtr::release() and change calls sites to use WTFMove()
        https://bugs.webkit.org/show_bug.cgi?id=158369

        Reviewed by Chris Dumez.

        RefPtr::release() releases its managed pointer awkwardly. It's more
        direct and clearer to use WTFMove to transfer ownership of the managed
        pointer.

        As part of this cleanup, also change a lot of explicit data types to
        'auto'.

        * API/JSObjectRef.cpp:
        (JSClassCreate):
        * API/JSScriptRef.cpp:
        * API/JSValueRef.cpp:
        (JSValueToStringCopy):
        * bytecompiler/StaticPropertyAnalyzer.h:
        (JSC::StaticPropertyAnalyzer::newObject):
        (JSC::StaticPropertyAnalyzer::mov):
        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::invalidate):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        * inspector/InspectorValues.cpp:
        (Inspector::InspectorValue::parseJSON):
        * inspector/agents/InspectorAgent.cpp:
        (Inspector::InspectorAgent::activateExtraDomain):
        (Inspector::InspectorAgent::activateExtraDomains):
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::breakpointActionProbe):
        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::receivedSetupMessage):
        * jit/Repatch.cpp:
        (JSC::linkPolymorphicCall):
        * runtime/GenericTypedArrayViewInlines.h:
        (JSC::GenericTypedArrayView<Adaptor>::create):
        (JSC::GenericTypedArrayView<Adaptor>::createUninitialized):
        * runtime/JSArrayBufferConstructor.cpp:
        (JSC::constructArrayBuffer):
        * runtime/PropertyNameArray.h:
        (JSC::PropertyNameArray::releaseData):
        * runtime/Structure.cpp:
        (JSC::Structure::toStructureShape):
        * runtime/TypeSet.cpp:
        (JSC::StructureShape::merge):
        * tools/FunctionOverrides.cpp:
        (JSC::initializeOverrideInfo):

2016-06-20  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: console.profile should use the new Sampling Profiler
        https://bugs.webkit.org/show_bug.cgi?id=153499
        <rdar://problem/24352431>

        Reviewed by Timothy Hatcher.

        Currently console.profile/profileEnd behave slightly differently
        between JSContext and Web inspection. Unifying will be part of:
        <https://webkit.org/b/158753> Generalize the concept of Instruments on the backend

        Both JSContext and Web inspection keep track of active
        profiles started and stopped via console.profile/profileEnd.

        JSContext inspection sends its programmatic start/stop
        via the ScriptProfiler domain.

        Web inspection sends its programmatic start/stop
        via the Timeline domain, and also will start/stop backend
        list of Instruments.

        The functional differences between these is that for JSContext
        inspection, console.profile only starts/stops the ScriptProfiler
        domain, and does not auto-start other instruments. This isn't really
        a problem right now given the instruments available for JSContext
        inspection; but it will be nice to unify as we add more instruments.
        Also, JSContext inspection won't have "Profile (name)" records in
        its Events view, since those are currently generated only by the
        Web's Timeline domain.

        * inspector/protocol/ScriptProfiler.json:
        * inspector/protocol/Timeline.json:
        Events to inform the frontend of programmatic start/stop.

        * debugger/Debugger.h:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::breakpointsActive):
        (Inspector::InspectorDebuggerAgent::isPaused):
        * inspector/agents/InspectorDebuggerAgent.h:
        Expose breakpoints active state, since programmatic recording
        will temporarily disabled breakpoints if needed.

        * inspector/JSGlobalObjectConsoleClient.cpp:
        (Inspector::JSGlobalObjectConsoleClient::JSGlobalObjectConsoleClient):
        (Inspector::JSGlobalObjectConsoleClient::profile):
        (Inspector::JSGlobalObjectConsoleClient::profileEnd):
        (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
        (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):
        * inspector/JSGlobalObjectConsoleClient.h:
        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
        * inspector/agents/InspectorScriptProfilerAgent.cpp:
        (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStarted):
        (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStopped):
        * inspector/agents/InspectorScriptProfilerAgent.h:
        JSContext implementation of console.profile/profileEnd.

2016-06-19  Saam Barati  <sbarati@apple.com>

        We should be able to generate more types of ICs inline
        https://bugs.webkit.org/show_bug.cgi?id=158719
        <rdar://problem/26825641>

        Reviewed by Filip Pizlo.

        This patch changes how we emit code for *byId ICs inline.
        We no longer keep data labels to patch structure checks, etc.
        Instead, we just regenerate the entire IC into a designated
        region of code that the Baseline/DFG/FTL JIT will emit inline.
        This makes it much simpler to patch inline ICs. All that's
        needed to patch an inline IC is to memcpy the code from
        a macro assembler inline using LinkBuffer. This architecture
        will be easy to extend into other forms of ICs, such as one
        for add, in the future.

        To support this change, I've reworked the fields inside
        StructureStubInfo. It now has one field that is the CodeLocationLabel 
        of the start of the inline IC. Then it has a few ints that track deltas
        to other locations in the IC such as the slow path start, slow path call, the
        ICs 'done' location. We used to perform math on these ints in a bunch of different
        places. I've consolidated that math into methods inside StructureStubInfo.

        To generate inline ICs, I've implemented a new class called InlineAccess.
        InlineAccess is stateless: it just has a bunch of static methods for
        generating code into the inline region specified by StructureStubInfo.
        Repatch will now decide when it wants to generate such an inline
        IC, and it will ask InlineAccess to do so.

        I've implemented three types of inline ICs to begin with (extending
        this in the future should be easy):
        - Self property loads (both inline and out of line offsets).
        - Self property replace (both inline and out of line offsets).
        - Array length on specific array types.
        (An easy extension would be to implement JSString length.)

        To know how much inline space to reserve, I've implemented a
        method that stubs out the various inline cache shapes and 
        dumps their size. This is used to determine how much space
        to save inline. When InlineAccess ends up generating more
        code than can fit inline, we will fall back to generating
        code with PolymorphicAccess instead.

        To make generating code into already allocated executable memory
        efficient, I've made AssemblerData have 128 bytes of inline storage.
        This saves us a malloc when splatting code into the inline region.

        This patch also tidies up LinkBuffer's API for generating
        into already allocated executable memory. Now, when generating
        code that has less size than the already allocated space, LinkBuffer
        will fill the extra space with nops. Also, if branch compaction shrinks
        the code, LinkBuffer will add a nop sled at the end of the shrunken
        code to take up the entire allocated size.

        This looks like it could be a 1% octane progression.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/ARM64Assembler.h:
        (JSC::ARM64Assembler::nop):
        (JSC::ARM64Assembler::fillNops):
        * assembler/ARMv7Assembler.h:
        (JSC::ARMv7Assembler::nopw):
        (JSC::ARMv7Assembler::nopPseudo16):
        (JSC::ARMv7Assembler::nopPseudo32):
        (JSC::ARMv7Assembler::fillNops):
        (JSC::ARMv7Assembler::dmbSY):
        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::addLinkTask):
        (JSC::AbstractMacroAssembler::emitNops):
        (JSC::AbstractMacroAssembler::AbstractMacroAssembler):
        * assembler/AssemblerBuffer.h:
        (JSC::AssemblerData::AssemblerData):
        (JSC::AssemblerData::operator=):
        (JSC::AssemblerData::~AssemblerData):
        (JSC::AssemblerData::buffer):
        (JSC::AssemblerData::grow):
        (JSC::AssemblerData::isInlineBuffer):
        (JSC::AssemblerBuffer::AssemblerBuffer):
        (JSC::AssemblerBuffer::ensureSpace):
        (JSC::AssemblerBuffer::codeSize):
        (JSC::AssemblerBuffer::setCodeSize):
        (JSC::AssemblerBuffer::label):
        (JSC::AssemblerBuffer::debugOffset):
        (JSC::AssemblerBuffer::releaseAssemblerData):
        * assembler/LinkBuffer.cpp:
        (JSC::LinkBuffer::copyCompactAndLinkCode):
        (JSC::LinkBuffer::linkCode):
        (JSC::LinkBuffer::allocate):
        (JSC::LinkBuffer::performFinalization):
        (JSC::LinkBuffer::shrink): Deleted.
        * assembler/LinkBuffer.h:
        (JSC::LinkBuffer::LinkBuffer):
        (JSC::LinkBuffer::debugAddress):
        (JSC::LinkBuffer::size):
        (JSC::LinkBuffer::wasAlreadyDisassembled):
        (JSC::LinkBuffer::didAlreadyDisassemble):
        (JSC::LinkBuffer::applyOffset):
        (JSC::LinkBuffer::code):
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::patchableBranch32):
        (JSC::MacroAssemblerARM64::patchableBranch64):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::patchableBranch32):
        (JSC::MacroAssemblerARMv7::patchableBranchPtrWithPatch):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::nop):
        (JSC::X86Assembler::fillNops):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::printGetByIdCacheStatus):
        * bytecode/InlineAccess.cpp: Added.
        (JSC::InlineAccess::dumpCacheSizesAndCrash):
        (JSC::linkCodeInline):
        (JSC::InlineAccess::generateSelfPropertyAccess):
        (JSC::getScratchRegister):
        (JSC::hasFreeRegister):
        (JSC::InlineAccess::canGenerateSelfPropertyReplace):
        (JSC::InlineAccess::generateSelfPropertyReplace):
        (JSC::InlineAccess::isCacheableArrayLength):
        (JSC::InlineAccess::generateArrayLength):
        (JSC::InlineAccess::rewireStubAsJump):
        * bytecode/InlineAccess.h: Added.
        (JSC::InlineAccess::sizeForPropertyAccess):
        (JSC::InlineAccess::sizeForPropertyReplace):
        (JSC::InlineAccess::sizeForLengthAccess):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::PolymorphicAccess::regenerate):
        * bytecode/StructureStubInfo.cpp:
        (JSC::StructureStubInfo::initGetByIdSelf):
        (JSC::StructureStubInfo::initArrayLength):
        (JSC::StructureStubInfo::initPutByIdReplace):
        (JSC::StructureStubInfo::deref):
        (JSC::StructureStubInfo::aboutToDie):
        (JSC::StructureStubInfo::propagateTransitions):
        (JSC::StructureStubInfo::containsPC):
        * bytecode/StructureStubInfo.h:
        (JSC::StructureStubInfo::considerCaching):
        (JSC::StructureStubInfo::slowPathCallLocation):
        (JSC::StructureStubInfo::doneLocation):
        (JSC::StructureStubInfo::slowPathStartLocation):
        (JSC::StructureStubInfo::patchableJumpForIn):
        (JSC::StructureStubInfo::valueRegs):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::link):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::reifyInlinedCallFrames):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetById):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetById):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileIn):
        (JSC::FTL::DFG::LowerDFGToB3::getById):
        * jit/JITInlineCacheGenerator.cpp:
        (JSC::JITByIdGenerator::finalize):
        (JSC::JITByIdGenerator::generateFastCommon):
        (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
        (JSC::JITGetByIdGenerator::generateFastPath):
        (JSC::JITPutByIdGenerator::JITPutByIdGenerator):
        (JSC::JITPutByIdGenerator::generateFastPath):
        (JSC::JITPutByIdGenerator::slowPathFunction):
        (JSC::JITByIdGenerator::generateFastPathChecks): Deleted.
        * jit/JITInlineCacheGenerator.h:
        (JSC::JITByIdGenerator::reportSlowPathCall):
        (JSC::JITByIdGenerator::slowPathBegin):
        (JSC::JITByIdGenerator::slowPathJump):
        (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitGetByValWithCachedId):
        (JSC::JIT::emit_op_try_get_by_id):
        (JSC::JIT::emit_op_get_by_id):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emitGetByValWithCachedId):
        (JSC::JIT::emit_op_try_get_by_id):
        (JSC::JIT::emit_op_get_by_id):
        * jit/Repatch.cpp:
        (JSC::repatchCall):
        (JSC::tryCacheGetByID):
        (JSC::repatchGetByID):
        (JSC::appropriateGenericPutByIdFunction):
        (JSC::tryCachePutByID):
        (JSC::repatchPutByID):
        (JSC::tryRepatchIn):
        (JSC::repatchIn):
        (JSC::linkSlowFor):
        (JSC::resetGetByID):
        (JSC::resetPutByID):
        (JSC::resetIn):
        (JSC::repatchByIdSelfAccess): Deleted.
        (JSC::resetGetByIDCheckAndLoad): Deleted.
        (JSC::resetPutByIDCheckAndLoad): Deleted.
        (JSC::replaceWithJump): Deleted.

2016-06-19  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION(concurrent baseline JIT): Kraken/ai-astar runs 20% slower
        https://bugs.webkit.org/show_bug.cgi?id=158906

        Reviewed by Benjamin Poulain.
        
        The concurrent baseline JIT was a 2-3% progression on JSBench, possibly a 1% progression
        on PLT3, but a 2-5% regression on Kraken. This patch fixes the Kraken regression without
        affecting the other tests.
        
        The problem is that Kraken/ai-astar's initialization code had a ginormous piece of init
        code that took about 16ms to compile in baseline. There's no good way to avoid letting it
        tier-up into baseline since it has a compute loop. The time it takes to run this code is
        never measured. The concurrent baseline JIT caused us to schedule the compilation of this
        huge code rather than doing it eagerly. This meant that after initialization was done and
        we started actually running real stuff, all of the real stuff's compiles would be convoyed
        behind this super-expensive baseline compile. Note that DFG and FTL compiles convoy behind
        baseline compiles, since you can't schedule a DFG compile for a code block until that code
        block is in baseline.
        
        This uses the simplest fix: if we are thinking about scheduling some compile and the
        thread is busy, do the compile on the main thread instead. This doesn't completely
        eliminate the ai-astar regression (we still have a 4% regression on that test) but it now
        results in concurrent baseline JIT being an overall progression on Kraken as a whole (1%
        on my machine). This is because concurrent baseline appears to help on other tests.

        In the future, we could fix this even better by allowing the JITWorklist to spawn more
        threads or by being smarter about baseline compilation. I think it's nasty that if a giant
        piece of initialization code ends in a compute loop, we compile all of the code instead of
        just the loop. It's also gross that a constant-like object creation expression will result
        in so much code. It would result in less code if we allowed ourselves to do a bit more
        static reasoning about object literals.
        
        But for now, I think that this is a great way to recover the Kraken regression while still
        keeping the other progressions from concurrent baseline.

        * jit/JITWorklist.cpp:
        (JSC::JITWorklist::Plan::Plan):
        (JSC::JITWorklist::Plan::compileInThread):
        (JSC::JITWorklist::Plan::finalize):
        (JSC::JITWorklist::Plan::codeBlock):
        (JSC::JITWorklist::Plan::isFinishedCompiling):
        (JSC::JITWorklist::Plan::compileNow):
        (JSC::JITWorklist::JITWorklist):
        (JSC::JITWorklist::compileLater):
        (JSC::JITWorklist::compileNow):
        (JSC::JITWorklist::runThread):
        (JSC::JITWorklist::Plan::isFinalized): Deleted.
        * jit/JITWorklist.h:

2016-06-17  Commit Queue  <commit-queue@webkit.org>

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

        The new test is very unstable, timing out frequently
        (Requested by ap on #webkit).

        Reverted changeset:

        "Web Inspector: console.profile should use the new Sampling
        Profiler"
        https://bugs.webkit.org/show_bug.cgi?id=153499
        http://trac.webkit.org/changeset/202152

2016-06-14  Filip Pizlo  <fpizlo@apple.com>

        Baseline JIT should be concurrent
        https://bugs.webkit.org/show_bug.cgi?id=158755

        Reviewed by Geoffrey Garen.
        
        This makes the baseline JIT concurrent. We want it to be concurrent because it takes up
        about 1% of PLT3 and 10% of JSBench (though the JSBench number might be down from recent
        optimizations).
        
        The idea is really simple: I separated the compile and link phases of JIT::privateCompile(),
        and arranged to call the compile phase from another thread. This doesn't reuse the old
        DFG::Worklist code, because that code does things we don't need (like compilation plan
        cancellation to allow GC to interleave with compilations) and is structured in a way that
        would have required more changes to the baseline JIT. Also, I think that code uses the wrong
        API, and as a result, clients of that API have a bad time. For example, it's never clear who
        has the responsibility of setting the JIT thresholds and the DFG::Worklist goes to great
        lengths to try to help its client set those things correctly, but since it doesn't set them
        directly, the client then has to have additional complex logic to combine what it learned
        from the Worklist and what it knows to set the thresholds. This patch takes a simpler
        approach: the JITWorklist takes complete control over scheduling compilations. It's like a
        combination of DFG::Worklist and operationOptimize().
        
        Because the baseline JIT runs quickly, we can take some shortcuts. The JITWorklist requires
        that all of its plans complete before a GC begins. This ensures that we don't have to worry
        about interactions between the concurrent baseline JIT and the GC.
        
        I needed to do a bunch of minor changes to the JIT to handle the races that emerged. For
        example, I needed to do things to opcodes that read profiling both in the main path code
        generator and the slow path one. One trick I used was to create a copy of the instruction
        stream and provide that for anyone interested in the original value of the profiles. Most
        code still uses the CodeBlock's instruction stream because it may emit JIT code that points
        at the stream.
        
        This also fixes a LLInt bug in prototype caching. This bug was revealed by this change
        because more of our LayoutTests now run in LLInt.
        
        This looks like it might be a ~1% Octane speed-up (on command line) and a ~0.7% PLT3
        speed-up. This also looks like a ~2% JSBench speed-up.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * debugger/Debugger.cpp:
        (JSC::Debugger::setSteppingMode):
        (JSC::Debugger::toggleBreakpoint):
        (JSC::Debugger::clearBreakpoints):
        (JSC::Debugger::clearDebuggerRequests):
        * dfg/DFGOSRExitPreparation.cpp:
        (JSC::DFG::prepareCodeOriginForOSRExit):
        * heap/Heap.cpp:
        (JSC::Heap::didFinishIterating):
        (JSC::Heap::completeAllJITPlans):
        (JSC::Heap::deleteAllCodeBlocks):
        (JSC::Heap::collectImpl):
        (JSC::Heap::completeAllDFGPlans): Deleted.
        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::forEachCodeBlock):
        * jit/JIT.cpp:
        (JSC::JIT::emitNotifyWrite):
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        (JSC::JIT::compileWithoutLinking):
        (JSC::JIT::link):
        (JSC::JIT::privateCompile):
        (JSC::JIT::privateCompileExceptionHandlers):
        * jit/JIT.h:
        (JSC::JIT::compile):
        (JSC::JIT::getSlowCase):
        (JSC::JIT::linkSlowCase):
        (JSC::JIT::linkDummySlowCase):
        * jit/JITInlines.h:
        (JSC::JIT::emitTagBool):
        (JSC::JIT::originalInstruction):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emitSlow_op_put_to_scope):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitSlow_op_put_by_val):
        (JSC::JIT::emit_op_resolve_scope):
        (JSC::JIT::emitSlow_op_resolve_scope):
        (JSC::JIT::emit_op_get_from_scope):
        (JSC::JIT::emitSlow_op_get_from_scope):
        (JSC::JIT::emit_op_put_to_scope):
        (JSC::JIT::emitSlow_op_put_to_scope):
        * jit/JITWorklist.cpp: Added.
        (JSC::JITWorklist::Plan::Plan):
        (JSC::JITWorklist::Plan::compileInThread):
        (JSC::JITWorklist::Plan::finalize):
        (JSC::JITWorklist::Plan::codeBlock):
        (JSC::JITWorklist::Plan::vm):
        (JSC::JITWorklist::Plan::isFinishedCompiling):
        (JSC::JITWorklist::Plan::isFinalized):
        (JSC::JITWorklist::JITWorklist):
        (JSC::JITWorklist::~JITWorklist):
        (JSC::JITWorklist::completeAllForVM):
        (JSC::JITWorklist::poll):
        (JSC::JITWorklist::compileLater):
        (JSC::JITWorklist::compileNow):
        (JSC::JITWorklist::runThread):
        (JSC::JITWorklist::finalizePlans):
        (JSC::JITWorklist::instance):
        * jit/JITWorklist.h: Added.
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::jitCompileAndSetHeuristics):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
        (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
        * runtime/VM.cpp:
        (JSC::VM::~VM):

2016-06-16  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: console.profile should use the new Sampling Profiler
        https://bugs.webkit.org/show_bug.cgi?id=153499
        <rdar://problem/24352431>

        Reviewed by Timothy Hatcher.

        Currently console.profile/profileEnd behave slightly differently
        between JSContext and Web inspection. Unifying will be part of:
        <https://webkit.org/b/158753> Generalize the concept of Instruments on the backend

        Both JSContext and Web inspection keep track of active
        profiles started and stopped via console.profile/profileEnd.

        JSContext inspection sends its programmatic start/stop
        via the ScriptProfiler domain.

        Web inspection sends its programmatic start/stop
        via the Timeline domain, and also will start/stop backend
        list of Instruments.

        The functional differences between these is that for JSContext
        inspection, console.profile only starts/stops the ScriptProfiler
        domain, and does not auto-start other instruments. This isn't really
        a problem right now given the instruments available for JSContext
        inspection; but it will be nice to unify as we add more instruments.
        Also, JSContext inspection won't have "Profile (name)" records in
        its Events view, since those are currently generated only by the
        Web's Timeline domain.

        * inspector/protocol/ScriptProfiler.json:
        * inspector/protocol/Timeline.json:
        Events to inform the frontend of programmatic start/stop.

        * debugger/Debugger.h:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::breakpointsActive):
        (Inspector::InspectorDebuggerAgent::isPaused):
        * inspector/agents/InspectorDebuggerAgent.h:
        Expose breakpoints active state, since programmatic recording
        will temporarily disabled breakpoints if needed.

        * inspector/JSGlobalObjectConsoleClient.cpp:
        (Inspector::JSGlobalObjectConsoleClient::JSGlobalObjectConsoleClient):
        (Inspector::JSGlobalObjectConsoleClient::profile):
        (Inspector::JSGlobalObjectConsoleClient::profileEnd):
        (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
        (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):
        * inspector/JSGlobalObjectConsoleClient.h:
        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
        * inspector/agents/InspectorScriptProfilerAgent.cpp:
        (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStarted):
        (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStopped):
        * inspector/agents/InspectorScriptProfilerAgent.h:
        JSContext implementation of console.profile/profileEnd.

2016-06-16  Filip Pizlo  <fpizlo@apple.com>

        Kraken/stanford-crypto-pbkdf2.js sometimes crashes with an OSR assertion in FTL
        https://bugs.webkit.org/show_bug.cgi?id=158850

        Reviewed by Keith Miller.
        
        Bytecode liveness was incorrectly claiming that all tail-deleted locals are live! That's
        crazy! We never noticed this because extending OSR liveness is usually not a showstopper and
        until recently we didn't have a lot of tail-call test cases to play with. Well, we do now,
        thanks to the increasing reliance on tail calls in our builtins.

        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::localsLiveInBytecode): Fix the bug and add some optional tracing. Also restructure the code so that we don't break to return true, since that's counterintuitive.
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::buildExitArguments): Make this assertion print more useful information.

2016-06-16  Mark Lam  <mark.lam@apple.com>

        Add collecting of LLINT slow path stats.
        https://bugs.webkit.org/show_bug.cgi?id=158829

        Reviewed by Keith Miller.

        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::dumpStats):
        * llint/LLIntData.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

2016-06-15  Keith Miller  <keith_miller@apple.com>

        Add support for Symbol.isConcatSpreadable (round 2)
        https://bugs.webkit.org/show_bug.cgi?id=158769

        Reviewed by Mark Lam.

        This patch adds support for Symbol.isConcatSpreadable. In order to
        do so, it was necessary to move the Array.prototype.concat function
        to JS. A number of different optimizations were needed to make
        such the move to a builtin performant. First, this patch adds a
        new Bytecode intrinsic, isJSArray, that checks if the value is a
        JSArray object. Specifically, isJSArray checks that the array
        object is a normal instance of JSArray and not a RuntimeArray or
        Array.prototype. isJSArray can also be converted into a constant
        by the DFG if we are able to prove that the incomming value is
        already a JSArray.

        In order to further improve the perfomance we also now cover more
        indexing types in our fast path memcpy code. Before we would only
        memcpy Arrays if they had the same indexing type and did not have
        Array storage or were undecided. Now the memcpy code covers the
        following additional three cases:

        1) One array is undecided and the other does not have array storage

        2) One array is Int32 and the other is contiguous (we map this
        into a contiguous array).

        3) The this value is an array and first argument is a non-array
        that does not have Symbol.isConcatSpreadable set.

        This patch also adds a new fast path for concat with more than one
        array argument by using memcpy to append values onto the result
        array. This works roughly the sa