2016-09-24 Chris Dumez REGRESSION (r206221): [USER] com.apple.WebKit.WebContent.Development at com.apple.JavaScriptCore: vmEntryToJavaScript + 299 https://bugs.webkit.org/show_bug.cgi?id=162536 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 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 [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::Lexer): (JSC::Lexer::lex): * parser/Lexer.h: * parser/NodeConstructors.h: (JSC::AwaitExprNode::AwaitExprNode): * parser/Nodes.h: * parser/Parser.cpp: (JSC::Parser::Parser): (JSC::Parser::parseInner): (JSC::Parser::isArrowFunctionParameters): (JSC::Parser::parseAsyncFunctionSourceElements): (JSC::Parser::parseStatementListItem): (JSC::Parser::parseVariableDeclarationList): (JSC::Parser::parseDestructuringPattern): (JSC::Parser::parseStatement): (JSC::Parser::parseFunctionDeclarationStatement): (JSC::Parser::maybeParseAsyncFunctionDeclarationStatement): (JSC::Parser::parseFormalParameters): (JSC::stringForFunctionMode): (JSC::Parser::parseFunctionParameters): (JSC::Parser::parseFunctionInfo): (JSC::Parser::parseAsyncFunctionDeclaration): (JSC::Parser::parseClass): (JSC::Parser::parseExpressionOrLabelStatement): (JSC::Parser::parseImportClauseItem): (JSC::Parser::parseImportDeclaration): (JSC::Parser::parseExportDeclaration): (JSC::Parser::parseAssignmentExpression): (JSC::Parser::parseProperty): Deleted. (JSC::Parser::parsePropertyMethod): Deleted. (JSC::Parser::parsePrimaryExpression): Deleted. (JSC::Parser::parseMemberExpression): Deleted. (JSC::Parser::parseArrowFunctionExpression): Deleted. (JSC::Parser::parseUnaryExpression): Deleted. (JSC::Parser::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 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 Unreviewed, fix all other builds. * assembler/AbstractMacroAssembler.h: 2016-09-23 Filip Pizlo Unreviewed, fix cloop. * assembler/AbstractMacroAssembler.h: * heap/SlotVisitor.cpp: 2016-09-22 Filip Pizlo 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 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 Add a new runtime flag for work on modern media controls (off by default) https://bugs.webkit.org/show_bug.cgi?id=162420 Reviewed by Eric Carlson. * runtime/CommonIdentifiers.h: 2016-09-23 Carlos Garcia Campos 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 [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 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 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 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 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::isArrowFunctionParameters): (JSC::Parser::parseGeneratorFunctionSourceElements): (JSC::Parser::parseFormalParameters): (JSC::Parser::parseFunctionBody): (JSC::Parser::parseFunctionParameters): (JSC::Parser::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 Remove a bunch of unnecessary includes https://bugs.webkit.org/show_bug.cgi?id=162376 Reviewed by Mark Lam. 2016-09-21 Keith Miller 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 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 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 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 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 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 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 [ARM] Unreviewed buildfix after r206136. * assembler/MacroAssembler.h: * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::branchPtr): Added. 2016-09-20 Alex Christensen 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 REGRESSION(r205692): Minified builds have broken inspector https://bugs.webkit.org/show_bug.cgi?id=162327 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 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 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 Rebaseline builtins generator tests after r206155. Unreviewed test gardening. * Scripts/tests/builtins/expected/WebCoreJSBuiltins.h-result: 2016-09-20 Filip Pizlo Unreviewed, fix cloop build. * runtime/VM.h: 2016-09-20 Filip Pizlo 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>::emptyValue): (WTF::HashTraits>::peek): * heap/WeakBlock.cpp: (JSC::WeakBlock::specializedVisit): (JSC::WeakBlock::reap): * heap/WeakInlines.h: (WTF::HashTraits>::emptyValue): Deleted. (WTF::HashTraits>::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 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 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 [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 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::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 [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::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 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 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 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::FunctionParser): (JSC::WASM::FunctionParser::parseBlock): (JSC::WASM::FunctionParser::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 [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 Web Replay: teach the replay inputs generator to encode and decode OptionSet 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' 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::encodeValue): (JSC::EncodingTraits::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 to capture generated encode/decode methods. 2016-09-19 Yusuke Suzuki [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::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 [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 [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 [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::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 [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 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 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 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 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 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 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 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::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 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 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 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 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 Unreviewed, fix the Windows build. * runtime/HashMapImpl.cpp: 2016-09-14 Keith Miller 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 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::finishCreation): 2016-09-14 Benjamin Poulain [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::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 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 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 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 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 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 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 DFG NewArrayBuffer node should watch for "have a bad time" state change. https://bugs.webkit.org/show_bug.cgi?id=161927 Reviewed by Geoffrey Garen. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): 2016-09-13 JF Bastien 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 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 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 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 [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 [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::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 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::executeEffects): * runtime/HashMapImpl.h: (JSC::wangsInt64Hash): (JSC::jsMapHash): (JSC::concurrentJSMapHash): 2016-09-11 Filip Pizlo 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 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::stepOverInstruction): (JSC::BytecodeLivenessPropagation::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 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 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::parseBlock): (JSC::WASM::FunctionParser::parseExpression): (JSC::WASM::FunctionParser::parseUnreachableExpression): * wasm/WASMOps.h: 2016-09-09 Filip Pizlo 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 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 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 ASSERTION FAILED: promise.inherits(JSPromise::info()) https://bugs.webkit.org/show_bug.cgi?id=161632 Reviewed by Mark Lam. * runtime/JSPromiseDeferred.cpp: (JSC::JSPromiseDeferred::create): Returning null if promise object is not created. 2016-09-08 Filip Pizlo 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 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 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 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 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 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 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::visitChildren): (JSC::HashMapImpl::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 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::createWithFastVector): (JSC::JSGenericTypedArrayView::visitChildren): (JSC::JSGenericTypedArrayView::slowDownAndWasteMemory): (JSC::JSGenericTypedArrayView::copyBackingStore): Deleted. 2016-09-08 Per Arne Vollan [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 [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 Enable the 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 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 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 Unreviewed, build fix after r205569 Tweak CMakeLists.txt * CMakeLists.txt: 2016-09-07 Mark Lam 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::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::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 [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 [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 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 Unreviewed CMake build fix after r205552 * CMakeLists.txt: 2016-09-03 Keith Miller 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::parse): (JSC::WASM::FunctionParser::parseExpression): * wasm/WASMModuleParser.cpp: (JSC::WASM::ModuleParser::parseFunctionTypes): * wasm/WASMOps.h: 2016-09-07 Youenn Fablet [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 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 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 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. 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 [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 Unreviewed build fix for 32-bit platforms after r205520. * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): Deleted. 2016-09-06 Saam Barati 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::executeEffects): 2016-09-06 Saam Barati 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::executeEffects): (JSC::DFG::AbstractInterpreter::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::visitChildren): (JSC::HashMapImpl::visitChildren): (JSC::HashMapImpl::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::visitChildren): (JSC::MapBase::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 [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::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 Gardening: change to use old header guard to appease Win EWS. Not reviewed. * runtime/AuxiliaryBarrier.h: 2016-09-06 Commit Queue 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 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 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::executeEffects): (JSC::DFG::AbstractInterpreter::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::visitChildren): (JSC::HashMapImpl::visitChildren): (JSC::HashMapImpl::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::visitChildren): (JSC::MapBase::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 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::createWithFastVector): (JSC::JSGenericTypedArrayView::visitChildren): (JSC::JSGenericTypedArrayView::slowDownAndWasteMemory): (JSC::JSGenericTypedArrayView::copyBackingStore): Deleted. 2016-09-06 Michael Catanzaro Silence GCC warning spam introduced in r205462 Rubber-stamped by Filip Pizlo. * bytecode/Opcode.h: (JSC::padOpcodeName): 2016-09-05 Filip Pizlo 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 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 Unreviewed, fix cloop build. * bytecode/SuperSampler.cpp: 2016-08-31 Filip Pizlo 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::AuxiliaryBarrier): (JSC::AuxiliaryBarrier::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::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 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 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 Reviewed by Joseph Pecoraro. * CMakeLists.txt: Remove some unnecessary MAKE_DIRECTORY commands. 2016-09-03 Joseph Pecoraro 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 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 [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 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 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 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 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 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 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 => Ref 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 Build fix. * Configurations/FeatureDefines.xcconfig: 2016-09-01 JF Bastien 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 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 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 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 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::FunctionParser): (JSC::WASM::FunctionParser::parseExpression): * wasm/WASMModuleParser.cpp: (JSC::WASM::ModuleParser::parseFunctionTypes): (JSC::WASM::ModuleParser::parseFunctionSignatures): * wasm/WASMModuleParser.h: * wasm/WASMOps.h: 2016-09-01 Keith Miller 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::FunctionParser): (JSC::WASM::FunctionParser::parse): (JSC::WASM::FunctionParser::parseBlock): (JSC::WASM::FunctionParser::parseExpression): (JSC::WASM::WASMFunctionParser::WASMFunctionParser): Deleted. (JSC::WASM::WASMFunctionParser::parse): Deleted. (JSC::WASM::WASMFunctionParser::parseBlock): Deleted. (JSC::WASM::WASMFunctionParser::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 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 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 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 Unreviewed ARM buildfix after r205283. * assembler/ARMAssembler.h: (JSC::ARMAssembler::patchableJumpSize): * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::patchableJumpSize): 2016-09-01 Saam Barati JITMathIC was misusing maxJumpReplacementSize https://bugs.webkit.org/show_bug.cgi?id=161356 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 [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