2017-12-22 Jeff Miller Update user-visible copyright strings to include 2018 https://bugs.webkit.org/show_bug.cgi?id=181141 Reviewed by Dan Bernstein. * Info.plist: 2017-12-30 Yusuke Suzuki [JSC] Remove unused JSTypes https://bugs.webkit.org/show_bug.cgi?id=181184 Reviewed by Saam Barati. JSType includes some unused types such as NullType. They are for primitive values in old days. But now JSType is only used for JSCells. * runtime/JSType.h: * runtime/TypedArrayType.cpp: (JSC::typeForTypedArrayType): 2017-12-28 Saam Barati Remove op_assert and make @assert in builtins a function call so we have DFG/FTL coverage for builtins that use @assert in debug builds https://bugs.webkit.org/show_bug.cgi?id=181176 Reviewed by Yusuke Suzuki. Previously, op_assert was only implemented in the LLInt and baseline JIT. This meant that any builtin that used @assert was not tiering up to the DFG/FTL in debug builds. This patch changes @assert to just call a host function when !ASSERT_DISABLED. It's a no-op when ASSERT_DISABLED. Now, builtins that use @assert will tier up to the DFG/FTL on debug builds. * builtins/BuiltinNames.h: * bytecode/BytecodeDumper.cpp: (JSC::BytecodeDumper::dumpBytecode): * bytecode/BytecodeIntrinsicRegistry.h: * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitAssert): Deleted. * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::FunctionCallResolveNode::emitBytecode): (JSC::BytecodeIntrinsicNode::emit_intrinsic_assert): Deleted. * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * llint/LowLevelInterpreter.asm: * runtime/CommonSlowPaths.cpp: * runtime/CommonSlowPaths.h: * runtime/JSGlobalObject.cpp: (JSC::assertCall): (JSC::JSGlobalObject::init): 2017-12-28 Fujii Hironori [Win][CMake] Use add_custom_command to copy each forwarding header files https://bugs.webkit.org/show_bug.cgi?id=180921 Reviewed by Brent Fulgham. * PlatformWin.cmake: Use WEBKIT_MAKE_FORWARDING_HEADERS. 2017-12-28 Saam Barati Assertion used to determine if something is an async generator is wrong https://bugs.webkit.org/show_bug.cgi?id=181168 Reviewed by Yusuke Suzuki. Previous assertions were doing a get on the base value for @@asyncIterator. This symbol is defined on AsyncGeneratorPrototype. The base value may change its prototype, but it's still an async generator as far as our system is concerned. This patch updates the assertion to check for a private property on the base value. * builtins/AsyncGeneratorPrototype.js: (globalPrivate.asyncGeneratorReject): (globalPrivate.asyncGeneratorResolve): (globalPrivate.asyncGeneratorResumeNext): 2017-12-27 Carlos Alberto Lopez Perez Build fix after r226299 (3) https://bugs.webkit.org/show_bug.cgi?id=181160 Unreviewed build fix. * API/tests/TypedArrayCTest.cpp: fix typo in header name. 2017-12-27 Carlos Alberto Lopez Perez Build fix after r226299 (2) https://bugs.webkit.org/show_bug.cgi?id=181160 Unreviewed build fix. * API/tests/TypedArrayCTest.cpp: Add missing header include. 2017-12-27 Carlos Alberto Lopez Perez Build fix after r226299 https://bugs.webkit.org/show_bug.cgi?id=181160 Unreviewed build fix. * API/tests/TypedArrayCTest.cpp: (assertEqualsAsNumber): Disambiguate usage of isnan. 2017-12-26 Carlos Alberto Lopez Perez REGRESSION(r225769): Build error with constexpr std::max // std::min in libdstdc++4 https://bugs.webkit.org/show_bug.cgi?id=181160 Reviewed by Myles C. Maxfield. Disambiguate usage of min and max (Use the version from stdlib). * runtime/JSArray.cpp: (JSC::JSArray::unshiftCountSlowCase): (JSC::JSArray::setLengthWithArrayStorage): (JSC::JSArray::shiftCountWithArrayStorage): (JSC::JSArray::fillArgList): (JSC::JSArray::copyToArguments): 2017-12-27 Zan Dobersek REGRESSION(r225913): about 30 JSC test failures on ARMv7 https://bugs.webkit.org/show_bug.cgi?id=181162 Reviewed by Michael Catanzaro. Fast case in DFG::SpeculativeJIT::compileArraySlice() was enabled in r225913 on all but 32-bit x86 platform. Other 32-bit platforms have the same lack of GP registers, so the conditional is changed here to only enable this optimization explicitly on ARM64 and x86-64. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArraySlice): 2017-12-26 Yusuke Suzuki [JSC] Remove std::chrono completely https://bugs.webkit.org/show_bug.cgi?id=181165 Reviewed by Konstantin Tokarev. This patch removes std::chrono use completely from JSC. * API/JSContextRef.cpp: (JSContextGroupSetExecutionTimeLimit): * API/tests/ExecutionTimeLimitTest.cpp: (currentCPUTimeAsJSFunctionCallback): (testExecutionTimeLimit): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::CodeBlock): (JSC::timeToLive): * bytecode/CodeBlock.h: (JSC::CodeBlock::timeSinceCreation): * runtime/SamplingProfiler.cpp: (JSC::SamplingProfiler::SamplingProfiler): (JSC::SamplingProfiler::timerLoop): (JSC::SamplingProfiler::takeSample): (JSC::SamplingProfiler::reportTopFunctions): (JSC::SamplingProfiler::reportTopBytecodes): * runtime/SamplingProfiler.h: (JSC::SamplingProfiler::setTimingInterval): * runtime/VM.cpp: (JSC::VM::VM): * runtime/Watchdog.cpp: (JSC::Watchdog::Watchdog): (JSC::Watchdog::setTimeLimit): (JSC::Watchdog::shouldTerminate): (JSC::Watchdog::startTimer): (JSC::currentWallClockTime): Deleted. * runtime/Watchdog.h: 2017-12-26 Zan Dobersek REGRESSION(r226269): 60 JSC test failures on ARMv7 https://bugs.webkit.org/show_bug.cgi?id=181163 Reviewed by Yusuke Suzuki. In r226269, DFG::SpeculativeJIT::compile() changed behavior for the GetDirectPname operation on non-x86 platforms, switching to using GPRFlushedCallResult registers for the payload and tag pair of the return value (through the JSValueRegsFlushedCallResult struct). This tripped about 60 test cases on ARMv7. As before this change, GPRTemporary registers should be used, but this can now be done through a JSValueRegsTemporary object. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2017-12-22 Caio Lima [JSC] IntlCollator and IntlNumberFormat has static fields with same name https://bugs.webkit.org/show_bug.cgi?id=181128 Reviewed by Yusuke Suzuki. Minor fixes into IntlNumberFormat::initializeNumberFormat and IntlCollator::initializeCollator that makes JSC unified sources compile. These files were generating compilation error when placed at the same UnifiedSource.cpp, because they had static variables with same name. * runtime/IntlCollator.cpp: (JSC::IntlCollator::initializeCollator): * runtime/IntlNumberFormat.cpp: (JSC::IntlNumberFormat::initializeNumberFormat): 2017-12-22 Michael Catanzaro generate_offset_extractor.rb should not print to stderr by default https://bugs.webkit.org/show_bug.cgi?id=181133 Reviewed by Mark Lam. Remove unneeded print output. * offlineasm/generate_offset_extractor.rb: 2017-12-22 Yusuke Suzuki [DFG] Cleaning up and unifying 32bit code more https://bugs.webkit.org/show_bug.cgi?id=181124 Reviewed by Mark Lam. This patch unifies DFG 32bit code into 64bit code more. In this patch, we move RegExp DFG nodes from 32bit / 64bit code to the common code. We change some RegExp operations to returning JSCell* instead of EncodedJSValue. This simplifies DFG implementation. And we also move HasGenericProperty since we now have JSValueRegsFlushedCallResult. ToPrimive, LogShadowChickenPrologue, and LogShadowChickenTail are almost the same in 32bit and 64bit. Thus, it is unified easily. And we also move some GPRFlushedCallResult from the original places to the places just after `flushRegisters()` not to spill unnecessary registers. * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileRegExpExec): (JSC::DFG::SpeculativeJIT::compileRegExpTest): (JSC::DFG::SpeculativeJIT::compileStringReplace): (JSC::DFG::SpeculativeJIT::compileHasGenericProperty): (JSC::DFG::SpeculativeJIT::compileToPrimitive): (JSC::DFG::SpeculativeJIT::compileLogShadowChickenPrologue): (JSC::DFG::SpeculativeJIT::compileLogShadowChickenTail): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): (JSC::DFG::SpeculativeJIT::speculateDoubleRepAnyInt): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileStringReplace): * jit/JITOperations.cpp: * jit/JITOperations.h: * runtime/StringPrototype.cpp: (JSC::jsSpliceSubstrings): (JSC::jsSpliceSubstringsWithSeparators): (JSC::removeUsingRegExpSearch): (JSC::replaceUsingRegExpSearch): (JSC::operationStringProtoFuncReplaceRegExpEmptyStr): (JSC::operationStringProtoFuncReplaceRegExpString): (JSC::replaceUsingStringSearch): (JSC::replace): (JSC::stringProtoFuncReplaceUsingRegExp): (JSC::stringProtoFuncReplaceUsingStringSearch): (JSC::operationStringProtoFuncReplaceGeneric): * runtime/StringPrototype.h: 2017-12-22 Michael Catanzaro [GTK] Duplicated symbols in libjavascriptcoregtk and libwebkit2gtk can cause crashes in production builds https://bugs.webkit.org/show_bug.cgi?id=179914 Unreviewed. * PlatformGTK.cmake: 2017-12-22 Michael Catanzaro [GTK] Duplicated symbols in libjavascriptcoregtk and libwebkit2gtk can cause crashes in production builds https://bugs.webkit.org/show_bug.cgi?id=179914 Reviewed by Carlos Garcia Campos. Add a new JavaScriptCoreGTK build target, to build JSC as a shared library. Link the original JavaScriptCore build target, which is now a static library, to it. Use --whole-archive to prevent all the JavaScriptCore symbols from being dropped, since none are used directly by JavaScriptCoreGTK. The installed libjavascriptcoregtk-4.0 now corresponds to the JavaScriptCoreGTK target, instead of the JavaScriptCore target. There is almost no difference on the installed system, except that we now use a version script when linking, to hide private symbols, since they're no longer needed by libwebkit2gtk-4.0.so. Also, move the symbols map here. * PlatformGTK.cmake: * javascriptcoregtk-symbols.map: Added. 2017-12-22 Yusuke Suzuki [DFG] Unify bunch of DFG 32bit code into 64bit code https://bugs.webkit.org/show_bug.cgi?id=181083 Reviewed by Mark Lam. There are bunch of the completely same code in 32bit and 64bit DFG. This is largely because of the old DFG code. At that time, we do not have enough abstraction to describe them in one code. But now, we have JSValueRegs, JSValueRegsTemporary etc. They allow DFG to write 32bit and 64bit handling in one code. This patch unifies easy ones. This is nice since basically 32bit code is a bit old and not maintained so much compared to 64bit. If we can drop 32bit specific code as much as possible, it would be nice. Furthermore, we can find various mistakes in 32bit: For example, NewObject does not have mutatorFence in 32bit while 64bit has it. This unification is a chance to fix miscellaneous bugs in 32bit while reducing maintenance burden. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize): (JSC::DFG::SpeculativeJIT::compileGetEnumerableLength): (JSC::DFG::SpeculativeJIT::compileToIndexString): (JSC::DFG::SpeculativeJIT::compilePutByIdWithThis): (JSC::DFG::SpeculativeJIT::compileHasStructureProperty): (JSC::DFG::SpeculativeJIT::compileGetPropertyEnumerator): (JSC::DFG::SpeculativeJIT::compileGetEnumeratorPname): (JSC::DFG::SpeculativeJIT::compileGetGetter): (JSC::DFG::SpeculativeJIT::compileGetSetter): (JSC::DFG::SpeculativeJIT::compileGetCallee): (JSC::DFG::SpeculativeJIT::compileGetArgumentCountIncludingThis): (JSC::DFG::SpeculativeJIT::compileStrCat): (JSC::DFG::SpeculativeJIT::compileNewArrayWithSize): (JSC::DFG::SpeculativeJIT::compileNewTypedArray): (JSC::DFG::SpeculativeJIT::compileCreateThis): (JSC::DFG::SpeculativeJIT::compileNewObject): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2017-12-22 Yusuke Suzuki [DFG] Add JSValueRegsFlushedCallResult https://bugs.webkit.org/show_bug.cgi?id=181075 Reviewed by Mark Lam. Add JSValueRegsFlushedCallResult, which is appropriate for the JSValueRegs result of the function call after flushing. We can remove bunch of `#if USE(JSVALUE32_64)` code and simplify them. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileFromCharCode): (JSC::DFG::SpeculativeJIT::compileGetByValForObjectWithString): (JSC::DFG::SpeculativeJIT::compileGetByValForObjectWithSymbol): (JSC::DFG::SpeculativeJIT::compileParseInt): (JSC::DFG::SpeculativeJIT::emitUntypedBitOp): (JSC::DFG::SpeculativeJIT::emitUntypedRightShiftBitOp): (JSC::DFG::SpeculativeJIT::compileValueAdd): (JSC::DFG::SpeculativeJIT::compileArithMul): (JSC::DFG::SpeculativeJIT::compileArithDiv): (JSC::DFG::SpeculativeJIT::compileArithRounding): (JSC::DFG::SpeculativeJIT::compileResolveScopeForHoistingFuncDeclInEval): (JSC::DFG::SpeculativeJIT::compileGetDynamicVar): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): (JSC::DFG::JSValueRegsFlushedCallResult::JSValueRegsFlushedCallResult): (JSC::DFG::JSValueRegsFlushedCallResult::regs): 2017-12-21 Saam Barati lowering get_by_val to GetById inside bytecode parser should check for BadType exit kind https://bugs.webkit.org/show_bug.cgi?id=181112 Reviewed by Mark Lam. The React subtest in Speedometer has a get_by_val it always converts into a GetById in the DFG. This GetById always exits because of the incoming identifier is a rope. This patch fixes this infinite exit loop by only doing this transformation if we haven't exited due to BadType. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): 2017-12-21 Mark Lam Add WTF::PoisonedUniquePtr to replace std::unique_ptr when poisoning is desired. https://bugs.webkit.org/show_bug.cgi?id=181062 Reviewed by Chris Dumez. * runtime/JSCPoisonedPtr.cpp: - Added a needed #include. 2017-12-21 Jeremy Jones Update FULLSCREEN_API feature defines. https://bugs.webkit.org/show_bug.cgi?id=181015 Reviewed by Tim Horton. Change enabled iphone sdk for FULLSCREEN_API. * Configurations/FeatureDefines.xcconfig: 2017-12-19 Yusuke Suzuki [JSC] Do not check isValid() in op_new_regexp https://bugs.webkit.org/show_bug.cgi?id=180970 Reviewed by Saam Barati. We should not check `isValid()` inside op_new_regexp. This simplifies the semantics of NewRegexp node in DFG. * bytecompiler/NodesCodegen.cpp: (JSC::RegExpNode::emitBytecode): * dfg/DFGMayExit.cpp: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileNewRegexp): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp): * jit/JITOperations.cpp: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): 2017-12-20 Saam Barati GetPropertyEnumerator in DFG/FTL should not unconditionally speculate cell https://bugs.webkit.org/show_bug.cgi?id=181054 Reviewed by Mark Lam. Speedometer's react subtest has a function that is in an OSR exit loop because we used to unconditionally speculate cell for the operand to GetPropertyEnumerator. This fix doesn't seem to speed up Speedometer at all, but it's good hygiene for our compiler to not have this pathology. This patch adds a generic GetPropertyEnumerator to prevent the exit loop. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileGetPropertyEnumerator): * jit/JITOperations.cpp: * jit/JITOperations.h: 2017-12-20 Daniel Bates Remove Alternative Presentation Button https://bugs.webkit.org/show_bug.cgi?id=180500 Reviewed by Simon Fraser. We no longer need the alternative presentation button. * Configurations/FeatureDefines.xcconfig: 2017-12-19 Saam Barati We forgot to do index masking for in bounds int32 arrays in the FTL https://bugs.webkit.org/show_bug.cgi?id=180987 Reviewed by Keith Miller. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal): 2017-12-19 Yusuke Suzuki [DFG][FTL] NewRegexp shoud be fast https://bugs.webkit.org/show_bug.cgi?id=180960 Reviewed by Michael Saboff. When we encounter RegExp literal like /AAA/g, we need to create a RegExp object. Typical idiom like `string.match(/regexp/)` requires RegExp object creation every time. As a first step, this patch accelerates RegExp object creation by handling it in DFG and FTL. In a subsequent patch, we would like to introduce PhantomNewRegexp to remove unnecessary RegExp object creations. This patch improves SixSpeed/regex-u.{es5,es6}. baseline patched regex-u.es5 69.6759+-3.1951 ^ 53.1425+-2.0292 ^ definitely 1.3111x faster regex-u.es6 129.5413+-5.4437 ^ 107.2105+-7.7775 ^ definitely 1.2083x faster * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileNewRegexp): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLAbstractHeapRepository.h: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp): * jit/JIT.h: * jit/JITInlines.h: (JSC::JIT::callOperation): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_new_regexp): * jit/JITOperations.cpp: * jit/JITOperations.h: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/RegExpObject.h: (JSC::RegExpObject::offsetOfRegExp): (JSC::RegExpObject::allocationSize): 2017-12-19 Yusuke Suzuki Unreviewed, include YarrErrorCode.h in Yarr.h https://bugs.webkit.org/show_bug.cgi?id=180966 * yarr/Yarr.h: 2017-12-19 Yusuke Suzuki [YARR] Yarr should return ErrorCode instead of error messages (const char*) https://bugs.webkit.org/show_bug.cgi?id=180966 Reviewed by Mark Lam. Currently, Yarr returns const char*` for an error message when needed. But it is easier to handle error status if Yarr returns an error code instead of `const char*`. In this patch, we introduce Yarr::ErrorCode. Yarr returns it instead of `const char*`. `std::expected` would be appropriate for the Yarr API interface. But it requires substantial changes removing ErrorCode::NoError, so this patch just uses the current Yarr::ErrorCode as a first step. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * inspector/ContentSearchUtilities.cpp: (Inspector::ContentSearchUtilities::findMagicComment): * parser/ASTBuilder.h: (JSC::ASTBuilder::createRegExp): * parser/Parser.cpp: (JSC::Parser::parsePrimaryExpression): * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createRegExp): * runtime/RegExp.cpp: (JSC::RegExp::RegExp): (JSC::RegExp::byteCodeCompileIfNecessary): (JSC::RegExp::compile): (JSC::RegExp::compileMatchOnly): * runtime/RegExp.h: * yarr/RegularExpression.cpp: (JSC::Yarr::RegularExpression::Private::Private): (JSC::Yarr::RegularExpression::Private::compile): * yarr/YarrErrorCode.cpp: Added. (JSC::Yarr::errorMessage): * yarr/YarrErrorCode.h: Copied from Source/JavaScriptCore/yarr/YarrSyntaxChecker.h. (JSC::Yarr::hasError): * yarr/YarrParser.h: (JSC::Yarr::Parser::CharacterClassParserDelegate::CharacterClassParserDelegate): (JSC::Yarr::Parser::CharacterClassParserDelegate::atomPatternCharacter): (JSC::Yarr::Parser::Parser): (JSC::Yarr::Parser::isIdentityEscapeAnError): (JSC::Yarr::Parser::parseEscape): (JSC::Yarr::Parser::parseCharacterClass): (JSC::Yarr::Parser::parseParenthesesBegin): (JSC::Yarr::Parser::parseParenthesesEnd): (JSC::Yarr::Parser::parseQuantifier): (JSC::Yarr::Parser::parseTokens): (JSC::Yarr::Parser::parse): (JSC::Yarr::Parser::tryConsumeUnicodeEscape): (JSC::Yarr::Parser::tryConsumeUnicodePropertyExpression): (JSC::Yarr::parse): * yarr/YarrPattern.cpp: (JSC::Yarr::YarrPatternConstructor::YarrPatternConstructor): (JSC::Yarr::YarrPatternConstructor::setupDisjunctionOffsets): (JSC::Yarr::YarrPatternConstructor::setupOffsets): (JSC::Yarr::YarrPattern::compile): (JSC::Yarr::YarrPattern::YarrPattern): (JSC::Yarr::YarrPattern::errorMessage): Deleted. * yarr/YarrPattern.h: (JSC::Yarr::YarrPattern::reset): * yarr/YarrSyntaxChecker.cpp: (JSC::Yarr::checkSyntax): * yarr/YarrSyntaxChecker.h: 2017-12-18 Saam Barati Follow up to bug#179762. Fix PreciseLocalClobberize to handle Spread/PhantomSpread(PhantomNewArrayBuffer) * dfg/DFGPreciseLocalClobberize.h: (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop): 2017-12-16 Filip Pizlo Vector index masking https://bugs.webkit.org/show_bug.cgi?id=180909 Reviewed by Keith Miller. Adopt index masking for strings. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetCharCodeAt): (JSC::DFG::SpeculativeJIT::compileGetByValOnString): * ftl/FTLAbstractHeapRepository.h: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt): (JSC::FTL::DFG::LowerDFGToB3::compileStringCharCodeAt): * jit/ThunkGenerators.cpp: (JSC::stringCharLoad): 2017-12-17 Yusuke Suzuki [FTL] NewArrayBuffer should be sinked if it is only used for spreading https://bugs.webkit.org/show_bug.cgi?id=179762 Reviewed by Saam Barati. This patch extends arguments elimination phase to accept NewArrayBuffer. We can convert NewArrayBuffer to PhantomNewArrayBuffer if it is only used by spreading nodes. This improves SixSpeed spread.es6 by 3.5x. spread.es6 79.1496+-3.5665 ^ 23.6204+-1.8526 ^ definitely 3.3509x faster * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGArgumentsEliminationPhase.cpp: * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNode.h: (JSC::DFG::Node::hasNewArrayBufferData): (JSC::DFG::Node::hasVectorLengthHint): (JSC::DFG::Node::hasIndexingType): (JSC::DFG::Node::indexingType): (JSC::DFG::Node::hasCellOperand): (JSC::DFG::Node::isPhantomAllocation): * dfg/DFGNodeType.h: * dfg/DFGOSRAvailabilityAnalysisPhase.cpp: (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode): * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGPromotedHeapLocation.cpp: (WTF::printInternal): * dfg/DFGPromotedHeapLocation.h: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGValidate.cpp: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread): (JSC::FTL::DFG::LowerDFGToB3::compileSpread): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs): (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs): (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargsWithSpread): * ftl/FTLOperations.cpp: (JSC::FTL::operationPopulateObjectInOSR): (JSC::FTL::operationMaterializeObjectInOSR): 2017-12-17 Yusuke Suzuki [JSC] Use IsoSpace for JSWeakMap and JSWeakSet to use finalizeUnconditionally https://bugs.webkit.org/show_bug.cgi?id=180916 Reviewed by Darin Adler. This patch drops UnconditionalFinalizer for JSWeakMap and JSWeakSetby using IsoSpace. Since these cells always require calling finalizeUnconditionally, we do not need to track cells by using IsoCellSet. Currently we still have WeakReferenceHarvester in JSWeakMap and JSWeakSet. We should avoid using a global linked-list for this in the future. * JavaScriptCore.xcodeproj/project.pbxproj: * heap/Heap.cpp: (JSC::Heap::finalizeUnconditionalFinalizersInIsoSubspace): (JSC::Heap::finalizeUnconditionalFinalizers): * heap/Heap.h: * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: * runtime/WeakMapImpl.cpp: (JSC::WeakMapImpl::visitChildren): (JSC::WeakMapImpl::finalizeUnconditionally): Deleted. * runtime/WeakMapImpl.h: (JSC::WeakMapImpl::isWeakMap): (JSC::WeakMapImpl::isWeakSet): (JSC::WeakMapImpl::subspaceFor): * runtime/WeakMapImplInlines.h: Added. (JSC::WeakMapImpl::finalizeUnconditionally): 2017-12-17 Mark Lam Hollow out stub implementation of InspectorBackendDispatcher::sendResponse(). https://bugs.webkit.org/show_bug.cgi?id=180901 Reviewed by Darin Adler. We only need to keep a deprecated implementation of InspectorValues, InspectorObjects, and InspectorBackendDispatcher::sendResponse() around so that older versions of Safari can link against and run with a build of the latest code in WebKit trunk. Older versions of System Safari used InspectorValues (via WebInspector.framework) for two things: 1. Augmented JSContexts SPIs (via WebInspector.framework). 2. maybe WebDriver. Neither of these are used when running SafariForWebKitDevelopment. Since neither are used, we can stub out the symbols (InspectorValues, InspectorObjects, InspectorBackendDispatcher::sendResponse) to do nothing, and SafariForWebKitDevelopment will still continue to launch with trunk WebKit, and run without any observable bad behavior. * JavaScriptCore.xcodeproj/project.pbxproj: * SourcesCocoa.txt: * inspector/InspectorBackendDispatcher.cpp: * inspector/InspectorBackendDispatcher.h: * inspector/cocoa/DeprecatedInspectorValues.cpp: (Inspector::InspectorValue::null): (Inspector::InspectorValue::create): (Inspector::InspectorValue::asValue): (Inspector::InspectorValue::asObject): (Inspector::InspectorValue::asArray): (Inspector::InspectorValue::parseJSON): (Inspector::InspectorValue::toJSONString const): (Inspector::InspectorValue::asBoolean const): (Inspector::InspectorValue::asDouble const): (Inspector::InspectorValue::asInteger const): (Inspector::InspectorValue::asString const): (Inspector::InspectorValue::writeJSON const): (Inspector::InspectorValue::memoryCost const): (Inspector::InspectorObjectBase::openAccessors): (Inspector::InspectorObjectBase::memoryCost const): (Inspector::InspectorObjectBase::getBoolean const): (Inspector::InspectorObjectBase::getString const): (Inspector::InspectorObjectBase::getObject const): (Inspector::InspectorObjectBase::getArray const): (Inspector::InspectorObjectBase::getValue const): (Inspector::InspectorObjectBase::remove): (Inspector::InspectorObject::create): (Inspector::InspectorArrayBase::get const): (Inspector::InspectorArrayBase::memoryCost const): (Inspector::InspectorArray::create): (Inspector::BackendDispatcher::sendResponse): (Inspector::InspectorObjectBase::~InspectorObjectBase): Deleted. (Inspector::InspectorObjectBase::asObject): Deleted. (Inspector::InspectorObjectBase::writeJSON const): Deleted. (Inspector::InspectorObjectBase::InspectorObjectBase): Deleted. (Inspector::InspectorArrayBase::~InspectorArrayBase): Deleted. (Inspector::InspectorArrayBase::asArray): Deleted. (Inspector::InspectorArrayBase::writeJSON const): Deleted. (Inspector::InspectorArrayBase::InspectorArrayBase): Deleted. * inspector/cocoa/DeprecatedInspectorValues.h: Removed. 2017-12-17 Yusuke Suzuki [JSC][WebCore][CSSJIT] Remove VM reference in CSSJIT https://bugs.webkit.org/show_bug.cgi?id=180917 Reviewed by Sam Weinig. We do not need to hold JIT flags in VM. We add static VM::{canUseJIT,canUseAssembler,canUseRegExpJIT} functions. * interpreter/AbstractPC.cpp: (JSC::AbstractPC::AbstractPC): * jit/JITThunks.cpp: (JSC::JITThunks::ctiNativeCall): (JSC::JITThunks::ctiNativeConstruct): (JSC::JITThunks::ctiNativeTailCall): (JSC::JITThunks::ctiNativeTailCallWithoutSavedTags): (JSC::JITThunks::ctiInternalFunctionCall): (JSC::JITThunks::ctiInternalFunctionConstruct): (JSC::JITThunks::hostFunctionStub): * llint/LLIntEntrypoint.cpp: (JSC::LLInt::setFunctionEntrypoint): (JSC::LLInt::setEvalEntrypoint): (JSC::LLInt::setProgramEntrypoint): (JSC::LLInt::setModuleProgramEntrypoint): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::shouldJIT): (JSC::LLInt::entryOSR): (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/RegExp.cpp: (JSC::RegExp::compile): (JSC::RegExp::compileMatchOnly): * runtime/VM.cpp: (JSC::VM::canUseAssembler): (JSC::VM::canUseJIT): (JSC::VM::canUseRegExpJIT): (JSC::VM::VM): * runtime/VM.h: (JSC::VM::canUseJIT): Deleted. (JSC::VM::canUseRegExpJIT): Deleted. 2017-12-16 Yusuke Suzuki [JSC] Number of SlotVisitors can increase after setting up m_visitCounters https://bugs.webkit.org/show_bug.cgi?id=180906 Reviewed by Filip Pizlo. The number of SlotVisitors can increase after setting up m_visitCounters. If it happens, our m_visitCounters misses the visit count of newly added SlotVisitors. It accidentally decides that constraints are converged. This leads to random assertion hits in Linux environment. In this patch, we compare the number of SlotVisitors in didVisitSomething(). If the number of SlotVisitors is changed, we conservatively say we did visit something. * heap/Heap.h: * heap/HeapInlines.h: (JSC::Heap::numberOfSlotVisitors): * heap/MarkingConstraintSet.h: * heap/MarkingConstraintSolver.cpp: (JSC::MarkingConstraintSolver::didVisitSomething const): 2017-12-16 Keith Miller Indexing should only be computed when the new structure has an indexing header. https://bugs.webkit.org/show_bug.cgi?id=180895 Reviewed by Saam Barati. If we don't have an indexing header then we point the butterfly sizeof(IndexingHeader) past the end of the butterfly. This makes the computation of the offset simpler since it doesn't depend on the indexing headeriness of the butterfly. * jit/JITOperations.cpp: * runtime/JSObject.cpp: (JSC::JSObject::createInitialUndecided): (JSC::JSObject::createInitialInt32): (JSC::JSObject::createInitialDouble): (JSC::JSObject::createInitialContiguous): (JSC::JSObject::createArrayStorage): (JSC::JSObject::convertUndecidedToArrayStorage): (JSC::JSObject::convertInt32ToArrayStorage): (JSC::JSObject::convertDoubleToArrayStorage): * runtime/JSObject.h: (JSC::JSObject::setButterfly): (JSC::JSObject::nukeStructureAndSetButterfly): * runtime/JSObjectInlines.h: (JSC::JSObject::prepareToPutDirectWithoutTransition): (JSC::JSObject::putDirectInternal): 2017-12-15 Ryan Haddad Unreviewed, rolling out r225941. This change introduced LayoutTest crashes and assertion failures. Reverted changeset: "Web Inspector: replace HTMLCanvasElement with CanvasRenderingContext for instrumentation logic" https://bugs.webkit.org/show_bug.cgi?id=180770 https://trac.webkit.org/changeset/225941 2017-12-15 Yusuke Suzuki Unreviewed, 32bit JSEmpty is not nullptr + CellTag https://bugs.webkit.org/show_bug.cgi?id=180804 Add 32bit path for WeakMapGet. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileWeakMapGet): 2017-12-14 Saam Barati The CleanUp after LICM is erroneously removing a Check https://bugs.webkit.org/show_bug.cgi?id=180852 Reviewed by Filip Pizlo. There was a bug where CleanUp phase relied on isProved() bits and LICM changed them in an invalid way. The bug is as follows: We have two loops, L1 and L2, and two preheaders, P1 and P2. L2 is nested inside of L1. We have a Check inside a node inside L1, say in basic block BB, and that Check dominates all of L2. This is also a hoisting candidate, so we hoist it outside of L1 and put it inside P1. Then, when we run AI, we look at the preheader for each loop inside L1, so P1 and P2. When considering P2, we execute the Check. Inside P2, before any hoisting is done, this Check is dead code, because BB dominates P2. When we use AI to "execute" the Check, it'll set its proof status to proved. This is because inside P2, in the program before LICM runs, the Check is indeed proven at P2. But it is not proven inside P1. This "execute" call will set our proof status for the node inside *P1*, hence, we crash. The fix here is to make LICM precise when updating the ProofStatus of an edge. It can trust the AI state at the preheader it hoists the node to, but it can't trust the state when executing effects inside inner loops's preheaders. * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThreadImpl): 2017-12-14 David Kilzer Enable -Wstrict-prototypes for WebKit Rubber-stamped by Joseph Pecoraro. * API/tests/CompareAndSwapTest.h: (testCompareAndSwap): Add 'void' to C function declaration. * API/tests/ExecutionTimeLimitTest.h: (testExecutionTimeLimit): Ditto. * API/tests/FunctionOverridesTest.h: (testFunctionOverrides): Ditto. * API/tests/GlobalContextWithFinalizerTest.h: (testGlobalContextWithFinalizer): Ditto. * API/tests/JSONParseTest.h: (testJSONParse): Ditto. * API/tests/MultithreadedMultiVMExecutionTest.h: (startMultithreadedMultiVMExecutionTest): Ditto. (finalizeMultithreadedMultiVMExecutionTest): Ditto. * API/tests/PingPongStackOverflowTest.h: (testPingPongStackOverflow): Ditto. * Configurations/Base.xcconfig: (CLANG_WARN_STRICT_PROTOTYPES): Add. Set to YES. 2017-12-14 Yusuke Suzuki [DFG] Reduce register pressure of WeakMapGet to be used for 32bit https://bugs.webkit.org/show_bug.cgi?id=180804 Reviewed by Saam Barati. This fixes 32bit failures of JSC by reducing register pressure of WeakMapGet. * dfg/DFGRegisterBank.h: (JSC::DFG::RegisterBank::lockedCount const): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileWeakMapGet): 2017-12-14 Keith Miller Unreviewed, forgot to add { } * runtime/JSObject.h: (JSC::JSObject::setButterfly): (JSC::JSObject::nukeStructureAndSetButterfly): 2017-12-14 Devin Rousso Web Inspector: replace HTMLCanvasElement with CanvasRenderingContext for instrumentation logic https://bugs.webkit.org/show_bug.cgi?id=180770 Reviewed by Joseph Pecoraro. * inspector/protocol/Canvas.json: 2017-12-14 Keith Miller Fix assertion in JSObject's structure setting methods https://bugs.webkit.org/show_bug.cgi?id=180840 Reviewed by Mark Lam. I forgot that when Typed Arrays have non-indexed properties added to them, they call the generic code. The generic code in turn calls the regular structure setting methods. Thus, these assertions were invalid and we should just avoid setting the indexing mask if we have a Typed Array. * runtime/JSObject.h: (JSC::JSObject::setButterfly): (JSC::JSObject::nukeStructureAndSetButterfly): 2017-12-14 Michael Saboff REGRESSION (r225695): Repro crash on yahoo login page https://bugs.webkit.org/show_bug.cgi?id=180761 Reviewed by JF Bastien. Relanding r225695 with a fix. The fix is that we need to save the return address for a parentheses in the ParenContext because it is actually used by any immediately contained alternatives. Also did a little refactoring, changing occurances of PatternContext to ParenContext since that is the name of the structure. * runtime/RegExp.cpp: (JSC::byteCodeCompilePattern): (JSC::RegExp::byteCodeCompileIfNecessary): (JSC::RegExp::compile): (JSC::RegExp::compileMatchOnly): * runtime/RegExp.h: * runtime/RegExpInlines.h: (JSC::RegExp::matchInline): * testRegExp.cpp: (parseRegExpLine): (runFromFiles): * yarr/Yarr.h: * yarr/YarrInterpreter.cpp: (JSC::Yarr::ByteCompiler::compile): (JSC::Yarr::ByteCompiler::dumpDisjunction): * yarr/YarrJIT.cpp: (JSC::Yarr::YarrGenerator::ParenContextSizes::ParenContextSizes): (JSC::Yarr::YarrGenerator::ParenContextSizes::numSubpatterns): (JSC::Yarr::YarrGenerator::ParenContextSizes::frameSlots): (JSC::Yarr::YarrGenerator::ParenContext::sizeFor): (JSC::Yarr::YarrGenerator::ParenContext::nextOffset): (JSC::Yarr::YarrGenerator::ParenContext::beginOffset): (JSC::Yarr::YarrGenerator::ParenContext::matchAmountOffset): (JSC::Yarr::YarrGenerator::ParenContext::returnAddressOffset): (JSC::Yarr::YarrGenerator::ParenContext::subpatternOffset): (JSC::Yarr::YarrGenerator::ParenContext::savedFrameOffset): (JSC::Yarr::YarrGenerator::initParenContextFreeList): (JSC::Yarr::YarrGenerator::allocateParenContext): (JSC::Yarr::YarrGenerator::freeParenContext): (JSC::Yarr::YarrGenerator::saveParenContext): (JSC::Yarr::YarrGenerator::restoreParenContext): (JSC::Yarr::YarrGenerator::tryReadUnicodeCharImpl): (JSC::Yarr::YarrGenerator::storeToFrame): (JSC::Yarr::YarrGenerator::generateJITFailReturn): (JSC::Yarr::YarrGenerator::clearMatches): (JSC::Yarr::YarrGenerator::generate): (JSC::Yarr::YarrGenerator::backtrack): (JSC::Yarr::YarrGenerator::opCompileParenthesesSubpattern): (JSC::Yarr::YarrGenerator::generateEnter): (JSC::Yarr::YarrGenerator::generateReturn): (JSC::Yarr::YarrGenerator::YarrGenerator): (JSC::Yarr::YarrGenerator::compile): * yarr/YarrJIT.h: (JSC::Yarr::YarrCodeBlock::execute): * yarr/YarrPattern.cpp: (JSC::Yarr::indentForNestingLevel): (JSC::Yarr::dumpUChar32): (JSC::Yarr::dumpCharacterClass): (JSC::Yarr::PatternTerm::dump): (JSC::Yarr::YarrPattern::dumpPattern): * yarr/YarrPattern.h: (JSC::Yarr::PatternTerm::containsAnyCaptures): (JSC::Yarr::BackTrackInfoParenthesesOnce::returnAddressIndex): (JSC::Yarr::BackTrackInfoParentheses::beginIndex): (JSC::Yarr::BackTrackInfoParentheses::returnAddressIndex): (JSC::Yarr::BackTrackInfoParentheses::matchAmountIndex): (JSC::Yarr::BackTrackInfoParentheses::parenContextHeadIndex): (JSC::Yarr::BackTrackInfoAlternative::offsetIndex): Deleted. 2017-12-13 Keith Miller JSObjects should have a mask for loading indexed properties https://bugs.webkit.org/show_bug.cgi?id=180768 Reviewed by Mark Lam. This patch adds a new member to JSObject that holds an indexing mask. The indexing mask is bitwise anded with the index used to load a property. If for whatever reason an attacker is able to clobber the vectorLength of our butterfly they still won't be able to read substantially past the end of the buttefly. For performance reasons we don't use the indexing masking for TypedArrays. Since TypedArrays are already gigacaged the risk of wild reads is still restricted. This patch is a <1% regression on Speedometer and ~3% regression on JetStream in my testing. * assembler/MacroAssembler.h: (JSC::MacroAssembler::urshiftPtr): * bytecode/AccessCase.cpp: (JSC::AccessCase::generateImpl): * dfg/DFGAbstractHeap.h: * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::emitAllocateRawObject): (JSC::DFG::SpeculativeJIT::compileDoublePutByVal): (JSC::DFG::SpeculativeJIT::compileNewFunctionCommon): (JSC::DFG::SpeculativeJIT::compileCreateActivation): (JSC::DFG::SpeculativeJIT::compileCreateDirectArguments): (JSC::DFG::SpeculativeJIT::compileArraySlice): (JSC::DFG::SpeculativeJIT::compileNukeStructureAndSetButterfly): (JSC::DFG::SpeculativeJIT::compileNewStringObject): (JSC::DFG::SpeculativeJIT::compileNewTypedArray): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::emitAllocateJSObject): (JSC::DFG::SpeculativeJIT::emitAllocateJSObjectWithKnownSize): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize): * ftl/FTLAbstractHeap.cpp: (JSC::FTL::IndexedAbstractHeap::baseIndex): * ftl/FTLAbstractHeap.h: * ftl/FTLAbstractHeapRepository.h: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileAtomicsReadModifyWrite): (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal): (JSC::FTL::DFG::LowerDFGToB3::compileCreateActivation): (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction): (JSC::FTL::DFG::LowerDFGToB3::compileCreateDirectArguments): (JSC::FTL::DFG::LowerDFGToB3::compileNewStringObject): (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray): (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject): (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation): (JSC::FTL::DFG::LowerDFGToB3::maskedIndex): (JSC::FTL::DFG::LowerDFGToB3::computeButterflyIndexingMask): (JSC::FTL::DFG::LowerDFGToB3::allocateObject): (JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedObject): (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray): (JSC::FTL::DFG::LowerDFGToB3::pointerIntoTypedArray): * ftl/FTLOutput.h: (JSC::FTL::Output::baseIndex): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::emitComputeButterflyIndexingMask): (JSC::AssemblyHelpers::nukeStructureAndStoreButterfly): (JSC::AssemblyHelpers::emitAllocateJSObject): (JSC::AssemblyHelpers::emitAllocateJSObjectWithKnownSize): (JSC::AssemblyHelpers::emitAllocateVariableSizedJSObject): (JSC::AssemblyHelpers::emitAllocateDestructibleObject): (JSC::AssemblyHelpers::storeButterfly): Deleted. * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_new_object): (JSC::JIT::emit_op_create_this): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_new_object): (JSC::JIT::emit_op_create_this): * jit/JITPropertyAccess.cpp: (JSC::JIT::emitDoubleLoad): (JSC::JIT::emitContiguousLoad): (JSC::JIT::emitArrayStorageLoad): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/ArrayStorage.h: (JSC::ArrayStorage::availableVectorLength): * runtime/Butterfly.h: (JSC::ContiguousData::ContiguousData): (JSC::ContiguousData::at const): (JSC::ContiguousData::at): (JSC::Butterfly::publicLength const): (JSC::Butterfly::vectorLength const): (JSC::Butterfly::computeIndexingMaskForVectorLength): (JSC::Butterfly::computeIndexingMask): (JSC::Butterfly::contiguousInt32): (JSC::ContiguousData::operator[] const): Deleted. (JSC::ContiguousData::operator[]): Deleted. (JSC::Butterfly::publicLength): Deleted. (JSC::Butterfly::vectorLength): Deleted. * runtime/ButterflyInlines.h: (JSC::ContiguousData::at const): (JSC::ContiguousData::at): * runtime/ClonedArguments.cpp: (JSC::ClonedArguments::createEmpty): * runtime/JSArray.cpp: (JSC::JSArray::tryCreateUninitializedRestricted): (JSC::JSArray::appendMemcpy): (JSC::JSArray::setLength): (JSC::JSArray::pop): (JSC::JSArray::fastSlice): (JSC::JSArray::shiftCountWithArrayStorage): (JSC::JSArray::shiftCountWithAnyIndexingType): (JSC::JSArray::unshiftCountWithAnyIndexingType): (JSC::JSArray::fillArgList): (JSC::JSArray::copyToArguments): * runtime/JSArrayBufferView.cpp: (JSC::JSArrayBufferView::JSArrayBufferView): * runtime/JSArrayInlines.h: (JSC::JSArray::pushInline): * runtime/JSFixedArray.h: (JSC::JSFixedArray::createFromArray): * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::slowDownAndWasteMemory): * runtime/JSObject.cpp: (JSC::JSObject::getOwnPropertySlotByIndex): (JSC::JSObject::putByIndex): (JSC::JSObject::createInitialInt32): (JSC::JSObject::createInitialDouble): (JSC::JSObject::createInitialContiguous): (JSC::JSObject::convertUndecidedToInt32): (JSC::JSObject::convertUndecidedToDouble): (JSC::JSObject::convertUndecidedToContiguous): (JSC::JSObject::convertInt32ToDouble): (JSC::JSObject::convertInt32ToArrayStorage): (JSC::JSObject::convertDoubleToContiguous): (JSC::JSObject::convertDoubleToArrayStorage): (JSC::JSObject::convertContiguousToArrayStorage): (JSC::JSObject::createInitialForValueAndSet): (JSC::JSObject::deletePropertyByIndex): (JSC::JSObject::getOwnPropertyNames): (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes): (JSC::JSObject::countElements): (JSC::JSObject::ensureLengthSlow): (JSC::JSObject::reallocateAndShrinkButterfly): (JSC::JSObject::getEnumerableLength): * runtime/JSObject.h: (JSC::JSObject::canGetIndexQuickly): (JSC::JSObject::getIndexQuickly): (JSC::JSObject::tryGetIndexQuickly const): (JSC::JSObject::setIndexQuickly): (JSC::JSObject::initializeIndex): (JSC::JSObject::initializeIndexWithoutBarrier): (JSC::JSObject::butterflyIndexingMaskOffset): (JSC::JSObject::butterflyIndexingMask const): (JSC::JSObject::setButterflyWithIndexingMask): (JSC::JSObject::setButterfly): (JSC::JSObject::nukeStructureAndSetButterfly): (JSC::JSObject::JSObject): * runtime/RegExpMatchesArray.h: (JSC::tryCreateUninitializedRegExpMatchesArray): * runtime/Structure.cpp: (JSC::Structure::flattenDictionaryStructure): 2017-12-14 David Kilzer REGRESSION (r225799/r225887): Remove duplicate entries for JSCPoisonedPtr.h in Xcode project Fixes the following warning during builds: Warning: Multiple build commands for output file WebKitBuild/Release/JavaScriptCore.framework/Versions/A/PrivateHeaders/JSCPoisonedPtr.h * JavaScriptCore.xcodeproj/project.pbxproj: Remove duplicate entries for JSCPoisonedPtr.h. 2017-12-14 David Kilzer REGRESSION (r225887): Build broke due to missing includes in InferredValue.h * runtime/InferredValue.h: Attempt to fix build by adding missing #include statements. 2017-12-13 Filip Pizlo Octane/richards regressed by a whopping 20% because eliminateCommonSubexpressions has a weird fixpoint requirement https://bugs.webkit.org/show_bug.cgi?id=180783 Reviewed by Saam Barati. This fixes the regression by fixpointing CSE. We need to fixpoint CSE because of this case: BB#1: a: Load(@x) b: Load(@x) c: Load(@b) BB#2: d: Load(@b) BB#3: e: Load(@b) Lets assume that #3 loops around to #2, so to eliminate @d, we need to prove that it's redundant with both @c and @e. The problem is that by the time we get to @d, the CSE state will look like this: BB#1: a: Load(@x) b: Load(@x) c: Load(@a) memoryAtTail: {@x=>@a, @a=>@c} BB#2: d: Load(@a) [sic] memoryAtTail: {@b=>@d} BB#3: e: Load(@b) memoryAtTail: {@b=>@e} [sic] Note that #3's atTail map is keyed on @b, which was the old (no longer canonical) version of @a. But @d's children were already substituted, so it refers to @a. Since @a is not in #3's atTail map, we don't find it and leave the redundancy. I think that the cleanest solution is to fixpoint. CSE is pretty cheap, so hopefully we can afford this. It fixes the richards regression, since richards is super dependent on B3 CSE. * b3/B3EliminateCommonSubexpressions.cpp: Logging. * b3/B3Generate.cpp: (JSC::B3::generateToAir): Fix the bug. * b3/air/AirReportUsedRegisters.cpp: (JSC::B3::Air::reportUsedRegisters): Logging. * dfg/DFGByteCodeParser.cpp: * dfg/DFGSSAConversionPhase.cpp: (JSC::DFG::SSAConversionPhase::run): Don't generate EntrySwitch if we don't need it (makes IR easier to read). * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::lower): Don't generate EntrySwitch if we don't need it (makes IR easier to read). 2017-12-13 Joseph Pecoraro REGRESSION: Web Inspector: Opening inspector crashes page if there are empty resources https://bugs.webkit.org/show_bug.cgi?id=180787 Reviewed by Brian Burg. * inspector/ContentSearchUtilities.cpp: (Inspector::ContentSearchUtilities::findMagicComment): For empty / null strings just return. There is no use trying to search them for a long common syntax. 2017-12-13 Saam Barati Arrow functions need their own structure because they have different properties than sloppy functions https://bugs.webkit.org/show_bug.cgi?id=180779 Reviewed by Mark Lam. We were using the same structure for sloppy functions and arrow functions. This broke our IC caching machinery because these two types of functions actually have different properties. This patch gives them different structures. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileNewFunction): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction): * runtime/FunctionConstructor.cpp: (JSC::constructFunctionSkippingEvalEnabledCheck): * runtime/JSFunction.cpp: (JSC::JSFunction::selectStructureForNewFuncExp): (JSC::JSFunction::create): * runtime/JSFunction.h: * runtime/JSFunctionInlines.h: (JSC::JSFunction::createWithInvalidatedReallocationWatchpoint): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildren): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::arrowFunctionStructure const): 2017-12-12 Filip Pizlo InferredValue should use IsoSubspace https://bugs.webkit.org/show_bug.cgi?id=180738 Reviewed by Keith Miller. This moves InferredValue into an IsoSubspace and then takes advantage of this to get rid of its UnconditionalFinalizer. * JavaScriptCore.xcodeproj/project.pbxproj: * heap/Heap.cpp: (JSC::Heap::finalizeUnconditionalFinalizers): * runtime/InferredValue.cpp: (JSC::InferredValue::visitChildren): (JSC::InferredValue::ValueCleanup::ValueCleanup): Deleted. (JSC::InferredValue::ValueCleanup::~ValueCleanup): Deleted. (JSC::InferredValue::ValueCleanup::finalizeUnconditionally): Deleted. * runtime/InferredValue.h: (JSC::InferredValue::subspaceFor): * runtime/InferredValueInlines.h: Added. (JSC::InferredValue::finalizeUnconditionally): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2017-12-13 Devin Rousso Web Inspector: add instrumentation for ImageBitmapRenderingContext https://bugs.webkit.org/show_bug.cgi?id=180736 Reviewed by Joseph Pecoraro. * inspector/protocol/Canvas.json: * inspector/scripts/codegen/generator.py: 2017-12-13 Saam Barati Take a value driven approach to how we emit structure checks in TypeCheckHoistingPhase to obviate the need for static_assert guards https://bugs.webkit.org/show_bug.cgi?id=180771 Reviewed by JF Bastien. * dfg/DFGTypeCheckHoistingPhase.cpp: (JSC::DFG::TypeCheckHoistingPhase::run): 2017-12-13 Saam Barati REGRESSION(r225844): Around 850 new JSC failures on 32-bit https://bugs.webkit.org/show_bug.cgi?id=180764 Unreviewed. We should only emit CheckStructureOrEmpty on 64 bit platforms. * dfg/DFGTypeCheckHoistingPhase.cpp: (JSC::DFG::TypeCheckHoistingPhase::run): 2017-12-13 Michael Saboff Unreviewed rollout of r225695. Caused a crash on yahoo login page. That bug tracked in https://bugs.webkit.org/show_bug.cgi?id=180761. * runtime/RegExp.cpp: (JSC::RegExp::compile): (JSC::RegExp::compileMatchOnly): (JSC::byteCodeCompilePattern): Deleted. (JSC::RegExp::byteCodeCompileIfNecessary): Deleted. * runtime/RegExp.h: * runtime/RegExpInlines.h: (JSC::RegExp::matchInline): * testRegExp.cpp: (parseRegExpLine): (runFromFiles): * yarr/Yarr.h: * yarr/YarrInterpreter.cpp: (JSC::Yarr::ByteCompiler::compile): (JSC::Yarr::ByteCompiler::dumpDisjunction): (JSC::Yarr::ByteCompiler::emitDisjunction): * yarr/YarrJIT.cpp: (JSC::Yarr::YarrGenerator::tryReadUnicodeCharImpl): (JSC::Yarr::YarrGenerator::generate): (JSC::Yarr::YarrGenerator::backtrack): (JSC::Yarr::YarrGenerator::opCompileParenthesesSubpattern): (JSC::Yarr::YarrGenerator::generateEnter): (JSC::Yarr::YarrGenerator::generateReturn): (JSC::Yarr::YarrGenerator::YarrGenerator): (JSC::Yarr::YarrGenerator::compile): (JSC::Yarr::YarrGenerator::ParenContextSizes::ParenContextSizes): Deleted. (JSC::Yarr::YarrGenerator::ParenContextSizes::numSubpatterns): Deleted. (JSC::Yarr::YarrGenerator::ParenContextSizes::frameSlots): Deleted. (JSC::Yarr::YarrGenerator::ParenContext::sizeFor): Deleted. (JSC::Yarr::YarrGenerator::ParenContext::nextOffset): Deleted. (JSC::Yarr::YarrGenerator::ParenContext::beginOffset): Deleted. (JSC::Yarr::YarrGenerator::ParenContext::matchAmountOffset): Deleted. (JSC::Yarr::YarrGenerator::ParenContext::subpatternOffset): Deleted. (JSC::Yarr::YarrGenerator::ParenContext::savedFrameOffset): Deleted. (JSC::Yarr::YarrGenerator::initParenContextFreeList): Deleted. (JSC::Yarr::YarrGenerator::allocatePatternContext): Deleted. (JSC::Yarr::YarrGenerator::freePatternContext): Deleted. (JSC::Yarr::YarrGenerator::savePatternContext): Deleted. (JSC::Yarr::YarrGenerator::restorePatternContext): Deleted. (JSC::Yarr::YarrGenerator::generateJITFailReturn): Deleted. (JSC::Yarr::YarrGenerator::clearMatches): Deleted. * yarr/YarrJIT.h: (JSC::Yarr::YarrCodeBlock::execute): * yarr/YarrPattern.cpp: (JSC::Yarr::indentForNestingLevel): (JSC::Yarr::dumpUChar32): (JSC::Yarr::PatternTerm::dump): (JSC::Yarr::YarrPattern::dumpPattern): (JSC::Yarr::dumpCharacterClass): Deleted. * yarr/YarrPattern.h: (JSC::Yarr::BackTrackInfoAlternative::offsetIndex): (JSC::Yarr::BackTrackInfoParenthesesOnce::beginIndex): (JSC::Yarr::PatternTerm::containsAnyCaptures): Deleted. (JSC::Yarr::BackTrackInfoParenthesesOnce::returnAddressIndex): Deleted. (JSC::Yarr::BackTrackInfoParentheses::beginIndex): Deleted. (JSC::Yarr::BackTrackInfoParentheses::returnAddressIndex): Deleted. (JSC::Yarr::BackTrackInfoParentheses::matchAmountIndex): Deleted. (JSC::Yarr::BackTrackInfoParentheses::patternContextHeadIndex): Deleted. 2017-12-13 Mark Lam Fill out some Poisoned APIs, fix some bugs, and add some tests. https://bugs.webkit.org/show_bug.cgi?id=180724 Reviewed by JF Bastien. * runtime/StructureTransitionTable.h: 2017-12-13 Caio Lima [ESNext][BigInt] Breking tests on Debug build and 32-bits due to missing Exception check https://bugs.webkit.org/show_bug.cgi?id=180746 Reviewed by Saam Barati. We have some uncatched exceptions that could happen due to OOM into JSBigInt::allocateFor and JSBigInt::toStringGeneric. This patching is catching such exceptions properly. * runtime/JSBigInt.cpp: (JSC::JSBigInt::allocateFor): (JSC::JSBigInt::parseInt): * runtime/JSCJSValue.cpp: (JSC::JSValue::toStringSlowCase const): 2017-12-13 Saam Barati Fix how JSFunction handles "caller" and "arguments" for functions that don't have those properties https://bugs.webkit.org/show_bug.cgi?id=163579 Reviewed by Mark Lam. Some functions in JavaScript do not have the "caller" and "arguments" properties. For example, strict functions do not. When reading our code that dealt with these types of functions, it was simply all wrong. We were doing weird things depending on the method table hook. This patch fixes this by doing what we should've been doing all along: when the JSFunction does not own the "caller"/"arguments" property, it should defer to its base class implementation for the various method table hooks. * runtime/JSFunction.cpp: (JSC::JSFunction::put): (JSC::JSFunction::deleteProperty): (JSC::JSFunction::defineOwnProperty): 2017-12-13 Saam Barati TypeCheckHoistingPhase needs to emit a CheckStructureOrEmpty if it's doing it for |this| https://bugs.webkit.org/show_bug.cgi?id=180734 Reviewed by Yusuke Suzuki. The |this| value may be TDZ. If type check hoisting phase hoists a CheckStructure to it, it will crash. This patch makes it so we emit CheckStructureOrEmpty for |this|. * dfg/DFGTypeCheckHoistingPhase.cpp: (JSC::DFG::TypeCheckHoistingPhase::run): 2017-12-12 Yusuke Suzuki [JSC] Optimize Object.assign by single transition acceleration https://bugs.webkit.org/show_bug.cgi?id=180644 Reviewed by Saam Barati. Handling single transition is critical. Since this get() function is only used in Structure.cpp's 2 functions and it is quite small, we can annotate `inline` to accelerate it. This improves SixSpeed/object-assign.es6 by 2.8%. baseline patched object-assign.es6 382.3548+-8.0461 371.6496+-5.7439 might be 1.0288x faster * runtime/Structure.cpp: (JSC::StructureTransitionTable::get const): 2017-12-12 Filip Pizlo Structure, StructureRareData, and PropertyTable should be in IsoSubspaces https://bugs.webkit.org/show_bug.cgi?id=180732 Rubber stamped by Mark Lam. We should eventually move all fixed-size cells into IsoSubspaces. I don't know if they are scalable enough to support that, so we should do it carefully. * heap/MarkedSpace.cpp: * runtime/PropertyMapHashTable.h: * runtime/Structure.h: * runtime/StructureRareData.h: * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2017-12-12 Saam Barati We need to model effects of Spread(@PhantomCreateRest) in Clobberize/PreciseLocalClobberize https://bugs.webkit.org/show_bug.cgi?id=180725 Reviewed by Michael Saboff. * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGPreciseLocalClobberize.h: (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop): 2017-12-12 Yusuke Suzuki [JSC] Implement optimized WeakMap and WeakSet https://bugs.webkit.org/show_bug.cgi?id=179929 Reviewed by Saam Barati. This patch introduces WeakMapImpl to optimize WeakMap and WeakSet. This is similar to HashMapImpl. But, 1. WeakMapImpl's bucket is not allocated in GC heap since WeakMap do not need to have iterators. 2. WeakMapImpl's buffer is allocated in JSValue Gigacage instead of auxiliary buffer. This is because we would like to allocate buffer when finalizing GC. At that time, WeakMapImpl prunes dead entries and shrink it if necessary. However, allocating from the GC heap during finalization is not allowed. In particular, (2) is important since it ensures any WeakMap operations do not cause GC. Since GC may collect dead keys in WeakMap, rehash WeakMap, and reallocate/change WeakMap's buffer, ensuring that any WeakMap operations do not cause GC makes our implementation simple. To ensure this, we place DisallowGC for each WeakMap's interface. In DFG, we introduce WeakMapGet and ExtractValueFromWeakMapGet nodes. WeakMapGet looks up entry in WeakMapImpl and returns value. If it is WeakMap, it returns value. And it returns key if it is WeakSet. If it does not find a corresponding entry, it returns JSEmpty. ExtractValueFromWeakMapGet converts JSEmpty to JSUndefined. This patch improves WeakMap and WeakSet operations. baseline patched weak-set-key 240.6932+-10.4923 ^ 148.7606+-6.1784 ^ definitely 1.6180x faster weak-map-key 174.3176+-8.2680 ^ 151.7053+-6.8723 ^ definitely 1.1491x faster * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * dfg/DFGAbstractHeap.h: * 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/DFGNode.h: (JSC::DFG::Node::hasHeapPrediction): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileExtractValueFromWeakMapGet): (JSC::DFG::SpeculativeJIT::compileWeakMapGet): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLAbstractHeapRepository.h: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileExtractValueFromWeakMapGet): (JSC::FTL::DFG::LowerDFGToB3::compileWeakMapGet): * inspector/JSInjectedScriptHost.cpp: (Inspector::JSInjectedScriptHost::weakMapEntries): (Inspector::JSInjectedScriptHost::weakSetEntries): Existing code is incorrect. They can run GC and break WeakMap's iterator. We introduce takeSnapshot function to WeakMapImpl, which retrieves live entries without causing any GC. * runtime/HashMapImpl.h: (JSC::shouldShrink): (JSC::shouldRehashAfterAdd): (JSC::nextCapacity): (JSC::HashMapImpl::shouldRehashAfterAdd const): (JSC::HashMapImpl::shouldShrink const): (JSC::HashMapImpl::rehash): (JSC::WeakMapHash::hash): Deleted. (JSC::WeakMapHash::equal): Deleted. * runtime/Intrinsic.cpp: (JSC::intrinsicName): * runtime/Intrinsic.h: * runtime/JSWeakMap.cpp: * runtime/JSWeakMap.h: * runtime/JSWeakSet.cpp: * runtime/JSWeakSet.h: * runtime/VM.cpp: * runtime/WeakGCMap.h: (JSC::WeakGCMap::forEach): Deleted. * runtime/WeakMapBase.cpp: Removed. * runtime/WeakMapBase.h: Removed. * runtime/WeakMapConstructor.cpp: (JSC::constructWeakMap): * runtime/WeakMapImpl.cpp: Added. (JSC::WeakMapImpl::destroy): (JSC::WeakMapImpl::visitChildren): (JSC::WeakMapImpl::estimatedSize): (JSC::WeakMapImpl>::visitWeakReferences): (JSC::WeakMapImpl>::visitWeakReferences): (JSC::WeakMapImpl::finalizeUnconditionally): (JSC::WeakMapImpl>::takeSnapshot): (JSC::WeakMapImpl>::takeSnapshot): * runtime/WeakMapImpl.h: Added. (JSC::jsWeakMapHash): (JSC::nextCapacityAfterRemoveBatching): (JSC::WeakMapBucket::setKey): (JSC::WeakMapBucket::setValue): (JSC::WeakMapBucket::key const): (JSC::WeakMapBucket::value const): (JSC::WeakMapBucket::copyFrom): (JSC::WeakMapBucket::offsetOfKey): (JSC::WeakMapBucket::offsetOfValue): (JSC::WeakMapBucket::extractValue): (JSC::WeakMapBucket::isEmpty): (JSC::WeakMapBucket::deletedKey): (JSC::WeakMapBucket::isDeleted): (JSC::WeakMapBucket::makeDeleted): (JSC::WeakMapBucket::visitAggregate): (JSC::WeakMapBucket::clearValue): (JSC::WeakMapBuffer::allocationSize): (JSC::WeakMapBuffer::buffer const): (JSC::WeakMapBuffer::create): (JSC::WeakMapBuffer::reset): (JSC::WeakMapImpl::WeakMapImpl): (JSC::WeakMapImpl::finishCreation): (JSC::WeakMapImpl::get): (JSC::WeakMapImpl::has): (JSC::WeakMapImpl::add): (JSC::WeakMapImpl::remove): (JSC::WeakMapImpl::size const): (JSC::WeakMapImpl::offsetOfBuffer): (JSC::WeakMapImpl::offsetOfCapacity): (JSC::WeakMapImpl::findBucket): (JSC::WeakMapImpl::buffer const): (JSC::WeakMapImpl::forEach): (JSC::WeakMapImpl::shouldRehashAfterAdd const): (JSC::WeakMapImpl::shouldShrink const): (JSC::WeakMapImpl::canUseBucket): (JSC::WeakMapImpl::addInternal): (JSC::WeakMapImpl::findBucketAlreadyHashed): (JSC::WeakMapImpl::rehash): (JSC::WeakMapImpl::checkConsistency const): (JSC::WeakMapImpl::makeAndSetNewBuffer): (JSC::WeakMapImpl::assertBufferIsEmpty const): (JSC::WeakMapImpl::DeadKeyCleaner::target): * runtime/WeakMapPrototype.cpp: (JSC::WeakMapPrototype::finishCreation): (JSC::protoFuncWeakMapGet): (JSC::protoFuncWeakMapHas): * runtime/WeakSetConstructor.cpp: (JSC::constructWeakSet): * runtime/WeakSetPrototype.cpp: (JSC::WeakSetPrototype::finishCreation): (JSC::protoFuncWeakSetHas): (JSC::protoFuncWeakSetAdd): 2017-12-11 Filip Pizlo It should be possible to flag a cell for unconditional finalization https://bugs.webkit.org/show_bug.cgi?id=180636 Reviewed by Saam Barati. UnconditionalFinalizers were annoying - you had to allocate them and you had to manage a global linked list - but they had some nice properties: - You only did the hardest work (creating the UnconditionalFinalizer) on first GC where you survived and needed it. -> Just needing it wasn't enough. -> Just surviving wasn't enough. The new API based on IsoSubspaces meant that just surviving was enough to cause unconditional finalizer logic to be invoked. I think that's not great. InferredType got around this by making InferredStructure a cell, but this was a gross hack. For one, it meant that InferredStructure would survive during the GC in which its finalizer obviated the need for its existence. It's not really an idiom I want us to repeat because it sounds like the sort of thing that turns out to be subtly broken. We really need to have a way of indicating when you have entered into the state that requires your unconditional finalizer to be invoked. Basically, we want to be able to track the set of objects that need unconditional finalizers. Only the subset of that set that overlaps with the set of marked objects needs to be accurate. The easiest way to do this is a hierarchy of bitvectors: one to say which MarkedBlocks have objects that have unconditional finalizers, and another level to say which atoms within a MarkedBlock have unconditional finalizers. This change introduces IsoCellSet, which couples itself to the MarkedAllocator of some IsoSubspace to allow maintaining a set of objects (well, cells - you could do this with auxiliaries) that belong to that IsoSubspace. It'll have undefined behavior if you try to add/remove/contains an object that isn't in that IsoSubspace. For objects in that subspace, you can add/remove/contains and forEachMarkedCell. The cost of each IsoCellSet is at worst about 0.8% increase in size to every object in the subspace that the set is attached to. So, it makes sense to have a handful per subspace max. This change only needs one per subspace, but you could imagine more if we do this for WeakReferenceHarvester. To absolutely minimize the possibility that this incurs costs, the add/remove/contains functions can be used from any thread so long as forEachMarkedCell isn't running. This means that InferredType only needs to add itself to the set during visitChildren. Thus, it needs to both survive and need it for the hardest work to take place. The work of adding does involve a gnarly load chain that ends in a CAS: load block handle from block, load index, load segment, load bitvector, load bit -> if not set, then CAS. That's five dependent loads! However, it's perfect for running in parallel since the only write operations are to widely dispersed cache lines that contain the bits underlying the set. The best part is how forEachMarkedCell works. That skips blocks that don't have any objects that need unconditional finalizers, and only touches the memory of marked objects that have the unconditional finalizer bit set. It will walk those objects in roughly address order. I previously found that this speeds up walking over a lot of objects when I made similar changes for DOM GC (calling visitAdditionalChildren via forEachMarkedCell rather than by walking a HashSet). This change makes InferredStructure be a malloc object again, but now it's in an IsoHeap. My expectation for this change is that it's perf-neutral. Long-term, it gives us a path forward for eliminating UnconditionalFinalizer and WeakReferenceHarvester while using IsoSubspace in more places. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * heap/AtomIndices.h: Added. (JSC::AtomIndices::AtomIndices): * heap/Heap.cpp: (JSC::Heap::finalizeUnconditionalFinalizers): * heap/Heap.h: * heap/IsoCellSet.cpp: Added. (JSC::IsoCellSet::IsoCellSet): (JSC::IsoCellSet::~IsoCellSet): (JSC::IsoCellSet::addSlow): (JSC::IsoCellSet::didResizeBits): (JSC::IsoCellSet::didRemoveBlock): (JSC::IsoCellSet::sweepToFreeList): * heap/IsoCellSet.h: Added. * heap/IsoCellSetInlines.h: Added. (JSC::IsoCellSet::add): (JSC::IsoCellSet::remove): (JSC::IsoCellSet::contains const): (JSC::IsoCellSet::forEachMarkedCell): * heap/IsoSubspace.cpp: (JSC::IsoSubspace::didResizeBits): (JSC::IsoSubspace::didRemoveBlock): (JSC::IsoSubspace::didBeginSweepingToFreeList): * heap/IsoSubspace.h: * heap/MarkedAllocator.cpp: (JSC::MarkedAllocator::addBlock): (JSC::MarkedAllocator::removeBlock): * heap/MarkedAllocator.h: * heap/MarkedAllocatorInlines.h: * heap/MarkedBlock.cpp: (JSC::MarkedBlock::Handle::sweep): (JSC::MarkedBlock::Handle::isEmpty): Deleted. * heap/MarkedBlock.h: (JSC::MarkedBlock::marks const): (JSC::MarkedBlock::Handle::newlyAllocated const): * heap/MarkedBlockInlines.h: (JSC::MarkedBlock::Handle::isAllocated): (JSC::MarkedBlock::Handle::isEmpty): (JSC::MarkedBlock::Handle::emptyMode): (JSC::MarkedBlock::Handle::forEachMarkedCell): * heap/Subspace.cpp: (JSC::Subspace::didResizeBits): (JSC::Subspace::didRemoveBlock): (JSC::Subspace::didBeginSweepingToFreeList): * heap/Subspace.h: * heap/SubspaceInlines.h: (JSC::Subspace::forEachMarkedCell): * runtime/InferredStructure.cpp: (JSC::InferredStructure::InferredStructure): (JSC::InferredStructure::create): Deleted. (JSC::InferredStructure::destroy): Deleted. (JSC::InferredStructure::createStructure): Deleted. (JSC::InferredStructure::visitChildren): Deleted. (JSC::InferredStructure::finalizeUnconditionally): Deleted. (JSC::InferredStructure::finishCreation): Deleted. * runtime/InferredStructure.h: * runtime/InferredStructureWatchpoint.cpp: (JSC::InferredStructureWatchpoint::fireInternal): * runtime/InferredType.cpp: (JSC::InferredType::visitChildren): (JSC::InferredType::willStoreValueSlow): (JSC::InferredType::makeTopSlow): (JSC::InferredType::set): (JSC::InferredType::removeStructure): (JSC::InferredType::finalizeUnconditionally): * runtime/InferredType.h: * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2017-12-12 Saam Barati ConstantFoldingPhase rule for GetMyArgumentByVal must check for negative indices https://bugs.webkit.org/show_bug.cgi?id=180723 Reviewed by JF Bastien. * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): 2017-12-04 Brian Burg Web Inspector: modernize InjectedScript a bit https://bugs.webkit.org/show_bug.cgi?id=180367 Reviewed by Timothy Hatcher. Stop using out parameters passed by pointer, use references instead. Stop using OptOutput in favor of std::optional where possible. If there is only one out-parameter and a void return type, then return the value. * inspector/InjectedScript.h: * inspector/InjectedScript.cpp: (Inspector::InjectedScript::evaluate): (Inspector::InjectedScript::callFunctionOn): (Inspector::InjectedScript::evaluateOnCallFrame): (Inspector::InjectedScript::getFunctionDetails): (Inspector::InjectedScript::functionDetails): (Inspector::InjectedScript::getPreview): (Inspector::InjectedScript::getProperties): (Inspector::InjectedScript::getDisplayableProperties): (Inspector::InjectedScript::getInternalProperties): (Inspector::InjectedScript::getCollectionEntries): (Inspector::InjectedScript::saveResult): (Inspector::InjectedScript::setExceptionValue): (Inspector::InjectedScript::clearExceptionValue): (Inspector::InjectedScript::inspectObject): (Inspector::InjectedScript::releaseObject): * inspector/InjectedScriptBase.h: * inspector/InjectedScriptBase.cpp: (Inspector::InjectedScriptBase::InjectedScriptBase): Declare m_environment with a default initializer. (Inspector::InjectedScriptBase::makeCall): (Inspector::InjectedScriptBase::makeEvalCall): Just return the result, no need for an out-parameter. Rearrange some code paths now that we can just return a result. Return a Ref since it is either a result value or error value. Use out_ prefixes in a few places to improve readability. * inspector/agents/InspectorDebuggerAgent.cpp: (Inspector::InspectorDebuggerAgent::getFunctionDetails): (Inspector::InspectorDebuggerAgent::evaluateOnCallFrame): * inspector/agents/InspectorHeapAgent.cpp: (Inspector::InspectorHeapAgent::getPreview): * inspector/agents/InspectorRuntimeAgent.cpp: (Inspector::InspectorRuntimeAgent::evaluate): (Inspector::InspectorRuntimeAgent::callFunctionOn): (Inspector::InspectorRuntimeAgent::getPreview): (Inspector::InspectorRuntimeAgent::getProperties): (Inspector::InspectorRuntimeAgent::getDisplayableProperties): (Inspector::InspectorRuntimeAgent::getCollectionEntries): (Inspector::InspectorRuntimeAgent::saveResult): Adapt to InjectedScript changes. In some cases we need to bridge OptOutput and std::optional until the former is removed from generated method signatures. 2017-12-12 Caio Lima [ESNext][BigInt] Implement BigInt literals and JSBigInt https://bugs.webkit.org/show_bug.cgi?id=179000 Reviewed by Darin Adler and Yusuke Suzuki. This patch starts the implementation of BigInt primitive on JavaScriptCore. We are introducing BigInt primitive and implementing it on JSBigInt as a subclass of JSCell with [[BigIntData]] field implemented contiguosly on memory as inline storage of JSBigInt to take advantages on performance due to cache locality. The implementation allows 64 or 32 bitwise arithmetic operations. JSBigInt also has m_sign to store the sign of [[BigIntData]] and m_length that keeps track of BigInt length. The implementation is following the V8 one. [[BigIntData]] is manipulated by JSBigInt::setDigit(index, value) and JSBigInt::digit(index) operations. We also have some operations to support arithmetics over digits. It is important to notice that on our representation, JSBigInt::dataStorage()[0] represents the least significant digit and JSBigInt::dataStorage()[m_length - 1] represents the most siginificant digit. We are also introducing into this Patch the BigInt literals lexer and syntax parsing support. The operation Strict Equals on BigInts is also being implemented to enable tests. These features are being implemented behind a runtime flage "--useBigInt" and are disabled by default. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * bytecode/CodeBlock.cpp: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitEqualityOp): (JSC::BytecodeGenerator::addBigIntConstant): * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::BigIntEntryHash::hash): (JSC::BytecodeGenerator::BigIntEntryHash::equal): * bytecompiler/NodesCodegen.cpp: (JSC::BigIntNode::jsValue const): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::isToThisAnIdentity): * interpreter/Interpreter.cpp: (JSC::sizeOfVarargs): * llint/LLIntData.cpp: (JSC::LLInt::Data::performAssertions): * llint/LowLevelInterpreter.asm: * parser/ASTBuilder.h: (JSC::ASTBuilder::createBigInt): * parser/Lexer.cpp: (JSC::Lexer::parseBinary): (JSC::Lexer::parseOctal): (JSC::Lexer::parseDecimal): (JSC::Lexer::lex): (JSC::Lexer::parseHex): Deleted. * parser/Lexer.h: * parser/NodeConstructors.h: (JSC::BigIntNode::BigIntNode): * parser/Nodes.h: (JSC::ExpressionNode::isBigInt const): (JSC::BigIntNode::value): * parser/Parser.cpp: (JSC::Parser::parsePrimaryExpression): * parser/ParserTokens.h: * parser/ResultType.h: (JSC::ResultType::definitelyIsBigInt const): (JSC::ResultType::mightBeBigInt const): (JSC::ResultType::isNotBigInt const): (JSC::ResultType::addResultType): (JSC::ResultType::bigIntType): (JSC::ResultType::forAdd): (JSC::ResultType::forLogicalOp): * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createBigInt): * runtime/CommonIdentifiers.h: * runtime/JSBigInt.cpp: Added. (JSC::JSBigInt::visitChildren): (JSC::JSBigInt::JSBigInt): (JSC::JSBigInt::initialize): (JSC::JSBigInt::createStructure): (JSC::JSBigInt::createZero): (JSC::JSBigInt::allocationSize): (JSC::JSBigInt::createWithLength): (JSC::JSBigInt::finishCreation): (JSC::JSBigInt::toPrimitive const): (JSC::JSBigInt::singleDigitValueForString): (JSC::JSBigInt::parseInt): (JSC::JSBigInt::toString): (JSC::JSBigInt::isZero): (JSC::JSBigInt::inplaceMultiplyAdd): (JSC::JSBigInt::digitAdd): (JSC::JSBigInt::digitSub): (JSC::JSBigInt::digitMul): (JSC::JSBigInt::digitPow): (JSC::JSBigInt::digitDiv): (JSC::JSBigInt::internalMultiplyAdd): (JSC::JSBigInt::equalToBigInt): (JSC::JSBigInt::absoluteDivSmall): (JSC::JSBigInt::calculateMaximumCharactersRequired): (JSC::JSBigInt::toStringGeneric): (JSC::JSBigInt::rightTrim): (JSC::JSBigInt::allocateFor): (JSC::JSBigInt::estimatedSize): (JSC::JSBigInt::toNumber const): (JSC::JSBigInt::getPrimitiveNumber const): * runtime/JSBigInt.h: Added. (JSC::JSBigInt::setSign): (JSC::JSBigInt::sign const): (JSC::JSBigInt::setLength): (JSC::JSBigInt::length const): (JSC::JSBigInt::parseInt): (JSC::JSBigInt::offsetOfData): (JSC::JSBigInt::dataStorage): (JSC::JSBigInt::digit): (JSC::JSBigInt::setDigit): (JSC::asBigInt): * runtime/JSCJSValue.cpp: (JSC::JSValue::synthesizePrototype const): (JSC::JSValue::toStringSlowCase const): * runtime/JSCJSValue.h: * runtime/JSCJSValueInlines.h: (JSC::JSValue::isBigInt const): (JSC::JSValue::strictEqualSlowCaseInline): * runtime/JSCell.cpp: (JSC::JSCell::put): (JSC::JSCell::putByIndex): (JSC::JSCell::toPrimitive const): (JSC::JSCell::getPrimitiveNumber const): (JSC::JSCell::toNumber const): (JSC::JSCell::toObjectSlow const): * runtime/JSCell.h: * runtime/JSCellInlines.h: (JSC::JSCell::isBigInt const): * runtime/JSType.h: * runtime/MathCommon.h: (JSC::clz64): * runtime/NumberPrototype.cpp: * runtime/Operations.cpp: (JSC::jsTypeStringForValue): (JSC::jsIsObjectTypeOrNull): * runtime/Options.h: * runtime/ParseInt.h: * runtime/SmallStrings.h: (JSC::SmallStrings::typeString const): * runtime/StructureInlines.h: (JSC::prototypeForLookupPrimitiveImpl): * runtime/TypeofType.cpp: (WTF::printInternal): * runtime/TypeofType.h: * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2017-12-12 Guillaume Emont LLInt: reserve 16 bytes of stack on MIPS for native calls https://bugs.webkit.org/show_bug.cgi?id=180653 Reviewed by Carlos Alberto Lopez Perez. * llint/LowLevelInterpreter32_64.asm: On MIPS, substract 24 from the stack pointer (16 for calling convention + 8 to be 16-aligned) instead of the 8 on other platforms (for alignment). 2017-12-12 Yusuke Suzuki [WTF] Thread::create should have Thread::tryCreate https://bugs.webkit.org/show_bug.cgi?id=180333 Reviewed by Darin Adler. * assembler/testmasm.cpp: (JSC::run): * b3/air/testair.cpp: * b3/testb3.cpp: (JSC::B3::run): * jsc.cpp: (functionDollarAgentStart): 2017-12-11 Michael Saboff REGRESSION(r225683): Chakra test failure in es6/regex-unicode.js for 32bit builds https://bugs.webkit.org/show_bug.cgi?id=180685 Reviewed by Saam Barati. The characterClass->m_anyCharacter check at the top of checkCharacterClass() caused the character class check to return true without reading the character. Given that the character could be a surrogate pair, we need to read the character even if we don't have the check it. * yarr/YarrInterpreter.cpp: (JSC::Yarr::Interpreter::testCharacterClass): (JSC::Yarr::Interpreter::checkCharacterClass): 2017-12-11 Saam Barati We need to disableCaching() in ErrorInstance when we materialize properties https://bugs.webkit.org/show_bug.cgi?id=180343 Reviewed by Mark Lam. This patch fixes a bug in ErrorInstance where we forgot to call PutPropertySlot::disableCaching on puts() to a property that we lazily materialized. Forgetting to do this goes against the PutPropertySlot's caching API. This lazy materialization caused the ErrorInstance to transition from a Structure A to a Structure B. However, we were telling the IC that we were caching an existing property only found on Structure B. This is obviously wrong as it would lead to an OOB store if we didn't already crash when generating the IC. * jit/Repatch.cpp: (JSC::tryCachePutByID): * runtime/ErrorInstance.cpp: (JSC::ErrorInstance::materializeErrorInfoIfNeeded): (JSC::ErrorInstance::put): * runtime/ErrorInstance.h: * runtime/Structure.cpp: (JSC::Structure::didCachePropertyReplacement): 2017-12-11 Fujii Hironori [WinCairo] DLLLauncherMain should use SetDllDirectory https://bugs.webkit.org/show_bug.cgi?id=180642 Reviewed by Alex Christensen. Windows have icuuc.dll in the system directory. WebKit should find one in WebKitLibraries directory, not one in the system directory. * shell/DLLLauncherMain.cpp: (modifyPath): Use SetDllDirectory for WebKitLibraries directory instead of modifying path. 2017-12-11 Eric Carlson Web Inspector: Optionally log WebKit log parameters as JSON https://bugs.webkit.org/show_bug.cgi?id=180529 Reviewed by Joseph Pecoraro. * inspector/ConsoleMessage.cpp: (Inspector::ConsoleMessage::ConsoleMessage): New constructor that takes a vector of JSON log values. Concatenate all adjacent strings to make logging cleaner. (Inspector::ConsoleMessage::addToFrontend): Process WebKit logging arguments. (Inspector::ConsoleMessage::scriptState const): * inspector/ConsoleMessage.h: * inspector/InjectedScript.cpp: (Inspector::InjectedScript::wrapJSONString const): Wrap JSON string log arguments. * inspector/InjectedScript.h: * inspector/InjectedScriptSource.js: (let.InjectedScript.prototype.wrapJSONString): 2017-12-11 Joseph Pecoraro Remove unused builtin names https://bugs.webkit.org/show_bug.cgi?id=180673 Reviewed by Keith Miller. * builtins/BuiltinNames.h: 2017-12-11 David Quesada Turn on ENABLE_APPLICATION_MANIFEST https://bugs.webkit.org/show_bug.cgi?id=180562 rdar://problem/35924737 Reviewed by Geoffrey Garen. * Configurations/FeatureDefines.xcconfig: 2017-12-10 Filip Pizlo Harden a few assertions in GC sweep https://bugs.webkit.org/show_bug.cgi?id=180634 Reviewed by Saam Barati. This turns one dynamic check into a release assertion and upgrades another assertion to a release assertion. * heap/MarkedBlock.cpp: (JSC::MarkedBlock::Handle::sweep): 2017-12-10 Konstantin Tokarev [python] Modernize "except" usage for python3 compatibility https://bugs.webkit.org/show_bug.cgi?id=180612 Reviewed by Michael Catanzaro. * inspector/scripts/generate-inspector-protocol-bindings.py: 2017-12-05 Filip Pizlo InferredType should not use UnconditionalFinalizer https://bugs.webkit.org/show_bug.cgi?id=180456 Reviewed by Saam Barati. This turns InferredStructure into a cell so that we can unconditionally finalize them without having to add things to the UnconditionalFinalizer list. I'm removing all uses of UnconditionalFinalizers and WeakReferenceHarvesters because the data structures used to manage them are a top cause of lock contention in the parallel GC. Also, we don't need those data structures if we use IsoSubspaces, subspace iteration, and marking constraints. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * heap/Heap.cpp: (JSC::Heap::finalizeUnconditionalFinalizers): * heap/Heap.h: * runtime/InferredStructure.cpp: Added. (JSC::InferredStructure::create): (JSC::InferredStructure::destroy): (JSC::InferredStructure::createStructure): (JSC::InferredStructure::visitChildren): (JSC::InferredStructure::finalizeUnconditionally): (JSC::InferredStructure::InferredStructure): (JSC::InferredStructure::finishCreation): * runtime/InferredStructure.h: Added. * runtime/InferredStructureWatchpoint.cpp: Added. (JSC::InferredStructureWatchpoint::fireInternal): * runtime/InferredStructureWatchpoint.h: Added. * runtime/InferredType.cpp: (JSC::InferredType::visitChildren): (JSC::InferredType::willStoreValueSlow): (JSC::InferredType::makeTopSlow): (JSC::InferredType::set): (JSC::InferredType::removeStructure): (JSC::InferredType::InferredStructureWatchpoint::fireInternal): Deleted. (JSC::InferredType::InferredStructureFinalizer::finalizeUnconditionally): Deleted. (JSC::InferredType::InferredStructure::InferredStructure): Deleted. * runtime/InferredType.h: * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2017-12-09 Konstantin Tokarev [python] Replace print >> operator with print() function for python3 compatibility https://bugs.webkit.org/show_bug.cgi?id=180611 Reviewed by Michael Catanzaro. * Scripts/make-js-file-arrays.py: (main): 2017-12-08 Joseph Pecoraro ServiceWorker Inspector: Various issues inspecting service worker on mobile.twitter.com https://bugs.webkit.org/show_bug.cgi?id=180520 Reviewed by Brian Burg. * inspector/protocol/ServiceWorker.json: Include content script content in the initialization info. 2017-12-08 Konstantin Tokarev [python] Replace print operator with print() function for python3 compatibility https://bugs.webkit.org/show_bug.cgi?id=180592 Reviewed by Michael Catanzaro. * Scripts/generateYarrUnicodePropertyTables.py: (openOrExit): (verifyUCDFilesExist): (Aliases.parsePropertyAliasesFile): (Aliases.parsePropertyValueAliasesFile): * Scripts/make-js-file-arrays.py: (main): * generate-bytecode-files: 2017-12-08 Mark Lam Need to unpoison native function pointers for CLoop. https://bugs.webkit.org/show_bug.cgi?id=180601 Reviewed by JF Bastien. * llint/LowLevelInterpreter64.asm: 2017-12-08 Michael Saboff YARR: JIT RegExps with greedy parenthesized sub patterns https://bugs.webkit.org/show_bug.cgi?id=180538 Reviewed by JF Bastien. This patch adds JIT support for regular expressions containing greedy counted parenthesis. An example expression that couldn't be JIT'ed before is /q(a|b)*q/. Just like in the interpreter, expressions with nested parenthetical subpatterns require saving the results of previous matches of the parentheses contents along with any associated state. This saved state is needed in the case that we need to backtrack. This state is called ParenContext within the code space allocated for this ParenContext is managed using a simple block allocator within the JIT'ed code. The raw space managed by this allocator is passed into the JIT'ed function. Since this fixed sized space may be exceeded, this patch adds a fallback mechanism. If the JIT'ed code exhausts all its ParenContext space, it returns a new error JSRegExpJITCodeFailure. The caller will then bytecompile and interpret the expression. Due to increased register usage by the parenthesis handling code, the use of registers by the JIT engine was restructured, with registers used for Unicode pattern matching replaced with constants. Reworked some of the context structures that are used across the interpreter and JIT implementations to make them a little more uniform and to handle the needs of JIT'ing the new parentheses forms. To help with development and debugging of this code, compiled patterns dumping code was enhanced. Also added the ability to also dump interpreter ByteCodes. * runtime/RegExp.cpp: (JSC::byteCodeCompilePattern): (JSC::RegExp::byteCodeCompileIfNecessary): (JSC::RegExp::compile): (JSC::RegExp::compileMatchOnly): * runtime/RegExp.h: * runtime/RegExpInlines.h: (JSC::RegExp::matchInline): * testRegExp.cpp: (parseRegExpLine): (runFromFiles): * yarr/Yarr.h: * yarr/YarrInterpreter.cpp: (JSC::Yarr::ByteCompiler::compile): (JSC::Yarr::ByteCompiler::dumpDisjunction): * yarr/YarrJIT.cpp: (JSC::Yarr::YarrGenerator::ParenContextSizes::ParenContextSizes): (JSC::Yarr::YarrGenerator::ParenContextSizes::numSubpatterns): (JSC::Yarr::YarrGenerator::ParenContextSizes::frameSlots): (JSC::Yarr::YarrGenerator::ParenContext::sizeFor): (JSC::Yarr::YarrGenerator::ParenContext::nextOffset): (JSC::Yarr::YarrGenerator::ParenContext::beginOffset): (JSC::Yarr::YarrGenerator::ParenContext::matchAmountOffset): (JSC::Yarr::YarrGenerator::ParenContext::subpatternOffset): (JSC::Yarr::YarrGenerator::ParenContext::savedFrameOffset): (JSC::Yarr::YarrGenerator::initParenContextFreeList): (JSC::Yarr::YarrGenerator::allocatePatternContext): (JSC::Yarr::YarrGenerator::freePatternContext): (JSC::Yarr::YarrGenerator::savePatternContext): (JSC::Yarr::YarrGenerator::restorePatternContext): (JSC::Yarr::YarrGenerator::tryReadUnicodeCharImpl): (JSC::Yarr::YarrGenerator::storeToFrame): (JSC::Yarr::YarrGenerator::generateJITFailReturn): (JSC::Yarr::YarrGenerator::clearMatches): (JSC::Yarr::YarrGenerator::generate): (JSC::Yarr::YarrGenerator::backtrack): (JSC::Yarr::YarrGenerator::opCompileParenthesesSubpattern): (JSC::Yarr::YarrGenerator::generateEnter): (JSC::Yarr::YarrGenerator::generateReturn): (JSC::Yarr::YarrGenerator::YarrGenerator): (JSC::Yarr::YarrGenerator::compile): * yarr/YarrJIT.h: (JSC::Yarr::YarrCodeBlock::execute): * yarr/YarrPattern.cpp: (JSC::Yarr::indentForNestingLevel): (JSC::Yarr::dumpUChar32): (JSC::Yarr::dumpCharacterClass): (JSC::Yarr::PatternTerm::dump): (JSC::Yarr::YarrPattern::dumpPattern): * yarr/YarrPattern.h: (JSC::Yarr::PatternTerm::containsAnyCaptures): (JSC::Yarr::BackTrackInfoParenthesesOnce::returnAddressIndex): (JSC::Yarr::BackTrackInfoParentheses::beginIndex): (JSC::Yarr::BackTrackInfoParentheses::returnAddressIndex): (JSC::Yarr::BackTrackInfoParentheses::matchAmountIndex): (JSC::Yarr::BackTrackInfoParentheses::patternContextHeadIndex): (JSC::Yarr::BackTrackInfoAlternative::offsetIndex): Deleted. 2017-12-08 Joseph Pecoraro Web Inspector: CRASH at InspectorConsoleAgent::enable when iterating mutable list of buffered console messages https://bugs.webkit.org/show_bug.cgi?id=180590 Reviewed by Mark Lam. * inspector/agents/InspectorConsoleAgent.cpp: (Inspector::InspectorConsoleAgent::enable): Swap the messages to a Vector that won't change during iteration. 2017-12-08 Michael Saboff YARR: Coalesce constructed character classes https://bugs.webkit.org/show_bug.cgi?id=180537 Reviewed by JF Bastien. When adding characters or character ranges to a character class being constructed, we now coalesce adjacent characters and character ranges. When we create a character class after construction is complete, we do a final coalescing pass across the character list and ranges to catch any remaining coalescing opportunities. Added an optimization for character classes that will match any character. This is somewhat common in code created before the /s (dotAll) flag was added to the engine. * yarr/YarrInterpreter.cpp: (JSC::Yarr::Interpreter::checkCharacterClass): * yarr/YarrJIT.cpp: (JSC::Yarr::YarrGenerator::generateCharacterClassOnce): (JSC::Yarr::YarrGenerator::generateCharacterClassFixed): (JSC::Yarr::YarrGenerator::generateCharacterClassGreedy): (JSC::Yarr::YarrGenerator::backtrackCharacterClassNonGreedy): * yarr/YarrPattern.cpp: (JSC::Yarr::CharacterClassConstructor::CharacterClassConstructor): (JSC::Yarr::CharacterClassConstructor::reset): (JSC::Yarr::CharacterClassConstructor::charClass): (JSC::Yarr::CharacterClassConstructor::addSorted): (JSC::Yarr::CharacterClassConstructor::addSortedRange): (JSC::Yarr::CharacterClassConstructor::mergeRangesFrom): (JSC::Yarr::CharacterClassConstructor::coalesceTables): (JSC::Yarr::CharacterClassConstructor::anyCharacter): (JSC::Yarr::YarrPatternConstructor::atomCharacterClassEnd): (JSC::Yarr::PatternTerm::dump): (JSC::Yarr::anycharCreate): * yarr/YarrPattern.h: (JSC::Yarr::CharacterClass::CharacterClass): 2017-12-07 Saam Barati Modify our dollar VM clflush intrinsic to aid in some perf testing https://bugs.webkit.org/show_bug.cgi?id=180559 Reviewed by Mark Lam. * tools/JSDollarVM.cpp: (JSC::functionCpuClflush): (JSC::functionDeltaBetweenButterflies): (JSC::JSDollarVM::finishCreation): 2017-12-07 Eric Carlson Simplify log channel configuration UI https://bugs.webkit.org/show_bug.cgi?id=180527 Reviewed by Joseph Pecoraro. * inspector/protocol/Console.json: 2017-12-07 Mark Lam Apply poisoning to some native code pointers. https://bugs.webkit.org/show_bug.cgi?id=180541 Reviewed by Filip Pizlo. Renamed g_classInfoPoison to g_globalDataPoison. Renamed g_masmPoison to g_jitCodePoison. Introduced g_nativeCodePoison. Applied g_nativeCodePoison to poisoning some native code pointers. Introduced non-random Int32 poison values (in JSCPoison.h) for use with pointers to malloc allocated data structures (where needed). * API/JSCallbackFunction.h: (JSC::JSCallbackFunction::functionCallback): * JavaScriptCore.xcodeproj/project.pbxproj: * jit/ThunkGenerators.cpp: (JSC::nativeForGenerator): * llint/LowLevelInterpreter64.asm: * runtime/CustomGetterSetter.h: (JSC::CustomGetterSetter::getter const): (JSC::CustomGetterSetter::setter const): * runtime/InternalFunction.cpp: (JSC::InternalFunction::getCallData): (JSC::InternalFunction::getConstructData): * runtime/InternalFunction.h: (JSC::InternalFunction::nativeFunctionFor): * runtime/JSCPoison.h: Added. * runtime/JSCPoisonedPtr.cpp: (JSC::initializePoison): * runtime/JSCPoisonedPtr.h: * runtime/Lookup.h: * runtime/NativeExecutable.cpp: (JSC::NativeExecutable::hashFor const): * runtime/NativeExecutable.h: * runtime/Structure.cpp: (JSC::StructureTransitionTable::setSingleTransition): * runtime/StructureTransitionTable.h: (JSC::StructureTransitionTable::StructureTransitionTable): (JSC::StructureTransitionTable::isUsingSingleSlot const): (JSC::StructureTransitionTable::map const): (JSC::StructureTransitionTable::weakImpl const): (JSC::StructureTransitionTable::setMap): 2017-12-07 Joseph Pecoraro Web Inspector: Fix style in remote inspector classes https://bugs.webkit.org/show_bug.cgi?id=180545 Reviewed by Youenn Fablet. * inspector/remote/RemoteControllableTarget.h: * inspector/remote/RemoteInspectionTarget.h: * runtime/JSGlobalObjectDebuggable.h: 2017-12-07 Per Arne Vollan Use fastAlignedFree to free aligned memory. https://bugs.webkit.org/show_bug.cgi?id=180540 Reviewed by Saam Barati. * heap/IsoAlignedMemoryAllocator.cpp: (JSC::IsoAlignedMemoryAllocator::~IsoAlignedMemoryAllocator): 2017-12-07 Matt Lewis Unreviewed, rolling out r225634. This caused layout tests to time out. Reverted changeset: "Simplify log channel configuration UI" https://bugs.webkit.org/show_bug.cgi?id=180527 https://trac.webkit.org/changeset/225634 2017-12-07 Eric Carlson Simplify log channel configuration UI https://bugs.webkit.org/show_bug.cgi?id=180527 Reviewed by Joseph Pecoraro. * inspector/protocol/Console.json: 2017-12-07 Mark Lam [Re-landing r225620] Refactoring: Rename ScrambledPtr to Poisoned. https://bugs.webkit.org/show_bug.cgi?id=180514 Reviewed by Saam Barati and JF Bastien. Re-landing r225620 with speculative build fix for GCC 7. * API/JSCallbackObject.h: * API/JSObjectRef.cpp: (classInfoPrivate): * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * assembler/MacroAssemblerCodeRef.h: (JSC::FunctionPtr::FunctionPtr): (JSC::FunctionPtr::value const): (JSC::FunctionPtr::executableAddress const): (JSC::ReturnAddressPtr::ReturnAddressPtr): (JSC::ReturnAddressPtr::value const): (JSC::MacroAssemblerCodePtr::MacroAssemblerCodePtr): (JSC::MacroAssemblerCodePtr::createFromExecutableAddress): (JSC::MacroAssemblerCodePtr::poisonedPtr const): (JSC::MacroAssemblerCodePtr:: const): (JSC::MacroAssemblerCodePtr::operator! const): (JSC::MacroAssemblerCodePtr::operator== const): (JSC::MacroAssemblerCodePtr::emptyValue): (JSC::MacroAssemblerCodePtr::deletedValue): (JSC::MacroAssemblerCodePtr::scrambledPtr const): Deleted. * b3/B3LowerMacros.cpp: * b3/testb3.cpp: (JSC::B3::testInterpreter): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::checkArray): (JSC::DFG::SpeculativeJIT::compileCheckSubClass): (JSC::DFG::SpeculativeJIT::compileNewStringObject): (JSC::DFG::SpeculativeJIT::emitSwitchIntJump): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNewStringObject): (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::emitAllocateDestructibleObject): * jit/SpecializedThunkJIT.h: (JSC::SpecializedThunkJIT::loadArgumentWithSpecificClass): * jit/ThunkGenerators.cpp: (JSC::virtualThunkFor): (JSC::boundThisNoArgsFunctionCallGenerator): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::handleHostCall): (JSC::LLInt::setUpCall): * llint/LowLevelInterpreter64.asm: * runtime/InitializeThreading.cpp: (JSC::initializeThreading): * runtime/JSCPoisonedPtr.cpp: Copied from Source/JavaScriptCore/runtime/JSCScrambledPtr.cpp. (JSC::initializePoison): (JSC::initializeScrambledPtrKeys): Deleted. * runtime/JSCPoisonedPtr.h: Copied from Source/JavaScriptCore/runtime/JSCScrambledPtr.h. * runtime/JSCScrambledPtr.cpp: Removed. * runtime/JSCScrambledPtr.h: Removed. * runtime/JSDestructibleObject.h: (JSC::JSDestructibleObject::classInfo const): * runtime/JSSegmentedVariableObject.h: (JSC::JSSegmentedVariableObject::classInfo const): * runtime/Structure.h: * runtime/VM.h: 2017-12-07 Michael Catanzaro Unreviewed, rolling out r225620 https://bugs.webkit.org/show_bug.cgi?id=180514 It broke the build with GCC 7, and I don't know how to fix it. * API/JSCallbackObject.h: * API/JSObjectRef.cpp: (classInfoPrivate): * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * assembler/MacroAssemblerCodeRef.h: (JSC::FunctionPtr::FunctionPtr): (JSC::FunctionPtr::value const): (JSC::FunctionPtr::executableAddress const): (JSC::ReturnAddressPtr::ReturnAddressPtr): (JSC::ReturnAddressPtr::value const): (JSC::MacroAssemblerCodePtr::MacroAssemblerCodePtr): (JSC::MacroAssemblerCodePtr::createFromExecutableAddress): (JSC::MacroAssemblerCodePtr::scrambledPtr const): (JSC::MacroAssemblerCodePtr:: const): (JSC::MacroAssemblerCodePtr::operator! const): (JSC::MacroAssemblerCodePtr::operator== const): (JSC::MacroAssemblerCodePtr::emptyValue): (JSC::MacroAssemblerCodePtr::deletedValue): (JSC::MacroAssemblerCodePtr::poisonedPtr const): Deleted. * b3/B3LowerMacros.cpp: * b3/testb3.cpp: (JSC::B3::testInterpreter): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::checkArray): (JSC::DFG::SpeculativeJIT::compileCheckSubClass): (JSC::DFG::SpeculativeJIT::compileNewStringObject): (JSC::DFG::SpeculativeJIT::emitSwitchIntJump): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNewStringObject): (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::emitAllocateDestructibleObject): * jit/SpecializedThunkJIT.h: (JSC::SpecializedThunkJIT::loadArgumentWithSpecificClass): * jit/ThunkGenerators.cpp: (JSC::virtualThunkFor): (JSC::boundThisNoArgsFunctionCallGenerator): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::handleHostCall): (JSC::LLInt::setUpCall): * llint/LowLevelInterpreter64.asm: * runtime/InitializeThreading.cpp: (JSC::initializeThreading): * runtime/JSCScrambledPtr.cpp: Renamed from Source/JavaScriptCore/runtime/JSCPoisonedPtr.cpp. (JSC::initializeScrambledPtrKeys): * runtime/JSCScrambledPtr.h: Renamed from Source/JavaScriptCore/runtime/JSCPoisonedPtr.h. * runtime/JSDestructibleObject.h: (JSC::JSDestructibleObject::classInfo const): * runtime/JSSegmentedVariableObject.h: (JSC::JSSegmentedVariableObject::classInfo const): * runtime/Structure.h: * runtime/VM.h: 2017-12-06 Mark Lam Refactoring: Rename ScrambledPtr to Poisoned. https://bugs.webkit.org/show_bug.cgi?id=180514 Reviewed by Saam Barati. * API/JSCallbackObject.h: * API/JSObjectRef.cpp: (classInfoPrivate): * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * assembler/MacroAssemblerCodeRef.h: (JSC::FunctionPtr::FunctionPtr): (JSC::FunctionPtr::value const): (JSC::FunctionPtr::executableAddress const): (JSC::ReturnAddressPtr::ReturnAddressPtr): (JSC::ReturnAddressPtr::value const): (JSC::MacroAssemblerCodePtr::MacroAssemblerCodePtr): (JSC::MacroAssemblerCodePtr::createFromExecutableAddress): (JSC::MacroAssemblerCodePtr::poisonedPtr const): (JSC::MacroAssemblerCodePtr:: const): (JSC::MacroAssemblerCodePtr::operator! const): (JSC::MacroAssemblerCodePtr::operator== const): (JSC::MacroAssemblerCodePtr::emptyValue): (JSC::MacroAssemblerCodePtr::deletedValue): (JSC::MacroAssemblerCodePtr::scrambledPtr const): Deleted. * b3/B3LowerMacros.cpp: * b3/testb3.cpp: (JSC::B3::testInterpreter): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::checkArray): (JSC::DFG::SpeculativeJIT::compileCheckSubClass): (JSC::DFG::SpeculativeJIT::compileNewStringObject): (JSC::DFG::SpeculativeJIT::emitSwitchIntJump): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNewStringObject): (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::emitAllocateDestructibleObject): * jit/SpecializedThunkJIT.h: (JSC::SpecializedThunkJIT::loadArgumentWithSpecificClass): * jit/ThunkGenerators.cpp: (JSC::virtualThunkFor): (JSC::boundThisNoArgsFunctionCallGenerator): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::handleHostCall): (JSC::LLInt::setUpCall): * llint/LowLevelInterpreter64.asm: * runtime/InitializeThreading.cpp: (JSC::initializeThreading): * runtime/JSCPoisonedPtr.cpp: Copied from Source/JavaScriptCore/runtime/JSCScrambledPtr.cpp. (JSC::initializePoison): (JSC::initializeScrambledPtrKeys): Deleted. * runtime/JSCPoisonedPtr.h: Copied from Source/JavaScriptCore/runtime/JSCScrambledPtr.h. * runtime/JSCScrambledPtr.cpp: Removed. * runtime/JSCScrambledPtr.h: Removed. * runtime/JSDestructibleObject.h: (JSC::JSDestructibleObject::classInfo const): * runtime/JSSegmentedVariableObject.h: (JSC::JSSegmentedVariableObject::classInfo const): * runtime/Structure.h: * runtime/VM.h: 2017-12-02 Darin Adler Modernize some aspects of text codecs, eliminate WebKit use of strcasecmp https://bugs.webkit.org/show_bug.cgi?id=180009 Reviewed by Alex Christensen. * bytecode/ArrayProfile.cpp: Removed include of StringExtras.h. * bytecode/CodeBlock.cpp: Ditto. * bytecode/ExecutionCounter.cpp: Ditto. * runtime/ConfigFile.cpp: Ditto. * runtime/DatePrototype.cpp: Ditto. * runtime/IndexingType.cpp: Ditto. * runtime/JSCJSValue.cpp: Ditto. * runtime/JSDateMath.cpp: Ditto. * runtime/JSGlobalObjectFunctions.cpp: Ditto. * runtime/Options.cpp: Ditto. (JSC::parse): Use equalLettersIgnoringASCIICase instead of strcasecmp. 2017-12-06 Saam Barati ASSERTION FAILED: vm->currentThreadIsHoldingAPILock() in void JSC::sanitizeStackForVM(JSC::VM *) https://bugs.webkit.org/show_bug.cgi?id=180438 Reviewed by Yusuke Suzuki. A couple inspector methods that take stacktraces need to grab the JSLock. * inspector/ScriptCallStackFactory.cpp: (Inspector::createScriptCallStack): (Inspector::createScriptCallStackForConsole): 2017-12-05 Stephan Szabo Switch windows build to Visual Studio 2017 https://bugs.webkit.org/show_bug.cgi?id=172412 Reviewed by Per Arne Vollan. * JavaScriptCore.vcxproj/JavaScriptCore.proj: 2017-12-05 JF Bastien WebAssembly: don't eagerly checksum https://bugs.webkit.org/show_bug.cgi?id=180441 Reviewed by Saam Barati. Make checksumming of module optional for now. The bots think the checksum hurt compile-time. I'd measured it and couldn't see a difference, and still can't at this point in time, but we'll see if disabling it fixes the bots. If so then I can make it lazy upon first backtrace construction, or I can try out MD5 instead of SHA1. * runtime/Options.h: * wasm/WasmModuleInformation.cpp: (JSC::Wasm::ModuleInformation::ModuleInformation): * wasm/WasmModuleInformation.h: * wasm/WasmNameSection.h: (JSC::Wasm::NameSection::NameSection): 2017-12-05 Filip Pizlo IsoAlignedMemoryAllocator needs to free all of its memory when the VM destructs https://bugs.webkit.org/show_bug.cgi?id=180425 Reviewed by Saam Barati. Failure to do so causes leaks after starting workers. * heap/IsoAlignedMemoryAllocator.cpp: (JSC::IsoAlignedMemoryAllocator::~IsoAlignedMemoryAllocator): (JSC::IsoAlignedMemoryAllocator::tryAllocateAlignedMemory): 2017-12-05 Per Arne Vollan [Win64] Compile error in testmasm.cpp. https://bugs.webkit.org/show_bug.cgi?id=180436 Reviewed by Mark Lam. Fix MSVC warning (32-bit shift implicitly converted to 64 bits). * assembler/testmasm.cpp: (JSC::testGetEffectiveAddress): 2017-12-01 Filip Pizlo GC constraint solving should be parallel https://bugs.webkit.org/show_bug.cgi?id=179934 Reviewed by JF Bastien. This makes it possible to do constraint solving in parallel. This looks like a 1% Speedometer speed-up. It's more than 1% on trunk-Speedometer. The constraint solver supports running constraints in parallel in two different ways: - Run multiple constraints in parallel to each other. This only works for constraints that can tolerate other constraints running concurrently to them (constraint.concurrency() == ConstraintConcurrency::Concurrent). This is the most basic kind of parallelism that the constraint solver supports. All constraints except the JSC SPI constraints are concurrent. We could probably make them concurrent, but I'm playing it safe for now. - A constraint can create parallel work for itself, which the constraint solver will interleave with other stuff. A constraint can report that it has parallel work by returning ConstraintParallelism::Parallel from its executeImpl() function. Then the solver will allow that constraint's doParallelWorkImpl() function to run on as many GC marker threads as are available, for as long as that function wants to run. It's not possible to have a non-concurrent constraint that creates parallel work. The parallelism is implemented in terms of the existing GC marker threads. This turns out to be most natural for two reasons: - No need to start any other threads. - The constraints all want to be passed a SlotVisitor. Running on the marker threads means having access to those threads' SlotVisitors. Also, it means less load balancing. The solver will create work on each marking thread's SlotVisitor. When the solver is done "stealing" a marker thread, that thread will have work it can start doing immediately. Before this change, we had to contribute the work found by the constraint solver to the global worklist so that it could be distributed to the marker threads by load balancing. This change probably helps to avoid that load balancing step. A lot of this change is about making it easy to iterate GC data structures in parallel. This change makes almost all constraints parallel-enabled, but only the DOM's output constraint uses the parallel work API. That constraint iterates the marked cells in two subspaces. This change makes it very easy to compose parallel iterators over subspaces, allocators, blocks, and cells. The marked cell parallel iterator is composed out of parallel iterators for the others. A parallel iterator is just an iterator that can do an atomic next() very quickly. We abstract them using RefPtr>, where ... is the type returned from the iterator. We know it's done when it returns a falsish version of ... (in the current code, that's always a pointer type, so done is indicated by null). * API/JSMarkingConstraintPrivate.cpp: (JSContextGroupAddMarkingConstraint): * API/JSVirtualMachine.mm: (scanExternalObjectGraph): (scanExternalRememberedSet): * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * bytecode/AccessCase.cpp: (JSC::AccessCase::propagateTransitions const): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::visitWeakly): (JSC::CodeBlock::shouldJettisonDueToOldAge): (JSC::shouldMarkTransition): (JSC::CodeBlock::propagateTransitions): (JSC::CodeBlock::determineLiveness): * dfg/DFGWorklist.cpp: * ftl/FTLCompile.cpp: (JSC::FTL::compile): * heap/ConstraintParallelism.h: Added. (WTF::printInternal): * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::addToRememberedSet): (JSC::Heap::runFixpointPhase): (JSC::Heap::stopThePeriphery): (JSC::Heap::resumeThePeriphery): (JSC::Heap::addCoreConstraints): (JSC::Heap::setBonusVisitorTask): (JSC::Heap::runTaskInParallel): (JSC::Heap::forEachSlotVisitor): Deleted. * heap/Heap.h: (JSC::Heap::worldIsRunning const): (JSC::Heap::runFunctionInParallel): * heap/HeapInlines.h: (JSC::Heap::worldIsStopped const): (JSC::Heap::isMarked): (JSC::Heap::incrementDeferralDepth): (JSC::Heap::decrementDeferralDepth): (JSC::Heap::decrementDeferralDepthAndGCIfNeeded): (JSC::Heap::forEachSlotVisitor): (JSC::Heap::collectorBelievesThatTheWorldIsStopped const): Deleted. (JSC::Heap::isMarkedConcurrently): Deleted. * heap/HeapSnapshotBuilder.cpp: (JSC::HeapSnapshotBuilder::appendNode): * heap/LargeAllocation.h: (JSC::LargeAllocation::isMarked): (JSC::LargeAllocation::isMarkedConcurrently): Deleted. * heap/LockDuringMarking.h: (JSC::lockDuringMarking): * heap/MarkedAllocator.cpp: (JSC::MarkedAllocator::parallelNotEmptyBlockSource): * heap/MarkedAllocator.h: * heap/MarkedBlock.h: (JSC::MarkedBlock::aboutToMark): (JSC::MarkedBlock::isMarked): (JSC::MarkedBlock::areMarksStaleWithDependency): Deleted. (JSC::MarkedBlock::isMarkedConcurrently): Deleted. * heap/MarkedSpace.h: (JSC::MarkedSpace::activeWeakSetsBegin): (JSC::MarkedSpace::activeWeakSetsEnd): (JSC::MarkedSpace::newActiveWeakSetsBegin): (JSC::MarkedSpace::newActiveWeakSetsEnd): * heap/MarkingConstraint.cpp: (JSC::MarkingConstraint::MarkingConstraint): (JSC::MarkingConstraint::execute): (JSC::MarkingConstraint::quickWorkEstimate): (JSC::MarkingConstraint::workEstimate): (JSC::MarkingConstraint::doParallelWork): (JSC::MarkingConstraint::finishParallelWork): (JSC::MarkingConstraint::doParallelWorkImpl): (JSC::MarkingConstraint::finishParallelWorkImpl): * heap/MarkingConstraint.h: (JSC::MarkingConstraint::lastExecuteParallelism const): (JSC::MarkingConstraint::parallelism const): (JSC::MarkingConstraint::quickWorkEstimate): Deleted. (JSC::MarkingConstraint::workEstimate): Deleted. * heap/MarkingConstraintSet.cpp: (JSC::MarkingConstraintSet::MarkingConstraintSet): (JSC::MarkingConstraintSet::add): (JSC::MarkingConstraintSet::executeConvergence): (JSC::MarkingConstraintSet::executeConvergenceImpl): (JSC::MarkingConstraintSet::executeAll): (JSC::MarkingConstraintSet::ExecutionContext::ExecutionContext): Deleted. (JSC::MarkingConstraintSet::ExecutionContext::didVisitSomething const): Deleted. (JSC::MarkingConstraintSet::ExecutionContext::shouldTimeOut const): Deleted. (JSC::MarkingConstraintSet::ExecutionContext::drain): Deleted. (JSC::MarkingConstraintSet::ExecutionContext::didExecute const): Deleted. (JSC::MarkingConstraintSet::ExecutionContext::execute): Deleted. (): Deleted. * heap/MarkingConstraintSet.h: * heap/MarkingConstraintSolver.cpp: Added. (JSC::MarkingConstraintSolver::MarkingConstraintSolver): (JSC::MarkingConstraintSolver::~MarkingConstraintSolver): (JSC::MarkingConstraintSolver::didVisitSomething const): (JSC::MarkingConstraintSolver::execute): (JSC::MarkingConstraintSolver::drain): (JSC::MarkingConstraintSolver::converge): (JSC::MarkingConstraintSolver::runExecutionThread): (JSC::MarkingConstraintSolver::didExecute): * heap/MarkingConstraintSolver.h: Added. * heap/OpaqueRootSet.h: Removed. * heap/ParallelSourceAdapter.h: Added. (JSC::ParallelSourceAdapter::ParallelSourceAdapter): (JSC::createParallelSourceAdapter): * heap/SimpleMarkingConstraint.cpp: Added. (JSC::SimpleMarkingConstraint::SimpleMarkingConstraint): (JSC::SimpleMarkingConstraint::~SimpleMarkingConstraint): (JSC::SimpleMarkingConstraint::quickWorkEstimate): (JSC::SimpleMarkingConstraint::executeImpl): * heap/SimpleMarkingConstraint.h: Added. * heap/SlotVisitor.cpp: (JSC::SlotVisitor::didStartMarking): (JSC::SlotVisitor::reset): (JSC::SlotVisitor::appendToMarkStack): (JSC::SlotVisitor::visitChildren): (JSC::SlotVisitor::updateMutatorIsStopped): (JSC::SlotVisitor::mutatorIsStoppedIsUpToDate const): (JSC::SlotVisitor::drain): (JSC::SlotVisitor::performIncrementOfDraining): (JSC::SlotVisitor::didReachTermination): (JSC::SlotVisitor::hasWork): (JSC::SlotVisitor::drainFromShared): (JSC::SlotVisitor::drainInParallelPassively): (JSC::SlotVisitor::waitForTermination): (JSC::SlotVisitor::addOpaqueRoot): Deleted. (JSC::SlotVisitor::containsOpaqueRoot const): Deleted. (JSC::SlotVisitor::containsOpaqueRootTriState const): Deleted. (JSC::SlotVisitor::mergeIfNecessary): Deleted. (JSC::SlotVisitor::mergeOpaqueRootsIfProfitable): Deleted. (JSC::SlotVisitor::mergeOpaqueRoots): Deleted. * heap/SlotVisitor.h: * heap/SlotVisitorInlines.h: (JSC::SlotVisitor::addOpaqueRoot): (JSC::SlotVisitor::containsOpaqueRoot const): (JSC::SlotVisitor::vm): (JSC::SlotVisitor::vm const): * heap/Subspace.cpp: (JSC::Subspace::parallelAllocatorSource): (JSC::Subspace::parallelNotEmptyMarkedBlockSource): * heap/Subspace.h: * heap/SubspaceInlines.h: (JSC::Subspace::forEachMarkedCellInParallel): * heap/VisitCounter.h: Added. (JSC::VisitCounter::VisitCounter): (JSC::VisitCounter::visitCount const): * heap/VisitingTimeout.h: Removed. * heap/WeakBlock.cpp: (JSC::WeakBlock::specializedVisit): * runtime/Structure.cpp: (JSC::Structure::isCheapDuringGC): (JSC::Structure::markIfCheap): 2017-12-04 JF Bastien Math: don't redundantly check for exceptions, just release scope https://bugs.webkit.org/show_bug.cgi?id=180395 Rubber stamped by Mark Lam. Two of the exceptions checks could just have been exception scope releases before the return, which is ever-so-slightly more efficient. The same technically applies where we have loops over parameters, but doing the scope release there isn't really more efficient and is way harder to read. * runtime/MathObject.cpp: (JSC::mathProtoFuncATan2): (JSC::mathProtoFuncPow): 2017-12-04 David Quesada Add a class for parsing application manifests https://bugs.webkit.org/show_bug.cgi?id=177973 rdar://problem/34747949 Reviewed by Geoffrey Garen. * Configurations/FeatureDefines.xcconfig: Add ENABLE_APPLICATION_MANIFEST feature flag. 2017-12-04 JF Bastien Update std::expected to match libc++ coding style https://bugs.webkit.org/show_bug.cgi?id=180264 Reviewed by Alex Christensen. Update various uses of Expected. * wasm/WasmModule.h: * wasm/WasmModuleParser.cpp: (JSC::Wasm::ModuleParser::parseImport): (JSC::Wasm::ModuleParser::parseTableHelper): (JSC::Wasm::ModuleParser::parseTable): (JSC::Wasm::ModuleParser::parseMemoryHelper): * wasm/WasmParser.h: * wasm/generateWasmValidateInlinesHeader.py: (loadMacro): (storeMacro): * wasm/js/JSWebAssemblyModule.cpp: (JSC::JSWebAssemblyModule::createStub): * wasm/js/JSWebAssemblyModule.h: 2017-12-04 Saam Barati We need to leave room on the top of the stack for the FTL TailCall slow path so it doesn't overwrite things we want to retrieve when doing a stack walk when throwing an exception https://bugs.webkit.org/show_bug.cgi?id=180366 Reviewed by Michael Saboff. On the TailCall slow path, the CallFrameShuffler will build the frame with respect to SP instead of FP. However, this may overwrite slots on the stack that are needed if the slow path C call does a stack walk. The slow path C call does a stack walk when it throws an exception. This patch fixes this bug by ensuring that the top of the stack in the FTL always has enough space to allow CallFrameShuffler to build a frame without overwriting any items on the stack that are needed when doing a stack walk. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileTailCall): 2017-12-04 Devin Rousso Web Inspector: provide method for recording CanvasRenderingContext2D from JavaScript https://bugs.webkit.org/show_bug.cgi?id=175166 Reviewed by Joseph Pecoraro. * inspector/protocol/Recording.json: Add optional `name` that will be used by the frontend for uniquely identifying the Recording. * inspector/JSGlobalObjectConsoleClient.h: * inspector/JSGlobalObjectConsoleClient.cpp: (Inspector::JSGlobalObjectConsoleClient::record): (Inspector::JSGlobalObjectConsoleClient::recordEnd): * runtime/ConsoleClient.h: * runtime/ConsoleObject.cpp: (JSC::ConsoleObject::finishCreation): (JSC::consoleProtoFuncRecord): (JSC::consoleProtoFuncRecordEnd): 2017-12-03 Yusuke Suzuki WTF shouldn't have both Thread and ThreadIdentifier https://bugs.webkit.org/show_bug.cgi?id=180308 Reviewed by Darin Adler. * heap/MachineStackMarker.cpp: (JSC::MachineThreads::tryCopyOtherThreadStacks): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::llint_trace_operand): (JSC::LLInt::llint_trace_value): (JSC::LLInt::LLINT_SLOW_PATH_DECL): (JSC::LLInt::traceFunctionPrologue): * runtime/ExceptionScope.cpp: (JSC::ExceptionScope::unexpectedExceptionMessage): * runtime/JSLock.h: (JSC::JSLock::currentThreadIsHoldingLock): * runtime/VM.cpp: (JSC::VM::throwException): * runtime/VM.h: (JSC::VM::throwingThread const): (JSC::VM::clearException): * tools/HeapVerifier.cpp: (JSC::HeapVerifier::printVerificationHeader): 2017-12-03 Caio Lima Rename DestroyFunc to avoid redefinition on unified build https://bugs.webkit.org/show_bug.cgi?id=180335 Reviewed by Filip Pizlo. Changing DestroyFunc structures to more specific names to avoid conflits on unified builds. * heap/HeapCellType.cpp: (JSC::HeapCellType::finishSweep): (JSC::HeapCellType::destroy): * runtime/JSDestructibleObjectHeapCellType.cpp: (JSC::JSDestructibleObjectHeapCellType::finishSweep): (JSC::JSDestructibleObjectHeapCellType::destroy): * runtime/JSSegmentedVariableObjectHeapCellType.cpp: (JSC::JSSegmentedVariableObjectHeapCellType::finishSweep): (JSC::JSSegmentedVariableObjectHeapCellType::destroy): * runtime/JSStringHeapCellType.cpp: (JSC::JSStringHeapCellType::finishSweep): (JSC::JSStringHeapCellType::destroy): * wasm/js/JSWebAssemblyCodeBlockHeapCellType.cpp: (JSC::JSWebAssemblyCodeBlockHeapCellType::finishSweep): (JSC::JSWebAssemblyCodeBlockHeapCellType::destroy): 2017-12-01 JF Bastien JavaScriptCore: missing exception checks in Math functions that take more than one argument https://bugs.webkit.org/show_bug.cgi?id=180297 Reviewed by Mark Lam. * runtime/MathObject.cpp: (JSC::mathProtoFuncATan2): (JSC::mathProtoFuncMax): (JSC::mathProtoFuncMin): (JSC::mathProtoFuncPow): 2017-12-01 Mark Lam Let's scramble ClassInfo pointers in cells. https://bugs.webkit.org/show_bug.cgi?id=180291 Reviewed by JF Bastien. * API/JSCallbackObject.h: * API/JSObjectRef.cpp: (classInfoPrivate): * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * assembler/MacroAssemblerCodeRef.cpp: (JSC::MacroAssemblerCodePtr::initialize): Deleted. * assembler/MacroAssemblerCodeRef.h: (JSC::MacroAssemblerCodePtr:: const): (JSC::MacroAssemblerCodePtr::hash const): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::checkArray): (JSC::DFG::SpeculativeJIT::compileCheckSubClass): (JSC::DFG::SpeculativeJIT::compileNewStringObject): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNewStringObject): (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::emitAllocateDestructibleObject): * jit/SpecializedThunkJIT.h: (JSC::SpecializedThunkJIT::loadArgumentWithSpecificClass): * runtime/InitializeThreading.cpp: (JSC::initializeThreading): * runtime/JSCScrambledPtr.cpp: Added. (JSC::initializeScrambledPtrKeys): * runtime/JSCScrambledPtr.h: Added. * runtime/JSDestructibleObject.h: (JSC::JSDestructibleObject::classInfo const): * runtime/JSSegmentedVariableObject.h: (JSC::JSSegmentedVariableObject::classInfo const): * runtime/Structure.h: * runtime/VM.h: 2017-12-01 Brian Burg Web Inspector: move Inspector::Protocol::Array to JSON namespace https://bugs.webkit.org/show_bug.cgi?id=173662 Reviewed by Joseph Pecoraro. Adopt new type names. Fix protocol generator to use correct type names. * inspector/ConsoleMessage.cpp: (Inspector::ConsoleMessage::addToFrontend): Improve namings and use 'auto' when the type is obvious and repeated. * inspector/ContentSearchUtilities.cpp: (Inspector::ContentSearchUtilities::searchInTextByLines): * inspector/ContentSearchUtilities.h: * inspector/InjectedScript.cpp: (Inspector::InjectedScript::getProperties): (Inspector::InjectedScript::getDisplayableProperties): (Inspector::InjectedScript::getInternalProperties): (Inspector::InjectedScript::getCollectionEntries): (Inspector::InjectedScript::wrapCallFrames const): * inspector/InjectedScript.h: * inspector/InspectorProtocolTypes.h: (Inspector::Protocol::BindingTraits>::runtimeCast): (Inspector::Protocol::Array::Array): Deleted. (Inspector::Protocol::Array::openAccessors): Deleted. (Inspector::Protocol::Array::addItem): Deleted. (Inspector::Protocol::Array::create): Deleted. (Inspector::Protocol::BindingTraits>::runtimeCast): Deleted. (Inspector::Protocol::BindingTraits>::assertValueHasExpectedType): Deleted. Move the implementation out of this file. * inspector/ScriptCallStack.cpp: (Inspector::ScriptCallStack::buildInspectorArray const): * inspector/ScriptCallStack.h: * inspector/agents/InspectorAgent.cpp: (Inspector::InspectorAgent::activateExtraDomain): (Inspector::InspectorAgent::activateExtraDomains): * inspector/agents/InspectorAgent.h: * inspector/agents/InspectorConsoleAgent.cpp: (Inspector::InspectorConsoleAgent::getLoggingChannels): * inspector/agents/InspectorConsoleAgent.h: * inspector/agents/InspectorDebuggerAgent.cpp: (Inspector::InspectorDebuggerAgent::setBreakpointByUrl): (Inspector::InspectorDebuggerAgent::searchInContent): (Inspector::InspectorDebuggerAgent::currentCallFrames): * inspector/agents/InspectorDebuggerAgent.h: * inspector/agents/InspectorRuntimeAgent.cpp: (Inspector::InspectorRuntimeAgent::getProperties): (Inspector::InspectorRuntimeAgent::getDisplayableProperties): (Inspector::InspectorRuntimeAgent::getCollectionEntries): (Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets): (Inspector::InspectorRuntimeAgent::getBasicBlocks): * inspector/agents/InspectorRuntimeAgent.h: * inspector/agents/InspectorScriptProfilerAgent.cpp: (Inspector::buildSamples): Use more 'auto' and rename a variable. * inspector/scripts/codegen/cpp_generator.py: (CppGenerator.cpp_protocol_type_for_type): Adopt new type names. This exposed a latent bug where we should have been unwrapping an AliasedType prior to generating a C++ type for it. The aliased type may be an array, in which case we would have generated the wrong type. * inspector/scripts/codegen/generate_cpp_protocol_types_header.py: (_generate_typedefs_for_domain.JSON): (_generate_typedefs_for_domain.Inspector): Deleted. * inspector/scripts/codegen/objc_generator.py: (ObjCGenerator.protocol_type_for_type): (ObjCGenerator.objc_protocol_export_expression_for_variable): * inspector/scripts/tests/generic/expected/commands-with-async-attribute.json-result: * inspector/scripts/tests/generic/expected/commands-with-optional-call-return-parameters.json-result: * inspector/scripts/tests/generic/expected/events-with-optional-parameters.json-result: * inspector/scripts/tests/generic/expected/shadowed-optional-type-setters.json-result: * inspector/scripts/tests/generic/expected/type-declaration-array-type.json-result: * inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result: Rebaseline. * runtime/TypeSet.cpp: (JSC::TypeSet::allStructureRepresentations const): (JSC::StructureShape::inspectorRepresentation): * runtime/TypeSet.h: 2017-12-01 Saam Barati Having a bad time needs to handle ArrayClass indexing type as well https://bugs.webkit.org/show_bug.cgi?id=180274 Reviewed by Keith Miller and Mark Lam. We need to make sure to transition ArrayClass to SlowPutArrayStorage as well. Otherwise, we'll end up with the wrong Structure, which will lead us to not adhere to the spec. The bug was that we were not considering ArrayClass inside hasBrokenIndexing. This patch rewrites that function to automatically opt in non-empty indexing types as broken, instead of having to opt out all non-empty indexing types besides SlowPutArrayStorage. * runtime/IndexingType.h: (JSC::hasSlowPutArrayStorage): (JSC::shouldUseSlowPut): * runtime/JSGlobalObject.cpp: * runtime/JSObject.cpp: (JSC::JSObject::switchToSlowPutArrayStorage): 2017-12-01 JF Bastien WebAssembly: stack trace improvement follow-ups https://bugs.webkit.org/show_bug.cgi?id=180273 Reviewed by Saam Barati. * wasm/WasmIndexOrName.cpp: (JSC::Wasm::makeString): * wasm/WasmIndexOrName.h: (JSC::Wasm::IndexOrName::nameSection const): * wasm/WasmNameSection.h: (JSC::Wasm::NameSection::NameSection): (JSC::Wasm::NameSection::get): 2017-12-01 JF Bastien WebAssembly: restore cached stack limit after out-call https://bugs.webkit.org/show_bug.cgi?id=179106 Reviewed by Saam Barati. We cache the stack limit on the Instance so that we can do fast stack checks where required. In regular usage the stack limit never changes because we always run on the same thread, but in rare cases an API user can totally migrate which thread (and therefore stack) is used for execution between WebAssembly traces. For that reason we set the cached stack limit to UINTPTR_MAX on the outgoing Instance when transitioning back into a different Instance. We usually restore the cached stack limit in Context::store, but this wasn't called on all code paths. We had a bug where an Instance calling into itself indirectly would therefore fail to restore its cached stack limit properly. This patch therefore restores the cached stack limit after direct calls which could be to imports (both wasm->wasm and wasm->embedder). We have to do all of them because we have no way of knowing what imports will do (they're known at instantiation time, not compilation time, and different instances can have different imports). To make this efficient we also add a pointer to the canonical location of the stack limit (i.e. the extra indirection we're trying to save by caching the stack limit on the Instance in the first place). This is potentially a small perf hit on imported direct calls. It's hard to say what the performance cost will be because we haven't seen much code in the wild which does this. We're adding two dependent loads and a store of the loaded value, which is unlikely to get used soon after. It's more code, but on an out-of-order processor it doesn't contribute to the critical path. * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState): (JSC::Wasm::B3IRGenerator::addGrowMemory): (JSC::Wasm::B3IRGenerator::addCall): (JSC::Wasm::B3IRGenerator::addCallIndirect): * wasm/WasmInstance.cpp: (JSC::Wasm::Instance::Instance): (JSC::Wasm::Instance::create): * wasm/WasmInstance.h: (JSC::Wasm::Instance::offsetOfPointerToActualStackLimit): (JSC::Wasm::Instance::cachedStackLimit const): (JSC::Wasm::Instance::setCachedStackLimit): * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::create): * wasm/js/WebAssemblyFunction.cpp: (JSC::callWebAssemblyFunction): 2017-11-30 Yusuke Suzuki [JSC] Use JSFixedArray for op_new_array_buffer https://bugs.webkit.org/show_bug.cgi?id=180084 Reviewed by Saam Barati. For op_new_array_buffer, we have a special constant buffer in CodeBlock. But using JSFixedArray is better because, 1. In DFG, we have special hashing mechanism to avoid duplicating constant buffer from the same CodeBlock. If we use JSFixedArray, this is unnecessary since JSFixedArray is handled just as JS constant. 2. In a subsequent patch[1], we would like to support Spread(PhantomNewArrayBuffer). If NewArrayBuffer has JSFixedArray, we can just emit a held JSFixedArray. 3. We can reduce length of op_new_array_buffer since JSFixedArray holds this. 4. We can fold NewArrayBufferData into uint64_t. No need to maintain a bag of NewArrayBufferData in DFG. 5. We do not need to look up constant buffer from CodeBlock if buffer data is necessary. Our NewArrayBuffer DFG node has JSFixedArray as its cellOperand. This makes materializing PhantomNewArrayBuffer easy, which will be introduced in [1]. [1]: https://bugs.webkit.org/show_bug.cgi?id=179762 * bytecode/BytecodeDumper.cpp: (JSC::BytecodeDumper::dumpBytecode): * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): * bytecode/CodeBlock.h: (JSC::CodeBlock::numberOfConstantBuffers const): Deleted. (JSC::CodeBlock::addConstantBuffer): Deleted. (JSC::CodeBlock::constantBufferAsVector): Deleted. (JSC::CodeBlock::constantBuffer): Deleted. * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::shrinkToFit): * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedCodeBlock::constantBufferCount): Deleted. (JSC::UnlinkedCodeBlock::addConstantBuffer): Deleted. (JSC::UnlinkedCodeBlock::constantBuffer const): Deleted. (JSC::UnlinkedCodeBlock::constantBuffer): Deleted. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitNewArray): (JSC::BytecodeGenerator::addConstantBuffer): Deleted. * bytecompiler/BytecodeGenerator.h: * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): (JSC::DFG::ConstantBufferKey::ConstantBufferKey): Deleted. (JSC::DFG::ConstantBufferKey::operator== const): Deleted. (JSC::DFG::ConstantBufferKey::hash const): Deleted. (JSC::DFG::ConstantBufferKey::isHashTableDeletedValue const): Deleted. (JSC::DFG::ConstantBufferKey::codeBlock const): Deleted. (JSC::DFG::ConstantBufferKey::index const): Deleted. (JSC::DFG::ConstantBufferKeyHash::hash): Deleted. (JSC::DFG::ConstantBufferKeyHash::equal): Deleted. * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGGraph.h: * dfg/DFGNode.h: (JSC::DFG::Node::hasNewArrayBufferData): (JSC::DFG::Node::newArrayBufferData): (JSC::DFG::Node::hasVectorLengthHint): (JSC::DFG::Node::vectorLengthHint): (JSC::DFG::Node::indexingType): (JSC::DFG::Node::hasCellOperand): (JSC::DFG::Node::OpInfoWrapper::operator=): (JSC::DFG::Node::OpInfoWrapper::asNewArrayBufferData const): (JSC::DFG::Node::hasConstantBuffer): Deleted. (JSC::DFG::Node::startConstant): Deleted. (JSC::DFG::Node::numConstants): Deleted. * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayBuffer): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JIT.h: * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_new_array_buffer): Deleted. * jit/JITOperations.cpp: * jit/JITOperations.h: * llint/LLIntSlowPaths.cpp: * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter.asm: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: * runtime/JSFixedArray.cpp: (JSC::JSFixedArray::dumpToStream): * runtime/JSFixedArray.h: (JSC::JSFixedArray::create): (JSC::JSFixedArray::get const): (JSC::JSFixedArray::set): (JSC::JSFixedArray::buffer const): (JSC::JSFixedArray::values const): (JSC::JSFixedArray::length const): (JSC::JSFixedArray::get): Deleted. 2017-11-30 JF Bastien WebAssembly: improve stack trace https://bugs.webkit.org/show_bug.cgi?id=179343 Reviewed by Saam Barati. Stack traces now include: - Module name, if provided by the name section. - Module SHA1 hash if no name was provided - Stub identification, to differentiate from user code - Slightly different naming to match design from: https://github.com/WebAssembly/design/blob/master/Web.md#developer-facing-display-conventions * interpreter/StackVisitor.cpp: (JSC::StackVisitor::Frame::functionName const): * runtime/StackFrame.cpp: (JSC::StackFrame::functionName const): (JSC::StackFrame::visitChildren): * wasm/WasmIndexOrName.cpp: (JSC::Wasm::IndexOrName::IndexOrName): (JSC::Wasm::makeString): * wasm/WasmIndexOrName.h: (JSC::Wasm::IndexOrName::nameSection const): * wasm/WasmModuleInformation.cpp: (JSC::Wasm::ModuleInformation::ModuleInformation): * wasm/WasmModuleInformation.h: * wasm/WasmNameSection.h: (JSC::Wasm::NameSection::NameSection): (JSC::Wasm::NameSection::get): * wasm/WasmNameSectionParser.cpp: (JSC::Wasm::NameSectionParser::parse): 2017-11-30 Stephan Szabo Make LegacyCustomProtocolManager optional for network process https://bugs.webkit.org/show_bug.cgi?id=176230 Reviewed by Alex Christensen. * Configurations/FeatureDefines.xcconfig: 2017-11-30 Yusuke Suzuki [JSC] Remove easy toRemove & map.remove() use in OAS phase https://bugs.webkit.org/show_bug.cgi?id=180208 Reviewed by Mark Lam. In this patch, we replace Vector<> toRemove & map.remove loop with removeIf, to optimize this common pattern. This patch only modifies apparent ones. But we can apply this refactoring further to OAS phase in the future. One thing we should care is that predicate of removeIf should not touch the removing set itself. In this patch, we apply this change to (1) apparently correct one and (2) things in DFG OAS phase since it is very slow. * b3/B3MoveConstants.cpp: * dfg/DFGObjectAllocationSinkingPhase.cpp: 2017-11-30 Commit Queue Unreviewed, rolling out r225362. https://bugs.webkit.org/show_bug.cgi?id=180225 removeIf predicate function can touch remove target set (Requested by yusukesuzuki on #webkit). Reverted changeset: "[JSC] Remove easy toRemove & map.remove() use" https://bugs.webkit.org/show_bug.cgi?id=180208 https://trac.webkit.org/changeset/225362 2017-11-30 Yusuke Suzuki [JSC] Use AllocatorIfExists for MaterializeNewObject https://bugs.webkit.org/show_bug.cgi?id=180189 Reviewed by Filip Pizlo. I don't think anyone guarantees this allocator exists at this phase. And nullptr allocator just works here. We change AllocatorForMode to AllocatorIfExists to accept nullptr for allocator. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject): 2017-11-30 Mark Lam Let's scramble MacroAssemblerCodePtr values. https://bugs.webkit.org/show_bug.cgi?id=180169 Reviewed by Filip Pizlo, Saam Barati, and JF Bastien. 1. MacroAssemblerCodePtr now stores a ScrambledPtr instead of a void*. 2. MacroAssemblerCodePtr's executableAddress() and dataLocation() now take a template argument type that will be used to cast the result. This makes the client code that uses these functions a little less verbose. 3. Change the code base in general to minimize passing void* code pointers around. We now pass MacroAssemblerCodePtr as much as possible, and descramble it only at the last moment when we need the underlying code pointer. 4. Added some MasmScrambledPtr paranoid asserts that are disabled (not built) by default. I'm leaving them in because they are instrumental in finding bugs where not all MacroAssemblerCodePtr values were not scrambled as expected. I expect them to be useful in the near future as we add more scrambling. 5. Also disable the casting operator on MacroAssemblerCodePtr (except for explicit casts to a boolean). This ensures that clients will always explicitly use scrambledBits() or executableAddress() to get a value based on which value they actually need. 5. Added currentThread() id to the logging in LLIntSlowPath trace functions. This was helpful when debugging tests that ran multiple VMs concurrently on different threads. MacroAssemblerCodePtr is currently supported on 64-bit builds (including the CLoop). It is not yet supported in 32-bit and Windows because we don't currently have a way to read a global variable from their LLInt code. * assembler/AbstractMacroAssembler.h: (JSC::AbstractMacroAssembler::differenceBetweenCodePtr): (JSC::AbstractMacroAssembler::linkPointer): * assembler/CodeLocation.h: (JSC::CodeLocationCommon::instructionAtOffset): (JSC::CodeLocationCommon::labelAtOffset): (JSC::CodeLocationCommon::jumpAtOffset): (JSC::CodeLocationCommon::callAtOffset): (JSC::CodeLocationCommon::nearCallAtOffset): (JSC::CodeLocationCommon::dataLabelPtrAtOffset): (JSC::CodeLocationCommon::dataLabel32AtOffset): (JSC::CodeLocationCommon::dataLabelCompactAtOffset): (JSC::CodeLocationCommon::convertibleLoadAtOffset): * assembler/LinkBuffer.cpp: (JSC::LinkBuffer::finalizeCodeWithDisassembly): * assembler/LinkBuffer.h: (JSC::LinkBuffer::link): (JSC::LinkBuffer::patch): * assembler/MacroAssemblerCodeRef.cpp: (JSC::MacroAssemblerCodePtr::initialize): * assembler/MacroAssemblerCodeRef.h: (JSC::FunctionPtr::FunctionPtr): (JSC::FunctionPtr::value const): (JSC::FunctionPtr::executableAddress const): (JSC::ReturnAddressPtr::ReturnAddressPtr): (JSC::ReturnAddressPtr::value const): (JSC::MacroAssemblerCodePtr::MacroAssemblerCodePtr): (JSC::MacroAssemblerCodePtr::createFromExecutableAddress): (JSC::MacroAssemblerCodePtr::scrambledPtr const): (JSC::MacroAssemblerCodePtr:: const): (JSC::MacroAssemblerCodePtr::operator! const): (JSC::MacroAssemblerCodePtr::operator bool const): (JSC::MacroAssemblerCodePtr::operator== const): (JSC::MacroAssemblerCodePtr::hash const): (JSC::MacroAssemblerCodePtr::emptyValue): (JSC::MacroAssemblerCodePtr::deletedValue): (JSC::MacroAssemblerCodePtr::executableAddress const): Deleted. (JSC::MacroAssemblerCodePtr::dataLocation const): Deleted. * b3/B3LowerMacros.cpp: * b3/testb3.cpp: (JSC::B3::testInterpreter): * dfg/DFGDisassembler.cpp: (JSC::DFG::Disassembler::dumpDisassembly): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::link): (JSC::DFG::JITCompiler::compileFunction): * dfg/DFGOperations.cpp: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::emitSwitchIntJump): (JSC::DFG::SpeculativeJIT::emitSwitchImm): (JSC::DFG::SpeculativeJIT::emitSwitchCharStringJump): (JSC::DFG::SpeculativeJIT::emitSwitchChar): * dfg/DFGSpeculativeJIT.h: * disassembler/Disassembler.cpp: (JSC::disassemble): * disassembler/UDis86Disassembler.cpp: (JSC::tryToDisassembleWithUDis86): * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLJITCode.cpp: (JSC::FTL::JITCode::executableAddressAtOffset): * ftl/FTLLink.cpp: (JSC::FTL::link): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileMathIC): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct): (JSC::FTL::DFG::LowerDFGToB3::compileTailCall): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs): * interpreter/InterpreterInlines.h: (JSC::Interpreter::getOpcodeID): * jit/JITArithmetic.cpp: (JSC::JIT::emitMathICFast): (JSC::JIT::emitMathICSlow): * jit/JITCode.cpp: (JSC::JITCodeWithCodeRef::executableAddressAtOffset): (JSC::JITCodeWithCodeRef::dataAddressAtOffset): (JSC::JITCodeWithCodeRef::offsetOf): * jit/JITDisassembler.cpp: (JSC::JITDisassembler::dumpDisassembly): * jit/PCToCodeOriginMap.cpp: (JSC::PCToCodeOriginMap::PCToCodeOriginMap): * jit/Repatch.cpp: (JSC::ftlThunkAwareRepatchCall): * jit/ThunkGenerators.cpp: (JSC::virtualThunkFor): (JSC::boundThisNoArgsFunctionCallGenerator): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::llint_trace_operand): (JSC::LLInt::llint_trace_value): (JSC::LLInt::handleHostCall): (JSC::LLInt::setUpCall): * llint/LowLevelInterpreter64.asm: * offlineasm/cloop.rb: * runtime/InitializeThreading.cpp: (JSC::initializeThreading): * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::complete): * wasm/WasmCallee.h: (JSC::Wasm::Callee::entrypoint const): * wasm/WasmCodeBlock.cpp: (JSC::Wasm::CodeBlock::CodeBlock): * wasm/WasmOMGPlan.cpp: (JSC::Wasm::OMGPlan::work): * wasm/js/WasmToJS.cpp: (JSC::Wasm::wasmToJS): * wasm/js/WebAssemblyFunction.cpp: (JSC::callWebAssemblyFunction): * wasm/js/WebAssemblyFunction.h: * wasm/js/WebAssemblyWrapperFunction.cpp: (JSC::WebAssemblyWrapperFunction::create): 2017-11-30 Yusuke Suzuki [JSC] Remove easy toRemove & map.remove() use https://bugs.webkit.org/show_bug.cgi?id=180208 Reviewed by Mark Lam. In this patch, we replace Vector<> toRemove & map.remove loop with removeIf, to optimize this common pattern. This patch only modifies apparent ones. But we can apply this refactoring further to OAS phase in the future. * b3/B3MoveConstants.cpp: * dfg/DFGArgumentsEliminationPhase.cpp: * dfg/DFGObjectAllocationSinkingPhase.cpp: * wasm/WasmSignature.cpp: (JSC::Wasm::SignatureInformation::tryCleanup): 2017-11-29 Yusuke Suzuki [JSC] Use getEffectiveAddress more in JSC https://bugs.webkit.org/show_bug.cgi?id=180154 Reviewed by Mark Lam. We can use MacroAssembler::getEffectiveAddress for stack height calculation. And we also add MacroAssembler::negPtr(src, dest) variation. * assembler/MacroAssembler.h: (JSC::MacroAssembler::negPtr): * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::neg32): * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::neg32): (JSC::MacroAssemblerARM64::neg64): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::neg32): * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::neg32): * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::neg32): * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::neg64): * dfg/DFGThunks.cpp: (JSC::DFG::osrEntryThunkGenerator): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread): * jit/SetupVarargsFrame.cpp: (JSC::emitSetVarargsFrame): 2017-11-30 Mark Lam jsc shell's flashHeapAccess() should not do JS work after releasing access to the heap. https://bugs.webkit.org/show_bug.cgi?id=180219 Reviewed by Filip Pizlo. * jsc.cpp: (functionFlashHeapAccess): 2017-11-30 Yusuke Suzuki [DFG][FTL] operationHasIndexedProperty does not consider negative int32_t https://bugs.webkit.org/show_bug.cgi?id=180190 Reviewed by Mark Lam. If DFG HasIndexedProperty node observes negative index, it goes to a slow path by calling operationHasIndexedProperty. The problem is that operationHasIndexedProperty does not account negative index. Negative index was used as uint32 array index. In this patch we add a path for negative index in operationHasIndexedProperty. And rename it to operationHasIndexedPropertyByInt to make intension clear. We also move operationHasIndexedPropertyByInt from JITOperations to DFGOperations since it is only used in DFG and FTL. While fixing this bug, we found that our op_in does not record OutOfBound feedback. This causes repeated OSR exit and significantly regresses the performance. We opened a bug to track this issue[1]. [1]: https://bugs.webkit.org/show_bug.cgi?id=180192 * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileHasIndexedProperty): * jit/JITOperations.cpp: * jit/JITOperations.h: 2017-11-30 Michael Saboff Allow JSC command line tool to accept UTF8 https://bugs.webkit.org/show_bug.cgi?id=180205 Reviewed by Keith Miller. This unifies the UTF8 handling of interactive mode with that of source files. * jsc.cpp: (runInteractive): 2017-11-30 Yusuke Suzuki REGRESSION(r225314): [Linux] More than 2000 jsc tests are failing after r225314 https://bugs.webkit.org/show_bug.cgi?id=180185 Reviewed by Carlos Garcia Campos. After r225314, we start using AllocatorForMode::MustAlreadyHaveAllocator for JSRopeString's allocatorFor. But it is different from the original code used before r225314. Since DFGSpeculativeJIT::emitAllocateJSCell can accept nullptr allocator, the behavior of the original code is AllocatorForMode::AllocatorIfExists. And JSRopeString's allocator may not exist at this point if any JSRopeString is not allocated. But MakeRope DFG node can be emitted if we see untaken path includes String + String code. This patch fixes Linux JSC crashes by changing JSRopeString's AllocatorForMode to AllocatorIfExists. As a result, only one user of AllocatorForMode::MustAlreadyHaveAllocator is MaterializeNewObject in FTL. I'm not sure why this condition (MustAlreadyHaveAllocator) is ensured. But this code is the same to the original code used before r225314. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileMakeRope): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope): 2017-11-28 Filip Pizlo CodeBlockSet::deleteUnmarkedAndUnreferenced can be a little more efficient https://bugs.webkit.org/show_bug.cgi?id=180108 Reviewed by Saam Barati. This was creating a vector of things to remove and then removing them. I think I remember writing this code, and I did that because at the time we did not have removeAllMatching, which is definitely better. This is a minuscule optimization for Speedometer. I wanted to land this obvious improvement before I did more fundamental things to this code. * heap/CodeBlockSet.cpp: (JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced): 2017-11-29 Filip Pizlo GC should support isoheaps https://bugs.webkit.org/show_bug.cgi?id=179288 Reviewed by Saam Barati. This expands the power of the Subspace API in JSC: - Everything associated with describing the types of objects is now part of the HeapCellType class. We have different HeapCellTypes for different destruction strategies. Any Subspace can use any HeapCellType; these are orthogonal things. - There are now two variants of Subspace: CompleteSubspace, which can allocate any size objects using any AlignedMemoryAllocator; and IsoSubspace, which can allocate just one size of object and uses a special virtual memory pool for that purpose. Like bmalloc's IsoHeap, IsoSubspace hoards virtual pages but releases the physical pages as part of the respective allocator's scavenging policy (the Scavenger in bmalloc for IsoHeap and the incremental sweep and full sweep in Riptide for IsoSubspace). So far, this patch just puts subtypes of ExecutableBase in IsoSubspaces. If it works, we can use it for more things. This does not have any effect on JetStream (0.18% faster with p = 0.69). * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * bytecode/AccessCase.cpp: (JSC::AccessCase::generateImpl): * bytecode/ObjectAllocationProfileInlines.h: (JSC::ObjectAllocationProfile::initializeProfile): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::emitAllocateRawObject): (JSC::DFG::SpeculativeJIT::compileMakeRope): (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage): (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLAbstractHeapRepository.h: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope): (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject): (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorageWithSizeImpl): (JSC::FTL::DFG::LowerDFGToB3::allocateObject): (JSC::FTL::DFG::LowerDFGToB3::allocatorForSize): * heap/AlignedMemoryAllocator.cpp: (JSC::AlignedMemoryAllocator::registerAllocator): (JSC::AlignedMemoryAllocator::registerSubspace): * heap/AlignedMemoryAllocator.h: (JSC::AlignedMemoryAllocator::firstAllocator const): * heap/AllocationFailureMode.h: Added. * heap/CompleteSubspace.cpp: Added. (JSC::CompleteSubspace::CompleteSubspace): (JSC::CompleteSubspace::~CompleteSubspace): (JSC::CompleteSubspace::allocatorFor): (JSC::CompleteSubspace::allocate): (JSC::CompleteSubspace::allocateNonVirtual): (JSC::CompleteSubspace::allocatorForSlow): (JSC::CompleteSubspace::allocateSlow): (JSC::CompleteSubspace::tryAllocateSlow): * heap/CompleteSubspace.h: Added. (JSC::CompleteSubspace::offsetOfAllocatorForSizeStep): (JSC::CompleteSubspace::allocatorForSizeStep): (JSC::CompleteSubspace::allocatorForNonVirtual): * heap/HeapCellType.cpp: Added. (JSC::HeapCellType::HeapCellType): (JSC::HeapCellType::~HeapCellType): (JSC::HeapCellType::finishSweep): (JSC::HeapCellType::destroy): * heap/HeapCellType.h: Added. (JSC::HeapCellType::attributes const): * heap/IsoAlignedMemoryAllocator.cpp: Added. (JSC::IsoAlignedMemoryAllocator::IsoAlignedMemoryAllocator): (JSC::IsoAlignedMemoryAllocator::~IsoAlignedMemoryAllocator): (JSC::IsoAlignedMemoryAllocator::tryAllocateAlignedMemory): (JSC::IsoAlignedMemoryAllocator::freeAlignedMemory): (JSC::IsoAlignedMemoryAllocator::dump const): * heap/IsoAlignedMemoryAllocator.h: Added. * heap/IsoSubspace.cpp: Added. (JSC::IsoSubspace::IsoSubspace): (JSC::IsoSubspace::~IsoSubspace): (JSC::IsoSubspace::allocatorFor): (JSC::IsoSubspace::allocatorForNonVirtual): (JSC::IsoSubspace::allocate): (JSC::IsoSubspace::allocateNonVirtual): * heap/IsoSubspace.h: Added. (JSC::IsoSubspace::size const): * heap/MarkedAllocator.cpp: (JSC::MarkedAllocator::MarkedAllocator): (JSC::MarkedAllocator::setSubspace): (JSC::MarkedAllocator::allocateSlowCase): (JSC::MarkedAllocator::tryAllocateSlowCase): Deleted. (JSC::MarkedAllocator::allocateSlowCaseImpl): Deleted. * heap/MarkedAllocator.h: (JSC::MarkedAllocator::nextAllocatorInAlignedMemoryAllocator const): (JSC::MarkedAllocator::setNextAllocatorInAlignedMemoryAllocator): * heap/MarkedAllocatorInlines.h: (JSC::MarkedAllocator::allocate): (JSC::MarkedAllocator::tryAllocate): Deleted. * heap/MarkedBlock.h: * heap/MarkedBlockInlines.h: (JSC::MarkedBlock::Handle::finishSweepKnowingHeapCellType): (JSC::MarkedBlock::Handle::finishSweepKnowingSubspace): Deleted. * heap/MarkedSpace.cpp: (JSC::MarkedSpace::addMarkedAllocator): * heap/MarkedSpace.h: * heap/Subspace.cpp: (JSC::Subspace::Subspace): (JSC::Subspace::initialize): (JSC::Subspace::finishSweep): (JSC::Subspace::destroy): (JSC::Subspace::prepareForAllocation): (JSC::Subspace::findEmptyBlockToSteal): (): Deleted. (JSC::Subspace::allocate): Deleted. (JSC::Subspace::tryAllocate): Deleted. (JSC::Subspace::allocatorForSlow): Deleted. (JSC::Subspace::allocateSlow): Deleted. (JSC::Subspace::tryAllocateSlow): Deleted. (JSC::Subspace::didAllocate): Deleted. * heap/Subspace.h: (JSC::Subspace::heapCellType const): (JSC::Subspace::nextSubspaceInAlignedMemoryAllocator const): (JSC::Subspace::setNextSubspaceInAlignedMemoryAllocator): (JSC::Subspace::offsetOfAllocatorForSizeStep): Deleted. (JSC::Subspace::allocatorForSizeStep): Deleted. (JSC::Subspace::tryAllocatorFor): Deleted. (JSC::Subspace::allocatorFor): Deleted. * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::emitAllocateJSObjectWithKnownSize): (JSC::AssemblyHelpers::emitAllocateVariableSized): (JSC::AssemblyHelpers::emitAllocateVariableSizedCell): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_new_object): * runtime/ButterflyInlines.h: (JSC::Butterfly::createUninitialized): (JSC::Butterfly::tryCreate): (JSC::Butterfly::growArrayRight): * runtime/DirectArguments.cpp: (JSC::DirectArguments::overrideThings): * runtime/DirectArguments.h: (JSC::DirectArguments::subspaceFor): * runtime/DirectEvalExecutable.h: * runtime/EvalExecutable.h: * runtime/ExecutableBase.h: (JSC::ExecutableBase::subspaceFor): * runtime/FunctionExecutable.h: * runtime/GenericArgumentsInlines.h: (JSC::GenericArguments::initModifiedArgumentsDescriptor): * runtime/HashMapImpl.h: (JSC::HashMapBuffer::create): * runtime/IndirectEvalExecutable.h: * runtime/JSArray.cpp: (JSC::JSArray::tryCreateUninitializedRestricted): (JSC::JSArray::unshiftCountSlowCase): * runtime/JSArray.h: (JSC::JSArray::tryCreate): * runtime/JSArrayBufferView.cpp: (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext): * runtime/JSCell.h: (JSC::subspaceFor): * runtime/JSCellInlines.h: (JSC::JSCell::subspaceFor): (JSC::tryAllocateCellHelper): (JSC::allocateCell): (JSC::tryAllocateCell): * runtime/JSDestructibleObject.h: (JSC::JSDestructibleObject::subspaceFor): * runtime/JSDestructibleObjectHeapCellType.cpp: Copied from Source/JavaScriptCore/runtime/JSDestructibleObjectSubspace.cpp. (JSC::JSDestructibleObjectHeapCellType::JSDestructibleObjectHeapCellType): (JSC::JSDestructibleObjectHeapCellType::~JSDestructibleObjectHeapCellType): (JSC::JSDestructibleObjectHeapCellType::finishSweep): (JSC::JSDestructibleObjectHeapCellType::destroy): (JSC::JSDestructibleObjectSubspace::JSDestructibleObjectSubspace): Deleted. (JSC::JSDestructibleObjectSubspace::~JSDestructibleObjectSubspace): Deleted. (JSC::JSDestructibleObjectSubspace::finishSweep): Deleted. (JSC::JSDestructibleObjectSubspace::destroy): Deleted. * runtime/JSDestructibleObjectHeapCellType.h: Copied from Source/JavaScriptCore/runtime/JSDestructibleObjectSubspace.h. * runtime/JSDestructibleObjectSubspace.cpp: Removed. * runtime/JSDestructibleObjectSubspace.h: Removed. * runtime/JSLexicalEnvironment.h: (JSC::JSLexicalEnvironment::subspaceFor): * runtime/JSSegmentedVariableObject.h: (JSC::JSSegmentedVariableObject::subspaceFor): * runtime/JSSegmentedVariableObjectHeapCellType.cpp: Copied from Source/JavaScriptCore/runtime/JSSegmentedVariableObjectSubspace.cpp. (JSC::JSSegmentedVariableObjectHeapCellType::JSSegmentedVariableObjectHeapCellType): (JSC::JSSegmentedVariableObjectHeapCellType::~JSSegmentedVariableObjectHeapCellType): (JSC::JSSegmentedVariableObjectHeapCellType::finishSweep): (JSC::JSSegmentedVariableObjectHeapCellType::destroy): (JSC::JSSegmentedVariableObjectSubspace::JSSegmentedVariableObjectSubspace): Deleted. (JSC::JSSegmentedVariableObjectSubspace::~JSSegmentedVariableObjectSubspace): Deleted. (JSC::JSSegmentedVariableObjectSubspace::finishSweep): Deleted. (JSC::JSSegmentedVariableObjectSubspace::destroy): Deleted. * runtime/JSSegmentedVariableObjectHeapCellType.h: Copied from Source/JavaScriptCore/runtime/JSSegmentedVariableObjectSubspace.h. * runtime/JSSegmentedVariableObjectSubspace.cpp: Removed. * runtime/JSSegmentedVariableObjectSubspace.h: Removed. * runtime/JSString.h: (JSC::JSString::subspaceFor): * runtime/JSStringHeapCellType.cpp: Copied from Source/JavaScriptCore/runtime/JSStringSubspace.cpp. (JSC::JSStringHeapCellType::JSStringHeapCellType): (JSC::JSStringHeapCellType::~JSStringHeapCellType): (JSC::JSStringHeapCellType::finishSweep): (JSC::JSStringHeapCellType::destroy): (JSC::JSStringSubspace::JSStringSubspace): Deleted. (JSC::JSStringSubspace::~JSStringSubspace): Deleted. (JSC::JSStringSubspace::finishSweep): Deleted. (JSC::JSStringSubspace::destroy): Deleted. * runtime/JSStringHeapCellType.h: Copied from Source/JavaScriptCore/runtime/JSStringSubspace.h. * runtime/JSStringSubspace.cpp: Removed. * runtime/JSStringSubspace.h: Removed. * runtime/ModuleProgramExecutable.h: * runtime/NativeExecutable.h: * runtime/ProgramExecutable.h: * runtime/RegExpMatchesArray.h: (JSC::tryCreateUninitializedRegExpMatchesArray): * runtime/ScopedArguments.h: (JSC::ScopedArguments::subspaceFor): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: (JSC::VM::gigacageAuxiliarySpace): * wasm/js/JSWebAssemblyCodeBlock.h: * wasm/js/JSWebAssemblyCodeBlockHeapCellType.cpp: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyCodeBlockSubspace.cpp. (JSC::JSWebAssemblyCodeBlockHeapCellType::JSWebAssemblyCodeBlockHeapCellType): (JSC::JSWebAssemblyCodeBlockHeapCellType::~JSWebAssemblyCodeBlockHeapCellType): (JSC::JSWebAssemblyCodeBlockHeapCellType::finishSweep): (JSC::JSWebAssemblyCodeBlockHeapCellType::destroy): (JSC::JSWebAssemblyCodeBlockSubspace::JSWebAssemblyCodeBlockSubspace): Deleted. (JSC::JSWebAssemblyCodeBlockSubspace::~JSWebAssemblyCodeBlockSubspace): Deleted. (JSC::JSWebAssemblyCodeBlockSubspace::finishSweep): Deleted. (JSC::JSWebAssemblyCodeBlockSubspace::destroy): Deleted. * wasm/js/JSWebAssemblyCodeBlockHeapCellType.h: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyCodeBlockSubspace.h. * wasm/js/JSWebAssemblyCodeBlockSubspace.cpp: Removed. * wasm/js/JSWebAssemblyCodeBlockSubspace.h: Removed. * wasm/js/JSWebAssemblyMemory.h: (JSC::JSWebAssemblyMemory::subspaceFor): 2017-11-29 Saam Barati Remove pointer caging for double arrays https://bugs.webkit.org/show_bug.cgi?id=180163 Reviewed by Mark Lam. This patch removes pointer caging from double arrays. Like my previous removals of pointer caging, this is a security vs performance tradeoff. We believe that butterflies being allocated in the cage and with a 32GB runway gives us enough security that pointer caging the butterfly just for double arrays does not add enough security benefit for the performance hit it incurs. This patch also removes the GetButterflyWithoutCaging node and the FixedButterflyAccessUncaging phase. The node is no longer needed because now all GetButterfly nodes are not caged. The phase is removed since we no longer have two nodes. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGArgumentsEliminationPhase.cpp: * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixedButterflyAccessUncagingPhase.cpp: Removed. * dfg/DFGFixedButterflyAccessUncagingPhase.h: Removed. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGHeapLocation.cpp: (WTF::printInternal): * dfg/DFGHeapLocation.h: * dfg/DFGNodeType.h: * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThreadImpl): * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileSpread): (JSC::DFG::SpeculativeJIT::compileArraySlice): (JSC::DFG::SpeculativeJIT::compileGetButterfly): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGTypeCheckHoistingPhase.cpp: (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks): (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileGetButterfly): * jit/JITPropertyAccess.cpp: (JSC::JIT::emitDoubleLoad): (JSC::JIT::emitGenericContiguousPutByVal): * runtime/Butterfly.h: (JSC::Butterfly::pointer): (JSC::Butterfly::contiguousDouble): (JSC::Butterfly::caged): Deleted. * runtime/ButterflyInlines.h: (JSC::Butterfly::createOrGrowPropertyStorage): * runtime/JSObject.cpp: (JSC::JSObject::ensureLengthSlow): (JSC::JSObject::reallocateAndShrinkButterfly): 2017-11-29 Stanislav Ocovaj [MIPS][JSC] Implement MacroAssembler::probe support on MIPS https://bugs.webkit.org/show_bug.cgi?id=175447 Reviewed by Carlos Alberto Lopez Perez. This patch allows DFG JIT to be enabled on MIPS platforms. * Sources.txt: * assembler/MIPSAssembler.h: (JSC::MIPSAssembler::lastSPRegister): (JSC::MIPSAssembler::numberOfSPRegisters): (JSC::MIPSAssembler::sprName): * assembler/MacroAssemblerMIPS.cpp: Added. (JSC::MacroAssembler::probe): * assembler/ProbeContext.cpp: (JSC::Probe::executeProbe): * assembler/ProbeContext.h: (JSC::Probe::CPUState::pc): * assembler/testmasm.cpp: (JSC::isSpecialGPR): (JSC::testProbePreservesGPRS): (JSC::testProbeModifiesStackPointer): (JSC::testProbeModifiesStackValues): 2017-11-29 Matt Lewis Unreviewed, rolling out r225286. The source files within this patch have been marked as executable. Reverted changeset: "[MIPS][JSC] Implement MacroAssembler::probe support on MIPS" https://bugs.webkit.org/show_bug.cgi?id=175447 https://trac.webkit.org/changeset/225286 2017-11-29 Alex Christensen Fix Mac CMake build. * PlatformMac.cmake: 2017-11-29 Stanislav Ocovaj [MIPS][JSC] Implement MacroAssembler::probe support on MIPS https://bugs.webkit.org/show_bug.cgi?id=175447 Reviewed by Carlos Alberto Lopez Perez. This patch allows DFG JIT to be enabled on MIPS platforms. * Sources.txt: * assembler/MIPSAssembler.h: (JSC::MIPSAssembler::lastSPRegister): (JSC::MIPSAssembler::numberOfSPRegisters): (JSC::MIPSAssembler::sprName): * assembler/MacroAssemblerMIPS.cpp: Added. (JSC::MacroAssembler::probe): * assembler/ProbeContext.cpp: (JSC::Probe::executeProbe): * assembler/ProbeContext.h: (JSC::Probe::CPUState::pc): * assembler/testmasm.cpp: (JSC::isSpecialGPR): (JSC::testProbePreservesGPRS): (JSC::testProbeModifiesStackPointer): (JSC::testProbeModifiesStackValues): 2017-11-28 JF Bastien Strict and sloppy functions shouldn't share structure https://bugs.webkit.org/show_bug.cgi?id=180103 Reviewed by Saam Barati. Sloppy and strict functions don't act the same when it comes to arguments, caller, and callee. Sharing a structure means that anything that is cached gets shared, and that's incorrect. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileNewFunction): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction): * runtime/FunctionConstructor.cpp: (JSC::constructFunctionSkippingEvalEnabledCheck): * runtime/JSFunction.cpp: (JSC::JSFunction::create): the second ::create is always strict because it applies to native functions. * runtime/JSFunctionInlines.h: (JSC::JSFunction::createWithInvalidatedReallocationWatchpoint): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildren): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::strictFunctionStructure const): (JSC::JSGlobalObject::sloppyFunctionStructure const): (JSC::JSGlobalObject::nativeStdFunctionStructure const): (JSC::JSGlobalObject::functionStructure const): Deleted. Renamed. (JSC::JSGlobalObject::namedFunctionStructure const): Deleted. Drive-by, unused. 2017-11-29 Yusuke Suzuki [JSC] Add MacroAssembler::getEffectiveAddress in all platforms https://bugs.webkit.org/show_bug.cgi?id=180070 Reviewed by Saam Barati. This patch adds getEffectiveAddress in all JIT platforms. This is abstracted version of x86 lea. We also fix a bug in Yarr that uses branch32 instead of branchPtr for addresses. * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::getEffectiveAddress): * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::getEffectiveAddress): (JSC::MacroAssemblerARM64::getEffectiveAddress64): Deleted. * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::getEffectiveAddress): * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::getEffectiveAddress): * assembler/MacroAssemblerX86.h: (JSC::MacroAssemblerX86::getEffectiveAddress): * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::getEffectiveAddress): (JSC::MacroAssemblerX86_64::getEffectiveAddress64): Deleted. * assembler/testmasm.cpp: (JSC::testGetEffectiveAddress): (JSC::run): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArrayPush): * yarr/YarrJIT.cpp: (JSC::Yarr::YarrGenerator::tryReadUnicodeCharImpl): (JSC::Yarr::YarrGenerator::tryReadUnicodeChar): 2017-11-29 Robin Morisset The recursive tail call optimisation is wrong on closures https://bugs.webkit.org/show_bug.cgi?id=179835 Reviewed by Saam Barati. The problem is that we only check the executable of the callee, not whatever variables might have been captured. As a stopgap measure this patch just does not do the optimisation for closures. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleRecursiveTailCall): 2017-11-28 Joseph Pecoraro Web Inspector: Cleanup Inspector classes be more consistent about using fast malloc / noncopyable https://bugs.webkit.org/show_bug.cgi?id=180119 Reviewed by Devin Rousso. * inspector/InjectedScriptManager.h: * inspector/JSGlobalObjectScriptDebugServer.h: * inspector/agents/InspectorHeapAgent.h: * inspector/agents/InspectorRuntimeAgent.h: * inspector/agents/InspectorScriptProfilerAgent.h: * inspector/agents/JSGlobalObjectRuntimeAgent.h: 2017-11-28 Joseph Pecoraro ServiceWorker Inspector: Frontend changes to support Network tab and sub resources https://bugs.webkit.org/show_bug.cgi?id=179642 Reviewed by Brian Burg. * inspector/protocol/Network.json: Expose the NetworkAgent for a Service Worker inspector. 2017-11-28 Brian Burg [Cocoa] Clean up names of conversion methods after renaming InspectorValue to JSON::Value https://bugs.webkit.org/show_bug.cgi?id=179696 Reviewed by Timothy Hatcher. * inspector/scripts/codegen/generate_objc_header.py: (ObjCHeaderGenerator._generate_type_interface): * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py: (ObjCProtocolTypesImplementationGenerator.generate_type_implementation): (ObjCProtocolTypesImplementationGenerator._generate_init_method_for_protocol_object): (ObjCProtocolTypesImplementationGenerator._generate_init_method_for_json_object): Deleted. * inspector/scripts/codegen/objc_generator.py: (ObjCGenerator.protocol_type_for_raw_name): (ObjCGenerator.objc_protocol_export_expression_for_variable): (ObjCGenerator.objc_protocol_export_expression_for_variable.is): (ObjCGenerator.objc_protocol_import_expression_for_variable): (ObjCGenerator.objc_protocol_import_expression_for_variable.is): (ObjCGenerator.objc_to_protocol_expression_for_member.is): (ObjCGenerator.objc_to_protocol_expression_for_member): (ObjCGenerator.protocol_to_objc_expression_for_member.is): (ObjCGenerator.protocol_to_objc_expression_for_member): (ObjCGenerator.protocol_to_objc_code_block_for_object_member): (ObjCGenerator.objc_setter_method_for_member_internal): (ObjCGenerator.objc_getter_method_for_member_internal): * inspector/scripts/tests/all/expected/definitions-with-mac-platform.json-result: * inspector/scripts/tests/generic/expected/commands-with-async-attribute.json-result: * inspector/scripts/tests/generic/expected/commands-with-optional-call-return-parameters.json-result: * inspector/scripts/tests/generic/expected/events-with-optional-parameters.json-result: * inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result: * inspector/scripts/tests/generic/expected/shadowed-optional-type-setters.json-result: * inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result: * inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result: * inspector/scripts/tests/generic/expected/type-with-open-parameters.json-result: * inspector/scripts/tests/mac/expected/definitions-with-mac-platform.json-result: 2017-11-27 JF Bastien JavaScript rest function parameter with negative index leads to bad DFG abstract interpretation https://bugs.webkit.org/show_bug.cgi?id=180051 Reviewed by Saam Barati. Checking for int32 isn't sufficient when uint32 is expected afterwards. While we're here, also use Checked<>. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): 2017-11-14 Carlos Garcia Campos Move JSONValues to WTF and convert uses of InspectorValues.h to JSONValues.h https://bugs.webkit.org/show_bug.cgi?id=173793 Reviewed by Joseph Pecoraro. Based on patch by Brian Burg. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * bindings/ScriptValue.cpp: (Inspector::jsToInspectorValue): (Inspector::toInspectorValue): (Deprecated::ScriptValue::toInspectorValue const): * bindings/ScriptValue.h: * inspector/AsyncStackTrace.cpp: * inspector/ConsoleMessage.cpp: * inspector/ContentSearchUtilities.cpp: * inspector/DeprecatedInspectorValues.cpp: Added. * inspector/DeprecatedInspectorValues.h: Added. Keep the old symbols around in JavaScriptCore so that builds with the public iOS SDK continue to work. These older SDKs include a version of WebInspector.framework that expects to find InspectorArray and other symbols in JavaScriptCore.framework. * inspector/InjectedScript.cpp: (Inspector::InjectedScript::getFunctionDetails): (Inspector::InjectedScript::functionDetails): (Inspector::InjectedScript::getPreview): (Inspector::InjectedScript::getProperties): (Inspector::InjectedScript::getDisplayableProperties): (Inspector::InjectedScript::getInternalProperties): (Inspector::InjectedScript::getCollectionEntries): (Inspector::InjectedScript::saveResult): (Inspector::InjectedScript::wrapCallFrames const): (Inspector::InjectedScript::wrapObject const): (Inspector::InjectedScript::wrapTable const): (Inspector::InjectedScript::previewValue const): (Inspector::InjectedScript::setExceptionValue): (Inspector::InjectedScript::clearExceptionValue): (Inspector::InjectedScript::inspectObject): (Inspector::InjectedScript::releaseObject): * inspector/InjectedScriptBase.cpp: (Inspector::InjectedScriptBase::makeCall): (Inspector::InjectedScriptBase::makeEvalCall): * inspector/InjectedScriptBase.h: * inspector/InjectedScriptManager.cpp: (Inspector::InjectedScriptManager::injectedScriptForObjectId): * inspector/InspectorBackendDispatcher.cpp: (Inspector::BackendDispatcher::CallbackBase::sendSuccess): (Inspector::BackendDispatcher::dispatch): (Inspector::BackendDispatcher::sendResponse): (Inspector::BackendDispatcher::sendPendingErrors): (Inspector::BackendDispatcher::getPropertyValue): (Inspector::castToInteger): (Inspector::castToNumber): (Inspector::BackendDispatcher::getInteger): (Inspector::BackendDispatcher::getDouble): (Inspector::BackendDispatcher::getString): (Inspector::BackendDispatcher::getBoolean): (Inspector::BackendDispatcher::getObject): (Inspector::BackendDispatcher::getArray): (Inspector::BackendDispatcher::getValue): * inspector/InspectorBackendDispatcher.h: We need to keep around the sendResponse() variant with a parameter that has the InspectorObject type, as older WebInspector.framework versions expect this symbol to exist. Introduce a variant with arity 3 that can be used in TOT so as to avoid having two methods with the same name, arity, and different parameter types. When system WebInspector.framework is updated, we can remove the legacy method variant that uses the InspectorObject type. At that point, we can transition TOT to use the 2-arity variant, and delete the 3-arity variant when system WebInspector.framework is updated once more to use the 2-arity one. * inspector/InspectorProtocolTypes.h: (Inspector::Protocol::Array::openAccessors): (Inspector::Protocol::PrimitiveBindingTraits::assertValueHasExpectedType): (Inspector::Protocol::BindingTraits>::runtimeCast): (Inspector::Protocol::BindingTraits>::assertValueHasExpectedType): (Inspector::Protocol::BindingTraits::assertValueHasExpectedType): * inspector/ScriptCallFrame.cpp: * inspector/ScriptCallStack.cpp: * inspector/agents/InspectorAgent.cpp: (Inspector::InspectorAgent::inspect): * inspector/agents/InspectorAgent.h: * inspector/agents/InspectorDebuggerAgent.cpp: (Inspector::buildAssertPauseReason): (Inspector::buildCSPViolationPauseReason): (Inspector::InspectorDebuggerAgent::buildBreakpointPauseReason): (Inspector::InspectorDebuggerAgent::buildExceptionPauseReason): (Inspector::buildObjectForBreakpointCookie): (Inspector::InspectorDebuggerAgent::breakpointActionsFromProtocol): (Inspector::parseLocation): (Inspector::InspectorDebuggerAgent::setBreakpointByUrl): (Inspector::InspectorDebuggerAgent::setBreakpoint): (Inspector::InspectorDebuggerAgent::continueToLocation): (Inspector::InspectorDebuggerAgent::schedulePauseOnNextStatement): (Inspector::InspectorDebuggerAgent::didParseSource): (Inspector::InspectorDebuggerAgent::breakProgram): * inspector/agents/InspectorDebuggerAgent.h: * inspector/agents/InspectorRuntimeAgent.cpp: (Inspector::InspectorRuntimeAgent::callFunctionOn): (Inspector::InspectorRuntimeAgent::saveResult): (Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets): * inspector/agents/InspectorRuntimeAgent.h: * inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py: (CppBackendDispatcherHeaderGenerator._generate_dispatcher_declaration_for_command): * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py: (CppBackendDispatcherImplementationGenerator.generate_output): (CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command): * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_header.py: (CppFrontendDispatcherHeaderGenerator.generate_output): * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py: (CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_event): * inspector/scripts/codegen/generate_cpp_protocol_types_header.py: (_generate_unchecked_setter_for_member): * inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py: (CppProtocolTypesImplementationGenerator): * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py: (ObjCBackendDispatcherImplementationGenerator.generate_output): (ObjCBackendDispatcherImplementationGenerator._generate_success_block_for_command): * inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py: (ObjCFrontendDispatcherImplementationGenerator.generate_output): (ObjCFrontendDispatcherImplementationGenerator._generate_event): (ObjCFrontendDispatcherImplementationGenerator._generate_event_out_parameters): * inspector/scripts/codegen/generate_objc_internal_header.py: (ObjCInternalHeaderGenerator.generate_output): * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py: (ObjCProtocolTypesImplementationGenerator.generate_output): * inspector/scripts/codegen/generator.py: * inspector/scripts/tests/all/expected/definitions-with-mac-platform.json-result: * inspector/scripts/tests/generic/expected/commands-with-async-attribute.json-result: * inspector/scripts/tests/generic/expected/commands-with-optional-call-return-parameters.json-result: * inspector/scripts/tests/generic/expected/definitions-with-mac-platform.json-result: * inspector/scripts/tests/generic/expected/domain-availability.json-result: * inspector/scripts/tests/generic/expected/domains-with-varying-command-sizes.json-result: * inspector/scripts/tests/generic/expected/enum-values.json-result: * inspector/scripts/tests/generic/expected/events-with-optional-parameters.json-result: * inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result: * inspector/scripts/tests/generic/expected/same-type-id-different-domain.json-result: * inspector/scripts/tests/generic/expected/shadowed-optional-type-setters.json-result: * inspector/scripts/tests/generic/expected/type-declaration-aliased-primitive-type.json-result: * inspector/scripts/tests/generic/expected/type-declaration-array-type.json-result: * inspector/scripts/tests/generic/expected/type-declaration-enum-type.json-result: * inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result: * inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result: * inspector/scripts/tests/generic/expected/type-with-open-parameters.json-result: * inspector/scripts/tests/generic/expected/worker-supported-domains.json-result: * inspector/scripts/tests/ios/expected/definitions-with-mac-platform.json-result: * inspector/scripts/tests/mac/expected/definitions-with-mac-platform.json-result: 2017-11-28 Robin Morisset Support recursive tail call optimization for polymorphic calls https://bugs.webkit.org/show_bug.cgi?id=178390 Reviewed by Saam Barati. Comes with a large but fairly simple refactoring: the inlining path for varargs and non-varargs calls now converge a lot later, eliminating some redundant checks, and simplifying a few parts of the inlining pipeline. Also removes some dead code from inlineCall(): there was a special path for when m_continuationBlock is null, but it should never be (now checked with RELEASE_ASSERT). * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleCall): (JSC::DFG::ByteCodeParser::handleVarargsCall): (JSC::DFG::ByteCodeParser::handleRecursiveTailCall): (JSC::DFG::ByteCodeParser::inlineCall): (JSC::DFG::ByteCodeParser::handleCallVariant): (JSC::DFG::ByteCodeParser::handleVarargsInlining): (JSC::DFG::ByteCodeParser::getInliningBalance): (JSC::DFG::ByteCodeParser::handleInlining): (JSC::DFG::ByteCodeParser::attemptToInlineCall): Deleted. 2017-11-27 Saam Barati Spread can escape when CreateRest does not https://bugs.webkit.org/show_bug.cgi?id=180057 Reviewed by JF Bastien. We previously did not handle Spread(PhantomCreateRest) only because I did not think it was possible to generate this IR. I was wrong. We can generate such IR when we have a PutStack(Spread) but nothing escapes the CreateRest. This IR is rare to generate since we normally don't PutStack(Spread) because the SetLocal almost always gets eliminated because of how our bytecode generates op_spread. However, there exists a test case showing it is possible. Supporting this IR pattern in FTLLower is trivial. This patch implements it and rewrites the Validation rule for Spread. * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGValidate.cpp: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileSpread): * runtime/JSFixedArray.h: (JSC::JSFixedArray::tryCreate): 2017-11-27 Don Olmstead [CMake][Win] Conditionally select DLL CRT or static CRT https://bugs.webkit.org/show_bug.cgi?id=170594 Reviewed by Alex Christensen. * shell/PlatformWin.cmake: 2017-11-27 Saam Barati Having a bad time watchpoint firing during compilation revealed a racy assertion https://bugs.webkit.org/show_bug.cgi?id=180048 Reviewed by Mark Lam. While a DFG compilation is watching the having a bad time watchpoint, it was asserting that the rest parameter structure has indexing type ArrayWithContiguous. However, if the having a bad time watchpoint fires during the compilation, this particular structure will no longer have ArrayWithContiguous indexing type. This patch fixes this racy assertion to be aware that the watchpoint may fire during compilation. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCreateRest): (JSC::DFG::SpeculativeJIT::compileNewArrayWithSpread): 2017-11-27 Tim Horton One too many zeroes in macOS version number in FeatureDefines https://bugs.webkit.org/show_bug.cgi?id=180011 Reviewed by Dan Bernstein. * Configurations/FeatureDefines.xcconfig: 2017-11-27 Robin Morisset Update DFGSafeToExecute to be aware that ArrayPush is now a varargs node https://bugs.webkit.org/show_bug.cgi?id=179821 Reviewed by Saam Barati. * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): 2017-11-21 Yusuke Suzuki [DFG] Add NormalizeMapKey DFG IR https://bugs.webkit.org/show_bug.cgi?id=179912 Reviewed by Saam Barati. This patch introduces NormalizeMapKey DFG node. It executes what normalizeMapKey does in inlined manner. By separating this from MapHash and Map/Set related operations, we can perform CSE onto that, and we do not need to call normalizeMapKey conservatively in DFG operations. This can reduce slow path case in Untyped GetMapBucket since we can normalize keys in DFG/FTL. * 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): (JSC::DFG::FixupPhase::fixupNormalizeMapKey): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileNormalizeMapKey): * 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::compileMapHash): (JSC::FTL::DFG::LowerDFGToB3::compileNormalizeMapKey): (JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucket): * runtime/HashMapImpl.h: 2017-11-26 Yusuke Suzuki [FTL] Support DeleteById and DeleteByVal https://bugs.webkit.org/show_bug.cgi?id=180022 Reviewed by Saam Barati. We should increase the coverage of FTL. Even if the code includes DeleteById, it does not mean that remaining part of the code should not be optimized in FTL. Right now, even CallEval and `with` scope are handled in FTL. This patch just adds DeleteById and DeleteByVal handling to FTL to allow optimizing code including them. * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileDeleteById): (JSC::FTL::DFG::LowerDFGToB3::compileDeleteByVal): 2017-11-26 Yusuke Suzuki [DFG] Introduce {Set,Map,WeakMap}Fields https://bugs.webkit.org/show_bug.cgi?id=179925 Reviewed by Saam Barati. SetAdd and MapSet uses `write(MiscFields)`, but it is not correct. It accidentally writes readonly MiscFields which is used by various nodes and make optimization conservative. We introduce JSSetFields, JSMapFields, and JSWeakMapFields to precisely model clobberizing of Map, Set, and WeakMap. * dfg/DFGAbstractHeap.h: * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsicCall): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGHeapLocation.cpp: (WTF::printInternal): * dfg/DFGHeapLocation.h: * dfg/DFGNode.h: (JSC::DFG::Node::hasBucketOwnerType): 2017-11-26 Yusuke Suzuki [JSC] Remove JSStringBuilder https://bugs.webkit.org/show_bug.cgi?id=180016 Reviewed by Saam Barati. JSStringBuilder is replaced with WTF::StringBuilder. This patch removes remaning uses and drop JSStringBuilder. * JavaScriptCore.xcodeproj/project.pbxproj: * runtime/ArrayPrototype.cpp: * runtime/AsyncFunctionPrototype.cpp: * runtime/AsyncGeneratorFunctionPrototype.cpp: * runtime/ErrorPrototype.cpp: * runtime/FunctionPrototype.cpp: * runtime/GeneratorFunctionPrototype.cpp: * runtime/JSGlobalObjectFunctions.cpp: (JSC::decode): (JSC::globalFuncEscape): * runtime/JSStringBuilder.h: Removed. * runtime/JSStringInlines.h: (JSC::jsMakeNontrivialString): * runtime/RegExpPrototype.cpp: * runtime/StringPrototype.cpp: 2017-11-26 Yusuke Suzuki [DFG] Remove GetLocalUnlinked https://bugs.webkit.org/show_bug.cgi?id=180017 Reviewed by Saam Barati. Since DFGArgumentsSimplificationPhase is removed 2 years ago, GetLocalUnlinked is no longer used in DFG. This patch just removes it. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGCommon.h: * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGNode.h: (JSC::DFG::Node::hasUnlinkedLocal): (JSC::DFG::Node::convertToGetLocalUnlinked): Deleted. (JSC::DFG::Node::convertToGetLocal): Deleted. (JSC::DFG::Node::hasUnlinkedMachineLocal): Deleted. (JSC::DFG::Node::setUnlinkedMachineLocal): Deleted. (JSC::DFG::Node::unlinkedMachineLocal): Deleted. * 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): * dfg/DFGStackLayoutPhase.cpp: (JSC::DFG::StackLayoutPhase::run): * dfg/DFGValidate.cpp: 2017-11-26 Yusuke Suzuki Make ArgList::data() private again when we can remove callWasmFunction(). https://bugs.webkit.org/show_bug.cgi?id=168582 Reviewed by JF Bastien. Make ArgList::data() private since we already removed callWasmFunction. * runtime/ArgList.h: 2016-08-05 Darin Adler Fix some minor problems in the StringImpl header https://bugs.webkit.org/show_bug.cgi?id=160630 Reviewed by Brent Fulgham. * inspector/ContentSearchUtilities.cpp: Removed a lot of unneeded explicit Yarr namespacing since we use "using namespace" in this file. 2017-11-24 Mark Lam Fix CLoop::sanitizeStack() bug where it was clearing part of the JS stack in use. https://bugs.webkit.org/show_bug.cgi?id=179936 Reviewed by Saam Barati. This issue was uncovered when we enabled --useDollarVM=true on the JSC tests. See https://bugs.webkit.org/show_bug.cgi?id=179684. Basically, in the case of the failing test we observed, op_tail_call_forward_arguments was allocating stack space to stash arguments (to be forwarded) and new frame info. The location of this new stash space happens to lie beyond the top of frame of the tail call caller frame. After stashing the arguments, the code proceeded to load the callee codeBlock. This triggered an allocation, which in turn, triggered stack sanitization. The CLoop stack sanitizer was relying on frame->topOfFrame() to tell it where the top of the used stack is. In this case, that turned out to be inadequate. As a result, part of the stashed data was zeroed out, and subsequently led to a crash. This bug does not affect JIT builds (i.e. the ASM LLint) for 2 reasons: 1. JIT builds do stack sanitization in the LLInt code itself (different from the CLoop implementation), and the sanitizer there is aware of the true top of stack value (i.e. the stack pointer). 2. JIT builds don't use a parallel stack like the CLoop. The presence of the parallel stack is one condition necessary for reproducing this issue. The fix is to make the CLoop record the stack pointer in CLoopStack::m_currentStackPointer every time before it calls out to native C++ code. This also brings the CLoop's behavior closer to hardware behavior where we can know where the stack pointer is after calling from JS back into native C++ code, which makes it easier to reason about correctness. Also simplified the various stack boundary calculations (removed the +1 and -1 adjustments). The CLoopStack bounds are now: reservationTop(): the lowest reserved address that can be within stack bounds. m_commitTop: the lowest address within stack bounds that has been committed. lowAddress() aka m_end: the lowest stack address that JS code can use. m_lastStackPointer: cache of the last m_currentStackPointer value. m_currentStackPointer: the CLoopStack stack pointer value when calling from JS into C++ code. highAddress(): the highest address just beyond the bounds of the stack. Also deleted some unneeded code. * interpreter/CLoopStack.cpp: (JSC::CLoopStack::CLoopStack): (JSC::CLoopStack::gatherConservativeRoots): (JSC::CLoopStack::sanitizeStack): (JSC::CLoopStack::setSoftReservedZoneSize): * interpreter/CLoopStack.h: (JSC::CLoopStack::setCurrentStackPointer): (JSC::CLoopStack::lowAddress const): (JSC::CLoopStack::baseOfStack const): Deleted. - Not needed after we simplified the code and removed all the +1/-1 adjustments. Now, it has the exact same value as highAddress() and can be removed. * interpreter/CLoopStackInlines.h: (JSC::CLoopStack::ensureCapacityFor): (JSC::CLoopStack::currentStackPointer): (JSC::CLoopStack::setCLoopStackLimit): (JSC::CLoopStack::topOfFrameFor): Deleted. - Not needed. (JSC::CLoopStack::topOfStack): Deleted. - Supplanted by currentStackPointer(). (JSC::CLoopStack::shrink): Deleted. - This is unused. * llint/LowLevelInterpreter.cpp: (JSC::CLoop::execute): - Introduce a StackPointerScope to restore the original CLoopStack::m_currentStackPointer upon exitting the interpreter loop. * offlineasm/cloop.rb: - Added setting of CLoopStack::m_currentStackPointer at boundary points where we call from JS into C++ code. * tools/VMInspector.h: - Added some default argument values. These were being used while debugging this issue. 2017-11-24 Yusuke Suzuki [JSC] Make empty key as deleted mark in HashMapBucket and drop m_deleted field https://bugs.webkit.org/show_bug.cgi?id=179923 Reviewed by Darin Adler. We do not set empty as a key in HashMapBucket since JSMap / JSSet can expose it to users. So we can use it as a marker of deleted bucket. This patch uses empty key as a deleted flag, and drop m_deleted field of HashMapBucket. It shrinks the size of HashMapBucket much. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetMapBucketNext): * ftl/FTLAbstractHeapRepository.h: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucketNext): * runtime/HashMapImpl.h: (JSC::HashMapBucket::createSentinel): We make sentinel bucket as (undefined, undefined) since DFG/FTL can load a value from sentinels. While the sentinel's deleted flag becomes false since key is set, it is not a problem since deleted flag of sentinel bucket is not used. (JSC::HashMapBucket::HashMapBucket): (JSC::HashMapBucket::deleted const): (JSC::HashMapBucket::makeDeleted): (JSC::HashMapImpl::remove): (JSC::HashMapImpl::clear): (JSC::HashMapImpl::setUpHeadAndTail): (JSC::HashMapImpl::addNormalizedInternal): (JSC::HashMapBucket::setDeleted): Deleted. (JSC::HashMapBucket::offsetOfDeleted): Deleted. (): Deleted. 2017-11-24 Mark Lam Move unsafe jsc shell test functions to the $vm object. https://bugs.webkit.org/show_bug.cgi?id=179980 Reviewed by Yusuke Suzuki. Also removed setElementRoot() which was not used. * jsc.cpp: (GlobalObject::finishCreation): (WTF::Element::Element): Deleted. (WTF::Element::root const): Deleted. (WTF::Element::setRoot): Deleted. (WTF::Element::create): Deleted. (WTF::Element::visitChildren): Deleted. (WTF::Element::createStructure): Deleted. (WTF::Root::Root): Deleted. (WTF::Root::element): Deleted. (WTF::Root::setElement): Deleted. (WTF::Root::create): Deleted. (WTF::Root::createStructure): Deleted. (WTF::Root::visitChildren): Deleted. (WTF::ImpureGetter::ImpureGetter): Deleted. (WTF::ImpureGetter::createStructure): Deleted. (WTF::ImpureGetter::create): Deleted. (WTF::ImpureGetter::finishCreation): Deleted. (WTF::ImpureGetter::getOwnPropertySlot): Deleted. (WTF::ImpureGetter::visitChildren): Deleted. (WTF::ImpureGetter::setDelegate): Deleted. (WTF::CustomGetter::CustomGetter): Deleted. (WTF::CustomGetter::createStructure): Deleted. (WTF::CustomGetter::create): Deleted. (WTF::CustomGetter::getOwnPropertySlot): Deleted. (WTF::CustomGetter::customGetter): Deleted. (WTF::CustomGetter::customGetterAcessor): Deleted. (WTF::RuntimeArray::create): Deleted. (WTF::RuntimeArray::~RuntimeArray): Deleted. (WTF::RuntimeArray::destroy): Deleted. (WTF::RuntimeArray::getOwnPropertySlot): Deleted. (WTF::RuntimeArray::getOwnPropertySlotByIndex): Deleted. (WTF::RuntimeArray::put): Deleted. (WTF::RuntimeArray::deleteProperty): Deleted. (WTF::RuntimeArray::getLength const): Deleted. (WTF::RuntimeArray::createPrototype): Deleted. (WTF::RuntimeArray::createStructure): Deleted. (WTF::RuntimeArray::finishCreation): Deleted. (WTF::RuntimeArray::RuntimeArray): Deleted. (WTF::RuntimeArray::lengthGetter): Deleted. (WTF::SimpleObject::SimpleObject): Deleted. (WTF::SimpleObject::create): Deleted. (WTF::SimpleObject::visitChildren): Deleted. (WTF::SimpleObject::createStructure): Deleted. (WTF::SimpleObject::hiddenValue): Deleted. (WTF::SimpleObject::setHiddenValue): Deleted. (WTF::DOMJITNode::DOMJITNode): Deleted. (WTF::DOMJITNode::createStructure): Deleted. (WTF::DOMJITNode::checkSubClassSnippet): Deleted. (WTF::DOMJITNode::create): Deleted. (WTF::DOMJITNode::value const): Deleted. (WTF::DOMJITNode::offsetOfValue): Deleted. (WTF::DOMJITGetter::DOMJITGetter): Deleted. (WTF::DOMJITGetter::createStructure): Deleted. (WTF::DOMJITGetter::create): Deleted. (WTF::DOMJITGetter::DOMJITAttribute::DOMJITAttribute): Deleted. (WTF::DOMJITGetter::DOMJITAttribute::slowCall): Deleted. (WTF::DOMJITGetter::DOMJITAttribute::callDOMGetter): Deleted. (WTF::DOMJITGetter::customGetter): Deleted. (WTF::DOMJITGetter::finishCreation): Deleted. (WTF::DOMJITGetterComplex::DOMJITGetterComplex): Deleted. (WTF::DOMJITGetterComplex::createStructure): Deleted. (WTF::DOMJITGetterComplex::create): Deleted. (WTF::DOMJITGetterComplex::DOMJITAttribute::DOMJITAttribute): Deleted. (WTF::DOMJITGetterComplex::DOMJITAttribute::slowCall): Deleted. (WTF::DOMJITGetterComplex::DOMJITAttribute::callDOMGetter): Deleted. (WTF::DOMJITGetterComplex::functionEnableException): Deleted. (WTF::DOMJITGetterComplex::customGetter): Deleted. (WTF::DOMJITGetterComplex::finishCreation): Deleted. (WTF::DOMJITFunctionObject::DOMJITFunctionObject): Deleted. (WTF::DOMJITFunctionObject::createStructure): Deleted. (WTF::DOMJITFunctionObject::create): Deleted. (WTF::DOMJITFunctionObject::safeFunction): Deleted. (WTF::DOMJITFunctionObject::unsafeFunction): Deleted. (WTF::DOMJITFunctionObject::checkSubClassSnippet): Deleted. (WTF::DOMJITFunctionObject::finishCreation): Deleted. (WTF::DOMJITCheckSubClassObject::DOMJITCheckSubClassObject): Deleted. (WTF::DOMJITCheckSubClassObject::createStructure): Deleted. (WTF::DOMJITCheckSubClassObject::create): Deleted. (WTF::DOMJITCheckSubClassObject::safeFunction): Deleted. (WTF::DOMJITCheckSubClassObject::unsafeFunction): Deleted. (WTF::DOMJITCheckSubClassObject::finishCreation): Deleted. (WTF::DOMJITGetterBaseJSObject::DOMJITGetterBaseJSObject): Deleted. (WTF::DOMJITGetterBaseJSObject::createStructure): Deleted. (WTF::DOMJITGetterBaseJSObject::create): Deleted. (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::DOMJITAttribute): Deleted. (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::slowCall): Deleted. (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::callDOMGetter): Deleted. (WTF::DOMJITGetterBaseJSObject::customGetter): Deleted. (WTF::DOMJITGetterBaseJSObject::finishCreation): Deleted. (WTF::Element::handleOwner): Deleted. (WTF::Element::finishCreation): Deleted. (JSTestCustomGetterSetter::JSTestCustomGetterSetter): Deleted. (JSTestCustomGetterSetter::create): Deleted. (JSTestCustomGetterSetter::createStructure): Deleted. (customGetAccessor): Deleted. (customGetValue): Deleted. (customSetAccessor): Deleted. (customSetValue): Deleted. (JSTestCustomGetterSetter::finishCreation): Deleted. (GlobalObject::addConstructableFunction): Deleted. (functionCreateRoot): Deleted. (functionCreateElement): Deleted. (functionGetElement): Deleted. (functionSetElementRoot): Deleted. (functionCreateSimpleObject): Deleted. (functionGetHiddenValue): Deleted. (functionSetHiddenValue): Deleted. (functionCreateProxy): Deleted. (functionCreateRuntimeArray): Deleted. (functionCreateImpureGetter): Deleted. (functionCreateCustomGetterObject): Deleted. (functionCreateDOMJITNodeObject): Deleted. (functionCreateDOMJITGetterObject): Deleted. (functionCreateDOMJITGetterComplexObject): Deleted. (functionCreateDOMJITFunctionObject): Deleted. (functionCreateDOMJITCheckSubClassObject): Deleted. (functionCreateDOMJITGetterBaseJSObject): Deleted. (functionSetImpureGetterDelegate): Deleted. (functionGetGetterSetter): Deleted. (functionShadowChickenFunctionsOnStack): Deleted. (functionSetGlobalConstRedeclarationShouldNotThrow): Deleted. (functionGlobalObjectForObject): Deleted. (functionLoadGetterFromGetterSetter): Deleted. (functionCreateCustomTestGetterSetter): Deleted. (functionAbort): Deleted. (functionFindTypeForExpression): Deleted. (functionReturnTypeFor): Deleted. (functionDumpBasicBlockExecutionRanges): Deleted. (functionHasBasicBlockExecuted): Deleted. (functionBasicBlockExecutionCount): Deleted. (functionEnableExceptionFuzz): Deleted. (functionCreateBuiltin): Deleted. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * tools/JSDollarVM.cpp: (WTF::Element::Element): (WTF::Element::root const): (WTF::Element::setRoot): (WTF::Element::create): (WTF::Element::visitChildren): (WTF::Element::createStructure): (WTF::Root::Root): (WTF::Root::element): (WTF::Root::setElement): (WTF::Root::create): (WTF::Root::createStructure): (WTF::Root::visitChildren): (WTF::SimpleObject::SimpleObject): (WTF::SimpleObject::create): (WTF::SimpleObject::visitChildren): (WTF::SimpleObject::createStructure): (WTF::SimpleObject::hiddenValue): (WTF::SimpleObject::setHiddenValue): (WTF::ImpureGetter::ImpureGetter): (WTF::ImpureGetter::createStructure): (WTF::ImpureGetter::create): (WTF::ImpureGetter::finishCreation): (WTF::ImpureGetter::getOwnPropertySlot): (WTF::ImpureGetter::visitChildren): (WTF::ImpureGetter::setDelegate): (WTF::CustomGetter::CustomGetter): (WTF::CustomGetter::createStructure): (WTF::CustomGetter::create): (WTF::CustomGetter::getOwnPropertySlot): (WTF::CustomGetter::customGetter): (WTF::CustomGetter::customGetterAcessor): (WTF::RuntimeArray::create): (WTF::RuntimeArray::~RuntimeArray): (WTF::RuntimeArray::destroy): (WTF::RuntimeArray::getOwnPropertySlot): (WTF::RuntimeArray::getOwnPropertySlotByIndex): (WTF::RuntimeArray::put): (WTF::RuntimeArray::deleteProperty): (WTF::RuntimeArray::getLength const): (WTF::RuntimeArray::createPrototype): (WTF::RuntimeArray::createStructure): (WTF::RuntimeArray::finishCreation): (WTF::RuntimeArray::RuntimeArray): (WTF::RuntimeArray::lengthGetter): (WTF::DOMJITNode::DOMJITNode): (WTF::DOMJITNode::createStructure): (WTF::DOMJITNode::checkSubClassSnippet): (WTF::DOMJITNode::create): (WTF::DOMJITNode::value const): (WTF::DOMJITNode::offsetOfValue): (WTF::DOMJITGetter::DOMJITGetter): (WTF::DOMJITGetter::createStructure): (WTF::DOMJITGetter::create): (WTF::DOMJITGetter::DOMJITAttribute::DOMJITAttribute): (WTF::DOMJITGetter::DOMJITAttribute::slowCall): (WTF::DOMJITGetter::DOMJITAttribute::callDOMGetter): (WTF::DOMJITGetter::customGetter): (WTF::DOMJITGetter::finishCreation): (WTF::DOMJITGetterComplex::DOMJITGetterComplex): (WTF::DOMJITGetterComplex::createStructure): (WTF::DOMJITGetterComplex::create): (WTF::DOMJITGetterComplex::DOMJITAttribute::DOMJITAttribute): (WTF::DOMJITGetterComplex::DOMJITAttribute::slowCall): (WTF::DOMJITGetterComplex::DOMJITAttribute::callDOMGetter): (WTF::DOMJITGetterComplex::functionEnableException): (WTF::DOMJITGetterComplex::customGetter): (WTF::DOMJITGetterComplex::finishCreation): (WTF::DOMJITFunctionObject::DOMJITFunctionObject): (WTF::DOMJITFunctionObject::createStructure): (WTF::DOMJITFunctionObject::create): (WTF::DOMJITFunctionObject::safeFunction): (WTF::DOMJITFunctionObject::unsafeFunction): (WTF::DOMJITFunctionObject::checkSubClassSnippet): (WTF::DOMJITFunctionObject::finishCreation): (WTF::DOMJITCheckSubClassObject::DOMJITCheckSubClassObject): (WTF::DOMJITCheckSubClassObject::createStructure): (WTF::DOMJITCheckSubClassObject::create): (WTF::DOMJITCheckSubClassObject::safeFunction): (WTF::DOMJITCheckSubClassObject::unsafeFunction): (WTF::DOMJITCheckSubClassObject::finishCreation): (WTF::DOMJITGetterBaseJSObject::DOMJITGetterBaseJSObject): (WTF::DOMJITGetterBaseJSObject::createStructure): (WTF::DOMJITGetterBaseJSObject::create): (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::DOMJITAttribute): (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::slowCall): (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::callDOMGetter): (WTF::DOMJITGetterBaseJSObject::customGetter): (WTF::DOMJITGetterBaseJSObject::finishCreation): (WTF::Message::releaseContents): (WTF::Message::index const): (WTF::JSTestCustomGetterSetter::JSTestCustomGetterSetter): (WTF::JSTestCustomGetterSetter::create): (WTF::JSTestCustomGetterSetter::createStructure): (WTF::customGetAccessor): (WTF::customGetValue): (WTF::customSetAccessor): (WTF::customSetValue): (WTF::JSTestCustomGetterSetter::finishCreation): (WTF::Element::handleOwner): (WTF::Element::finishCreation): (JSC::functionCrash): (JSC::functionCreateProxy): (JSC::functionCreateRuntimeArray): (JSC::functionCreateImpureGetter): (JSC::functionCreateCustomGetterObject): (JSC::functionCreateDOMJITNodeObject): (JSC::functionCreateDOMJITGetterObject): (JSC::functionCreateDOMJITGetterComplexObject): (JSC::functionCreateDOMJITFunctionObject): (JSC::functionCreateDOMJITCheckSubClassObject): (JSC::functionCreateDOMJITGetterBaseJSObject): (JSC::functionSetImpureGetterDelegate): (JSC::functionCreateBuiltin): (JSC::functionCreateRoot): (JSC::functionCreateElement): (JSC::functionGetElement): (JSC::functionCreateSimpleObject): (JSC::functionGetHiddenValue): (JSC::functionSetHiddenValue): (JSC::functionShadowChickenFunctionsOnStack): (JSC::functionSetGlobalConstRedeclarationShouldNotThrow): (JSC::functionFindTypeForExpression): (JSC::functionReturnTypeFor): (JSC::functionDumpBasicBlockExecutionRanges): (JSC::functionHasBasicBlockExecuted): (JSC::functionBasicBlockExecutionCount): (JSC::functionEnableExceptionFuzz): (JSC::functionGlobalObjectForObject): (JSC::functionGetGetterSetter): (JSC::functionLoadGetterFromGetterSetter): (JSC::functionCreateCustomTestGetterSetter): (JSC::JSDollarVM::finishCreation): (JSC::JSDollarVM::addFunction): (JSC::JSDollarVM::addConstructibleFunction): * tools/JSDollarVM.h: (JSC::JSDollarVM::create): 2017-11-23 Simon Fraser Minor ArrayBufferView cleanup https://bugs.webkit.org/show_bug.cgi?id=179966 Reviewed by Darin Adler. Use void* for data pointers when we don't need to do offset math. Use const for source pointers. Prefer uint8_t* to char*. Add comments noting that the assertions should not be made release assertions as recommended by the style checker, since the point is to avoid the virtual byteLength() call in release. * runtime/ArrayBufferView.h: (JSC::ArrayBufferView::setImpl): (JSC::ArrayBufferView::setRangeImpl): (JSC::ArrayBufferView::getRangeImpl): (JSC::ArrayBufferView::zeroRangeImpl): 2017-11-23 Darin Adler Reduce WTF::String operations that do unnecessary Unicode operations instead of ASCII https://bugs.webkit.org/show_bug.cgi?id=179907 Reviewed by Sam Weinig. * inspector/agents/InspectorDebuggerAgent.cpp: (Inspector::matches): Removed explicit TextCaseSensitive because RegularExpression now defaults to that. * runtime/StringPrototype.cpp: (JSC::stringIncludesImpl): Use String::find since there is no overload of String::contains that takes a start offset now that we removed the one that took a caseSensitive boolean. We can add one later if we like, but this should do for now. * yarr/RegularExpression.h: Moved the TextCaseSensitivity enumeration here from the StringImpl.h header because it is only used here. 2017-11-22 Simon Fraser Followup after r225084: if anyone called GenericTypedArrayView() it didn't compile, because of a getRangeUnchecked/getRangeImpl name mismatch; fixed to use getRangeImpl(). Also name the argument to zeroRange() to 'count' since it's an item count. * runtime/GenericTypedArrayView.h: (JSC::GenericTypedArrayView::zeroRange): (JSC::GenericTypedArrayView::getRange): 2017-11-21 Simon Fraser Allow for more efficient use of GenericTypedArrayView https://bugs.webkit.org/show_bug.cgi?id=179899 Reviewed by Sam Weinig. Fix ArrayBufferView::setRange() to not make two virtual function calls to byteLength() under setRangeImpl(). There is only one caller in GenericTypedArrayView, and it can pass in a length. Add GenericTypedArrayView::getRange() to fetch a range of elements, also without virtual byteLength() calls. Renamed 'dataLength' to 'count' in setRange() to be clearer. Added setNative() for callers who don't need clamping of doubles. * runtime/ArrayBufferView.h: (JSC::ArrayBufferView::setRangeImpl): (JSC::ArrayBufferView::getRangeImpl): * runtime/GenericTypedArrayView.h: (JSC::GenericTypedArrayView::setRange): (JSC::GenericTypedArrayView::setNative const): (JSC::GenericTypedArrayView::getRange): (JSC::GenericTypedArrayView::checkInboundData const): (JSC::GenericTypedArrayView::internalByteLength const): 2017-11-21 Yusuke Suzuki [DFG][FTL] Support MapSet / SetAdd intrinsics https://bugs.webkit.org/show_bug.cgi?id=179858 Reviewed by Saam Barati. Map.prototype.set and Set.prototype.add uses MapHash value anyway. By handling them as MapSet and SetAdd DFG nodes and decoupling MapSet and SetAdd nodes from MapHash DFG node, we have a chance to remove duplicate MapHash calculation for the same key. One story is *set-if-not-exists*. if (!map.has(key)) map.set(key, value); In the above code, both `has` and `set` require hash value for `key`. If we can change `set` to the series of DFG nodes: 1: MapHash(key) 2: MapSet(MapObjectUse:map, Untyped:key, Untyped:value, Int32Use:@1) we can remove duplicate @1 produced by `has` operation. This patch improves SixSpeed map-set.es6 and map-set-object.es6 by 20.5% and 20.4% respectively, baseline patched map-set.es6 246.2413+-15.2084 ^ 204.3679+-11.2408 ^ definitely 1.2049x faster map-set-object.es6 266.5075+-17.2289 ^ 221.2792+-12.2948 ^ definitely 1.2044x faster Microbenchmarks map-has-and-set 148.1522+-7.6665 ^ 131.4552+-7.8846 ^ definitely 1.1270x 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::compileSetAdd): (JSC::DFG::SpeculativeJIT::compileMapSet): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * 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::compileSetAdd): (JSC::FTL::DFG::LowerDFGToB3::compileMapSet): * jit/JITOperations.h: * runtime/HashMapImpl.h: (JSC::HashMapImpl::addNormalized): (JSC::HashMapImpl::addNormalizedInternal): * runtime/Intrinsic.cpp: (JSC::intrinsicName): * runtime/Intrinsic.h: * runtime/MapPrototype.cpp: (JSC::MapPrototype::finishCreation): * runtime/SetPrototype.cpp: (JSC::SetPrototype::finishCreation): 2017-11-21 Yusuke Suzuki [JSC] Allow poly proto for intrinsic getters https://bugs.webkit.org/show_bug.cgi?id=179550 Reviewed by Saam Barati. This patch allows intrinsic getters to accept poly proto. We propagate PolyProtoAccessChain in IntrinsicGetterAccessCase to perform poly proto checks. And we extend UnderscoreProtoIntrinsic to emit code for poly proto case. * bytecode/IntrinsicGetterAccessCase.cpp: (JSC::IntrinsicGetterAccessCase::IntrinsicGetterAccessCase): (JSC::IntrinsicGetterAccessCase::create): * bytecode/IntrinsicGetterAccessCase.h: * jit/IntrinsicEmitter.cpp: (JSC::IntrinsicGetterAccessCase::canEmitIntrinsicGetter): (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter): * jit/Repatch.cpp: (JSC::tryCacheGetByID): 2017-11-20 Don Olmstead Detect __declspec within JSBase.h https://bugs.webkit.org/show_bug.cgi?id=179892 Reviewed by Darin Adler. * API/JSBase.h: 2017-11-19 Tim Horton Remove unused TOUCH_ICON_LOADING feature flag https://bugs.webkit.org/show_bug.cgi?id=179873 Reviewed by Simon Fraser. * Configurations/FeatureDefines.xcconfig: 2017-11-19 Yusuke Suzuki Add CPU(UNKNOWN) to cover all the unknown CPU types https://bugs.webkit.org/show_bug.cgi?id=179243 Reviewed by JF Bastien. * CMakeLists.txt: 2017-11-19 Tim Horton Remove unused LEGACY_VENDOR_PREFIXES feature flag https://bugs.webkit.org/show_bug.cgi?id=179872 Reviewed by Darin Adler. * Configurations/FeatureDefines.xcconfig: 2017-11-18 Tim Horton Fix typos in closing ENABLE() comments https://bugs.webkit.org/show_bug.cgi?id=179869 Unreviewed. * wasm/WasmMemory.h: * wasm/WasmMemoryMode.h: 2017-11-17 JF Bastien NFC update ClassInfo to C++14 https://bugs.webkit.org/show_bug.cgi?id=179783 Reviewed by Mark Lam. Forked from #179734, use `using` instead of `typedef`. It's easier to read. * runtime/ClassInfo.h: 2017-11-17 JF Bastien WebAssembly JS API: throw when a promise can't be created https://bugs.webkit.org/show_bug.cgi?id=179826 Reviewed by Mark Lam. Failure *in* a promise causes rejection, but failure to create a promise (because of stack overflow) isn't really spec'd (as all stack things JS). This applies to WebAssembly.compile and WebAssembly.instantiate. Dan's current proposal says: https://littledan.github.io/spec/document/js-api/index.html#stack-overflow Whenever a stack overflow occurs in WebAssembly code, the same class of exception is thrown as for a stack overflow in JavaScript. The particular exception here is implementation-defined in both cases. Note: ECMAScript doesn’t specify any sort of behavior on stack overflow; implementations have been observed to throw RangeError, InternalError or Error. Any is valid here. This is for general stack overflow within WebAssembly, not specifically for promise creation within JavaScript, but it seems like a stack overflow in promise creation should follow the same rule instead of, say, swallowing the overflow and returning undefined. * wasm/js/WebAssemblyPrototype.cpp: (JSC::webAssemblyCompileFunc): (JSC::webAssemblyInstantiateFunc): 2017-11-16 Daniel Bates Add feature define for alternative presentation button element https://bugs.webkit.org/show_bug.cgi?id=179692 Part of Reviewed by Andy Estes. Only enabled on Cocoa platforms by default. * Configurations/FeatureDefines.xcconfig: 2017-11-16 Saam Barati Fix a bug with cpuid in the FTL. Rubber stamped by Mark Lam. Before uploading the previous patch, I tried to condense the code. I accidentally removed a crucial line saying that CPUID clobbers various registers. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCPUIntrinsic): 2017-11-16 Saam Barati Add some X86 intrinsics to $vm to help with some perf testing https://bugs.webkit.org/show_bug.cgi?id=179693 Reviewed by Mark Lam. I've been doing some local perf testing of various ideas and have had these come in handy. I'm going to land them to dollarVM to prevent having to add them to my local build every time I do perf testing. * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::mfence): (JSC::MacroAssemblerX86Common::rdtsc): (JSC::MacroAssemblerX86Common::pause): (JSC::MacroAssemblerX86Common::cpuid): * assembler/X86Assembler.h: (JSC::X86Assembler::rdtsc): (JSC::X86Assembler::pause): (JSC::X86Assembler::cpuid): * 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/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGNode.h: (JSC::DFG::Node::intrinsic): * 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): * dfg/DFGValidate.cpp: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileCPUIntrinsic): * runtime/Intrinsic.cpp: (JSC::intrinsicName): * runtime/Intrinsic.h: * tools/JSDollarVM.cpp: (JSC::functionCpuMfence): (JSC::functionCpuRdtsc): (JSC::functionCpuCpuid): (JSC::functionCpuPause): (JSC::functionCpuClflush): (JSC::JSDollarVM::finishCreation): 2017-11-16 JF Bastien It should be easier to reify lazy property names https://bugs.webkit.org/show_bug.cgi?id=179734 Reviewed by Keith Miller. We reify lazy property names in a few different ways, each specific to the JSCell implementation, in put() instead of having a special function to do reification. Let's make that simpler. This patch makes it easier to reify property names in a uniform manner, and does so in JSFunction. As a follow up I'll use the same mechanics for: ClonedArguments callee, iteratorSymbol (Symbol.iterator) ErrorConstructor stackTraceLimit ErrorInstance line, column, sourceURL, stack GenericArguments length, callee, iteratorSymbol (Symbol.iterator) GetterSetter RELEASE_ASSERT_NOT_REACHED() JSArray length RegExpObject lastIndex StringObject length * runtime/ClassInfo.h: Add reifyPropertyNameIfNeeded to method table. * runtime/JSCell.cpp: (JSC::JSCell::reifyPropertyNameIfNeeded): by default, don't reify. * runtime/JSCell.h: * runtime/JSFunction.cpp: `name` and `length` can be reified. (JSC::JSFunction::reifyPropertyNameIfNeeded): (JSC::JSFunction::put): (JSC::JSFunction::reifyLength): (JSC::JSFunction::reifyName): (JSC::JSFunction::reifyLazyPropertyIfNeeded): (JSC::JSFunction::reifyLazyPropertyForHostOrBuiltinIfNeeded): (JSC::JSFunction::reifyLazyLengthIfNeeded): (JSC::JSFunction::reifyLazyNameIfNeeded): (JSC::JSFunction::reifyLazyBoundNameIfNeeded): * runtime/JSFunction.h: (JSC::JSFunction::isLazy): (JSC::JSFunction::isReified): * runtime/JSObjectInlines.h: (JSC::JSObject::putDirectInternal): do the reification here. 2017-11-16 Robin Morisset Provide a runtime option for disabling the optimization of recursive tail calls https://bugs.webkit.org/show_bug.cgi?id=179765 Reviewed by Mark Lam. * bytecode/PreciseJumpTargets.cpp: (JSC::getJumpTargetsForBytecodeOffset): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitEnter): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleRecursiveTailCall): * runtime/Options.h: 2017-11-16 Robin Morisset Fix null pointer dereference in bytecodeDumper https://bugs.webkit.org/show_bug.cgi?id=179764 Reviewed by Mark Lam. The problem was just a call to lastSeenCallee() that was unguarded by haveLastSeenCallee(). * bytecode/BytecodeDumper.cpp: (JSC::BytecodeDumper::printCallOp): 2017-11-16 Robin Morisset REGRESSION (r224592): oss-fuzz: jsc: Null-dereference READ in JSC::JSCell::isObject (4216) https://bugs.webkit.org/show_bug.cgi?id=179763 Reviewed by Keith Miller. Fix null pointer dereference caused by an eliminated tdz_check The problem was when doing an OSR entry in DFG while |this| was null (because super() had not yet been called in the constructor of this subclass), it would be marked as non-null, and the tdz_check eliminated. * dfg/DFGInPlaceAbstractState.cpp: (JSC::DFG::InPlaceAbstractState::initialize): 2017-11-15 Ryan Haddad Unreviewed, rolling out r224863. Introduced LayoutTest crashes on iOS Simulator. Reverted changeset: "Move JSONValues to WTF and convert uses of InspectorValues.h to JSONValues.h" https://bugs.webkit.org/show_bug.cgi?id=173793 https://trac.webkit.org/changeset/224863 2017-11-14 Mark Lam Gardening: CLoop build fix after r224862. https://bugs.webkit.org/show_bug.cgi?id=179699 Not reviewed.. * bytecode/CodeBlock.h: (JSC::CodeBlock::calleeSaveSpaceAsVirtualRegisters): 2017-11-14 Carlos Garcia Campos Move JSONValues to WTF and convert uses of InspectorValues.h to JSONValues.h https://bugs.webkit.org/show_bug.cgi?id=173793 Reviewed by Brian Burg. Based on patch by Brian Burg. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * bindings/ScriptValue.cpp: (Inspector::jsToInspectorValue): (Inspector::toInspectorValue): (Deprecated::ScriptValue::toInspectorValue const): * bindings/ScriptValue.h: * inspector/AsyncStackTrace.cpp: * inspector/ConsoleMessage.cpp: * inspector/ContentSearchUtilities.cpp: * inspector/InjectedScript.cpp: (Inspector::InjectedScript::getFunctionDetails): (Inspector::InjectedScript::functionDetails): (Inspector::InjectedScript::getPreview): (Inspector::InjectedScript::getProperties): (Inspector::InjectedScript::getDisplayableProperties): (Inspector::InjectedScript::getInternalProperties): (Inspector::InjectedScript::getCollectionEntries): (Inspector::InjectedScript::saveResult): (Inspector::InjectedScript::wrapCallFrames const): (Inspector::InjectedScript::wrapObject const): (Inspector::InjectedScript::wrapTable const): (Inspector::InjectedScript::previewValue const): (Inspector::InjectedScript::setExceptionValue): (Inspector::InjectedScript::clearExceptionValue): (Inspector::InjectedScript::inspectObject): (Inspector::InjectedScript::releaseObject): * inspector/InjectedScriptBase.cpp: (Inspector::InjectedScriptBase::makeCall): (Inspector::InjectedScriptBase::makeEvalCall): * inspector/InjectedScriptBase.h: * inspector/InjectedScriptManager.cpp: (Inspector::InjectedScriptManager::injectedScriptForObjectId): * inspector/InspectorBackendDispatcher.cpp: (Inspector::BackendDispatcher::CallbackBase::sendSuccess): (Inspector::BackendDispatcher::dispatch): (Inspector::BackendDispatcher::sendResponse): (Inspector::BackendDispatcher::sendPendingErrors): (Inspector::BackendDispatcher::getPropertyValue): (Inspector::castToInteger): (Inspector::castToNumber): (Inspector::BackendDispatcher::getInteger): (Inspector::BackendDispatcher::getDouble): (Inspector::BackendDispatcher::getString): (Inspector::BackendDispatcher::getBoolean): (Inspector::BackendDispatcher::getObject): (Inspector::BackendDispatcher::getArray): (Inspector::BackendDispatcher::getValue): * inspector/InspectorBackendDispatcher.h: * inspector/InspectorProtocolTypes.h: (Inspector::Protocol::Array::openAccessors): (Inspector::Protocol::PrimitiveBindingTraits::assertValueHasExpectedType): (Inspector::Protocol::BindingTraits>::runtimeCast): (Inspector::Protocol::BindingTraits>::assertValueHasExpectedType): (Inspector::Protocol::BindingTraits::assertValueHasExpectedType): * inspector/ScriptCallFrame.cpp: * inspector/ScriptCallStack.cpp: * inspector/agents/InspectorAgent.cpp: (Inspector::InspectorAgent::inspect): * inspector/agents/InspectorAgent.h: * inspector/agents/InspectorDebuggerAgent.cpp: (Inspector::buildAssertPauseReason): (Inspector::buildCSPViolationPauseReason): (Inspector::InspectorDebuggerAgent::buildBreakpointPauseReason): (Inspector::InspectorDebuggerAgent::buildExceptionPauseReason): (Inspector::buildObjectForBreakpointCookie): (Inspector::InspectorDebuggerAgent::breakpointActionsFromProtocol): (Inspector::parseLocation): (Inspector::InspectorDebuggerAgent::setBreakpointByUrl): (Inspector::InspectorDebuggerAgent::setBreakpoint): (Inspector::InspectorDebuggerAgent::continueToLocation): (Inspector::InspectorDebuggerAgent::schedulePauseOnNextStatement): (Inspector::InspectorDebuggerAgent::didParseSource): (Inspector::InspectorDebuggerAgent::breakProgram): * inspector/agents/InspectorDebuggerAgent.h: * inspector/agents/InspectorRuntimeAgent.cpp: (Inspector::InspectorRuntimeAgent::callFunctionOn): (Inspector::InspectorRuntimeAgent::saveResult): (Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets): * inspector/agents/InspectorRuntimeAgent.h: * inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py: (CppBackendDispatcherHeaderGenerator._generate_dispatcher_declaration_for_command): * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py: (CppBackendDispatcherImplementationGenerator.generate_output): (CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command): * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_header.py: (CppFrontendDispatcherHeaderGenerator.generate_output): * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py: (CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_event): * inspector/scripts/codegen/generate_cpp_protocol_types_header.py: (_generate_unchecked_setter_for_member): * inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py: (CppProtocolTypesImplementationGenerator): * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py: (ObjCBackendDispatcherImplementationGenerator.generate_output): (ObjCBackendDispatcherImplementationGenerator._generate_success_block_for_command): * inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py: (ObjCFrontendDispatcherImplementationGenerator.generate_output): (ObjCFrontendDispatcherImplementationGenerator._generate_event): (ObjCFrontendDispatcherImplementationGenerator._generate_event_out_parameters): * inspector/scripts/codegen/generate_objc_internal_header.py: (ObjCInternalHeaderGenerator.generate_output): * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py: (ObjCProtocolTypesImplementationGenerator.generate_output): * inspector/scripts/codegen/generator.py: * inspector/scripts/tests/all/expected/definitions-with-mac-platform.json-result: * inspector/scripts/tests/generic/expected/commands-with-async-attribute.json-result: * inspector/scripts/tests/generic/expected/commands-with-optional-call-return-parameters.json-result: * inspector/scripts/tests/generic/expected/definitions-with-mac-platform.json-result: * inspector/scripts/tests/generic/expected/domain-availability.json-result: * inspector/scripts/tests/generic/expected/domains-with-varying-command-sizes.json-result: * inspector/scripts/tests/generic/expected/enum-values.json-result: * inspector/scripts/tests/generic/expected/events-with-optional-parameters.json-result: * inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result: * inspector/scripts/tests/generic/expected/same-type-id-different-domain.json-result: * inspector/scripts/tests/generic/expected/shadowed-optional-type-setters.json-result: * inspector/scripts/tests/generic/expected/type-declaration-aliased-primitive-type.json-result: * inspector/scripts/tests/generic/expected/type-declaration-array-type.json-result: * inspector/scripts/tests/generic/expected/type-declaration-enum-type.json-result: * inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result: * inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result: * inspector/scripts/tests/generic/expected/type-with-open-parameters.json-result: * inspector/scripts/tests/generic/expected/worker-supported-domains.json-result: * inspector/scripts/tests/ios/expected/definitions-with-mac-platform.json-result: * inspector/scripts/tests/mac/expected/definitions-with-mac-platform.json-result: 2017-11-14 Mark Lam Fix a bit-rotted Interpreter::dumpRegisters() and make it more robust. https://bugs.webkit.org/show_bug.cgi?id=179699 Reviewed by Michael Saboff. * interpreter/Interpreter.cpp: (JSC::Interpreter::dumpRegisters): - Need to skip the callee saved registers 2017-11-14 Guillaume Emont REGRESSION(r224623) [MIPS] branchTruncateDoubleToInt32() doesn't set return register when branching https://bugs.webkit.org/show_bug.cgi?id=179563 Reviewed by Carlos Alberto Lopez Perez. When run with BranchIfTruncateSuccessful, branchTruncateDoubleToInt32() should set the destination register before branching. This change also removes branchTruncateDoubleToUInt32() as it is deprecated (see r160205), merges branchOnTruncateResult() into branchTruncateDoubleToInt32() and adds test cases in testmasm. * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::branchOnTruncateResult): Deleted. (JSC::MacroAssemblerMIPS::branchTruncateDoubleToInt32): Properly set dest before branching. (JSC::MacroAssemblerMIPS::branchTruncateDoubleToUInt32): Deleted. * assembler/testmasm.cpp: (JSC::testBranchTruncateDoubleToInt32): (JSC::run): Add tests for branchTruncateDoubleToInt32(). 2017-11-14 Daniel Bates Update comment in FeatureDefines.xcconfig to reflect location of Visual Studio property files for feature defines Following r195498 and r201917 the Visual Studio property files for feature defines have moved from directory WebKitLibraries/win/tools/vsprops to directory Source/cmake/tools/vsprops. Update the comment in FeatureDefines.xcconfig to reflect the new location and names of these files. * Configurations/FeatureDefines.xcconfig: 2017-11-14 Mark Lam Remove JSDollarVMPrototype. https://bugs.webkit.org/show_bug.cgi?id=179685 Reviewed by Saam Barati. 1. Move the JSDollarVMPrototype C++ utility functions into VMInspector.cpp. This allows us to call these functions during lldb debugging sessions using VMInspector::foo() instead of JSDollarVMPrototype::foo(). It makes sense that VMInspector provides VM debugging utility methods. It doesn't make sense to have a JSDollarVMPrototype object provide these methods. Plus, it's shorter to type VMInspector than JSDollarVMPrototype. 2. Move the JSDollarVMPrototype JS functions into JSDollarVM.cpp. JSDollarVM is a special object used only for debugging purposes. There's no gain in requiring its methods to be stored in a prototype object other than to conform to typical JS convention. We can remove this complexity. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * tools/JSDollarVM.cpp: (JSC::JSDollarVM::addFunction): (JSC::functionCrash): (JSC::functionDFGTrue): (JSC::CallerFrameJITTypeFunctor::CallerFrameJITTypeFunctor): (JSC::CallerFrameJITTypeFunctor::operator() const): (JSC::CallerFrameJITTypeFunctor::jitType): (JSC::functionLLintTrue): (JSC::functionJITTrue): (JSC::functionGC): (JSC::functionEdenGC): (JSC::functionCodeBlockForFrame): (JSC::codeBlockFromArg): (JSC::functionCodeBlockFor): (JSC::functionPrintSourceFor): (JSC::functionPrintBytecodeFor): (JSC::functionPrint): (JSC::functionPrintCallFrame): (JSC::functionPrintStack): (JSC::functionValue): (JSC::functionGetPID): (JSC::JSDollarVM::finishCreation): * tools/JSDollarVM.h: (JSC::JSDollarVM::create): * tools/JSDollarVMPrototype.cpp: Removed. * tools/JSDollarVMPrototype.h: Removed. * tools/VMInspector.cpp: (JSC::VMInspector::currentThreadOwnsJSLock): (JSC::ensureCurrentThreadOwnsJSLock): (JSC::VMInspector::gc): (JSC::VMInspector::edenGC): (JSC::VMInspector::isInHeap): (JSC::CellAddressCheckFunctor::CellAddressCheckFunctor): (JSC::CellAddressCheckFunctor::operator() const): (JSC::VMInspector::isValidCell): (JSC::VMInspector::isValidCodeBlock): (JSC::VMInspector::codeBlockForFrame): (JSC::PrintFrameFunctor::PrintFrameFunctor): (JSC::PrintFrameFunctor::operator() const): (JSC::VMInspector::printCallFrame): (JSC::VMInspector::printStack): (JSC::VMInspector::printValue): * tools/VMInspector.h: 2017-11-14 Joseph Pecoraro Web Inspector: Add a ServiceWorker domain to get information about an inspected ServiceWorker https://bugs.webkit.org/show_bug.cgi?id=179640 Reviewed by Devin Rousso. * CMakeLists.txt: * DerivedSources.make: Gate the ServiceWorker domain on the ENABLE feature flag. * inspector/protocol/ServiceWorker.json: Added. New domain to be made available inside of a ServiceWorker target. 2017-11-14 Yusuke Suzuki [DFG][FTL] Support Array::DirectArguments with OutOfBounds https://bugs.webkit.org/show_bug.cgi?id=179594 Reviewed by Saam Barati. Currently we handle OOB access to DirectArguments as GetByVal(Array::Generic). If we can handle it as GetByVal(Array::DirectArguments+OutOfBounds), we can (1) optimize `arguments[i]` accesses if i is in bound, and (2) encourage arguments elimination phase to convert CreateDirectArguments and GetByVal(Array::DirectArguments+OutOfBounds) to PhantomDirectArguments and GetMyArgumentOutOfBounds respectively. This patch introduces Array::DirectArguments+OutOfBounds array mode. GetByVal can accept this type, and emit optimized code compared to Array::Generic case. We make OOB check failures in GetByVal(Array::DirectArguments+InBounds) as OutOfBounds exit instead of ExoticObjectMode. This change significantly improves SixSpeed rest.es5 since it uses OOB access. Our arguments elimination phase can change CreateDirectArguments to PhantomDirectArguments. rest.es5 59.6719+-2.2440 ^ 3.1634+-0.5507 ^ definitely 18.8635x faster * dfg/DFGArgumentsEliminationPhase.cpp: * dfg/DFGArrayMode.cpp: (JSC::DFG::ArrayMode::refine const): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetByValOnDirectArguments): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal): (JSC::FTL::DFG::LowerDFGToB3::compileGetMyArgumentByVal): 2017-11-14 Saam Barati We need to set topCallFrame when calling Wasm::Memory::grow from the JIT https://bugs.webkit.org/show_bug.cgi?id=179639 Reviewed by JF Bastien. Calling Wasm::Memory::grow from the JIT may cause us to GC. When we GC, we will walk the stack for ShadowChicken (and maybe other things). We weren't updating topCallFrame when calling grow from the Wasm JIT. This would cause the GC to use stale topCallFrame bits in VM, often leading to crashes. This patch fixes this bug by giving Wasm::Instance a lambda that is called when we need to store the topCallFrame. Users of Wasm::Instance can provide a function to do this action. Currently, JSWebAssemblyInstance passes in a lambda that stores to VM.topCallFrame. * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::addGrowMemory): * wasm/WasmInstance.cpp: (JSC::Wasm::Instance::Instance): (JSC::Wasm::Instance::create): * wasm/WasmInstance.h: (JSC::Wasm::Instance::storeTopCallFrame): * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::create): * wasm/js/JSWebAssemblyInstance.h: * wasm/js/WasmToJS.cpp: (JSC::Wasm::wasmToJSException): * wasm/js/WebAssemblyInstanceConstructor.cpp: (JSC::constructJSWebAssemblyInstance): * wasm/js/WebAssemblyPrototype.cpp: (JSC::instantiate): 2017-11-13 Saam Barati Remove pointer caging for HashMapImpl, JSLexicalEnvironment, DirectArguments, ScopedArguments, and ScopedArgumentsTable https://bugs.webkit.org/show_bug.cgi?id=179203 Reviewed by Yusuke Suzuki. This patch only removes the pointer caging for the described types in the title. These types still allocate out of the gigacage. This is a just a cost vs benefit tradeoff of performance vs security. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetByValOnDirectArguments): (JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal): * jit/JITPropertyAccess.cpp: (JSC::JIT::emitDirectArgumentsGetByVal): (JSC::JIT::emitScopedArgumentsGetByVal): * runtime/DirectArguments.h: (JSC::DirectArguments::storage): * runtime/HashMapImpl.cpp: (JSC::HashMapImpl::visitChildren): * runtime/HashMapImpl.h: * runtime/JSLexicalEnvironment.h: (JSC::JSLexicalEnvironment::variables): * runtime/ScopedArguments.h: (JSC::ScopedArguments::overflowStorage const): 2017-11-08 Keith Miller Async iteration should only fetch the next method once and add feature flag https://bugs.webkit.org/show_bug.cgi?id=179451 Reviewed by Geoffrey Garen. Add feature flag for Async iteration. Also, change async iteration to match the expected behavior of the proposal. * Configurations/FeatureDefines.xcconfig: * builtins/AsyncFromSyncIteratorPrototype.js: (globalPrivate.createAsyncFromSyncIterator): (globalPrivate.AsyncFromSyncIteratorConstructor): * builtins/BuiltinNames.h: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitGetAsyncIterator): * runtime/Options.h: 2017-11-13 Mark Lam Add more overflow check book-keeping for MarkedArgumentBuffer. https://bugs.webkit.org/show_bug.cgi?id=179634 Reviewed by Saam Barati. * runtime/ArgList.h: (JSC::MarkedArgumentBuffer::overflowCheckNotNeeded): * runtime/JSJob.cpp: (JSC::JSJobMicrotask::run): * runtime/ObjectConstructor.cpp: (JSC::defineProperties): * runtime/ReflectObject.cpp: (JSC::reflectObjectConstruct): 2017-11-13 Guillaume Emont [JSC] Remove ARM implementation of branchTruncateDoubleToUInt32 https://bugs.webkit.org/show_bug.cgi?id=179542 Reviewed by Alex Christensen. * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::branchTruncateDoubleToUint32): Removed. 2017-11-13 Mark Lam Make the jsc shell loadGetterFromGetterSetter() function more robust. https://bugs.webkit.org/show_bug.cgi?id=179619 Reviewed by Saam Barati. * jsc.cpp: (functionLoadGetterFromGetterSetter): 2017-11-12 Darin Adler More is<> and downcast<>, less static_cast<> https://bugs.webkit.org/show_bug.cgi?id=179600 Reviewed by Chris Dumez. * runtime/JSString.h: (JSC::jsSubstring): Removed unneeded static_cast; length already returns unsigned. (JSC::jsSubstringOfResolved): Ditto. 2017-11-12 Mark Lam We should ensure that operationStrCat2 and operationStrCat3 are never passed Symbols as arguments. https://bugs.webkit.org/show_bug.cgi?id=179562 Reviewed by Saam Barati. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGOperations.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::SafeToExecuteEdge::operator()): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::speculateNotSymbol): (JSC::DFG::SpeculativeJIT::speculate): * dfg/DFGSpeculativeJIT.h: * dfg/DFGUseKind.cpp: (WTF::printInternal): * dfg/DFGUseKind.h: (JSC::DFG::typeFilterFor): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::speculate): (JSC::FTL::DFG::LowerDFGToB3::speculateNotSymbol): 2017-11-11 Devin Rousso Web Inspector: Canvas tab: show detailed status during canvas recording https://bugs.webkit.org/show_bug.cgi?id=178185 Reviewed by Brian Burg. * inspector/protocol/Canvas.json: Add a `recordingProgress` event that is sent to the frontend that contains all the frame payloads since the last Canvas.recordingProgress event and the current buffer usage. * inspector/protocol/Recording.json: Remove the required `frames` parameter from the Recording protocol object, as they will be sent in batches via the Canvas.recordingProgress event. 2017-11-10 Joseph Pecoraro Web Inspector: Make http status codes be "integer" instead of "number" in protocol https://bugs.webkit.org/show_bug.cgi?id=179543 Reviewed by Antoine Quint. * inspector/protocol/Network.json: Use a better type for the status code. 2017-11-10 Robin Morisset The memory consumption of DFG::BasicBlock can be easily reduced a bit https://bugs.webkit.org/show_bug.cgi?id=179528 Reviewed by Saam Barati. A few changes here: - Reordering some fields of DFG::BasicBlock to reduce padding - Making the enum fields that are glorified booleans fit into a u8 - Make each Operands object have a single vector that holds all arguments followed by all locals, instead of two vectors. This change works because we never increase the number of arguments after allocating an Operands object. It lets us avoid one extra capacity field and one extra pointer field per Operands, and more importantly one allocation per Operands whenever both vectors would have overflowed their inlined buffer. Additionally, if a single vector would have overflowed its inline buffer, while the other would have had some free space, we have a chance to avoid an allocation. - Finally, the three methods argumentForIndex, variableForIndex and indexForOperand were deleted since they were dead code. * bytecode/Operands.h: (JSC::Operands::Operands): (JSC::Operands::numberOfArguments const): (JSC::Operands::numberOfLocals const): (JSC::Operands::argument): (JSC::Operands::argument const): (JSC::Operands::local): (JSC::Operands::local const): (JSC::Operands::ensureLocals): (JSC::Operands::setLocal): (JSC::Operands::getLocal): (JSC::Operands::setArgumentFirstTime): (JSC::Operands::setLocalFirstTime): (JSC::Operands::operand): (JSC::Operands::setOperand): (JSC::Operands::size const): (JSC::Operands::at const): (JSC::Operands::at): (JSC::Operands::isArgument const): (JSC::Operands::isVariable const): (JSC::Operands::virtualRegisterForIndex const): (JSC::Operands::fill): (JSC::Operands::operator== const): (JSC::Operands::argumentForIndex const): Deleted. (JSC::Operands::variableForIndex const): Deleted. (JSC::Operands::indexForOperand const): Deleted. * dfg/DFGBasicBlock.cpp: (JSC::DFG::BasicBlock::BasicBlock): * dfg/DFGBasicBlock.h: * dfg/DFGBranchDirection.h: * dfg/DFGStructureClobberState.h: 2017-11-09 Yusuke Suzuki [JSC] Retry module fetching if previous request fails https://bugs.webkit.org/show_bug.cgi?id=178168 Reviewed by Saam Barati. According to the latest spec, the failed fetching operation can be retried if it is requested again. For example, When performing the first module fetching, integrity check fails, and the load of this module becomes failed. But when loading the second module, we do not use the cached failure result in the first module loading. We retry fetching for "./A.js". In this case, we have a correct integrity and module fetching succeeds. This is specified in whatwg/HTML[1]. If the fetching fails, we do not cache it. Interestingly, fetching result and instantiation result will be cached if they succeeds. This is because we would like to cache modules based on their URLs. As a result, In the above case, the first loading succeeds. And the second loading also succeeds since the succeeded fetching and instantiation are cached in the module pipeline. This patch implements the above semantics. Previously, our module pipeline always caches the result. If the fetching failed, all the subsequent fetching for the same URL fails even if we have different integrity values. We retry fetching if the previous one fails. As an overview of our change, 1. Fetching result should be cached only if it succeeds. Two or more on-the-fly fetching requests to the same URLs should be unified. But if currently executing one fails, other attempts should retry fetching. 2. Instantiation should be cached if fetching succeeds. 3. Satisfying should be cached if it succeeds. [1]: https://html.spec.whatwg.org/#fetch-a-single-module-script * builtins/ModuleLoaderPrototype.js: (requestFetch): (requestInstantiate): (requestSatisfy): (link): (loadModule): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): 2017-11-09 Devin Rousso Web Inspector: support undo/redo of insertAdjacentHTML https://bugs.webkit.org/show_bug.cgi?id=179283 Reviewed by Joseph Pecoraro. * inspector/protocol/DOM.json: Add `insertAdjacentHTML` command that executes an undoable version of `insertAdjacentHTML` on the given node. 2017-11-09 Joseph Pecoraro Web Inspector: Make domain availability a list of types instead of a single type https://bugs.webkit.org/show_bug.cgi?id=179457 Reviewed by Brian Burg. * inspector/scripts/codegen/generate_js_backend_commands.py: (JSBackendCommandsGenerator.generate_domain): Update output of `InspectorBackend.activateDomain` to include the list. * inspector/scripts/codegen/models.py: (Protocol.parse_domain): Parse `availability` as a list and include a new supported value of "service-worker". * inspector/protocol/ApplicationCache.json: * inspector/protocol/CSS.json: * inspector/protocol/Canvas.json: * inspector/protocol/DOM.json: * inspector/protocol/DOMDebugger.json: * inspector/protocol/DOMStorage.json: * inspector/protocol/Database.json: * inspector/protocol/IndexedDB.json: * inspector/protocol/LayerTree.json: * inspector/protocol/Memory.json: * inspector/protocol/Network.json: * inspector/protocol/Page.json: * inspector/protocol/Timeline.json: * inspector/protocol/Worker.json: Update `availability` to be a list. * inspector/scripts/tests/generic/domain-availability.json: * inspector/scripts/tests/generic/expected/domain-availability.json-result: * inspector/scripts/tests/generic/expected/fail-on-domain-availability-type.json-error: Added. * inspector/scripts/tests/generic/expected/fail-on-domain-availability-value.json-error: Added. * inspector/scripts/tests/generic/expected/fail-on-domain-availability.json-error: * inspector/scripts/tests/generic/fail-on-domain-availability-type.json: Copied from Source/JavaScriptCore/inspector/scripts/tests/generic/fail-on-domain-availability.json. * inspector/scripts/tests/generic/fail-on-domain-availability-value.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/fail-on-domain-availability.json. Update tests to include a test for the type and an invalid value. 2017-11-03 Yusuke Suzuki [JSC][JIT] Clean up SlowPathCall stubs https://bugs.webkit.org/show_bug.cgi?id=179247 Reviewed by Saam Barati. We have bunch of duplicate functions that just call a slow path function. This patch cleans up the above duplication. * jit/JIT.cpp: (JSC::JIT::emitSlowCaseCall): (JSC::JIT::privateCompileSlowCases): * jit/JIT.h: * jit/JITArithmetic.cpp: (JSC::JIT::emitSlow_op_unsigned): Deleted. (JSC::JIT::emitSlow_op_inc): Deleted. (JSC::JIT::emitSlow_op_dec): Deleted. (JSC::JIT::emitSlow_op_bitand): Deleted. (JSC::JIT::emitSlow_op_bitor): Deleted. (JSC::JIT::emitSlow_op_bitxor): Deleted. (JSC::JIT::emitSlow_op_lshift): Deleted. (JSC::JIT::emitSlow_op_rshift): Deleted. (JSC::JIT::emitSlow_op_urshift): Deleted. (JSC::JIT::emitSlow_op_div): Deleted. * jit/JITArithmetic32_64.cpp: (JSC::JIT::emitSlow_op_unsigned): Deleted. (JSC::JIT::emitSlow_op_inc): Deleted. (JSC::JIT::emitSlow_op_dec): Deleted. * jit/JITOpcodes.cpp: (JSC::JIT::emitSlow_op_create_this): Deleted. (JSC::JIT::emitSlow_op_check_tdz): Deleted. (JSC::JIT::emitSlow_op_to_this): Deleted. (JSC::JIT::emitSlow_op_to_primitive): Deleted. (JSC::JIT::emitSlow_op_not): Deleted. (JSC::JIT::emitSlow_op_stricteq): Deleted. (JSC::JIT::emitSlow_op_nstricteq): Deleted. (JSC::JIT::emitSlow_op_to_number): Deleted. (JSC::JIT::emitSlow_op_to_string): Deleted. (JSC::JIT::emitSlow_op_to_object): Deleted. (JSC::JIT::emitSlow_op_get_direct_pname): Deleted. (JSC::JIT::emitSlow_op_has_structure_property): Deleted. * jit/JITOpcodes32_64.cpp: (JSC::JIT::emitSlow_op_to_primitive): Deleted. (JSC::JIT::emitSlow_op_not): Deleted. (JSC::JIT::emitSlow_op_stricteq): Deleted. (JSC::JIT::emitSlow_op_nstricteq): Deleted. (JSC::JIT::emitSlow_op_to_number): Deleted. (JSC::JIT::emitSlow_op_to_string): Deleted. (JSC::JIT::emitSlow_op_to_object): Deleted. (JSC::JIT::emitSlow_op_create_this): Deleted. (JSC::JIT::emitSlow_op_to_this): Deleted. (JSC::JIT::emitSlow_op_check_tdz): Deleted. (JSC::JIT::emitSlow_op_get_direct_pname): Deleted. * jit/JITPropertyAccess.cpp: (JSC::JIT::emitSlow_op_resolve_scope): Deleted. * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_resolve_scope): (JSC::JIT::emitSlow_op_resolve_scope): Deleted. * jit/SlowPathCall.h: (JSC::JITSlowPathCall::JITSlowPathCall): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: 2017-11-09 Guillaume Emont [JSC][MIPS] Use fcsr to check the validity of the result of trunc.w.d https://bugs.webkit.org/show_bug.cgi?id=179446 Reviewed by Žan Doberšek. The trunc.w.d mips instruction should give a 0x7fffffff result when the source value is Infinity, NaN, or rounds to an integer outside the range -2^31 to 2^31 -1. This is what branchTruncateDoubleToInt32() and branchTruncateDoubleToUInt32() have been relying on. It turns out that this assumption is not true on some CPUs, including on the ci20 on which we run the testbot (we get 0x80000000 instead). We should the invalid operation cause bit instead to check whether the source value could be properly truncated. This requires the addition of the cfc1 instruction, as well as the special registers that can be used with it (control registers of CP1). * assembler/MIPSAssembler.h: (JSC::MIPSAssembler::firstSPRegister): (JSC::MIPSAssembler::lastSPRegister): (JSC::MIPSAssembler::numberOfSPRegisters): (JSC::MIPSAssembler::sprName): Added control registers of CP1. (JSC::MIPSAssembler::cfc1): Added. * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::branchOnTruncateResult): (JSC::MacroAssemblerMIPS::branchTruncateDoubleToInt32): (JSC::MacroAssemblerMIPS::branchTruncateDoubleToUint32): Use fcsr to check if the value could be properly truncated. 2017-11-08 Jeremy Jones HTMLMediaElement should not use element fullscreen on iOS https://bugs.webkit.org/show_bug.cgi?id=179418 rdar://problem/35409277 Reviewed by Eric Carlson. Add ENABLE_VIDEO_USES_ELEMENT_FULLSCREEN to determine if HTMLMediaElement should use element full screen or not. * Configurations/FeatureDefines.xcconfig: 2017-11-08 Joseph Pecoraro Web Inspector: Show Internal properties of PaymentRequest in Web Inspector Console https://bugs.webkit.org/show_bug.cgi?id=179276 Reviewed by Andy Estes. * inspector/InjectedScriptHost.h: * inspector/JSInjectedScriptHost.cpp: (Inspector::JSInjectedScriptHost::getInternalProperties): Call through to virtual implementation so that WebCore can provide custom internal properties for Web / DOM objects. 2017-11-08 Saam Barati A JSFunction's ObjectAllocationProfile should watch the poly prototype watchpoint so it can clear its object allocation profile https://bugs.webkit.org/show_bug.cgi?id=177792 Reviewed by Yusuke Suzuki. Before this patch, if a JSFunction's rare data initialized its allocation profile before its backing Executable's poly proto watchpoint was invalidated, that JSFunction would continue to allocate non-poly proto objects until its allocation profile was cleared (which essentially never happens in practice). This patch improves on this pathology. A JSFunction's rare data will now watch the poly proto watchpoint if it's still valid and clear its allocation profile when we detect that we should go poly proto. * bytecode/ObjectAllocationProfile.h: * bytecode/ObjectAllocationProfileInlines.h: (JSC::ObjectAllocationProfile::initializeProfile): * runtime/FunctionRareData.cpp: (JSC::FunctionRareData::initializeObjectAllocationProfile): (JSC::FunctionRareData::AllocationProfileClearingWatchpoint::fireInternal): * runtime/FunctionRareData.h: (JSC::FunctionRareData::hasAllocationProfileClearingWatchpoint const): (JSC::FunctionRareData::createAllocationProfileClearingWatchpoint): (JSC::FunctionRareData::AllocationProfileClearingWatchpoint::AllocationProfileClearingWatchpoint): 2017-11-08 Keith Miller Add super sampler begin and end bytecodes. https://bugs.webkit.org/show_bug.cgi?id=179376 Reviewed by Filip Pizlo. This patch adds a way to measure a narrow range of bytecodes for performance. This is done using the same infrastructure as the super sampler. I also added a class that helps do the bytecode checking with RAII. One problem with the current way this is done is that we don't handle decrementing early exits, either from branches or exceptions. So, when using this API users need to ensure that there are no early exits or that those exits don't occur on the measure code. * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/BytecodeDumper.cpp: (JSC::BytecodeDumper::dumpBytecode): * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitSuperSamplerBegin): (JSC::BytecodeGenerator::emitSuperSamplerEnd): * bytecompiler/BytecodeGenerator.h: * bytecompiler/SuperSamplerBytecodeScope.h: Added. (JSC::SuperSamplerBytecodeScope::SuperSamplerBytecodeScope): (JSC::SuperSamplerBytecodeScope::~SuperSamplerBytecodeScope): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGClobbersExitState.cpp: (JSC::DFG::clobbersExitState): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGMayExit.cpp: * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: * 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::compileSuperSamplerBegin): (JSC::FTL::DFG::LowerDFGToB3::compileSuperSamplerEnd): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JIT.h: * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_super_sampler_begin): (JSC::JIT::emit_op_super_sampler_end): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter.asm: 2017-11-08 Robin Morisset Turn recursive tail calls into loops https://bugs.webkit.org/show_bug.cgi?id=176601 Reviewed by Saam Barati. Relanding after https://bugs.webkit.org/show_bug.cgi?id=178834. We want to turn recursive tail calls into loops early in the pipeline, so that the loops can then be optimized. One difficulty is that we need to split the entry block of the function we are jumping to in order to have somewhere to jump to. Worse: it is not necessarily the first block of the codeBlock, because of inlining! So we must do the splitting in the DFGByteCodeParser, at the same time as inlining. We do this part through modifying the computation of the jump targets. Importantly, we only do this splitting for functions that have tail calls. It is the only case where the optimisation is sound, and doing the splitting unconditionnaly destroys performance on Octane/raytrace. We must then do the actual transformation also in DFGByteCodeParser, to avoid code motion moving code out of the body of what will become a loop. The transformation is entirely contained in handleRecursiveTailCall, which is hooked to the inlining machinery. * bytecode/CodeBlock.h: (JSC::CodeBlock::hasTailCalls const): * bytecode/PreciseJumpTargets.cpp: (JSC::getJumpTargetsForBytecodeOffset): (JSC::computePreciseJumpTargetsInternal): * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedCodeBlock::hasTailCalls const): (JSC::UnlinkedCodeBlock::setHasTailCalls): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitEnter): (JSC::BytecodeGenerator::emitCallInTailPosition): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::allocateTargetableBlock): (JSC::DFG::ByteCodeParser::makeBlockTargetable): (JSC::DFG::ByteCodeParser::handleCall): (JSC::DFG::ByteCodeParser::handleRecursiveTailCall): (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::parse): 2017-11-08 Joseph Pecoraro Web Inspector: Remove unused Page.ScriptIdentifier protocol type https://bugs.webkit.org/show_bug.cgi?id=179407 Reviewed by Matt Baker. * inspector/protocol/Page.json: Remove unused protocol type. 2017-11-08 Carlos Garcia Campos Web Inspector: use JSON::{Array,Object,Value} instead of Inspector{Array,Object,Value} https://bugs.webkit.org/show_bug.cgi?id=173619 Reviewed by Alex Christensen and Brian Burg. Eventually all classes used for our JSON-RPC message passing should be outside of the Inspector namespace since the protocol is used outside of Inspector code. This will also allow us to unify the primitive JSON types with parameteric types like Inspector::Protocol::Array and other protocol-related types which don't need to be in the Inspector namespace. Start this refactoring off by making JSON::Value a typedef for InspectorValue. In following patches, other clients will move to use JSON::Value and friends. When all uses are changed, the actual implementation will be renamed. This patch just focuses on the typedef and making changes in generated protocol code. Original patch by Brian Burg, rebased and updated by me. * inspector/InspectorValues.cpp: * inspector/InspectorValues.h: * inspector/scripts/codegen/cpp_generator.py: (CppGenerator.cpp_protocol_type_for_type): (CppGenerator.cpp_type_for_unchecked_formal_in_parameter): (CppGenerator.cpp_type_for_type_with_name): (CppGenerator.cpp_type_for_stack_in_parameter): * inspector/scripts/codegen/cpp_generator_templates.py: (void): * inspector/scripts/codegen/generate_cpp_protocol_types_header.py: (_generate_class_for_object_declaration): (_generate_forward_declarations_for_binding_traits): * inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py: (CppProtocolTypesImplementationGenerator._generate_assertion_for_object_declaration): (CppProtocolTypesImplementationGenerator._generate_assertion_for_enum): * inspector/scripts/tests/all/expected/definitions-with-mac-platform.json-result: * inspector/scripts/tests/generic/expected/commands-with-async-attribute.json-result: * inspector/scripts/tests/generic/expected/commands-with-optional-call-return-parameters.json-result: * inspector/scripts/tests/generic/expected/domain-availability.json-result: * inspector/scripts/tests/generic/expected/domains-with-varying-command-sizes.json-result: * inspector/scripts/tests/generic/expected/enum-values.json-result: * inspector/scripts/tests/generic/expected/events-with-optional-parameters.json-result: * inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result: * inspector/scripts/tests/generic/expected/shadowed-optional-type-setters.json-result: * inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result: * inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result: * inspector/scripts/tests/generic/expected/type-with-open-parameters.json-result: * inspector/scripts/tests/generic/expected/worker-supported-domains.json-result: * inspector/scripts/tests/mac/expected/definitions-with-mac-platform.json-result: 2017-11-07 Maciej Stachowiak Get rid of unsightly hex numbers from unified build object files https://bugs.webkit.org/show_bug.cgi?id=179410 Reviewed by Saam Barati. * JavaScriptCore.xcodeproj/project.pbxproj: Rename UnifiedSource*.mm to UnifiedSource*-mm.mm for more readable build output. 2017-11-07 Saam Barati Only cage double butterfly accesses https://bugs.webkit.org/show_bug.cgi?id=179202 Reviewed by Mark Lam. This patch removes caging from all butterfly accesses except double loads/stores. This is a performance vs security tradeoff. Double loads/stores are the only butterfly loads/stores that can write arbitrary bit patterns, so we choose to keep them safe by caging. The other load/stores we are no longer caging to get back performance on various benchmarks. * bytecode/AccessCase.cpp: (JSC::AccessCase::generateImpl): * bytecode/InlineAccess.cpp: (JSC::InlineAccess::dumpCacheSizesAndCrash): (JSC::InlineAccess::generateSelfPropertyAccess): (JSC::InlineAccess::generateSelfPropertyReplace): (JSC::InlineAccess::generateArrayLength): * dfg/DFGFixedButterflyAccessUncagingPhase.cpp: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCreateRest): (JSC::DFG::SpeculativeJIT::compileSpread): (JSC::DFG::SpeculativeJIT::compileNewArrayWithSpread): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileGetDirectPname): * jit/JITPropertyAccess.cpp: (JSC::JIT::emitContiguousLoad): (JSC::JIT::emitArrayStorageLoad): (JSC::JIT::emitGenericContiguousPutByVal): (JSC::JIT::emitArrayStoragePutByVal): (JSC::JIT::emit_op_get_from_scope): (JSC::JIT::emit_op_put_to_scope): * llint/LowLevelInterpreter64.asm: * runtime/AuxiliaryBarrier.h: (JSC::AuxiliaryBarrier::operator-> const): * runtime/Butterfly.h: (JSC::Butterfly::caged): (JSC::Butterfly::contiguousDouble): * runtime/JSArray.cpp: (JSC::JSArray::setLength): (JSC::JSArray::pop): (JSC::JSArray::shiftCountWithAnyIndexingType): (JSC::JSArray::unshiftCountWithAnyIndexingType): (JSC::JSArray::fillArgList): (JSC::JSArray::copyToArguments): * runtime/JSArrayInlines.h: (JSC::JSArray::pushInline): * runtime/JSObject.cpp: (JSC::JSObject::heapSnapshot): (JSC::JSObject::createInitialIndexedStorage): (JSC::JSObject::createArrayStorage): (JSC::JSObject::convertUndecidedToInt32): (JSC::JSObject::ensureLengthSlow): (JSC::JSObject::reallocateAndShrinkButterfly): (JSC::JSObject::allocateMoreOutOfLineStorage): * runtime/JSObject.h: (JSC::JSObject::canGetIndexQuickly): (JSC::JSObject::getIndexQuickly): (JSC::JSObject::tryGetIndexQuickly const): (JSC::JSObject::canSetIndexQuickly): (JSC::JSObject::butterfly const): (JSC::JSObject::butterfly): 2017-11-07 Mark Lam Introduce a default RegisterSet constructor so that we can use { } notation. https://bugs.webkit.org/show_bug.cgi?id=179389 Reviewed by Saam Barati. I also replaced uses of "RegisterSet()" with "{ }" where the use of "RegisterSet()" does not add any code documentation value. * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp: * b3/air/AirCode.cpp: (JSC::B3::Air::Code::setRegsInPriorityOrder): * b3/air/AirPrintSpecial.cpp: (JSC::B3::Air::PrintSpecial::extraEarlyClobberedRegs): (JSC::B3::Air::PrintSpecial::extraClobberedRegs): * b3/air/testair.cpp: * bytecode/PolymorphicAccess.h: (JSC::AccessGenerationState::preserveLiveRegistersToStackForCall): (JSC::AccessGenerationState::restoreLiveRegistersFromStackForCall): * dfg/DFGJITCode.cpp: (JSC::DFG::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite): * ftl/FTLJITCode.cpp: (JSC::FTL::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite): * jit/JITCode.cpp: (JSC::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite): * jit/RegisterSet.cpp: (JSC::RegisterSet::reservedHardwareRegisters): (JSC::RegisterSet::runtimeRegisters): (JSC::RegisterSet::macroScratchRegisters): * jit/RegisterSet.h: (JSC::RegisterSet::RegisterSet): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::emitTierUpCheck): 2017-11-07 Mark Lam AccessCase::generateImpl() should exclude the result register when restoring registers after a call. https://bugs.webkit.org/show_bug.cgi?id=179355 Reviewed by Saam Barati. In the Transition case in AccessCase::generateImpl(), we were restoring registers using restoreLiveRegistersFromStackForCall() without excluding the scratchGPR where we previously stashed the reallocated butterfly. If the generated code is under heavy register pressure, scratchGPR could have been from the set of preserved registers, and hence, would be restored by restoreLiveRegistersFromStackForCall(). As a result, the restoration would trash the butterfly result we stored there. This patch fixes the issue by excluding the scratchGPR in the restoration. * bytecode/AccessCase.cpp: (JSC::AccessCase::generateImpl): 2017-11-06 Robin Morisset CodeBlock::usesOpcode() is dead code https://bugs.webkit.org/show_bug.cgi?id=179316 Reviewed by Yusuke Suzuki. Remove CodeBlock::usesOpcode which is dead code * bytecode/CodeBlock.cpp: * bytecode/CodeBlock.h: 2017-11-05 Yusuke Suzuki JIT call inline caches should cache calls to objects with getCallData/getConstructData traps https://bugs.webkit.org/show_bug.cgi?id=144458 Reviewed by Saam Barati. Previously only JSFunction is handled by CallLinkInfo's caching mechanism. This means that InternalFunction calls are not cached and they always go to the slow path. This is not good because 1. We need to query getCallData/getConstructData every time in the slow path. 2. CallLinkInfo tells nothing in the higher tier JITs. This patch starts handling InternalFunction in CallLinkInfo's caching mechanism. We change InternalFunction to hold pointers to the functions for call and construct. We have new stubs that can call/construct InternalFunction. And we return this code pointer as a result of setup call to use CallLinkInfo mechanism. This patch is critical to optimizing derived Array construction[1] since it starts using CallLinkInfo for InternalFunction. Previously we did not record any information to CallLinkInfo. Except for the case that DFGByteCodeParser figures out InternalFunction constant, we cannot attempt to emit DFG nodes for these InternalFunctions since CallLinkInfo tells us nothing. Attached microbenchmarks show performance improvement. baseline patched dfg-internal-function-construct 1.6439+-0.0826 ^ 1.2829+-0.0727 ^ definitely 1.2813x faster dfg-internal-function-not-handled-construct 2.1862+-0.1361 2.0696+-0.1201 might be 1.0564x faster dfg-internal-function-not-handled-call 20.7592+-0.9085 19.7369+-0.7921 might be 1.0518x faster dfg-internal-function-call 1.6856+-0.0967 ^ 1.2771+-0.0744 ^ definitely 1.3198x faster [1]: https://bugs.webkit.org/show_bug.cgi?id=178064 * API/JSCallbackFunction.cpp: (JSC::JSCallbackFunction::JSCallbackFunction): (JSC::JSCallbackFunction::getCallData): Deleted. * API/JSCallbackFunction.h: (JSC::JSCallbackFunction::createStructure): * API/ObjCCallbackFunction.h: (JSC::ObjCCallbackFunction::createStructure): * API/ObjCCallbackFunction.mm: (JSC::ObjCCallbackFunction::ObjCCallbackFunction): (JSC::ObjCCallbackFunction::getCallData): Deleted. (JSC::ObjCCallbackFunction::getConstructData): Deleted. * bytecode/BytecodeDumper.cpp: (JSC::BytecodeDumper::printCallOp): * bytecode/BytecodeList.json: * bytecode/CallLinkInfo.cpp: (JSC::CallLinkInfo::setCallee): (JSC::CallLinkInfo::callee): (JSC::CallLinkInfo::setLastSeenCallee): (JSC::CallLinkInfo::lastSeenCallee): (JSC::CallLinkInfo::visitWeak): * bytecode/CallLinkInfo.h: * bytecode/CallLinkStatus.cpp: (JSC::CallLinkStatus::computeFromCallLinkInfo): * bytecode/LLIntCallLinkInfo.h: * jit/JITOperations.cpp: * jit/JITThunks.cpp: (JSC::JITThunks::ctiInternalFunctionCall): (JSC::JITThunks::ctiInternalFunctionConstruct): * jit/JITThunks.h: * jit/Repatch.cpp: (JSC::linkFor): (JSC::linkPolymorphicCall): * jit/Repatch.h: * jit/ThunkGenerators.cpp: (JSC::virtualThunkFor): (JSC::nativeForGenerator): (JSC::nativeCallGenerator): (JSC::nativeTailCallGenerator): (JSC::nativeTailCallWithoutSavedTagsGenerator): (JSC::nativeConstructGenerator): (JSC::internalFunctionCallGenerator): (JSC::internalFunctionConstructGenerator): * jit/ThunkGenerators.h: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::setUpCall): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/ArrayConstructor.cpp: (JSC::ArrayConstructor::ArrayConstructor): (JSC::ArrayConstructor::getConstructData): Deleted. (JSC::ArrayConstructor::getCallData): Deleted. * runtime/ArrayConstructor.h: (JSC::ArrayConstructor::createStructure): * runtime/AsyncFunctionConstructor.cpp: (JSC::AsyncFunctionConstructor::AsyncFunctionConstructor): (JSC::AsyncFunctionConstructor::finishCreation): (JSC::AsyncFunctionConstructor::getCallData): Deleted. (JSC::AsyncFunctionConstructor::getConstructData): Deleted. * runtime/AsyncFunctionConstructor.h: (JSC::AsyncFunctionConstructor::createStructure): * runtime/AsyncGeneratorFunctionConstructor.cpp: (JSC::AsyncGeneratorFunctionConstructor::AsyncGeneratorFunctionConstructor): (JSC::AsyncGeneratorFunctionConstructor::finishCreation): (JSC::AsyncGeneratorFunctionConstructor::getCallData): Deleted. (JSC::AsyncGeneratorFunctionConstructor::getConstructData): Deleted. * runtime/AsyncGeneratorFunctionConstructor.h: (JSC::AsyncGeneratorFunctionConstructor::createStructure): * runtime/BooleanConstructor.cpp: (JSC::callBooleanConstructor): (JSC::BooleanConstructor::BooleanConstructor): (JSC::BooleanConstructor::finishCreation): (JSC::BooleanConstructor::getConstructData): Deleted. (JSC::BooleanConstructor::getCallData): Deleted. * runtime/BooleanConstructor.h: (JSC::BooleanConstructor::createStructure): * runtime/DateConstructor.cpp: (JSC::DateConstructor::DateConstructor): (JSC::DateConstructor::getConstructData): Deleted. (JSC::DateConstructor::getCallData): Deleted. * runtime/DateConstructor.h: (JSC::DateConstructor::createStructure): * runtime/Error.h: (JSC::StrictModeTypeErrorFunction::StrictModeTypeErrorFunction): (JSC::StrictModeTypeErrorFunction::createStructure): (JSC::StrictModeTypeErrorFunction::getConstructData): Deleted. (JSC::StrictModeTypeErrorFunction::getCallData): Deleted. * runtime/ErrorConstructor.cpp: (JSC::ErrorConstructor::ErrorConstructor): (JSC::ErrorConstructor::getConstructData): Deleted. (JSC::ErrorConstructor::getCallData): Deleted. * runtime/ErrorConstructor.h: (JSC::ErrorConstructor::createStructure): * runtime/FunctionConstructor.cpp: (JSC::FunctionConstructor::FunctionConstructor): (JSC::FunctionConstructor::finishCreation): (JSC::FunctionConstructor::getConstructData): Deleted. (JSC::FunctionConstructor::getCallData): Deleted. * runtime/FunctionConstructor.h: (JSC::FunctionConstructor::createStructure): * runtime/FunctionPrototype.cpp: (JSC::callFunctionPrototype): (JSC::FunctionPrototype::FunctionPrototype): (JSC::FunctionPrototype::getCallData): Deleted. * runtime/FunctionPrototype.h: (JSC::FunctionPrototype::createStructure): * runtime/GeneratorFunctionConstructor.cpp: (JSC::GeneratorFunctionConstructor::GeneratorFunctionConstructor): (JSC::GeneratorFunctionConstructor::finishCreation): (JSC::GeneratorFunctionConstructor::getCallData): Deleted. (JSC::GeneratorFunctionConstructor::getConstructData): Deleted. * runtime/GeneratorFunctionConstructor.h: (JSC::GeneratorFunctionConstructor::createStructure): * runtime/InternalFunction.cpp: (JSC::InternalFunction::InternalFunction): (JSC::InternalFunction::finishCreation): (JSC::InternalFunction::getCallData): (JSC::InternalFunction::getConstructData): * runtime/InternalFunction.h: (JSC::InternalFunction::createStructure): (JSC::InternalFunction::nativeFunctionFor): (JSC::InternalFunction::offsetOfNativeFunctionFor): * runtime/IntlCollatorConstructor.cpp: (JSC::IntlCollatorConstructor::createStructure): (JSC::IntlCollatorConstructor::IntlCollatorConstructor): (JSC::IntlCollatorConstructor::getConstructData): Deleted. (JSC::IntlCollatorConstructor::getCallData): Deleted. * runtime/IntlCollatorConstructor.h: * runtime/IntlDateTimeFormatConstructor.cpp: (JSC::IntlDateTimeFormatConstructor::createStructure): (JSC::IntlDateTimeFormatConstructor::IntlDateTimeFormatConstructor): (JSC::IntlDateTimeFormatConstructor::getConstructData): Deleted. (JSC::IntlDateTimeFormatConstructor::getCallData): Deleted. * runtime/IntlDateTimeFormatConstructor.h: * runtime/IntlNumberFormatConstructor.cpp: (JSC::IntlNumberFormatConstructor::createStructure): (JSC::IntlNumberFormatConstructor::IntlNumberFormatConstructor): (JSC::IntlNumberFormatConstructor::getConstructData): Deleted. (JSC::IntlNumberFormatConstructor::getCallData): Deleted. * runtime/IntlNumberFormatConstructor.h: * runtime/JSArrayBufferConstructor.cpp: (JSC::JSArrayBufferConstructor::JSArrayBufferConstructor): (JSC::JSArrayBufferConstructor::createStructure): (JSC::JSArrayBufferConstructor::getConstructData): Deleted. (JSC::JSArrayBufferConstructor::getCallData): Deleted. * runtime/JSArrayBufferConstructor.h: * runtime/JSGenericTypedArrayViewConstructor.h: * runtime/JSGenericTypedArrayViewConstructorInlines.h: (JSC::JSGenericTypedArrayViewConstructor::JSGenericTypedArrayViewConstructor): (JSC::JSGenericTypedArrayViewConstructor::createStructure): (JSC::JSGenericTypedArrayViewConstructor::getConstructData): Deleted. (JSC::JSGenericTypedArrayViewConstructor::getCallData): Deleted. * runtime/JSInternalPromiseConstructor.cpp: (JSC::JSInternalPromiseConstructor::createStructure): (JSC::JSInternalPromiseConstructor::JSInternalPromiseConstructor): (JSC::JSInternalPromiseConstructor::getConstructData): Deleted. (JSC::JSInternalPromiseConstructor::getCallData): Deleted. * runtime/JSInternalPromiseConstructor.h: * runtime/JSPromiseConstructor.cpp: (JSC::JSPromiseConstructor::createStructure): (JSC::JSPromiseConstructor::JSPromiseConstructor): (JSC::JSPromiseConstructor::getConstructData): Deleted. (JSC::JSPromiseConstructor::getCallData): Deleted. * runtime/JSPromiseConstructor.h: * runtime/JSType.h: * runtime/JSTypedArrayViewConstructor.cpp: (JSC::JSTypedArrayViewConstructor::JSTypedArrayViewConstructor): (JSC::JSTypedArrayViewConstructor::createStructure): (JSC::JSTypedArrayViewConstructor::getConstructData): Deleted. (JSC::JSTypedArrayViewConstructor::getCallData): Deleted. * runtime/JSTypedArrayViewConstructor.h: * runtime/MapConstructor.cpp: (JSC::MapConstructor::MapConstructor): (JSC::MapConstructor::getConstructData): Deleted. (JSC::MapConstructor::getCallData): Deleted. * runtime/MapConstructor.h: (JSC::MapConstructor::createStructure): (JSC::MapConstructor::MapConstructor): Deleted. * runtime/NativeErrorConstructor.cpp: (JSC::NativeErrorConstructor::NativeErrorConstructor): (JSC::NativeErrorConstructor::getConstructData): Deleted. (JSC::NativeErrorConstructor::getCallData): Deleted. * runtime/NativeErrorConstructor.h: (JSC::NativeErrorConstructor::createStructure): * runtime/NullGetterFunction.cpp: (JSC::NullGetterFunction::NullGetterFunction): (JSC::NullGetterFunction::getCallData): Deleted. (JSC::NullGetterFunction::getConstructData): Deleted. * runtime/NullGetterFunction.h: (JSC::NullGetterFunction::createStructure): (JSC::NullGetterFunction::NullGetterFunction): Deleted. * runtime/NullSetterFunction.cpp: (JSC::NullSetterFunction::NullSetterFunction): (JSC::NullSetterFunction::getCallData): Deleted. (JSC::NullSetterFunction::getConstructData): Deleted. * runtime/NullSetterFunction.h: (JSC::NullSetterFunction::createStructure): (JSC::NullSetterFunction::NullSetterFunction): Deleted. * runtime/NumberConstructor.cpp: (JSC::NumberConstructor::NumberConstructor): (JSC::constructNumberConstructor): (JSC::constructWithNumberConstructor): Deleted. (JSC::NumberConstructor::getConstructData): Deleted. (JSC::NumberConstructor::getCallData): Deleted. * runtime/NumberConstructor.h: (JSC::NumberConstructor::createStructure): * runtime/ObjectConstructor.cpp: (JSC::ObjectConstructor::ObjectConstructor): (JSC::ObjectConstructor::getConstructData): Deleted. (JSC::ObjectConstructor::getCallData): Deleted. * runtime/ObjectConstructor.h: (JSC::ObjectConstructor::createStructure): * runtime/ProxyConstructor.cpp: (JSC::ProxyConstructor::ProxyConstructor): (JSC::ProxyConstructor::getConstructData): Deleted. (JSC::ProxyConstructor::getCallData): Deleted. * runtime/ProxyConstructor.h: (JSC::ProxyConstructor::createStructure): * runtime/ProxyRevoke.cpp: (JSC::ProxyRevoke::ProxyRevoke): (JSC::ProxyRevoke::getCallData): Deleted. * runtime/ProxyRevoke.h: (JSC::ProxyRevoke::createStructure): * runtime/RegExpConstructor.cpp: (JSC::RegExpConstructor::RegExpConstructor): (JSC::RegExpConstructor::getConstructData): Deleted. (JSC::RegExpConstructor::getCallData): Deleted. * runtime/RegExpConstructor.h: (JSC::RegExpConstructor::createStructure): * runtime/SetConstructor.cpp: (JSC::SetConstructor::SetConstructor): (JSC::SetConstructor::getConstructData): Deleted. (JSC::SetConstructor::getCallData): Deleted. * runtime/SetConstructor.h: (JSC::SetConstructor::createStructure): (JSC::SetConstructor::SetConstructor): Deleted. * runtime/StringConstructor.cpp: (JSC::StringConstructor::StringConstructor): (JSC::StringConstructor::getConstructData): Deleted. (JSC::StringConstructor::getCallData): Deleted. * runtime/StringConstructor.h: (JSC::StringConstructor::createStructure): * runtime/SymbolConstructor.cpp: (JSC::SymbolConstructor::SymbolConstructor): (JSC::SymbolConstructor::getConstructData): Deleted. (JSC::SymbolConstructor::getCallData): Deleted. * runtime/SymbolConstructor.h: (JSC::SymbolConstructor::createStructure): * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::getCTIInternalFunctionTrampolineFor): * runtime/VM.h: * runtime/WeakMapConstructor.cpp: (JSC::WeakMapConstructor::WeakMapConstructor): (JSC::WeakMapConstructor::getConstructData): Deleted. (JSC::WeakMapConstructor::getCallData): Deleted. * runtime/WeakMapConstructor.h: (JSC::WeakMapConstructor::createStructure): (JSC::WeakMapConstructor::WeakMapConstructor): Deleted. * runtime/WeakSetConstructor.cpp: (JSC::WeakSetConstructor::WeakSetConstructor): (JSC::WeakSetConstructor::getConstructData): Deleted. (JSC::WeakSetConstructor::getCallData): Deleted. * runtime/WeakSetConstructor.h: (JSC::WeakSetConstructor::createStructure): (JSC::WeakSetConstructor::WeakSetConstructor): Deleted. * wasm/js/WebAssemblyCompileErrorConstructor.cpp: (JSC::WebAssemblyCompileErrorConstructor::createStructure): (JSC::WebAssemblyCompileErrorConstructor::WebAssemblyCompileErrorConstructor): (JSC::WebAssemblyCompileErrorConstructor::getConstructData): Deleted. (JSC::WebAssemblyCompileErrorConstructor::getCallData): Deleted. * wasm/js/WebAssemblyCompileErrorConstructor.h: * wasm/js/WebAssemblyInstanceConstructor.cpp: (JSC::WebAssemblyInstanceConstructor::createStructure): (JSC::WebAssemblyInstanceConstructor::WebAssemblyInstanceConstructor): (JSC::WebAssemblyInstanceConstructor::getConstructData): Deleted. (JSC::WebAssemblyInstanceConstructor::getCallData): Deleted. * wasm/js/WebAssemblyInstanceConstructor.h: * wasm/js/WebAssemblyLinkErrorConstructor.cpp: (JSC::WebAssemblyLinkErrorConstructor::createStructure): (JSC::WebAssemblyLinkErrorConstructor::WebAssemblyLinkErrorConstructor): (JSC::WebAssemblyLinkErrorConstructor::getConstructData): Deleted. (JSC::WebAssemblyLinkErrorConstructor::getCallData): Deleted. * wasm/js/WebAssemblyLinkErrorConstructor.h: * wasm/js/WebAssemblyMemoryConstructor.cpp: (JSC::WebAssemblyMemoryConstructor::createStructure): (JSC::WebAssemblyMemoryConstructor::WebAssemblyMemoryConstructor): (JSC::WebAssemblyMemoryConstructor::getConstructData): Deleted. (JSC::WebAssemblyMemoryConstructor::getCallData): Deleted. * wasm/js/WebAssemblyMemoryConstructor.h: * wasm/js/WebAssemblyModuleConstructor.cpp: (JSC::WebAssemblyModuleConstructor::createStructure): (JSC::WebAssemblyModuleConstructor::WebAssemblyModuleConstructor): (JSC::WebAssemblyModuleConstructor::getConstructData): Deleted. (JSC::WebAssemblyModuleConstructor::getCallData): Deleted. * wasm/js/WebAssemblyModuleConstructor.h: * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp: (JSC::WebAssemblyRuntimeErrorConstructor::createStructure): (JSC::WebAssemblyRuntimeErrorConstructor::WebAssemblyRuntimeErrorConstructor): (JSC::WebAssemblyRuntimeErrorConstructor::getConstructData): Deleted. (JSC::WebAssemblyRuntimeErrorConstructor::getCallData): Deleted. * wasm/js/WebAssemblyRuntimeErrorConstructor.h: * wasm/js/WebAssemblyTableConstructor.cpp: (JSC::WebAssemblyTableConstructor::createStructure): (JSC::WebAssemblyTableConstructor::WebAssemblyTableConstructor): (JSC::WebAssemblyTableConstructor::getConstructData): Deleted. (JSC::WebAssemblyTableConstructor::getCallData): Deleted. * wasm/js/WebAssemblyTableConstructor.h: 2017-11-03 Michael Saboff The Abstract Interpreter needs to change similar to clobberize() in r224366 https://bugs.webkit.org/show_bug.cgi?id=179267 Reviewed by Saam Barati. Add clobberWorld() to HasGenericProperty, HasStructureProperty & GetPropertyEnumerator cases in the abstract interpreter to match what was done for r224366. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): 2017-11-03 Keith Miller PutProperytSlot should inform the IC about the property before effects. https://bugs.webkit.org/show_bug.cgi?id=179262 Reviewed by Mark Lam. This patch fixes an issue where we choose to cache setters based on incorrect information. If we did so we might end up OSR exiting more than we would otherwise need to. The new model is that the PutPropertySlot should inform the IC of what the property looked like before any potential side effects might have occurred. * runtime/JSObject.cpp: (JSC::JSObject::putInlineSlow): * runtime/Lookup.h: (JSC::putEntry): 2017-11-03 Mark Lam CachedCall (and its clients) needs overflow checks. https://bugs.webkit.org/show_bug.cgi?id=179185 Reviewed by JF Bastien. * interpreter/CachedCall.h: (JSC::CachedCall::CachedCall): (JSC::CachedCall::hasOverflowedArguments): * runtime/ArgList.h: (JSC::MarkedArgumentBuffer::clear): * runtime/StringPrototype.cpp: (JSC::replaceUsingRegExpSearch): 2017-11-03 Devin Rousso Web Inspector: Canvas2D Profiling: highlight expensive context commands in the captured command log https://bugs.webkit.org/show_bug.cgi?id=178302 Reviewed by Brian Burg. * inspector/protocol/Recording.json: Add `duration` to each Frame that represents the total time of all the recorded actions. 2017-11-02 Devin Rousso Web Inspector: Canvas Tab: show supported GL extensions for selected canvas https://bugs.webkit.org/show_bug.cgi?id=179070 Reviewed by Brian Burg. * inspector/protocol/Canvas.json: Add `extensionEnabled` event that is fired each time `getExtension` is called with a different string on a WebGL context. 2017-11-02 Joseph Pecoraro Make ServiceWorker a Remote Inspector debuggable target https://bugs.webkit.org/show_bug.cgi?id=179043 Reviewed by Brian Burg. * inspector/remote/RemoteControllableTarget.h: * inspector/remote/RemoteInspectionTarget.h: * inspector/remote/RemoteInspectorConstants.h: Include a new ServiceWorker remote inspector target type. * inspector/remote/cocoa/RemoteInspectorCocoa.mm: (Inspector::RemoteInspector::listingForInspectionTarget const): Implement listing for a ServiceWorker to include a URL like a page. * inspector/remote/glib/RemoteInspectorGlib.cpp: (Inspector::RemoteInspector::listingForInspectionTarget const): Bail for ServiceWorker support in glib. They will need to implement their support. 2017-11-02 Michael Saboff DFG needs to handle code motion of code in for..in loop bodies https://bugs.webkit.org/show_bug.cgi?id=179212 Reviewed by Keith Miller. The processing of the DFG nodes HasGenericProperty, HasStructureProperty & GetPropertyEnumerator make calls with side effects. Updated clobberize() for those nodes to take that into account. * dfg/DFGClobberize.h: (JSC::DFG::clobberize): 2017-11-02 Joseph Pecoraro Inspector should display service worker served responses properly https://bugs.webkit.org/show_bug.cgi?id=178597 Reviewed by Brian Burg. * inspector/protocol/Network.json: Expose a new "service-worker" response source. 2017-11-02 Filip Pizlo AI does not correctly model the clobber case of ArithClz32 https://bugs.webkit.org/show_bug.cgi?id=179188 Reviewed by Michael Saboff. The non-Int32 case clobbers the world because it may call valueOf. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): 2017-11-02 Yusuke Suzuki Unreviewed, release throw scope https://bugs.webkit.org/show_bug.cgi?id=178726 * dfg/DFGOperations.cpp: 2017-11-02 Frederic Wang Add references to bug 179167 in FIXME comments https://bugs.webkit.org/show_bug.cgi?id=179168 Reviewed by Daniel Bates. * Configurations/FeatureDefines.xcconfig: 2017-11-01 Jeremy Jones Implement WKFullscreenWindowController for iOS. https://bugs.webkit.org/show_bug.cgi?id=178924 rdar://problem/34697120 Reviewed by Simon Fraser. Enable ENABLE_FULLSCREEN_API for iOS. * Configurations/FeatureDefines.xcconfig: 2017-11-01 Mark Lam Add support to throw OOM if MarkedArgumentBuffer may overflow. https://bugs.webkit.org/show_bug.cgi?id=179092 Reviewed by Saam Barati. The test for overflowing a MarkedArgumentBuffer will run for a ridiculously long time, which renders it unsuitable for automated tests. Instead, I've run a test manually to verify that an OutOfMemoryError will be thrown when an overflow occurs. The MarkedArgumentBuffer's destructor will now assert that the client has indeed checked for an overflow after invoking methods that may result in an overflow i.e. the destructor checks that MarkedArgumentBuffer::hasOverflowed() has been called. This is only done on debug builds. * API/JSObjectRef.cpp: (JSObjectMakeFunction): (JSObjectMakeArray): (JSObjectMakeDate): (JSObjectMakeRegExp): (JSObjectCallAsFunction): (JSObjectCallAsConstructor): * dfg/DFGOperations.cpp: * inspector/InjectedScriptManager.cpp: (Inspector::InjectedScriptManager::createInjectedScript): * inspector/JSJavaScriptCallFrame.cpp: (Inspector::JSJavaScriptCallFrame::scopeChain const): * interpreter/Interpreter.cpp: (JSC::Interpreter::executeProgram): * jsc.cpp: (functionDollarAgentReceiveBroadcast): * runtime/ArgList.cpp: (JSC::MarkedArgumentBuffer::slowEnsureCapacity): (JSC::MarkedArgumentBuffer::expandCapacity): (JSC::MarkedArgumentBuffer::slowAppend): * runtime/ArgList.h: (JSC::MarkedArgumentBuffer::~MarkedArgumentBuffer): (JSC::MarkedArgumentBuffer::appendWithAction): (JSC::MarkedArgumentBuffer::append): (JSC::MarkedArgumentBuffer::appendWithCrashOnOverflow): (JSC::MarkedArgumentBuffer::hasOverflowed): (JSC::MarkedArgumentBuffer::setNeedsOverflowCheck): (JSC::MarkedArgumentBuffer::clearNeedsOverflowCheck): * runtime/ArrayPrototype.cpp: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/GetterSetter.cpp: (JSC::callSetter): * runtime/IteratorOperations.cpp: (JSC::iteratorNext): (JSC::iteratorClose): * runtime/JSBoundFunction.cpp: (JSC::boundThisNoArgsFunctionCall): (JSC::boundFunctionCall): (JSC::boundThisNoArgsFunctionConstruct): (JSC::boundFunctionConstruct): * runtime/JSGenericTypedArrayViewConstructorInlines.h: (JSC::constructGenericTypedArrayViewFromIterator): * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: (JSC::genericTypedArrayViewProtoFuncSlice): (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::haveABadTime): * runtime/JSInternalPromise.cpp: (JSC::JSInternalPromise::then): * runtime/JSJob.cpp: (JSC::JSJobMicrotask::run): * runtime/JSMapIterator.cpp: (JSC::JSMapIterator::createPair): * runtime/JSModuleLoader.cpp: (JSC::JSModuleLoader::provideFetch): (JSC::JSModuleLoader::loadAndEvaluateModule): (JSC::JSModuleLoader::loadModule): (JSC::JSModuleLoader::linkAndEvaluateModule): (JSC::JSModuleLoader::requestImportModule): * runtime/JSONObject.cpp: (JSC::Stringifier::toJSONImpl): (JSC::Stringifier::appendStringifiedValue): (JSC::Walker::callReviver): * runtime/JSObject.cpp: (JSC::ordinarySetSlow): (JSC::callToPrimitiveFunction): (JSC::JSObject::hasInstance): * runtime/JSPromise.cpp: (JSC::JSPromise::initialize): (JSC::JSPromise::resolve): * runtime/JSPromiseDeferred.cpp: (JSC::newPromiseCapability): (JSC::callFunction): * runtime/JSSetIterator.cpp: (JSC::JSSetIterator::createPair): * runtime/LiteralParser.cpp: (JSC::LiteralParser::parse): * runtime/MapConstructor.cpp: (JSC::constructMap): * runtime/ObjectConstructor.cpp: (JSC::defineProperties): * runtime/ProxyObject.cpp: (JSC::performProxyGet): (JSC::ProxyObject::performInternalMethodGetOwnProperty): (JSC::ProxyObject::performHasProperty): (JSC::ProxyObject::performPut): (JSC::performProxyCall): (JSC::performProxyConstruct): (JSC::ProxyObject::performDelete): (JSC::ProxyObject::performPreventExtensions): (JSC::ProxyObject::performIsExtensible): (JSC::ProxyObject::performDefineOwnProperty): (JSC::ProxyObject::performGetOwnPropertyNames): (JSC::ProxyObject::performSetPrototype): (JSC::ProxyObject::performGetPrototype): * runtime/ReflectObject.cpp: (JSC::reflectObjectConstruct): * runtime/SetConstructor.cpp: (JSC::constructSet): * runtime/StringPrototype.cpp: (JSC::replaceUsingRegExpSearch): (JSC::replaceUsingStringSearch): * runtime/WeakMapConstructor.cpp: (JSC::constructWeakMap): * runtime/WeakSetConstructor.cpp: (JSC::constructWeakSet): * wasm/js/WasmToJS.cpp: (JSC::Wasm::wasmToJS): 2017-11-01 Michael Saboff Integer overflow in code generated by LoadVarargs processing in DFG and FTL. https://bugs.webkit.org/show_bug.cgi?id=179140 Reviewed by Saam Barati. Added overflow checks to computation of arg count plus this. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileLoadVarargs): 2017-11-01 Yusuke Suzuki Unreviewed, use weakPointer instead of FTLOutput::weakPointer https://bugs.webkit.org/show_bug.cgi?id=178934 * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileStringSlice): 2017-11-01 Yusuke Suzuki [JSC] Introduce @toObject https://bugs.webkit.org/show_bug.cgi?id=178726 Reviewed by Saam Barati. This patch introduces @toObject intrinsic. And we introduce op_to_object bytecode and DFG ToObject node. Previously we emulated @toObject behavior in builtin JS. But it consumes much bytecode size while @toObject is frequently seen and defined clearly in the spec. Furthermore, the emulated @toObject always calls ObjectConstructor in LLInt and Baseline. We add a new intrinsic `@toObject(target, "error message")`. It takes an error message string constant to offer understandable messages in builtin JS. We can change the frequently seen "emulated ToObject" operation if (this === @undefined || this === null) @throwTypeError("error message"); var object = @Object(this); with var object = @toObject(this, "error message"); And we handle op_to_object in DFG as ToObject node. While CallObjectConstructor does not throw an error for null/undefined, ToObject needs to throw an error for null/undefined. So it is marked as MustGenerate and it clobbers the world. In fixup phase, we attempt to convert ToObject to CallObjectConstructor with edge filters to relax its side effect. It also fixes a bug that CallObjectConstructor DFG node uses Node's semantic GlobalObject instead of function's one. * builtins/ArrayConstructor.js: (from): * builtins/ArrayPrototype.js: (values): (keys): (entries): (reduce): (reduceRight): (every): (forEach): (filter): (map): (some): (fill): (find): (findIndex): (includes): (sort): (globalPrivate.concatSlowPath): (copyWithin): * builtins/DatePrototype.js: (toLocaleString.toDateTimeOptionsAnyAll): (toLocaleString): (toLocaleDateString.toDateTimeOptionsDateDate): (toLocaleDateString): (toLocaleTimeString.toDateTimeOptionsTimeTime): (toLocaleTimeString): * builtins/GlobalOperations.js: (globalPrivate.copyDataProperties): (globalPrivate.copyDataPropertiesNoExclusions): * builtins/ObjectConstructor.js: (entries): * builtins/StringConstructor.js: (raw): * builtins/TypedArrayConstructor.js: (from): * builtins/TypedArrayPrototype.js: (map): (filter): * bytecode/BytecodeDumper.cpp: (JSC::BytecodeDumper::dumpBytecode): * bytecode/BytecodeIntrinsicRegistry.h: * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitToObject): * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::BytecodeIntrinsicNode::emit_intrinsic_toObject): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleConstantInternalFunction): (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::fixupToObject): (JSC::DFG::FixupPhase::fixupCallObjectConstructor): * dfg/DFGNode.h: (JSC::DFG::Node::convertToCallObjectConstructor): (JSC::DFG::Node::convertToNewStringObject): (JSC::DFG::Node::convertToNewObject): (JSC::DFG::Node::hasIdentifier): (JSC::DFG::Node::hasHeapPrediction): (JSC::DFG::Node::hasCellOperand): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileToObjectOrCallObjectConstructor): (JSC::DFG::SpeculativeJIT::compileCallObjectConstructor): Deleted. * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * 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::compileToObjectOrCallObjectConstructor): (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor): Deleted. * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): * jit/JIT.h: * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_to_object): (JSC::JIT::emitSlow_op_to_object): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_to_object): (JSC::JIT::emitSlow_op_to_object): * jit/JITOperations.cpp: * jit/JITOperations.h: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: 2017-11-01 Fujii Hironori Use LazyNeverDestroyed instead of DEFINE_GLOBAL https://bugs.webkit.org/show_bug.cgi?id=174979 Reviewed by Yusuke Suzuki. * config.h: Removed definitions of SKIP_STATIC_CONSTRUCTORS_ON_MSVC and SKIP_STATIC_CONSTRUCTORS_ON_GCC. 2017-10-27 Yusuke Suzuki [DFG][FTL] Introduce StringSlice https://bugs.webkit.org/show_bug.cgi?id=178934 Reviewed by Saam Barati. String.prototype.slice is one of the most frequently called function in ARES-6/Babylon. This patch introduces StringSlice DFG node to optimize it in DFG and FTL. This patch's StringSlice node optimizes the following things. 1. Empty string generation is accelerated. It is fully executed inline. 2. One char string generation is accelerated. `< 0x100` character is supported right now. It is the same to charAt acceleration. 3. We calculate start and end index in DFG/FTL with Int32Use information and call optimized operation. We do not inline (3)'s operation right now since we do not have a way to call bmalloc allocation from DFG / FTL. And we do not optimize String.prototype.{substring,substr} right now. But they can be optimized based on this change in subsequent changes. This patch improves ARES-6/Babylon performance by 3% in steady state. Baseline: Running... Babylon ( 1 to go) firstIteration: 50.05 +- 13.68 ms averageWorstCase: 16.80 +- 1.27 ms steadyState: 7.53 +- 0.22 ms Patched: Running... Babylon ( 1 to go) firstIteration: 50.91 +- 13.41 ms averageWorstCase: 16.12 +- 0.99 ms steadyState: 7.30 +- 0.29 ms * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGBackwardsPropagationPhase.cpp: (JSC::DFG::BackwardsPropagationPhase::propagate): * 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::compileStringSlice): (JSC::DFG::SpeculativeJIT::emitPopulateSliceIndex): (JSC::DFG::SpeculativeJIT::compileArraySlice): (JSC::DFG::SpeculativeJIT::compileArrayIndexOf): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * 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::populateSliceRange): (JSC::FTL::DFG::LowerDFGToB3::compileArraySlice): (JSC::FTL::DFG::LowerDFGToB3::compileStringSlice): * jit/JITOperations.h: * runtime/Intrinsic.cpp: (JSC::intrinsicName): * runtime/Intrinsic.h: * runtime/StringPrototype.cpp: (JSC::StringPrototype::finishCreation): 2017-10-31 JF Bastien WebAssembly: Wasm::IndexOrName has a raw pointer to Name https://bugs.webkit.org/show_bug.cgi?id=176644 Reviewed by Michael Saboff. IndexOrName now keeps a RefPtr to its original NameSection, which holds the Name (or references nullptr if Index). Holding onto the entire section seems like the better thing to do, since backtraces probably contain multiple names from the same Module. * JavaScriptCore.xcodeproj/project.pbxproj: * interpreter/Interpreter.cpp: (JSC::GetStackTraceFunctor::operator() const): * interpreter/StackVisitor.h: Frame is no longer POD because of the RefPtr. * runtime/StackFrame.cpp: (JSC::StackFrame::StackFrame): * runtime/StackFrame.h: Drop the union, size is now 40 bytes. (JSC::StackFrame::StackFrame): Deleted. Initialized in class instead. (JSC::StackFrame::wasm): Deleted. Make it a ctor instead. * wasm/WasmBBQPlanInlines.h: (JSC::Wasm::BBQPlan::initializeCallees): * wasm/WasmCallee.cpp: (JSC::Wasm::Callee::Callee): * wasm/WasmCallee.h: (JSC::Wasm::Callee::create): * wasm/WasmFormat.h: Move NameSection to its own header. (JSC::Wasm::isValidNameType): (JSC::Wasm::NameSection::get): Deleted. * wasm/WasmIndexOrName.cpp: (JSC::Wasm::IndexOrName::IndexOrName): (JSC::Wasm::makeString): * wasm/WasmIndexOrName.h: (JSC::Wasm::IndexOrName::IndexOrName): (JSC::Wasm::IndexOrName::isEmpty const): (JSC::Wasm::IndexOrName::isIndex const): * wasm/WasmModuleInformation.cpp: (JSC::Wasm::ModuleInformation::ModuleInformation): * wasm/WasmModuleInformation.h: (JSC::Wasm::ModuleInformation::ModuleInformation): Deleted. * wasm/WasmNameSection.h: (JSC::Wasm::NameSection::get): (JSC::Wasm::NameSection::create): Deleted. * wasm/WasmNameSectionParser.cpp: (JSC::Wasm::NameSectionParser::parse): * wasm/WasmNameSectionParser.h: * wasm/WasmOMGPlan.cpp: (JSC::Wasm::OMGPlan::work): 2017-10-31 Tim Horton Clean up some drag and drop feature flags https://bugs.webkit.org/show_bug.cgi?id=179082 Reviewed by Simon Fraser. * Configurations/FeatureDefines.xcconfig: 2017-10-31 Commit Queue Unreviewed, rolling out r224243, r224246, and r224248. https://bugs.webkit.org/show_bug.cgi?id=179083 The patch and fix broke the Windows build. (Requested by mlewis13 on #webkit). Reverted changesets: "StructureStubInfo should have GPRReg members not int8_ts" https://bugs.webkit.org/show_bug.cgi?id=179071 https://trac.webkit.org/changeset/224243 "Make all register enums be backed by uint8_t." https://bugs.webkit.org/show_bug.cgi?id=179074 https://trac.webkit.org/changeset/224246 "Unreviewed, windows build fix." https://trac.webkit.org/changeset/224248 2017-10-31 Tim Horton Fix up some content filtering feature flags https://bugs.webkit.org/show_bug.cgi?id=179079 Reviewed by Simon Fraser. * Configurations/FeatureDefines.xcconfig: 2017-10-31 Keith Miller Unreviewed, windows build fix. * assembler/X86Assembler.h: (JSC::X86Assembler::numberOfRegisters): (JSC::X86Assembler::numberOfSPRegisters): (JSC::X86Assembler::numberOfFPRegisters): 2017-10-31 Keith Miller Make all register enums be backed by uint8_t. https://bugs.webkit.org/show_bug.cgi?id=179074 Reviewed by Mark Lam. * assembler/ARM64Assembler.h: * assembler/ARMAssembler.h: * assembler/ARMv7Assembler.h: * assembler/MIPSAssembler.h: * assembler/MacroAssembler.h: * assembler/X86Assembler.h: 2017-10-31 Keith Miller StructureStubInfo should have GPRReg members not int8_ts https://bugs.webkit.org/show_bug.cgi?id=179071 Reviewed by Michael Saboff. This patch makes the various RegisterID enums be backed by uint8_t. This means that we can remove the old int8_t members in StructureStubInfo and replace them with the correct enum types. Also, this fixes an indentation issue in ARMv7Assembler.h. * assembler/ARM64Assembler.h: * assembler/ARMAssembler.h: * assembler/ARMv7Assembler.h: (JSC::ARMRegisters::asSingle): (JSC::ARMRegisters::asDouble): * assembler/MIPSAssembler.h: * assembler/X86Assembler.h: * bytecode/InlineAccess.cpp: (JSC::InlineAccess::generateSelfPropertyAccess): (JSC::getScratchRegister): * bytecode/PolymorphicAccess.cpp: (JSC::PolymorphicAccess::regenerate): * bytecode/StructureStubInfo.h: (JSC::StructureStubInfo::valueRegs const): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileIn): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileIn): * jit/JITInlineCacheGenerator.cpp: (JSC::JITByIdGenerator::JITByIdGenerator): (JSC::JITGetByIdWithThisGenerator::JITGetByIdWithThisGenerator): 2017-10-31 Devin Rousso Web Inspector: make ScriptCallStack::maxCallStackSizeToCapture the default value when capturing backtraces https://bugs.webkit.org/show_bug.cgi?id=179048 Reviewed by Mark Lam. * inspector/ScriptCallStackFactory.h: * inspector/ScriptCallStackFactory.cpp: (createScriptCallStack): (createScriptCallStackForConsole): (createScriptCallStackFromException): * inspector/ConsoleMessage.cpp: (Inspector::ConsoleMessage::autogenerateMetadata): * inspector/JSGlobalObjectInspectorController.cpp: (Inspector::JSGlobalObjectInspectorController::reportAPIException): * inspector/agents/InspectorConsoleAgent.cpp: (Inspector::InspectorConsoleAgent::count): * inspector/agents/JSGlobalObjectDebuggerAgent.cpp: (Inspector::JSGlobalObjectDebuggerAgent::breakpointActionLog): 2017-10-31 Carlos Garcia Campos Unreviewed. Fix GTK+ make distcheck. Ensure DERIVED_SOURCES_JAVASCRIPTCORE_DIR/yarr is created before scripts generating files there are run. * CMakeLists.txt: 2017-10-30 Saam Barati We need a storeStoreFence before storing to the instruction stream's live variable catch data https://bugs.webkit.org/show_bug.cgi?id=178649 Reviewed by Keith Miller. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffsetSlow): 2017-10-30 Michael Catanzaro [WPE] Fix build warnings https://bugs.webkit.org/show_bug.cgi?id=178899 Reviewed by Carlos Alberto Lopez Perez. * PlatformWPE.cmake: 2017-10-30 Zan Dobersek [ARMv7] Fix initial start register support in YarrJIT https://bugs.webkit.org/show_bug.cgi?id=178641 Reviewed by Saam Barati. * yarr/YarrJIT.cpp: On ARMv7, use r8 as the initialStart register in the YarrGenerator class. r6 should be avoided since it's already used inside MacroAssemblerARMv7 as addressTempRegister. r7 isn't picked because it can be used as the frame pointer register when targetting ARM Thumb2. 2017-10-30 Zan Dobersek [ARM64][Linux] Re-enable Gigacage https://bugs.webkit.org/show_bug.cgi?id=178130 Reviewed by Michael Catanzaro. Guard the current globaladdr opcode implementation for ARM64 with OS(DARWIN) as it's only usable for Mach-O. For OS(LINUX), ELF-supported :got: and :got_lo12: relocation specifiers have to be used. The .loh directive can't be used as it's not supported in GCC or the ld linker. On every other OS target, a compilation error is thrown. * offlineasm/arm64.rb: 2017-10-27 Devin Rousso Web Inspector: Canvas Tab: no way to see backtrace of where a canvas context was created https://bugs.webkit.org/show_bug.cgi?id=178799 Reviewed by Brian Burg. * inspector/protocol/Canvas.json: Add optional `backtrace` to Canvas type that is an array of Console.CallFrame. 2017-10-27 Yusuke Suzuki [JSC] Tweak ES6 generator function to allow inlining https://bugs.webkit.org/show_bug.cgi?id=178935 Reviewed by Saam Barati. We optimize builtins' generator helper functions to allow them inlined in the caller side. This patch adjust the layer between @generatorResume, next(), throw(), and return() to allow them inlined in DFG. baseline patched spread-generator.es6 301.2637+-11.1011 ^ 260.5905+-14.2258 ^ definitely 1.1561x faster generator.es6 269.6030+-13.2435 ^ 148.8840+-6.7614 ^ definitely 1.8108x faster * builtins/GeneratorPrototype.js: (globalPrivate.generatorResume): (next): (return): (throw): 2017-10-27 Saam Barati Bytecode liveness should live on UnlinkedCodeBlock so it can be shared amongst CodeBlocks https://bugs.webkit.org/show_bug.cgi?id=178949 Reviewed by Keith Miller. This patch stores BytecodeLiveness on UnlinkedCodeBlock instead of CodeBlock so that we don't need to recompute liveness for the same UnlinkedCodeBlock more than once. To do this, this patch solidifies the invariant that CodeBlock linking can't do anything that would change the result of liveness. For example, it can't introduce new locals. This invariant was met my JSC before, because we didn't do anything in bytecode linking that would change liveness. However, it is now a correctness requirement that we don't do anything that would change the result of running liveness. To support this change, I've refactored BytecodeGraph to not be tied to a CodeBlockType*. Things that perform liveness will pass in CodeBlockType* and the instruction stream as needed. This means that we may compute liveness with one CodeBlock*'s instruction stream, and then perform queries on that analysis with a different CodeBlock*'s instruction stream. This seems to be a 2% JSBench progression. * bytecode/BytecodeGeneratorification.cpp: (JSC::BytecodeGeneratorification::BytecodeGeneratorification): (JSC::BytecodeGeneratorification::graph): (JSC::BytecodeGeneratorification::storageForGeneratorLocal): (JSC::GeneratorLivenessAnalysis::run): (JSC::BytecodeGeneratorification::run): * bytecode/BytecodeGraph.h: (JSC::BytecodeGraph::BytecodeGraph): (JSC::BytecodeGraph::codeBlock const): Deleted. (JSC::BytecodeGraph::instructions): Deleted. (JSC::BytecodeGraph::BytecodeGraph): Deleted. * bytecode/BytecodeLivenessAnalysis.cpp: (JSC::BytecodeLivenessAnalysis::BytecodeLivenessAnalysis): (JSC::BytecodeLivenessAnalysis::getLivenessInfoAtBytecodeOffset): (JSC::BytecodeLivenessAnalysis::computeFullLiveness): (JSC::BytecodeLivenessAnalysis::computeKills): (JSC::BytecodeLivenessAnalysis::dumpResults): (JSC::BytecodeLivenessAnalysis::operandIsLiveAtBytecodeOffset): Deleted. (JSC::BytecodeLivenessAnalysis::compute): Deleted. * bytecode/BytecodeLivenessAnalysis.h: * bytecode/BytecodeLivenessAnalysisInlines.h: (JSC::BytecodeLivenessPropagation::stepOverInstruction): (JSC::BytecodeLivenessPropagation::computeLocalLivenessForBytecodeOffset): (JSC::BytecodeLivenessPropagation::computeLocalLivenessForBlock): (JSC::BytecodeLivenessPropagation::getLivenessInfoAtBytecodeOffset): (JSC::BytecodeLivenessPropagation::runLivenessFixpoint): * bytecode/BytecodeRewriter.cpp: (JSC::BytecodeRewriter::applyModification): (JSC::BytecodeRewriter::execute): (JSC::BytecodeRewriter::adjustJumpTargetsInFragment): * bytecode/BytecodeRewriter.h: (JSC::BytecodeRewriter::BytecodeRewriter): (JSC::BytecodeRewriter::removeBytecode): (JSC::BytecodeRewriter::graph): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): (JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffsetSlow): (JSC::CodeBlock::validate): (JSC::CodeBlock::livenessAnalysisSlow): Deleted. * bytecode/CodeBlock.h: (JSC::CodeBlock::livenessAnalysis): * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::applyModification): (JSC::UnlinkedCodeBlock::livenessAnalysisSlow): * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedCodeBlock::livenessAnalysis): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::livenessFor): (JSC::DFG::Graph::killsFor): * dfg/DFGPlan.cpp: (JSC::DFG::Plan::cleanMustHandleValuesIfNecessary): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): 2017-10-27 Keith Miller Add unified source list files and build scripts to Xcode project navigator https://bugs.webkit.org/show_bug.cgi?id=178959 Reviewed by Andy Estes. Also, Add some extra source files for so new .cpp/.mm files don't cause the build to fail right away. We already do this in WebCore. * JavaScriptCore.xcodeproj/project.pbxproj: * PlatformMac.cmake: * SourcesCocoa.txt: Renamed from Source/JavaScriptCore/SourcesMac.txt. 2017-10-27 JF Bastien WebAssembly: update arbitrary limits to what browsers use https://bugs.webkit.org/show_bug.cgi?id=178946 Reviewed by Saam Barati. https://github.com/WebAssembly/design/issues/1138 discusses the arbitrary function size limit, which it turns out Chrome and Firefox didn't enforce. We didn't use it because it was ridiculously low and actual programs ran into that limit (bummer for Edge which just shipped it...). Now that we agree on a high arbitrary program limit, let's update it! While I'm doing this there are a few other spots that I polished to use Checked or better check limits overall. * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::addLocal): * wasm/WasmFormat.cpp: (JSC::Wasm::Segment::create): * wasm/WasmFunctionParser.h: (JSC::Wasm::FunctionParser::parse): * wasm/WasmInstance.cpp: * wasm/WasmLimits.h: * wasm/WasmModuleParser.cpp: (JSC::Wasm::ModuleParser::parseGlobal): (JSC::Wasm::ModuleParser::parseCode): (JSC::Wasm::ModuleParser::parseData): * wasm/WasmSignature.h: (JSC::Wasm::Signature::allocatedSize): * wasm/WasmTable.cpp: (JSC::Wasm::Table::Table): * wasm/js/JSWebAssemblyTable.cpp: (JSC::JSWebAssemblyTable::JSWebAssemblyTable): (JSC::JSWebAssemblyTable::grow): 2017-10-26 Michael Saboff REGRESSION(r222601): We fail to properly backtrack into a sub pattern of a parenthesis with non-zero minimum https://bugs.webkit.org/show_bug.cgi?id=178890 Reviewed by Keith Miller. We need to let a contained subpattern backtrack before declaring that the containing parenthesis doesn't match. If the subpattern fails to match backtracking, then we can check to see if we trying to backtrack below the minimum match count. * yarr/YarrInterpreter.cpp: (JSC::Yarr::Interpreter::backtrackParentheses): 2017-10-26 Mark Lam JSRopeString::RopeBuilder::append() should check for overflows. https://bugs.webkit.org/show_bug.cgi?id=178385 Reviewed by Saam Barati. 1. Made RopeString check for overflow like the Checked class does. 2. Added a missing overflow check in objectProtoFuncToString(). * runtime/JSString.cpp: (JSC::JSRopeString::RopeBuilder::expand): (JSC::JSRopeString::RopeBuilder::expand): Deleted. * runtime/JSString.h: * runtime/ObjectPrototype.cpp: (JSC::objectProtoFuncToString): * runtime/Operations.h: (JSC::jsStringFromRegisterArray): (JSC::jsStringFromArguments): 2017-10-26 JF Bastien WebAssembly: no VM / JS version of our implementation https://bugs.webkit.org/show_bug.cgi?id=177472 Reviewed by Michael Saboff. This patch removes all appearances of "JS" and "VM" in the wasm directory. These now only appear in the wasm/js directory, which is only used in a JS embedding of wasm. It should therefore now be possible to create non-JS embeddings of wasm through JSC, though it'll still require: - Mild codegen for wasm<->embedder calls; - A strategy for trap handling (no need for full unwind! Could kill). - Creation of the Wasm::* objects. - Calling convention handling to call the embedder. - Handling of multiple embedders (see #177475, this is optional). Most of the patch consists in renaming JSWebAssemblyInstance to Instance, and removing temporary copies which I'd added to make this specific patch very simple. * interpreter/CallFrame.cpp: (JSC::CallFrame::wasmAwareLexicalGlobalObject): this one place which needs to know about who "owns" the Wasm::Instance. In a JS embedding it's the JSWebAssemblyInstance. * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState): (JSC::Wasm::B3IRGenerator::addGrowMemory): (JSC::Wasm::B3IRGenerator::addCurrentMemory): (JSC::Wasm::B3IRGenerator::getGlobal): (JSC::Wasm::B3IRGenerator::setGlobal): (JSC::Wasm::B3IRGenerator::addCall): (JSC::Wasm::B3IRGenerator::addCallIndirect): * wasm/WasmBinding.cpp: (JSC::Wasm::wasmToWasm): * wasm/WasmContext.cpp: (JSC::Wasm::Context::load const): (JSC::Wasm::Context::store): * wasm/WasmContext.h: * wasm/WasmEmbedder.h: * wasm/WasmInstance.cpp: (JSC::Wasm::Instance::Instance): (JSC::Wasm::Instance::create): (JSC::Wasm::Instance::extraMemoryAllocated const): * wasm/WasmInstance.h: add an "owner", the Wasm::Context, move the "tail" import information from JSWebAssemblyInstance over to here. (JSC::Wasm::Instance::finalizeCreation): (JSC::Wasm::Instance::owner const): (JSC::Wasm::Instance::offsetOfOwner): (JSC::Wasm::Instance::context const): (JSC::Wasm::Instance::setMemory): (JSC::Wasm::Instance::setTable): (JSC::Wasm::Instance::offsetOfMemory): (JSC::Wasm::Instance::offsetOfGlobals): (JSC::Wasm::Instance::offsetOfTable): (JSC::Wasm::Instance::offsetOfTail): (JSC::Wasm::Instance::numImportFunctions const): (JSC::Wasm::Instance::importFunctionInfo): (JSC::Wasm::Instance::offsetOfTargetInstance): (JSC::Wasm::Instance::offsetOfWasmEntrypoint): (JSC::Wasm::Instance::offsetOfWasmToEmbedderStubExecutableAddress): (JSC::Wasm::Instance::offsetOfImportFunction): (JSC::Wasm::Instance::importFunction): (JSC::Wasm::Instance::allocationSize): (JSC::Wasm::Instance::create): Deleted. * wasm/WasmOMGPlan.cpp: (JSC::Wasm::OMGPlan::runForIndex): * wasm/WasmOMGPlan.h: * wasm/WasmTable.cpp: (JSC::Wasm::Table::Table): (JSC::Wasm::Table::setFunction): * wasm/WasmTable.h: * wasm/WasmThunks.cpp: (JSC::Wasm::throwExceptionFromWasmThunkGenerator): (JSC::Wasm::triggerOMGTierUpThunkGenerator): * wasm/js/JSToWasm.cpp: (JSC::Wasm::createJSToWasmWrapper): * wasm/js/JSWebAssemblyInstance.cpp: delete code that is now on Wasm::Instance (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance): The embedder decides what the import function is. Here we must properly placement-new it to what we've elected (and initialize it later). (JSC::JSWebAssemblyInstance::visitChildren): (JSC::JSWebAssemblyInstance::finalizeCreation): (JSC::JSWebAssemblyInstance::create): * wasm/js/JSWebAssemblyInstance.h: delete code that is now on Wasm::Instance (JSC::JSWebAssemblyInstance::instance): (JSC::JSWebAssemblyInstance::moduleNamespaceObject): (JSC::JSWebAssemblyInstance::setMemory): (JSC::JSWebAssemblyInstance::table): (JSC::JSWebAssemblyInstance::setTable): (JSC::JSWebAssemblyInstance::offsetOfInstance): (JSC::JSWebAssemblyInstance::offsetOfCallee): (JSC::JSWebAssemblyInstance::context const): Deleted. (JSC::JSWebAssemblyInstance::offsetOfTail): Deleted. (): Deleted. (JSC::JSWebAssemblyInstance::importFunctionInfo): Deleted. (JSC::JSWebAssemblyInstance::offsetOfTargetInstance): Deleted. (JSC::JSWebAssemblyInstance::offsetOfWasmEntrypoint): Deleted. (JSC::JSWebAssemblyInstance::offsetOfWasmToEmbedderStubExecutableAddress): Deleted. (JSC::JSWebAssemblyInstance::offsetOfImportFunction): Deleted. (JSC::JSWebAssemblyInstance::importFunction): Deleted. (JSC::JSWebAssemblyInstance::internalMemory): Deleted. (JSC::JSWebAssemblyInstance::wasmCodeBlock const): Deleted. (JSC::JSWebAssemblyInstance::offsetOfWasmTable): Deleted. (JSC::JSWebAssemblyInstance::offsetOfGlobals): Deleted. (JSC::JSWebAssemblyInstance::offsetOfCodeBlock): Deleted. (JSC::JSWebAssemblyInstance::offsetOfWasmCodeBlock): Deleted. (JSC::JSWebAssemblyInstance::offsetOfCachedStackLimit): Deleted. (JSC::JSWebAssemblyInstance::offsetOfWasmMemory): Deleted. (JSC::JSWebAssemblyInstance::offsetOfTopEntryFramePointer): Deleted. (JSC::JSWebAssemblyInstance::cachedStackLimit const): Deleted. (JSC::JSWebAssemblyInstance::setCachedStackLimit): Deleted. (JSC::JSWebAssemblyInstance::wasmMemory): Deleted. (JSC::JSWebAssemblyInstance::wasmModule): Deleted. (JSC::JSWebAssemblyInstance::allocationSize): Deleted. * wasm/js/JSWebAssemblyTable.cpp: (JSC::JSWebAssemblyTable::setFunction): * wasm/js/WasmToJS.cpp: One extra indirection to find the JSWebAssemblyInstance. (JSC::Wasm::materializeImportJSCell): (JSC::Wasm::handleBadI64Use): (JSC::Wasm::wasmToJS): (JSC::Wasm::wasmToJSException): * wasm/js/WasmToJS.h: * wasm/js/WebAssemblyFunction.cpp: (JSC::callWebAssemblyFunction): * wasm/js/WebAssemblyInstanceConstructor.cpp: (JSC::constructJSWebAssemblyInstance): * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::link): (JSC::WebAssemblyModuleRecord::evaluate): * wasm/js/WebAssemblyPrototype.cpp: (JSC::instantiate): * wasm/js/WebAssemblyWrapperFunction.cpp: (JSC::WebAssemblyWrapperFunction::create): 2017-10-25 Devin Rousso Web Inspector: provide a way to enable/disable event listeners https://bugs.webkit.org/show_bug.cgi?id=177451 Reviewed by Joseph Pecoraro. * inspector/protocol/DOM.json: Add `setEventListenerDisabled` command that enables/disables a specific event listener during event dispatch. When a disabled event listener is fired, the listener's callback will not be called. 2017-10-25 Commit Queue Unreviewed, rolling out r223691 and r223729. https://bugs.webkit.org/show_bug.cgi?id=178834 Broke Speedometer 2 React-Redux-TodoMVC test case (Requested by rniwa on #webkit). Reverted changesets: "Turn recursive tail calls into loops" https://bugs.webkit.org/show_bug.cgi?id=176601 https://trac.webkit.org/changeset/223691 "REGRESSION(r223691): DFGByteCodeParser.cpp:1483:83: warning: comparison is always false due to limited range of data type [-Wtype-limits]" https://bugs.webkit.org/show_bug.cgi?id=178543 https://trac.webkit.org/changeset/223729 2017-10-25 Michael Saboff REGRESSION(r223937): Use of -fobjc-weak causes build failures with older compilers https://bugs.webkit.org/show_bug.cgi?id=178825 Reviewed by Mark Lam. Enable ARC for ARM64_32. This eliminate the need for setting CLANG_ENABLE_OBJC_WEAK. * Configurations/ToolExecutable.xcconfig: 2017-10-25 Keith Miller Fix implicit cast of enum, which seems to break the windows build of unified sources. https://bugs.webkit.org/show_bug.cgi?id=178822 Reviewed by Saam Barati. * bytecode/DFGExitProfile.h: (JSC::DFG::FrequentExitSite::hash const): 2017-10-24 Michael Saboff Allow OjbC Weak References when building TestAPI https://bugs.webkit.org/show_bug.cgi?id=178748 Reviewed by Dan Bernstein. Set TestAPI build flag Weak References in Manual Retain Release to true. * JavaScriptCore.xcodeproj/project.pbxproj: Reverted. * Configurations/ToolExecutable.xcconfig: Changed the flag here instead. 2017-10-24 Eric Carlson Web Inspector: Enable WebKit logging configuration and display https://bugs.webkit.org/show_bug.cgi?id=177027 Reviewed by Joseph Pecoraro. * inspector/ConsoleMessage.cpp: (Inspector::messageSourceValue): Inspector::Protocol::Console::ConsoleMessage -> Inspector::Protocol::Console::ChannelSource. * inspector/agents/JSGlobalObjectConsoleAgent.cpp: (Inspector::JSGlobalObjectConsoleAgent::getLoggingChannels): There are no logging channels specific to a JSContext yet, so return an empty channel array. (Inspector::JSGlobalObjectConsoleAgent::setLoggingChannelLevel): No channels, return an error. * inspector/agents/JSGlobalObjectConsoleAgent.h: * inspector/protocol/Console.json: Add ChannelSource, ChannelLevel, and Channel. Add getLoggingChannels and setLoggingChannelLevel. * inspector/scripts/codegen/generator.py: Special case "webrtc"-> "WebRTC". * inspector/scripts/tests/generic/expected/enum-values.json-result: * inspector/scripts/tests/generic/expected/type-declaration-array-type.json-result: * inspector/scripts/tests/generic/expected/type-declaration-enum-type.json-result: * inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result: * inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result: * runtime/ConsoleTypes.h: Add Media and WebRTC. 2017-10-24 Michael Saboff Allow OjbC Weak References when building TestAPI https://bugs.webkit.org/show_bug.cgi?id=178748 Reviewed by Saam Barati. Set TestAPI build flag Weak References in Manual Retain Release to true. * JavaScriptCore.xcodeproj/project.pbxproj: 2017-10-24 Yusuke Suzuki [FTL] Support NewStringObject https://bugs.webkit.org/show_bug.cgi?id=178737 Reviewed by Saam Barati. FTL should support NewStringObject and encourage use of NewStringObject in DFG pipeline. After this change, we can convert `CallObjectConstructor(String)` to `NewStringObject(String)`. * ftl/FTLAbstractHeapRepository.h: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileNewStringObject): 2017-10-24 Guillaume Emont [mips] fix offsets of branches that have to go over a jump https://bugs.webkit.org/show_bug.cgi?id=153464 The jump() function creates 8 instructions, but the offsets of branches meant to go over them only account for 6. In most cases, this is not an issue as the last two instructions of jump() would be nops, but in the rarer case where the jump destination is in a different 256 MB segment, MIPSAssembler::linkWithOffset() will rewrite the code in a way in which the last 4 instructions would be a 2 instruction load (lui/ori) into $t9, a "j $t9" and then a nop. The wrong offset will mean that the previous branches meant to go over the whole jump will branch to the "j $t9" instruction, which would jump to whatever is currently in $t9 (since lui/ori would not be executed). Reviewed by Michael Catanzaro. * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::branchAdd32): (JSC::MacroAssemblerMIPS::branchMul32): (JSC::MacroAssemblerMIPS::branchSub32): Fix the offsets of branches meant to go over code generated by jump(). 2017-10-24 JF Bastien WebAssembly: NFC renames of things that aren't JS-specific https://bugs.webkit.org/show_bug.cgi?id=178738 Reviewed by Saam Barati. * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::parseAndCompile): * wasm/WasmB3IRGenerator.h: * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::complete): * wasm/WasmCodeBlock.cpp: (JSC::Wasm::CodeBlock::CodeBlock): * wasm/WasmCodeBlock.h: (JSC::Wasm::CodeBlock::embedderEntrypointCalleeFromFunctionIndexSpace): (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace): Deleted. * wasm/WasmFormat.h: * wasm/js/JSToWasm.cpp: (JSC::Wasm::createJSToWasmWrapper): * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::link): (JSC::WebAssemblyModuleRecord::evaluate): 2017-10-24 Stephan Szabo [Win][JSCOnly] Make jsconly build testapi and dlls and copy dlls when running tests https://bugs.webkit.org/show_bug.cgi?id=177279 Reviewed by Yusuke Suzuki. * shell/PlatformJSCOnly.cmake: Added. 2017-10-15 Yusuke Suzuki [JSC] modules can be visited more than once when resolving bindings through "star" exports as long as the exportName is different each time https://bugs.webkit.org/show_bug.cgi?id=178308 Reviewed by Mark Lam. With the change of the spec[1], we now do not need to remember star resolution modules. We reflect this change to our implementation. Since this change is covered by test262, this patch improves the score of test262. We also add logging to ResolveExport to debug it easily. [1]: https://github.com/tc39/ecma262/commit/a865e778ff0fc60e26e3e1c589635103710766a1 * runtime/AbstractModuleRecord.cpp: (JSC::AbstractModuleRecord::ResolveQuery::dump const): (JSC::AbstractModuleRecord::resolveExportImpl): 2017-10-24 Yusuke Suzuki [JSC] Use emitDumbVirtualCall in 32bit JIT https://bugs.webkit.org/show_bug.cgi?id=178644 Reviewed by Mark Lam. This patch aligns 32bit JIT op_call_eval slow case to 64bit version by using emitDumbVirtualCall. * jit/JITCall32_64.cpp: (JSC::JIT::compileCallEvalSlowCase): 2017-10-22 Yusuke Suzuki [JSC] Drop ArityCheckData https://bugs.webkit.org/show_bug.cgi?id=178648 Reviewed by Mark Lam. ArityCheckData is used to return a pair of `slotsToAdd` and `thunkToCall`. However, use of `thunkToCall` is removed in 64bit environment at r189575. We remove `thunkToCall` and align 32bit implementation to 64bit implementation. Since we no longer need to have the above pair, we can remove ArityCheckData too. * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): (JSC::setupArityCheckData): Deleted. * runtime/CommonSlowPaths.h: * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2017-10-23 Keith Miller Unreviewed, reland r223866 Didn't break the windows build... Restored changeset: "WebAssembly: topEntryFrame on Wasm::Instance" https://bugs.webkit.org/show_bug.cgi?id=178690 https://trac.webkit.org/changeset/223866 2017-10-23 Commit Queue Unreviewed, rolling out r223866. https://bugs.webkit.org/show_bug.cgi?id=178699 Probably broke the windows build (Requested by keith_miller on #webkit). Reverted changeset: "WebAssembly: topEntryFrame on Wasm::Instance" https://bugs.webkit.org/show_bug.cgi?id=178690 https://trac.webkit.org/changeset/223866 2017-10-23 Joseph Pecoraro Web Inspector: Remove unused Console.setMonitoringXHREnabled https://bugs.webkit.org/show_bug.cgi?id=178617 Reviewed by Sam Weinig. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * inspector/agents/InspectorConsoleAgent.h: * inspector/agents/JSGlobalObjectConsoleAgent.cpp: Removed. * inspector/agents/JSGlobalObjectConsoleAgent.h: Removed. * inspector/protocol/Console.json: Removed files and method. * inspector/JSGlobalObjectInspectorController.cpp: (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController): This can use the base ConsoleAgent now. 2017-10-23 JF Bastien WebAssembly: topEntryFrame on Wasm::Instance https://bugs.webkit.org/show_bug.cgi?id=178690 Reviewed by Saam Barati. topEntryFrame is usually on VM, but for a no-VM WebAssembly we need to hold topEntryFrame elsewhere, and generated code cannot hard-code where topEntryFrame live. Do this at creation time of Wasm::Instance, and then generated code will just load from wherever Wasm::Instance was told topEntryFrame is. In a JavaScript embedding this is still from VM, so all of the unwinding machinery stays the same. * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareOSREntry): * dfg/DFGOSRExit.cpp: (JSC::DFG::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer): (JSC::DFG::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer): * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): * interpreter/Interpreter.cpp: (JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::restoreCalleeSavesFromEntryFrameCalleeSavesBuffer): (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBufferImpl): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBuffer): The default parameter was never non-defaulted from any of the callers. The new version calls the impl directly because it doesn't have VM and doesn't hard-code the address of topEntryFrame. * jit/RegisterSet.cpp: (JSC::RegisterSet::vmCalleeSaveRegisterOffsets): This was weird on VM because it's not really VM-specific. * jit/RegisterSet.h: * runtime/VM.cpp: (JSC::VM::getAllCalleeSaveRegisterOffsets): Deleted. * runtime/VM.h: (JSC::VM::getCTIStub): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::B3IRGenerator::addCall): (JSC::Wasm::B3IRGenerator::addCallIndirect): * wasm/WasmInstance.cpp: (JSC::Wasm::Instance::Instance): * wasm/WasmInstance.h: topEntryFramePointer will eventually live here for real. Right now it's mirrored in JSWebAssemblyInstance because that's the acting Context. (JSC::Wasm::Instance::create): (JSC::Wasm::Instance::offsetOfTopEntryFramePointer): * wasm/WasmThunks.cpp: (JSC::Wasm::throwExceptionFromWasmThunkGenerator): * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance): * wasm/js/JSWebAssemblyInstance.h: Mirror Wasm::Instance temporarily. (JSC::JSWebAssemblyInstance::offsetOfCallee): (JSC::JSWebAssemblyInstance::offsetOfTopEntryFramePointer): (JSC::JSWebAssemblyInstance::offsetOfVM): Deleted. * wasm/js/WebAssemblyInstanceConstructor.cpp: (JSC::constructJSWebAssemblyInstance): * wasm/js/WebAssemblyPrototype.cpp: (JSC::instantiate): 2017-10-23 Joseph Pecoraro Web Inspector: Please support HAR Export for network traffic https://bugs.webkit.org/show_bug.cgi?id=146692 Reviewed by Brian Burg. * inspector/protocol/Network.json: Add a walltime to each send request. 2017-10-23 Matt Lewis Unreviewed, rolling out r223820. This caused a build break on Windows. Reverted changeset: "Web Inspector: Remove unused Console.setMonitoringXHREnabled" https://bugs.webkit.org/show_bug.cgi?id=178617 https://trac.webkit.org/changeset/223820 2017-10-23 Yusuke Suzuki [JSC] Use fastJoin in Array#toString https://bugs.webkit.org/show_bug.cgi?id=178062 Reviewed by Darin Adler. Array#toString()'s fast path uses original join operation. But this should use fastJoin if possible. This patch adds a fast path using fastJoin in Array#toString. And we also extend fastJoin to perform fast joining for int32 arrays. baseline patched double-array-to-string 126.6157+-5.8625 ^ 103.7343+-4.4968 ^ definitely 1.2206x faster int32-array-to-string 64.7792+-2.6524 61.2390+-2.1749 might be 1.0578x faster contiguous-array-to-string 62.6224+-2.6388 ^ 56.9899+-2.0852 ^ definitely 1.0988x faster * runtime/ArrayPrototype.cpp: (JSC::fastJoin): (JSC::arrayProtoFuncToString): (JSC::arrayProtoFuncToLocaleString): * runtime/JSStringJoiner.h: (JSC::JSStringJoiner::appendWithoutSideEffects): (JSC::JSStringJoiner::appendInt32): (JSC::JSStringJoiner::appendDouble): 2017-10-22 Zan Dobersek [JSC] Remove !(OS(LINUX) && CPU(ARM64)) guards in RegisterState.h https://bugs.webkit.org/show_bug.cgi?id=178452 Reviewed by Yusuke Suzuki. * heap/RegisterState.h: Re-enable the custom RegisterState and ALLOCATE_AND_GET_REGISTER_STATE definitions on ARM64 Linux. These don't cause any crashes nowadays. 2017-10-22 Yusuke Suzuki [JSC][Baseline] Use linkAllSlowCasesForBytecodeOffset as much as possible to simplify slow cases handling https://bugs.webkit.org/show_bug.cgi?id=178647 Reviewed by Saam Barati. There is much code counting slow cases in fast paths to call `linkSlowCase` carefully. This is really error-prone since the number of slow cases depends on values of instruction's metadata. We have linkAllSlowCasesForBytecodeOffset, which drains all slow cases for a specified bytecode offset. In typical cases like just calling a slow path function, this is enough. We use linkAllSlowCasesForBytecodeOffset as much as possible. It significantly simplifies the code. * jit/JIT.h: (JSC::JIT::linkAllSlowCases): * jit/JITArithmetic.cpp: (JSC::JIT::emitSlow_op_unsigned): (JSC::JIT::emit_compareAndJump): (JSC::JIT::emit_compareAndJumpSlow): (JSC::JIT::emitSlow_op_inc): (JSC::JIT::emitSlow_op_dec): (JSC::JIT::emitSlow_op_mod): (JSC::JIT::emitSlow_op_negate): (JSC::JIT::emitSlow_op_bitand): (JSC::JIT::emitSlow_op_bitor): (JSC::JIT::emitSlow_op_bitxor): (JSC::JIT::emitSlow_op_lshift): (JSC::JIT::emitSlow_op_rshift): (JSC::JIT::emitSlow_op_urshift): (JSC::JIT::emitSlow_op_add): (JSC::JIT::emitSlow_op_div): (JSC::JIT::emitSlow_op_mul): (JSC::JIT::emitSlow_op_sub): * jit/JITArithmetic32_64.cpp: (JSC::JIT::emit_compareAndJumpSlow): (JSC::JIT::emitSlow_op_unsigned): (JSC::JIT::emitSlow_op_inc): (JSC::JIT::emitSlow_op_dec): (JSC::JIT::emitSlow_op_mod): * jit/JITCall.cpp: (JSC::JIT::compileCallEvalSlowCase): (JSC::JIT::compileOpCallSlowCase): * jit/JITCall32_64.cpp: (JSC::JIT::compileCallEvalSlowCase): (JSC::JIT::compileOpCallSlowCase): * jit/JITInlines.h: (JSC::JIT::linkAllSlowCasesForBytecodeOffset): * jit/JITOpcodes.cpp: (JSC::JIT::emitSlow_op_new_object): (JSC::JIT::emitSlow_op_create_this): (JSC::JIT::emitSlow_op_check_tdz): (JSC::JIT::emitSlow_op_to_this): (JSC::JIT::emitSlow_op_to_primitive): (JSC::JIT::emitSlow_op_not): (JSC::JIT::emitSlow_op_eq): (JSC::JIT::emitSlow_op_neq): (JSC::JIT::emitSlow_op_stricteq): (JSC::JIT::emitSlow_op_nstricteq): (JSC::JIT::emitSlow_op_instanceof): (JSC::JIT::emitSlow_op_instanceof_custom): (JSC::JIT::emitSlow_op_to_number): (JSC::JIT::emitSlow_op_to_string): (JSC::JIT::emitSlow_op_loop_hint): (JSC::JIT::emitSlow_op_check_traps): (JSC::JIT::emitSlow_op_has_indexed_property): (JSC::JIT::emitSlow_op_get_direct_pname): (JSC::JIT::emitSlow_op_has_structure_property): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emitSlow_op_new_object): (JSC::JIT::emitSlow_op_instanceof): (JSC::JIT::emitSlow_op_instanceof_custom): (JSC::JIT::emitSlow_op_to_primitive): (JSC::JIT::emitSlow_op_not): (JSC::JIT::emitSlow_op_stricteq): (JSC::JIT::emitSlow_op_nstricteq): (JSC::JIT::emitSlow_op_to_number): (JSC::JIT::emitSlow_op_to_string): (JSC::JIT::emitSlow_op_create_this): (JSC::JIT::emitSlow_op_to_this): (JSC::JIT::emitSlow_op_check_tdz): (JSC::JIT::emitSlow_op_has_indexed_property): (JSC::JIT::emitSlow_op_get_direct_pname): * jit/JITPropertyAccess.cpp: (JSC::JIT::emitSlow_op_try_get_by_id): (JSC::JIT::emitSlow_op_get_by_id): (JSC::JIT::emitSlow_op_get_by_id_with_this): (JSC::JIT::emitSlow_op_put_by_id): (JSC::JIT::emitSlow_op_resolve_scope): (JSC::JIT::emitSlow_op_get_from_scope): (JSC::JIT::emitSlow_op_put_to_scope): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emitSlow_op_try_get_by_id): (JSC::JIT::emitSlow_op_get_by_id): (JSC::JIT::emitSlow_op_get_by_id_with_this): (JSC::JIT::emitSlow_op_put_by_id): (JSC::JIT::emitSlow_op_resolve_scope): (JSC::JIT::emitSlow_op_get_from_scope): (JSC::JIT::emitSlow_op_put_to_scope): 2017-10-22 Yusuke Suzuki [JSC] Clean up baseline slow path https://bugs.webkit.org/show_bug.cgi?id=178646 Reviewed by Saam Barati. If the given op is just calling a slow path function, we should use DEFINE_SLOW_OP instead. It is good since (1) we can reduce the manual emitting code and (2) it can clarify which function is implemented as a slow path call. This patch is an attempt to reduce 32bit specific code in baseline JIT. * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JIT.h: * jit/JITArithmetic.cpp: (JSC::JIT::emit_op_pow): Deleted. * jit/JITArithmetic32_64.cpp: (JSC::JIT::emitSlow_op_mod): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_strcat): Deleted. (JSC::JIT::emit_op_push_with_scope): Deleted. (JSC::JIT::emit_op_assert): Deleted. (JSC::JIT::emit_op_create_lexical_environment): Deleted. (JSC::JIT::emit_op_throw_static_error): Deleted. (JSC::JIT::emit_op_new_array_with_spread): Deleted. (JSC::JIT::emit_op_spread): Deleted. (JSC::JIT::emit_op_get_enumerable_length): Deleted. (JSC::JIT::emit_op_has_generic_property): Deleted. (JSC::JIT::emit_op_get_property_enumerator): Deleted. (JSC::JIT::emit_op_to_index_string): Deleted. (JSC::JIT::emit_op_create_direct_arguments): Deleted. (JSC::JIT::emit_op_create_scoped_arguments): Deleted. (JSC::JIT::emit_op_create_cloned_arguments): Deleted. (JSC::JIT::emit_op_create_rest): Deleted. (JSC::JIT::emit_op_unreachable): Deleted. * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_strcat): Deleted. (JSC::JIT::emit_op_push_with_scope): Deleted. (JSC::JIT::emit_op_assert): Deleted. (JSC::JIT::emit_op_create_lexical_environment): Deleted. * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_put_by_val_with_this): Deleted. (JSC::JIT::emit_op_get_by_val_with_this): Deleted. (JSC::JIT::emit_op_put_by_id_with_this): Deleted. (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval): Deleted. (JSC::JIT::emit_op_define_data_property): Deleted. (JSC::JIT::emit_op_define_accessor_property): Deleted. * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval): Deleted. (JSC::JIT::emit_op_get_by_val_with_this): Deleted. (JSC::JIT::emit_op_put_by_id_with_this): Deleted. (JSC::JIT::emit_op_put_by_val_with_this): Deleted. 2017-10-21 Joseph Pecoraro Web Inspector: Remove unused Console.setMonitoringXHREnabled https://bugs.webkit.org/show_bug.cgi?id=178617 Reviewed by Sam Weinig. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * inspector/agents/InspectorConsoleAgent.h: * inspector/agents/JSGlobalObjectConsoleAgent.cpp: Removed. * inspector/agents/JSGlobalObjectConsoleAgent.h: Removed. * inspector/protocol/Console.json: Removed files and method. * inspector/JSGlobalObjectInspectorController.cpp: (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController): This can use the base ConsoleAgent now. 2017-10-21 Yusuke Suzuki [JSC] Remove per-host-function CTI stub in 32bit environment https://bugs.webkit.org/show_bug.cgi?id=178581 Reviewed by Saam Barati. JIT::privateCompileCTINativeCall only exists in 32bit environment and it is almost the same to native call CTI stub. The only difference is that it embed the address of the host function directly in the generated stub. This means that we have per-host-function CTI stub only in 32bit environment. This patch just removes it and use one CTI stub instead. This design is the same to the current 64bit implementation. * jit/JIT.cpp: (JSC::JIT::compileCTINativeCall): Deleted. * jit/JIT.h: * jit/JITOpcodes.cpp: (JSC::JIT::privateCompileCTINativeCall): Deleted. * jit/JITOpcodes32_64.cpp: (JSC::JIT::privateCompileCTINativeCall): Deleted. * jit/JITThunks.cpp: (JSC::JITThunks::hostFunctionStub): 2017-10-20 Antoine Quint [Web Animations] Provide basic timeline and animation interfaces https://bugs.webkit.org/show_bug.cgi?id=178526 Reviewed by Dean Jackson. Remove the WEB_ANIMATIONS compile-time flag. * Configurations/FeatureDefines.xcconfig: 2017-10-20 Commit Queue Unreviewed, rolling out r223744, r223750, and r223751. https://bugs.webkit.org/show_bug.cgi?id=178594 These caused consistent failures in test that existed and were added in the patches. (Requested by mlewis13 on #webkit). Reverted changesets: "[JSC] ScriptFetcher should be notified directly from module pipeline" https://bugs.webkit.org/show_bug.cgi?id=178340 https://trac.webkit.org/changeset/223744 "Unreviewed, fix changed line number in test expect files" https://bugs.webkit.org/show_bug.cgi?id=178340 https://trac.webkit.org/changeset/223750 "Unreviewed, follow up to reflect comments" https://bugs.webkit.org/show_bug.cgi?id=178340 https://trac.webkit.org/changeset/223751 2017-10-20 Yusuke Suzuki Unreviewed, follow up to reflect comments https://bugs.webkit.org/show_bug.cgi?id=178340 * runtime/JSModuleLoader.cpp: (JSC::JSModuleLoader::notifyCompleted): 2017-10-20 Saam Barati Optimize accesses to how we get the direct prototype https://bugs.webkit.org/show_bug.cgi?id=178548 Reviewed by Yusuke Suzuki. This patch makes JSObject::getPrototypeDirect take VM& as a parameter so it can use the faster version of the structure accessor function. The reason for making this change is that JSObjet::getPrototypeDirect is called on the hot path in property lookup. * API/JSObjectRef.cpp: (JSObjectGetPrototype): * jsc.cpp: (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::slowCall): (WTF::DOMJITGetterBaseJSObject::customGetter): (functionCreateProxy): * runtime/ArrayPrototype.cpp: (JSC::speciesWatchpointIsValid): * runtime/ErrorInstance.cpp: (JSC::ErrorInstance::sanitizedToString): * runtime/JSArray.cpp: (JSC::JSArray::isIteratorProtocolFastAndNonObservable): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::lastInPrototypeChain): (JSC::JSGlobalObject::resetPrototype): (JSC::JSGlobalObject::finishCreation): * runtime/JSGlobalObjectInlines.h: (JSC::JSGlobalObject::objectPrototypeIsSane): (JSC::JSGlobalObject::arrayPrototypeChainIsSane): (JSC::JSGlobalObject::stringPrototypeChainIsSane): * runtime/JSLexicalEnvironment.cpp: (JSC::JSLexicalEnvironment::getOwnPropertySlot): * runtime/JSMap.cpp: (JSC::JSMap::isIteratorProtocolFastAndNonObservable): * runtime/JSObject.cpp: (JSC::JSObject::calculatedClassName): (JSC::JSObject::setPrototypeWithCycleCheck): (JSC::JSObject::getPrototype): (JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype): (JSC::JSObject::attemptToInterceptPutByIndexOnHole): (JSC::JSObject::anyObjectInChainMayInterceptIndexedAccesses const): (JSC::JSObject::prototypeChainMayInterceptStoreTo): * runtime/JSObject.h: (JSC::JSObject::finishCreation): (JSC::JSObject::getPrototypeDirect const): (JSC::JSObject::getPrototype): * runtime/JSObjectInlines.h: (JSC::JSObject::canPerformFastPutInline): (JSC::JSObject::getPropertySlot): (JSC::JSObject::getNonIndexPropertySlot): * runtime/JSProxy.cpp: (JSC::JSProxy::setTarget): * runtime/JSSet.cpp: (JSC::JSSet::isIteratorProtocolFastAndNonObservable): * runtime/ProgramExecutable.cpp: (JSC::ProgramExecutable::initializeGlobalProperties): * runtime/StructureInlines.h: (JSC::Structure::isValid const): 2017-10-20 Yusuke Suzuki [ARM64] static_cast() in BinaryOpNode::emitBytecode() prevents op_unsigned emission https://bugs.webkit.org/show_bug.cgi?id=178379 Reviewed by Saam Barati. We reuse jsNumber's checking mechanism here to precisely check the generated number is within uint32_t in bytecode compiler. This is reasonable since the NumberNode will generate the exact this JSValue. * bytecompiler/NodesCodegen.cpp: (JSC::BinaryOpNode::emitBytecode): 2017-10-20 Yusuke Suzuki [JSC] ScriptFetcher should be notified directly from module pipeline https://bugs.webkit.org/show_bug.cgi?id=178340 Reviewed by Sam Weinig. Previously, we use JSStdFunction to let WebCore inform the module pipeline results. We setup JSStdFunction to the resulted promise of the module pipeline. It is super ad-hoc since JSStdFunction's lambda need extra-careful to make it non-cyclic-referenced. JSStdFunction's lambda can capture variables, but they are not able to be marked by GC. But now, we have ScriptFetcher. It is introduced after we implemented the module pipeline notification mechanism by using JSStdFunction. But it is appropriate one to receive notification from the module pipeline by observer style. This patch removes the above ad-hoc JSStdFunction use. And now ScriptFetcher receives completion/failure notifications from the module pipeline. * builtins/ModuleLoaderPrototype.js: (loadModule): (loadAndEvaluateModule): * runtime/Completion.cpp: (JSC::loadModule): * runtime/Completion.h: * runtime/JSModuleLoader.cpp: (JSC::jsValueToModuleKey): (JSC::JSModuleLoader::notifyCompleted): (JSC::JSModuleLoader::notifyFailed): * runtime/JSModuleLoader.h: * runtime/ModuleLoaderPrototype.cpp: (JSC::moduleLoaderPrototypeNotifyCompleted): (JSC::moduleLoaderPrototypeNotifyFailed): * runtime/ScriptFetcher.h: (JSC::ScriptFetcher::notifyLoadCompleted): (JSC::ScriptFetcher::notifyLoadFailed): 2017-10-19 JF Bastien WebAssembly: no VM / JS version of everything but Instance https://bugs.webkit.org/show_bug.cgi?id=177473 Reviewed by Filip Pizlo, Saam Barati. This change entails cleaning up and splitting a bunch of code which we had intertwined between C++ classes which represent JS objects, and pure C++ implementation objects. This specific change goes most of the way towards allowing JSC's WebAssembly to work without VM / JS, up to but excluding JSWebAssemblyInstance (there's Wasm::Instance, but it's not *the* thing yet). Because of this we still have a few FIXME identifying places that need to change. A follow-up change will go the rest of the way. I went about this change in the simplest way possible: grep the JavaScriptCore/wasm directory for "JS[^C_]" as well as "VM" and exclude the /js/ sub-directory (which contains the JS implementation of WebAssembly). None of this change removes the need for a JIT entitlement to be able to use WebAssembly. We don't have an interpreter, the process therefore still needs to be allowed to JIT to use these pure-C++ APIs. Interesting things to note: - Remove VM from Plan and associated places. It can just live as a capture in the callback lambda if it's needed. - Wasm::Memory shouldn't require a VM. It was only used to ask the GC to collect. We now instead pass two lambdas at construction time for this purpose: one to notify of memory pressure, and the other to ask for syncrhonous memory reclamation. This allows whoever creates the memory to dictate how to react to both these cases, and for a JS embedding that's to call the GC (async or sync, respectively). - Move grow logic from JSWebAssemblyMemory to Wasm::Memory::grow. Use Expected there, with an enum class for failure types. - Exceeding max on memory growth now returns a range error as per spec. This is a (very minor) breaking change: it used to throw OOM error. Update the corresponding test. - When generating the grow_memory opcode, no need to get the VM. Instead, reach directly for Wasm::Memory and grow it. - JSWebAssemblyMemory::grow can now always throw on failure, because it's only ever called from JS (not from grow_memory as before). - Wasm::Memory now takes a callback for successful growth. This allows JS wrappers to register themselves when growth succeeds without Wasm::Memory knowning anything about JS. It'll also allow creating a list of callbacks for when we add thread support (we'll want to notify many wrappers, all under a lock). - Wasm::Memory is now back to being the source of truth about address / size, used directly by generated code instead of JSWebAssemblyMemory. - Move wasmToJS from the general WasmBinding header to its own header under wasm/js. It's only used by wasm/js/JSWebAssemblyCodeBlock.cpp, and uses VM, and therefore isn't general WebAssembly. - Make Wasm::Context an actual type (just a struct holding a JSWebAssemlyInstance for now) instead of an alias for that. Notably this doesn't add anything to the Context and doesn't change what actually gets passed around in JIT code (fast TLS or registers) because these changes potentially impact performance. The entire purpose of this change is to allow passing Wasm::Context around without having to know about VM. Since VM contains a Wasm::Context the JS embedding is effectively the same, but with this setup a non-JS embedding is much better off. - Move JSWebAssembly into the JS folder. - OMGPlan: use Wasm::CodeBlock directly instead of JSWebAssemblyCodeBlock. - wasm->JS stubs are now on the instance's tail as raw pointers, instead of being on JSWebAssemblyCodeBlock, and are now called wasm->Embedder stubs. The owned reference is still on JSWebAssemblyCodeBlock, and is still called wasm->JS stub. This move means that the embedder must, after creating a Wasm::CodeBlock, somehow create the stubs to call back into the embedder. This removes an indirection in the generated code because the B3 IR generator now reaches into the instance instead of JSWebAssemblyCodeBlock. - Move more CodeBlock things. Compilation completion is now marked by its own atomic flag instead of a nullptr plan: that required using a lock, and was causing a deadlock in stack-trace.js because before my changes JSWebAssemblyCodeBlock did its own completion checking separately from Wasm::CodeBlock, without getting the lock. Now that everything points to Wasm::CodeBlock and there's no cached completion marker, the lock was being acquired in a sanity-check assertion. - Embedder -> Wasm wrappers are now generated through a function that's passed in at compilation time, instead of being hard-coded as a JS -> Wasm wrapper. - WasmMemory doens't need to know about fault handling thunks. Only the IR generator should know, and should make sure that the exception throwing thunk is generated if any memory is present (note: with signal handling not all of them generate an exception check). - Make exception throwing pluggable: instead of having a hard-coded JS-specific lambda we now have a regular C++ function being called from JIT code when a WebAssembly exception is thrown. This allows any embedder to get called as they wish. For now a process can only have a single of these functions (i.e. only one embedder per process) because the trap handler is a singleton. That can be fixed in in #177475. - Create WasmEmbedder.h where all embedder plugging will live. - Split up JSWebAssemblyTable into Wasm::Table which is refcounted. JSWebAssemblyTable now only contains the JS functions in the table, and Wasm::Table is what's used by the JIT code to lookup where to call and do the instance check (for context switch). Note that this creates an extra allocation for all the instances in Wasm::Table, and in exchange removes an indirection in JIT code because the instance used to be obtained off of the JS function. Also note that it's the embedder than keeps the instances alive, not Wasm::Table (which holds a dumb pointer to the instance), because doing otherwise would cause reference cycles. - Add WasmInstance. It doesn't do much for now, owns globals. - JSWebAssembly instance now doesn't just contain the imported functions as JSObjects, it also has the corresponding import's instance and wasm entrypoint. This triples the space allocated per instance's imported function, but there shouldn't be that many imports. This has two upsides: it creates smaller and faster code, and makes is easier to disassociate embedder-specific things from embedder-neutral things. The small / faster win is in two places: B3 IR generator only needs offsetOfImportFunction for the call opcode (when the called index is an import) to know whether the import is wasm->wasm or wasm->embedder (this isn't known at compile-time because it's dependent on the import object), this is now done by seeing if that import function has an associated target instance (only wasm->wasm does); the other place is wasmBinding which uses offsetOfImportFunction to figure out the wasm->wasm target instance, and then gets WebAssemblyFunction::offsetOfWasmEntrypointLoadLocation to do a tail call. The disassociation comes because the target instance can be Wasm::Instance once we change what the Context is, and WasmEntrypointLoadLocation is already embedder-independent. As a next step I can move this tail allocation from JSWebAssemblyInstance to Wasm::Instance, and leave importFunction in as an opaque pointer which is embedder-specific, and in JS will remain WriteBarrier. - Rename VMEntryFrame to EntryFrame, and in many places pass a pointer to it around instead of VM. This is a first step in allowing entry frames which aren't stored on VM, but which are instead stored in an embedder-specific location. That change won't really affect JS except through code churn, but will allow WebAssembly to use some machinery in a generic manner without having a VM. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * bytecode/PolymorphicAccess.cpp: (JSC::AccessGenerationState::emitExplicitExceptionHandler): * debugger/Debugger.cpp: (JSC::Debugger::stepOutOfFunction): (JSC::Debugger::returnEvent): (JSC::Debugger::unwindEvent): (JSC::Debugger::didExecuteProgram): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compileExceptionHandlers): * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareOSREntry): * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::compileOSRExit): (JSC::DFG::OSRExit::compileExit): * dfg/DFGThunks.cpp: (JSC::DFG::osrEntryThunkGenerator): * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLLink.cpp: (JSC::FTL::link): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::lower): * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): * interpreter/CallFrame.cpp: (JSC::CallFrame::wasmAwareLexicalGlobalObject): (JSC::CallFrame::callerFrame): (JSC::CallFrame::unsafeCallerFrame): * interpreter/CallFrame.h: (JSC::ExecState::callerFrame const): (JSC::ExecState::callerFrameOrEntryFrame const): (JSC::ExecState::unsafeCallerFrameOrEntryFrame const): * interpreter/FrameTracers.h: (JSC::NativeCallFrameTracer::NativeCallFrameTracer): (JSC::NativeCallFrameTracerWithRestore::NativeCallFrameTracerWithRestore): (JSC::NativeCallFrameTracerWithRestore::~NativeCallFrameTracerWithRestore): * interpreter/Interpreter.cpp: (JSC::UnwindFunctor::operator() const): (JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const): (JSC::Interpreter::unwind): * interpreter/StackVisitor.cpp: (JSC::StackVisitor::StackVisitor): (JSC::StackVisitor::gotoNextFrame): (JSC::StackVisitor::readNonInlinedFrame): (JSC::StackVisitor::Frame::dump const): * interpreter/StackVisitor.h: (JSC::StackVisitor::Frame::callerIsEntryFrame const): * interpreter/VMEntryRecord.h: (JSC::VMEntryRecord::prevTopEntryFrame): (JSC::VMEntryRecord::unsafePrevTopEntryFrame): (JSC::EntryFrame::vmEntryRecordOffset): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::restoreCalleeSavesFromEntryFrameCalleeSavesBuffer): (JSC::AssemblyHelpers::loadWasmContextInstance): (JSC::AssemblyHelpers::storeWasmContextInstance): (JSC::AssemblyHelpers::loadWasmContextInstanceNeedsMacroScratchRegister): (JSC::AssemblyHelpers::storeWasmContextInstanceNeedsMacroScratchRegister): (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBufferImpl): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer): (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBuffer): (JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToEntryFrameCalleeSavesBuffer): * jit/JIT.cpp: (JSC::JIT::emitEnterOptimizationCheck): (JSC::JIT::privateCompileExceptionHandlers): * jit/JITExceptions.cpp: (JSC::genericUnwind): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_throw): (JSC::JIT::emit_op_catch): (JSC::JIT::emitSlow_op_loop_hint): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_throw): (JSC::JIT::emit_op_catch): * jit/JITOperations.cpp: * jit/ThunkGenerators.cpp: (JSC::throwExceptionFromCallSlowPathGenerator): (JSC::nativeForGenerator): * jsc.cpp: (functionDumpCallFrame): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LLIntThunks.cpp: (JSC::vmEntryRecord): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/Options.cpp: (JSC::recomputeDependentOptions): * runtime/Options.h: * runtime/SamplingProfiler.cpp: (JSC::FrameWalker::FrameWalker): (JSC::FrameWalker::advanceToParentFrame): (JSC::SamplingProfiler::processUnverifiedStackTraces): * runtime/ThrowScope.cpp: (JSC::ThrowScope::~ThrowScope): * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::~VM): * runtime/VM.h: (JSC::VM::topEntryFrameOffset): * runtime/VMTraps.cpp: (JSC::isSaneFrame): (JSC::VMTraps::tryInstallTrapBreakpoints): (JSC::VMTraps::invalidateCodeBlocksOnStack): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::restoreWasmContextInstance): (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState): (JSC::Wasm::B3IRGenerator::addGrowMemory): (JSC::Wasm::B3IRGenerator::addCurrentMemory): (JSC::Wasm::B3IRGenerator::addCall): (JSC::Wasm::B3IRGenerator::addCallIndirect): (JSC::Wasm::parseAndCompile): * wasm/WasmB3IRGenerator.h: * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::BBQPlan): (JSC::Wasm::BBQPlan::compileFunctions): (JSC::Wasm::BBQPlan::complete): * wasm/WasmBBQPlan.h: * wasm/WasmBBQPlanInlines.h: (JSC::Wasm::BBQPlan::initializeCallees): * wasm/WasmBinding.cpp: (JSC::Wasm::wasmToWasm): * wasm/WasmBinding.h: * wasm/WasmCodeBlock.cpp: (JSC::Wasm::CodeBlock::create): (JSC::Wasm::CodeBlock::CodeBlock): (JSC::Wasm::CodeBlock::compileAsync): (JSC::Wasm::CodeBlock::setCompilationFinished): * wasm/WasmCodeBlock.h: (JSC::Wasm::CodeBlock::offsetOfImportStubs): (JSC::Wasm::CodeBlock::allocationSize): (JSC::Wasm::CodeBlock::importWasmToEmbedderStub): (JSC::Wasm::CodeBlock::offsetOfImportWasmToEmbedderStub): (JSC::Wasm::CodeBlock::wasmToJSCallStubForImport): (JSC::Wasm::CodeBlock::compilationFinished): (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace): (JSC::Wasm::CodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace): * wasm/WasmContext.cpp: (JSC::Wasm::Context::useFastTLS): (JSC::Wasm::Context::load const): (JSC::Wasm::Context::store): * wasm/WasmContext.h: * wasm/WasmEmbedder.h: Copied from Source/JavaScriptCore/wasm/WasmContext.h. * wasm/WasmFaultSignalHandler.cpp: * wasm/WasmFaultSignalHandler.h: * wasm/WasmFormat.h: * wasm/WasmInstance.cpp: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h. (JSC::Wasm::Instance::Instance): (JSC::Wasm::Instance::~Instance): (JSC::Wasm::Instance::extraMemoryAllocated const): * wasm/WasmInstance.h: Added. (JSC::Wasm::Instance::create): (JSC::Wasm::Instance::finalizeCreation): (JSC::Wasm::Instance::module): (JSC::Wasm::Instance::codeBlock): (JSC::Wasm::Instance::memory): (JSC::Wasm::Instance::table): (JSC::Wasm::Instance::loadI32Global const): (JSC::Wasm::Instance::loadI64Global const): (JSC::Wasm::Instance::loadF32Global const): (JSC::Wasm::Instance::loadF64Global const): (JSC::Wasm::Instance::setGlobal): (JSC::Wasm::Instance::offsetOfCachedStackLimit): (JSC::Wasm::Instance::cachedStackLimit const): (JSC::Wasm::Instance::setCachedStackLimit): * wasm/WasmMemory.cpp: (JSC::Wasm::Memory::Memory): (JSC::Wasm::Memory::create): (JSC::Wasm::Memory::~Memory): (JSC::Wasm::Memory::grow): * wasm/WasmMemory.h: (JSC::Wasm::Memory::offsetOfMemory): (JSC::Wasm::Memory::offsetOfSize): * wasm/WasmMemoryInformation.cpp: (JSC::Wasm::PinnedRegisterInfo::get): (JSC::Wasm::PinnedRegisterInfo::PinnedRegisterInfo): * wasm/WasmMemoryInformation.h: (JSC::Wasm::PinnedRegisterInfo::toSave const): * wasm/WasmMemoryMode.cpp: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h. (JSC::Wasm::makeString): * wasm/WasmMemoryMode.h: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h. * wasm/WasmModule.cpp: (JSC::Wasm::makeValidationCallback): (JSC::Wasm::Module::validateSync): (JSC::Wasm::Module::validateAsync): (JSC::Wasm::Module::getOrCreateCodeBlock): (JSC::Wasm::Module::compileSync): (JSC::Wasm::Module::compileAsync): * wasm/WasmModule.h: * wasm/WasmModuleParser.cpp: (JSC::Wasm::ModuleParser::parseTableHelper): * wasm/WasmOMGPlan.cpp: (JSC::Wasm::OMGPlan::OMGPlan): (JSC::Wasm::OMGPlan::runForIndex): * wasm/WasmOMGPlan.h: * wasm/WasmPageCount.h: (JSC::Wasm::PageCount::isValid const): * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::Plan): (JSC::Wasm::Plan::runCompletionTasks): (JSC::Wasm::Plan::addCompletionTask): (JSC::Wasm::Plan::tryRemoveContextAndCancelIfLast): * wasm/WasmPlan.h: (JSC::Wasm::Plan::dontFinalize): * wasm/WasmSignature.cpp: * wasm/WasmSignature.h: * wasm/WasmTable.cpp: Added. (JSC::Wasm::Table::create): (JSC::Wasm::Table::~Table): (JSC::Wasm::Table::Table): (JSC::Wasm::Table::grow): (JSC::Wasm::Table::clearFunction): (JSC::Wasm::Table::setFunction): * wasm/WasmTable.h: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyTable.h. (JSC::Wasm::Table::maximum const): (JSC::Wasm::Table::size const): (JSC::Wasm::Table::offsetOfSize): (JSC::Wasm::Table::offsetOfFunctions): (JSC::Wasm::Table::offsetOfInstances): (JSC::Wasm::Table::isValidSize): * wasm/WasmThunks.cpp: (JSC::Wasm::throwExceptionFromWasmThunkGenerator): (JSC::Wasm::triggerOMGTierUpThunkGenerator): (JSC::Wasm::Thunks::setThrowWasmException): (JSC::Wasm::Thunks::throwWasmException): * wasm/WasmThunks.h: * wasm/WasmWorklist.cpp: (JSC::Wasm::Worklist::stopAllPlansForContext): * wasm/WasmWorklist.h: * wasm/js/JSToWasm.cpp: Added. (JSC::Wasm::createJSToWasmWrapper): * wasm/js/JSToWasm.h: Copied from Source/JavaScriptCore/wasm/WasmBinding.h. * wasm/js/JSWebAssembly.cpp: Renamed from Source/JavaScriptCore/wasm/JSWebAssembly.cpp. * wasm/js/JSWebAssembly.h: Renamed from Source/JavaScriptCore/wasm/JSWebAssembly.h. * wasm/js/JSWebAssemblyCodeBlock.cpp: (JSC::JSWebAssemblyCodeBlock::create): (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock): * wasm/js/JSWebAssemblyCodeBlock.h: * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance): (JSC::JSWebAssemblyInstance::finishCreation): (JSC::JSWebAssemblyInstance::visitChildren): (JSC::JSWebAssemblyInstance::finalizeCreation): (JSC::JSWebAssemblyInstance::create): * wasm/js/JSWebAssemblyInstance.h: (JSC::JSWebAssemblyInstance::instance): (JSC::JSWebAssemblyInstance::context const): (JSC::JSWebAssemblyInstance::table): (JSC::JSWebAssemblyInstance::webAssemblyToJSCallee): (JSC::JSWebAssemblyInstance::setMemory): (JSC::JSWebAssemblyInstance::offsetOfTail): (JSC::JSWebAssemblyInstance::importFunctionInfo): (JSC::JSWebAssemblyInstance::offsetOfTargetInstance): (JSC::JSWebAssemblyInstance::offsetOfWasmEntrypoint): (JSC::JSWebAssemblyInstance::offsetOfImportFunction): (JSC::JSWebAssemblyInstance::importFunction): (JSC::JSWebAssemblyInstance::internalMemory): (JSC::JSWebAssemblyInstance::wasmCodeBlock const): (JSC::JSWebAssemblyInstance::offsetOfWasmTable): (JSC::JSWebAssemblyInstance::offsetOfCallee): (JSC::JSWebAssemblyInstance::offsetOfGlobals): (JSC::JSWebAssemblyInstance::offsetOfWasmCodeBlock): (JSC::JSWebAssemblyInstance::offsetOfWasmMemory): (JSC::JSWebAssemblyInstance::cachedStackLimit const): (JSC::JSWebAssemblyInstance::setCachedStackLimit): (JSC::JSWebAssemblyInstance::wasmMemory): (JSC::JSWebAssemblyInstance::wasmModule): (JSC::JSWebAssemblyInstance::allocationSize): (JSC::JSWebAssemblyInstance::module const): * wasm/js/JSWebAssemblyMemory.cpp: (JSC::JSWebAssemblyMemory::create): (JSC::JSWebAssemblyMemory::adopt): (JSC::JSWebAssemblyMemory::JSWebAssemblyMemory): (JSC::JSWebAssemblyMemory::grow): (JSC::JSWebAssemblyMemory::growSuccessCallback): * wasm/js/JSWebAssemblyMemory.h: * wasm/js/JSWebAssemblyModule.cpp: (JSC::JSWebAssemblyModule::moduleInformation const): (JSC::JSWebAssemblyModule::exportSymbolTable const): (JSC::JSWebAssemblyModule::signatureIndexFromFunctionIndexSpace const): (JSC::JSWebAssemblyModule::callee const): (JSC::JSWebAssemblyModule::codeBlock): (JSC::JSWebAssemblyModule::module): * wasm/js/JSWebAssemblyModule.h: * wasm/js/JSWebAssemblyTable.cpp: (JSC::JSWebAssemblyTable::create): (JSC::JSWebAssemblyTable::JSWebAssemblyTable): (JSC::JSWebAssemblyTable::visitChildren): (JSC::JSWebAssemblyTable::grow): (JSC::JSWebAssemblyTable::getFunction): (JSC::JSWebAssemblyTable::clearFunction): (JSC::JSWebAssemblyTable::setFunction): * wasm/js/JSWebAssemblyTable.h: (JSC::JSWebAssemblyTable::isValidSize): (JSC::JSWebAssemblyTable::maximum const): (JSC::JSWebAssemblyTable::size const): (JSC::JSWebAssemblyTable::table): * wasm/js/WasmToJS.cpp: Copied from Source/JavaScriptCore/wasm/WasmBinding.cpp. (JSC::Wasm::materializeImportJSCell): (JSC::Wasm::wasmToJS): (JSC::Wasm::wasmToJSException): * wasm/js/WasmToJS.h: Copied from Source/JavaScriptCore/wasm/WasmBinding.h. * wasm/js/WebAssemblyFunction.cpp: (JSC::callWebAssemblyFunction): * wasm/js/WebAssemblyInstanceConstructor.cpp: (JSC::constructJSWebAssemblyInstance): * wasm/js/WebAssemblyMemoryConstructor.cpp: (JSC::constructJSWebAssemblyMemory): * wasm/js/WebAssemblyMemoryPrototype.cpp: (JSC::webAssemblyMemoryProtoFuncGrow): * wasm/js/WebAssemblyModuleConstructor.cpp: (JSC::constructJSWebAssemblyModule): (JSC::WebAssemblyModuleConstructor::createModule): * wasm/js/WebAssemblyModuleConstructor.h: * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::link): (JSC::WebAssemblyModuleRecord::evaluate): * wasm/js/WebAssemblyPrototype.cpp: (JSC::webAssemblyCompileFunc): (JSC::instantiate): (JSC::compileAndInstantiate): (JSC::webAssemblyValidateFunc): * wasm/js/WebAssemblyTableConstructor.cpp: (JSC::constructJSWebAssemblyTable): * wasm/js/WebAssemblyWrapperFunction.cpp: (JSC::WebAssemblyWrapperFunction::create): 2017-10-19 Mark Lam Stringifier::appendStringifiedValue() is missing an exception check. https://bugs.webkit.org/show_bug.cgi?id=178386 Reviewed by Saam Barati. * runtime/JSONObject.cpp: (JSC::Stringifier::appendStringifiedValue): 2017-10-19 Saam Barati REGRESSION(r223691): DFGByteCodeParser.cpp:1483:83: warning: comparison is always false due to limited range of data type [-Wtype-limits] https://bugs.webkit.org/show_bug.cgi?id=178543 Reviewed by Filip Pizlo. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleRecursiveTailCall): 2017-10-19 Saam Barati re-inline ObjectAllocationProfile::initializeProfile https://bugs.webkit.org/show_bug.cgi?id=178532 Rubber stamped by Michael Saboff. I un-inlined this function when implementing poly proto. This patch re-inlines it. In my testing, it looks like it might be a 0.5% speedometer progression to inline it. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * bytecode/CodeBlock.cpp: * bytecode/ObjectAllocationProfile.cpp: Removed. * bytecode/ObjectAllocationProfileInlines.h: Copied from Source/JavaScriptCore/bytecode/ObjectAllocationProfile.cpp. (JSC::ObjectAllocationProfile::initializeProfile): (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount): * runtime/FunctionRareData.cpp: 2017-10-19 Michael Saboff Test262: RegExp/property-escapes/generated/Emoji_Component.js fails with current RegExp Unicode Properties implementation https://bugs.webkit.org/show_bug.cgi?id=178521 Reviewed by JF Bastien. * ucd/emoji-data.txt: Replaced with the Unicode Emoji 5.0 version of the file as that is the most recent standard version. The prior version was the draft 6.0 version. 2017-10-19 Saam Barati We should hard code the poly proto offset https://bugs.webkit.org/show_bug.cgi?id=178531 Reviewed by Filip Pizlo. This patch embraces that the poly proto offset is always zero. It's already the case that we would always get the inline offset zero for poly proto just by construction. This just hardcodes this assumption throughout the codebase. This appears to be a 1% speedometer progression in my testing. The downside of this patch is that it may require changing how we do things when we implement poly proto when inheriting from builtin types. I think we can face this problem when we decide to implement that. * bytecode/AccessCase.cpp: (JSC::AccessCase::generateWithGuard): * dfg/DFGOperations.cpp: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject): (JSC::DFG::SpeculativeJIT::compileGetPrototypeOf): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileGetPrototypeOf): (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_instanceof): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_instanceof): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/JSObject.cpp: (JSC::JSObject::setPrototypeDirect): * runtime/JSObject.h: (JSC::JSObject::locationForOffset const): (JSC::JSObject::locationForOffset): (JSC::JSObject::getDirect const): * runtime/PropertyOffset.h: * runtime/Structure.cpp: (JSC::Structure::create): (JSC::Structure::dump const): * runtime/Structure.h: * runtime/StructureInlines.h: (JSC::Structure::storedPrototype const): (JSC::Structure::storedPrototypeObject const): 2017-10-19 Saam Barati Turn various poly proto RELEASE_ASSERTs into ASSERTs because they're on the hot path in speedometer https://bugs.webkit.org/show_bug.cgi?id=178529 Reviewed by Mark Lam. * runtime/Structure.h: * runtime/StructureInlines.h: (JSC::Structure::storedPrototypeObject const): (JSC::Structure::storedPrototypeStructure const): (JSC::Structure::storedPrototype const): (JSC::Structure::prototypeForLookup const): (JSC::Structure::prototypeChain const): 2017-10-19 Saam Barati Turn poly proto back on by default and remove the option https://bugs.webkit.org/show_bug.cgi?id=178525 Reviewed by Mark Lam. I added this option because I thought it'd speed speedometer up because the original poly proto patch slowed speedometer down. It turns out that allocating poly proto objects is not what slows speedometer down. It's other code I added in the runtime that needs to be poly proto aware. I'll be addressing these in follow up patches. * runtime/Options.h: * runtime/StructureInlines.h: (JSC::Structure::shouldConvertToPolyProto): 2017-10-19 Robin Morisset Turn recursive tail calls into loops https://bugs.webkit.org/show_bug.cgi?id=176601 Reviewed by Saam Barati. We want to turn recursive tail calls into loops early in the pipeline, so that the loops can then be optimized. One difficulty is that we need to split the entry block of the function we are jumping to in order to have somewhere to jump to. Worse: it is not necessarily the first block of the codeBlock, because of inlining! So we must do the splitting in the DFGByteCodeParser, at the same time as inlining. We do this part through modifying the computation of the jump targets. Importantly, we only do this splitting for functions that have tail calls. It is the only case where the optimisation is sound, and doing the splitting unconditionnaly destroys performance on Octane/raytrace. We must then do the actual transformation also in DFGByteCodeParser, to avoid code motion moving code out of the body of what will become a loop. The transformation is entirely contained in handleRecursiveTailCall, which is hooked to the inlining machinery. * bytecode/CodeBlock.h: (JSC::CodeBlock::hasTailCalls const): * bytecode/PreciseJumpTargets.cpp: (JSC::getJumpTargetsForBytecodeOffset): (JSC::computePreciseJumpTargetsInternal): * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedCodeBlock::hasTailCalls const): (JSC::UnlinkedCodeBlock::setHasTailCalls): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitEnter): (JSC::BytecodeGenerator::emitCallInTailPosition): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::allocateTargetableBlock): (JSC::DFG::ByteCodeParser::makeBlockTargetable): (JSC::DFG::ByteCodeParser::handleCall): (JSC::DFG::ByteCodeParser::handleRecursiveTailCall): (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::parse): 2017-10-18 Mark Lam RegExpObject::defineOwnProperty() does not need to compare values if no descriptor value is specified. https://bugs.webkit.org/show_bug.cgi?id=177600 Reviewed by Saam Barati. According to http://www.ecma-international.org/ecma-262/8.0/#sec-validateandapplypropertydescriptor, section 9.1.6.3-7.a.ii, we should only check if the value is the same if the descriptor value is present. * runtime/RegExpObject.cpp: (JSC::RegExpObject::defineOwnProperty): 2017-10-18 Keith Miller Setup WebCore build to start using unified sources. https://bugs.webkit.org/show_bug.cgi?id=178362 Reviewed by Tim Horton. Change comments in source list files. Also, pass explicit names for build files. * CMakeLists.txt: * PlatformGTK.cmake: * PlatformMac.cmake: * Sources.txt: * SourcesGTK.txt: * SourcesMac.txt: 2017-10-18 Commit Queue Unreviewed, rolling out r223321. https://bugs.webkit.org/show_bug.cgi?id=178476 This protocol change broke some internal builds (Requested by brrian__ on #webkit). Reverted changeset: "Web Inspector: provide a way to enable/disable event listeners" https://bugs.webkit.org/show_bug.cgi?id=177451 https://trac.webkit.org/changeset/223321 2017-10-18 Mark Lam The compiler should always register a structure when it adds its transitionWatchPointSet. https://bugs.webkit.org/show_bug.cgi?id=178420 Reviewed by Saam Barati and Filip Pizlo. Instead of invoking addLazily() to add a structure's transitionWatchpointSet, we now invoke Graph::registerAndWatchStructureTransition() on the structure. registerAndWatchStructureTransition() both registers the structure and add its transitionWatchpointSet to the plan desired watchpoints. Graph::registerAndWatchStructureTransition() is based on Graph::registerStructure() except registerAndWatchStructureTransition() adds the structure's transitionWatchpointSet unconditionally. * dfg/DFGArgumentsEliminationPhase.cpp: * dfg/DFGArrayMode.cpp: (JSC::DFG::ArrayMode::refine const): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsicCall): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::registerAndWatchStructureTransition): * dfg/DFGGraph.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetByValOnString): - The second set of addLazily()s is redundant. This set is executed only when prototypeChainIsSane is true, and prototypeChainIsSane can only be true if and only if we've executed the if statement above it. That preceding if statement already registerAndWatchStructureTransition() the same 2 structures. Hence, this second set can be deleted. * dfg/DFGWatchpointCollectionPhase.cpp: (JSC::DFG::WatchpointCollectionPhase::addLazily): - Deleted an unused function. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt): 2017-10-18 Yusuke Suzuki [JSC] Remove unused private name structure https://bugs.webkit.org/show_bug.cgi?id=178436 Reviewed by Sam Weinig. It is no longer used. This patch just removes it. * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::numberObjectStructure const): (JSC::JSGlobalObject::privateNameStructure const): Deleted. 2017-10-18 Ryosuke Niwa Fix macOS and iOS builds after r223594. * JavaScriptCore.xcodeproj/project.pbxproj: 2017-10-18 Yusuke Suzuki [JSC] __proto__ getter should be fast https://bugs.webkit.org/show_bug.cgi?id=178067 Reviewed by Saam Barati. In our ES6 class implementation, we access __proto__ field to retrieve super constructor. Currently, it is handled as an usual getter call to a generic function. And DFG just emits Call node for this. It is inefficient since typically we know the `prototype` of the given object when accessing `object.__proto__` since we emit CheckStructure for this `object`. If Structure has mono proto, we can immediately fold it to constant value. If it is poly proto, we can still change this to efficient access to poly proto slot. This patch implements GetPrototypeOf DFG node. This node efficiently accesses to prototype of the given object. And in AI and ByteCodeParser phase, we attempt to fold it to constant. ByteCodeParser's folding is a bit important since we have `callee.__proto__` code to get super constructor. If we can change this to constant, we can reify CallLinkInfo with this constant. This paves the way to optimizing ArrayConstructor super calls[1], which is particularly important for ARES-6 ML. And we also optimize Reflect.getPrototypeOf and Object.getPrototypeOf with this GetPrototypeOf node. Currently, __proto__ access for poly proto object is not handled well in IC. But we add code handling poly proto in GetPrototypeOf since Reflect.getPrototypeOf and Object.getPrototypeOf can use it. Once IC starts handling poly proto & intrinsic getter well, this code will be used for that too. This patch improves SixSpeed super.es6 by 3.42x. baseline patched super.es6 123.6666+-3.9917 ^ 36.1684+-1.0351 ^ definitely 3.4192x faster [1]: https://bugs.webkit.org/show_bug.cgi?id=178064 * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsicCall): (JSC::DFG::ByteCodeParser::handleIntrinsicGetter): (JSC::DFG::ByteCodeParser::handleGetById): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::fixupGetPrototypeOf): * dfg/DFGHeapLocation.cpp: (WTF::printInternal): * dfg/DFGHeapLocation.h: * dfg/DFGNode.h: (JSC::DFG::Node::hasHeapPrediction): (JSC::DFG::Node::shouldSpeculateFunction): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::speculateFunction): (JSC::DFG::SpeculativeJIT::speculateFinalObject): (JSC::DFG::SpeculativeJIT::compileGetPrototypeOf): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * 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::compileGetPrototypeOf): (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf): * jit/IntrinsicEmitter.cpp: (JSC::IntrinsicGetterAccessCase::canEmitIntrinsicGetter): (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter): * jit/JITOperations.h: * runtime/Intrinsic.cpp: (JSC::intrinsicName): * runtime/Intrinsic.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::booleanPrototype const): (JSC::JSGlobalObject::numberPrototype const): (JSC::JSGlobalObject::booleanObjectStructure const): * runtime/JSGlobalObjectFunctions.cpp: (JSC::globalFuncProtoGetter): * runtime/JSGlobalObjectFunctions.h: * runtime/ObjectConstructor.cpp: * runtime/ReflectObject.cpp: 2017-10-17 Ryan Haddad Unreviewed, rolling out r223523. A test for this change is failing on debug JSC bots. Reverted changeset: "[JSC] __proto__ getter should be fast" https://bugs.webkit.org/show_bug.cgi?id=178067 https://trac.webkit.org/changeset/223523 2017-10-17 Youenn Fablet Add preliminary support for fetch event https://bugs.webkit.org/show_bug.cgi?id=178171 Reviewed by Chris Dumez. Adding events * runtime/JSPromise.h: 2017-10-10 Yusuke Suzuki [JSC] __proto__ getter should be fast https://bugs.webkit.org/show_bug.cgi?id=178067 Reviewed by Saam Barati. In our ES6 class implementation, we access __proto__ field to retrieve super constructor. Currently, it is handled as an usual getter call to a generic function. And DFG just emits Call node for this. It is inefficient since typically we know the `prototype` of the given object when accessing `object.__proto__` since we emit CheckStructure for this `object`. If Structure has mono proto, we can immediately fold it to constant value. If it is poly proto, we can still change this to efficient access to poly proto slot. This patch implements GetPrototypeOf DFG node. This node efficiently accesses to prototype of the given object. And in AI and ByteCodeParser phase, we attempt to fold it to constant. ByteCodeParser's folding is a bit important since we have `callee.__proto__` code to get super constructor. If we can change this to constant, we can reify CallLinkInfo with this constant. This paves the way to optimizing ArrayConstructor super calls[1], which is particularly important for ARES-6 ML. And we also optimize Reflect.getPrototypeOf and Object.getPrototypeOf with this GetPrototypeOf node. Currently, __proto__ access for poly proto object is not handled well in IC. But we add code handling poly proto in GetPrototypeOf since Reflect.getPrototypeOf and Object.getPrototypeOf can use it. Once IC starts handling poly proto & intrinsic getter well, this code will be used for that too. This patch improves SixSpeed super.es6 by 3.42x. baseline patched super.es6 123.6666+-3.9917 ^ 36.1684+-1.0351 ^ definitely 3.4192x faster [1]: https://bugs.webkit.org/show_bug.cgi?id=178064 * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsicCall): (JSC::DFG::ByteCodeParser::handleIntrinsicGetter): (JSC::DFG::ByteCodeParser::handleGetById): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::fixupGetPrototypeOf): * dfg/DFGHeapLocation.cpp: (WTF::printInternal): * dfg/DFGHeapLocation.h: * dfg/DFGNode.h: (JSC::DFG::Node::hasHeapPrediction): (JSC::DFG::Node::shouldSpeculateFunction): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::speculateFunction): (JSC::DFG::SpeculativeJIT::speculateFinalObject): (JSC::DFG::SpeculativeJIT::compileGetPrototypeOf): * 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::compileGetPrototypeOf): (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf): * jit/IntrinsicEmitter.cpp: (JSC::IntrinsicGetterAccessCase::canEmitIntrinsicGetter): (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter): * runtime/Intrinsic.cpp: (JSC::intrinsicName): * runtime/Intrinsic.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/JSGlobalObjectFunctions.cpp: (JSC::globalFuncProtoGetter): * runtime/JSGlobalObjectFunctions.h: * runtime/ObjectConstructor.cpp: * runtime/ReflectObject.cpp: 2017-10-17 Keith Miller Change WebCore sources to work with unified source builds https://bugs.webkit.org/show_bug.cgi?id=178229 Rubber stamped by Tim Horton. * Configurations/FeatureDefines.xcconfig: 2017-10-15 Filip Pizlo Make some asserts into release asserts https://bugs.webkit.org/show_bug.cgi?id=178324 Reviewed by Saam Barati. These asserts are not on perf critical paths, so they might as well be release asserts. * runtime/DataView.h: (JSC::DataView::get): (JSC::DataView::set): 2017-10-16 JF Bastien JSRunLoopTimer: reduce likely race when used improperly https://bugs.webkit.org/show_bug.cgi?id=178298 Reviewed by Saam Barati. If an API user sets a timer on JSRunLoopTimer, and then racily destroys the JSRunLoopTimer while the timer is firing then it's possible for timerDidFire to cause a use-after-free and / or crash because e.g. m_apiLock becomes a nullptr while timerDidFire is executing. That results from an invalid use of JSRunLoopTimer, but we should try to be more resilient for that type of misuse because it's not necessarily easy to catch by inspection. With this change the only remaining race is if the timer fires, and then only timerDidFire's prologue executes, but not the load of the m_apiLock pointer from `this`. It's a much smaller race. Separately, I'll reach out to API users who are seemingly misusing the API. * runtime/JSRunLoopTimer.cpp: (JSC::JSRunLoopTimer::timerDidFire): put m_apiLock on the stack, and checks for nullptr. This prevents loading it twice off of `this` and turns a nullptr deref into "just" a use-after-free. (JSC::JSRunLoopTimer::~JSRunLoopTimer): acquire m_apiLock before calling m_vm->unregisterRunLoopTimer(this), which in turn does CFRunLoopRemoveTimer / CFRunLoopTimerInvalidate. This prevents timerDidFire from doing much while the timers are un-registered. ~JSRunLoopTimer also needs to set m_apiLock to nullptr before releasing the lock, so it needs its own local copy. 2017-10-15 Yusuke Suzuki [JSC] Perform module specifier validation at parsing time https://bugs.webkit.org/show_bug.cgi?id=178256 Reviewed by Darin Adler. This patch make module loader's `resolve` operation synchronous. And we validate module's requested module names when instantiating the module instead of satisfying module's dependencies. This change is not observable to users. But this is precise to the spec and this optimizes & simplifies the current module loader a bit by reducing object allocations. Previously, we have an object called pair in the module loader. This is pair of module's name and module's record. And we use it to link one module to dependent modules. Now, it is replaced with module's registry entry. We also change our loader functions to take a registry entry instead of a module key. Previous design is due to the consideration that these APIs may be exposed to users in whatwg/loader spec. However, this won't happen. This change removes unnecessary repeatedly hash map lookups. * builtins/ModuleLoaderPrototype.js: (globalPrivate.newRegistryEntry): (requestFetch): (requestInstantiate): (requestSatisfy): (link): (moduleEvaluation): (loadModule): * jsc.cpp: (GlobalObject::moduleLoaderResolve): * runtime/AbstractModuleRecord.cpp: (JSC::AbstractModuleRecord::finishCreation): (JSC::AbstractModuleRecord::hostResolveImportedModule): * runtime/JSGlobalObject.h: * runtime/JSModuleLoader.cpp: (JSC::JSModuleLoader::resolveSync): (JSC::JSModuleLoader::resolve): * runtime/JSModuleLoader.h: * runtime/ModuleLoaderPrototype.cpp: (JSC::moduleLoaderPrototypeResolveSync): 2017-10-14 Devin Rousso Web Inspector: provide a way to enable/disable event listeners https://bugs.webkit.org/show_bug.cgi?id=177451 Reviewed by Joseph Pecoraro. * inspector/protocol/DOM.json: Add `setEventListenerDisabled` command that enables/disables a specific event listener during event dispatch. When a disabled event listener is fired, the listener's callback will not be called. 2017-10-14 Yusuke Suzuki Reland "Add Above/Below comparisons for UInt32 patterns" https://bugs.webkit.org/show_bug.cgi?id=177281 Reviewed by Saam Barati. We reland this patch without DFGStrengthReduction change to see what causes regression in the iOS bot. Sometimes, we would like to have UInt32 operations in JS. While VM does not support UInt32 nicely, VM supports efficient Int32 operations. As long as signedness does not matter, we can just perform Int32 operations instead and recognize its bit pattern as UInt32. But of course, some operations respect signedness. The most frequently used one is comparison. Octane/zlib performs UInt32 comparison by performing `val >>> 0`. It emits op_urshift and op_unsigned. op_urshift produces UInt32 in Int32 form. And op_unsigned will generate Double value if the generated Int32 is < 0 (which should be UInt32). There is a chance for optimization. The given code pattern is the following. op_unsigned(op_urshift(@1)) lessThan:< op_unsigned(op_urshift(@2)) This can be converted to the following. op_urshift(@1) below:< op_urshift(@2) The above conversion is nice since 1. We can avoid op_unsigned. This could be unsignedness check in DFG. Since this check depends on the value of Int32, dropping this check is not as easy as removing Int32 edge filters. 2. We can perform unsigned comparison in Int32 form. We do not need to convert them to DoubleRep. Since the above comparison exists in Octane/zlib's *super* hot path, dropping op_unsigned offers huge win. At first, my patch attempts to convert the above thing in DFG pipeline. However it poses several problems. 1. MovHint is not well removed. It makes UInt32ToNumber (which is for op_unsigned) live. 2. UInt32ToNumber could cause an OSR exit. So if we have the following nodes, 2: UInt32ToNumber(@0) 3: MovHint(@2, xxx) 4: UInt32ToNumber(@1) 5: MovHint(@1, xxx) we could drop @5's MovHint. But @3 is difficult since @4 can exit. So, instead, we start introducing a simple optimization in the bytecode compiler. It performs pattern matching for op_urshift and comparison to drop op_unsigned. We adds op_below and op_above families to bytecodes. They only accept Int32 and perform unsigned comparison. This offers 4% performance improvement in Octane/zlib. baseline patched zlib x2 431.07483+-16.28434 414.33407+-9.38375 might be 1.0404x faster * bytecode/BytecodeDumper.cpp: (JSC::BytecodeDumper::printCompareJump): (JSC::BytecodeDumper::dumpBytecode): * bytecode/BytecodeDumper.h: * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/Opcode.h: (JSC::isBranch): * bytecode/PreciseJumpTargetsInlines.h: (JSC::extractStoredJumpTargetsForBytecodeOffset): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitJumpIfTrue): (JSC::BytecodeGenerator::emitJumpIfFalse): * bytecompiler/NodesCodegen.cpp: (JSC::BinaryOpNode::emitBytecode): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGIntegerRangeOptimizationPhase.cpp: * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCompareUnsigned): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGValidate.cpp: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileCompareBelow): (JSC::FTL::DFG::LowerDFGToB3::compileCompareBelowEq): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JIT.h: * jit/JITArithmetic.cpp: (JSC::JIT::emit_op_below): (JSC::JIT::emit_op_beloweq): (JSC::JIT::emit_op_jbelow): (JSC::JIT::emit_op_jbeloweq): (JSC::JIT::emit_compareUnsignedAndJump): (JSC::JIT::emit_compareUnsigned): * jit/JITArithmetic32_64.cpp: (JSC::JIT::emit_compareUnsignedAndJump): (JSC::JIT::emit_compareUnsigned): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * parser/Nodes.h: (JSC::ExpressionNode::isBinaryOpNode const): 2017-10-12 Yusuke Suzuki WebAssembly: Wasm functions should have either JSFunctionType or TypeOfShouldCallGetCallData https://bugs.webkit.org/show_bug.cgi?id=178210 Reviewed by Saam Barati. In Wasm, we have two JS functions exposed to users: WebAssemblyFunction and WebAssemblyWrapperFunction. The former is an exported wasm function and the latter is an imported & exported function. Since they have [[Call]], they should be categorized into "function" in typeof operation. However, these functions do not implement our function protocol correctly. They inherit JSFunction. But JSType of WebAssemblyFunction is WebAssemblyFunctionType, and one of WebAssemblyWrapperFunction is ObjectType. Since both do not have TypeOfShouldCallGetCallData, they return "object" when performing typeof operation. In this patch, we address the above issue by the following 2 fixes. 1. We add TypeOfShouldCallGetCallData to WebAssemblyFunction. This is the same way how we implement InternalFunction. Since WebAssemblyFunction requires WebAssemblyFunctionType for fast checking in Wasm implementation, we cannot make this JSFunctionType. 2. On the other hand, WebAssemblyWrapperFunction does not require a specific JSType. So this patch changes JSType of WebAssemblyWrapperFunction to JSFunctionType. JSFunctionType can be usable for derived classes of JSFunction (e.g. JSCustomGetterSetterFunction). * wasm/js/WebAssemblyFunction.h: (JSC::WebAssemblyFunction::signatureIndex const): Deleted. (JSC::WebAssemblyFunction::wasmEntrypointLoadLocation const): Deleted. (JSC::WebAssemblyFunction::callableFunction const): Deleted. (JSC::WebAssemblyFunction::jsEntrypoint): Deleted. (JSC::WebAssemblyFunction::offsetOfWasmEntrypointLoadLocation): Deleted. * wasm/js/WebAssemblyWrapperFunction.cpp: (JSC::WebAssemblyWrapperFunction::createStructure): * wasm/js/WebAssemblyWrapperFunction.h: (JSC::WebAssemblyWrapperFunction::signatureIndex const): Deleted. (JSC::WebAssemblyWrapperFunction::wasmEntrypointLoadLocation const): Deleted. (JSC::WebAssemblyWrapperFunction::callableFunction const): Deleted. (JSC::WebAssemblyWrapperFunction::function): Deleted. 2017-10-12 Per Arne Vollan [Win64] JSC compile error. https://bugs.webkit.org/show_bug.cgi?id=178213 Reviewed by Alex Christensen. Add static cast from int64 to uintptr_t. * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::executeOSRExit): 2017-09-29 Filip Pizlo Enable gigacage on iOS https://bugs.webkit.org/show_bug.cgi?id=177586 Reviewed by JF Bastien. The hardest part of enabling Gigacage on iOS is that it requires loading global variables while executing JS, so the LLInt needs to know how to load from global variables on all platforms that have Gigacage. So, this teaches ARM64 how to load from global variables. Also, this makes the code handle disabling the gigacage a bit better. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::caged): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::cage): (JSC::AssemblyHelpers::cageConditionally): * offlineasm/arm64.rb: * offlineasm/asm.rb: * offlineasm/instructions.rb: 2017-10-11 Sam Weinig Remove out-parameter variants of copyToVector https://bugs.webkit.org/show_bug.cgi?id=178155 Reviewed by Tim Horton. * inspector/ScriptDebugServer.cpp: (Inspector::ScriptDebugServer::dispatchBreakpointActionLog): (Inspector::ScriptDebugServer::dispatchBreakpointActionSound): (Inspector::ScriptDebugServer::dispatchBreakpointActionProbe): (Inspector::ScriptDebugServer::dispatchDidParseSource): (Inspector::ScriptDebugServer::dispatchFailedToParseSource): (Inspector::ScriptDebugServer::dispatchFunctionToListeners): Replace out-parameter based copyToVector, with one that returns a Vector. 2017-10-12 Yusuke Suzuki Support integrity="" on module scripts https://bugs.webkit.org/show_bug.cgi?id=177959 Reviewed by Sam Weinig. This patch adds Subresource Integrity check for module scripts. Currently, only top-level module can be verified with integrity parameter since there is no way to perform integrity check onto the imported modules. In JSC side, we add `parameters` to the entry point of the module loader pipeline. This is fetching parameters and used when fetching modules. We separately pass this parameters to the pipeline along with the script fetcher. The script fetcher is only one for module graph since this is the initiator of this module graph loading. On the other hand, this parameters is for each module fetching. While setting "integrity" parameters to this script fetcher is sufficient to pass parameters to top-level-module's fetching, it is not enough for the future extension. In the future, we will investigate a way to pass parameters to each non-top-level module. At that time, this `parameters` should be per-module. This is because "integrity" value should be different for each module. For example, we will accept some form of syntax to add parameters to `import`. Some proposed syntax is like https://discourse.wicg.io/t/specifying-nonce-or-integrity-when-importing-modules/1861 import "./xxx.js" integrity "xxxxxxx" In this case, this `parameters` will be passed to "./xxx.js" module fetching. This `parameters` should be different from the one of top-level-module's one. That's why we need per-module `parameters` and why this patch adds `parameters` to the module pipeline. On the other hand, we also want to keep script fetcher. This `per-module-graph` thing is important to offer module-graph-wide information. For example, import.meta would have `import.meta.scriptElement`, which is the script element fetching the module graph including this. So, we keep the both, script fetcher and parameters. https://github.com/tc39/proposal-import-meta This parameters will be finally used by pipeline's fetch hook, and WebCore side can use this parameters to fetch modules. We also further clean up the module pipeline by dropping unnecessary features. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * builtins/ModuleLoaderPrototype.js: (requestFetch): (requestInstantiate): (requestSatisfy): (loadModule): (loadAndEvaluateModule): This loadAndEvaluateModule should be implemented by just calling loadModule and linkAndEvaluateModule. We can drop requestReady and requestLink. (requestLink): Deleted. (requestImportModule): Deleted. * jsc.cpp: (GlobalObject::moduleLoaderImportModule): (GlobalObject::moduleLoaderFetch): import and fetch hook takes parameters. Currently, we always pass `undefined` for import hook. When dynamic `import()` is extended to accept additional parameters like integrity, this parameters will be replaced with the actual value. (functionLoadModule): (runWithOptions): * runtime/Completion.cpp: (JSC::loadAndEvaluateModule): (JSC::loadModule): (JSC::importModule): * runtime/Completion.h: * runtime/JSGlobalObject.h: * runtime/JSGlobalObjectFunctions.cpp: (JSC::globalFuncImportModule): * runtime/JSModuleLoader.cpp: (JSC::JSModuleLoader::loadAndEvaluateModule): (JSC::JSModuleLoader::loadModule): (JSC::JSModuleLoader::requestImportModule): (JSC::JSModuleLoader::importModule): (JSC::JSModuleLoader::fetch): * runtime/JSModuleLoader.h: * runtime/JSScriptFetchParameters.cpp: Added. (JSC::JSScriptFetchParameters::destroy): * runtime/JSScriptFetchParameters.h: Added. (JSC::JSScriptFetchParameters::createStructure): (JSC::JSScriptFetchParameters::create): (JSC::JSScriptFetchParameters::parameters const): (JSC::JSScriptFetchParameters::JSScriptFetchParameters): Add ScriptFetchParameters' JSCell wrapper, JSScriptFetchParameters. It is used in the module pipeline. * runtime/JSType.h: * runtime/ModuleLoaderPrototype.cpp: (JSC::moduleLoaderPrototypeFetch): * runtime/ScriptFetchParameters.h: Added. (JSC::ScriptFetchParameters::~ScriptFetchParameters): Add ScriptFetchParameters. We can define our own custom ScriptFetchParameters by inheriting this class. WebCore creates ModuleFetchParameters by inheriting this. * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2017-10-11 Yusuke Suzuki import.meta should not be assignable https://bugs.webkit.org/show_bug.cgi?id=178202 Reviewed by Saam Barati. `import.meta` cannot be used for LHS. This patch adds MetaPropertyNode and make NewTargetNode and ImportMetaNode as derived classes of MetaPropertyNode. We change the parser not to allow assignments for MetaPropertyNode. * bytecompiler/NodesCodegen.cpp: (JSC::ImportMetaNode::emitBytecode): * parser/ASTBuilder.h: (JSC::ASTBuilder::createImportMetaExpr): (JSC::ASTBuilder::isMetaProperty): (JSC::ASTBuilder::isImportMeta): * parser/NodeConstructors.h: (JSC::MetaPropertyNode::MetaPropertyNode): (JSC::NewTargetNode::NewTargetNode): (JSC::ImportMetaNode::ImportMetaNode): * parser/Nodes.h: (JSC::ExpressionNode::isMetaProperty const): (JSC::ExpressionNode::isImportMeta const): * parser/Parser.cpp: (JSC::Parser::metaPropertyName): (JSC::Parser::parseAssignmentExpression): (JSC::Parser::parseMemberExpression): (JSC::Parser::parseUnaryExpression): * parser/Parser.h: * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createImportMetaExpr): (JSC::SyntaxChecker::isMetaProperty): (JSC::SyntaxChecker::isImportMeta): 2017-10-11 Saam Barati Runtime disable poly proto because it may be a 3-4% Speedometer regression https://bugs.webkit.org/show_bug.cgi?id=178192 Reviewed by JF Bastien. * runtime/Options.h: * runtime/StructureInlines.h: (JSC::Structure::shouldConvertToPolyProto): 2017-10-11 Commit Queue Unreviewed, rolling out r223113 and r223121. https://bugs.webkit.org/show_bug.cgi?id=178182 Reintroduced 20% regression on Kraken (Requested by rniwa on #webkit). Reverted changesets: "Enable gigacage on iOS" https://bugs.webkit.org/show_bug.cgi?id=177586 https://trac.webkit.org/changeset/223113 "Use one virtual allocation for all gigacages and their runways" https://bugs.webkit.org/show_bug.cgi?id=178050 https://trac.webkit.org/changeset/223121 2017-10-11 Michael Saboff Update JavaScriptCore/ucd/CaseFolding.txt to Unicode database 10.0 https://bugs.webkit.org/show_bug.cgi?id=178106 Reviewed by Keith Miller. * ucd/CaseFolding.txt: 2017-10-11 Caio Lima Object properties are undefined in super.call() but not in this.call() https://bugs.webkit.org/show_bug.cgi?id=177230 Reviewed by Saam Barati. Bytecode generation for "super.call(...)" or "super.apply(...)" shouldn't be considered as CallFunctionCallDotNode or ApplyFunctionCallDotNode because they should be considered as common super property access as any other function. According to spec[1], "super" is not refering to parent constructor. [1] - https://tc39.github.io/ecma262/#sec-super-keyword-runtime-semantics-evaluation * parser/ASTBuilder.h: (JSC::ASTBuilder::makeFunctionCallNode): * parser/Parser.cpp: (JSC::Parser::parseMemberExpression): * parser/SyntaxChecker.h: (JSC::SyntaxChecker::makeFunctionCallNode): 2017-10-11 Yusuke Suzuki [JSC] Drop Instantiate hook in ES6 module loader https://bugs.webkit.org/show_bug.cgi?id=178162 Reviewed by Sam Weinig. This patch is a part of patch series for module loader refactoring to adopt integrity="" parameters and introduce new whatwg module import mechanism. In this patch, we drop instantiate hook in module loader. This hook is originally introduced because it is defined in whatwg/loader spec. But this hook is not used in our implementation, and this hook won't be used since (1) whatwg/loader spec is abandoned, and (2) this type of hooks should be done in Service Workers. In addition, this patch applies some cleaning up of our module loader JS code to simplify things. This change paves the way to more efficient loader implementation with great flexibility to adopt integrity="" parameters. * builtins/ModuleLoaderPrototype.js: (requestInstantiate): (provideFetch): provide is changed to provideFetch since we only used this function with Fetch stage parameter. (fulfillInstantiate): Deleted. (commitInstantiated): Deleted. (instantiation): Deleted. They are merged into requestInstantiate code. This is simpler. (provide): Deleted. * jsc.cpp: * runtime/Completion.cpp: (JSC::loadAndEvaluateModule): (JSC::loadModule): * runtime/JSGlobalObject.cpp: * runtime/JSGlobalObject.h: * runtime/JSModuleLoader.cpp: (JSC::JSModuleLoader::provideFetch): (JSC::JSModuleLoader::provide): Deleted. Changed to provideFetch. (JSC::JSModuleLoader::instantiate): Deleted. Drop this hook. * runtime/JSModuleLoader.h: * runtime/ModuleLoaderPrototype.cpp: (JSC::moduleLoaderPrototypeInstantiate): Deleted. Drop this hook. 2017-10-10 Saam Barati Prototype structure transition should be a deferred transition https://bugs.webkit.org/show_bug.cgi?id=177734 Reviewed by Keith Miller. Absence ObjectPropertyConditions work by verifying both that the Structure does not have a particular property and that its prototype has remained constant. However, the prototype transition was firing the transition watchpoint before setting the object's structure. This meant that isValid for Absence would never return false because the prototype changed. Clearly this is wrong. The reason this didn't break OPCs in general is that we'd also check if we could still watch the OPC. In this case, we can't still watch it because we're inspecting a structure with an invalidated transition watchpoint. To fix this weird quirk of the code, I'm making it so that doing a prototype transition uses the DeferredStructureTransitionWatchpointFire machinery. This patch also fixes some dead code that I left in regarding poly proto in OPC. * bytecode/PropertyCondition.cpp: (JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint const): * runtime/JSObject.cpp: (JSC::JSObject::setPrototypeDirect): * runtime/Structure.cpp: (JSC::Structure::changePrototypeTransition): * runtime/Structure.h: 2017-10-10 Robin Morisset Avoid allocating useless landingBlocks in DFGByteCodeParser::handleInlining() https://bugs.webkit.org/show_bug.cgi?id=177926 Reviewed by Saam Barati. When doing polyvariant inlining, there used to be a landing block for each callee, each of which was then linked to a continuation block. With this change, we allocate the continuation block first, and pass it to the inlining routine so that op_ret in the callee link directly to it. The only subtlety is that when inlining an intrinsic we must do the jump by hand, and also remember to call processSetLocalQueue with nextOffset before it. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::inlineCall): (JSC::DFG::ByteCodeParser::attemptToInlineCall): (JSC::DFG::ByteCodeParser::handleInlining): (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): (JSC::DFG::ByteCodeParser::parse): 2017-10-10 Guillaume Emont Fix compilation when MASM_PROBE (and therefore DFG) are disabled https://bugs.webkit.org/show_bug.cgi?id=178134 Reviewed by Saam Barati. * bytecode/CodeBlock.cpp: * bytecode/CodeBlock.h: Disable some code when building without DFG_JIT. 2017-10-10 Sam Weinig Replace copyKeysToVector/copyValuesToVector with copyToVector(map.keys())/copyToVector(map.values()) https://bugs.webkit.org/show_bug.cgi?id=178102 Reviewed by Tim Horton. * inspector/agents/InspectorDebuggerAgent.cpp: (Inspector::InspectorDebuggerAgent::clearInspectorBreakpointState): 2017-10-10 Michael Saboff Unreviewed build fix. Removed unused lambda capture. * yarr/YarrPattern.cpp: (JSC::Yarr::CharacterClassConstructor::appendInverted): 2017-10-10 Saam Barati The prototype cache should be aware of the Executable it generates a Structure for https://bugs.webkit.org/show_bug.cgi?id=177907 Reviewed by Filip Pizlo. This patch renames PrototypeMap to StructureCache because it is no longer a map of the prototypes in the VM. It's only used to cache Structures during object construction. The main change of this patch is to guarantee that Structures generated by the create_this originating from different two different Executables' bytecode won't hash-cons to the same thing. Previously, we could hash-cons them depending on the JSObject* prototype pointer. This would cause the last thing that hash-consed to overwrite the Structure's poly proto watchpoint. This happened because when we initialize a JSFunction's ObjectAllocationProfile, we set the resulting Structure's poly proto watchpoint. This could cause a Structure generating from some Executable e1 to end up with the poly proto watchpoint for another Executable e2 simply because JSFunctions backed by e1 and e2 shared the same prototype. Then, based on profiling information, we may fire the wrong Executable's poly proto watchpoint. This patch fixes this bug by guaranteeing that Structures generating from create_this for different Executables are unique even if they share the same prototype by adding the FunctionExecutable* as another field in PrototypeKey. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * bytecode/InternalFunctionAllocationProfile.h: (JSC::InternalFunctionAllocationProfile::createAllocationStructureFromBase): * bytecode/ObjectAllocationProfile.cpp: (JSC::ObjectAllocationProfile::initializeProfile): * dfg/DFGOperations.cpp: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/InternalFunction.cpp: (JSC::InternalFunction::createSubclassStructureSlow): * runtime/IteratorOperations.cpp: (JSC::createIteratorResultObjectStructure): * runtime/JSBoundFunction.cpp: (JSC::getBoundFunctionStructure): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/ObjectConstructor.h: (JSC::constructEmptyObject): * runtime/PrototypeKey.h: (JSC::PrototypeKey::PrototypeKey): (JSC::PrototypeKey::executable const): (JSC::PrototypeKey::operator== const): (JSC::PrototypeKey::hash const): * runtime/PrototypeMap.cpp: Removed. * runtime/PrototypeMap.h: Removed. * runtime/StructureCache.cpp: Copied from Source/JavaScriptCore/runtime/PrototypeMap.cpp. (JSC::StructureCache::createEmptyStructure): (JSC::StructureCache::emptyStructureForPrototypeFromBaseStructure): (JSC::StructureCache::emptyObjectStructureForPrototype): (JSC::PrototypeMap::createEmptyStructure): Deleted. (JSC::PrototypeMap::emptyStructureForPrototypeFromBaseStructure): Deleted. (JSC::PrototypeMap::emptyObjectStructureForPrototype): Deleted. * runtime/StructureCache.h: Copied from Source/JavaScriptCore/runtime/PrototypeMap.h. (JSC::StructureCache::StructureCache): (JSC::PrototypeMap::PrototypeMap): Deleted. * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2017-10-09 Yusuke Suzuki `async` should be able to be used as an imported binding name https://bugs.webkit.org/show_bug.cgi?id=176573 Reviewed by Saam Barati. Previously, we have ASYNC keyword in the parser. This is introduced only for performance, and ECMA262 spec does not categorize "async" to keyword. This makes parser code complicated, since ASYNC should be handled as IDENT. If we missed this ASYNC keyword, we cause a bug. For example, import declaration failed to bind imported binding to the name "async" because the parser considered ASYNC as keyword. This patch removes ASYNC keyword from the parser. By carefully handling ASYNC, we can keep the current performance without using this ASYNC keyword. We also add `escaped` field to token data since contextual keyword is valid only if it does not contain any escape sequences. We fix bunch of contextual keyword use with this fix too e.g. `of in for-of`. This improves test262 score. * parser/Keywords.table: * parser/Lexer.cpp: (JSC::Lexer::parseIdentifier): (JSC::Lexer::parseIdentifier): (JSC::Lexer::parseIdentifierSlowCase): * parser/Parser.cpp: (JSC::Parser::parseStatementListItem): (JSC::Parser::parseForStatement): (JSC::Parser::parseStatement): (JSC::Parser::maybeParseAsyncFunctionDeclarationStatement): (JSC::Parser::parseClass): (JSC::Parser::parseExportDeclaration): (JSC::Parser::parseAssignmentExpression): (JSC::Parser::parseProperty): (JSC::Parser::parsePrimaryExpression): (JSC::Parser::parseMemberExpression): (JSC::Parser::printUnexpectedTokenText): * parser/Parser.h: (JSC::Parser::matchContextualKeyword): * parser/ParserTokens.h: * runtime/CommonIdentifiers.h: 2017-10-09 Saam Barati We don't need to clearEmptyObjectStructureForPrototype because JSGlobalObject* is part of the cache's key https://bugs.webkit.org/show_bug.cgi?id=177987 Reviewed by Filip Pizlo. * runtime/JSProxy.cpp: (JSC::JSProxy::setTarget): * runtime/PrototypeMap.cpp: (JSC::PrototypeMap::clearEmptyObjectStructureForPrototype): Deleted. * runtime/PrototypeMap.h: 2017-10-09 Filip Pizlo JSCell::didBecomePrototype is racy https://bugs.webkit.org/show_bug.cgi?id=178110 Reviewed by Saam Barati. The indexing type can be modified by any thread using CAS. So, we need to use atomics when modifying it. We don't need to use atomics when reading it though (since it's just one field). * runtime/JSCellInlines.h: (JSC::JSCell::didBecomePrototype): 2017-09-29 Filip Pizlo Enable gigacage on iOS https://bugs.webkit.org/show_bug.cgi?id=177586 Reviewed by JF Bastien. The hardest part of enabling Gigacage on iOS is that it requires loading global variables while executing JS, so the LLInt needs to know how to load from global variables on all platforms that have Gigacage. So, this teaches ARM64 how to load from global variables. Also, this makes the code handle disabling the gigacage a bit better. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::caged): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::cage): (JSC::AssemblyHelpers::cageConditionally): * offlineasm/arm64.rb: * offlineasm/asm.rb: * offlineasm/instructions.rb: 2017-10-09 Robin Morisset Evaluate the benefit of skipping dead code in the DFGByteCodeParser when a function returns in its first block https://bugs.webkit.org/show_bug.cgi?id=177925 Reviewed by Saam Barati. We used to do a rather weird "optimisation" in the bytecode parser: when a function would return in its first block, the rest of the function was skipped. Since it has no actual impact on any benchmarks from what I could see, I removed that code. It allows some changes to parseBlock(), since it now returns void and no-longer bool (it was returning a boolean that said whether that case happened or not). * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::parseCodeBlock): 2017-10-09 Robin Morisset Refactor the inliner to simplify block linking https://bugs.webkit.org/show_bug.cgi?id=177922 Reviewed by Saam Barati. The biggest refactor changes the way blocks are linked. In DFGByteCodeParser, most terminals (such as Jump or Branch) jump to nullptr initially, and have some metadata indicating the bytecode index corresponding to their targets. They are later linked to the right basic block using two fields of InlineStackEntry: - m_unlinkedBlocks is just a worklist of blocks with a terminal that needs to be linked - m_linkingTargets is a dictionary from bytecode indices to BasicBlock* Before refactoring, every block was automatically added to both of these fields, for the InlineStackEntry of whatever function allocated it. This created a significant number of corner cases, such as blocks allocated in a caller, with a terminal written by an inlined callee and pointing to a block in the callee, or blocks allocated in an inline callee, with a terminal written by the caller after it returns and pointing to a block in the caller, or blocks with a manually linked terminal that needs to be taken off m_unlinkedBlocks. I changed things so that blocks are only added to m_unlinkedBlocks when their terminal gets written (see the LAST_OPCODE macro) making it a lot easier to be in the "right" InlineStackEntry, that is the one that holds their target in its m_linkingTargets field. There are a few much smaller refactors in this patch: - parse() is now of type void insted of bool (it was always returning true) - The 7 and 8 arguments of handleCall were inlined in its 3 arguments version for readability - The 9 argument version was cleaned up and simplified - I made separate allocateBlock routines because the little dance with adoptRef(* new BasicBlock(...)) was being repeated in lots of places, and typos in that were a major source of bugs during other refactorings - Jumps are now created with explicit addJumpTo() functions, providing some sanity checking through asserts and didLink() - Blocks are only added to m_unlinkedBlocks if they end in a terminal that linkBlock works with (see LAST_OPCODE) * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::addToGraph): (JSC::DFG::ByteCodeParser::handleCall): (JSC::DFG::ByteCodeParser::refineStatically): (JSC::DFG::ByteCodeParser::handleRecursiveTailCall): (JSC::DFG::ByteCodeParser::handleVarargsCall): (JSC::DFG::ByteCodeParser::inlineCall): (JSC::DFG::ByteCodeParser::attemptToInlineCall): (JSC::DFG::ByteCodeParser::handleInlining): (JSC::DFG::ByteCodeParser::handleIntrinsicCall): (JSC::DFG::ByteCodeParser::handleConstantInternalFunction): (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::parseCodeBlock): (JSC::DFG::ByteCodeParser::parse): (JSC::DFG::parse): (JSC::DFG::ByteCodeParser::cancelLinkingForBlock): Deleted. * dfg/DFGByteCodeParser.h: * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThreadImpl): 2017-10-09 Michael Saboff Implement RegExp Unicode property escapes https://bugs.webkit.org/show_bug.cgi?id=172069 Reviewed by JF Bastien. Added Unicode Properties by extending the existing CharacterClass processing. Introduced a new Python script, generateYarrUnicodePropertyTables.py, that parses Unicode Database files to create character class data. The result is a set of functions that return character classes, one for each of the required Unicode properties. There are many cases where many properties are handled by one function, primarily due to property aliases, but also due to Script_Extension properties that are the same as the Script property for the same script value. Extended the BuiltInCharacterClassID enum so it can be used also for Unicode property character classes. Unicode properties are the enum value BaseUnicodePropertyID plus a zero based value, that value being the index to the corrensponding character class function. The generation script also creates static hashing tables similar to what we use for the generated .lut.h lookup table files. These hashing tables map property names to the function index. Using these hashing tables, we can lookup a property name and if present convert it to a function index. We add that index to BaseUnicodePropertyID to create a BuiltInCharacterClassID. When we do syntax parsing, we convert the property to its corresponding BuiltInCharacterClassID. When doing real parsing we takes the returned BuiltInCharacterClassID and use it to get the actual character class by calling the corresponding generated function. Added a new CharacterClass constructor that can take literal arrays for ranges and matches to make the creation of large static character classes more efficent. Since the Unicode character classes typically have more matches and ranges, the character class matching in the interpreter has been updated to use binary searching for matches and ranges with more than 6 entries. * CMakeLists.txt: * DerivedSources.make: * JavaScriptCore.xcodeproj/project.pbxproj: * Scripts/generateYarrUnicodePropertyTables.py: Added. (openOrExit): (openUCDFileOrExit): (verifyUCDFilesExist): (ceilingToPowerOf2): (Aliases): (Aliases.__init__): (Aliases.parsePropertyAliasesFile): (Aliases.parsePropertyValueAliasesFile): (Aliases.globalAliasesFor): (Aliases.generalCategoryAliasesFor): (Aliases.generalCategoryForAlias): (Aliases.scriptAliasesFor): (Aliases.scriptNameForAlias): (PropertyData): (PropertyData.__init__): (PropertyData.setAliases): (PropertyData.makeCopy): (PropertyData.getIndex): (PropertyData.getCreateFuncName): (PropertyData.addMatch): (PropertyData.addRange): (PropertyData.addMatchUnorderedForMatchesAndRanges): (PropertyData.addRangeUnorderedForMatchesAndRanges): (PropertyData.addMatchUnordered): (PropertyData.addRangeUnordered): (PropertyData.removeMatchFromRanges): (PropertyData.removeMatch): (PropertyData.dumpMatchData): (PropertyData.dump): (PropertyData.dumpAll): (PropertyData.dumpAll.std): (PropertyData.createAndDumpHashTable): (Scripts): (Scripts.__init__): (Scripts.parseScriptsFile): (Scripts.parseScriptExtensionsFile): (Scripts.dump): (GeneralCategory): (GeneralCategory.__init__): (GeneralCategory.createSpecialPropertyData): (GeneralCategory.findPropertyGroupFor): (GeneralCategory.addNextCodePoints): (GeneralCategory.parse): (GeneralCategory.dump): (BinaryProperty): (BinaryProperty.__init__): (BinaryProperty.parsePropertyFile): (BinaryProperty.dump): * Scripts/hasher.py: Added. (stringHash): * Sources.txt: * ucd/DerivedBinaryProperties.txt: Added. * ucd/DerivedCoreProperties.txt: Added. * ucd/DerivedNormalizationProps.txt: Added. * ucd/PropList.txt: Added. * ucd/PropertyAliases.txt: Added. * ucd/PropertyValueAliases.txt: Added. * ucd/ScriptExtensions.txt: Added. * ucd/Scripts.txt: Added. * ucd/UnicodeData.txt: Added. * ucd/emoji-data.txt: Added. * yarr/Yarr.h: * yarr/YarrInterpreter.cpp: (JSC::Yarr::Interpreter::testCharacterClass): * yarr/YarrParser.h: (JSC::Yarr::Parser::parseEscape): (JSC::Yarr::Parser::parseTokens): (JSC::Yarr::Parser::isUnicodePropertyValueExpressionChar): (JSC::Yarr::Parser::tryConsumeUnicodePropertyExpression): * yarr/YarrPattern.cpp: (JSC::Yarr::CharacterClassConstructor::appendInverted): (JSC::Yarr::YarrPatternConstructor::atomBuiltInCharacterClass): (JSC::Yarr::YarrPatternConstructor::atomCharacterClassBuiltIn): (JSC::Yarr::YarrPattern::errorMessage): (JSC::Yarr::PatternTerm::dump): * yarr/YarrPattern.h: (JSC::Yarr::CharacterRange::CharacterRange): (JSC::Yarr::CharacterClass::CharacterClass): (JSC::Yarr::YarrPattern::reset): (JSC::Yarr::YarrPattern::unicodeCharacterClassFor): * yarr/YarrUnicodeProperties.cpp: Added. (JSC::Yarr::HashTable::entry const): (JSC::Yarr::unicodeMatchPropertyValue): (JSC::Yarr::unicodeMatchProperty): (JSC::Yarr::createUnicodeCharacterClassFor): * yarr/YarrUnicodeProperties.h: Added. 2017-10-09 Commit Queue Unreviewed, rolling out r223015 and r223025. https://bugs.webkit.org/show_bug.cgi?id=178093 Regressed Kraken on iOS by 20% (Requested by keith_mi_ on #webkit). Reverted changesets: "Enable gigacage on iOS" https://bugs.webkit.org/show_bug.cgi?id=177586 http://trac.webkit.org/changeset/223015 "Unreviewed, disable Gigacage on ARM64 Linux" https://bugs.webkit.org/show_bug.cgi?id=177586 http://trac.webkit.org/changeset/223025 2017-10-09 Keith Miller Unreviewed, sort unified sources again now that they are numbered numerically rather than lexicographically. * JavaScriptCore.xcodeproj/project.pbxproj: 2017-10-09 Ryan Haddad Unreviewed, rolling out r223022. This change introduced 18 test262 failures. Reverted changeset: "`async` should be able to be used as an imported binding name" https://bugs.webkit.org/show_bug.cgi?id=176573 http://trac.webkit.org/changeset/223022 2017-10-09 Robin Morisset Make the names of the options consistent https://bugs.webkit.org/show_bug.cgi?id=177933 Reviewed by Saam Barati. I added an alias so the old spelling still works. I also fixed a bunch of typos in comments all around the codebase. * b3/B3LowerToAir.cpp: * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGIntegerRangeOptimizationPhase.cpp: * dfg/DFGOperations.h: * dfg/DFGSSAConversionPhase.h: * dfg/DFGSpeculativeJIT.h: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::lower): * ftl/FTLOSREntry.cpp: (JSC::FTL::prepareOSREntry): * jit/CallFrameShuffler.cpp: (JSC::CallFrameShuffler::prepareForTailCall): * parser/Nodes.h: * parser/Parser.cpp: (JSC::Parser::parseExportDeclaration): * runtime/Options.h: 2017-10-09 Oleksandr Skachkov Safari 10 /11 problem with if (!await get(something)). https://bugs.webkit.org/show_bug.cgi?id=176685 Reviewed by Saam Barati. Using unary operator before `await` lead to count it as identifier. According to spec https://tc39.github.io/ecma262/#sec-async-function-definitions and Note 1 `await` is as AwaitExpression and it is allowed to use unary operator * parser/Parser.cpp: (JSC::Parser::parsePrimaryExpression): 2017-10-07 Filip Pizlo direct-construct-arity-mismatch.js can have GCs that take ~70ms if you force poly proto and disable generational GC https://bugs.webkit.org/show_bug.cgi?id=178051 Reviewed by Saam Barati. After I studied the profile of this test, I found two pathologies in our code relating to prototypes. I think that now that we support poly proto, it's more likely for these pathologies to happen. Also, the fact that we force poly proto in some tests, it's possible for one of our tests to trigger these pathologies. - WeakGCMap::m_prototoypes is the set of all prototypes. That's super dangerous. This patch turns this into a bit in the JSCell header. It uses the last spare bit in indexingTypeAndMisc. Note that we still have 6 spare bits in cellState, but those are a bit more annoying to get at. - WeakGCMap registers itself with GC using a std::function. That means allocating things in the malloc heap. This changes it to a virtual method on WeakGCMap. I don't know for sure that this is a problem area, but there are places where we could allocate a lot of WeakGCMaps, like if we have a lot of transition tables. It's good to reduce the amount of memory those require. Also, I saw a FIXME about turning the std::tuple in PrototypeMap into a struct, so I did that while I was at it. I initially thought that this would have to be part of my solution, but it turned out not to be. I think it's worth landing anyway since it makes the code a lot more clear. This fixes the timeout in that test and probably reduces memory consumption. * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGOperations.cpp: * heap/Heap.cpp: (JSC::Heap::pruneStaleEntriesFromWeakGCMaps): (JSC::Heap::registerWeakGCMap): (JSC::Heap::unregisterWeakGCMap): * heap/Heap.h: * inspector/JSInjectedScriptHostPrototype.cpp: (Inspector::JSInjectedScriptHostPrototype::finishCreation): * inspector/JSJavaScriptCallFramePrototype.cpp: (Inspector::JSJavaScriptCallFramePrototype::finishCreation): * runtime/ArrayIteratorPrototype.cpp: (JSC::ArrayIteratorPrototype::finishCreation): * runtime/ArrayPrototype.cpp: (JSC::ArrayPrototype::finishCreation): * runtime/AsyncFromSyncIteratorPrototype.cpp: (JSC::AsyncFromSyncIteratorPrototype::finishCreation): * runtime/AsyncFunctionPrototype.cpp: (JSC::AsyncFunctionPrototype::finishCreation): * runtime/AsyncGeneratorFunctionPrototype.cpp: (JSC::AsyncGeneratorFunctionPrototype::finishCreation): * runtime/AsyncGeneratorPrototype.cpp: (JSC::AsyncGeneratorPrototype::finishCreation): * runtime/AsyncIteratorPrototype.cpp: (JSC::AsyncIteratorPrototype::finishCreation): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/GeneratorFunctionPrototype.cpp: (JSC::GeneratorFunctionPrototype::finishCreation): * runtime/GeneratorPrototype.cpp: (JSC::GeneratorPrototype::finishCreation): * runtime/IndexingType.h: * runtime/IteratorPrototype.cpp: (JSC::IteratorPrototype::finishCreation): * runtime/JSCInlines.h: * runtime/JSCell.h: * runtime/JSCellInlines.h: (JSC::JSCell::mayBePrototype const): (JSC::JSCell::didBecomePrototype): * runtime/JSObject.cpp: (JSC::JSObject::notifyPresenceOfIndexedAccessors): (JSC::JSObject::setPrototypeDirect): * runtime/JSProxy.cpp: (JSC::JSProxy::setTarget): * runtime/MapIteratorPrototype.cpp: (JSC::MapIteratorPrototype::finishCreation): * runtime/MapPrototype.cpp: (JSC::MapPrototype::finishCreation): * runtime/ObjectPrototype.cpp: (JSC::ObjectPrototype::finishCreation): * runtime/PrototypeKey.h: Added. (JSC::PrototypeKey::PrototypeKey): (JSC::PrototypeKey::prototype const): (JSC::PrototypeKey::inlineCapacity const): (JSC::PrototypeKey::classInfo const): (JSC::PrototypeKey::globalObject const): (JSC::PrototypeKey::operator== const): (JSC::PrototypeKey::operator!= const): (JSC::PrototypeKey::operator bool const): (JSC::PrototypeKey::isHashTableDeletedValue const): (JSC::PrototypeKey::hash const): (JSC::PrototypeKeyHash::hash): (JSC::PrototypeKeyHash::equal): * runtime/PrototypeMap.cpp: (JSC::PrototypeMap::createEmptyStructure): (JSC::PrototypeMap::clearEmptyObjectStructureForPrototype): * runtime/PrototypeMap.h: (JSC::PrototypeMap::PrototypeMap): * runtime/PrototypeMapInlines.h: Removed. * runtime/SetIteratorPrototype.cpp: (JSC::SetIteratorPrototype::finishCreation): * runtime/SetPrototype.cpp: (JSC::SetPrototype::finishCreation): * runtime/StringIteratorPrototype.cpp: (JSC::StringIteratorPrototype::finishCreation): * runtime/WeakGCMap.h: (JSC::WeakGCMapBase::~WeakGCMapBase): * runtime/WeakGCMapInlines.h: (JSC::KeyTraitsArg>::WeakGCMap): * runtime/WeakMapPrototype.cpp: (JSC::WeakMapPrototype::finishCreation): * runtime/WeakSetPrototype.cpp: (JSC::WeakSetPrototype::finishCreation): 2017-10-07 Filip Pizlo Octane/splay can leak memory due to stray pointers on the stack when run from the command line https://bugs.webkit.org/show_bug.cgi?id=178054 Reviewed by Saam Barati. This throws in a bunch of sanitize calls. It fixes the problem. It's also performance-neutral. In most cases, calling the sanitize function is O(1), because it doesn't have anything to do if the stack height stays relatively constant. * dfg/DFGOperations.cpp: * dfg/DFGTierUpCheckInjectionPhase.cpp: (JSC::DFG::TierUpCheckInjectionPhase::run): * ftl/FTLOSREntry.cpp: * heap/Heap.cpp: (JSC::Heap::runCurrentPhase): * heap/MarkedAllocatorInlines.h: (JSC::MarkedAllocator::tryAllocate): (JSC::MarkedAllocator::allocate): * heap/Subspace.cpp: (JSC::Subspace::tryAllocateSlow): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::sanitizeStackInline): * jit/ThunkGenerators.cpp: (JSC::slowPathFor): * runtime/VM.h: (JSC::VM::addressOfLastStackTop): 2017-10-07 Yusuke Suzuki `async` should be able to be used as an imported binding name https://bugs.webkit.org/show_bug.cgi?id=176573 Reviewed by Darin Adler. Previously, we have ASYNC keyword in the parser. This is introduced only for performance, and ECMA262 spec does not categorize "async" to keyword. This makes parser code complicated, since ASYNC should be handled as IDENT. If we missed this ASYNC keyword, we cause a bug. For example, import declaration failed to bind imported binding to the name "async" because the parser considered ASYNC as keyword. This patch removes ASYNC keyword from the parser. By carefully handling ASYNC, we can keep the current performance without using this ASYNC keyword. * parser/Keywords.table: * parser/Parser.cpp: (JSC::Parser::parseStatementListItem): (JSC::Parser::parseStatement): (JSC::Parser::maybeParseAsyncFunctionDeclarationStatement): (JSC::Parser::parseClass): (JSC::Parser::parseExportDeclaration): (JSC::Parser::parseAssignmentExpression): (JSC::Parser::parseProperty): (JSC::Parser::parsePrimaryExpression): (JSC::Parser::parseMemberExpression): (JSC::Parser::printUnexpectedTokenText): * parser/ParserTokens.h: * runtime/CommonIdentifiers.h: 2017-09-29 Filip Pizlo Enable gigacage on iOS https://bugs.webkit.org/show_bug.cgi?id=177586 Reviewed by JF Bastien. The hardest part of enabling Gigacage on iOS is that it requires loading global variables while executing JS, so the LLInt needs to know how to load from global variables on all platforms that have Gigacage. So, this teaches ARM64 how to load from global variables. Also, this makes the code handle disabling the gigacage a bit better. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::caged): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::cage): (JSC::AssemblyHelpers::cageConditionally): * offlineasm/arm64.rb: * offlineasm/asm.rb: * offlineasm/instructions.rb: 2017-10-06 Michael Saboff Enable RegExp JIT for match only Unicode RegExp's https://bugs.webkit.org/show_bug.cgi?id=178033 Reviewed by JF Bastien. I forgot to turn on JIT'ing for match-only Unicode RegExp's in r221052. Do it now. * runtime/RegExp.cpp: (JSC::RegExp::compileMatchOnly): 2017-10-06 Alex Christensen Build fix after r223002. * dfg/DFGOSRExit.cpp: (JSC::DFG::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer): (JSC::DFG::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer): 2017-10-06 Commit Queue Unreviewed, rolling out r222791 and r222873. https://bugs.webkit.org/show_bug.cgi?id=178031 Caused crashes with workers/wasm LayoutTests (Requested by ryanhaddad on #webkit). Reverted changesets: "WebAssembly: no VM / JS version of everything but Instance" https://bugs.webkit.org/show_bug.cgi?id=177473 http://trac.webkit.org/changeset/222791 "WebAssembly: address no VM / JS follow-ups" https://bugs.webkit.org/show_bug.cgi?id=177887 http://trac.webkit.org/changeset/222873 2017-10-06 Robin Morisset Avoid integer overflow in DFGStrengthReduction.cpp https://bugs.webkit.org/show_bug.cgi?id=177944 Reviewed by Saam Barati. The check that we won't do integer overflow by negating INT32_MIN was itself an integer overflow. I think that signed integer overflow is undefined behaviour in C, so I replace it by an explicit check that value != INT32_MIN instead. * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::handleNode): 2017-10-05 Keith Miller JSC generate unified sources doesn't need to run during installhdrs. https://bugs.webkit.org/show_bug.cgi?id=177640 Reviewed by Dan Bernstein. generate unified sources doesn't need to have a xcconfig file since we don't have any feature defines. Also, remove the plist because there's no plist for this... * JavaScriptCore.xcodeproj/project.pbxproj: 2017-10-05 Jer Noble [Cocoa] Enable ENABLE_ENCRYPTED_MEDIA build-time setting https://bugs.webkit.org/show_bug.cgi?id=177261 Reviewed by Eric Carlson. * Configurations/FeatureDefines.xcconfig: 2017-10-05 Ryan Haddad Unreviewed, rolling out r222929. Caused assertion failures during LayoutTests. Reverted changeset: "Only add prototypes to the PrototypeMap if they're not already present" https://bugs.webkit.org/show_bug.cgi?id=177952 http://trac.webkit.org/changeset/222929 2017-10-05 Carlos Alberto Lopez Perez Generate a compile error if release is built without compiler optimizations https://bugs.webkit.org/show_bug.cgi?id=177665 Reviewed by Brian Burg. Pass -DRELEASE_WITHOUT_OPTIMIZATIONS to testair.cpp and testb3.cpp because this files are compiled with -O0 for build speed reasons after r195639. * JavaScriptCore.xcodeproj/project.pbxproj: 2017-10-05 Saam Barati Only add prototypes to the PrototypeMap if they're not already present https://bugs.webkit.org/show_bug.cgi?id=177952 Reviewed by Michael Saboff and JF Bastien. With poly proto, we need to call PrototypeMap::add more frequently since we don't know if the prototype is already in the map or not based solely on Structure. PrototypeMap::add was calling WeakMap::set unconditionally, which would unconditionally allocate a Weak handle. Allocating a Weak handle is expensive. It's at least 8x more expensive than just checking if the prototype is in the map prior to adding it. This patch makes the change to only add the prototype if it's not already in the map. To do this, I've added a WeakMap::add API that just forwards into HashMap's add API. This allows us to both only do a single hash table lookup and also to allocate only a single Weak handle when necessary. * runtime/PrototypeMapInlines.h: (JSC::PrototypeMap::addPrototype): * runtime/WeakGCMap.h: (JSC::WeakGCMap::add): 2017-10-05 Saam Barati Unreviewed. Disable probe OSR exit on 32-bit until it's fixed. * runtime/Options.cpp: (JSC::recomputeDependentOptions): 2017-10-05 Saam Barati Make sure all prototypes under poly proto get added into the VM's prototype map https://bugs.webkit.org/show_bug.cgi?id=177909 Reviewed by Keith Miller. This is an invariant of prototypes that I broke when doing poly proto. This patch fixes it. * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/BytecodeList.json: * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGOperations.cpp: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/JSCInlines.h: * runtime/PrototypeMap.cpp: (JSC::PrototypeMap::addPrototype): Deleted. * runtime/PrototypeMap.h: * runtime/PrototypeMapInlines.h: (JSC::PrototypeMap::isPrototype const): (JSC::PrototypeMap::addPrototype): 2017-09-30 Yusuke Suzuki [JSC] Introduce import.meta https://bugs.webkit.org/show_bug.cgi?id=177703 Reviewed by Filip Pizlo. This patch adds stage 3 `import.meta`[1]. We add a new hook function moduleLoaderCreateImportMetaProperties, which creates import meta properties object to this module. And we set this object as @meta private variable in module environments. So module code can access this by accessing @meta private variable. [1]: https://github.com/tc39/proposal-import-meta * builtins/BuiltinNames.h: * builtins/ModuleLoaderPrototype.js: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): * jsc.cpp: (GlobalObject::moduleLoaderCreateImportMetaProperties): * parser/Parser.cpp: (JSC::Parser::parseModuleSourceElements): (JSC::Parser::parseMemberExpression): * runtime/JSGlobalObject.cpp: * runtime/JSGlobalObject.h: * runtime/JSModuleLoader.cpp: (JSC::JSModuleLoader::createImportMetaProperties): * runtime/JSModuleLoader.h: * runtime/JSModuleRecord.cpp: (JSC::JSModuleRecord::link): (JSC::JSModuleRecord::instantiateDeclarations): * runtime/JSModuleRecord.h: * runtime/ModuleLoaderPrototype.cpp: (JSC::moduleLoaderPrototypeModuleDeclarationInstantiation): 2017-10-04 Saam Barati Make pertinent AccessCases watch the poly proto watchpoint https://bugs.webkit.org/show_bug.cgi?id=177765 Reviewed by Keith Miller. This patch makes it so that stubs that encounter a structure with a valid poly proto watchpoint will watch the poly proto watchpoint. This ensures that if the watchpoint is fired, the stub will be cleared and have a chance to regenerate. In an ideal world, this will lead to the stub generating better code since it may never encounter the non-poly proto structure again. This patch also fixes a bug in the original poly proto code where I accidentally had a condition inverted. The bad code caused a stub that continually cached two structures which are structurally equivalent but with different prototype objects to always clear itself. The code should have been written differently. It should have only cleared if the poly proto watchpoint *was not* fired. The code accidentally cleared only if stub *was* fired. * bytecode/AccessCase.cpp: (JSC::AccessCase::commit): * bytecode/PolymorphicAccess.cpp: (JSC::PolymorphicAccess::addCases): (WTF::printInternal): * bytecode/PolymorphicAccess.h: (JSC::AccessGenerationResult::shouldResetStubAndFireWatchpoints const): (JSC::AccessGenerationResult::addWatchpointToFire): (JSC::AccessGenerationResult::fireWatchpoints): (JSC::AccessGenerationResult::shouldResetStub const): Deleted. * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::addAccessCase): (JSC::StructureStubInfo::reset): * bytecode/Watchpoint.h: (JSC::InlineWatchpointSet::inflate): * jit/Repatch.cpp: (JSC::fireWatchpointsAndClearStubIfNeeded): (JSC::tryCacheGetByID): (JSC::repatchGetByID): (JSC::tryCachePutByID): (JSC::repatchPutByID): (JSC::tryCacheIn): (JSC::repatchIn): (JSC::tryRepatchIn): Deleted. 2017-10-04 Matt Baker Web Inspector: Improve CanvasManager recording events https://bugs.webkit.org/show_bug.cgi?id=177762 Reviewed by Devin Rousso. * inspector/protocol/Canvas.json: Renamed events for clarity and consistency; made recording data optional. 2017-10-04 JF Bastien WTF: Update std::expected to match current proposal https://bugs.webkit.org/show_bug.cgi?id=177881 Reviewed by Mark Lam. Update API. * wasm/WasmB3IRGenerator.cpp: * wasm/WasmModule.cpp: (JSC::Wasm::makeValidationResult): * wasm/WasmParser.h: * wasm/WasmValidate.cpp: * wasm/generateWasmValidateInlinesHeader.py: (loadMacro): (storeMacro): 2017-10-04 JF Bastien WebAssembly: address no VM / JS follow-ups https://bugs.webkit.org/show_bug.cgi?id=177887 Reviewed by Saam Barati. All minor fixes, no functional changes. * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState): (JSC::Wasm::B3IRGenerator::addCurrentMemory): (JSC::Wasm::B3IRGenerator::addCall): (JSC::Wasm::B3IRGenerator::addCallIndirect): * wasm/WasmContext.cpp: (JSC::Wasm::Context::store): * wasm/WasmMemoryMode.h: * wasm/WasmTable.h: * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance): * wasm/js/JSWebAssemblyTable.cpp: (JSC::JSWebAssemblyTable::JSWebAssemblyTable): (JSC::JSWebAssemblyTable::grow): 2017-10-04 Mark Lam Add support for using Probe DFG OSR Exit behind a runtime flag. https://bugs.webkit.org/show_bug.cgi?id=177844 Reviewed by Saam Barati. This is based on the code originally posted in https://bugs.webkit.org/show_bug.cgi?id=175144 (in r221774 and r221832) with some optimizations and bug fixes added. The probe based DFG OSR Exit is only enabled if Options::useProbeOSRExit() is true. We're landing this behind an option switch to make it easier to tune performance using the probe based OSR exit. * JavaScriptCore.xcodeproj/project.pbxproj: * assembler/MacroAssembler.cpp: (JSC::stdFunctionCallback): * assembler/MacroAssemblerPrinter.cpp: (JSC::Printer::printCallback): * assembler/ProbeContext.cpp: (JSC::Probe::executeProbe): (JSC::Probe::flushDirtyStackPages): * assembler/ProbeContext.h: (JSC::Probe::Context::Context): (JSC::Probe::Context::arg): * assembler/ProbeFrame.h: Added. (JSC::Probe::Frame::Frame): (JSC::Probe::Frame::argument): (JSC::Probe::Frame::operand): (JSC::Probe::Frame::setArgument): (JSC::Probe::Frame::setOperand): (JSC::Probe::Frame::get): (JSC::Probe::Frame::set): * assembler/ProbeStack.cpp: (JSC::Probe::Page::lowWatermarkFromVisitingDirtyChunks): (JSC::Probe::Stack::Stack): (JSC::Probe::Stack::lowWatermarkFromVisitingDirtyPages): * assembler/ProbeStack.h: (JSC::Probe::Stack::Stack): (JSC::Probe::Stack::lowWatermark): (JSC::Probe::Stack::set): (JSC::Probe::Stack::savedStackPointer const): (JSC::Probe::Stack::setSavedStackPointer): (JSC::Probe::Stack::newStackPointer const): Deleted. (JSC::Probe::Stack::setNewStackPointer): Deleted. * bytecode/ArrayProfile.h: (JSC::ArrayProfile::observeArrayMode): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::updateOSRExitCounterAndCheckIfNeedToReoptimize): * bytecode/CodeBlock.h: (JSC::CodeBlock::addressOfOSRExitCounter): Deleted. * bytecode/ExecutionCounter.h: (JSC::ExecutionCounter::hasCrossedThreshold const): (JSC::ExecutionCounter::setNewThresholdForOSRExit): * bytecode/MethodOfGettingAValueProfile.cpp: (JSC::MethodOfGettingAValueProfile::reportValue): * bytecode/MethodOfGettingAValueProfile.h: * dfg/DFGDriver.cpp: (JSC::DFG::compileImpl): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::linkOSRExits): (JSC::DFG::JITCompiler::link): * dfg/DFGOSRExit.cpp: (JSC::DFG::jsValueFor): (JSC::DFG::restoreCalleeSavesFor): (JSC::DFG::saveCalleeSavesFor): (JSC::DFG::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer): (JSC::DFG::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer): (JSC::DFG::saveOrCopyCalleeSavesFor): (JSC::DFG::createDirectArgumentsDuringExit): (JSC::DFG::createClonedArgumentsDuringExit): (JSC::DFG::emitRestoreArguments): (JSC::DFG::OSRExit::executeOSRExit): (JSC::DFG::reifyInlinedCallFrames): (JSC::DFG::adjustAndJumpToTarget): (JSC::DFG::printOSRExit): * dfg/DFGOSRExit.h: (JSC::DFG::OSRExitState::OSRExitState): * dfg/DFGThunks.cpp: (JSC::DFG::osrExitThunkGenerator): * dfg/DFGThunks.h: * dfg/DFGVariableEventStream.cpp: (JSC::DFG::tryToSetConstantRecovery): (JSC::DFG::VariableEventStream::reconstruct const): (JSC::DFG::VariableEventStream::tryToSetConstantRecovery const): Deleted. * dfg/DFGVariableEventStream.h: * profiler/ProfilerOSRExit.h: (JSC::Profiler::OSRExit::incCount): * runtime/JSCJSValue.h: * runtime/JSCJSValueInlines.h: * runtime/Options.h: 2017-10-04 Ryan Haddad Unreviewed, rolling out r222840. This change breaks internal builds. Reverted changeset: "Generate a compile error if release is built without compiler optimizations" https://bugs.webkit.org/show_bug.cgi?id=177665 http://trac.webkit.org/changeset/222840 2017-10-04 Carlos Alberto Lopez Perez Generate a compile error if release is built without compiler optimizations https://bugs.webkit.org/show_bug.cgi?id=177665 Reviewed by Michael Catanzaro. Pass -DRELEASE_WITHOUT_OPTIMIZATIONS to testair.cpp and testb3.cpp because this files are compiled with -O0 for build speed reasons after r195639. * JavaScriptCore.xcodeproj/project.pbxproj: 2017-10-03 Jon Davis Update WebAssembly to "Supported" https://bugs.webkit.org/show_bug.cgi?id=177831 Reviewed by Alexey Proskuryakov. Cleaned up Async Iteration and Object rest/spread to use "In Development" instead of "In development". * features.json: 2017-10-03 Saam Barati Implement polymorphic prototypes https://bugs.webkit.org/show_bug.cgi?id=176391 Reviewed by Filip Pizlo. This patch changes JSC's object model with respect to where the prototype of an object is stored. Previously, it was always stored as a constant value inside Structure. So an object's structure used to always tell you what its prototype is. Anytime an object changed its prototype, it would do a structure transition. This enables a large class of optimizations: just by doing a structure check, we know what the prototype is. However, this design falls down when you have many objects that have the same shape, but only differ in what their prototype value is. This arises in many JS programs. A simple, and probably common, example is when the program has a constructor inside of a function: ``` function foo() { class C { constructor() { this.field1 = 42; ...; this.fieldN = 42; } method1() { doStuffWith(this.field); } method2() { doStuffWith(this.field); } } let c = new C; do things with c; } repeatedly call foo() here. ``` Before this patch, in the above program, each time `new C` created an object, it would create an object with a different structure. The reason for this is that each time foo is called, there is a new instance of C.prototype. However, each `new C` that was created with have identical shape sans its prototype value. This would cause all ICs that used `c` to quickly give up on any form of caching because they would see too many structures and give up and permanently divert control flow to the slow path. This patch fixes this issue by expanding the notion of where the prototype of an object is stored. There are now two notions of where the prototype is stored. A Structure can now be in two modes: 1. Mono proto mode. This is the same mode as we used to have. It means the structure itself has a constant prototype value. 2. Poly proto mode. This means the structure knows nothing about the prototype value itself. Objects with this structure store their prototype in normal object field storage. The structure will tell you the offset of this prototype inside the object's storage. As of today, we only reserve inline slots for the prototype field because poly proto only occurs for JSFinalObject. However, this will be expanded to support out of line offsets in a future patch when we extend poly proto to work when we inherit from builtin types like Map and Array. In this initial patch, we do poly proto style inline caching whenever we see an object that is poly proto or if an object in its prototype lookup chain is poly proto. Poly proto ICs work by verifying the lookup chain at runtime. This essentially boils down to performing structure checks up the prototype chain. In a future patch, we're going to extend object property condition set to work with objects that don't have poly proto bases. Initially, accesses that have poly proto access chains will always turn into GetById/PutById in the DFG. In a future patch, I'm going to teach the DFG how to inline certain accesses that have poly proto in the access chain. One of most interesting parts about this patch is how we decide when to go poly proto. This patch uses a profiling based approach. An IC will inform a watchpoint that it sees an opportunity when two Structure's are structurally the same, sans the base object's prototype. This means that two structures have equivalent shapes all the way up the prototype chain. To support fast structural comparison, we compute a hash for a structure based on the properties it has. We compute this hash as we add properties to the structure. This computation is nearly free since we always add UniquedStringImpl*'s which already have their hashes computed. To compare structural equivalence, we just compare hash values all the way up the prototype chain. This means we can get hash conflicts between two structures, but it's extremely rare. First, it'll be rare for two structures to have the same hash. Secondly, we only consider structures originating from the same executable. How we set up this poly proto watchpoint is crucial to its design. When we create_this an object originating from some executable, that executable will create a Box. Each structure that originates from this executable will get a copy of that Box. As that structure transitions to new structures, they too will get a copy of that Box. Therefore, when invalidating an arbitrary structure's poly proto watchpoint, we will know the next time we create_this from that executable that it had been invalidated, and that we should create an object with a poly proto structure. We also use the pointer value of this Box to determine if two structures originated from the same executable. This pruning will severely limit the chances of getting a hash conflict in practice. This patch is neutral on my MBP on traditional JS benchmarks like Octane/Kraken/Sunspider. It may be a 1-2% ARES-6 progression. This patch is between neutral and a 9x progression on the various tests I added. Most of the microbenchmarks are progressed by at least 50%. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * builtins/BuiltinNames.cpp: * builtins/BuiltinNames.h: (JSC::BuiltinNames::BuiltinNames): (JSC::BuiltinNames::underscoreProtoPrivateName const): * bytecode/AccessCase.cpp: (JSC::AccessCase::AccessCase): (JSC::AccessCase::create): (JSC::AccessCase::commit): (JSC::AccessCase::guardedByStructureCheck const): (JSC::AccessCase::canReplace const): (JSC::AccessCase::dump const): (JSC::AccessCase::visitWeak const): (JSC::AccessCase::propagateTransitions const): (JSC::AccessCase::generateWithGuard): (JSC::AccessCase::generateImpl): * bytecode/AccessCase.h: (JSC::AccessCase::usesPolyProto const): (JSC::AccessCase::AccessCase): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback): * bytecode/GetterSetterAccessCase.cpp: (JSC::GetterSetterAccessCase::GetterSetterAccessCase): (JSC::GetterSetterAccessCase::create): * bytecode/GetterSetterAccessCase.h: * bytecode/InternalFunctionAllocationProfile.h: (JSC::InternalFunctionAllocationProfile::createAllocationStructureFromBase): * bytecode/IntrinsicGetterAccessCase.cpp: (JSC::IntrinsicGetterAccessCase::IntrinsicGetterAccessCase): * bytecode/IntrinsicGetterAccessCase.h: * bytecode/ModuleNamespaceAccessCase.cpp: (JSC::ModuleNamespaceAccessCase::ModuleNamespaceAccessCase): * bytecode/ObjectAllocationProfile.cpp: Added. (JSC::ObjectAllocationProfile::initializeProfile): (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount): * bytecode/ObjectAllocationProfile.h: (JSC::ObjectAllocationProfile::clear): (JSC::ObjectAllocationProfile::initialize): Deleted. (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount): Deleted. * bytecode/ObjectPropertyConditionSet.cpp: * bytecode/PolyProtoAccessChain.cpp: Added. (JSC::PolyProtoAccessChain::create): (JSC::PolyProtoAccessChain::needImpurePropertyWatchpoint const): (JSC::PolyProtoAccessChain::operator== const): (JSC::PolyProtoAccessChain::dump const): * bytecode/PolyProtoAccessChain.h: Added. (JSC::PolyProtoAccessChain::clone): (JSC::PolyProtoAccessChain:: const): (JSC::PolyProtoAccessChain::operator!= const): (JSC::PolyProtoAccessChain::forEach const): * bytecode/PolymorphicAccess.cpp: (JSC::PolymorphicAccess::addCases): (JSC::PolymorphicAccess::regenerate): (WTF::printInternal): * bytecode/PolymorphicAccess.h: (JSC::AccessGenerationResult::shouldResetStub const): (JSC::AccessGenerationState::AccessGenerationState): * bytecode/PropertyCondition.cpp: (JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint const): * bytecode/ProxyableAccessCase.cpp: (JSC::ProxyableAccessCase::ProxyableAccessCase): (JSC::ProxyableAccessCase::create): * bytecode/ProxyableAccessCase.h: * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeForStubInfo): * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::addAccessCase): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::load): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::canDoFastSpread): * dfg/DFGOperations.cpp: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject): (JSC::DFG::SpeculativeJIT::compileInstanceOf): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_instanceof): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_instanceof): * jit/Repatch.cpp: (JSC::tryCacheGetByID): (JSC::tryCachePutByID): (JSC::tryRepatchIn): * jsc.cpp: (WTF::DOMJITGetterBaseJSObject::DOMJITGetterBaseJSObject): (WTF::DOMJITGetterBaseJSObject::createStructure): (WTF::DOMJITGetterBaseJSObject::create): (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::DOMJITAttribute): (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::slowCall): (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::callDOMGetter): (WTF::DOMJITGetterBaseJSObject::customGetter): (WTF::DOMJITGetterBaseJSObject::finishCreation): (GlobalObject::finishCreation): (functionCreateDOMJITGetterBaseJSObject): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/ArrayPrototype.cpp: (JSC::holesMustForwardToPrototype): (JSC::fastJoin): (JSC::arrayProtoFuncReverse): (JSC::moveElements): * runtime/ClonedArguments.cpp: (JSC::ClonedArguments::createEmpty): (JSC::ClonedArguments::createWithInlineFrame): (JSC::ClonedArguments::createWithMachineFrame): (JSC::ClonedArguments::createByCopyingFrom): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/FunctionExecutable.cpp: (JSC::FunctionExecutable::visitChildren): * runtime/FunctionExecutable.h: * runtime/FunctionRareData.cpp: (JSC::FunctionRareData::initializeObjectAllocationProfile): * runtime/FunctionRareData.h: * runtime/InternalFunction.cpp: (JSC::InternalFunction::createSubclassStructureSlow): * runtime/JSArray.cpp: (JSC::JSArray::fastSlice): (JSC::JSArray::shiftCountWithArrayStorage): (JSC::JSArray::shiftCountWithAnyIndexingType): (JSC::JSArray::isIteratorProtocolFastAndNonObservable): * runtime/JSArrayInlines.h: (JSC::JSArray::canFastCopy): * runtime/JSCJSValue.cpp: (JSC::JSValue::dumpInContextAssumingStructure const): * runtime/JSFunction.cpp: (JSC::JSFunction::prototypeForConstruction): (JSC::JSFunction::allocateAndInitializeRareData): (JSC::JSFunction::initializeRareData): (JSC::JSFunction::getOwnPropertySlot): * runtime/JSFunction.h: * runtime/JSMap.cpp: (JSC::JSMap::isIteratorProtocolFastAndNonObservable): (JSC::JSMap::canCloneFastAndNonObservable): * runtime/JSObject.cpp: (JSC::JSObject::putInlineSlow): (JSC::JSObject::createInitialIndexedStorage): (JSC::JSObject::createArrayStorage): (JSC::JSObject::convertUndecidedToArrayStorage): (JSC::JSObject::convertInt32ToArrayStorage): (JSC::JSObject::convertDoubleToArrayStorage): (JSC::JSObject::convertContiguousToArrayStorage): (JSC::JSObject::ensureInt32Slow): (JSC::JSObject::ensureDoubleSlow): (JSC::JSObject::ensureContiguousSlow): (JSC::JSObject::ensureArrayStorageSlow): (JSC::JSObject::setPrototypeDirect): (JSC::JSObject::ordinaryToPrimitive const): (JSC::JSObject::putByIndexBeyondVectorLength): (JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength): (JSC::JSObject::getEnumerableLength): (JSC::JSObject::anyObjectInChainMayInterceptIndexedAccesses const): (JSC::JSObject::prototypeChainMayInterceptStoreTo): (JSC::JSObject::needsSlowPutIndexing const): (JSC::JSObject::suggestedArrayStorageTransition const): * runtime/JSObject.h: (JSC::JSObject::finishCreation): (JSC::JSObject::getPrototypeDirect const): (JSC::JSObject::getPropertySlot): * runtime/JSObjectInlines.h: (JSC::JSObject::getPropertySlot): (JSC::JSObject::getNonIndexPropertySlot): (JSC::JSObject::putInlineForJSObject): * runtime/JSPropertyNameEnumerator.h: (JSC::propertyNameEnumerator): * runtime/JSSet.cpp: (JSC::JSSet::isIteratorProtocolFastAndNonObservable): (JSC::JSSet::canCloneFastAndNonObservable): * runtime/LazyClassStructure.h: (JSC::LazyClassStructure::prototypeConcurrently const): Deleted. * runtime/Operations.cpp: (JSC::normalizePrototypeChain): * runtime/Operations.h: * runtime/Options.h: * runtime/PrototypeMap.cpp: (JSC::PrototypeMap::createEmptyStructure): (JSC::PrototypeMap::emptyStructureForPrototypeFromBaseStructure): (JSC::PrototypeMap::emptyObjectStructureForPrototype): (JSC::PrototypeMap::clearEmptyObjectStructureForPrototype): * runtime/PrototypeMap.h: * runtime/Structure.cpp: (JSC::Structure::Structure): (JSC::Structure::create): (JSC::Structure::holesMustForwardToPrototype const): (JSC::Structure::changePrototypeTransition): (JSC::Structure::isCheapDuringGC): (JSC::Structure::toStructureShape): (JSC::Structure::dump const): (JSC::Structure::canCachePropertyNameEnumerator const): (JSC::Structure::anyObjectInChainMayInterceptIndexedAccesses const): Deleted. (JSC::Structure::needsSlowPutIndexing const): Deleted. (JSC::Structure::suggestedArrayStorageTransition const): Deleted. (JSC::Structure::prototypeForLookup const): Deleted. (JSC::Structure::prototypeChainMayInterceptStoreTo): Deleted. (JSC::Structure::canUseForAllocationsOf): Deleted. * runtime/Structure.h: * runtime/StructureChain.h: * runtime/StructureInlines.h: (JSC::Structure::create): (JSC::Structure::storedPrototypeObject const): (JSC::Structure::storedPrototypeStructure const): (JSC::Structure::storedPrototype const): (JSC::prototypeForLookupPrimitiveImpl): (JSC::Structure::prototypeForLookup const): (JSC::Structure::prototypeChain const): (JSC::Structure::isValid const): (JSC::Structure::add): (JSC::Structure::setPropertyTable): (JSC::Structure::shouldConvertToPolyProto): * runtime/StructureRareData.h: * runtime/TypeProfilerLog.cpp: (JSC::TypeProfilerLog::processLogEntries): * runtime/TypeSet.cpp: (JSC::TypeSet::addTypeInformation): * runtime/TypeSet.h: * runtime/WriteBarrier.h: (JSC::WriteBarrierBase::isInt32 const): 2017-10-03 JF Bastien WebAssembly: no VM / JS version of everything but Instance https://bugs.webkit.org/show_bug.cgi?id=177473 Reviewed by Filip Pizlo. This change entails cleaning up and splitting a bunch of code which we had intertwined between C++ classes which represent JS objects, and pure C++ implementation objects. This specific change goes most of the way towards allowing JSC's WebAssembly to work without VM / JS, up to but excluding JSWebAssemblyInstance (there's Wasm::Instance, but it's not *the* thing yet). Because of this we still have a few FIXME identifying places that need to change. A follow-up change will go the rest of the way. I went about this change in the simplest way possible: grep the JavaScriptCore/wasm directory for "JS[^C_]" as well as "VM" and exclude the /js/ sub-directory (which contains the JS implementation of WebAssembly). None of this change removes the need for a JIT entitlement to be able to use WebAssembly. We don't have an interpreter, the process therefore still needs to be allowed to JIT to use these pure-C++ APIs. Interesting things to note: - Remove VM from Plan and associated places. It can just live as a capture in the callback lambda if it's needed. - Wasm::Memory shouldn't require a VM. It was only used to ask the GC to collect. We now instead pass two lambdas at construction time for this purpose: one to notify of memory pressure, and the other to ask for syncrhonous memory reclamation. This allows whoever creates the memory to dictate how to react to both these cases, and for a JS embedding that's to call the GC (async or sync, respectively). - Move grow logic from JSWebAssemblyMemory to Wasm::Memory::grow. Use Expected there, with an enum class for failure types. - Exceeding max on memory growth now returns a range error as per spec. This is a (very minor) breaking change: it used to throw OOM error. Update the corresponding test. - When generating the grow_memory opcode, no need to get the VM. Instead, reach directly for Wasm::Memory and grow it. - JSWebAssemblyMemory::grow can now always throw on failure, because it's only ever called from JS (not from grow_memory as before). - Wasm::Memory now takes a callback for successful growth. This allows JS wrappers to register themselves when growth succeeds without Wasm::Memory knowning anything about JS. It'll also allow creating a list of callbacks for when we add thread support (we'll want to notify many wrappers, all under a lock). - Wasm::Memory is now back to being the source of truth about address / size, used directly by generated code instead of JSWebAssemblyMemory. - Move wasmToJS from the general WasmBinding header to its own header under wasm/js. It's only used by wasm/js/JSWebAssemblyCodeBlock.cpp, and uses VM, and therefore isn't general WebAssembly. - Make Wasm::Context an actual type (just a struct holding a JSWebAssemlyInstance for now) instead of an alias for that. Notably this doesn't add anything to the Context and doesn't change what actually gets passed around in JIT code (fast TLS or registers) because these changes potentially impact performance. The entire purpose of this change is to allow passing Wasm::Context around without having to know about VM. Since VM contains a Wasm::Context the JS embedding is effectively the same, but with this setup a non-JS embedding is much better off. - Move JSWebAssembly into the JS folder. - OMGPlan: use Wasm::CodeBlock directly instead of JSWebAssemblyCodeBlock. - wasm->JS stubs are now on Wasm::CodeBlock's tail as raw pointers, instead of being on JSWebAssemblyCodeBlock, and are now called wasm->Embedder stubs. The owned reference is still on JSWebAssemblyCodeBlock, and is still called wasm->JS stub. This move means that the embedder must, after creating a Wasm::CodeBlock, somehow create the stubs to call back into the embedder. This isn't adding any indirection to the generated code because the B3 IR generator now reaches for Wasm::CodeBlock instead of JSWebAssemblyCodeBlock. - Move more CodeBlock things. Compilation completion is now marked by its own atomic flag instead of a nullptr plan: that required using a lock, and was causing a deadlock in stack-trace.js because before my changes JSWebAssemblyCodeBlock did its own completion checking separately from Wasm::CodeBlock, without getting the lock. Now that everything points to Wasm::CodeBlock and there's no cached completion marker, the lock was being acquired in a sanity-check assertion. - Embedder -> Wasm wrappers are now generated through a function that's passed in at compilation time, instead of being hard-coded as a JS -> Wasm wrapper. - WasmMemory doens't need to know about fault handling thunks. Only the IR generator should know, and should make sure that the exception throwing thunk is generated if any memory is present (note: with signal handling not all of them generate an exception check). - Make exception throwing pluggable: instead of having a hard-coded JS-specific lambda we now have a regular C++ function being called from JIT code when a WebAssembly exception is thrown. This allows any embedder to get called as they wish. For now a process can only have a single of these functions (i.e. only one embedder per process) because the trap handler is a singleton. That can be fixed in in #177475. - Create WasmEmbedder.h where all embedder plugging will live. - Split up JSWebAssemblyTable into Wasm::Table which is refcounted. JSWebAssemblyTable now only contains the JS functions in the table, and Wasm::Table is what's used by the JIT code to lookup where to call and do the instance check (for context switch). Note that this creates an extra allocation for all the instances in Wasm::Table, and in exchange removes an indirection in JIT code because the instance used to be obtained off of the JS function. Also note that it's the embedder than keeps the instances alive, not Wasm::Table (which holds a dumb pointer to the instance), because doing otherwise would cause reference cycles. - Add WasmInstance. It doesn't do much for now, owns globals. - JSWebAssembly instance now doesn't just contain the imported functions as JSObjects, it also has the corresponding import's instance and wasm entrypoint. This triples the space allocated per instance's imported function, but there shouldn't be that many imports. This has two upsides: it creates smaller and faster code, and makes is easier to disassociate embedder-specific things from embedder-neutral things. The small / faster win is in two places: B3 IR generator only needs offsetOfImportFunction for the call opcode (when the called index is an import) to know whether the import is wasm->wasm or wasm->embedder (this isn't known at compile-time because it's dependent on the import object), this is now done by seeing if that import function has an associated target instance (only wasm->wasm does); the other place is wasmBinding which uses offsetOfImportFunction to figure out the wasm->wasm target instance, and then gets WebAssemblyFunction::offsetOfWasmEntrypointLoadLocation to do a tail call. The disassociation comes because the target instance can be Wasm::Instance once we change what the Context is, and WasmEntrypointLoadLocation is already embedder-independent. As a next step I can move this tail allocation from JSWebAssemblyInstance to Wasm::Instance, and leave importFunction in as an opaque pointer which is embedder-specific, and in JS will remain WriteBarrier. - Rename VMEntryFrame to EntryFrame, and in many places pass a pointer to it around instead of VM. This is a first step in allowing entry frames which aren't stored on VM, but which are instead stored in an embedder-specific location. That change won't really affect JS except through code churn, but will allow WebAssembly to use some machinery in a generic manner without having a VM. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * bytecode/PolymorphicAccess.cpp: (JSC::AccessGenerationState::emitExplicitExceptionHandler): * debugger/Debugger.cpp: (JSC::Debugger::stepOutOfFunction): (JSC::Debugger::returnEvent): (JSC::Debugger::unwindEvent): (JSC::Debugger::didExecuteProgram): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compileExceptionHandlers): * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareOSREntry): * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::compileOSRExit): (JSC::DFG::OSRExit::compileExit): * dfg/DFGThunks.cpp: (JSC::DFG::osrEntryThunkGenerator): * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLLink.cpp: (JSC::FTL::link): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::lower): * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): * interpreter/CallFrame.cpp: (JSC::CallFrame::wasmAwareLexicalGlobalObject): (JSC::CallFrame::callerFrame): (JSC::CallFrame::unsafeCallerFrame): * interpreter/CallFrame.h: (JSC::ExecState::callerFrame const): (JSC::ExecState::callerFrameOrEntryFrame const): (JSC::ExecState::unsafeCallerFrameOrEntryFrame const): * interpreter/FrameTracers.h: (JSC::NativeCallFrameTracer::NativeCallFrameTracer): (JSC::NativeCallFrameTracerWithRestore::NativeCallFrameTracerWithRestore): (JSC::NativeCallFrameTracerWithRestore::~NativeCallFrameTracerWithRestore): * interpreter/Interpreter.cpp: (JSC::UnwindFunctor::operator() const): (JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const): (JSC::Interpreter::unwind): * interpreter/StackVisitor.cpp: (JSC::StackVisitor::StackVisitor): (JSC::StackVisitor::gotoNextFrame): (JSC::StackVisitor::readNonInlinedFrame): (JSC::StackVisitor::Frame::dump const): * interpreter/StackVisitor.h: (JSC::StackVisitor::Frame::callerIsEntryFrame const): * interpreter/VMEntryRecord.h: (JSC::VMEntryRecord::prevTopEntryFrame): (JSC::VMEntryRecord::unsafePrevTopEntryFrame): (JSC::EntryFrame::vmEntryRecordOffset): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::restoreCalleeSavesFromEntryFrameCalleeSavesBuffer): (JSC::AssemblyHelpers::loadWasmContextInstance): (JSC::AssemblyHelpers::storeWasmContextInstance): (JSC::AssemblyHelpers::loadWasmContextInstanceNeedsMacroScratchRegister): (JSC::AssemblyHelpers::storeWasmContextInstanceNeedsMacroScratchRegister): (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBufferImpl): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer): (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBuffer): (JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToEntryFrameCalleeSavesBuffer): * jit/JIT.cpp: (JSC::JIT::emitEnterOptimizationCheck): (JSC::JIT::privateCompileExceptionHandlers): * jit/JITExceptions.cpp: (JSC::genericUnwind): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_throw): (JSC::JIT::emit_op_catch): (JSC::JIT::emitSlow_op_loop_hint): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_throw): (JSC::JIT::emit_op_catch): * jit/JITOperations.cpp: * jit/ThunkGenerators.cpp: (JSC::throwExceptionFromCallSlowPathGenerator): (JSC::nativeForGenerator): * jsc.cpp: (functionDumpCallFrame): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LLIntThunks.cpp: (JSC::vmEntryRecord): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/Options.cpp: (JSC::recomputeDependentOptions): * runtime/Options.h: * runtime/SamplingProfiler.cpp: (JSC::FrameWalker::FrameWalker): (JSC::FrameWalker::advanceToParentFrame): (JSC::SamplingProfiler::processUnverifiedStackTraces): * runtime/ThrowScope.cpp: (JSC::ThrowScope::~ThrowScope): * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::~VM): * runtime/VM.h: (JSC::VM::topEntryFrameOffset): * runtime/VMTraps.cpp: (JSC::isSaneFrame): (JSC::VMTraps::tryInstallTrapBreakpoints): (JSC::VMTraps::invalidateCodeBlocksOnStack): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::restoreWasmContextInstance): (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState): (JSC::Wasm::B3IRGenerator::addGrowMemory): (JSC::Wasm::B3IRGenerator::addCurrentMemory): (JSC::Wasm::B3IRGenerator::addCall): (JSC::Wasm::B3IRGenerator::addCallIndirect): (JSC::Wasm::parseAndCompile): * wasm/WasmB3IRGenerator.h: * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::BBQPlan): (JSC::Wasm::BBQPlan::compileFunctions): (JSC::Wasm::BBQPlan::complete): * wasm/WasmBBQPlan.h: * wasm/WasmBBQPlanInlines.h: (JSC::Wasm::BBQPlan::initializeCallees): * wasm/WasmBinding.cpp: (JSC::Wasm::wasmToWasm): * wasm/WasmBinding.h: * wasm/WasmCodeBlock.cpp: (JSC::Wasm::CodeBlock::create): (JSC::Wasm::CodeBlock::CodeBlock): (JSC::Wasm::CodeBlock::compileAsync): (JSC::Wasm::CodeBlock::setCompilationFinished): * wasm/WasmCodeBlock.h: (JSC::Wasm::CodeBlock::offsetOfImportStubs): (JSC::Wasm::CodeBlock::allocationSize): (JSC::Wasm::CodeBlock::importWasmToEmbedderStub): (JSC::Wasm::CodeBlock::offsetOfImportWasmToEmbedderStub): (JSC::Wasm::CodeBlock::wasmToJSCallStubForImport): (JSC::Wasm::CodeBlock::compilationFinished): (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace): (JSC::Wasm::CodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace): * wasm/WasmContext.cpp: (JSC::Wasm::Context::useFastTLS): (JSC::Wasm::Context::load const): (JSC::Wasm::Context::store): * wasm/WasmContext.h: * wasm/WasmEmbedder.h: Copied from Source/JavaScriptCore/wasm/WasmContext.h. * wasm/WasmFaultSignalHandler.cpp: * wasm/WasmFaultSignalHandler.h: * wasm/WasmFormat.h: * wasm/WasmInstance.cpp: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h. (JSC::Wasm::Instance::Instance): (JSC::Wasm::Instance::~Instance): (JSC::Wasm::Instance::extraMemoryAllocated const): * wasm/WasmInstance.h: Added. (JSC::Wasm::Instance::create): (JSC::Wasm::Instance::finalizeCreation): (JSC::Wasm::Instance::module): (JSC::Wasm::Instance::codeBlock): (JSC::Wasm::Instance::memory): (JSC::Wasm::Instance::table): (JSC::Wasm::Instance::loadI32Global const): (JSC::Wasm::Instance::loadI64Global const): (JSC::Wasm::Instance::loadF32Global const): (JSC::Wasm::Instance::loadF64Global const): (JSC::Wasm::Instance::setGlobal): (JSC::Wasm::Instance::offsetOfCachedStackLimit): (JSC::Wasm::Instance::cachedStackLimit const): (JSC::Wasm::Instance::setCachedStackLimit): * wasm/WasmMemory.cpp: (JSC::Wasm::Memory::Memory): (JSC::Wasm::Memory::create): (JSC::Wasm::Memory::~Memory): (JSC::Wasm::Memory::grow): * wasm/WasmMemory.h: (JSC::Wasm::Memory::offsetOfMemory): (JSC::Wasm::Memory::offsetOfSize): * wasm/WasmMemoryInformation.cpp: (JSC::Wasm::PinnedRegisterInfo::get): (JSC::Wasm::PinnedRegisterInfo::PinnedRegisterInfo): * wasm/WasmMemoryInformation.h: (JSC::Wasm::PinnedRegisterInfo::toSave const): * wasm/WasmMemoryMode.cpp: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h. (JSC::Wasm::makeString): * wasm/WasmMemoryMode.h: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h. * wasm/WasmModule.cpp: (JSC::Wasm::makeValidationCallback): (JSC::Wasm::Module::validateSync): (JSC::Wasm::Module::validateAsync): (JSC::Wasm::Module::getOrCreateCodeBlock): (JSC::Wasm::Module::compileSync): (JSC::Wasm::Module::compileAsync): * wasm/WasmModule.h: * wasm/WasmModuleParser.cpp: (JSC::Wasm::ModuleParser::parseTableHelper): * wasm/WasmOMGPlan.cpp: (JSC::Wasm::OMGPlan::OMGPlan): (JSC::Wasm::OMGPlan::runForIndex): * wasm/WasmOMGPlan.h: * wasm/WasmPageCount.h: (JSC::Wasm::PageCount::isValid const): * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::Plan): (JSC::Wasm::Plan::runCompletionTasks): (JSC::Wasm::Plan::addCompletionTask): (JSC::Wasm::Plan::tryRemoveContextAndCancelIfLast): * wasm/WasmPlan.h: (JSC::Wasm::Plan::dontFinalize): * wasm/WasmSignature.cpp: * wasm/WasmSignature.h: * wasm/WasmTable.cpp: Added. (JSC::Wasm::Table::create): (JSC::Wasm::Table::~Table): (JSC::Wasm::Table::Table): (JSC::Wasm::Table::grow): (JSC::Wasm::Table::clearFunction): (JSC::Wasm::Table::setFunction): * wasm/WasmTable.h: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyTable.h. (JSC::Wasm::Table::maximum const): (JSC::Wasm::Table::size const): (JSC::Wasm::Table::offsetOfSize): (JSC::Wasm::Table::offsetOfFunctions): (JSC::Wasm::Table::offsetOfInstances): (JSC::Wasm::Table::isValidSize): * wasm/WasmThunks.cpp: (JSC::Wasm::throwExceptionFromWasmThunkGenerator): (JSC::Wasm::triggerOMGTierUpThunkGenerator): (JSC::Wasm::Thunks::setThrowWasmException): (JSC::Wasm::Thunks::throwWasmException): * wasm/WasmThunks.h: * wasm/WasmWorklist.cpp: (JSC::Wasm::Worklist::stopAllPlansForContext): * wasm/WasmWorklist.h: * wasm/js/JSToWasm.cpp: Added. (JSC::Wasm::createJSToWasmWrapper): * wasm/js/JSToWasm.h: Copied from Source/JavaScriptCore/wasm/WasmBinding.h. * wasm/js/JSWebAssembly.cpp: Renamed from Source/JavaScriptCore/wasm/JSWebAssembly.cpp. * wasm/js/JSWebAssembly.h: Renamed from Source/JavaScriptCore/wasm/JSWebAssembly.h. * wasm/js/JSWebAssemblyCodeBlock.cpp: (JSC::JSWebAssemblyCodeBlock::create): (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock): * wasm/js/JSWebAssemblyCodeBlock.h: * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance): (JSC::JSWebAssemblyInstance::finishCreation): (JSC::JSWebAssemblyInstance::visitChildren): (JSC::JSWebAssemblyInstance::finalizeCreation): (JSC::JSWebAssemblyInstance::create): * wasm/js/JSWebAssemblyInstance.h: (JSC::JSWebAssemblyInstance::instance): (JSC::JSWebAssemblyInstance::context const): (JSC::JSWebAssemblyInstance::table): (JSC::JSWebAssemblyInstance::webAssemblyToJSCallee): (JSC::JSWebAssemblyInstance::setMemory): (JSC::JSWebAssemblyInstance::offsetOfTail): (JSC::JSWebAssemblyInstance::importFunctionInfo): (JSC::JSWebAssemblyInstance::offsetOfTargetInstance): (JSC::JSWebAssemblyInstance::offsetOfWasmEntrypoint): (JSC::JSWebAssemblyInstance::offsetOfImportFunction): (JSC::JSWebAssemblyInstance::importFunction): (JSC::JSWebAssemblyInstance::internalMemory): (JSC::JSWebAssemblyInstance::wasmCodeBlock const): (JSC::JSWebAssemblyInstance::offsetOfWasmTable): (JSC::JSWebAssemblyInstance::offsetOfCallee): (JSC::JSWebAssemblyInstance::offsetOfGlobals): (JSC::JSWebAssemblyInstance::offsetOfWasmCodeBlock): (JSC::JSWebAssemblyInstance::offsetOfWasmMemory): (JSC::JSWebAssemblyInstance::cachedStackLimit const): (JSC::JSWebAssemblyInstance::setCachedStackLimit): (JSC::JSWebAssemblyInstance::wasmMemory): (JSC::JSWebAssemblyInstance::wasmModule): (JSC::JSWebAssemblyInstance::allocationSize): (JSC::JSWebAssemblyInstance::module const): * wasm/js/JSWebAssemblyMemory.cpp: (JSC::JSWebAssemblyMemory::create): (JSC::JSWebAssemblyMemory::adopt): (JSC::JSWebAssemblyMemory::JSWebAssemblyMemory): (JSC::JSWebAssemblyMemory::grow): (JSC::JSWebAssemblyMemory::growSuccessCallback): * wasm/js/JSWebAssemblyMemory.h: * wasm/js/JSWebAssemblyModule.cpp: (JSC::JSWebAssemblyModule::moduleInformation const): (JSC::JSWebAssemblyModule::exportSymbolTable const): (JSC::JSWebAssemblyModule::signatureIndexFromFunctionIndexSpace const): (JSC::JSWebAssemblyModule::callee const): (JSC::JSWebAssemblyModule::codeBlock): (JSC::JSWebAssemblyModule::module): * wasm/js/JSWebAssemblyModule.h: * wasm/js/JSWebAssemblyTable.cpp: (JSC::JSWebAssemblyTable::create): (JSC::JSWebAssemblyTable::JSWebAssemblyTable): (JSC::JSWebAssemblyTable::visitChildren): (JSC::JSWebAssemblyTable::grow): (JSC::JSWebAssemblyTable::getFunction): (JSC::JSWebAssemblyTable::clearFunction): (JSC::JSWebAssemblyTable::setFunction): * wasm/js/JSWebAssemblyTable.h: (JSC::JSWebAssemblyTable::isValidSize): (JSC::JSWebAssemblyTable::maximum const): (JSC::JSWebAssemblyTable::size const): (JSC::JSWebAssemblyTable::table): * wasm/js/WasmToJS.cpp: Copied from Source/JavaScriptCore/wasm/WasmBinding.cpp. (JSC::Wasm::materializeImportJSCell): (JSC::Wasm::wasmToJS): (JSC::Wasm::wasmToJSException): * wasm/js/WasmToJS.h: Copied from Source/JavaScriptCore/wasm/WasmBinding.h. * wasm/js/WebAssemblyFunction.cpp: (JSC::callWebAssemblyFunction): * wasm/js/WebAssemblyInstanceConstructor.cpp: (JSC::constructJSWebAssemblyInstance): * wasm/js/WebAssemblyMemoryConstructor.cpp: (JSC::constructJSWebAssemblyMemory): * wasm/js/WebAssemblyMemoryPrototype.cpp: (JSC::webAssemblyMemoryProtoFuncGrow): * wasm/js/WebAssemblyModuleConstructor.cpp: (JSC::constructJSWebAssemblyModule): (JSC::WebAssemblyModuleConstructor::createModule): * wasm/js/WebAssemblyModuleConstructor.h: * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::link): (JSC::WebAssemblyModuleRecord::evaluate): * wasm/js/WebAssemblyPrototype.cpp: (JSC::webAssemblyCompileFunc): (JSC::instantiate): (JSC::compileAndInstantiate): (JSC::webAssemblyValidateFunc): * wasm/js/WebAssemblyTableConstructor.cpp: (JSC::constructJSWebAssemblyTable): * wasm/js/WebAssemblyWrapperFunction.cpp: (JSC::WebAssemblyWrapperFunction::create): 2017-10-02 Keith Miller VMTraps shouldn't crash if it sees an exception it doesn't understand. https://bugs.webkit.org/show_bug.cgi?id=177780 Reviewed by Mark Lam. VMTraps could see a JIT breakpoint (SegV) for any number of reasons it doesn't understand. e.g. a bug in JIT code, Wasm OOB, etc. This patch makes it handle that case gracefully. It's worth noting that this means there's no way to know if, due to a bug, we didn't accurately track all the VMTraps we installed. I'm not sure if there is a good solution to that problem though. * runtime/VMTraps.cpp: 2017-10-02 Saam Barati Unreviewed. Add missing exception check for the custom-get-set-inline-caching-one-level-up-proto-chain.js test that I added. It uncovered a pre-existing missing exception check. * runtime/JSObject.cpp: (JSC::JSObject::putInlineSlow): 2017-10-02 Joseph Pecoraro Web Inspector: Include Beacon and Ping requests in Network tab https://bugs.webkit.org/show_bug.cgi?id=177641 Reviewed by Chris Dumez. * inspector/protocol/Page.json: Include new "Beacon" and "Ping" resource types. 2017-10-02 Caio Lima ChakraCore/test/Function/apply3.js is resulting wrong result in x86_64 https://bugs.webkit.org/show_bug.cgi?id=175642 Reviewed by Darin Adler. According JS spec, the ToLength operation[1] has a range of 0..(2^53) - 1. In Interpreter.cpp::sizeFrameForVarargs, the call to sizeOfVarargs() was being assigned to "unsigned length", forcing a type cast that results in different value among architectures JSC supports. For instance, in x86_64 "4294967295 + 1" results in 0, while in ARMv6 it results 4294967295. This patch is changing "sizeOfVarargs" to clamp the result from "toLength" to unsigned and then get desired behavior for all supported platforms. [1] - https://tc39.github.io/ecma262/#sec-tolength * interpreter/Interpreter.cpp: (JSC::sizeOfVarargs): * interpreter/Interpreter.h: 2017-10-02 Saam Barati Unreviewed. Fix debug assertion after r222671. JSTestCustomGetterSetter::finishCreation needs to call its base's finishCreation implementation. * jsc.cpp: (JSTestCustomGetterSetter::finishCreation): 2017-10-01 Commit Queue Unreviewed, rolling out r222564. https://bugs.webkit.org/show_bug.cgi?id=177720 "It regressed JetStream by 2% on iOS caused by a 50% regression on the bigfib subtest" (Requested by saamyjoon on #webkit). Reverted changeset: "Add Above/Below comparisons for UInt32 patterns" https://bugs.webkit.org/show_bug.cgi?id=177281 http://trac.webkit.org/changeset/222564 2017-09-29 Yusuke Suzuki [DFG] Support ArrayPush with multiple args https://bugs.webkit.org/show_bug.cgi?id=175823 Reviewed by Saam Barati. Reviewed by Saam Barati. This patch implements ArrayPush(with multiple arguments) in DFG and FTL. Previously, they are not handled by ArrayPush. Then they go to generic direct call to Array#push and it does in slow path. This patch extends ArrayPush to push multiple arguments in a bulk push manner. The problem of ArrayPush is that we need to perform ArrayPush atomically: If OSR exit occurs in the middle of ArrayPush, we incorrectly push pushed elements twice. Once we start pushing values, we should not exit. But we do not want to iterate elements twice, once for type checks and once for actually pushing it. It could move elements between registers and memory back and forth. This patch achieves the above goal by separating type checks from ArrayPush. When starting ArrayPush, type checks for elements are already done by separately emitted Check nodes. We also add JSArray::pushInline for DFG operations just calling JSArray::push. And we also use it in arrayProtoFuncPush's fast path. This patch significantly improves performance of `push(multiple args)`. baseline patched Microbenchmarks: array-push-0 461.8455+-28.9995 ^ 151.3438+-6.5653 ^ definitely 3.0516x faster array-push-1 133.8845+-7.0349 ? 136.1775+-5.8327 ? might be 1.0171x slower array-push-2 675.6555+-13.4645 ^ 145.8747+-6.4621 ^ definitely 4.6318x faster array-push-3 849.5284+-15.2540 ^ 253.4421+-9.1249 ^ definitely 3.3520x faster baseline patched SixSpeed: spread-literal.es5 90.3482+-6.6514 ^ 24.8123+-2.3304 ^ definitely 3.6413x faster * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsicCall): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArrayPush): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStoreBarrierInsertionPhase.cpp: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileArrayPush): * jit/JITOperations.h: * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncPush): * runtime/JSArray.cpp: (JSC::JSArray::push): * runtime/JSArray.h: * runtime/JSArrayInlines.h: (JSC::JSArray::pushInline): 2017-09-29 Saam Barati Custom GetterSetterAccessCase does not use the correct slotBase when making call https://bugs.webkit.org/show_bug.cgi?id=177639 Reviewed by Geoffrey Garen. The bug occurred when you had a custom set value. Custom set/get values are passed the property holder, not the base of the access. If we had an object chain like this: o = {__proto__: thingWithCustomSetValue} We would end up not providing thingWithCustomSetValue as the argument to the PutValueFunc. The reason is, we would use generateConditionsForPrototypePropertyHitCustom for custom sets. This would return to us an empty ConditionSet, because the property holder was only one level up the prototype chain. The reason is, it didn't generate a condition for the slot holder, because the protocol for custom set/get is that if an object responds to a custom setter/getter, it will continue to respond to that getter/setter for the lifetime of that object. Therefore, it's not strictly necessary to generate an OPC for the slot base for custom accesses. However, AccessCase uses !m_conditionSet.isEmtpy() to indicate that the IC is doing a prototype access. With the above object "o", we were doing a prototype access, but we had an empty condition set. This lead us to passing the base instead of the property holder to the custom set value function, which is incorrect. With custom getters, we never called to into the generateConditionsForPrototypePropertyHitCustom API. Gets would always call into generateConditionsForPrototypePropertyHit, which will generate an OPC on the slot base, even if it isn't strictly necessary for custom accessors. This patch simply removes generateConditionsForPrototypePropertyHitCustom and aligns the set case with the get case. It makes us properly detect when we're doing a prototype access with the above object "o". If we find that generateConditionsForPrototypePropertyHitCustom was a worthwhile optimization to have, we can re-introduce it. We'll just need to pipe through a new notion of when we're doing prototype accesses that doesn't rely solely on !m_conditionSet.isEmpty(). * bytecode/ObjectPropertyConditionSet.cpp: (JSC::generateConditionsForPrototypePropertyHitCustom): Deleted. * bytecode/ObjectPropertyConditionSet.h: * jit/Repatch.cpp: (JSC::tryCachePutByID): * jsc.cpp: (JSTestCustomGetterSetter::JSTestCustomGetterSetter): (JSTestCustomGetterSetter::create): (JSTestCustomGetterSetter::createStructure): (customGetAccessor): (customGetValue): (customSetAccessor): (customSetValue): (JSTestCustomGetterSetter::finishCreation): (GlobalObject::finishCreation): (functionLoadGetterFromGetterSetter): (functionCreateCustomTestGetterSetter): * runtime/PropertySlot.h: (JSC::PropertySlot::setCustomGetterSetter): 2017-09-29 Commit Queue Unreviewed, rolling out r222563, r222565, and r222581. https://bugs.webkit.org/show_bug.cgi?id=177675 "It causes a crash when playing youtube videos" (Requested by saamyjoon on #webkit). Reverted changesets: "[DFG] Support ArrayPush with multiple args" https://bugs.webkit.org/show_bug.cgi?id=175823 http://trac.webkit.org/changeset/222563 "Unreviewed, build fix after r222563" https://bugs.webkit.org/show_bug.cgi?id=175823 http://trac.webkit.org/changeset/222565 "Unreviewed, fix x86 breaking due to exhausted registers" https://bugs.webkit.org/show_bug.cgi?id=175823 http://trac.webkit.org/changeset/222581 2017-09-29 Commit Queue Unreviewed, rolling out r222625. https://bugs.webkit.org/show_bug.cgi?id=177664 causes crashes on iOS (Requested by pizlo-mbp on #webkit). Reverted changeset: "Enable gigacage on iOS" https://bugs.webkit.org/show_bug.cgi?id=177586 http://trac.webkit.org/changeset/222625 2017-09-28 Mark Lam test262: Unexpected passes after r222617 and r222618. https://bugs.webkit.org/show_bug.cgi?id=177622 Reviewed by Saam Barati. Now that these tests are marked as "normal", we will run them and discover a few missing exception checks. This patch also adds those missing exception checks. * runtime/DatePrototype.cpp: (JSC::fillStructuresUsingDateArgs): 2017-09-28 Mark Lam Add missing exception checks and book-keeping for exception check validation. https://bugs.webkit.org/show_bug.cgi?id=177609 Reviewed by Keith Miller. This resolves exception check validation failures when running test262 tests and a few other tests. * API/APIUtils.h: (handleExceptionIfNeeded): * API/JSObjectRef.cpp: (JSObjectMakeFunction): (JSObjectMakeArray): (JSObjectMakeDate): (JSObjectMakeError): (JSObjectMakeRegExp): (JSObjectSetPrototype): (JSObjectGetProperty): (JSObjectSetProperty): (JSObjectGetPropertyAtIndex): (JSObjectSetPropertyAtIndex): (JSObjectDeleteProperty): (JSObjectCallAsFunction): (JSObjectCallAsConstructor): * API/JSTypedArray.cpp: (JSObjectMakeTypedArray): (JSObjectMakeTypedArrayWithBytesNoCopy): (JSObjectMakeTypedArrayWithArrayBuffer): (JSObjectMakeTypedArrayWithArrayBufferAndOffset): (JSObjectMakeArrayBufferWithBytesNoCopy): * API/JSValueRef.cpp: (JSValueIsEqual): (JSValueIsInstanceOfConstructor): (JSValueCreateJSONString): (JSValueToNumber): (JSValueToStringCopy): (JSValueToObject): * interpreter/Interpreter.cpp: (JSC::Interpreter::executeProgram): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncIndexOf): (JSC::arrayProtoFuncLastIndexOf): * runtime/DatePrototype.cpp: (JSC::fillStructuresUsingTimeArgs): (JSC::setNewValueFromDateArgs): (JSC::dateProtoFuncSetYear): * runtime/JSGenericTypedArrayViewConstructorInlines.h: (JSC::constructGenericTypedArrayViewWithArguments): * runtime/JSModuleEnvironment.cpp: (JSC::JSModuleEnvironment::put): * runtime/ProgramExecutable.cpp: (JSC::ProgramExecutable::initializeGlobalProperties): * runtime/ProxyObject.cpp: (JSC::ProxyObject::toStringName): * runtime/StringPrototype.cpp: (JSC::stringProtoFuncCharAt): (JSC::stringProtoFuncCharCodeAt): (JSC::stringProtoFuncIndexOf): (JSC::stringProtoFuncLastIndexOf): (JSC::stringProtoFuncSlice): (JSC::stringProtoFuncSplitFast): (JSC::stringProtoFuncSubstr): 2017-09-27 Michael Saboff REGRESSION(210837): RegExp containing failed non-zero minimum greedy groups incorrectly match https://bugs.webkit.org/show_bug.cgi?id=177570 Reviewed by Filip Pizlo. The change in r210837 neglected to change the check in Interpreter::backtrackParentheses() that greedy parenthesis have backtracked as far as possible. Prior to r210837, non-zero minimum greedy parenthesis were factored into a fixed component and a zero-based variable component. After r210837, the variable component is not zero based and the check needs to compare the backTrack->matchAmount with the quantity iminimum count. * yarr/YarrInterpreter.cpp: (JSC::Yarr::Interpreter::backtrackParentheses): 2017-09-28 Michael Saboff Heap out of bounds read in JSC::Yarr::Parser::peek() https://bugs.webkit.org/show_bug.cgi?id=177423 Reviewed by Mark Lam. Updated fix that restructures that changes the do ... while to a while and adds another atEndOfPattern() check before looking for the first named group identifier character. * yarr/YarrParser.h: (JSC::Yarr::Parser::tryConsumeGroupName): 2017-09-27 Mark Lam JSArray::canFastCopy() should fail if the source and destination arrays are the same. https://bugs.webkit.org/show_bug.cgi?id=177584 Reviewed by Saam Barati. If the source and destination arrays are the same, we may be copying overlapping regions. Hence, we need to take the slow path. * runtime/JSArrayInlines.h: (JSC::JSArray::canFastCopy): 2017-09-27 Saam Barati Propagate hasBeenFlattenedBefore in Structure's transition constructor and fix our for-in caching to fail when the prototype chain has an object with a dictionary structure https://bugs.webkit.org/show_bug.cgi?id=177523 Reviewed by Mark Lam. There was a bug in Structure's transition constructor where it didn't propagate forward the hasBeenFlattenedBefore bit. In practice, this meant that every time we asked a dictionary structure if it has been flattened before, it would return false. This patch fixes this bug. It also fixes a bug that this uncovers in our for-in implementation. Our implementation would cache the property name enumerator even when the prototype chain included a structure that is as dictionary. This is wrong because that prototype object may add properties without transitioning, and the for-in loop would vend a stale set of prototype properties. * jit/JITOperations.cpp: * runtime/JSPropertyNameEnumerator.h: (JSC::propertyNameEnumerator): * runtime/Structure.cpp: (JSC::Structure::Structure): (JSC::Structure::canCachePropertyNameEnumerator const): 2017-09-27 Mark Lam Yarr::Parser::tryConsumeGroupName() should check for the end of the pattern. https://bugs.webkit.org/show_bug.cgi?id=177423 Reviewed by Keith Miller. * yarr/YarrParser.h: (JSC::Yarr::Parser::tryConsumeGroupName): 2017-09-27 Yusuke Suzuki Unreviewed, fix x86 breaking due to exhausted registers https://bugs.webkit.org/show_bug.cgi?id=175823 * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsicCall): 2017-09-27 Yusuke Suzuki Unreviewed, build fix after r222563 https://bugs.webkit.org/show_bug.cgi?id=175823 * runtime/JSArrayInlines.h: 2017-09-27 Yusuke Suzuki Add Above/Below comparisons for UInt32 patterns https://bugs.webkit.org/show_bug.cgi?id=177281 Reviewed by Saam Barati. Sometimes, we would like to have UInt32 operations in JS. While VM does not support UInt32 nicely, VM supports efficient Int32 operations. As long as signedness does not matter, we can just perform Int32 operations instead and recognize its bit pattern as UInt32. But of course, some operations respect signedness. The most frequently used one is comparison. Octane/zlib performs UInt32 comparison by performing `val >>> 0`. It emits op_urshift and op_unsigned. op_urshift produces UInt32 in Int32 form. And op_unsigned will generate Double value if the generated Int32 is < 0 (which should be UInt32). There is a chance for optimization. The given code pattern is the following. op_unsigned(op_urshift(@1)) lessThan:< op_unsigned(op_urshift(@2)) This can be converted to the following. op_urshift(@1) below:< op_urshift(@2) The above conversion is nice since 1. We can avoid op_unsigned. This could be unsignedness check in DFG. Since this check depends on the value of Int32, dropping this check is not as easy as removing Int32 edge filters. 2. We can perform unsigned comparison in Int32 form. We do not need to convert them to DoubleRep. Since the above comparison exists in Octane/zlib's *super* hot path, dropping op_unsigned offers huge win. At first, my patch attempts to convert the above thing in DFG pipeline. However it poses several problems. 1. MovHint is not well removed. It makes UInt32ToNumber (which is for op_unsigned) live. 2. UInt32ToNumber could cause an OSR exit. So if we have the following nodes, 2: UInt32ToNumber(@0) 3: MovHint(@2, xxx) 4: UInt32ToNumber(@1) 5: MovHint(@1, xxx) we could drop @5's MovHint. But @3 is difficult since @4 can exit. So, instead, we start introducing a simple optimization in the bytecode compiler. It performs pattern matching for op_urshift and comparison to drop op_unsigned. We adds op_below and op_above families to bytecodes. They only accept Int32 and perform unsigned comparison. This offers 4% performance improvement in Octane/zlib. baseline patched zlib x2 431.07483+-16.28434 414.33407+-9.38375 might be 1.0404x faster * bytecode/BytecodeDumper.cpp: (JSC::BytecodeDumper::printCompareJump): (JSC::BytecodeDumper::dumpBytecode): * bytecode/BytecodeDumper.h: * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/Opcode.h: (JSC::isBranch): * bytecode/PreciseJumpTargetsInlines.h: (JSC::extractStoredJumpTargetsForBytecodeOffset): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitJumpIfTrue): (JSC::BytecodeGenerator::emitJumpIfFalse): * bytecompiler/NodesCodegen.cpp: (JSC::BinaryOpNode::emitBytecode): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGIntegerRangeOptimizationPhase.cpp: * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCompareUnsigned): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::handleNode): * dfg/DFGValidate.cpp: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileCompareBelow): (JSC::FTL::DFG::LowerDFGToB3::compileCompareBelowEq): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JIT.h: * jit/JITArithmetic.cpp: (JSC::JIT::emit_op_below): (JSC::JIT::emit_op_beloweq): (JSC::JIT::emit_op_jbelow): (JSC::JIT::emit_op_jbeloweq): (JSC::JIT::emit_compareUnsignedAndJump): (JSC::JIT::emit_compareUnsigned): * jit/JITArithmetic32_64.cpp: (JSC::JIT::emit_compareUnsignedAndJump): (JSC::JIT::emit_compareUnsigned): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * parser/Nodes.h: (JSC::ExpressionNode::isBinaryOpNode const): 2017-09-25 Yusuke Suzuki [DFG] Support ArrayPush with multiple args https://bugs.webkit.org/show_bug.cgi?id=175823 Reviewed by Saam Barati. This patch implements ArrayPush(with multiple arguments) in DFG and FTL. Previously, they are not handled by ArrayPush. Then they go to generic direct call to Array#push and it does in slow path. This patch extends ArrayPush to push multiple arguments in a bulk push manner. The problem of ArrayPush is that we need to perform ArrayPush atomically: If OSR exit occurs in the middle of ArrayPush, we incorrectly push pushed elements twice. Once we start pushing values, we should not exit. But we do not want to iterate elements twice, once for type checks and once for actually pushing it. It could move elements between registers and memory back and forth. This patch achieves the above goal by separating type checks from ArrayPush. When starting ArrayPush, type checks for elements are already done by separately emitted Check nodes. We also add JSArray::pushInline for DFG operations just calling JSArray::push. And we also use it in arrayProtoFuncPush's fast path. This patch significantly improves performance of `push(multiple args)`. baseline patched Microbenchmarks: array-push-0 461.8455+-28.9995 ^ 151.3438+-6.5653 ^ definitely 3.0516x faster array-push-1 133.8845+-7.0349 ? 136.1775+-5.8327 ? might be 1.0171x slower array-push-2 675.6555+-13.4645 ^ 145.8747+-6.4621 ^ definitely 4.6318x faster array-push-3 849.5284+-15.2540 ^ 253.4421+-9.1249 ^ definitely 3.3520x faster baseline patched SixSpeed: spread-literal.es5 90.3482+-6.6514 ^ 24.8123+-2.3304 ^ definitely 3.6413x faster * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsicCall): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArrayPush): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStoreBarrierInsertionPhase.cpp: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileArrayPush): * jit/JITOperations.h: * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncPush): * runtime/JSArray.cpp: (JSC::JSArray::push): * runtime/JSArray.h: * runtime/JSArrayInlines.h: (JSC::JSArray::pushInline): 2017-09-26 Joseph Pecoraro Web Inspector: Remove unused parameter of Page.reload https://bugs.webkit.org/show_bug.cgi?id=177522 Reviewed by Matt Baker. * inspector/protocol/Page.json: 2017-09-26 Filip Pizlo Put g_gigacageBasePtr into its own page and make it read-only https://bugs.webkit.org/show_bug.cgi?id=174972 Reviewed by Michael Saboff. C++ code doesn't have to know about this change. That includes C++ code that generates JIT code. But the offline assembler now needs to know about how to load from offsets of global variables. This turned out to be easy to support by extending the existing expression support. * llint/LowLevelInterpreter64.asm: * offlineasm/ast.rb: * offlineasm/parser.rb: * offlineasm/transform.rb: * offlineasm/x86.rb: 2017-09-26 Commit Queue Unreviewed, rolling out r222518. https://bugs.webkit.org/show_bug.cgi?id=177507 Break the High Sierra build (Requested by yusukesuzuki on #webkit). Reverted changeset: "Add Above/Below comparisons for UInt32 patterns" https://bugs.webkit.org/show_bug.cgi?id=177281 http://trac.webkit.org/changeset/222518 2017-09-26 Yusuke Suzuki Add Above/Below comparisons for UInt32 patterns https://bugs.webkit.org/show_bug.cgi?id=177281 Reviewed by Saam Barati. Sometimes, we would like to have UInt32 operations in JS. While VM does not support UInt32 nicely, VM supports efficient Int32 operations. As long as signedness does not matter, we can just perform Int32 operations instead and recognize its bit pattern as UInt32. But of course, some operations respect signedness. The most frequently used one is comparison. Octane/zlib performs UInt32 comparison by performing `val >>> 0`. It emits op_urshift and op_unsigned. op_urshift produces UInt32 in Int32 form. And op_unsigned will generate Double value if the generated Int32 is < 0 (which should be UInt32). There is a chance for optimization. The given code pattern is the following. op_unsigned(op_urshift(@1)) lessThan:< op_unsigned(op_urshift(@2)) This can be converted to the following. op_urshift(@1) below:< op_urshift(@2) The above conversion is nice since 1. We can avoid op_unsigned. This could be unsignedness check in DFG. Since this check depends on the value of Int32, dropping this check is not as easy as removing Int32 edge filters. 2. We can perform unsigned comparison in Int32 form. We do not need to convert them to DoubleRep. Since the above comparison exists in Octane/zlib's *super* hot path, dropping op_unsigned offers huge win. At first, my patch attempts to convert the above thing in DFG pipeline. However it poses several problems. 1. MovHint is not well removed. It makes UInt32ToNumber (which is for op_unsigned) live. 2. UInt32ToNumber could cause an OSR exit. So if we have the following nodes, 2: UInt32ToNumber(@0) 3: MovHint(@2, xxx) 4: UInt32ToNumber(@1) 5: MovHint(@1, xxx) we could drop @5's MovHint. But @3 is difficult since @4 can exit. So, instead, we start introducing a simple optimization in the bytecode compiler. It performs pattern matching for op_urshift and comparison to drop op_unsigned. We adds op_below and op_above families to bytecodes. They only accept Int32 and perform unsigned comparison. This offers 4% performance improvement in Octane/zlib. baseline patched zlib x2 431.07483+-16.28434 414.33407+-9.38375 might be 1.0404x faster * bytecode/BytecodeDumper.cpp: (JSC::BytecodeDumper::printCompareJump): (JSC::BytecodeDumper::dumpBytecode): * bytecode/BytecodeDumper.h: * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/Opcode.h: (JSC::isBranch): * bytecode/PreciseJumpTargetsInlines.h: (JSC::extractStoredJumpTargetsForBytecodeOffset): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitJumpIfTrue): (JSC::BytecodeGenerator::emitJumpIfFalse): * bytecompiler/NodesCodegen.cpp: (JSC::BinaryOpNode::emitBytecode): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGIntegerRangeOptimizationPhase.cpp: * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCompareUnsigned): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::handleNode): * dfg/DFGValidate.cpp: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileCompareBelow): (JSC::FTL::DFG::LowerDFGToB3::compileCompareBelowEq): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JIT.h: * jit/JITArithmetic.cpp: (JSC::JIT::emit_op_below): (JSC::JIT::emit_op_beloweq): (JSC::JIT::emit_op_jbelow): (JSC::JIT::emit_op_jbeloweq): (JSC::JIT::emit_compareUnsignedAndJump): (JSC::JIT::emit_compareUnsigned): * jit/JITArithmetic32_64.cpp: (JSC::JIT::emit_compareUnsignedAndJump): (JSC::JIT::emit_compareUnsigned): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * parser/Nodes.h: (JSC::ExpressionNode::isBinaryOpNode const): 2017-09-24 Keith Miller JSC build should use unified sources for derived sources https://bugs.webkit.org/show_bug.cgi?id=177421 Reviewed by JF Bastien. This patch make a couple of changes: 1) Make derived sources added to relevant bundles. I was going to add JSCBuiltins.cpp to runtime but that kept breaking the windows build. I'll get back to it later 2) Move the derived location of some sources both for clarity and for ease of use. 3) Make auto generator scripts able to create directories if needed. 4) Move some scripts from the top level of the JavaScriptCore directory to a more appropriate directory. 5) Move some CMake generation commands around for clarity. * CMakeLists.txt: * DerivedSources.make: * JavaScriptCore.xcodeproj/project.pbxproj: * Scripts/lazywriter.py: (LazyFileWriter.close): * Sources.txt: * inspector/scripts/generate-inspector-protocol-bindings.py: (IncrementalFileWriter.close): * yarr/create_regex_tables: Renamed from Source/JavaScriptCore/create_regex_tables. * yarr/generateYarrCanonicalizeUnicode: Renamed from Source/JavaScriptCore/generateYarrCanonicalizeUnicode. 2017-09-26 Zan Dobersek Support building JavaScriptCore with the Bionic C library https://bugs.webkit.org/show_bug.cgi?id=177427 Reviewed by Michael Catanzaro. When compiling with the Bionic C library, the MachineContext.h header should enable the same code paths that are enabled for the GNU C library. The Bionic C library defines the __BIONIC__ macro, but unlike other C libraries that mimic the GNU one, it doesn't define __GLIBC__. So the __BIONIC__ macro checks have to match the __GLIBC__ ones. * runtime/MachineContext.h: (JSC::MachineContext::stackPointer): (JSC::MachineContext::framePointer): (JSC::MachineContext::instructionPointer): (JSC::MachineContext::argumentPointer<1>): (JSC::MachineContext::llintInstructionPointer): 2017-09-25 Devin Rousso Web Inspector: move Console.addInspectedNode to DOM.setInspectedNode https://bugs.webkit.org/show_bug.cgi?id=176827 Reviewed by Joseph Pecoraro. * inspector/agents/InspectorConsoleAgent.h: * inspector/agents/JSGlobalObjectConsoleAgent.h: * inspector/agents/JSGlobalObjectConsoleAgent.cpp: (Inspector::JSGlobalObjectConsoleAgent::addInspectedNode): Deleted. * inspector/protocol/Console.json: * inspector/protocol/DOM.json: 2017-09-25 Ryan Haddad Unreviewed, rebaseline builtins generator tests after r222473. * Scripts/tests/builtins/expected/WebCoreJSBuiltins.h-result: 2017-09-25 Alex Christensen Make Attribute an enum class https://bugs.webkit.org/show_bug.cgi?id=177414 Reviewed by Yusuke Suzuki. I've had enough of these naming collisions. This is what enum classes are for. Unfortunately a lot of static_cast is necessary until those functions take an OptionSet instead of an unsigned parameter, but this is a big step towards where we ought to be. * API/JSCallbackObjectFunctions.h: (JSC::JSCallbackObject::getOwnPropertySlot): * API/JSObjectRef.cpp: (JSObjectMakeConstructor): * Scripts/builtins/builtins_generate_internals_wrapper_implementation.py: (BuiltinsInternalsWrapperImplementationGenerator.property_macro): * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeFromLLInt): (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback): (JSC::GetByIdStatus::computeFor): * bytecode/PropertyCondition.cpp: (JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint const): (JSC::PropertyCondition::isValidValueForAttributes): * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeFor): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::instantiateLexicalVariables): (JSC::BytecodeGenerator::variable): * bytecompiler/BytecodeGenerator.h: (JSC::Variable::isReadOnly const): (JSC::Variable::setIsReadOnly): * bytecompiler/NodesCodegen.cpp: (JSC::PropertyListNode::emitBytecode): * create_hash_table: * debugger/DebuggerScope.cpp: (JSC::DebuggerScope::getOwnPropertySlot): * dfg/DFGOperations.cpp: * inspector/JSInjectedScriptHostPrototype.cpp: (Inspector::JSInjectedScriptHostPrototype::finishCreation): * inspector/JSJavaScriptCallFramePrototype.cpp: (Inspector::JSJavaScriptCallFramePrototype::finishCreation): * jit/Repatch.cpp: (JSC::tryCacheGetByID): * jsc.cpp: (WTF::CustomGetter::getOwnPropertySlot): (WTF::RuntimeArray::getOwnPropertySlot): (WTF::RuntimeArray::getOwnPropertySlotByIndex): (WTF::DOMJITGetter::finishCreation): (WTF::DOMJITGetterComplex::finishCreation): (WTF::DOMJITFunctionObject::finishCreation): (WTF::DOMJITCheckSubClassObject::finishCreation): (GlobalObject::finishCreation): * runtime/ArrayConstructor.cpp: (JSC::ArrayConstructor::finishCreation): * runtime/ArrayIteratorPrototype.cpp: (JSC::ArrayIteratorPrototype::finishCreation): * runtime/ArrayPrototype.cpp: (JSC::ArrayPrototype::finishCreation): * runtime/AsyncFromSyncIteratorPrototype.cpp: (JSC::AsyncFromSyncIteratorPrototype::finishCreation): * runtime/AsyncFunctionConstructor.cpp: (JSC::AsyncFunctionConstructor::finishCreation): * runtime/AsyncFunctionPrototype.cpp: (JSC::AsyncFunctionPrototype::finishCreation): * runtime/AsyncGeneratorFunctionConstructor.cpp: (JSC::AsyncGeneratorFunctionConstructor::finishCreation): * runtime/AsyncGeneratorFunctionPrototype.cpp: (JSC::AsyncGeneratorFunctionPrototype::finishCreation): * runtime/AsyncGeneratorPrototype.cpp: (JSC::AsyncGeneratorPrototype::finishCreation): * runtime/AsyncIteratorPrototype.cpp: (JSC::AsyncIteratorPrototype::finishCreation): * runtime/AtomicsObject.cpp: (JSC::AtomicsObject::finishCreation): * runtime/BooleanConstructor.cpp: (JSC::BooleanConstructor::finishCreation): * runtime/ClonedArguments.cpp: (JSC::ClonedArguments::createStructure): (JSC::ClonedArguments::getOwnPropertySlot): (JSC::ClonedArguments::materializeSpecials): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/ConsoleObject.cpp: (JSC::ConsoleObject::finishCreation): * runtime/DateConstructor.cpp: (JSC::DateConstructor::finishCreation): * runtime/DatePrototype.cpp: (JSC::DatePrototype::finishCreation): * runtime/DirectArguments.cpp: (JSC::DirectArguments::overrideThings): * runtime/Error.cpp: (JSC::addErrorInfo): * runtime/ErrorConstructor.cpp: (JSC::ErrorConstructor::finishCreation): * runtime/ErrorInstance.cpp: (JSC::ErrorInstance::finishCreation): * runtime/ErrorPrototype.cpp: (JSC::ErrorPrototype::finishCreation): * runtime/FunctionConstructor.cpp: (JSC::FunctionConstructor::finishCreation): * runtime/FunctionPrototype.cpp: (JSC::FunctionPrototype::finishCreation): (JSC::FunctionPrototype::addFunctionProperties): (JSC::FunctionPrototype::initRestrictedProperties): * runtime/GeneratorFunctionConstructor.cpp: (JSC::GeneratorFunctionConstructor::finishCreation): * runtime/GeneratorFunctionPrototype.cpp: (JSC::GeneratorFunctionPrototype::finishCreation): * runtime/GeneratorPrototype.cpp: (JSC::GeneratorPrototype::finishCreation): * runtime/GenericArgumentsInlines.h: (JSC::GenericArguments::getOwnPropertySlot): (JSC::GenericArguments::getOwnPropertySlotByIndex): * runtime/InternalFunction.cpp: (JSC::InternalFunction::finishCreation): * runtime/IntlCollatorConstructor.cpp: (JSC::IntlCollatorConstructor::finishCreation): * runtime/IntlDateTimeFormatConstructor.cpp: (JSC::IntlDateTimeFormatConstructor::finishCreation): * runtime/IntlDateTimeFormatPrototype.cpp: (JSC::IntlDateTimeFormatPrototype::finishCreation): * runtime/IntlNumberFormatConstructor.cpp: (JSC::IntlNumberFormatConstructor::finishCreation): * runtime/IntlObject.cpp: (JSC::IntlObject::finishCreation): * runtime/IteratorPrototype.cpp: (JSC::IteratorPrototype::finishCreation): * runtime/JSArray.cpp: (JSC::JSArray::getOwnPropertySlot): (JSC::JSArray::setLengthWithArrayStorage): * runtime/JSArrayBufferConstructor.cpp: (JSC::JSArrayBufferConstructor::finishCreation): * runtime/JSArrayBufferPrototype.cpp: (JSC::JSArrayBufferPrototype::finishCreation): * runtime/JSBoundFunction.cpp: (JSC::JSBoundFunction::finishCreation): * runtime/JSCJSValue.cpp: (JSC::JSValue::putToPrimitive): * runtime/JSDataView.cpp: (JSC::JSDataView::getOwnPropertySlot): * runtime/JSDataViewPrototype.cpp: (JSC::JSDataViewPrototype::finishCreation): * runtime/JSFunction.cpp: (JSC::JSFunction::finishCreation): (JSC::JSFunction::getOwnPropertySlot): (JSC::JSFunction::defineOwnProperty): (JSC::JSFunction::reifyLength): (JSC::JSFunction::reifyName): (JSC::JSFunction::reifyLazyBoundNameIfNeeded): * runtime/JSGenericTypedArrayViewConstructorInlines.h: (JSC::JSGenericTypedArrayViewConstructor::finishCreation): * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::getOwnPropertySlot): (JSC::JSGenericTypedArrayView::getOwnPropertySlotByIndex): * runtime/JSGenericTypedArrayViewPrototypeInlines.h: (JSC::JSGenericTypedArrayViewPrototype::finishCreation): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::addStaticGlobals): * runtime/JSLexicalEnvironment.cpp: (JSC::JSLexicalEnvironment::getOwnNonIndexPropertyNames): * runtime/JSModuleNamespaceObject.cpp: (JSC::JSModuleNamespaceObject::finishCreation): (JSC::JSModuleNamespaceObject::getOwnPropertySlotCommon): * runtime/JSONObject.cpp: (JSC::JSONObject::finishCreation): * runtime/JSObject.cpp: (JSC::getClassPropertyNames): (JSC::JSObject::getOwnPropertySlotByIndex): (JSC::ordinarySetSlow): (JSC::JSObject::putInlineSlow): (JSC::JSObject::putGetter): (JSC::JSObject::putSetter): (JSC::JSObject::putDirectAccessor): (JSC::JSObject::putDirectCustomAccessor): (JSC::JSObject::putDirectNonIndexAccessor): (JSC::JSObject::deleteProperty): (JSC::JSObject::deletePropertyByIndex): (JSC::JSObject::getOwnPropertyNames): (JSC::JSObject::putIndexedDescriptor): (JSC::JSObject::defineOwnIndexedProperty): (JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype): (JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength): (JSC::JSObject::getOwnPropertyDescriptor): (JSC::putDescriptor): (JSC::validateAndApplyPropertyDescriptor): * runtime/JSObject.h: (JSC::JSObject::putDirect): * runtime/JSObjectInlines.h: (JSC::JSObject::putDirectWithoutTransition): (JSC::JSObject::putDirectInternal): * runtime/JSPromiseConstructor.cpp: (JSC::JSPromiseConstructor::finishCreation): (JSC::JSPromiseConstructor::addOwnInternalSlots): * runtime/JSPromisePrototype.cpp: (JSC::JSPromisePrototype::finishCreation): (JSC::JSPromisePrototype::addOwnInternalSlots): * runtime/JSString.cpp: (JSC::JSString::getStringPropertyDescriptor): * runtime/JSString.h: (JSC::JSString::getStringPropertySlot): * runtime/JSSymbolTableObject.cpp: (JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames): * runtime/JSSymbolTableObject.h: (JSC::symbolTableGet): * runtime/JSTypedArrayViewConstructor.cpp: (JSC::JSTypedArrayViewConstructor::finishCreation): * runtime/JSTypedArrayViewPrototype.cpp: (JSC::JSTypedArrayViewPrototype::finishCreation): * runtime/LazyClassStructure.cpp: (JSC::LazyClassStructure::Initializer::setConstructor): * runtime/Lookup.cpp: (JSC::reifyStaticAccessor): (JSC::setUpStaticFunctionSlot): * runtime/Lookup.h: (JSC::HashTableValue::intrinsic const): (JSC::HashTableValue::builtinGenerator const): (JSC::HashTableValue::function const): (JSC::HashTableValue::functionLength const): (JSC::HashTableValue::propertyGetter const): (JSC::HashTableValue::propertyPutter const): (JSC::HashTableValue::domJIT const): (JSC::HashTableValue::signature const): (JSC::HashTableValue::accessorGetter const): (JSC::HashTableValue::accessorSetter const): (JSC::HashTableValue::constantInteger const): (JSC::HashTableValue::lazyCellPropertyOffset const): (JSC::HashTableValue::lazyClassStructureOffset const): (JSC::HashTableValue::lazyPropertyCallback const): (JSC::HashTableValue::builtinAccessorGetterGenerator const): (JSC::HashTableValue::builtinAccessorSetterGenerator const): (JSC::getStaticPropertySlotFromTable): (JSC::putEntry): (JSC::reifyStaticProperty): * runtime/MapConstructor.cpp: (JSC::MapConstructor::finishCreation): * runtime/MapIteratorPrototype.cpp: (JSC::MapIteratorPrototype::finishCreation): * runtime/MapPrototype.cpp: (JSC::MapPrototype::finishCreation): * runtime/MathObject.cpp: (JSC::MathObject::finishCreation): * runtime/NativeErrorConstructor.cpp: (JSC::NativeErrorConstructor::finishCreation): * runtime/NativeErrorPrototype.cpp: (JSC::NativeErrorPrototype::finishCreation): * runtime/NumberConstructor.cpp: (JSC::NumberConstructor::finishCreation): * runtime/NumberPrototype.cpp: (JSC::NumberPrototype::finishCreation): * runtime/ObjectConstructor.cpp: (JSC::ObjectConstructor::finishCreation): (JSC::objectConstructorAssign): (JSC::objectConstructorValues): (JSC::objectConstructorDefineProperty): * runtime/ObjectPrototype.cpp: (JSC::ObjectPrototype::finishCreation): (JSC::objectProtoFuncLookupGetter): (JSC::objectProtoFuncLookupSetter): * runtime/ProgramExecutable.cpp: (JSC::ProgramExecutable::initializeGlobalProperties): * runtime/PropertyDescriptor.cpp: (JSC::PropertyDescriptor::writable const): (JSC::PropertyDescriptor::enumerable const): (JSC::PropertyDescriptor::configurable const): (JSC::PropertyDescriptor::setUndefined): (JSC::PropertyDescriptor::setDescriptor): (JSC::PropertyDescriptor::setCustomDescriptor): (JSC::PropertyDescriptor::setAccessorDescriptor): (JSC::PropertyDescriptor::setWritable): (JSC::PropertyDescriptor::setEnumerable): (JSC::PropertyDescriptor::setConfigurable): (JSC::PropertyDescriptor::setSetter): (JSC::PropertyDescriptor::setGetter): (JSC::PropertyDescriptor::attributesEqual const): (JSC::PropertyDescriptor::attributesOverridingCurrent const): * runtime/PropertySlot.cpp: (JSC::PropertySlot::customGetter const): * runtime/PropertySlot.h: (JSC::operator| ): (JSC::operator&): (JSC::operator<): (JSC::operator~): (JSC::operator|=): (JSC::PropertySlot::setUndefined): * runtime/ProxyConstructor.cpp: (JSC::makeRevocableProxy): (JSC::ProxyConstructor::finishCreation): * runtime/ProxyObject.cpp: (JSC::ProxyObject::performHasProperty): * runtime/ProxyRevoke.cpp: (JSC::ProxyRevoke::finishCreation): * runtime/ReflectObject.cpp: (JSC::ReflectObject::finishCreation): (JSC::reflectObjectDefineProperty): * runtime/RegExpConstructor.cpp: (JSC::RegExpConstructor::finishCreation): * runtime/RegExpObject.cpp: (JSC::RegExpObject::getOwnPropertySlot): * runtime/RegExpPrototype.cpp: (JSC::RegExpPrototype::finishCreation): * runtime/ScopedArguments.cpp: (JSC::ScopedArguments::overrideThings): * runtime/SetConstructor.cpp: (JSC::SetConstructor::finishCreation): * runtime/SetIteratorPrototype.cpp: (JSC::SetIteratorPrototype::finishCreation): * runtime/SetPrototype.cpp: (JSC::SetPrototype::finishCreation): * runtime/SparseArrayValueMap.cpp: (JSC::SparseArrayValueMap::putDirect): (JSC::SparseArrayEntry::put): * runtime/StringConstructor.cpp: (JSC::StringConstructor::finishCreation): * runtime/StringIteratorPrototype.cpp: (JSC::StringIteratorPrototype::finishCreation): * runtime/StringPrototype.cpp: (JSC::StringPrototype::finishCreation): * runtime/Structure.cpp: (JSC::Structure::nonPropertyTransition): (JSC::Structure::isSealed): (JSC::Structure::isFrozen): (JSC::Structure::getPropertyNamesFromStructure): (JSC::Structure::prototypeChainMayInterceptStoreTo): * runtime/StructureInlines.h: (JSC::Structure::add): * runtime/SymbolConstructor.cpp: (JSC::SymbolConstructor::finishCreation): * runtime/SymbolPrototype.cpp: (JSC::SymbolPrototype::finishCreation): * runtime/SymbolTable.h: (JSC::SymbolTableEntry::Fast::getAttributes const): (JSC::SymbolTableEntry::SymbolTableEntry): (JSC::SymbolTableEntry::setAttributes): * runtime/TemplateRegistry.cpp: (JSC::TemplateRegistry::getTemplateObject): * runtime/WeakMapConstructor.cpp: (JSC::WeakMapConstructor::finishCreation): * runtime/WeakMapPrototype.cpp: (JSC::WeakMapPrototype::finishCreation): * runtime/WeakSetConstructor.cpp: (JSC::WeakSetConstructor::finishCreation): * runtime/WeakSetPrototype.cpp: (JSC::WeakSetPrototype::finishCreation): * tools/JSDollarVMPrototype.cpp: (JSC::JSDollarVMPrototype::finishCreation): * wasm/js/WebAssemblyCompileErrorConstructor.cpp: (JSC::WebAssemblyCompileErrorConstructor::finishCreation): * wasm/js/WebAssemblyInstanceConstructor.cpp: (JSC::WebAssemblyInstanceConstructor::finishCreation): * wasm/js/WebAssemblyLinkErrorConstructor.cpp: (JSC::WebAssemblyLinkErrorConstructor::finishCreation): * wasm/js/WebAssemblyMemoryConstructor.cpp: (JSC::WebAssemblyMemoryConstructor::finishCreation): * wasm/js/WebAssemblyMemoryPrototype.cpp: * wasm/js/WebAssemblyModuleConstructor.cpp: (JSC::WebAssemblyModuleConstructor::finishCreation): * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp: (JSC::WebAssemblyRuntimeErrorConstructor::finishCreation): * wasm/js/WebAssemblyTableConstructor.cpp: (JSC::WebAssemblyTableConstructor::finishCreation): 2017-09-23 Oleksandr Skachkov [ESNext] Async iteration - Implement Async Generator - optimization https://bugs.webkit.org/show_bug.cgi?id=175891 Reviewed by Yusuke Suzuki. Add small optimization for async generators: 1. merging async generator queue to async generator itself generator.@first / generator.@last is enough, by doing so, we remove one unnecessary object alloc. 2. merging request with queue. * builtins/AsyncGeneratorPrototype.js: (globalPrivate.asyncGeneratorQueueIsEmpty): (globalPrivate.asyncGeneratorQueueCreateItem): (globalPrivate.asyncGeneratorQueueEnqueue): (globalPrivate.asyncGeneratorQueueDequeue): (globalPrivate.asyncGeneratorDequeue): (globalPrivate.isSuspendYieldState): (globalPrivate.asyncGeneratorEnqueue): * builtins/BuiltinNames.h: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitPutAsyncGeneratorFields): * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::FunctionNode::emitBytecode): 2017-09-23 Joseph Pecoraro test262: $.agent became $262.agent in test262 update https://bugs.webkit.org/show_bug.cgi?id=177407 Reviewed by Yusuke Suzuki. * jsc.cpp: (GlobalObject::finishCreation): Alias `$` and `$262` for now. 2017-09-22 Keith Miller Speculatively change iteration protocall to use the same next function https://bugs.webkit.org/show_bug.cgi?id=175653 Reviewed by Saam Barati. This patch speculatively makes a change to the iteration protocall to fetch the next property immediately after calling the Symbol.iterator function. This is, in theory, a breaking change, so we will see if this breaks things (most likely it won't as this is a relatively subtle point). See: https://github.com/tc39/ecma262/issues/976 * builtins/IteratorHelpers.js: (performIteration): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitEnumeration): (JSC::BytecodeGenerator::emitIteratorNext): (JSC::BytecodeGenerator::emitIteratorNextWithValue): (JSC::BytecodeGenerator::emitDelegateYield): * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::ArrayPatternNode::bindValue const): * inspector/JSInjectedScriptHost.cpp: (Inspector::JSInjectedScriptHost::iteratorEntries): * runtime/IteratorOperations.cpp: (JSC::iteratorNext): (JSC::iteratorStep): (JSC::iteratorClose): (JSC::iteratorForIterable): * runtime/IteratorOperations.h: (JSC::forEachInIterable): * runtime/JSGenericTypedArrayViewConstructorInlines.h: (JSC::constructGenericTypedArrayViewFromIterator): (JSC::constructGenericTypedArrayViewWithArguments): 2017-09-22 Fujii Hironori [Win64] Crashes in Yarr JIT compiled code https://bugs.webkit.org/show_bug.cgi?id=177293 Reviewed by Yusuke Suzuki. In x64 Windows, rcx register is used for the address of allocated space for the return value. But, rcx is used for regT1 since r221052. Save rcx in the stack. * yarr/YarrJIT.cpp: (JSC::Yarr::YarrGenerator::generateEnter): Push ecx. (JSC::Yarr::YarrGenerator::generateReturn): Pop ecx. 2017-09-22 Saam Barati Usage of ErrorInstance::m_stackTrace on the mutator is racy with the collector https://bugs.webkit.org/show_bug.cgi?id=177368 Reviewed by Keith Miller. * runtime/ErrorInstance.cpp: (JSC::ErrorInstance::finishCreation): (JSC::ErrorInstance::materializeErrorInfoIfNeeded): (JSC::ErrorInstance::visitChildren): 2017-09-22 Yusuke Suzuki [DFG][FTL] Profile array vector length for array allocation https://bugs.webkit.org/show_bug.cgi?id=177051 Reviewed by Saam Barati. Currently, NewArrayBuffer allocation is penalized by JSC: While empty array gets 25 vector size (BASE_CONTIGUOUS_VECTOR_LEN), new_array_buffer case gets 3 vector size (BASE_CONTIGUOUS_VECTOR_LEN). Surely, new_array_buffer can get larger vector size if the number of its constant elements is larger than 3. But these created array may be grown by `push()` operation after the allocation. In this case, new_array_buffer is penalized compared to empty array allocation. empty array allocation, var array = []; array.push(0); array.push(1); array.push(2); array.push(3); array.push(4); v.s. new_array_buffer case, var array = [0]; array.push(1); array.push(2); array.push(3); array.push(4); In this case, the latter becomes slow. While we have a chance to reduce memory usage if new_array_buffer is not grown (and a bit likely), we should allocate 3 to 25 vector size if it is likely grown. So we should get profile on the resulted array. We select 25 to make it fit to one of size classes. In this patch, we extend ArrayAllocationProfile to record vector length. And use this information when allocating array for new_array_buffer. If the number of new_array_buffer constants is <= 25, array vector size would become 3 to 25 based on profiling. If the number of its constants is larger than 25, we just use it for allocation as before. Added microbenchmark and SixSpeed spread-literal.es5 shows improvement. new-array-buffer-vector-profile 67.4706+-3.7625 ^ 28.4249+-1.9025 ^ definitely 2.3736x faster spread-literal.es5 133.1443+-9.2253 ^ 95.2667+-0.5740 ^ definitely 1.3976x faster * bytecode/ArrayAllocationProfile.cpp: (JSC::ArrayAllocationProfile::updateProfile): (JSC::ArrayAllocationProfile::updateIndexingType): Deleted. * bytecode/ArrayAllocationProfile.h: (JSC::ArrayAllocationProfile::selectIndexingType): (JSC::ArrayAllocationProfile::vectorLengthHint): (JSC::ArrayAllocationProfile::ArrayAllocationProfile): Deleted. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::updateAllArrayPredictions): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGNode.h: (JSC::DFG::Node::vectorLengthHint): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileArraySlice): (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayBuffer): (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize): (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray): (JSC::FTL::DFG::LowerDFGToB3::allocateUninitializedContiguousJSArrayInternal): (JSC::FTL::DFG::LowerDFGToB3::allocateUninitializedContiguousJSArray): * runtime/ArrayConventions.h: * runtime/JSArray.h: (JSC::JSArray::tryCreate): 2017-09-22 Commit Queue Unreviewed, rolling out r222380. https://bugs.webkit.org/show_bug.cgi?id=177352 Octane/box2d shows 8% regression (Requested by yusukesuzuki on #webkit). Reverted changeset: "[DFG][FTL] Profile array vector length for array allocation" https://bugs.webkit.org/show_bug.cgi?id=177051 http://trac.webkit.org/changeset/222380 2017-09-21 Yusuke Suzuki [DFG][FTL] Profile array vector length for array allocation https://bugs.webkit.org/show_bug.cgi?id=177051 Reviewed by Saam Barati. Currently, NewArrayBuffer allocation is penalized by JSC: While empty array gets 25 vector size (BASE_CONTIGUOUS_VECTOR_LEN), new_array_buffer case gets 3 vector size (BASE_CONTIGUOUS_VECTOR_LEN). Surely, new_array_buffer can get larger vector size if the number of its constant elements is larger than 3. But these created array may be grown by `push()` operation after the allocation. In this case, new_array_buffer is penalized compared to empty array allocation. empty array allocation, var array = []; array.push(0); array.push(1); array.push(2); array.push(3); array.push(4); v.s. new_array_buffer case, var array = [0]; array.push(1); array.push(2); array.push(3); array.push(4); In this case, the latter becomes slow. While we have a chance to reduce memory usage if new_array_buffer is not grown (and a bit likely), we should allocate 3 to 25 vector size if it is likely grown. So we should get profile on the resulted array. We select 25 to make it fit to one of size classes. In this patch, we extend ArrayAllocationProfile to record vector length. And use this information when allocating array for new_array_buffer. If the number of new_array_buffer constants is <= 25, array vector size would become 3 to 25 based on profiling. If the number of its constants is larger than 25, we just use it for allocation as before. Added microbenchmark and SixSpeed spread-literal.es5 shows improvement. new-array-buffer-vector-profile 67.4706+-3.7625 ^ 28.4249+-1.9025 ^ definitely 2.3736x faster spread-literal.es5 133.1443+-9.2253 ^ 95.2667+-0.5740 ^ definitely 1.3976x faster * bytecode/ArrayAllocationProfile.cpp: (JSC::ArrayAllocationProfile::updateProfile): (JSC::ArrayAllocationProfile::updateIndexingType): Deleted. * bytecode/ArrayAllocationProfile.h: (JSC::ArrayAllocationProfile::selectIndexingType): (JSC::ArrayAllocationProfile::vectorLengthHint): (JSC::ArrayAllocationProfile::ArrayAllocationProfile): Deleted. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::updateAllArrayPredictions): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGNode.h: (JSC::DFG::Node::vectorLengthHint): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileArraySlice): (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayBuffer): (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize): (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray): (JSC::FTL::DFG::LowerDFGToB3::allocateUninitializedContiguousJSArrayInternal): (JSC::FTL::DFG::LowerDFGToB3::allocateUninitializedContiguousJSArray): * runtime/ArrayConventions.h: * runtime/JSArray.h: (JSC::JSArray::tryCreate): 2017-09-21 Joseph Pecoraro Web Inspector: Remove support for CSS Regions https://bugs.webkit.org/show_bug.cgi?id=177287 Reviewed by Matt Baker. * inspector/protocol/CSS.json: * inspector/protocol/OverlayTypes.json: 2017-09-21 Brian Burg Web Inspector: keyboard shortcut for "Reload page from origin" doesn't match Safari, and doesn't work https://bugs.webkit.org/show_bug.cgi?id=177010 Reviewed by Joseph Pecoraro. Use "reload from origin" nomenclature instead of "reload ignoring cache". * inspector/protocol/Page.json: Improve the comment, but don't change the parameter name since this would be a divergence from legacy protocols. 2017-09-21 Joseph Pecoraro test262: test262/test/annexB/built-ins/RegExp/prototype/flags/order-after-compile.js ASSERTs https://bugs.webkit.org/show_bug.cgi?id=177307 Reviewed by Michael Saboff. * runtime/RegExpPrototype.cpp: In r221160 we added support for the new RegExp flag (dotAll). We needed to make space for it in FlagsString. 2017-09-20 Keith Miller JSC should use unified sources for platform specific files. https://bugs.webkit.org/show_bug.cgi?id=177290 Reviewed by Michael Saboff. Add a list of platform specific source files and update the Generate Unified Sources phase of the Xcode build. I skipped WPE since that seems to have failed for some reason that I didn't fully understand. See: https://webkit-queues.webkit.org/results/4611260 Also, fix duplicate symbols in Glib remote inspector files. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * PlatformGTK.cmake: * PlatformMac.cmake: * SourcesGTK.txt: Added. * SourcesMac.txt: Added. * inspector/remote/glib/RemoteInspectorServer.cpp: (Inspector::RemoteInspectorServer::interfaceInfo): (Inspector::RemoteInspectorServer::setTargetList): (Inspector::RemoteInspectorServer::setupInspectorClient): (Inspector::RemoteInspectorServer::setup): (Inspector::RemoteInspectorServer::close): (Inspector::RemoteInspectorServer::connectionClosed): (Inspector::RemoteInspectorServer::sendMessageToBackend): (Inspector::RemoteInspectorServer::sendMessageToFrontend): (Inspector::dbusConnectionCallAsyncReadyCallback): Deleted. 2017-09-20 Stephan Szabo [Win] WTF: Add alias for process id to use in place of direct uses of pid_t https://bugs.webkit.org/show_bug.cgi?id=177017 Reviewed by Alex Christensen. * API/JSRemoteInspector.cpp: (JSRemoteInspectorSetParentProcessInformation): * API/JSRemoteInspector.h: * inspector/remote/RemoteInspector.h: 2017-09-20 Keith Miller Rename source list file to Sources.txt https://bugs.webkit.org/show_bug.cgi?id=177283 Reviewed by Saam Barati. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: Renamed from Source/JavaScriptCore/sources.txt. 2017-09-20 Keith Miller Unreviewed, fix string capitalization * JavaScriptCore.xcodeproj/project.pbxproj: 2017-09-20 Keith Miller JSC Xcode build should use unified sources for platform independent files https://bugs.webkit.org/show_bug.cgi?id=177190 Reviewed by Saam Barati. This patch changes the Xcode build to use unified sources. The main difference from a development perspective is that instead of added source files to Xcode they need to be added to the shared sources.txt. For now, platform specific files are still added to the JavaScriptCore target. Because Xcode needs to know about all the files before we generate them all the unified source files need to be added to the JavaScriptCore framework target. As a result, if we run out of bundle files more will need to be added to the project. Currently, there are no spare files. If adding more bundle files becomes problematic we can change this. LowLevelInterpreter.cpp can't be added to the unified source list yet due to a clang bug. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * sources.txt: Added. 2017-09-20 Per Arne Vollan [Win] Cannot find script to generate unified sources. https://bugs.webkit.org/show_bug.cgi?id=177014 Reviewed by Keith Miller. The ruby script can now be found in WTF/Scripts in the forwarding headers folder. * CMakeLists.txt: * JavaScriptCore.vcxproj/JavaScriptCore.proj: 2017-09-20 Alberto Garcia Fix HPPA and Alpha builds https://bugs.webkit.org/show_bug.cgi?id=177224 Reviewed by Alex Christensen. * CMakeLists.txt: 2017-09-18 Filip Pizlo ErrorInstance and Exception need destroy methods https://bugs.webkit.org/show_bug.cgi?id=177095 Reviewed by Saam Barati. When I made ErrorInstance and Exception into JSDestructibleObjects, I forgot to make them follow that type's protocol. * runtime/ErrorInstance.cpp: (JSC::ErrorInstance::destroy): Implement this to fix leaks. * runtime/ErrorInstance.h: * runtime/Exception.h: Change how this is declared now that this is a DestructibleObject. 2017-09-18 Yusuke Suzuki [JSC] Consider dropping JSObjectSetPrototype feature for JSGlobalObject https://bugs.webkit.org/show_bug.cgi?id=177070 Reviewed by Saam Barati. Due to the security reason, our global object is immutable prototype exotic object. It prevents users from injecting proxies into the prototype chain of the global object[1]. But our JSC API does not respect this attribute, and allows users to change [[Prototype]] of the global object after instantiating it. This patch removes this feature. Once global object is instantiated, we cannot change [[Prototype]] of the global object. It drops JSGlobalObject::resetPrototype use, which involves GlobalThis edge cases. [1]: https://github.com/tc39/ecma262/commit/935dad4283d045bc09c67a259279772d01b3d33d * API/JSObjectRef.cpp: (JSObjectSetPrototype): * API/tests/CustomGlobalObjectClassTest.c: (globalObjectSetPrototypeTest): 2017-09-17 Yusuke Suzuki [DFG] Remove ToThis more aggressively https://bugs.webkit.org/show_bug.cgi?id=177056 Reviewed by Saam Barati. The variation of toThis() implementation is limited. So, we attempts to implement common toThis operation in AI. We move scope related toThis to JSScope::toThis. And AI investigates proven value/structure's toThis methods and attempts to fold/convert to efficient nodes. We introduces GetGlobalThis, which just loads globalThis from semantic origin's globalObject. Using this, we can implement JSScope::toThis in DFG. This can avoid costly toThis indirect function pointer call. Currently, we just emit GetGlobalThis if necessary. We can further convert it to constant if we can put watchpoint to JSGlobalObject's globalThis change. But we leave it for a future patch for now. This removes GetGlobalThis from ES6 generators in common cases. spread-generator.es6 303.1550+-9.5037 290.9337+-8.3487 might be 1.0420x faster * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::isToThisAnIdentity): (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNode.h: (JSC::DFG::Node::convertToGetGlobalThis): * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetGlobalThis): * 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::compileGetGlobalThis): * runtime/JSGlobalLexicalEnvironment.cpp: (JSC::JSGlobalLexicalEnvironment::toThis): Deleted. * runtime/JSGlobalLexicalEnvironment.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::toThis): Deleted. * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::addressOfGlobalThis): * runtime/JSLexicalEnvironment.cpp: (JSC::JSLexicalEnvironment::toThis): Deleted. * runtime/JSLexicalEnvironment.h: * runtime/JSScope.cpp: (JSC::JSScope::toThis): * runtime/JSScope.h: * runtime/StrictEvalActivation.cpp: (JSC::StrictEvalActivation::toThis): Deleted. * runtime/StrictEvalActivation.h: 2017-09-17 Yusuke Suzuki Merge JSLexicalEnvironment and JSEnvironmentRecord https://bugs.webkit.org/show_bug.cgi?id=175492 Reviewed by Saam Barati. JSEnvironmentRecord is only inherited by JSLexicalEnvironment. We can merge JSEnvironmentRecord and JSLexicalEnvironment. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLAbstractHeapRepository.h: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal): (JSC::FTL::DFG::LowerDFGToB3::compileCreateActivation): (JSC::FTL::DFG::LowerDFGToB3::compileGetClosureVar): (JSC::FTL::DFG::LowerDFGToB3::compilePutClosureVar): (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation): * jit/JITPropertyAccess.cpp: (JSC::JIT::emitGetClosureVar): (JSC::JIT::emitPutClosureVar): (JSC::JIT::emitScopedArgumentsGetByVal): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emitGetClosureVar): (JSC::JIT::emitPutClosureVar): * llint/LLIntOffsetsExtractor.cpp: * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/JSEnvironmentRecord.cpp: Removed. * runtime/JSEnvironmentRecord.h: Removed. * runtime/JSLexicalEnvironment.cpp: (JSC::JSLexicalEnvironment::visitChildren): (JSC::JSLexicalEnvironment::heapSnapshot): (JSC::JSLexicalEnvironment::getOwnNonIndexPropertyNames): * runtime/JSLexicalEnvironment.h: (JSC::JSLexicalEnvironment::subspaceFor): (JSC::JSLexicalEnvironment::variables): (JSC::JSLexicalEnvironment::isValidScopeOffset): (JSC::JSLexicalEnvironment::variableAt): (JSC::JSLexicalEnvironment::offsetOfVariables): (JSC::JSLexicalEnvironment::offsetOfVariable): (JSC::JSLexicalEnvironment::allocationSizeForScopeSize): (JSC::JSLexicalEnvironment::allocationSize): (JSC::JSLexicalEnvironment::finishCreationUninitialized): (JSC::JSLexicalEnvironment::finishCreation): * runtime/JSModuleEnvironment.cpp: (JSC::JSModuleEnvironment::create): * runtime/JSObject.h: (JSC::JSObject::isEnvironment const): (JSC::JSObject::isEnvironmentRecord const): Deleted. * runtime/JSSegmentedVariableObject.h: * runtime/StringPrototype.cpp: (JSC::checkObjectCoercible): 2017-09-15 Saam Barati Arity fixup during inlining should do a 2 phase commit so it properly recovers the frame in case of exit https://bugs.webkit.org/show_bug.cgi?id=176981 Reviewed by Yusuke Suzuki. This patch makes inline arity fixup happen in two phases: 1. We get all the values we need and MovHint them to the expected locals. 2. We SetLocal them inside the callee's CodeOrigin. This way, if we exit, the callee's frame is already set up. If any SetLocal exits, we have a valid exit state. This is required because if we didn't do this in two phases, we may exit in the middle of arity fixup from the caller's CodeOrigin. This is unsound because if we did the SetLocals in the caller's frame, the memcpy may clobber needed parts of the frame right before exiting. For example, consider if we need to pad two args: [arg3][arg2][arg1][arg0] [fix ][fix ][arg3][arg2][arg1][arg0] We memcpy starting from arg0 in the direction of arg3. If we were to exit at a type check for arg3's SetLocal in the caller's CodeOrigin, we'd exit with a frame like so: [arg3][arg2][arg1][arg2][arg1][arg0] And the caller would then just end up thinking its argument are: [arg3][arg2][arg1][arg2] which is incorrect. This patch also fixes a couple of bugs in IdentitiyWithProfile: 1. The bytecode generator for this bytecode intrinsic was written incorrectly. It needed to store the result of evaluating its argument in a temporary that it creates. Otherwise, it might try to simply overwrite a constant or a register that it didn't own. 2. We weren't eliminating this node in CSE inside the DFG. * bytecompiler/NodesCodegen.cpp: (JSC::BytecodeIntrinsicNode::emit_intrinsic_idWithProfile): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::inlineCall): * dfg/DFGCSEPhase.cpp: 2017-09-15 JF Bastien WTF: use Forward.h when appropriate instead of Vector.h https://bugs.webkit.org/show_bug.cgi?id=176984 Reviewed by Saam Barati. There's no need to include Vector.h when Forward.h will suffice. All we need is to move the template default parameters from Vector, and then the forward declaration can be used in so many new places: if a header only takes Vector by reference, rvalue reference, pointer, returns any of these, or has them as members then the header doesn't need to see the definition because the declaration will suffice. * bytecode/HandlerInfo.h: * heap/GCIncomingRefCounted.h: * heap/GCSegmentedArray.h: * wasm/js/JSWebAssemblyModule.h: 2017-09-14 Saam Barati We should have a way of preventing a caller from making a tail call and we should use it for ProxyObject instead of using build flags https://bugs.webkit.org/show_bug.cgi?id=176863 Reviewed by Keith Miller. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * runtime/ProxyObject.cpp: (JSC::performProxyGet): (JSC::ProxyObject::performInternalMethodGetOwnProperty): (JSC::ProxyObject::performHasProperty): (JSC::ProxyObject::getOwnPropertySlotCommon): (JSC::ProxyObject::performPut): (JSC::performProxyCall): (JSC::performProxyConstruct): (JSC::ProxyObject::performDelete): (JSC::ProxyObject::performPreventExtensions): (JSC::ProxyObject::performIsExtensible): (JSC::ProxyObject::performDefineOwnProperty): (JSC::ProxyObject::performGetOwnPropertyNames): (JSC::ProxyObject::performSetPrototype): (JSC::ProxyObject::performGetPrototype): 2017-09-14 Saam Barati Make dumping the graph print when both when exitOK and !exitOK https://bugs.webkit.org/show_bug.cgi?id=176954 Reviewed by Keith Miller. * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): 2017-09-14 Saam Barati It should be valid to exit before each set when doing arity fixup when inlining https://bugs.webkit.org/show_bug.cgi?id=176948 Reviewed by Keith Miller. This patch makes it so that we can exit before each SetLocal when doing arity fixup during inlining. This is OK because if we exit at any of these SetLocals, we will simply exit to the beginning of the call instruction. Not doing this led to a bug where FixupPhase would insert a ValueRep of a node before the actual node. This is obviously invalid IR. I've added a new validation rule to catch this malformed IR. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::inliningCost): (JSC::DFG::ByteCodeParser::inlineCall): * dfg/DFGValidate.cpp: * runtime/Options.h: 2017-09-14 Mark Lam AddressSanitizer: stack-buffer-underflow in JSC::Probe::Page::Page https://bugs.webkit.org/show_bug.cgi?id=176874 Reviewed by Saam Barati. 1. Make Probe::Stack play nice with ASan by: a. using a local memcpy implementation that suppresses ASan on ASan builds. We don't want to use std:memcpy() which validates stack memory because we are intentionally copying stack memory beyond the current frame. b. changing Stack::s_chunkSize to equal sizeof(uintptr_t) on ASan builds. This ensures that Page::flushWrites() only writes stack memory that was modified by a probe. The probes should only modify stack memory that belongs to JSC stack data structures. We don't want to inadvertently modify adjacent words that may belong to ASan (which may happen if s_chunkSize is larger than sizeof(uintptr_t)). c. fixing a bug in Page dirtyBits management for when the size of the value to write is greater than s_chunkSize. The fix in generic, but in practice, this currently only manifests on 32-bit ASan builds because sizeof(uintptr_t) and s_chunkSize are 32-bit, and we may write 64-bit values. d. making Page::m_dirtyBits 64 bits always. This maximizes the number of s_chunksPerPage we can have even on ASan builds. 2. Fixed the bottom most Probe::Context and Probe::Stack get/set methods to use std::memcpy to avoid strict aliasing issues. 3. Optimized the implementation of Page::physicalAddressFor(). 4. Optimized the implementation of Stack::set() in the recording of the low watermark. We just record the lowest raw pointer now, and only compute the alignment to its chuck boundary later when the low watermark is requested. 5. Changed a value in testmasm to make the test less vulnerable to rounding issues. No new test needed because this is already covered by testmasm with ASan enabled. * assembler/ProbeContext.h: (JSC::Probe::CPUState::gpr const): (JSC::Probe::CPUState::spr const): (JSC::Probe::Context::gpr): (JSC::Probe::Context::spr): (JSC::Probe::Context::fpr): (JSC::Probe::Context::gprName): (JSC::Probe::Context::sprName): (JSC::Probe::Context::fprName): (JSC::Probe::Context::gpr const): (JSC::Probe::Context::spr const): (JSC::Probe::Context::fpr const): (JSC::Probe::Context::pc): (JSC::Probe::Context::fp): (JSC::Probe::Context::sp): (JSC::Probe:: const): Deleted. * assembler/ProbeStack.cpp: (JSC::Probe::copyStackPage): (JSC::Probe::Page::Page): (JSC::Probe::Page::flushWrites): * assembler/ProbeStack.h: (JSC::Probe::Page::get): (JSC::Probe::Page::set): (JSC::Probe::Page::dirtyBitFor): (JSC::Probe::Page::physicalAddressFor): (JSC::Probe::Stack::lowWatermark): (JSC::Probe::Stack::get): (JSC::Probe::Stack::set): * assembler/testmasm.cpp: (JSC::testProbeModifiesStackValues): 2017-09-14 Yusuke Suzuki [JSC] Disable Arity Fixup Inlining until crash in facebook.com is fixed https://bugs.webkit.org/show_bug.cgi?id=176917 Reviewed by Saam Barati. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::inliningCost): * runtime/Options.h: 2017-09-14 Yusuke Suzuki [JSC] Add PrivateSymbolMode::{Include,Exclude} for PropertyNameArray https://bugs.webkit.org/show_bug.cgi?id=176867 Reviewed by Sam Weinig. We rarely require private symbols when enumerating property names. This patch adds PrivateSymbolMode::{Include,Exclude}. If PrivateSymbolMode::Exclude is specified, PropertyNameArray does not include private symbols. This removes many ad-hoc `Identifier::isPrivateName()` in enumeration operations. One additional good thing is that we do not need to filter private symbols out from PropertyNameArray. It allows us to use Object.keys()'s fast path for Object.getOwnPropertySymbols. object-get-own-property-symbols 48.6275+-1.0021 ^ 38.1846+-1.7934 ^ definitely 1.2735x faster * API/JSObjectRef.cpp: (JSObjectCopyPropertyNames): * bindings/ScriptValue.cpp: (Inspector::jsToInspectorValue): * bytecode/ObjectAllocationProfile.h: (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount): * runtime/EnumerationMode.h: * runtime/IntlObject.cpp: (JSC::supportedLocales): * runtime/JSONObject.cpp: (JSC::Stringifier::Stringifier): (JSC::Stringifier::Holder::appendNextProperty): (JSC::Walker::walk): * runtime/JSPropertyNameEnumerator.cpp: (JSC::JSPropertyNameEnumerator::create): * runtime/JSPropertyNameEnumerator.h: (JSC::propertyNameEnumerator): * runtime/ObjectConstructor.cpp: (JSC::objectConstructorGetOwnPropertyDescriptors): (JSC::objectConstructorAssign): (JSC::objectConstructorValues): (JSC::defineProperties): (JSC::setIntegrityLevel): (JSC::testIntegrityLevel): (JSC::ownPropertyKeys): * runtime/PropertyNameArray.h: (JSC::PropertyNameArray::PropertyNameArray): (JSC::PropertyNameArray::propertyNameMode const): (JSC::PropertyNameArray::privateSymbolMode const): (JSC::PropertyNameArray::addUncheckedInternal): (JSC::PropertyNameArray::addUnchecked): (JSC::PropertyNameArray::add): (JSC::PropertyNameArray::isUidMatchedToTypeMode): (JSC::PropertyNameArray::includeSymbolProperties const): (JSC::PropertyNameArray::includeStringProperties const): (JSC::PropertyNameArray::mode const): Deleted. * runtime/ProxyObject.cpp: (JSC::ProxyObject::performGetOwnPropertyNames): 2017-09-13 Mark Lam Rolling out r221832: Regresses Speedometer by ~4% and Dromaeo CSS YUI by ~20%. https://bugs.webkit.org/show_bug.cgi?id=176888 Not reviewed. * JavaScriptCore.xcodeproj/project.pbxproj: * assembler/MacroAssembler.cpp: (JSC::stdFunctionCallback): * assembler/MacroAssemblerPrinter.cpp: (JSC::Printer::printCallback): * assembler/ProbeContext.h: (JSC::Probe:: const): (JSC::Probe::Context::Context): (JSC::Probe::Context::gpr): (JSC::Probe::Context::spr): (JSC::Probe::Context::fpr): (JSC::Probe::Context::gprName): (JSC::Probe::Context::sprName): (JSC::Probe::Context::fprName): (JSC::Probe::Context::pc): (JSC::Probe::Context::fp): (JSC::Probe::Context::sp): (JSC::Probe::CPUState::gpr const): Deleted. (JSC::Probe::CPUState::spr const): Deleted. (JSC::Probe::Context::arg): Deleted. (JSC::Probe::Context::gpr const): Deleted. (JSC::Probe::Context::spr const): Deleted. (JSC::Probe::Context::fpr const): Deleted. * assembler/ProbeFrame.h: Removed. * assembler/ProbeStack.cpp: (JSC::Probe::Page::Page): * assembler/ProbeStack.h: (JSC::Probe::Page::get): (JSC::Probe::Page::set): (JSC::Probe::Page::physicalAddressFor): (JSC::Probe::Stack::lowWatermark): (JSC::Probe::Stack::get): (JSC::Probe::Stack::set): * bytecode/ArithProfile.cpp: * bytecode/ArithProfile.h: * bytecode/ArrayProfile.h: (JSC::ArrayProfile::observeArrayMode): Deleted. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::updateOSRExitCounterAndCheckIfNeedToReoptimize): Deleted. * bytecode/CodeBlock.h: (JSC::CodeBlock::addressOfOSRExitCounter): * bytecode/ExecutionCounter.h: (JSC::ExecutionCounter::hasCrossedThreshold const): Deleted. (JSC::ExecutionCounter::setNewThresholdForOSRExit): Deleted. * bytecode/MethodOfGettingAValueProfile.cpp: (JSC::MethodOfGettingAValueProfile::reportValue): Deleted. * bytecode/MethodOfGettingAValueProfile.h: * dfg/DFGDriver.cpp: (JSC::DFG::compileImpl): * dfg/DFGJITCode.cpp: (JSC::DFG::JITCode::findPC): * dfg/DFGJITCode.h: * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::linkOSRExits): (JSC::DFG::JITCompiler::link): * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::setPatchableCodeOffset): (JSC::DFG::OSRExit::getPatchableCodeOffsetAsJump const): (JSC::DFG::OSRExit::codeLocationForRepatch const): (JSC::DFG::OSRExit::correctJump): (JSC::DFG::OSRExit::emitRestoreArguments): (JSC::DFG::OSRExit::compileOSRExit): (JSC::DFG::OSRExit::compileExit): (JSC::DFG::OSRExit::debugOperationPrintSpeculationFailure): (JSC::DFG::jsValueFor): Deleted. (JSC::DFG::restoreCalleeSavesFor): Deleted. (JSC::DFG::saveCalleeSavesFor): Deleted. (JSC::DFG::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer): Deleted. (JSC::DFG::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer): Deleted. (JSC::DFG::saveOrCopyCalleeSavesFor): Deleted. (JSC::DFG::createDirectArgumentsDuringExit): Deleted. (JSC::DFG::createClonedArgumentsDuringExit): Deleted. (JSC::DFG::emitRestoreArguments): Deleted. (JSC::DFG::OSRExit::executeOSRExit): Deleted. (JSC::DFG::reifyInlinedCallFrames): Deleted. (JSC::DFG::adjustAndJumpToTarget): Deleted. (JSC::DFG::printOSRExit): Deleted. * dfg/DFGOSRExit.h: (JSC::DFG::OSRExitState::OSRExitState): Deleted. * dfg/DFGOSRExitCompilerCommon.cpp: * dfg/DFGOSRExitCompilerCommon.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGThunks.cpp: (JSC::DFG::osrExitGenerationThunkGenerator): (JSC::DFG::osrExitThunkGenerator): Deleted. * dfg/DFGThunks.h: * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::debugCall): * jit/AssemblyHelpers.h: * jit/JITOperations.cpp: * jit/JITOperations.h: * profiler/ProfilerOSRExit.h: (JSC::Profiler::OSRExit::incCount): Deleted. * runtime/JSCJSValue.h: * runtime/JSCJSValueInlines.h: * runtime/VM.h: 2017-09-13 Yusuke Suzuki [JSC] Move class/struct used in other class' member out of anonymous namespace https://bugs.webkit.org/show_bug.cgi?id=176876 Reviewed by Saam Barati. GCC warns if a class has a base or field whose type uses the anonymous namespace and it is defined in an included file. This is because this possibly violates one definition rule (ODR): if an included file has the anonymous namespace, each translation unit creates its private anonymous namespace. Thus, each type inside the anonymous namespace becomes different in each translation unit if the file is included in multiple translation units. While the current use in JSC is not violating ODR since these cpp files are included only once for unified sources, specifying `-Wno-subobject-linkage` could miss the actual bugs. So, in this patch, we just move related classes/structs out of the anonymous namespace. * dfg/DFGIntegerCheckCombiningPhase.cpp: (JSC::DFG::IntegerCheckCombiningPhase::RangeKey::addition): (JSC::DFG::IntegerCheckCombiningPhase::RangeKey::arrayBounds): (JSC::DFG::IntegerCheckCombiningPhase::RangeKey::operator! const): (JSC::DFG::IntegerCheckCombiningPhase::RangeKey::hash const): (JSC::DFG::IntegerCheckCombiningPhase::RangeKey::operator== const): (JSC::DFG::IntegerCheckCombiningPhase::RangeKey::dump const): (JSC::DFG::IntegerCheckCombiningPhase::RangeKeyAndAddend::RangeKeyAndAddend): (JSC::DFG::IntegerCheckCombiningPhase::RangeKeyAndAddend::operator! const): (JSC::DFG::IntegerCheckCombiningPhase::RangeKeyAndAddend::dump const): (JSC::DFG::IntegerCheckCombiningPhase::Range::dump const): * dfg/DFGLICMPhase.cpp: 2017-09-13 Devin Rousso Web Inspector: Event Listeners section does not update when listeners are added/removed https://bugs.webkit.org/show_bug.cgi?id=170570 Reviewed by Joseph Pecoraro. * inspector/protocol/DOM.json: Add two new events: "didAddEventListener" and "willRemoveEventListener". These events do not contain any information about the event listeners that were added/removed. They serve more as indications that something has changed, and to refetch the data again via `getEventListenersForNode`. 2017-09-13 Yusuke Suzuki [JSC] Fix Array allocation in Object.keys https://bugs.webkit.org/show_bug.cgi?id=176826 Reviewed by Saam Barati. When isHavingABadTime() is true, array allocation does not become ArrayWithContiguous. We check isHavingABadTime() in ownPropertyKeys fast path. And we also ensures that ownPropertyKeys uses putDirect operation instead of put by a test. * runtime/ObjectConstructor.cpp: (JSC::ownPropertyKeys): 2017-09-12 Yusuke Suzuki [DFG] Optimize WeakMap::get by adding intrinsic and fixup https://bugs.webkit.org/show_bug.cgi?id=176010 Reviewed by Filip Pizlo. It reveals that Ember.js consumes 3.8% of execution time for WeakMap#get. It is used for meta property for objects (see peekMeta function in Ember.js). This patch optimizes WeakMap#get. 1. We use inlineGet to inline WeakMap#get operation in the native function. Since this native function itself is very small, we should inline HashMap#get entirely in this function. 2. We add JSWeakMapType and JSWeakSetType. This allows us to perform `isJSWeakMap()` very fast. And this patch wires this to DFG and FTL to add WeakMapObjectUse and WeakSetObjectUse to drop unnecessary type checking. We add fixup rules for WeakMapGet DFG node by using WeakMapObjectUse, ObjectUse, and Int32Use. 3. We add intrinsic for WeakMap#get, and handle it in DFG and FTL. We use MapHash to calculate hash value for the key's Object and use this hash value to look up value from JSWeakMap's HashMap. Currently, we just call the operationWeakMapGet function in DFG and FTL. It is worth considering that implementing this operation entirely in JIT, like GetMapBucket. But anyway, the current one already optimizes the performance, so we leave this for the subsequent patches. We currently do not implement any other intrinsics (like, WeakMap#has, WeakSet) because they are not used in Ember.js right now. This patch optimizes WeakMap#get by 50%. baseline patched weak-map-key 88.6456+-3.9564 ^ 59.1502+-2.2406 ^ definitely 1.4987x faster * bytecode/DirectEvalCodeCache.h: (JSC::DirectEvalCodeCache::tryGet): * bytecode/SpeculatedType.cpp: (JSC::dumpSpeculation): (JSC::speculationFromClassInfo): (JSC::speculationFromJSType): (JSC::speculationFromString): * bytecode/SpeculatedType.h: * 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/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::speculateWeakMapObject): (JSC::DFG::SpeculativeJIT::speculateWeakSetObject): (JSC::DFG::SpeculativeJIT::speculate): (JSC::DFG::SpeculativeJIT::compileWeakMapGet): * 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/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileWeakMapGet): (JSC::FTL::DFG::LowerDFGToB3::lowWeakMapObject): (JSC::FTL::DFG::LowerDFGToB3::lowWeakSetObject): (JSC::FTL::DFG::LowerDFGToB3::speculate): (JSC::FTL::DFG::LowerDFGToB3::speculateWeakMapObject): (JSC::FTL::DFG::LowerDFGToB3::speculateWeakSetObject): * jit/JITOperations.h: * runtime/HashMapImpl.h: (JSC::WeakMapHash::hash): (JSC::WeakMapHash::equal): * runtime/Intrinsic.cpp: (JSC::intrinsicName): * runtime/Intrinsic.h: * runtime/JSType.h: * runtime/JSWeakMap.h: (JSC::isJSWeakMap): * runtime/JSWeakSet.h: (JSC::isJSWeakSet): * runtime/WeakMapBase.cpp: (JSC::WeakMapBase::get): * runtime/WeakMapBase.h: (JSC::WeakMapBase::HashTranslator::hash): (JSC::WeakMapBase::HashTranslator::equal): (JSC::WeakMapBase::inlineGet): * runtime/WeakMapPrototype.cpp: (JSC::WeakMapPrototype::finishCreation): (JSC::getWeakMap): (JSC::protoFuncWeakMapGet): * runtime/WeakSetPrototype.cpp: (JSC::getWeakSet): 2017-09-12 Keith Miller Rename JavaScriptCore CMake unifiable sources list https://bugs.webkit.org/show_bug.cgi?id=176823 Reviewed by Joseph Pecoraro. This patch also changes the error message when the unified source bundler fails to be more accurate. * CMakeLists.txt: 2017-09-12 Keith Miller Do unified source builds for JSC https://bugs.webkit.org/show_bug.cgi?id=176076 Reviewed by Geoffrey Garen. This patch switches the CMake JavaScriptCore build to use unified sources. The Xcode build will be upgraded in a follow up patch. Most of the source changes in this patch are fixing static variable/functions name collisions. The most common collisions were from our use of "static const bool verbose" and "using namespace ...". I fixed all the verbose cases and fixed the "using namespace" issues that occurred under the current bundling strategy. It's likely that more of the "using namespace" issues will need to be resolved in the future, particularly in the FTL. I don't expect either of these problems will apply to other parts of the project nearly as much as in JSC. Using a verbose variable is a JSC idiom and JSC tends use the same, canonical, class name in multiple parts of the engine. * CMakeLists.txt: * b3/B3CheckSpecial.cpp: (JSC::B3::CheckSpecial::forEachArg): (JSC::B3::CheckSpecial::generate): (JSC::B3::Air::numB3Args): Deleted. * b3/B3DuplicateTails.cpp: * b3/B3EliminateCommonSubexpressions.cpp: * b3/B3FixSSA.cpp: (JSC::B3::demoteValues): * b3/B3FoldPathConstants.cpp: * b3/B3InferSwitches.cpp: * b3/B3LowerMacrosAfterOptimizations.cpp: (): Deleted. * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::LowerToAir): Deleted. (JSC::B3::Air::LowerToAir::run): Deleted. (JSC::B3::Air::LowerToAir::shouldCopyPropagate): Deleted. (JSC::B3::Air::LowerToAir::ArgPromise::ArgPromise): Deleted. (JSC::B3::Air::LowerToAir::ArgPromise::swap): Deleted. (JSC::B3::Air::LowerToAir::ArgPromise::operator=): Deleted. (JSC::B3::Air::LowerToAir::ArgPromise::~ArgPromise): Deleted. (JSC::B3::Air::LowerToAir::ArgPromise::setTraps): Deleted. (JSC::B3::Air::LowerToAir::ArgPromise::tmp): Deleted. (JSC::B3::Air::LowerToAir::ArgPromise::operator bool const): Deleted. (JSC::B3::Air::LowerToAir::ArgPromise::kind const): Deleted. (JSC::B3::Air::LowerToAir::ArgPromise::peek const): Deleted. (JSC::B3::Air::LowerToAir::ArgPromise::consume): Deleted. (JSC::B3::Air::LowerToAir::ArgPromise::inst): Deleted. (JSC::B3::Air::LowerToAir::tmp): Deleted. (JSC::B3::Air::LowerToAir::tmpPromise): Deleted. (JSC::B3::Air::LowerToAir::canBeInternal): Deleted. (JSC::B3::Air::LowerToAir::commitInternal): Deleted. (JSC::B3::Air::LowerToAir::crossesInterference): Deleted. (JSC::B3::Air::LowerToAir::scaleForShl): Deleted. (JSC::B3::Air::LowerToAir::effectiveAddr): Deleted. (JSC::B3::Air::LowerToAir::addr): Deleted. (JSC::B3::Air::LowerToAir::trappingInst): Deleted. (JSC::B3::Air::LowerToAir::loadPromiseAnyOpcode): Deleted. (JSC::B3::Air::LowerToAir::loadPromise): Deleted. (JSC::B3::Air::LowerToAir::imm): Deleted. (JSC::B3::Air::LowerToAir::bitImm): Deleted. (JSC::B3::Air::LowerToAir::bitImm64): Deleted. (JSC::B3::Air::LowerToAir::immOrTmp): Deleted. (JSC::B3::Air::LowerToAir::tryOpcodeForType): Deleted. (JSC::B3::Air::LowerToAir::opcodeForType): Deleted. (JSC::B3::Air::LowerToAir::appendUnOp): Deleted. (JSC::B3::Air::LowerToAir::preferRightForResult): Deleted. (JSC::B3::Air::LowerToAir::appendBinOp): Deleted. (JSC::B3::Air::LowerToAir::appendShift): Deleted. (JSC::B3::Air::LowerToAir::tryAppendStoreUnOp): Deleted. (JSC::B3::Air::LowerToAir::tryAppendStoreBinOp): Deleted. (JSC::B3::Air::LowerToAir::createStore): Deleted. (JSC::B3::Air::LowerToAir::storeOpcode): Deleted. (JSC::B3::Air::LowerToAir::appendStore): Deleted. (JSC::B3::Air::LowerToAir::moveForType): Deleted. (JSC::B3::Air::LowerToAir::relaxedMoveForType): Deleted. (JSC::B3::Air::LowerToAir::print): Deleted. (JSC::B3::Air::LowerToAir::append): Deleted. (JSC::B3::Air::LowerToAir::appendTrapping): Deleted. (JSC::B3::Air::LowerToAir::finishAppendingInstructions): Deleted. (JSC::B3::Air::LowerToAir::newBlock): Deleted. (JSC::B3::Air::LowerToAir::splitBlock): Deleted. (JSC::B3::Air::LowerToAir::ensureSpecial): Deleted. (JSC::B3::Air::LowerToAir::ensureCheckSpecial): Deleted. (JSC::B3::Air::LowerToAir::fillStackmap): Deleted. (JSC::B3::Air::LowerToAir::createGenericCompare): Deleted. (JSC::B3::Air::LowerToAir::createBranch): Deleted. (JSC::B3::Air::LowerToAir::createCompare): Deleted. (JSC::B3::Air::LowerToAir::createSelect): Deleted. (JSC::B3::Air::LowerToAir::tryAppendLea): Deleted. (JSC::B3::Air::LowerToAir::appendX86Div): Deleted. (JSC::B3::Air::LowerToAir::appendX86UDiv): Deleted. (JSC::B3::Air::LowerToAir::loadLinkOpcode): Deleted. (JSC::B3::Air::LowerToAir::storeCondOpcode): Deleted. (JSC::B3::Air::LowerToAir::appendCAS): Deleted. (JSC::B3::Air::LowerToAir::appendVoidAtomic): Deleted. (JSC::B3::Air::LowerToAir::appendGeneralAtomic): Deleted. (JSC::B3::Air::LowerToAir::lower): Deleted. * b3/B3PatchpointSpecial.cpp: (JSC::B3::PatchpointSpecial::generate): * b3/B3ReduceDoubleToFloat.cpp: (JSC::B3::reduceDoubleToFloat): * b3/B3ReduceStrength.cpp: * b3/B3StackmapGenerationParams.cpp: * b3/B3StackmapSpecial.cpp: (JSC::B3::StackmapSpecial::repsImpl): (JSC::B3::StackmapSpecial::repForArg): * b3/air/AirAllocateStackByGraphColoring.cpp: (JSC::B3::Air::allocateStackByGraphColoring): * b3/air/AirEmitShuffle.cpp: (JSC::B3::Air::emitShuffle): * b3/air/AirFixObviousSpills.cpp: * b3/air/AirLowerAfterRegAlloc.cpp: (JSC::B3::Air::lowerAfterRegAlloc): * b3/air/AirStackAllocation.cpp: (JSC::B3::Air::attemptAssignment): (JSC::B3::Air::assign): * bytecode/AccessCase.cpp: (JSC::AccessCase::generateImpl): * bytecode/CallLinkStatus.cpp: (JSC::CallLinkStatus::computeDFGStatuses): * bytecode/GetterSetterAccessCase.cpp: (JSC::GetterSetterAccessCase::emitDOMJITGetter): * bytecode/ObjectPropertyConditionSet.cpp: * bytecode/PolymorphicAccess.cpp: (JSC::PolymorphicAccess::addCases): (JSC::PolymorphicAccess::regenerate): * bytecode/PropertyCondition.cpp: (JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint const): * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::addAccessCase): * dfg/DFGArgumentsEliminationPhase.cpp: * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::DelayedSetLocal::DelayedSetLocal): (JSC::DFG::ByteCodeParser::inliningCost): (JSC::DFG::ByteCodeParser::inlineCall): (JSC::DFG::ByteCodeParser::attemptToInlineCall): (JSC::DFG::ByteCodeParser::handleInlining): (JSC::DFG::ByteCodeParser::planLoad): (JSC::DFG::ByteCodeParser::store): (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::linkBlock): (JSC::DFG::ByteCodeParser::linkBlocks): * dfg/DFGCSEPhase.cpp: * dfg/DFGInPlaceAbstractState.cpp: (JSC::DFG::InPlaceAbstractState::merge): * dfg/DFGIntegerCheckCombiningPhase.cpp: (JSC::DFG::IntegerCheckCombiningPhase::handleBlock): * dfg/DFGIntegerRangeOptimizationPhase.cpp: * dfg/DFGMovHintRemovalPhase.cpp: * dfg/DFGObjectAllocationSinkingPhase.cpp: * dfg/DFGPhantomInsertionPhase.cpp: * dfg/DFGPutStackSinkingPhase.cpp: * dfg/DFGStoreBarrierInsertionPhase.cpp: * dfg/DFGVarargsForwardingPhase.cpp: * ftl/FTLAbstractHeap.cpp: (JSC::FTL::AbstractHeap::compute): * ftl/FTLAbstractHeapRepository.cpp: (JSC::FTL::AbstractHeapRepository::decorateMemory): (JSC::FTL::AbstractHeapRepository::decorateCCallRead): (JSC::FTL::AbstractHeapRepository::decorateCCallWrite): (JSC::FTL::AbstractHeapRepository::decoratePatchpointRead): (JSC::FTL::AbstractHeapRepository::decoratePatchpointWrite): (JSC::FTL::AbstractHeapRepository::decorateFenceRead): (JSC::FTL::AbstractHeapRepository::decorateFenceWrite): (JSC::FTL::AbstractHeapRepository::decorateFencedAccess): (JSC::FTL::AbstractHeapRepository::computeRangesAndDecorateInstructions): * ftl/FTLLink.cpp: (JSC::FTL::link): * heap/MarkingConstraintSet.cpp: (JSC::MarkingConstraintSet::add): * interpreter/ShadowChicken.cpp: (JSC::ShadowChicken::update): * jit/BinarySwitch.cpp: (JSC::BinarySwitch::BinarySwitch): (JSC::BinarySwitch::build): * llint/LLIntData.cpp: (JSC::LLInt::Data::loadStats): (JSC::LLInt::Data::saveStats): * runtime/ArrayPrototype.cpp: (JSC::ArrayPrototype::tryInitializeSpeciesWatchpoint): (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::handleFire): * runtime/ErrorInstance.cpp: (JSC::FindFirstCallerFrameWithCodeblockFunctor::FindFirstCallerFrameWithCodeblockFunctor): Deleted. (JSC::FindFirstCallerFrameWithCodeblockFunctor::operator()): Deleted. (JSC::FindFirstCallerFrameWithCodeblockFunctor::foundCallFrame const): Deleted. (JSC::FindFirstCallerFrameWithCodeblockFunctor::index const): Deleted. * runtime/IntlDateTimeFormat.cpp: (JSC::IntlDateTimeFormat::initializeDateTimeFormat): * runtime/PromiseDeferredTimer.cpp: (JSC::PromiseDeferredTimer::doWork): (JSC::PromiseDeferredTimer::addPendingPromise): (JSC::PromiseDeferredTimer::cancelPendingPromise): * runtime/TypeProfiler.cpp: (JSC::TypeProfiler::insertNewLocation): * runtime/TypeProfilerLog.cpp: (JSC::TypeProfilerLog::processLogEntries): * runtime/WeakMapPrototype.cpp: (JSC::protoFuncWeakMapDelete): (JSC::protoFuncWeakMapGet): (JSC::protoFuncWeakMapHas): (JSC::protoFuncWeakMapSet): (JSC::getWeakMapData): Deleted. * runtime/WeakSetPrototype.cpp: (JSC::protoFuncWeakSetDelete): (JSC::protoFuncWeakSetHas): (JSC::protoFuncWeakSetAdd): (JSC::getWeakMapData): Deleted. * testRegExp.cpp: (testOneRegExp): (runFromFiles): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::parseAndCompile): * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::moveToState): (JSC::Wasm::BBQPlan::parseAndValidateModule): (JSC::Wasm::BBQPlan::prepare): (JSC::Wasm::BBQPlan::compileFunctions): (JSC::Wasm::BBQPlan::complete): * wasm/WasmFaultSignalHandler.cpp: (JSC::Wasm::trapHandler): * wasm/WasmOMGPlan.cpp: (JSC::Wasm::OMGPlan::OMGPlan): (JSC::Wasm::OMGPlan::work): * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::fail): * wasm/WasmSignature.cpp: (JSC::Wasm::SignatureInformation::adopt): * wasm/WasmWorklist.cpp: (JSC::Wasm::Worklist::enqueue): 2017-09-12 Michael Saboff String.prototype.replace() puts extra '<' in result when a named capture reference is used without named captures in the RegExp https://bugs.webkit.org/show_bug.cgi?id=176814 Reviewed by Mark Lam. The copy and advance indices where off by one and needed a little fine tuning. * runtime/StringPrototype.cpp: (JSC::substituteBackreferencesSlow): 2017-09-11 Mark Lam More exception check book-keeping needed found by 32-bit JSC test failures. https://bugs.webkit.org/show_bug.cgi?id=176742 Reviewed by Michael Saboff and Keith Miller. * dfg/DFGOperations.cpp: 2017-09-11 Mark Lam Make jsc dump the command line if JSC_dumpOption environment variable is set with a non-zero value. https://bugs.webkit.org/show_bug.cgi?id=176722 Reviewed by Saam Barati. For PLATFORM(COCOA), I also dumped the JSC_* environmental variables that are in effect when jsc is invoked. * jsc.cpp: (CommandLine::parseArguments): 2017-09-11 Ryan Haddad Unreviewed, rolling out r221854. The test added with this change fails on 32-bit JSC bots. Reverted changeset: "[DFG] Optimize WeakMap::get by adding intrinsic and fixup" https://bugs.webkit.org/show_bug.cgi?id=176010 http://trac.webkit.org/changeset/221854 2017-09-03 Yusuke Suzuki [DFG] Optimize WeakMap::get by adding intrinsic and fixup https://bugs.webkit.org/show_bug.cgi?id=176010 Reviewed by Filip Pizlo. It reveals that Ember.js consumes 3.8% of execution time for WeakMap#get. It is used for meta property for objects (see peekMeta function in Ember.js). This patch optimizes WeakMap#get. 1. We use inlineGet to inline WeakMap#get operation in the native function. Since this native function itself is very small, we should inline HashMap#get entirely in this function. 2. We add JSWeakMapType and JSWeakSetType. This allows us to perform `isJSWeakMap()` very fast. And this patch wires this to DFG and FTL to add WeakMapObjectUse and WeakSetObjectUse to drop unnecessary type checking. We add fixup rules for WeakMapGet DFG node by using WeakMapObjectUse, ObjectUse, and Int32Use. 3. We add intrinsic for WeakMap#get, and handle it in DFG and FTL. We use MapHash to calculate hash value for the key's Object and use this hash value to look up value from JSWeakMap's HashMap. Currently, we just call the operationWeakMapGet function in DFG and FTL. It is worth considering that implementing this operation entirely in JIT, like GetMapBucket. But anyway, the current one already optimizes the performance, so we leave this for the subsequent patches. We currently do not implement any other intrinsics (like, WeakMap#has, WeakSet) because they are not used in Ember.js right now. This patch optimizes WeakMap#get by 50%. baseline patched weak-map-key 88.6456+-3.9564 ^ 59.1502+-2.2406 ^ definitely 1.4987x faster * bytecode/DirectEvalCodeCache.h: (JSC::DirectEvalCodeCache::tryGet): * bytecode/SpeculatedType.cpp: (JSC::dumpSpeculation): (JSC::speculationFromClassInfo): (JSC::speculationFromJSType): (JSC::speculationFromString): * bytecode/SpeculatedType.h: * 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/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::speculateWeakMapObject): (JSC::DFG::SpeculativeJIT::speculateWeakSetObject): (JSC::DFG::SpeculativeJIT::speculate): (JSC::DFG::SpeculativeJIT::compileWeakMapGet): * 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/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileWeakMapGet): (JSC::FTL::DFG::LowerDFGToB3::lowWeakMapObject): (JSC::FTL::DFG::LowerDFGToB3::lowWeakSetObject): (JSC::FTL::DFG::LowerDFGToB3::speculate): (JSC::FTL::DFG::LowerDFGToB3::speculateWeakMapObject): (JSC::FTL::DFG::LowerDFGToB3::speculateWeakSetObject): * jit/JITOperations.h: * runtime/Intrinsic.cpp: (JSC::intrinsicName): * runtime/Intrinsic.h: * runtime/JSType.h: * runtime/JSWeakMap.h: (JSC::isJSWeakMap): * runtime/JSWeakSet.h: (JSC::isJSWeakSet): * runtime/WeakMapBase.cpp: (JSC::WeakMapBase::get): * runtime/WeakMapBase.h: (JSC::WeakMapBase::HashTranslator::hash): (JSC::WeakMapBase::HashTranslator::equal): (JSC::WeakMapBase::inlineGet): * runtime/WeakMapPrototype.cpp: (JSC::WeakMapPrototype::finishCreation): (JSC::getWeakMap): (JSC::protoFuncWeakMapGet): * runtime/WeakSetPrototype.cpp: (JSC::getWeakSet): 2017-09-09 Yusuke Suzuki [JSC] Optimize Object.keys by using careful array allocation https://bugs.webkit.org/show_bug.cgi?id=176654 Reviewed by Darin Adler. SixSpeed object-assign.es6 stresses Object.keys. Object.keys is one of frequently used function in JS apps. Luckily Object.keys has several good features. 1. Once PropertyNameArray is allocated, we know the length of the result array since we do not need to filter out keys listed in PropertyNameArray. The execption is ProxyObject, but it rarely appears. ProxyObject case goes to the generic path. 2. Object.keys does not need to access object after listing PropertyNameArray. It means that we do not need to worry about enumeration attribute change by touching object. This patch adds a fast path for Object.keys's array allocation. We allocate the JSArray with the size and ArrayContiguous indexing shape. This further improves SixSpeed object-assign.es5 by 13%. baseline patched Microbenchmarks: object-keys-map-values 73.4324+-2.5397 ^ 62.5933+-2.6677 ^ definitely 1.1732x faster object-keys 40.8828+-1.5851 ^ 29.2066+-1.8944 ^ definitely 1.3998x faster baseline patched SixSpeed: object-assign.es5 384.8719+-10.7204 ^ 340.2734+-12.0947 ^ definitely 1.1311x faster BTW, the further optimization of Object.keys can be considered: introducing own property keys cache which is similar to the current enumeration cache. But this patch is orthogonal to this optimization! * runtime/ObjectConstructor.cpp: (JSC::objectConstructorValues): (JSC::ownPropertyKeys): * runtime/ObjectConstructor.h: 2017-09-10 Mark Lam Fix all ExceptionScope verification failures in JavaScriptCore. https://bugs.webkit.org/show_bug.cgi?id=176662 Reviewed by Filip Pizlo. 1. Introduced EXCEPTION_ASSERT macros so that we can enable exception scope verification for release builds too (though this requires manually setting ENABLE_EXCEPTION_SCOPE_VERIFICATION to 1 in Platform.h). This is useful because it allows us to run the tests more quickly to check if any regressions have occurred. Debug builds run so much slower and not good for a quick turn around. Debug builds are necessary though to get trace information without inlining by the C++ compiler. This is necessary to diagnose where the missing exception check is. 2. Repurposed the JSC_dumpSimulatedThrows=true options to capture and dump the last simulated throw when an exception scope verification fails. Previously, this option dumps the stack trace on all simulated throws. That turned out to not be very useful, and slows down the debugging process. Instead, the new implementation captures the stack trace and only dumps it if we have a verification failure. 3. Fixed missing exception checks and book-keeping needed to allow the JSC tests to pass with JSC_validateExceptionChecks=true. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::executeOSRExit): * dfg/DFGOperations.cpp: * interpreter/Interpreter.cpp: (JSC::eval): (JSC::loadVarargs): (JSC::Interpreter::unwind): (JSC::Interpreter::executeProgram): (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): (JSC::Interpreter::prepareForRepeatCall): (JSC::Interpreter::execute): (JSC::Interpreter::executeModuleProgram): * jit/JITOperations.cpp: (JSC::getByVal): * jsc.cpp: (WTF::CustomGetter::customGetterAcessor): (GlobalObject::moduleLoaderImportModule): (GlobalObject::moduleLoaderResolve): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::getByVal): (JSC::LLInt::setUpCall): * parser/Parser.h: (JSC::Parser::popScopeInternal): * runtime/AbstractModuleRecord.cpp: (JSC::AbstractModuleRecord::hostResolveImportedModule): (JSC::AbstractModuleRecord::resolveImport): (JSC::AbstractModuleRecord::resolveExportImpl): (JSC::getExportedNames): (JSC::AbstractModuleRecord::getModuleNamespace): * runtime/ArrayPrototype.cpp: (JSC::getProperty): (JSC::unshift): (JSC::arrayProtoFuncToString): (JSC::arrayProtoFuncToLocaleString): (JSC::arrayProtoFuncJoin): (JSC::arrayProtoFuncPop): (JSC::arrayProtoFuncPush): (JSC::arrayProtoFuncReverse): (JSC::arrayProtoFuncShift): (JSC::arrayProtoFuncSlice): (JSC::arrayProtoFuncSplice): (JSC::arrayProtoFuncUnShift): (JSC::arrayProtoFuncIndexOf): (JSC::arrayProtoFuncLastIndexOf): (JSC::concatAppendOne): (JSC::arrayProtoPrivateFuncConcatMemcpy): (JSC::arrayProtoPrivateFuncAppendMemcpy): * runtime/CatchScope.h: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/DatePrototype.cpp: (JSC::dateProtoFuncSetTime): (JSC::setNewValueFromTimeArgs): * runtime/DirectArguments.h: (JSC::DirectArguments::length const): * runtime/ErrorPrototype.cpp: (JSC::errorProtoFuncToString): * runtime/ExceptionFuzz.cpp: (JSC::doExceptionFuzzing): * runtime/ExceptionScope.h: (JSC::ExceptionScope::needExceptionCheck): (JSC::ExceptionScope::assertNoException): * runtime/GenericArgumentsInlines.h: (JSC::GenericArguments::defineOwnProperty): * runtime/HashMapImpl.h: (JSC::HashMapImpl::rehash): * runtime/IntlDateTimeFormat.cpp: (JSC::IntlDateTimeFormat::formatToParts): * runtime/JSArray.cpp: (JSC::JSArray::defineOwnProperty): (JSC::JSArray::put): * runtime/JSCJSValue.cpp: (JSC::JSValue::putToPrimitive): (JSC::JSValue::putToPrimitiveByIndex): * runtime/JSCJSValueInlines.h: (JSC::JSValue::toIndex const): (JSC::JSValue::get const): (JSC::JSValue::getPropertySlot const): (JSC::JSValue::equalSlowCaseInline): * runtime/JSGenericTypedArrayViewConstructorInlines.h: (JSC::constructGenericTypedArrayViewFromIterator): (JSC::constructGenericTypedArrayViewWithArguments): * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::set): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::put): * runtime/JSGlobalObjectFunctions.cpp: (JSC::decode): (JSC::globalFuncEval): (JSC::globalFuncProtoGetter): (JSC::globalFuncProtoSetter): (JSC::globalFuncImportModule): * runtime/JSInternalPromise.cpp: (JSC::JSInternalPromise::then): * runtime/JSInternalPromiseDeferred.cpp: (JSC::JSInternalPromiseDeferred::create): * runtime/JSJob.cpp: (JSC::JSJobMicrotask::run): * runtime/JSModuleEnvironment.cpp: (JSC::JSModuleEnvironment::getOwnPropertySlot): (JSC::JSModuleEnvironment::put): (JSC::JSModuleEnvironment::deleteProperty): * runtime/JSModuleLoader.cpp: (JSC::JSModuleLoader::provide): (JSC::JSModuleLoader::loadAndEvaluateModule): (JSC::JSModuleLoader::loadModule): (JSC::JSModuleLoader::linkAndEvaluateModule): (JSC::JSModuleLoader::requestImportModule): * runtime/JSModuleRecord.cpp: (JSC::JSModuleRecord::link): (JSC::JSModuleRecord::instantiateDeclarations): * runtime/JSONObject.cpp: (JSC::Stringifier::stringify): (JSC::Stringifier::toJSON): (JSC::JSONProtoFuncParse): * runtime/JSObject.cpp: (JSC::JSObject::calculatedClassName): (JSC::ordinarySetSlow): (JSC::JSObject::putInlineSlow): (JSC::JSObject::ordinaryToPrimitive const): (JSC::JSObject::toPrimitive const): (JSC::JSObject::hasInstance): (JSC::JSObject::getPropertyNames): (JSC::JSObject::toNumber const): (JSC::JSObject::defineOwnIndexedProperty): (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes): (JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage): (JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage): (JSC::validateAndApplyPropertyDescriptor): (JSC::JSObject::defineOwnNonIndexProperty): (JSC::JSObject::getGenericPropertyNames): * runtime/JSObject.h: (JSC::JSObject::get const): * runtime/JSObjectInlines.h: (JSC::JSObject::getPropertySlot const): (JSC::JSObject::getPropertySlot): (JSC::JSObject::getNonIndexPropertySlot): (JSC::JSObject::putInlineForJSObject): * runtime/JSPromiseConstructor.cpp: (JSC::constructPromise): * runtime/JSPromiseDeferred.cpp: (JSC::JSPromiseDeferred::create): * runtime/JSScope.cpp: (JSC::abstractAccess): (JSC::JSScope::resolve): (JSC::JSScope::resolveScopeForHoistingFuncDeclInEval): (JSC::JSScope::abstractResolve): * runtime/LiteralParser.cpp: (JSC::LiteralParser::tryJSONPParse): (JSC::LiteralParser::parse): * runtime/Lookup.h: (JSC::putEntry): * runtime/MapConstructor.cpp: (JSC::constructMap): * runtime/NumberPrototype.cpp: (JSC::numberProtoFuncToString): * runtime/ObjectConstructor.cpp: (JSC::objectConstructorSetPrototypeOf): (JSC::objectConstructorGetOwnPropertyDescriptor): (JSC::objectConstructorGetOwnPropertyDescriptors): (JSC::objectConstructorAssign): (JSC::objectConstructorValues): (JSC::toPropertyDescriptor): (JSC::objectConstructorDefineProperty): (JSC::defineProperties): (JSC::objectConstructorDefineProperties): (JSC::ownPropertyKeys): * runtime/ObjectPrototype.cpp: (JSC::objectProtoFuncHasOwnProperty): (JSC::objectProtoFuncIsPrototypeOf): (JSC::objectProtoFuncLookupGetter): (JSC::objectProtoFuncLookupSetter): (JSC::objectProtoFuncToLocaleString): (JSC::objectProtoFuncToString): * runtime/Options.h: * runtime/ParseInt.h: (JSC::toStringView): * runtime/ProxyObject.cpp: (JSC::performProxyGet): (JSC::ProxyObject::performPut): * runtime/ReflectObject.cpp: (JSC::reflectObjectDefineProperty): * runtime/RegExpConstructor.cpp: (JSC::toFlags): (JSC::regExpCreate): (JSC::constructRegExp): * runtime/RegExpObject.cpp: (JSC::collectMatches): * runtime/RegExpObjectInlines.h: (JSC::RegExpObject::execInline): (JSC::RegExpObject::matchInline): * runtime/RegExpPrototype.cpp: (JSC::regExpProtoFuncTestFast): (JSC::regExpProtoFuncExec): (JSC::regExpProtoFuncMatchFast): (JSC::regExpProtoFuncToString): (JSC::regExpProtoFuncSplitFast): * runtime/ScriptExecutable.cpp: (JSC::ScriptExecutable::newCodeBlockFor): (JSC::ScriptExecutable::prepareForExecutionImpl): * runtime/SetConstructor.cpp: (JSC::constructSet): * runtime/ThrowScope.cpp: (JSC::ThrowScope::simulateThrow): * runtime/VM.cpp: (JSC::VM::verifyExceptionCheckNeedIsSatisfied): * runtime/VM.h: * runtime/WeakMapPrototype.cpp: (JSC::protoFuncWeakMapSet): * runtime/WeakSetPrototype.cpp: (JSC::protoFuncWeakSetAdd): * wasm/js/WebAssemblyModuleConstructor.cpp: (JSC::WebAssemblyModuleConstructor::createModule): * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::link): * wasm/js/WebAssemblyPrototype.cpp: (JSC::reject): (JSC::webAssemblyCompileFunc): (JSC::resolve): (JSC::webAssemblyInstantiateFunc): 2017-09-08 Filip Pizlo Error should compute .stack and friends lazily https://bugs.webkit.org/show_bug.cgi?id=176645 Reviewed by Saam Barati. Building the string portion of the stack trace after we walk the stack accounts for most of the cost of computing the .stack property. So, this patch makes ErrorInstance hold onto the Vector so that it can build the string only once it's really needed. This is an enormous speed-up for programs that allocate and throw exceptions. It's a 5.6x speed-up for "new Error()" with a stack that is 4 functions deep. It's a 2.2x speed-up for throwing and catching an Error. It's a 1.17x speed-up for the WSL test suite (which throws a lot). It's a significant speed-up on many of our existing try-catch microbenchmarks. For example, delta-blue-try-catch is 1.16x faster. * interpreter/Interpreter.cpp: (JSC::GetStackTraceFunctor::GetStackTraceFunctor): (JSC::GetStackTraceFunctor::operator() const): (JSC::Interpreter::getStackTrace): * interpreter/Interpreter.h: * runtime/Error.cpp: (JSC::getStackTrace): (JSC::getBytecodeOffset): (JSC::addErrorInfo): (JSC::addErrorInfoAndGetBytecodeOffset): Deleted. * runtime/Error.h: * runtime/ErrorInstance.cpp: (JSC::ErrorInstance::ErrorInstance): (JSC::ErrorInstance::finishCreation): (JSC::ErrorInstance::materializeErrorInfoIfNeeded): (JSC::ErrorInstance::visitChildren): (JSC::ErrorInstance::getOwnPropertySlot): (JSC::ErrorInstance::getOwnNonIndexPropertyNames): (JSC::ErrorInstance::defineOwnProperty): (JSC::ErrorInstance::put): (JSC::ErrorInstance::deleteProperty): * runtime/ErrorInstance.h: * runtime/Exception.cpp: (JSC::Exception::visitChildren): (JSC::Exception::finishCreation): * runtime/Exception.h: * runtime/StackFrame.cpp: (JSC::StackFrame::visitChildren): * runtime/StackFrame.h: (JSC::StackFrame::StackFrame): 2017-09-09 Mark Lam [Re-landing] Use JIT probes for DFG OSR exit. https://bugs.webkit.org/show_bug.cgi?id=175144 Not reviewed. Original patch reviewed by Saam Barati. Relanding r221774. * JavaScriptCore.xcodeproj/project.pbxproj: * assembler/MacroAssembler.cpp: (JSC::stdFunctionCallback): * assembler/MacroAssemblerPrinter.cpp: (JSC::Printer::printCallback): * assembler/ProbeContext.h: (JSC::Probe::CPUState::gpr const): (JSC::Probe::CPUState::spr const): (JSC::Probe::Context::Context): (JSC::Probe::Context::arg): (JSC::Probe::Context::gpr): (JSC::Probe::Context::spr): (JSC::Probe::Context::fpr): (JSC::Probe::Context::gprName): (JSC::Probe::Context::sprName): (JSC::Probe::Context::fprName): (JSC::Probe::Context::gpr const): (JSC::Probe::Context::spr const): (JSC::Probe::Context::fpr const): (JSC::Probe::Context::pc): (JSC::Probe::Context::fp): (JSC::Probe::Context::sp): (JSC::Probe:: const): Deleted. * assembler/ProbeFrame.h: Copied from Source/JavaScriptCore/assembler/ProbeFrame.h. * assembler/ProbeStack.cpp: (JSC::Probe::Page::Page): * assembler/ProbeStack.h: (JSC::Probe::Page::get): (JSC::Probe::Page::set): (JSC::Probe::Page::physicalAddressFor): (JSC::Probe::Stack::lowWatermark): (JSC::Probe::Stack::get): (JSC::Probe::Stack::set): * bytecode/ArithProfile.cpp: * bytecode/ArithProfile.h: * bytecode/ArrayProfile.h: (JSC::ArrayProfile::observeArrayMode): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::updateOSRExitCounterAndCheckIfNeedToReoptimize): * bytecode/CodeBlock.h: (JSC::CodeBlock::addressOfOSRExitCounter): Deleted. * bytecode/ExecutionCounter.h: (JSC::ExecutionCounter::hasCrossedThreshold const): (JSC::ExecutionCounter::setNewThresholdForOSRExit): * bytecode/MethodOfGettingAValueProfile.cpp: (JSC::MethodOfGettingAValueProfile::reportValue): * bytecode/MethodOfGettingAValueProfile.h: * dfg/DFGDriver.cpp: (JSC::DFG::compileImpl): * dfg/DFGJITCode.cpp: (JSC::DFG::JITCode::findPC): Deleted. * dfg/DFGJITCode.h: * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::linkOSRExits): (JSC::DFG::JITCompiler::link): * dfg/DFGOSRExit.cpp: (JSC::DFG::jsValueFor): (JSC::DFG::restoreCalleeSavesFor): (JSC::DFG::saveCalleeSavesFor): (JSC::DFG::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer): (JSC::DFG::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer): (JSC::DFG::saveOrCopyCalleeSavesFor): (JSC::DFG::createDirectArgumentsDuringExit): (JSC::DFG::createClonedArgumentsDuringExit): (JSC::DFG::OSRExit::OSRExit): (JSC::DFG::emitRestoreArguments): (JSC::DFG::OSRExit::executeOSRExit): (JSC::DFG::reifyInlinedCallFrames): (JSC::DFG::adjustAndJumpToTarget): (JSC::DFG::printOSRExit): (JSC::DFG::OSRExit::setPatchableCodeOffset): Deleted. (JSC::DFG::OSRExit::getPatchableCodeOffsetAsJump const): Deleted. (JSC::DFG::OSRExit::codeLocationForRepatch const): Deleted. (JSC::DFG::OSRExit::correctJump): Deleted. (JSC::DFG::OSRExit::emitRestoreArguments): Deleted. (JSC::DFG::OSRExit::compileOSRExit): Deleted. (JSC::DFG::OSRExit::compileExit): Deleted. (JSC::DFG::OSRExit::debugOperationPrintSpeculationFailure): Deleted. * dfg/DFGOSRExit.h: (JSC::DFG::OSRExitState::OSRExitState): (JSC::DFG::OSRExit::considerAddingAsFrequentExitSite): * dfg/DFGOSRExitCompilerCommon.cpp: * dfg/DFGOSRExitCompilerCommon.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGThunks.cpp: (JSC::DFG::osrExitThunkGenerator): (JSC::DFG::osrExitGenerationThunkGenerator): Deleted. * dfg/DFGThunks.h: * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::debugCall): Deleted. * jit/AssemblyHelpers.h: * jit/JITOperations.cpp: * jit/JITOperations.h: * profiler/ProfilerOSRExit.h: (JSC::Profiler::OSRExit::incCount): * runtime/JSCJSValue.h: * runtime/JSCJSValueInlines.h: * runtime/VM.h: 2017-09-09 Ryan Haddad Unreviewed, rolling out r221774. This change introduced three debug JSC test timeouts. Reverted changeset: "Use JIT probes for DFG OSR exit." https://bugs.webkit.org/show_bug.cgi?id=175144 http://trac.webkit.org/changeset/221774 2017-09-09 Mark Lam Avoid duplicate computations of ExecState::vm(). https://bugs.webkit.org/show_bug.cgi?id=176647 Reviewed by Saam Barati. Because while computing ExecState::vm() is cheap, it is not free. This patch also: 1. gets rids of some convenience methods in CallFrame that implicitly does a ExecState::vm() computation. This minimizes the chance of us accidentally computing ExecState::vm() more than necessary. 2. passes vm (when available) to methodTable(). 3. passes vm (when available) to JSLockHolder. * API/JSBase.cpp: (JSCheckScriptSyntax): (JSGarbageCollect): (JSReportExtraMemoryCost): (JSSynchronousGarbageCollectForDebugging): (JSSynchronousEdenCollectForDebugging): * API/JSCallbackConstructor.h: (JSC::JSCallbackConstructor::create): * API/JSCallbackObject.h: (JSC::JSCallbackObject::create): * API/JSContext.mm: (-[JSContext setException:]): * API/JSContextRef.cpp: (JSContextGetGlobalObject): (JSContextCreateBacktrace): * API/JSManagedValue.mm: (-[JSManagedValue value]): * API/JSObjectRef.cpp: (JSObjectMake): (JSObjectMakeFunctionWithCallback): (JSObjectMakeConstructor): (JSObjectMakeFunction): (JSObjectSetPrototype): (JSObjectHasProperty): (JSObjectGetProperty): (JSObjectSetProperty): (JSObjectSetPropertyAtIndex): (JSObjectDeleteProperty): (JSObjectGetPrivateProperty): (JSObjectSetPrivateProperty): (JSObjectDeletePrivateProperty): (JSObjectIsFunction): (JSObjectCallAsFunction): (JSObjectCallAsConstructor): (JSObjectCopyPropertyNames): (JSPropertyNameAccumulatorAddName): * API/JSScriptRef.cpp: * API/JSTypedArray.cpp: (JSValueGetTypedArrayType): (JSObjectMakeTypedArrayWithArrayBuffer): (JSObjectMakeTypedArrayWithArrayBufferAndOffset): (JSObjectGetTypedArrayBytesPtr): (JSObjectGetTypedArrayBuffer): (JSObjectMakeArrayBufferWithBytesNoCopy): (JSObjectGetArrayBufferBytesPtr): * API/JSWeakObjectMapRefPrivate.cpp: * API/JSWrapperMap.mm: (constructorHasInstance): (makeWrapper): * API/ObjCCallbackFunction.mm: (objCCallbackFunctionForInvocation): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::CodeBlock): (JSC::CodeBlock::jettison): * bytecode/CodeBlock.h: (JSC::CodeBlock::addConstant): (JSC::CodeBlock::replaceConstant): * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeFromLLInt): (JSC::PutByIdStatus::computeFor): * dfg/DFGDesiredWatchpoints.cpp: (JSC::DFG::ArrayBufferViewWatchpointAdaptor::add): * dfg/DFGGraph.h: (JSC::DFG::Graph::globalThisObjectFor): * dfg/DFGOperations.cpp: * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileFTLOSRExit): * ftl/FTLOperations.cpp: (JSC::FTL::operationPopulateObjectInOSR): (JSC::FTL::operationMaterializeObjectInOSR): * heap/GCAssertions.h: * inspector/InjectedScriptHost.cpp: (Inspector::InjectedScriptHost::wrapper): * inspector/JSInjectedScriptHost.cpp: (Inspector::JSInjectedScriptHost::subtype): (Inspector::constructInternalProperty): (Inspector::JSInjectedScriptHost::getInternalProperties): (Inspector::JSInjectedScriptHost::weakMapEntries): (Inspector::JSInjectedScriptHost::weakSetEntries): (Inspector::JSInjectedScriptHost::iteratorEntries): * inspector/JSJavaScriptCallFrame.cpp: (Inspector::valueForScopeLocation): (Inspector::JSJavaScriptCallFrame::scopeDescriptions): (Inspector::toJS): * inspector/ScriptCallStackFactory.cpp: (Inspector::extractSourceInformationFromException): (Inspector::createScriptArguments): * interpreter/CachedCall.h: (JSC::CachedCall::CachedCall): * interpreter/CallFrame.h: (JSC::ExecState::atomicStringTable const): Deleted. (JSC::ExecState::propertyNames const): Deleted. (JSC::ExecState::emptyList const): Deleted. (JSC::ExecState::interpreter): Deleted. (JSC::ExecState::heap): Deleted. * interpreter/Interpreter.cpp: (JSC::Interpreter::executeProgram): (JSC::Interpreter::execute): (JSC::Interpreter::executeModuleProgram): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JITOperations.cpp: * jit/JITWorklist.cpp: (JSC::JITWorklist::compileNow): * jsc.cpp: (WTF::RuntimeArray::create): (WTF::RuntimeArray::getOwnPropertySlot): (WTF::DOMJITGetter::DOMJITAttribute::slowCall): (WTF::DOMJITFunctionObject::unsafeFunction): (WTF::DOMJITCheckSubClassObject::unsafeFunction): (GlobalObject::moduleLoaderFetch): (functionDumpCallFrame): (functionCreateRoot): (functionGetElement): (functionSetElementRoot): (functionCreateSimpleObject): (functionSetHiddenValue): (functionCreateProxy): (functionCreateImpureGetter): (functionCreateCustomGetterObject): (functionCreateDOMJITNodeObject): (functionCreateDOMJITGetterObject): (functionCreateDOMJITGetterComplexObject): (functionCreateDOMJITFunctionObject): (functionCreateDOMJITCheckSubClassObject): (functionGCAndSweep): (functionFullGC): (functionEdenGC): (functionHeapSize): (functionShadowChickenFunctionsOnStack): (functionSetGlobalConstRedeclarationShouldNotThrow): (functionJSCOptions): (functionFailNextNewCodeBlock): (functionMakeMasquerader): (functionDumpTypesForAllVariables): (functionFindTypeForExpression): (functionReturnTypeFor): (functionDumpBasicBlockExecutionRanges): (functionBasicBlockExecutionCount): (functionDrainMicrotasks): (functionGenerateHeapSnapshot): (functionEnsureArrayStorage): (functionStartSamplingProfiler): (runInteractive): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * parser/ModuleAnalyzer.cpp: (JSC::ModuleAnalyzer::ModuleAnalyzer): * profiler/ProfilerBytecode.cpp: (JSC::Profiler::Bytecode::toJS const): * profiler/ProfilerBytecodeSequence.cpp: (JSC::Profiler::BytecodeSequence::addSequenceProperties const): * profiler/ProfilerBytecodes.cpp: (JSC::Profiler::Bytecodes::toJS const): * profiler/ProfilerCompilation.cpp: (JSC::Profiler::Compilation::toJS const): * profiler/ProfilerCompiledBytecode.cpp: (JSC::Profiler::CompiledBytecode::toJS const): * profiler/ProfilerDatabase.cpp: (JSC::Profiler::Database::toJS const): * profiler/ProfilerEvent.cpp: (JSC::Profiler::Event::toJS const): * profiler/ProfilerOSRExit.cpp: (JSC::Profiler::OSRExit::toJS const): * profiler/ProfilerOrigin.cpp: (JSC::Profiler::Origin::toJS const): * profiler/ProfilerProfiledBytecodes.cpp: (JSC::Profiler::ProfiledBytecodes::toJS const): * runtime/AbstractModuleRecord.cpp: (JSC::identifierToJSValue): (JSC::AbstractModuleRecord::resolveExportImpl): (JSC::getExportedNames): * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncToString): (JSC::arrayProtoFuncToLocaleString): * runtime/BooleanConstructor.cpp: (JSC::constructBooleanFromImmediateBoolean): * runtime/CallData.cpp: (JSC::call): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: (JSC::CommonSlowPaths::tryCachePutToScopeGlobal): (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal): * runtime/Completion.cpp: (JSC::checkSyntax): (JSC::evaluate): (JSC::loadAndEvaluateModule): (JSC::loadModule): (JSC::linkAndEvaluateModule): (JSC::importModule): * runtime/ConstructData.cpp: (JSC::construct): * runtime/DatePrototype.cpp: (JSC::dateProtoFuncToJSON): * runtime/DirectArguments.h: (JSC::DirectArguments::length const): * runtime/DirectEvalExecutable.cpp: (JSC::DirectEvalExecutable::create): * runtime/ErrorPrototype.cpp: (JSC::errorProtoFuncToString): * runtime/ExceptionHelpers.cpp: (JSC::createUndefinedVariableError): (JSC::errorDescriptionForValue): * runtime/FunctionConstructor.cpp: (JSC::constructFunction): * runtime/GenericArgumentsInlines.h: (JSC::GenericArguments::getOwnPropertyNames): * runtime/IdentifierInlines.h: (JSC::Identifier::add): * runtime/IndirectEvalExecutable.cpp: (JSC::IndirectEvalExecutable::create): * runtime/InternalFunction.cpp: (JSC::InternalFunction::finishCreation): (JSC::InternalFunction::createSubclassStructureSlow): * runtime/JSArray.cpp: (JSC::JSArray::getOwnPropertySlot): (JSC::JSArray::put): (JSC::JSArray::deleteProperty): (JSC::JSArray::getOwnNonIndexPropertyNames): (JSC::JSArray::isIteratorProtocolFastAndNonObservable): * runtime/JSArray.h: (JSC::JSArray::shiftCountForShift): * runtime/JSCJSValue.cpp: (JSC::JSValue::dumpForBacktrace const): * runtime/JSDataView.cpp: (JSC::JSDataView::getOwnPropertySlot): (JSC::JSDataView::deleteProperty): (JSC::JSDataView::getOwnNonIndexPropertyNames): * runtime/JSFunction.cpp: (JSC::JSFunction::getOwnPropertySlot): (JSC::JSFunction::deleteProperty): (JSC::JSFunction::reifyName): * runtime/JSGlobalObjectFunctions.cpp: (JSC::globalFuncEval): * runtime/JSInternalPromise.cpp: (JSC::JSInternalPromise::then): * runtime/JSLexicalEnvironment.cpp: (JSC::JSLexicalEnvironment::deleteProperty): * runtime/JSMap.cpp: (JSC::JSMap::isIteratorProtocolFastAndNonObservable): * runtime/JSMapIterator.h: (JSC::JSMapIterator::advanceIter): * runtime/JSModuleEnvironment.cpp: (JSC::JSModuleEnvironment::getOwnNonIndexPropertyNames): * runtime/JSModuleLoader.cpp: (JSC::printableModuleKey): (JSC::JSModuleLoader::provide): (JSC::JSModuleLoader::loadAndEvaluateModule): (JSC::JSModuleLoader::loadModule): (JSC::JSModuleLoader::linkAndEvaluateModule): (JSC::JSModuleLoader::requestImportModule): * runtime/JSModuleNamespaceObject.h: * runtime/JSModuleRecord.cpp: (JSC::JSModuleRecord::evaluate): * runtime/JSONObject.cpp: (JSC::Stringifier::Stringifier): (JSC::Stringifier::appendStringifiedValue): (JSC::Stringifier::Holder::appendNextProperty): * runtime/JSObject.cpp: (JSC::JSObject::calculatedClassName): (JSC::JSObject::putByIndex): (JSC::JSObject::ordinaryToPrimitive const): (JSC::JSObject::toPrimitive const): (JSC::JSObject::hasInstance): (JSC::JSObject::getOwnPropertyNames): (JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength): (JSC::getCustomGetterSetterFunctionForGetterSetter): (JSC::JSObject::getOwnPropertyDescriptor): (JSC::JSObject::getMethod): * runtime/JSObject.h: (JSC::JSObject::createRawObject): (JSC::JSFinalObject::create): * runtime/JSObjectInlines.h: (JSC::JSObject::canPerformFastPutInline): (JSC::JSObject::putInlineForJSObject): (JSC::JSObject::hasOwnProperty const): * runtime/JSScope.cpp: (JSC::isUnscopable): (JSC::JSScope::resolveScopeForHoistingFuncDeclInEval): * runtime/JSSet.cpp: (JSC::JSSet::isIteratorProtocolFastAndNonObservable): * runtime/JSSetIterator.h: (JSC::JSSetIterator::advanceIter): * runtime/JSString.cpp: (JSC::JSString::getStringPropertyDescriptor): * runtime/JSString.h: (JSC::JSString::getStringPropertySlot): * runtime/MapConstructor.cpp: (JSC::constructMap): * runtime/ModuleProgramExecutable.cpp: (JSC::ModuleProgramExecutable::create): * runtime/ObjectPrototype.cpp: (JSC::objectProtoFuncToLocaleString): * runtime/ProgramExecutable.h: * runtime/RegExpObject.cpp: (JSC::RegExpObject::getOwnPropertySlot): (JSC::RegExpObject::deleteProperty): (JSC::RegExpObject::getOwnNonIndexPropertyNames): (JSC::RegExpObject::getPropertyNames): (JSC::RegExpObject::getGenericPropertyNames): (JSC::RegExpObject::put): * runtime/ScopedArguments.h: (JSC::ScopedArguments::length const): * runtime/StrictEvalActivation.h: (JSC::StrictEvalActivation::create): * runtime/StringObject.cpp: (JSC::isStringOwnProperty): (JSC::StringObject::deleteProperty): (JSC::StringObject::getOwnNonIndexPropertyNames): * tools/JSDollarVMPrototype.cpp: (JSC::JSDollarVMPrototype::gc): (JSC::JSDollarVMPrototype::edenGC): * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::evaluate): 2017-09-08 Yusuke Suzuki [DFG] NewArrayWithSize(size)'s size does not care negative zero https://bugs.webkit.org/show_bug.cgi?id=176300 Reviewed by Saam Barati. NewArrayWithSize(size)'s size does not care negative zero as is the same to NewTypedArray. We propagate this information in DFGBackwardsPropagationPhase. This removes negative zero check in kraken fft's deinterleave function. * dfg/DFGBackwardsPropagationPhase.cpp: (JSC::DFG::BackwardsPropagationPhase::propagate): 2017-09-08 Yusuke Suzuki [DFG] PutByVal with Array::Generic is too generic https://bugs.webkit.org/show_bug.cgi?id=176345 Reviewed by Filip Pizlo. Our DFG/FTL's PutByVal with Array::Generic is too generic implementation. We could have the case like, dst[key] = src[key]; with string or symbol keys. But they are handled in slow path. This patch adds PutByVal(CellUse, StringUse/SymbolUse, UntypedUse). They go to optimized path that does not have generic checks like (isInt32() / isDouble() etc.). This improves SixSpeed object-assign.es5 by 9.1%. object-assign.es5 424.3159+-11.0471 ^ 388.8771+-10.9239 ^ definitely 1.0911x faster * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGOperations.cpp: (JSC::DFG::putByVal): (JSC::DFG::putByValInternal): (JSC::DFG::putByValCellInternal): (JSC::DFG::putByValCellStringInternal): (JSC::DFG::operationPutByValInternal): Deleted. * dfg/DFGOperations.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compilePutByValForCellWithString): (JSC::DFG::SpeculativeJIT::compilePutByValForCellWithSymbol): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal): * jit/JITOperations.h: 2017-09-08 Yusuke Suzuki [DFG][FTL] GetByVal(ObjectUse with Array::Generic, StringUse/SymbolUse) should be supported https://bugs.webkit.org/show_bug.cgi?id=176590 Reviewed by Saam Barati. We add fixup edges for GetByVal(Array::Generic) to call faster operation instead of generic operationGetByVal. baseline patched object-iterate 5.8531+-0.3029 5.7903+-0.2795 might be 1.0108x faster object-iterate-symbols 7.4099+-0.3993 ^ 5.8254+-0.2276 ^ definitely 1.2720x faster * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGOperations.cpp: (JSC::DFG::getByValObject): * dfg/DFGOperations.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetByValForObjectWithString): (JSC::DFG::SpeculativeJIT::compileGetByValForObjectWithSymbol): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal): 2017-09-07 Mark Lam Use JIT probes for DFG OSR exit. https://bugs.webkit.org/show_bug.cgi?id=175144 Reviewed by Saam Barati. This patch does the following: 1. Replaces osrExitGenerationThunkGenerator() with osrExitThunkGenerator(). While osrExitGenerationThunkGenerator() generates a thunk that compiles a unique OSR offramp for each DFG OSR exit site, osrExitThunkGenerator() generates a thunk that just executes the OSR exit. The osrExitThunkGenerator() generated thunk works by using a single JIT probe to call OSRExit::executeOSRExit(). The JIT probe takes care of preserving CPU registers, and providing the Probe::Stack mechanism for modifying the stack frame. OSRExit::executeOSRExit() replaces OSRExit::compileOSRExit() and OSRExit::compileExit(). It is basically a re-write of those functions to execute the OSR exit work instead of compiling code to execute the work. As a result, we get the following savings: a. no more OSR exit ramp compilation time. b. no use of JIT executable memory for storing each unique OSR exit ramp. On the negative side, we incur these costs: c. the OSRExit::executeOSRExit() ramp may be a little slower than the compiled version of the ramp. However, OSR exits are rare. Hence, this small difference should not matter much. It is also offset by the savings from (a). d. the Probe::Stack allocates 1K pages for memory for buffering stack modifcations. The number of these pages depends on the span of stack memory that the OSR exit ramp reads from and writes to. Since the OSR exit ramp tends to only modify values in the current DFG frame and the current VMEntryRecord, the number of pages tends to only be 1 or 2. Using the jsc tests as a workload, the vast majority of tests that do OSR exit, uses 3 or less 1K pages (with the overwhelming number using just 1 page). A few tests that are pathological uses up to 14 pages, and one particularly bad test (function-apply-many-args.js) uses 513 pages. Similar to the old code, the OSR exit ramp still has 2 parts: 1 part that is only executed once to compute some values for the exit site that is used by all exit operations from that site, and a 2nd part to execute the exit. The 1st part is protected by a checking if exit.exitState has already been initialized. The computed values are cached in exit.exitState. Because the OSR exit thunk no longer compiles an OSR exit off-ramp, we no longer need the facility to patch the site that jumps to the OSR exit ramp. The DFG::JITCompiler has been modified to remove this patching code. 2. Fixed the bottom most Probe::Context and Probe::Stack get/set methods to use std::memcpy to avoid strict aliasing issues. Also optimized the implementation of Probe::Stack::physicalAddressFor(). 3. Miscellaneous convenience methods added to make the Probe::Context easier of use. 4. Added a Probe::Frame class that makes it easier to get/set operands and arguments in a given frame using the deferred write properties of the Probe::Stack. Probe::Frame makes it easier to do some of the recovery work in the OSR exit ramp. 5. Cloned or converted some functions needed by the OSR exit ramp. The original JIT versions of these functions are still left in place because they are still needed for FTL OSR exit. A FIXME comment has been added to remove them later. These functions include: DFGOSRExitCompilerCommon.cpp's handleExitCounts() ==> CodeBlock::updateOSRExitCounterAndCheckIfNeedToReoptimize() DFGOSRExitCompilerCommon.cpp's reifyInlinedCallFrames() ==> DFGOSRExit.cpp's reifyInlinedCallFrames() DFGOSRExitCompilerCommon.cpp's adjustAndJumpToTarget() ==> DFGOSRExit.cpp's adjustAndJumpToTarget() MethodOfGettingAValueProfile::emitReportValue() ==> MethodOfGettingAValueProfile::reportValue() DFGOperations.cpp's operationCreateDirectArgumentsDuringExit() ==> DFGOSRExit.cpp's createDirectArgumentsDuringExit() DFGOperations.cpp's operationCreateClonedArgumentsDuringExit() ==> DFGOSRExit.cpp's createClonedArgumentsDuringExit() * JavaScriptCore.xcodeproj/project.pbxproj: * assembler/MacroAssembler.cpp: (JSC::stdFunctionCallback): * assembler/MacroAssemblerPrinter.cpp: (JSC::Printer::printCallback): * assembler/ProbeContext.h: (JSC::Probe::CPUState::gpr const): (JSC::Probe::CPUState::spr const): (JSC::Probe::Context::Context): (JSC::Probe::Context::arg): (JSC::Probe::Context::gpr): (JSC::Probe::Context::spr): (JSC::Probe::Context::fpr): (JSC::Probe::Context::gprName): (JSC::Probe::Context::sprName): (JSC::Probe::Context::fprName): (JSC::Probe::Context::gpr const): (JSC::Probe::Context::spr const): (JSC::Probe::Context::fpr const): (JSC::Probe::Context::pc): (JSC::Probe::Context::fp): (JSC::Probe::Context::sp): (JSC::Probe:: const): Deleted. * assembler/ProbeFrame.h: Added. (JSC::Probe::Frame::Frame): (JSC::Probe::Frame::getArgument): (JSC::Probe::Frame::getOperand): (JSC::Probe::Frame::get): (JSC::Probe::Frame::setArgument): (JSC::Probe::Frame::setOperand): (JSC::Probe::Frame::set): * assembler/ProbeStack.cpp: (JSC::Probe::Page::Page): * assembler/ProbeStack.h: (JSC::Probe::Page::get): (JSC::Probe::Page::set): (JSC::Probe::Page::physicalAddressFor): (JSC::Probe::Stack::lowWatermark): (JSC::Probe::Stack::get): (JSC::Probe::Stack::set): * bytecode/ArithProfile.cpp: * bytecode/ArithProfile.h: * bytecode/ArrayProfile.h: (JSC::ArrayProfile::observeArrayMode): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::updateOSRExitCounterAndCheckIfNeedToReoptimize): * bytecode/CodeBlock.h: (JSC::CodeBlock::addressOfOSRExitCounter): Deleted. * bytecode/ExecutionCounter.h: (JSC::ExecutionCounter::hasCrossedThreshold const): (JSC::ExecutionCounter::setNewThresholdForOSRExit): * bytecode/MethodOfGettingAValueProfile.cpp: (JSC::MethodOfGettingAValueProfile::reportValue): * bytecode/MethodOfGettingAValueProfile.h: * dfg/DFGDriver.cpp: (JSC::DFG::compileImpl): * dfg/DFGJITCode.cpp: (JSC::DFG::JITCode::findPC): Deleted. * dfg/DFGJITCode.h: * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::linkOSRExits): (JSC::DFG::JITCompiler::link): * dfg/DFGOSRExit.cpp: (JSC::DFG::jsValueFor): (JSC::DFG::restoreCalleeSavesFor): (JSC::DFG::saveCalleeSavesFor): (JSC::DFG::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer): (JSC::DFG::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer): (JSC::DFG::saveOrCopyCalleeSavesFor): (JSC::DFG::createDirectArgumentsDuringExit): (JSC::DFG::createClonedArgumentsDuringExit): (JSC::DFG::OSRExit::OSRExit): (JSC::DFG::emitRestoreArguments): (JSC::DFG::OSRExit::executeOSRExit): (JSC::DFG::reifyInlinedCallFrames): (JSC::DFG::adjustAndJumpToTarget): (JSC::DFG::printOSRExit): (JSC::DFG::OSRExit::setPatchableCodeOffset): Deleted. (JSC::DFG::OSRExit::getPatchableCodeOffsetAsJump const): Deleted. (JSC::DFG::OSRExit::codeLocationForRepatch const): Deleted. (JSC::DFG::OSRExit::correctJump): Deleted. (JSC::DFG::OSRExit::emitRestoreArguments): Deleted. (JSC::DFG::OSRExit::compileOSRExit): Deleted. (JSC::DFG::OSRExit::compileExit): Deleted. (JSC::DFG::OSRExit::debugOperationPrintSpeculationFailure): Deleted. * dfg/DFGOSRExit.h: (JSC::DFG::OSRExitState::OSRExitState): (JSC::DFG::OSRExit::considerAddingAsFrequentExitSite): * dfg/DFGOSRExitCompilerCommon.cpp: * dfg/DFGOSRExitCompilerCommon.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGThunks.cpp: (JSC::DFG::osrExitThunkGenerator): (JSC::DFG::osrExitGenerationThunkGenerator): Deleted. * dfg/DFGThunks.h: * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::debugCall): Deleted. * jit/AssemblyHelpers.h: * jit/JITOperations.cpp: * jit/JITOperations.h: * profiler/ProfilerOSRExit.h: (JSC::Profiler::OSRExit::incCount): * runtime/JSCJSValue.h: * runtime/JSCJSValueInlines.h: * runtime/VM.h: 2017-09-07 Michael Saboff Add support for RegExp named capture groups https://bugs.webkit.org/show_bug.cgi?id=176435 Reviewed by Filip Pizlo. Added parsing for both naming a captured parenthesis as well and using a named group in a back reference. Also added support for using named groups with String.prototype.replace(). This patch does not throw Syntax Errors as described in the current spec text for the two cases of malformed back references in String.prototype.replace() as I believe that it is inconsistent with the current semantics for handling of other malformed replacement tokens. I filed an issue for the requested change to the proposed spec and also filed a FIXME bug https://bugs.webkit.org/show_bug.cgi?id=176434. This patch does not implement strength reduction in the optimizing JITs for named capture groups. Filed https://bugs.webkit.org/show_bug.cgi?id=176464. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::handleNode): * runtime/CommonIdentifiers.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::haveABadTime): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::regExpMatchesArrayWithGroupsStructure const): * runtime/RegExp.cpp: (JSC::RegExp::finishCreation): * runtime/RegExp.h: * runtime/RegExpMatchesArray.cpp: (JSC::createStructureImpl): (JSC::createRegExpMatchesArrayWithGroupsStructure): (JSC::createRegExpMatchesArrayWithGroupsSlowPutStructure): * runtime/RegExpMatchesArray.h: (JSC::createRegExpMatchesArray): * runtime/StringPrototype.cpp: (JSC::substituteBackreferencesSlow): (JSC::replaceUsingRegExpSearch): * yarr/YarrParser.h: (JSC::Yarr::Parser::CharacterClassParserDelegate::atomNamedBackReference): (JSC::Yarr::Parser::parseEscape): (JSC::Yarr::Parser::parseParenthesesBegin): (JSC::Yarr::Parser::tryConsumeUnicodeEscape): (JSC::Yarr::Parser::tryConsumeIdentifierCharacter): (JSC::Yarr::Parser::isIdentifierStart): (JSC::Yarr::Parser::isIdentifierPart): (JSC::Yarr::Parser::tryConsumeGroupName): * yarr/YarrPattern.cpp: (JSC::Yarr::YarrPatternConstructor::atomParenthesesSubpatternBegin): (JSC::Yarr::YarrPatternConstructor::atomNamedBackReference): (JSC::Yarr::YarrPattern::errorMessage): * yarr/YarrPattern.h: (JSC::Yarr::YarrPattern::reset): * yarr/YarrSyntaxChecker.cpp: (JSC::Yarr::SyntaxChecker::atomParenthesesSubpatternBegin): (JSC::Yarr::SyntaxChecker::atomNamedBackReference): 2017-09-07 Myles C. Maxfield [PAL] Unify PlatformUserPreferredLanguages.h with Language.h https://bugs.webkit.org/show_bug.cgi?id=176561 Reviewed by Brent Fulgham. * runtime/IntlObject.cpp: (JSC::defaultLocale): 2017-09-07 Joseph Pecoraro Augmented Inspector: Provide a way to inspect a DOM Node (DOM.inspect) https://bugs.webkit.org/show_bug.cgi?id=176563 Reviewed by Matt Baker. * inspector/protocol/DOM.json: Add an event that is useful for augmented inspectors to inspect a node. Web pages will still prefer Inspector.inspect. 2017-09-06 Yusuke Suzuki [JSC] Remove "malloc" and "free" from JSC/API https://bugs.webkit.org/show_bug.cgi?id=176331 Reviewed by Keith Miller. Remove "malloc" and "free" manual calls in JSC/API. * API/JSValue.mm: (createStructHandlerMap): * API/JSWrapperMap.mm: (parsePropertyAttributes): (makeSetterName): (copyPrototypeProperties): Use RetainPtr to keep NSString. We avoid repeated "char*" to "NSString" conversion. * API/ObjcRuntimeExtras.h: (adoptSystem): Add adoptSystem to automate calling system free(). (protocolImplementsProtocol): (forEachProtocolImplementingProtocol): (forEachMethodInClass): (forEachMethodInProtocol): (forEachPropertyInProtocol): (StringRange::StringRange): (StringRange::operator const char* const): (StringRange::get const): Use CString for backend. (StructBuffer::StructBuffer): (StructBuffer::~StructBuffer): (StringRange::~StringRange): Deleted. Use fastAlignedMalloc/astAlignedFree to get aligned memory. 2017-09-06 Mark Lam constructGenericTypedArrayViewWithArguments() is missing an exception check. https://bugs.webkit.org/show_bug.cgi?id=176485 Reviewed by Keith Miller. * runtime/JSGenericTypedArrayViewConstructorInlines.h: (JSC::constructGenericTypedArrayViewWithArguments): 2017-09-06 Saam Barati Air should have a Vector of prologue generators instead of a HashMap representing an optional prologue generator https://bugs.webkit.org/show_bug.cgi?id=176346 Reviewed by Mark Lam. * b3/B3Procedure.cpp: (JSC::B3::Procedure::Procedure): (JSC::B3::Procedure::setNumEntrypoints): * b3/B3Procedure.h: (JSC::B3::Procedure::setNumEntrypoints): Deleted. * b3/air/AirCode.cpp: (JSC::B3::Air::defaultPrologueGenerator): (JSC::B3::Air::Code::Code): (JSC::B3::Air::Code::setNumEntrypoints): * b3/air/AirCode.h: (JSC::B3::Air::Code::setPrologueForEntrypoint): (JSC::B3::Air::Code::prologueGeneratorForEntrypoint): (JSC::B3::Air::Code::setEntrypoints): (JSC::B3::Air::Code::setEntrypointLabels): * b3/air/AirGenerate.cpp: (JSC::B3::Air::generate): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::lower): 2017-09-06 Saam Barati ASSERTION FAILED: op() == CheckStructure in Source/JavaScriptCore/dfg/DFGNode.h(443) https://bugs.webkit.org/show_bug.cgi?id=176470 Reviewed by Mark Lam. Update Node::convertToCheckStructureImmediate's assertion to allow the node to either be a CheckStructure or CheckStructureOrEmpty. * dfg/DFGNode.h: (JSC::DFG::Node::convertToCheckStructureImmediate): 2017-09-05 Saam Barati isNotCellSpeculation is wrong with respect to SpecEmpty https://bugs.webkit.org/show_bug.cgi?id=176429 Reviewed by Michael Saboff. The isNotCellSpeculation(SpeculatedType t) function was not taking into account SpecEmpty in the set for t. It should return false when SpecEmpty is present, since the empty value will fail a NotCell check. This bug would cause us to erroneously generate NotCellUse UseKinds for inputs that are the empty value, causing repeated OSR exits. * bytecode/SpeculatedType.h: (JSC::isNotCellSpeculation): 2017-09-05 Saam Barati Make the distinction between entrypoints and CFG roots more clear by naming things better https://bugs.webkit.org/show_bug.cgi?id=176336 Reviewed by Mark Lam and Keith Miller and Michael Saboff. This patch does renaming to make the distinction between Graph::m_entrypoints and Graph::m_numberOfEntrypoints more clear. The source of confusion is that Graph::m_entrypoints.size() is not equivalent to Graph::m_numberOfEntrypoints. Graph::m_entrypoints is really just the CFG roots. In CPS, this vector has size >= 1. In SSA, the size is always 1. This patch renames Graph::m_entrypoints to Graph::m_roots. To be consistent, this patch also renames Graph's m_entrypointToArguments field to m_rootToArguments. Graph::m_numberOfEntrypoints retains its name. This field is only used in SSA when compiling with EntrySwitch. It represents the logical number of entrypoints the compilation will end up with. Each EntrySwitch has m_numberOfEntrypoints cases. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::parseCodeBlock): * dfg/DFGCFG.h: (JSC::DFG::CFG::roots): (JSC::DFG::CPSCFG::CPSCFG): * dfg/DFGCPSRethreadingPhase.cpp: (JSC::DFG::CPSRethreadingPhase::specialCaseArguments): * dfg/DFGDCEPhase.cpp: (JSC::DFG::DCEPhase::run): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): (JSC::DFG::Graph::determineReachability): (JSC::DFG::Graph::blocksInPreOrder): (JSC::DFG::Graph::blocksInPostOrder): (JSC::DFG::Graph::methodOfGettingAValueProfileFor): * dfg/DFGGraph.h: (JSC::DFG::Graph::isRoot): (JSC::DFG::Graph::isEntrypoint): Deleted. * dfg/DFGInPlaceAbstractState.cpp: (JSC::DFG::InPlaceAbstractState::initialize): * dfg/DFGLoopPreHeaderCreationPhase.cpp: (JSC::DFG::createPreHeader): * dfg/DFGMaximalFlushInsertionPhase.cpp: (JSC::DFG::MaximalFlushInsertionPhase::run): (JSC::DFG::MaximalFlushInsertionPhase::treatRegularBlock): * dfg/DFGOSREntrypointCreationPhase.cpp: (JSC::DFG::OSREntrypointCreationPhase::run): * dfg/DFGPredictionInjectionPhase.cpp: (JSC::DFG::PredictionInjectionPhase::run): * dfg/DFGSSAConversionPhase.cpp: (JSC::DFG::SSAConversionPhase::run): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::checkArgumentTypes): (JSC::DFG::SpeculativeJIT::linkOSREntries): * dfg/DFGTypeCheckHoistingPhase.cpp: (JSC::DFG::TypeCheckHoistingPhase::run): * dfg/DFGValidate.cpp: 2017-09-05 Joseph Pecoraro test262: Completion values for control flow do not match the spec https://bugs.webkit.org/show_bug.cgi?id=171265 Reviewed by Saam Barati. * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::shouldBeConcernedWithCompletionValue): When we care about having proper completion values (global code in programs, modules, and eval) insert undefined results for control flow statements. * bytecompiler/NodesCodegen.cpp: (JSC::SourceElements::emitBytecode): Reduce writing a default `undefined` value to the completion result to only once before the last statement we know will produce a value. (JSC::IfElseNode::emitBytecode): (JSC::WithNode::emitBytecode): (JSC::WhileNode::emitBytecode): (JSC::ForNode::emitBytecode): (JSC::ForInNode::emitBytecode): (JSC::ForOfNode::emitBytecode): (JSC::SwitchNode::emitBytecode): Insert an undefined to handle cases where code may break out of an if/else or with statement (break/continue). (JSC::TryNode::emitBytecode): Same handling for break cases. Also, finally block statement completion values are always ignored for the try statement result. (JSC::ClassDeclNode::emitBytecode): Class declarations, like function declarations, produce an empty result. * parser/Nodes.cpp: (JSC::SourceElements::lastStatement): (JSC::SourceElements::hasCompletionValue): (JSC::SourceElements::hasEarlyBreakOrContinue): (JSC::BlockNode::lastStatement): (JSC::BlockNode::singleStatement): (JSC::BlockNode::hasCompletionValue): (JSC::BlockNode::hasEarlyBreakOrContinue): (JSC::ScopeNode::singleStatement): (JSC::ScopeNode::hasCompletionValue): (JSC::ScopeNode::hasEarlyBreakOrContinue): The only non-trivial cases need to loop through their list of statements to determine if this has a completion value or not. Likewise for determining if there is an early break / continue, meaning a break or continue statement with no preceding statement that has a completion value. * parser/Nodes.h: (JSC::StatementNode::next): (JSC::StatementNode::hasCompletionValue): Helper to check if a statement nodes produces a completion value or not. 2017-09-04 Saam Barati typeCheckHoistingPhase may emit a CheckStructure on the empty value which leads to a dereference of zero on 64 bit platforms https://bugs.webkit.org/show_bug.cgi?id=176317 Reviewed by Keith Miller. It turns out that TypeCheckHoistingPhase may hoist a CheckStructure up to the SetLocal of a particular value where the value is the empty JSValue. On 64-bit platforms, the empty value is zero. This means that the empty value passes a cell check. This will lead to a crash when we dereference null to load the value's structure. This patch teaches TypeCheckHoistingPhase to be conservative in the structure checks it hoists. On 64-bit platforms, instead of emitting a CheckStructure node, we now emit a CheckStructureOrEmpty node. This node allows the empty value to flow through. If the value isn't empty, it'll perform the normal structure check that CheckStructure performs. For now, we only emit CheckStructureOrEmpty on 64-bit platforms since a cell check on 32-bit platforms does not allow the empty value to flow through. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGArgumentsEliminationPhase.cpp: * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNode.h: (JSC::DFG::Node::convertCheckStructureOrEmptyToCheckStructure): (JSC::DFG::Node::hasStructureSet): * dfg/DFGNodeType.h: * dfg/DFGObjectAllocationSinkingPhase.cpp: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::SafeToExecuteEdge::SafeToExecuteEdge): (JSC::DFG::SafeToExecuteEdge::operator()): (JSC::DFG::SafeToExecuteEdge::maySeeEmptyChild): (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::emitStructureCheck): (JSC::DFG::SpeculativeJIT::compileCheckStructure): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGTypeCheckHoistingPhase.cpp: (JSC::DFG::TypeCheckHoistingPhase::run): * dfg/DFGValidate.cpp: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileCheckStructureOrEmpty): 2017-09-04 Saam Barati Support compiling catch in the FTL https://bugs.webkit.org/show_bug.cgi?id=175396 Reviewed by Filip Pizlo. This patch implements op_catch in the FTL. It extends the DFG implementation by supporting multiple entrypoints in DFG-SSA. This patch implements this by introducing an EntrySwitch node. When converting to SSA, we introduce a new root block with an EntrySwitch that has the previous DFG entrypoints as its successors. By convention, we pick the zeroth entry point index to be the op_enter entrypoint. Like in B3, in DFG-SSA, EntrySwitch just acts like a switch over the entrypoint index argument. DFG::EntrySwitch in the FTL simply lowers to B3::EntrySwitch. The EntrySwitch in the root block that SSAConversion creates can not exit because we would both not know where to exit to in the program: we would not have valid OSR exit state. This design also mandates that anything we hoist above EntrySwitch in the new root block can not exit since they also do not have valid OSR exit state. This patch also adds a new metadata node named InitializeEntrypointArguments. InitializeEntrypointArguments is a metadata node that initializes the flush format for the arguments at a given entrypoint. For a given entrypoint index, this node tells AI and OSRAvailabilityAnalysis what the flush format for each argument is. This allows each individual entrypoint to have an independent set of argument types. Currently, this won't happen in practice because ArgumentPosition unifies flush formats, but this is an implementation detail we probably want to modify in the future. SSAConversion will add InitializeEntrypointArguments to the beginning of each of the original DFG entrypoint blocks. This patch also adds the ability to specify custom prologue code generators in Air. This allows the FTL to specify a custom prologue for catch entrypoints that matches the op_catch OSR entry calling convention that the DFG uses. This way, the baseline JIT code OSR enters into op_catch the same way both in the DFG and the FTL. In the future, we can use this same mechanism to perform stack overflow checks instead of using a patchpoint. * b3/air/AirCode.cpp: (JSC::B3::Air::Code::isEntrypoint): (JSC::B3::Air::Code::entrypointIndex): * b3/air/AirCode.h: (JSC::B3::Air::Code::setPrologueForEntrypoint): (JSC::B3::Air::Code::prologueGeneratorForEntrypoint): * b3/air/AirGenerate.cpp: (JSC::B3::Air::generate): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGBasicBlock.h: * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::parse): * dfg/DFGCFG.h: (JSC::DFG::selectCFG): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGClobbersExitState.cpp: (JSC::DFG::clobbersExitState): * dfg/DFGCommonData.cpp: (JSC::DFG::CommonData::shrinkToFit): (JSC::DFG::CommonData::finalizeCatchEntrypoints): * dfg/DFGCommonData.h: (JSC::DFG::CommonData::catchOSREntryDataForBytecodeIndex): (JSC::DFG::CommonData::appendCatchEntrypoint): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): (JSC::DFG::Graph::invalidateCFG): (JSC::DFG::Graph::ensureCPSCFG): (JSC::DFG::Graph::methodOfGettingAValueProfileFor): * dfg/DFGGraph.h: (JSC::DFG::Graph::isEntrypoint): * dfg/DFGInPlaceAbstractState.cpp: (JSC::DFG::InPlaceAbstractState::initialize): (JSC::DFG::InPlaceAbstractState::mergeToSuccessors): * dfg/DFGJITCode.cpp: (JSC::DFG::JITCode::shrinkToFit): (JSC::DFG::JITCode::finalizeOSREntrypoints): * dfg/DFGJITCode.h: (JSC::DFG::JITCode::catchOSREntryDataForBytecodeIndex): Deleted. (JSC::DFG::JITCode::appendCatchEntrypoint): Deleted. * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::noticeCatchEntrypoint): (JSC::DFG::JITCompiler::makeCatchOSREntryBuffer): * dfg/DFGMayExit.cpp: * dfg/DFGNode.h: (JSC::DFG::Node::isEntrySwitch): (JSC::DFG::Node::isTerminal): (JSC::DFG::Node::entrySwitchData): (JSC::DFG::Node::numSuccessors): (JSC::DFG::Node::successor): (JSC::DFG::Node::entrypointIndex): * dfg/DFGNodeType.h: * dfg/DFGOSRAvailabilityAnalysisPhase.cpp: (JSC::DFG::OSRAvailabilityAnalysisPhase::run): (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode): * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareCatchOSREntry): * dfg/DFGOSREntry.h: * dfg/DFGOSREntrypointCreationPhase.cpp: (JSC::DFG::OSREntrypointCreationPhase::run): * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSSAConversionPhase.cpp: (JSC::DFG::SSAConversionPhase::SSAConversionPhase): (JSC::DFG::SSAConversionPhase::run): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::linkOSREntries): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStaticExecutionCountEstimationPhase.cpp: (JSC::DFG::StaticExecutionCountEstimationPhase::run): * dfg/DFGValidate.cpp: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::lower): (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileExtractCatchLocal): (JSC::FTL::DFG::LowerDFGToB3::compileGetStack): (JSC::FTL::DFG::LowerDFGToB3::compileEntrySwitch): (JSC::FTL::DFG::LowerDFGToB3::speculate): (JSC::FTL::DFG::LowerDFGToB3::appendOSRExitDescriptor): (JSC::FTL::DFG::LowerDFGToB3::appendOSRExit): (JSC::FTL::DFG::LowerDFGToB3::blessSpeculation): * ftl/FTLOutput.cpp: (JSC::FTL::Output::entrySwitch): * ftl/FTLOutput.h: * jit/JITOperations.cpp: 2017-09-03 Yusuke Suzuki [DFG][FTL] Efficiently execute number#toString() https://bugs.webkit.org/show_bug.cgi?id=170007 Reviewed by Keith Miller. In JS, the natural way to convert number to string with radix is `number.toString(radix)`. However, our IC only cares about cells. If the base value is a number, it always goes to the slow path. While extending our IC for number and boolean, the most meaningful use of this IC is calling `number.toString(radix)`. So, in this patch, we first add a fast path for this in DFG by using watchpoint. We set up a watchpoint for Number.prototype.toString. And if this watchpoint is kept alive and GetById(base, "toString")'s base should be speculated as Number, we emit Number related Checks and convert GetById to Number.prototype.toString constant. It removes costly GetById slow path, and makes it non-clobbering node (JSConstant). In addition, we add NumberToStringWithValidRadixConstant node. We have NumberToStringWithRadix node, but it may throw an error if the valid value is incorrect (for example, number.toString(2000)). So its clobbering rule is conservatively use read(World)/write(Heap). But in reality, `number.toString` is mostly called with the constant radix, and we can easily figure out this radix is valid (2 <= radix && radix < 32). We add a rule to the constant folding phase to convert NumberToStringWithRadix to NumberToStringWithValidRadixConstant. It ensures that it has valid constant radix. And we relax our clobbering rule for NumberToStringWithValidRadixConstant. Added microbenchmarks show performance improvement. baseline patched number-to-string-with-radix-cse 43.8312+-1.3017 ^ 7.4930+-0.5105 ^ definitely 5.8496x faster number-to-string-with-radix-10 7.2775+-0.5225 ^ 2.1906+-0.1864 ^ definitely 3.3222x faster number-to-string-with-radix 39.7378+-1.4921 ^ 16.6137+-0.7776 ^ definitely 2.3919x faster number-to-string-strength-reduction 94.9667+-2.7157 ^ 9.3060+-0.7202 ^ definitely 10.2049x faster * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.h: (JSC::DFG::Graph::isWatchingGlobalObjectWatchpoint): (JSC::DFG::Graph::isWatchingArrayIteratorProtocolWatchpoint): (JSC::DFG::Graph::isWatchingNumberToStringWatchpoint): * dfg/DFGNode.h: (JSC::DFG::Node::convertToNumberToStringWithValidRadixConstant): (JSC::DFG::Node::hasValidRadixConstant): (JSC::DFG::Node::validRadixConstant): * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructor): (JSC::DFG::SpeculativeJIT::compileNumberToStringWithValidRadixConstant): (JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOnNumber): Deleted. * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::handleNode): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileNumberToStringWithValidRadixConstant): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::JSGlobalObject): (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildren): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::numberToStringWatchpoint): (JSC::JSGlobalObject::numberProtoToStringFunction const): * runtime/NumberPrototype.cpp: (JSC::NumberPrototype::finishCreation): (JSC::toStringWithRadixInternal): (JSC::toStringWithRadix): (JSC::int32ToStringInternal): (JSC::numberToStringInternal): * runtime/NumberPrototype.h: 2017-09-04 Yusuke Suzuki [DFG] Consider increasing the number of DFG worklist threads https://bugs.webkit.org/show_bug.cgi?id=176222 Reviewed by Saam Barati. Attempt to add one more thread to DFG worklist. DFG compiler sometimes takes very long time if the target function is very large. However, DFG worklist has only one thread before this patch. Therefore, one function that takes too much time to be compiled can prevent the other functions from being compiled in DFG or upper tiers. One example is Octane/zlib. In zlib, compiling "a1" function in DFG takes super long time (447 ms) because of its super large size of the function. While this function never gets compiled in FTL due to its large size, it can be compiled in DFG and takes super long time. Subsequent "a8" function compilation in DFG is blocked by this "a1". As a consequence, the benchmark takes very long time in a1/Baseline code, which is slower than DFG of course. While FTL has a bit more threads, DFG worklist has only one thread. This patch adds one more thread to DFG worklist to alleviate the above situation. This change significantly improves Octane/zlib performance. baseline patched zlib x2 482.32825+-6.07640 ^ 408.66072+-14.03856 ^ definitely 1.1803x faster * runtime/Options.h: 2017-09-04 Sam Weinig [WebIDL] Unify and simplify EnableBySettings with the rest of the runtime settings https://bugs.webkit.org/show_bug.cgi?id=176312 Reviewed by Darin Adler. * runtime/CommonIdentifiers.h: Remove WebCore specific identifiers from CommonIdentifiers. They have been moved to WebCoreBuiltinNames in WebCore. 2017-09-03 Yusuke Suzuki Remove "malloc" and "free" use https://bugs.webkit.org/show_bug.cgi?id=176310 Reviewed by Darin Adler. Use Vector instead. * API/JSWrapperMap.mm: (selectorToPropertyName): 2017-09-03 Darin Adler Try to fix Windows build. * runtime/JSGlobalObjectFunctions.cpp: #include . 2017-09-03 Yusuke Suzuki [WTF] Add C++03 allocator interface for GCC < 6 https://bugs.webkit.org/show_bug.cgi?id=176301 Reviewed by Darin Adler. * dfg/DFGObjectAllocationSinkingPhase.cpp: 2017-09-03 Chris Dumez Unreviewed, rolling out r221555. Did not fix Windows build Reverted changeset: "Unreviewed attempt to fix Windows build." http://trac.webkit.org/changeset/221555 2017-09-03 Chris Dumez Unreviewed attempt to fix Windows build. * runtime/JSGlobalObjectFunctions.cpp: 2017-09-03 Chris Dumez Unreviewed, rolling out r221552. Broke the build Reverted changeset: "[WTF] Add C++03 allocator interface for GCC < 6" https://bugs.webkit.org/show_bug.cgi?id=176301 http://trac.webkit.org/changeset/221552 2017-09-03 Yusuke Suzuki [WTF] Add C++03 allocator interface for GCC < 6 https://bugs.webkit.org/show_bug.cgi?id=176301 Reviewed by Darin Adler. * dfg/DFGObjectAllocationSinkingPhase.cpp: 2017-09-03 Yusuke Suzuki [JSC] Clean up BytecodeLivenessAnalysis https://bugs.webkit.org/show_bug.cgi?id=176295 Reviewed by Saam Barati. Previously, computeDefsForBytecodeOffset was a bit customizable. This is used for try-catch handler's liveness analysis. But after careful generatorification implementation, it is now not necessary. This patch drops this customizability. * bytecode/BytecodeGeneratorification.cpp: (JSC::GeneratorLivenessAnalysis::computeDefsForBytecodeOffset): Deleted. (JSC::GeneratorLivenessAnalysis::computeUsesForBytecodeOffset): Deleted. * bytecode/BytecodeLivenessAnalysis.cpp: (JSC::BytecodeLivenessAnalysis::computeKills): (JSC::BytecodeLivenessAnalysis::computeDefsForBytecodeOffset): Deleted. (JSC::BytecodeLivenessAnalysis::computeUsesForBytecodeOffset): Deleted. * bytecode/BytecodeLivenessAnalysis.h: * bytecode/BytecodeLivenessAnalysisInlines.h: (JSC::BytecodeLivenessPropagation::stepOverInstruction): (JSC::BytecodeLivenessPropagation::computeLocalLivenessForBytecodeOffset): (JSC::BytecodeLivenessPropagation::computeLocalLivenessForBlock): (JSC::BytecodeLivenessPropagation::getLivenessInfoAtBytecodeOffset): (JSC::BytecodeLivenessPropagation::runLivenessFixpoint): (JSC::BytecodeLivenessPropagation::stepOverInstruction): Deleted. (JSC::BytecodeLivenessPropagation::computeLocalLivenessForBytecodeOffset): Deleted. (JSC::BytecodeLivenessPropagation::computeLocalLivenessForBlock): Deleted. (JSC::BytecodeLivenessPropagation::getLivenessInfoAtBytecodeOffset): Deleted. (JSC::BytecodeLivenessPropagation::runLivenessFixpoint): Deleted. 2017-09-03 Sam Weinig Remove CanvasProxy https://bugs.webkit.org/show_bug.cgi?id=176288 Reviewed by Yusuke Suzuki. CanvasProxy does not appear to be in any current HTML spec and was disabled and unimplemented in our tree. Time to get rid of it. * Configurations/FeatureDefines.xcconfig: 2017-09-02 Oliver Hunt Need an API to get the global context from JSObjectRef https://bugs.webkit.org/show_bug.cgi?id=176291 Reviewed by Saam Barati. Very simple additional API, starting off as SPI on principle. * API/JSObjectRef.cpp: (JSObjectGetGlobalContext): * API/JSObjectRefPrivate.h: * API/tests/testapi.c: (main): 2017-09-02 Yusuke Suzuki [DFG] Relax arity requirement https://bugs.webkit.org/show_bug.cgi?id=175523 Reviewed by Saam Barati. Our DFG pipeline gives up inlining when the arity of the target function is more than the number of the arguments. It effectively prevents us from inlining and optimizing functions, which takes some optional arguments in the form of the pre-ES6. This patch removes the above restriction by performing the arity fixup in DFG. SixSpeed shows improvement when we can inline arity-mismatched functions. (For example, calling generator.next()). baseline patched defaults.es5 1232.1226+-20.6775 ^ 442.3326+-26.1883 ^ definitely 2.7855x faster rest.es6 5.3406+-0.8588 ^ 3.5812+-0.5388 ^ definitely 1.4913x faster spread-generator.es6 320.9107+-12.4808 310.4295+-12.0047 might be 1.0338x faster generator.es6 318.3514+-9.6023 ^ 286.4974+-12.6203 ^ definitely 1.1112x faster * bytecode/InlineCallFrame.cpp: (JSC::InlineCallFrame::dumpInContext const): * bytecode/InlineCallFrame.h: (JSC::InlineCallFrame::InlineCallFrame): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGArgumentsEliminationPhase.cpp: * dfg/DFGArgumentsUtilities.cpp: (JSC::DFG::argumentsInvolveStackSlot): (JSC::DFG::emitCodeToGetArgumentsArrayLength): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::setLocal): (JSC::DFG::ByteCodeParser::setArgument): (JSC::DFG::ByteCodeParser::findArgumentPositionForLocal): (JSC::DFG::ByteCodeParser::flush): (JSC::DFG::ByteCodeParser::getArgumentCount): (JSC::DFG::ByteCodeParser::inliningCost): (JSC::DFG::ByteCodeParser::inlineCall): (JSC::DFG::ByteCodeParser::attemptToInlineCall): (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): * dfg/DFGCommonData.cpp: (JSC::DFG::CommonData::validateReferences): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::isLiveInBytecode): * dfg/DFGGraph.h: (JSC::DFG::Graph::forAllLocalsLiveInBytecode): * dfg/DFGOSRAvailabilityAnalysisPhase.cpp: (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode): * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::emitRestoreArguments): * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::reifyInlinedCallFrames): * dfg/DFGPreciseLocalClobberize.h: (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::emitGetLength): (JSC::DFG::SpeculativeJIT::compileCreateDirectArguments): * dfg/DFGStackLayoutPhase.cpp: (JSC::DFG::StackLayoutPhase::run): * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileGetMyArgumentByVal): (JSC::FTL::DFG::LowerDFGToB3::getArgumentsLength): * ftl/FTLOperations.cpp: (JSC::FTL::operationMaterializeObjectInOSR): * interpreter/StackVisitor.cpp: (JSC::StackVisitor::readInlinedFrame): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::argumentsStart): * jit/SetupVarargsFrame.cpp: (JSC::emitSetupVarargsFrameFastCase): * runtime/ClonedArguments.cpp: (JSC::ClonedArguments::createWithInlineFrame): * runtime/CommonSlowPaths.h: (JSC::CommonSlowPaths::numberOfExtraSlots): (JSC::CommonSlowPaths::numberOfStackPaddingSlots): (JSC::CommonSlowPaths::numberOfStackPaddingSlotsWithExtraSlots): (JSC::CommonSlowPaths::arityCheckFor): * runtime/StackAlignment.h: (JSC::stackAlignmentBytes): (JSC::stackAlignmentRegisters): 2017-09-01 Yusuke Suzuki [FTL] FTL allocation for async Function is incorrect https://bugs.webkit.org/show_bug.cgi?id=176214 Reviewed by Saam Barati. In FTL, allocating async function / async generator function was incorrectly using JSFunction logic. While it is not observable right now since sizeof(JSFunction) == sizeof(JSAsyncFunction), but it is a bug. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction): 2017-08-31 Yusuke Suzuki [JSC] Fix "name" and "length" of Proxy revoke function https://bugs.webkit.org/show_bug.cgi?id=176155 Reviewed by Mark Lam. ProxyRevoke's length should be configurable. And it does not have its own name. We add NameVisibility enum to InternalFunction to control visibility of the name. * runtime/InternalFunction.cpp: (JSC::InternalFunction::finishCreation): * runtime/InternalFunction.h: * runtime/ProxyRevoke.cpp: (JSC::ProxyRevoke::finishCreation): 2017-08-31 Saam Barati Throwing an exception in the DFG/FTL should not cause a jettison https://bugs.webkit.org/show_bug.cgi?id=176060 Reviewed by Keith Miller. Throwing an exception is not something that should be a jettison-able OSR exit. We used to count Throw/ThrowStaticError towards our OSR exit counts which could cause a CodeBlock to jettison and recompile. This was dumb. Throwing an exception is not a reason to jettison and recompile in the way that a speculation failure is. This patch treats Throw/ThrowStaticError as true terminals in DFG IR. * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGInPlaceAbstractState.cpp: (JSC::DFG::InPlaceAbstractState::mergeToSuccessors): * dfg/DFGNode.h: (JSC::DFG::Node::isTerminal): (JSC::DFG::Node::isPseudoTerminal): (JSC::DFG::Node::errorType): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileThrow): (JSC::DFG::SpeculativeJIT::compileThrowStaticError): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileThrow): (JSC::FTL::DFG::LowerDFGToB3::compileThrowStaticError): * jit/JITOperations.h: 2017-08-31 Saam Barati Graph::methodOfGettingAValueProfileFor compares NodeOrigin instead of the semantic CodeOrigin https://bugs.webkit.org/show_bug.cgi?id=176206 Reviewed by Keith Miller. Mark fixed the main issue in Graph::methodOfGettingAValueProfileFor in r208560 when he fixed it from overwriting invalid parts of the ArithProfile when the currentNode and the operandNode are from the same bytecode. However, the mechanism used to determine same bytecode was comparing NodeOrigin. That's slightly wrong. We need to compare semantic origin, since two NodeOrigins can have the same semantic origin, but differ only in exitOK. For example, in the below IR, the DoubleRep and the Phi have the same semantic origin, but different NodeOrigins. 43 Phi(JS|PureInt, NonBoolInt32|NonIntAsdouble, W:SideState, bc#63, ExitInvalid) 58 ExitOK(MustGen, W:SideState, bc#63) 51 DoubleRep(Check:Number:Kill:@43, Double|PureInt, BytecodeDouble, Exits, bc#63) 54 ArithNegate(DoubleRep:Kill:@51, Double|UseAsOther|MayHaveDoubleResult, AnyIntAsDouble|NonIntAsdouble, NotSet, Exits, bc#63) * dfg/DFGGraph.cpp: (JSC::DFG::Graph::methodOfGettingAValueProfileFor): 2017-08-31 Don Olmstead [CMake] Make USE_CF conditional within Windows https://bugs.webkit.org/show_bug.cgi?id=176173 Reviewed by Alex Christensen. * PlatformWin.cmake: 2017-08-31 Saam Barati useSeparatedWXHeap should never be true when not on iOS https://bugs.webkit.org/show_bug.cgi?id=176190 Reviewed by JF Bastien. If you set useSeparatedWXHeap to true on X86_64, and launch the jsc shell, the process insta-crashes. Let's silently ignore that option and set it to false when not on iOS. * runtime/Options.cpp: (JSC::recomputeDependentOptions): 2017-08-31 Filip Pizlo Fix debug crashes. Rubber stamped by Mark Lam. * runtime/JSArrayBufferView.cpp: (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext): 2017-08-31 Filip Pizlo All of the different ArrayBuffer::data's should be CagedPtr<> https://bugs.webkit.org/show_bug.cgi?id=175515 Reviewed by Michael Saboff. This straightforwardly implements what the title says. * runtime/ArrayBuffer.cpp: (JSC::SharedArrayBufferContents::~SharedArrayBufferContents): (JSC::ArrayBufferContents::destroy): (JSC::ArrayBufferContents::tryAllocate): (JSC::ArrayBufferContents::makeShared): (JSC::ArrayBufferContents::copyTo): (JSC::ArrayBuffer::createFromBytes): (JSC::ArrayBuffer::transferTo): * runtime/ArrayBuffer.h: (JSC::SharedArrayBufferContents::data const): (JSC::ArrayBufferContents::data const): (JSC::ArrayBuffer::data): (JSC::ArrayBuffer::data const): * runtime/ArrayBufferView.h: (JSC::ArrayBufferView::baseAddress const): * runtime/CagedBarrierPtr.h: Added a specialization so that CagedBarrierPtr is valid. * runtime/DataView.h: (JSC::DataView::get): (JSC::DataView::set): * runtime/JSArrayBufferView.cpp: (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext): * runtime/JSArrayBufferView.h: (JSC::JSArrayBufferView::ConstructionContext::vector const): (JSC::JSArrayBufferView::vector const): * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::visitChildren): 2017-08-22 Filip Pizlo Strings need to be in some kind of gigacage https://bugs.webkit.org/show_bug.cgi?id=174924 Reviewed by Oliver Hunt. * runtime/JSString.cpp: (JSC::JSRopeString::resolveRopeToAtomicString const): (JSC::JSRopeString::resolveRope const): * runtime/JSString.h: (JSC::JSString::create): (JSC::JSString::createHasOtherOwner): * runtime/JSStringBuilder.h: * runtime/VM.h: (JSC::VM::gigacageAuxiliarySpace): 2017-08-31 Yusuke Suzuki [JSC] Use reifying system for "name" property of builtin JSFunction https://bugs.webkit.org/show_bug.cgi?id=175260 Reviewed by Saam Barati. Currently builtin JSFunction uses direct property for "name", which is different from usual JSFunction. Usual JSFunction uses reifying system for "name". We would like to apply this reifying mechanism to builtin JSFunction to simplify code and drop JSFunction::createBuiltinFunction. We would like to store the "correct" name in FunctionExecutable. For example, we would like to store the name like "get [Symbol.species]" to FunctionExecutable instead of specifying name when creating JSFunction. To do so, we add a new annotations, @getter and @overriddenName. When @getter is specified, the name of the function becomes "get xxx". And when @overriddenName="xxx" is specified, the name of the function becomes "xxx". We also treat @xxx as anonymous builtin functions that cannot be achieved in the current JS without privilege. * Scripts/builtins/builtins_generate_combined_header.py: (generate_section_for_code_table_macro): * Scripts/builtins/builtins_generate_combined_implementation.py: (BuiltinsCombinedImplementationGenerator.generate_secondary_header_includes): * Scripts/builtins/builtins_generate_separate_header.py: (generate_section_for_code_table_macro): * Scripts/builtins/builtins_generate_separate_implementation.py: (BuiltinsSeparateImplementationGenerator.generate_secondary_header_includes): * Scripts/builtins/builtins_model.py: (BuiltinFunction.__init__): (BuiltinFunction.fromString): * Scripts/builtins/builtins_templates.py: * Scripts/tests/builtins/JavaScriptCore-Builtin.prototype-Combined.js: (overriddenName.string_appeared_here.match): (intrinsic.RegExpTestIntrinsic.test): * Scripts/tests/builtins/JavaScriptCore-Builtin.prototype-Separate.js: (overriddenName.string_appeared_here.match): (intrinsic.RegExpTestIntrinsic.test): * 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: * builtins/AsyncIteratorPrototype.js: (symbolAsyncIteratorGetter): Deleted. * builtins/BuiltinExecutables.cpp: (JSC::BuiltinExecutables::BuiltinExecutables): * builtins/BuiltinExecutables.h: * builtins/BuiltinNames.h: * builtins/FunctionPrototype.js: (symbolHasInstance): Deleted. * builtins/GlobalOperations.js: (globalPrivate.speciesGetter): Deleted. * builtins/IteratorPrototype.js: (symbolIteratorGetter): Deleted. * builtins/PromiseConstructor.js: (all.newResolveElement.return.resolve): (all.newResolveElement): (all): * builtins/PromiseOperations.js: (globalPrivate.newPromiseCapability.executor): (globalPrivate.newPromiseCapability): (globalPrivate.createResolvingFunctions.resolve): (globalPrivate.createResolvingFunctions.reject): (globalPrivate.createResolvingFunctions): * builtins/RegExpPrototype.js: (match): Deleted. (replace): Deleted. (search): Deleted. (split): Deleted. * jsc.cpp: (functionCreateBuiltin): * runtime/AsyncIteratorPrototype.cpp: (JSC::AsyncIteratorPrototype::finishCreation): * runtime/FunctionPrototype.cpp: (JSC::FunctionPrototype::addFunctionProperties): * runtime/IteratorPrototype.cpp: (JSC::IteratorPrototype::finishCreation): * runtime/JSFunction.cpp: (JSC::JSFunction::finishCreation): (JSC::JSFunction::getOwnNonIndexPropertyNames): (JSC::JSFunction::reifyLazyBoundNameIfNeeded): (JSC::JSFunction::createBuiltinFunction): Deleted. * runtime/JSFunction.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/JSObject.cpp: (JSC::JSObject::putDirectBuiltinFunction): (JSC::JSObject::putDirectBuiltinFunctionWithoutTransition): * runtime/JSTypedArrayViewPrototype.cpp: (JSC::JSTypedArrayViewPrototype::finishCreation): * runtime/Lookup.cpp: (JSC::reifyStaticAccessor): * runtime/MapPrototype.cpp: (JSC::MapPrototype::finishCreation): * runtime/RegExpPrototype.cpp: (JSC::RegExpPrototype::finishCreation): * runtime/SetPrototype.cpp: (JSC::SetPrototype::finishCreation): 2017-08-30 Ryan Haddad Unreviewed, rolling out r221327. This change caused test262 failures. Reverted changeset: "[JSC] Use reifying system for "name" property of builtin JSFunction" https://bugs.webkit.org/show_bug.cgi?id=175260 http://trac.webkit.org/changeset/221327 2017-08-30 Matt Lewis Unreviewed, rolling out r221384. This patch caused multiple 32-bit JSC test failures. Reverted changeset: "Strings need to be in some kind of gigacage" https://bugs.webkit.org/show_bug.cgi?id=174924 http://trac.webkit.org/changeset/221384 2017-08-30 Saam Barati semicolon is being interpreted as an = in the LiteralParser https://bugs.webkit.org/show_bug.cgi?id=176114 Reviewed by Oliver Hunt. When lexing a semicolon in the LiteralParser, we were properly setting the TokenType on the current token, however, we were *returning* the wrong TokenType. The lex function both returns the TokenType and sets it on the current token. Semicolon was setting the TokenType to semicolon, but returning the TokenType for '='. This caused programs like `x;123` to be interpreted as `x=123`. * runtime/LiteralParser.cpp: (JSC::LiteralParser::Lexer::lex): (JSC::LiteralParser::Lexer::next): 2017-08-22 Filip Pizlo Strings need to be in some kind of gigacage https://bugs.webkit.org/show_bug.cgi?id=174924 Reviewed by Oliver Hunt. * runtime/JSString.cpp: (JSC::JSRopeString::resolveRopeToAtomicString const): (JSC::JSRopeString::resolveRope const): * runtime/JSString.h: (JSC::JSString::create): (JSC::JSString::createHasOtherOwner): * runtime/JSStringBuilder.h: * runtime/VM.h: (JSC::VM::gigacageAuxiliarySpace): 2017-08-30 Oleksandr Skachkov [ESNext] Async iteration - Implement async iteration statement: for-await-of https://bugs.webkit.org/show_bug.cgi?id=166698 Reviewed by Yusuke Suzuki. Implementation of the for-await-of statement. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitEnumeration): (JSC::BytecodeGenerator::emitIteratorNext): * bytecompiler/BytecodeGenerator.h: * parser/ASTBuilder.h: (JSC::ASTBuilder::createForOfLoop): * parser/NodeConstructors.h: (JSC::ForOfNode::ForOfNode): * parser/Nodes.h: (JSC::ForOfNode::isForAwait const): * parser/Parser.cpp: (JSC::Parser::parseForStatement): * parser/Parser.h: (JSC::Scope::setSourceParseMode): (JSC::Scope::setIsFunction): (JSC::Scope::setIsAsyncGeneratorFunction): (JSC::Scope::setIsAsyncGeneratorFunctionBody): * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createForOfLoop): 2017-08-29 Commit Queue Unreviewed, rolling out r221317. https://bugs.webkit.org/show_bug.cgi?id=176090 "It broke a testing mode because we will never FTL compile a function that repeatedly throws" (Requested by saamyjoon on #webkit). Reverted changeset: "Throwing an exception in the DFG/FTL should not be a jettison-able OSR exit" https://bugs.webkit.org/show_bug.cgi?id=176060 http://trac.webkit.org/changeset/221317 2017-08-29 Yusuke Suzuki [DFG] Add constant folding rule to convert CompareStrictEq(Untyped, Untyped [with non string cell constant]) to CompareEqPtr(Untyped) https://bugs.webkit.org/show_bug.cgi?id=175895 Reviewed by Saam Barati. We have `bucket === @sentinelMapBucket` code in builtin. Since @sentinelMapBucket and bucket are MapBucket cell (SpecCellOther), we do not have any good fixup for CompareStrictEq. But rather than introducing a special fixup edge (like, NonStringCellUse), converting CompareStrictEq(Untyped, Untyped) to CompareEqPtr is simpler. In constant folding phase, we convert CompareStrictEq(Untyped, Untyped) to CompareEqPtr(Untyed) if one side of the children is constant non String cell. This slightly optimizes map/set iteration. set-for-each 4.5064+-0.3072 ^ 3.2862+-0.2098 ^ definitely 1.3713x faster large-map-iteration 56.2583+-1.6640 53.6798+-2.0097 might be 1.0480x faster set-for-of 8.8058+-0.5953 ^ 7.5832+-0.3805 ^ definitely 1.1612x faster map-for-each 4.2633+-0.2694 ^ 3.3967+-0.3013 ^ definitely 1.2551x faster map-for-of 13.1556+-0.5707 12.4911+-0.6004 might be 1.0532x faster * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGNode.h: (JSC::DFG::Node::convertToCompareEqPtr): 2017-08-29 Yusuke Suzuki [JSC] Use reifying system for "name" property of builtin JSFunction https://bugs.webkit.org/show_bug.cgi?id=175260 Reviewed by Saam Barati. Currently builtin JSFunction uses direct property for "name", which is different from usual JSFunction. Usual JSFunction uses reifying system for "name". We would like to apply this reifying mechanism to builtin JSFunction to simplify code and drop JSFunction::createBuiltinFunction. We would like to store the "correct" name in FunctionExecutable. For example, we would like to store the name like "get [Symbol.species]" to FunctionExecutable instead of specifying name when creating JSFunction. To do so, we add a new annotations, @getter and @overriddenName. When @getter is specified, the name of the function becomes "get xxx". And when @overriddenName="xxx" is specified, the name of the function becomes "xxx". * Scripts/builtins/builtins_generate_combined_header.py: (generate_section_for_code_table_macro): * Scripts/builtins/builtins_generate_combined_implementation.py: (BuiltinsCombinedImplementationGenerator.generate_secondary_header_includes): * Scripts/builtins/builtins_generate_separate_header.py: (generate_section_for_code_table_macro): * Scripts/builtins/builtins_generate_separate_implementation.py: (BuiltinsSeparateImplementationGenerator.generate_secondary_header_includes): * Scripts/builtins/builtins_model.py: (BuiltinFunction.__init__): (BuiltinFunction.fromString): * Scripts/builtins/builtins_templates.py: * Scripts/tests/builtins/JavaScriptCore-Builtin.prototype-Combined.js: (overriddenName.string_appeared_here.match): (intrinsic.RegExpTestIntrinsic.test): * Scripts/tests/builtins/JavaScriptCore-Builtin.prototype-Separate.js: (overriddenName.string_appeared_here.match): (intrinsic.RegExpTestIntrinsic.test): * 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: * builtins/BuiltinExecutables.cpp: (JSC::BuiltinExecutables::BuiltinExecutables): * builtins/BuiltinExecutables.h: * builtins/FunctionPrototype.js: (symbolHasInstance): Deleted. * builtins/GlobalOperations.js: (globalPrivate.speciesGetter): Deleted. * builtins/IteratorPrototype.js: (symbolIteratorGetter): Deleted. * builtins/RegExpPrototype.js: (match): Deleted. (replace): Deleted. (search): Deleted. (split): Deleted. * jsc.cpp: (functionCreateBuiltin): * runtime/FunctionPrototype.cpp: (JSC::FunctionPrototype::addFunctionProperties): * runtime/IteratorPrototype.cpp: (JSC::IteratorPrototype::finishCreation): * runtime/JSFunction.cpp: (JSC::JSFunction::getOwnNonIndexPropertyNames): (JSC::JSFunction::reifyLazyBoundNameIfNeeded): (JSC::JSFunction::createBuiltinFunction): Deleted. * runtime/JSFunction.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/JSObject.cpp: (JSC::JSObject::putDirectBuiltinFunction): (JSC::JSObject::putDirectBuiltinFunctionWithoutTransition): * runtime/JSTypedArrayViewPrototype.cpp: (JSC::JSTypedArrayViewPrototype::finishCreation): * runtime/Lookup.cpp: (JSC::reifyStaticAccessor): * runtime/RegExpPrototype.cpp: (JSC::RegExpPrototype::finishCreation): 2017-08-29 Saam Barati Throwing an exception in the DFG/FTL should not be a jettison-able OSR exit https://bugs.webkit.org/show_bug.cgi?id=176060 Reviewed by Michael Saboff. OSR exitting when we throw an exception is expected behavior. We should not count these exits towards our jettison OSR exit threshold. * bytecode/ExitKind.cpp: (JSC::exitKindToString): (JSC::exitKindMayJettison): * bytecode/ExitKind.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileThrow): 2017-08-29 Chris Dumez Add initial support for dataTransferItem.webkitGetAsEntry() https://bugs.webkit.org/show_bug.cgi?id=176038 Reviewed by Wenson Hsieh. Add CommonIdentifier needed by [EnabledAtRuntime]. * runtime/CommonIdentifiers.h: 2017-08-27 Devin Rousso Web Inspector: Record actions performed on WebGLRenderingContext https://bugs.webkit.org/show_bug.cgi?id=174483 Reviewed by Matt Baker. * inspector/protocol/Recording.json: * inspector/scripts/codegen/generator.py: Add type and mapping for WebGL: "canvas-webgl" => CanvasWebGL 2017-08-26 Yusuke Suzuki Unreviewed, suppress warnings in GTK port The "block" variable hides the argument variable. * dfg/DFGLiveCatchVariablePreservationPhase.cpp: (JSC::DFG::LiveCatchVariablePreservationPhase::isValidFlushLocation): 2017-08-26 Yusuke Suzuki Merge WeakMapData into JSWeakMap and JSWeakSet https://bugs.webkit.org/show_bug.cgi?id=143919 Reviewed by Darin Adler. This patch changes WeakMapData from JSCell to JSDestructibleObject, renaming it to WeakMapBase, and JSWeakMap and JSWeakSet simply inherit it instead of separately allocating WeakMapData. This reduces memory consumption and allocation times. Also this patch a bit optimizes sizeof(DeadKeyCleaner) by dropping m_target field. Since this class is always embedded in WeakMapBase, we can calculate WeakMapBase address from the address of DeadKeyCleaner. This patch does not include the optimization changing WeakMapData to Set for JSWeakSet. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * inspector/JSInjectedScriptHost.cpp: (Inspector::JSInjectedScriptHost::weakMapSize): (Inspector::JSInjectedScriptHost::weakMapEntries): (Inspector::JSInjectedScriptHost::weakSetSize): (Inspector::JSInjectedScriptHost::weakSetEntries): * runtime/JSWeakMap.cpp: (JSC::JSWeakMap::finishCreation): Deleted. (JSC::JSWeakMap::visitChildren): Deleted. * runtime/JSWeakMap.h: (JSC::JSWeakMap::createStructure): Deleted. (JSC::JSWeakMap::create): Deleted. (JSC::JSWeakMap::weakMapData): Deleted. (JSC::JSWeakMap::JSWeakMap): Deleted. * runtime/JSWeakSet.cpp: (JSC::JSWeakSet::finishCreation): Deleted. (JSC::JSWeakSet::visitChildren): Deleted. * runtime/JSWeakSet.h: (JSC::JSWeakSet::createStructure): Deleted. (JSC::JSWeakSet::create): Deleted. (JSC::JSWeakSet::weakMapData): Deleted. (JSC::JSWeakSet::JSWeakSet): Deleted. * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: * runtime/WeakMapBase.cpp: Renamed from Source/JavaScriptCore/runtime/WeakMapData.cpp. (JSC::WeakMapBase::WeakMapBase): (JSC::WeakMapBase::destroy): (JSC::WeakMapBase::estimatedSize): (JSC::WeakMapBase::visitChildren): (JSC::WeakMapBase::set): (JSC::WeakMapBase::get): (JSC::WeakMapBase::remove): (JSC::WeakMapBase::contains): (JSC::WeakMapBase::clear): (JSC::WeakMapBase::DeadKeyCleaner::target): (JSC::WeakMapBase::DeadKeyCleaner::visitWeakReferences): (JSC::WeakMapBase::DeadKeyCleaner::finalizeUnconditionally): * runtime/WeakMapBase.h: Renamed from Source/JavaScriptCore/runtime/WeakMapData.h. (JSC::WeakMapBase::size const): * runtime/WeakMapPrototype.cpp: (JSC::getWeakMap): (JSC::protoFuncWeakMapDelete): (JSC::protoFuncWeakMapGet): (JSC::protoFuncWeakMapHas): (JSC::protoFuncWeakMapSet): (JSC::getWeakMapData): Deleted. * runtime/WeakSetPrototype.cpp: (JSC::getWeakSet): (JSC::protoFuncWeakSetDelete): (JSC::protoFuncWeakSetHas): (JSC::protoFuncWeakSetAdd): (JSC::getWeakMapData): Deleted. 2017-08-25 Daniel Bates Demarcate code added due to lack of NSDMI for aggregates https://bugs.webkit.org/show_bug.cgi?id=175990 Reviewed by Andy Estes. * domjit/DOMJITEffect.h: (JSC::DOMJIT::Effect::Effect): (JSC::DOMJIT::Effect::forWrite): (JSC::DOMJIT::Effect::forRead): (JSC::DOMJIT::Effect::forReadWrite): (JSC::DOMJIT::Effect::forPure): (JSC::DOMJIT::Effect::forDef): * runtime/HasOwnPropertyCache.h: (JSC::HasOwnPropertyCache::Entry::Entry): (JSC::HasOwnPropertyCache::Entry::operator=): Deleted. * wasm/WasmFormat.h: Modernize some of the code while I am here. Also make some comments read well. (JSC::Wasm::CallableFunction::CallableFunction): * wasm/js/WebAssemblyFunction.cpp: (JSC::WebAssemblyFunction::WebAssemblyFunction): * wasm/js/WebAssemblyWrapperFunction.cpp: (JSC::WebAssemblyWrapperFunction::create): 2017-08-25 Saam Barati Unreviewed. Fix 32-bit after r221196 * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_catch): 2017-08-25 Chris Dumez Land stubs for File and Directory Entries API interfaces https://bugs.webkit.org/show_bug.cgi?id=175993 Reviewed by Ryosuke Niwa. Add CommonIdentifiers needed for [EnabledAtRuntime]. * runtime/CommonIdentifiers.h: 2017-08-25 Brian Burg Web Automation: add capabilities to control ICE candidate filtering and insecure media capture https://bugs.webkit.org/show_bug.cgi?id=175563 Reviewed by Joseph Pecoraro. Add macros for new capability protocol string names. Let's use a reverse domain name notification for these capabilities so we know whether they are intended for a particular client/port or any WebKit client, and what feature they are related to (i.e., webrtc). * inspector/remote/RemoteInspectorConstants.h: 2017-08-24 Brian Burg Web Automation: use automation session configurations to propagate per-session settings https://bugs.webkit.org/show_bug.cgi?id=175562 Reviewed by Joseph Pecoraro. Add a Cocoa-specific code path to forward capabilities when requesting a new session from the remote inspector (i.e., automation) client. If other ports want to use this, then we can convert Cocoa types to WebKit types later. * inspector/remote/RemoteInspector.h: * inspector/remote/RemoteInspectorConstants.h: * inspector/remote/cocoa/RemoteInspectorCocoa.mm: (Inspector::RemoteInspector::receivedAutomationSessionRequestMessage): 2017-08-25 Saam Barati DFG::JITCode::osrEntry should get sorted since we perform a binary search on it https://bugs.webkit.org/show_bug.cgi?id=175893 Reviewed by Mark Lam. * dfg/DFGJITCode.cpp: (JSC::DFG::JITCode::finalizeOSREntrypoints): * dfg/DFGJITCode.h: (JSC::DFG::JITCode::finalizeCatchOSREntrypoints): Deleted. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::linkOSREntries): 2017-08-25 Saam Barati Support compiling catch in the DFG https://bugs.webkit.org/show_bug.cgi?id=174590 Reviewed by Filip Pizlo. This patch implements OSR entry into op_catch in the DFG. We will support OSR entry into the FTL in a followup: https://bugs.webkit.org/show_bug.cgi?id=175396 To implement catch in the DFG, this patch introduces the concept of multiple entrypoints into CPS/LoadStore DFG IR. A lot of this patch is stringing this concept through the DFG. Many phases used to assume that Graph::block(0) is the only root, and this patch contains many straight forward changes generalizing the code to handle more than one entrypoint. A main building block of this is moving to two CFG types: SSACFG and CPSCFG. SSACFG is the same CFG we used to have. CPSCFG is a new type that introduces a fake root that has an outgoing edge to all the entrypoints. This allows our existing graph algorithms to Just Work over CPSCFG. For example, there is now the concept of SSADominators vs CPSDominators, and SSANaturalLoops vs CPSNaturalLoops. The way we compile the catch entrypoint is by bootstrapping the state of the program by loading all live bytecode locals from a buffer. The OSR entry code will store all live values into that buffer before jumping to the entrypoint. The OSR entry code is also responsible for performing type proofs of the arguments before doing an OSR entry. If there is a type mismatch, it's not legal to OSR enter into the DFG compilation. Currently, each catch entrypoint knows the argument type proofs it must perform to enter into the DFG. Currently, all entrypoints' arguments flush format are unified via ArgumentPosition, but this is just an implementation detail. The code is written more generally to assume that each entrypoint may perform its own distinct proof. op_catch now performs value profiling for all live bytecode locals in the LLInt and baseline JIT. This information is then fed into the DFG via the ExtractCatchLocal node in the prediction propagation phase. This patch also changes how we generate op_catch in bytecode. All op_catches are now split out at the end of the program in bytecode. This ensures that no op_catch is inside a try block. This is needed to ensure correctness in the DFGLiveCatchVariablePreservationPhase. That phase only inserts flushes before SetLocals inside a try block. If an op_catch were in a try block, this would cause the phase to insert a Flush before one of the state bootstrapping SetLocals, which would generate invalid IR. Moving op_catch to be generated on its own at the end of a bytecode stream seemed like the most elegant solution since it better represents that we treat op_catch as an entrypoint. This is true both in the DFG and in the baseline and LLInt: we don't reach an op_catch via normal control flow. Because op_catch cannot throw, this will not break any previous semantics of op_catch. Logically, it'd be valid to split try blocks around any non-throwing bytecode operation. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/BytecodeDumper.cpp: (JSC::BytecodeDumper::dumpBytecode): * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): (JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffset): (JSC::CodeBlock::updateAllPredictionsAndCountLiveness): (JSC::CodeBlock::validate): * bytecode/CodeBlock.h: * bytecode/ValueProfile.h: (JSC::ValueProfile::ValueProfile): (JSC::ValueProfileAndOperandBuffer::ValueProfileAndOperandBuffer): (JSC::ValueProfileAndOperandBuffer::~ValueProfileAndOperandBuffer): (JSC::ValueProfileAndOperandBuffer::forEach): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::generate): (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::emitCatch): (JSC::BytecodeGenerator::emitEnumeration): * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::TryNode::emitBytecode): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGBackwardsCFG.h: (JSC::DFG::BackwardsCFG::BackwardsCFG): * dfg/DFGBasicBlock.cpp: (JSC::DFG::BasicBlock::BasicBlock): * dfg/DFGBasicBlock.h: (JSC::DFG::BasicBlock::findTerminal const): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::setDirect): (JSC::DFG::ByteCodeParser::flush): (JSC::DFG::ByteCodeParser::DelayedSetLocal::DelayedSetLocal): (JSC::DFG::ByteCodeParser::DelayedSetLocal::execute): (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::parseCodeBlock): (JSC::DFG::ByteCodeParser::parse): * dfg/DFGCFG.h: (JSC::DFG::CFG::root): (JSC::DFG::CFG::roots): (JSC::DFG::CPSCFG::CPSCFG): (JSC::DFG::selectCFG): * dfg/DFGCPSRethreadingPhase.cpp: (JSC::DFG::CPSRethreadingPhase::specialCaseArguments): * dfg/DFGCSEPhase.cpp: * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGControlEquivalenceAnalysis.h: (JSC::DFG::ControlEquivalenceAnalysis::ControlEquivalenceAnalysis): * dfg/DFGDCEPhase.cpp: (JSC::DFG::DCEPhase::run): * dfg/DFGDisassembler.cpp: (JSC::DFG::Disassembler::createDumpList): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGDominators.h: (JSC::DFG::Dominators::Dominators): (JSC::DFG::ensureDominatorsForCFG): * dfg/DFGEdgeDominates.h: (JSC::DFG::EdgeDominates::EdgeDominates): (JSC::DFG::EdgeDominates::operator()): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::fixupChecksInBlock): * dfg/DFGFlushFormat.h: * dfg/DFGGraph.cpp: (JSC::DFG::Graph::Graph): (JSC::DFG::unboxLoopNode): (JSC::DFG::Graph::dumpBlockHeader): (JSC::DFG::Graph::dump): (JSC::DFG::Graph::determineReachability): (JSC::DFG::Graph::invalidateCFG): (JSC::DFG::Graph::blocksInPreOrder): (JSC::DFG::Graph::blocksInPostOrder): (JSC::DFG::Graph::ensureCPSDominators): (JSC::DFG::Graph::ensureSSADominators): (JSC::DFG::Graph::ensureCPSNaturalLoops): (JSC::DFG::Graph::ensureSSANaturalLoops): (JSC::DFG::Graph::ensureBackwardsCFG): (JSC::DFG::Graph::ensureBackwardsDominators): (JSC::DFG::Graph::ensureControlEquivalenceAnalysis): (JSC::DFG::Graph::methodOfGettingAValueProfileFor): (JSC::DFG::Graph::clearCPSCFGData): (JSC::DFG::Graph::ensureDominators): Deleted. (JSC::DFG::Graph::ensurePrePostNumbering): Deleted. (JSC::DFG::Graph::ensureNaturalLoops): Deleted. * dfg/DFGGraph.h: (JSC::DFG::Graph::willCatchExceptionInMachineFrame): (JSC::DFG::Graph::isEntrypoint const): * dfg/DFGInPlaceAbstractState.cpp: (JSC::DFG::InPlaceAbstractState::initialize): (JSC::DFG::InPlaceAbstractState::mergeToSuccessors): * dfg/DFGJITCode.cpp: (JSC::DFG::JITCode::shrinkToFit): * dfg/DFGJITCode.h: (JSC::DFG::JITCode::catchOSREntryDataForBytecodeIndex): (JSC::DFG::JITCode::finalizeCatchOSREntrypoints): (JSC::DFG::JITCode::appendCatchEntrypoint): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): (JSC::DFG::JITCompiler::noticeCatchEntrypoint): (JSC::DFG::JITCompiler::noticeOSREntry): (JSC::DFG::JITCompiler::makeCatchOSREntryBuffer): * dfg/DFGJITCompiler.h: * dfg/DFGLICMPhase.cpp: (JSC::DFG::LICMPhase::run): (JSC::DFG::LICMPhase::attemptHoist): * dfg/DFGLiveCatchVariablePreservationPhase.cpp: (JSC::DFG::LiveCatchVariablePreservationPhase::run): (JSC::DFG::LiveCatchVariablePreservationPhase::isValidFlushLocation): (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch): (JSC::DFG::LiveCatchVariablePreservationPhase::newVariableAccessData): (JSC::DFG::LiveCatchVariablePreservationPhase::willCatchException): Deleted. (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlock): Deleted. * dfg/DFGLoopPreHeaderCreationPhase.cpp: (JSC::DFG::createPreHeader): (JSC::DFG::LoopPreHeaderCreationPhase::run): * dfg/DFGMaximalFlushInsertionPhase.cpp: (JSC::DFG::MaximalFlushInsertionPhase::run): (JSC::DFG::MaximalFlushInsertionPhase::treatRegularBlock): (JSC::DFG::MaximalFlushInsertionPhase::treatRootBlock): * dfg/DFGMayExit.cpp: * dfg/DFGNaturalLoops.h: (JSC::DFG::NaturalLoops::NaturalLoops): * dfg/DFGNode.h: (JSC::DFG::Node::isSwitch const): (JSC::DFG::Node::successor): (JSC::DFG::Node::catchOSREntryIndex const): (JSC::DFG::Node::catchLocalPrediction): (JSC::DFG::Node::isSwitch): Deleted. * dfg/DFGNodeType.h: * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareCatchOSREntry): * dfg/DFGOSREntry.h: * dfg/DFGOSREntrypointCreationPhase.cpp: (JSC::DFG::OSREntrypointCreationPhase::run): * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::handleExitCounts): * dfg/DFGObjectAllocationSinkingPhase.cpp: * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThreadImpl): * dfg/DFGPrePostNumbering.cpp: (JSC::DFG::PrePostNumbering::PrePostNumbering): Deleted. (JSC::DFG::PrePostNumbering::~PrePostNumbering): Deleted. (WTF::printInternal): Deleted. * dfg/DFGPrePostNumbering.h: (): Deleted. (JSC::DFG::PrePostNumbering::preNumber const): Deleted. (JSC::DFG::PrePostNumbering::postNumber const): Deleted. (JSC::DFG::PrePostNumbering::isStrictAncestorOf const): Deleted. (JSC::DFG::PrePostNumbering::isAncestorOf const): Deleted. (JSC::DFG::PrePostNumbering::isStrictDescendantOf const): Deleted. (JSC::DFG::PrePostNumbering::isDescendantOf const): Deleted. (JSC::DFG::PrePostNumbering::edgeKind const): Deleted. * dfg/DFGPredictionInjectionPhase.cpp: (JSC::DFG::PredictionInjectionPhase::run): * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGPutStackSinkingPhase.cpp: * dfg/DFGSSACalculator.cpp: (JSC::DFG::SSACalculator::nonLocalReachingDef): (JSC::DFG::SSACalculator::reachingDefAtTail): * dfg/DFGSSACalculator.h: (JSC::DFG::SSACalculator::computePhis): * dfg/DFGSSAConversionPhase.cpp: (JSC::DFG::SSAConversionPhase::run): (JSC::DFG::performSSAConversion): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCurrentBlock): (JSC::DFG::SpeculativeJIT::checkArgumentTypes): (JSC::DFG::SpeculativeJIT::createOSREntries): (JSC::DFG::SpeculativeJIT::linkOSREntries): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStaticExecutionCountEstimationPhase.cpp: (JSC::DFG::StaticExecutionCountEstimationPhase::run): * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::handleNode): * dfg/DFGTierUpCheckInjectionPhase.cpp: (JSC::DFG::TierUpCheckInjectionPhase::run): (JSC::DFG::TierUpCheckInjectionPhase::buildNaturalLoopToLoopHintMap): * dfg/DFGTypeCheckHoistingPhase.cpp: (JSC::DFG::TypeCheckHoistingPhase::run): * dfg/DFGValidate.cpp: * ftl/FTLLink.cpp: (JSC::FTL::link): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::lower): (JSC::FTL::DFG::LowerDFGToB3::safelyInvalidateAfterTermination): (JSC::FTL::DFG::LowerDFGToB3::isValid): * jit/JIT.h: * jit/JITInlines.h: (JSC::JIT::callOperation): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_catch): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_catch): * jit/JITOperations.cpp: * jit/JITOperations.h: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: 2017-08-25 Keith Miller Explore increasing max JSString::m_length to UINT_MAX. https://bugs.webkit.org/show_bug.cgi?id=163955 Reviewed by JF Bastien. This can cause us to release assert on some code paths. I don't see a reason to maintain this restriction. * runtime/JSString.h: (JSC::JSString::length const): (JSC::JSString::setLength): (JSC::JSString::isValidLength): Deleted. * runtime/JSStringBuilder.h: (JSC::jsMakeNontrivialString): 2017-08-24 Commit Queue Unreviewed, rolling out r221119, r221124, and r221143. https://bugs.webkit.org/show_bug.cgi?id=175973 "I think it regressed JSBench by 20%" (Requested by saamyjoon on #webkit). Reverted changesets: "Support compiling catch in the DFG" https://bugs.webkit.org/show_bug.cgi?id=174590 http://trac.webkit.org/changeset/221119 "Unreviewed, build fix in GTK port" https://bugs.webkit.org/show_bug.cgi?id=174590 http://trac.webkit.org/changeset/221124 "DFG::JITCode::osrEntry should get sorted since we perform a binary search on it" https://bugs.webkit.org/show_bug.cgi?id=175893 http://trac.webkit.org/changeset/221143 2017-08-24 Michael Saboff Enable moving fixed character class terms after fixed character terms for BMP only character classes https://bugs.webkit.org/show_bug.cgi?id=175958 Reviewed by Saam Barati. Currently we don't perform the reordering optimiaztion of fixed character terms that follow fixed character class terms for Unicode patterns. This change allows that reordering when the character class contains only BMP characters. This fix is covered by existing tests. * yarr/YarrJIT.cpp: (JSC::Yarr::YarrGenerator::optimizeAlternative): 2017-08-24 Michael Saboff Add support for RegExp "dotAll" flag https://bugs.webkit.org/show_bug.cgi?id=175924 Reviewed by Keith Miller. The dotAll RegExp flag, 's', changes . to match any character including line terminators. Added a the "dotAll" identifier as well as RegExp.prototype.dotAll getter. Added a new any character CharacterClass that is used to match . terms in a dotAll flags RegExp. In the YARR pattern and parsing code, changed the NewlineClassID, which was only used for '.' processing, to DotClassID. The selection of which builtin character class that DotClassID resolves to when generating the pattern is conditional on the dotAll flag. This NewlineClassID to DotClassID refactoring includes the atomBuiltInCharacterClass() in the WebCore content extensions code in the PatternParser class. As an optimization, the Yarr JIT actually doesn't perform match checks against the builtin any character CharacterClass, it merely reads the character. There is another optimization in our DotStart enclosure processing where a non-capturing regular expression in the form of .* Reduce Gigacage sizes https://bugs.webkit.org/show_bug.cgi?id=175920 Reviewed by Mark Lam. Teach all of the code generators to use the right gigacage masks. Also teach Wasm that it has much less memory for signaling memories. With 32GB, we have room for 7 signaling memories. But if we actually did that, then we'd have no memory left for anything else. So, this caps us at 4 signaling memories. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::caged): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::cage): (JSC::AssemblyHelpers::cageConditionally): * llint/LowLevelInterpreter64.asm: * runtime/Options.h: 2017-08-24 Saam Barati DFG::JITCode::osrEntry should get sorted since we perform a binary search on it https://bugs.webkit.org/show_bug.cgi?id=175893 Reviewed by Mark Lam. * dfg/DFGJITCode.cpp: (JSC::DFG::JITCode::finalizeOSREntrypoints): * dfg/DFGJITCode.h: (JSC::DFG::JITCode::finalizeCatchOSREntrypoints): Deleted. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::linkOSREntries): 2017-08-23 Keith Miller Fix Titzer bench on iOS. https://bugs.webkit.org/show_bug.cgi?id=175917 Reviewed by Ryosuke Niwa. Currently, Titzer bench doesn't run on iOS since the benchmark allocates lots of physical pages that it never actually writes to. We limited the total number wasm physical pages to the ram size of the phone, which caused us to fail a memory allocation. This patch changes it so we will allocate up to 3x ram size, which seems to fix the problem. * wasm/WasmMemory.cpp: 2017-08-23 Yusuke Suzuki Unreviewed, fix for test262 https://bugs.webkit.org/show_bug.cgi?id=175915 * runtime/MapPrototype.cpp: (JSC::MapPrototype::finishCreation): * runtime/SetPrototype.cpp: (JSC::SetPrototype::finishCreation): 2017-08-23 Yusuke Suzuki Unreviewed, build fix in GTK port https://bugs.webkit.org/show_bug.cgi?id=174590 * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitCatch): * bytecompiler/BytecodeGenerator.h: 2017-08-23 Saam Barati Support compiling catch in the DFG https://bugs.webkit.org/show_bug.cgi?id=174590 Reviewed by Filip Pizlo. This patch implements OSR entry into op_catch in the DFG. We will support OSR entry into the FTL in a followup: https://bugs.webkit.org/show_bug.cgi?id=175396 To implement catch in the DFG, this patch introduces the concept of multiple entrypoints into CPS/LoadStore DFG IR. A lot of this patch is stringing this concept through the DFG. Many phases used to assume that Graph::block(0) is the only root, and this patch contains many straight forward changes generalizing the code to handle more than one entrypoint. A main building block of this is moving to two CFG types: SSACFG and CPSCFG. SSACFG is the same CFG we used to have. CPSCFG is a new type that introduces a fake root that has an outgoing edge to all the entrypoints. This allows our existing graph algorithms to Just Work over CPSCFG. For example, there is now the concept of SSADominators vs CPSDominators, and SSANaturalLoops vs CPSNaturalLoops. The way we compile the catch entrypoint is by bootstrapping the state of the program by loading all live bytecode locals from a buffer. The OSR entry code will store all live values into that buffer before jumping to the entrypoint. The OSR entry code is also responsible for performing type proofs of the arguments before doing an OSR entry. If there is a type mismatch, it's not legal to OSR enter into the DFG compilation. Currently, each catch entrypoint knows the argument type proofs it must perform to enter into the DFG. Currently, all entrypoints' arguments flush format are unified via ArgumentPosition, but this is just an implementation detail. The code is written more generally to assume that each entrypoint may perform its own distinct proof. op_catch now performs value profiling for all live bytecode locals in the LLInt and baseline JIT. This information is then fed into the DFG via the ExtractCatchLocal node in the prediction propagation phase. This patch also changes how we generate op_catch in bytecode. All op_catches are now split out at the end of the program in bytecode. This ensures that no op_catch is inside a try block. This is needed to ensure correctness in the DFGLiveCatchVariablePreservationPhase. That phase only inserts flushes before SetLocals inside a try block. If an op_catch were in a try block, this would cause the phase to insert a Flush before one of the state bootstrapping SetLocals, which would generate invalid IR. Moving op_catch to be generated on its own at the end of a bytecode stream seemed like the most elegant solution since it better represents that we treat op_catch as an entrypoint. This is true both in the DFG and in the baseline and LLInt: we don't reach an op_catch via normal control flow. Because op_catch cannot throw, this will not break any previous semantics of op_catch. Logically, it'd be valid to split try blocks around any non-throwing bytecode operation. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/BytecodeDumper.cpp: (JSC::BytecodeDumper::dumpBytecode): * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): (JSC::CodeBlock::updateAllPredictionsAndCountLiveness): (JSC::CodeBlock::validate): * bytecode/CodeBlock.h: * bytecode/ValueProfile.h: (JSC::ValueProfile::ValueProfile): (JSC::ValueProfileAndOperandBuffer::ValueProfileAndOperandBuffer): (JSC::ValueProfileAndOperandBuffer::~ValueProfileAndOperandBuffer): (JSC::ValueProfileAndOperandBuffer::forEach): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::generate): (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::emitCatch): (JSC::BytecodeGenerator::emitEnumeration): * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::TryNode::emitBytecode): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGBackwardsCFG.h: (JSC::DFG::BackwardsCFG::BackwardsCFG): * dfg/DFGBasicBlock.cpp: (JSC::DFG::BasicBlock::BasicBlock): * dfg/DFGBasicBlock.h: (JSC::DFG::BasicBlock::findTerminal const): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::setDirect): (JSC::DFG::ByteCodeParser::flush): (JSC::DFG::ByteCodeParser::DelayedSetLocal::DelayedSetLocal): (JSC::DFG::ByteCodeParser::DelayedSetLocal::execute): (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::parseCodeBlock): (JSC::DFG::ByteCodeParser::parse): * dfg/DFGCFG.h: (JSC::DFG::CFG::root): (JSC::DFG::CFG::roots): (JSC::DFG::CPSCFG::CPSCFG): (JSC::DFG::selectCFG): * dfg/DFGCPSRethreadingPhase.cpp: (JSC::DFG::CPSRethreadingPhase::specialCaseArguments): * dfg/DFGCSEPhase.cpp: * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGControlEquivalenceAnalysis.h: (JSC::DFG::ControlEquivalenceAnalysis::ControlEquivalenceAnalysis): * dfg/DFGDCEPhase.cpp: (JSC::DFG::DCEPhase::run): * dfg/DFGDisassembler.cpp: (JSC::DFG::Disassembler::createDumpList): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGDominators.h: (JSC::DFG::Dominators::Dominators): (JSC::DFG::ensureDominatorsForCFG): * dfg/DFGEdgeDominates.h: (JSC::DFG::EdgeDominates::EdgeDominates): (JSC::DFG::EdgeDominates::operator()): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::fixupChecksInBlock): * dfg/DFGFlushFormat.h: * dfg/DFGGraph.cpp: (JSC::DFG::Graph::Graph): (JSC::DFG::unboxLoopNode): (JSC::DFG::Graph::dumpBlockHeader): (JSC::DFG::Graph::dump): (JSC::DFG::Graph::determineReachability): (JSC::DFG::Graph::invalidateCFG): (JSC::DFG::Graph::blocksInPreOrder): (JSC::DFG::Graph::blocksInPostOrder): (JSC::DFG::Graph::ensureCPSDominators): (JSC::DFG::Graph::ensureSSADominators): (JSC::DFG::Graph::ensureCPSNaturalLoops): (JSC::DFG::Graph::ensureSSANaturalLoops): (JSC::DFG::Graph::ensureBackwardsCFG): (JSC::DFG::Graph::ensureBackwardsDominators): (JSC::DFG::Graph::ensureControlEquivalenceAnalysis): (JSC::DFG::Graph::methodOfGettingAValueProfileFor): (JSC::DFG::Graph::clearCPSCFGData): (JSC::DFG::Graph::ensureDominators): Deleted. (JSC::DFG::Graph::ensurePrePostNumbering): Deleted. (JSC::DFG::Graph::ensureNaturalLoops): Deleted. * dfg/DFGGraph.h: (JSC::DFG::Graph::willCatchExceptionInMachineFrame): (JSC::DFG::Graph::isEntrypoint const): * dfg/DFGInPlaceAbstractState.cpp: (JSC::DFG::InPlaceAbstractState::initialize): (JSC::DFG::InPlaceAbstractState::mergeToSuccessors): * dfg/DFGJITCode.cpp: (JSC::DFG::JITCode::shrinkToFit): * dfg/DFGJITCode.h: (JSC::DFG::JITCode::catchOSREntryDataForBytecodeIndex): (JSC::DFG::JITCode::finalizeCatchOSREntrypoints): (JSC::DFG::JITCode::appendCatchEntrypoint): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): (JSC::DFG::JITCompiler::noticeCatchEntrypoint): (JSC::DFG::JITCompiler::noticeOSREntry): (JSC::DFG::JITCompiler::makeCatchOSREntryBuffer): * dfg/DFGJITCompiler.h: * dfg/DFGLICMPhase.cpp: (JSC::DFG::LICMPhase::run): (JSC::DFG::LICMPhase::attemptHoist): * dfg/DFGLiveCatchVariablePreservationPhase.cpp: (JSC::DFG::LiveCatchVariablePreservationPhase::run): (JSC::DFG::LiveCatchVariablePreservationPhase::isValidFlushLocation): (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch): (JSC::DFG::LiveCatchVariablePreservationPhase::newVariableAccessData): (JSC::DFG::LiveCatchVariablePreservationPhase::willCatchException): Deleted. (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlock): Deleted. * dfg/DFGLoopPreHeaderCreationPhase.cpp: (JSC::DFG::createPreHeader): (JSC::DFG::LoopPreHeaderCreationPhase::run): * dfg/DFGMaximalFlushInsertionPhase.cpp: (JSC::DFG::MaximalFlushInsertionPhase::run): (JSC::DFG::MaximalFlushInsertionPhase::treatRegularBlock): (JSC::DFG::MaximalFlushInsertionPhase::treatRootBlock): * dfg/DFGMayExit.cpp: * dfg/DFGNaturalLoops.h: (JSC::DFG::NaturalLoops::NaturalLoops): * dfg/DFGNode.h: (JSC::DFG::Node::isSwitch const): (JSC::DFG::Node::successor): (JSC::DFG::Node::catchOSREntryIndex const): (JSC::DFG::Node::catchLocalPrediction): (JSC::DFG::Node::isSwitch): Deleted. * dfg/DFGNodeType.h: * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareCatchOSREntry): * dfg/DFGOSREntry.h: * dfg/DFGOSREntrypointCreationPhase.cpp: (JSC::DFG::OSREntrypointCreationPhase::run): * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::handleExitCounts): * dfg/DFGObjectAllocationSinkingPhase.cpp: * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThreadImpl): * dfg/DFGPrePostNumbering.cpp: (JSC::DFG::PrePostNumbering::PrePostNumbering): Deleted. (JSC::DFG::PrePostNumbering::~PrePostNumbering): Deleted. (WTF::printInternal): Deleted. * dfg/DFGPrePostNumbering.h: (): Deleted. (JSC::DFG::PrePostNumbering::preNumber const): Deleted. (JSC::DFG::PrePostNumbering::postNumber const): Deleted. (JSC::DFG::PrePostNumbering::isStrictAncestorOf const): Deleted. (JSC::DFG::PrePostNumbering::isAncestorOf const): Deleted. (JSC::DFG::PrePostNumbering::isStrictDescendantOf const): Deleted. (JSC::DFG::PrePostNumbering::isDescendantOf const): Deleted. (JSC::DFG::PrePostNumbering::edgeKind const): Deleted. * dfg/DFGPredictionInjectionPhase.cpp: (JSC::DFG::PredictionInjectionPhase::run): * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGPutStackSinkingPhase.cpp: * dfg/DFGSSACalculator.cpp: (JSC::DFG::SSACalculator::nonLocalReachingDef): (JSC::DFG::SSACalculator::reachingDefAtTail): * dfg/DFGSSACalculator.h: (JSC::DFG::SSACalculator::computePhis): * dfg/DFGSSAConversionPhase.cpp: (JSC::DFG::SSAConversionPhase::run): (JSC::DFG::performSSAConversion): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCurrentBlock): (JSC::DFG::SpeculativeJIT::checkArgumentTypes): (JSC::DFG::SpeculativeJIT::createOSREntries): (JSC::DFG::SpeculativeJIT::linkOSREntries): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStaticExecutionCountEstimationPhase.cpp: (JSC::DFG::StaticExecutionCountEstimationPhase::run): * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::handleNode): * dfg/DFGTierUpCheckInjectionPhase.cpp: (JSC::DFG::TierUpCheckInjectionPhase::run): (JSC::DFG::TierUpCheckInjectionPhase::buildNaturalLoopToLoopHintMap): * dfg/DFGTypeCheckHoistingPhase.cpp: (JSC::DFG::TypeCheckHoistingPhase::run): * dfg/DFGValidate.cpp: * ftl/FTLLink.cpp: (JSC::FTL::link): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::lower): (JSC::FTL::DFG::LowerDFGToB3::safelyInvalidateAfterTermination): (JSC::FTL::DFG::LowerDFGToB3::isValid): * jit/JIT.h: * jit/JITInlines.h: (JSC::JIT::callOperation): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_catch): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_catch): * jit/JITOperations.cpp: * jit/JITOperations.h: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: 2017-08-23 Yusuke Suzuki Unreviewed, debug build fix https://bugs.webkit.org/show_bug.cgi?id=174355 * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucketNext): 2017-08-23 Michael Saboff REGRESSION (r221052): DumpRenderTree crashed in com.apple.JavaScriptCore: JSC::Yarr::YarrCodeBlock::execute + 137 https://bugs.webkit.org/show_bug.cgi?id=175903 Reviewed by Saam Barati. In generateCharacterClassGreedy we were incrementing the "count" register before checking for the end of the input string. The at-end-of-input check is the final check before knowing that the current character matched. In this case, the end of input check indicates that we ran out of prechecked characters and therefore should fail the match of the current character. The backtracking code uses the value in the "count" register as the number of character that successfully matched, which shouldn't include the current character. Therefore we need to move the incrementing of "count" to after the at end of input check. Through code inspection of the expectations of other backtracking code, I determined that the non greedy character class matching code had a similar issue. I fixed that as well and added a new test case. * yarr/YarrJIT.cpp: (JSC::Yarr::YarrGenerator::generateCharacterClassGreedy): (JSC::Yarr::YarrGenerator::backtrackCharacterClassNonGreedy): 2017-08-23 Yusuke Suzuki [JSC] Optimize Map iteration with intrinsic https://bugs.webkit.org/show_bug.cgi?id=174355 Reviewed by Saam Barati. This patch optimizes Map/Set iteration by taking the approach similar to Array iteration. We create a simple iterator object instead of JSMapIterator and JSSetIterator. And we directly handles Map/Set buckets in JS builtins. We carefully create mapIteratorNext and setIteratorNext functions which should be inlined. This leads significant performance boost when they are inlined in for-of iteration. This patch changes how DFG and FTL handles MapBucket if the bucket is not found. Previously, we use nullptr for that, and DFG and FTL specially handle this nullptr as bucket. Instead, this patch introduces sentinel buckets. They are marked as deleted, and not linked to any hash maps. And its key and value fields are filled with Undefined. By returning this sentinel bucket instead of returning nullptr, we simplify DFG and FTL's LoadXXXFromMapBucket code. We still keep JSMapIterator and JSSetIterator because they are useful to serialize Map and Set in WebCore. So they are not used in user observable JS. We change them from JS objects to JS cells. Existing microbenchmarks shows performance improvements. large-map-iteration 164.1622+-4.1618 ^ 56.6284+-1.5355 ^ definitely 2.8989x faster set-for-of 15.4369+-1.0631 ^ 9.2955+-0.5979 ^ definitely 1.6607x faster map-for-each 7.5889+-0.5792 ^ 6.3011+-0.4816 ^ definitely 1.2044x faster map-for-of 32.3904+-1.3003 ^ 12.6907+-0.6118 ^ definitely 2.5523x faster map-rehash 13.9275+-0.9187 ^ 11.5367+-0.6430 ^ definitely 1.2072x faster * CMakeLists.txt: * DerivedSources.make: * builtins/ArrayPrototype.js: (globalPrivate.createArrayIterator): * builtins/BuiltinNames.h: * builtins/MapIteratorPrototype.js: Copied from Source/JavaScriptCore/builtins/MapPrototype.js. (globalPrivate.mapIteratorNext): (next): * builtins/MapPrototype.js: (globalPrivate.createMapIterator): (values): (keys): (entries): (forEach): * builtins/SetIteratorPrototype.js: Copied from Source/JavaScriptCore/builtins/MapPrototype.js. (globalPrivate.setIteratorNext): (next): * builtins/SetPrototype.js: (globalPrivate.createSetIterator): (values): (entries): (forEach): * bytecode/BytecodeIntrinsicRegistry.cpp: (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry): * bytecode/BytecodeIntrinsicRegistry.h: * bytecode/SpeculatedType.h: * 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/DFGHeapLocation.cpp: (WTF::printInternal): * dfg/DFGHeapLocation.h: * dfg/DFGNode.h: (JSC::DFG::Node::hasHeapPrediction): (JSC::DFG::Node::hasBucketOwnerType): (JSC::DFG::Node::bucketOwnerType): (JSC::DFG::Node::OpInfoWrapper::as const): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetMapBucketHead): (JSC::DFG::SpeculativeJIT::compileGetMapBucketNext): (JSC::DFG::SpeculativeJIT::compileLoadKeyFromMapBucket): (JSC::DFG::SpeculativeJIT::compileLoadValueFromMapBucket): (JSC::DFG::SpeculativeJIT::compileCompareEqPtr): Deleted. * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compileCompareEqPtr): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compileCompareEqPtr): (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLAbstractHeapRepository.h: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucket): (JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucketHead): (JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucketNext): (JSC::FTL::DFG::LowerDFGToB3::compileLoadValueFromMapBucket): (JSC::FTL::DFG::LowerDFGToB3::compileLoadKeyFromMapBucket): (JSC::FTL::DFG::LowerDFGToB3::setStorage): (JSC::FTL::DFG::LowerDFGToB3::compileLoadFromJSMapBucket): Deleted. (JSC::FTL::DFG::LowerDFGToB3::compileIsNonEmptyMapBucket): Deleted. (JSC::FTL::DFG::LowerDFGToB3::lowMapBucket): Deleted. (JSC::FTL::DFG::LowerDFGToB3::setMapBucket): Deleted. * inspector/JSInjectedScriptHost.cpp: (Inspector::JSInjectedScriptHost::subtype): (Inspector::JSInjectedScriptHost::getInternalProperties): (Inspector::cloneMapIteratorObject): (Inspector::cloneSetIteratorObject): (Inspector::JSInjectedScriptHost::iteratorEntries): * runtime/HashMapImpl.h: (JSC::HashMapBucket::createSentinel): (JSC::HashMapBucket::offsetOfNext): (JSC::HashMapBucket::offsetOfDeleted): (JSC::HashMapImpl::offsetOfHead): * runtime/Intrinsic.cpp: (JSC::intrinsicName): * runtime/Intrinsic.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/JSGlobalObject.h: * runtime/JSMap.h: * runtime/JSMapIterator.cpp: (JSC::JSMapIterator::clone): Deleted. * runtime/JSMapIterator.h: (JSC::JSMapIterator::iteratedValue const): * runtime/JSSet.h: * runtime/JSSetIterator.cpp: (JSC::JSSetIterator::clone): Deleted. * runtime/JSSetIterator.h: (JSC::JSSetIterator::iteratedValue const): * runtime/MapConstructor.cpp: (JSC::mapPrivateFuncMapBucketHead): (JSC::mapPrivateFuncMapBucketNext): (JSC::mapPrivateFuncMapBucketKey): (JSC::mapPrivateFuncMapBucketValue): * runtime/MapConstructor.h: * runtime/MapIteratorPrototype.cpp: (JSC::MapIteratorPrototype::finishCreation): (JSC::MapIteratorPrototypeFuncNext): Deleted. * runtime/MapPrototype.cpp: (JSC::MapPrototype::finishCreation): (JSC::mapProtoFuncValues): Deleted. (JSC::mapProtoFuncEntries): Deleted. (JSC::mapProtoFuncKeys): Deleted. (JSC::privateFuncMapIterator): Deleted. (JSC::privateFuncMapIteratorNext): Deleted. * runtime/MapPrototype.h: * runtime/SetConstructor.cpp: (JSC::setPrivateFuncSetBucketHead): (JSC::setPrivateFuncSetBucketNext): (JSC::setPrivateFuncSetBucketKey): * runtime/SetConstructor.h: * runtime/SetIteratorPrototype.cpp: (JSC::SetIteratorPrototype::finishCreation): (JSC::SetIteratorPrototypeFuncNext): Deleted. * runtime/SetPrototype.cpp: (JSC::SetPrototype::finishCreation): (JSC::setProtoFuncSize): (JSC::setProtoFuncValues): Deleted. (JSC::setProtoFuncEntries): Deleted. (JSC::privateFuncSetIterator): Deleted. (JSC::privateFuncSetIteratorNext): Deleted. * runtime/SetPrototype.h: * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2017-08-23 David Kilzer Fix -Wcast-qual warnings in JavaScriptCore with new clang compiler Reviewed by Mark Lam. * API/ObjCCallbackFunction.mm: (JSC::objCCallbackFunctionCallAsConstructor): Use const_cast() since JSValueRef is const while JSObjectRef is not. * API/tests/CurrentThisInsideBlockGetterTest.mm: (+[JSValue valueWithConstructorDescriptor:inContext:]): Use const_cast() since JSObjectMake() takes a void*, but CFBridgingRetain() returns const void*. 2017-08-23 Robin Morisset Make GetDynamicVar propagate heap predictions instead of saying HeapTop https://bugs.webkit.org/show_bug.cgi?id=175738 Reviewed by Saam Barati. The heap prediction always end up in m_opInfo2. But GetDynamicVar was already storing getPutInfo in there. So we move that one into m_opInfo. We can do this because it is 32-bit, and the already present identifierNumber is also 32-bit, so we can pack both in m_opInfo (which is 64 bits). * dfg/DFGByteCodeParser.cpp: (JSC::DFG::makeDynamicVarOpInfo): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGNode.h: (JSC::DFG::Node::getPutInfo): (JSC::DFG::Node::hasHeapPrediction): * dfg/DFGPredictionPropagationPhase.cpp: 2017-08-23 Skachkov Oleksandr [ESNext] Async iteration - Implement Async Generator - runtime https://bugs.webkit.org/show_bug.cgi?id=175240 Reviewed by Yusuke Suzuki. Current implementation is draft version of Async Iteration. Link to spec https://tc39.github.io/proposal-async-iteration/ To implement async generator added new states that show reason why async generator was suspended: # yield - return promise with result # await - wait until promise will be resolved and then continue The main difference between async function and async generator is that, async function returns promise but async generator returns object with methods (next, throw and return) that return promise that can be resolved with pair of properties value and done. Async generator functions are similar to generator functions, with the following differences: # When called, async generator functions return an object, an async generator whose methods (next, throw, and return) return promises for { value, done }, instead of directly returning { value, done }. This automatically makes the returned async generator objects async iterators. # await expressions and for-await-of statements are allowed. # The behavior of yield* is modified to support delegation to sync and async iterables * CMakeLists.txt: * DerivedSources.make: * JavaScriptCore.xcodeproj/project.pbxproj: * builtins/AsyncFromSyncIteratorPrototype.js: Added. (next.try): (next): (return.try): (return): (throw.try): (throw): (globalPrivate.createAsyncFromSyncIterator): (globalPrivate.AsyncFromSyncIteratorConstructor): * builtins/AsyncGeneratorPrototype.js: Added. (globalPrivate.createAsyncGeneratorQueue): (globalPrivate.asyncGeneratorQueueIsEmpty): (globalPrivate.asyncGeneratorQueueCreateItem): (globalPrivate.asyncGeneratorQueueEnqueue): (globalPrivate.asyncGeneratorQueueDequeue): (globalPrivate.asyncGeneratorQueueGetFirstValue): (globalPrivate.asyncGeneratorDequeue): (globalPrivate.isExecutionState): (globalPrivate.isSuspendYieldState): (globalPrivate.asyncGeneratorReject): (globalPrivate.asyncGeneratorResolve): (asyncGeneratorYieldAwaited): (globalPrivate.asyncGeneratorYield): (const.onRejected): (globalPrivate.awaitValue): (const.onFulfilled): (globalPrivate.doAsyncGeneratorBodyCall): (globalPrivate.asyncGeneratorResumeNext.): (globalPrivate.asyncGeneratorResumeNext): (globalPrivate.asyncGeneratorEnqueue): (next): (return): (throw): * builtins/AsyncIteratorPrototype.js: Added. (symbolAsyncIteratorGetter): * builtins/BuiltinNames.h: * bytecode/BytecodeDumper.cpp: (JSC::BytecodeDumper::dumpBytecode): * bytecode/BytecodeIntrinsicRegistry.cpp: (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry): * bytecode/BytecodeIntrinsicRegistry.h: * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::emitCreateAsyncGeneratorQueue): (JSC::BytecodeGenerator::emitPutAsyncGeneratorFields): (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon): (JSC::BytecodeGenerator::emitNewFunction): (JSC::BytecodeGenerator::emitIteratorNextWithValue): (JSC::BytecodeGenerator::emitIteratorClose): (JSC::BytecodeGenerator::emitYieldPoint): (JSC::BytecodeGenerator::emitYield): (JSC::BytecodeGenerator::emitCallIterator): (JSC::BytecodeGenerator::emitAwait): (JSC::BytecodeGenerator::emitGetIterator): (JSC::BytecodeGenerator::emitGetAsyncIterator): (JSC::BytecodeGenerator::emitDelegateYield): * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::ReturnNode::emitBytecode): (JSC::FunctionNode::emitBytecode): (JSC::YieldExprNode::emitBytecode): (JSC::AwaitExprNode::emitBytecode): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGClobbersExitState.cpp: (JSC::DFG::clobbersExitState): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGMayExit.cpp: * dfg/DFGNode.h: (JSC::DFG::Node::convertToPhantomNewFunction): (JSC::DFG::Node::convertToPhantomNewAsyncGeneratorFunction): (JSC::DFG::Node::hasCellOperand): (JSC::DFG::Node::isFunctionAllocation): (JSC::DFG::Node::isPhantomFunctionAllocation): (JSC::DFG::Node::isPhantomAllocation): * dfg/DFGNodeType.h: * dfg/DFGObjectAllocationSinkingPhase.cpp: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileNewFunction): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStoreBarrierInsertionPhase.cpp: * dfg/DFGValidate.cpp: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction): * ftl/FTLOperations.cpp: (JSC::FTL::operationPopulateObjectInOSR): (JSC::FTL::operationMaterializeObjectInOSR): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JIT.h: * jit/JITOpcodes.cpp: (JSC::JIT::emitNewFuncCommon): (JSC::JIT::emit_op_new_async_generator_func): (JSC::JIT::emit_op_new_async_func): (JSC::JIT::emitNewFuncExprCommon): (JSC::JIT::emit_op_new_async_generator_func_exp): * jit/JITOperations.cpp: * jit/JITOperations.h: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter.asm: * parser/ASTBuilder.h: (JSC::ASTBuilder::createFunctionMetadata): * runtime/AsyncFromSyncIteratorPrototype.cpp: Added. (JSC::AsyncFromSyncIteratorPrototype::AsyncFromSyncIteratorPrototype): (JSC::AsyncFromSyncIteratorPrototype::finishCreation): (JSC::AsyncFromSyncIteratorPrototype::create): * runtime/AsyncFromSyncIteratorPrototype.h: Added. (JSC::AsyncFromSyncIteratorPrototype::createStructure): * runtime/AsyncGeneratorFunctionConstructor.cpp: Added. (JSC::AsyncGeneratorFunctionConstructor::AsyncGeneratorFunctionConstructor): (JSC::AsyncGeneratorFunctionConstructor::finishCreation): (JSC::callAsyncGeneratorFunctionConstructor): (JSC::constructAsyncGeneratorFunctionConstructor): (JSC::AsyncGeneratorFunctionConstructor::getCallData): (JSC::AsyncGeneratorFunctionConstructor::getConstructData): * runtime/AsyncGeneratorFunctionConstructor.h: Added. (JSC::AsyncGeneratorFunctionConstructor::create): (JSC::AsyncGeneratorFunctionConstructor::createStructure): * runtime/AsyncGeneratorFunctionPrototype.cpp: Added. (JSC::AsyncGeneratorFunctionPrototype::AsyncGeneratorFunctionPrototype): (JSC::AsyncGeneratorFunctionPrototype::finishCreation): * runtime/AsyncGeneratorFunctionPrototype.h: Added. (JSC::AsyncGeneratorFunctionPrototype::create): (JSC::AsyncGeneratorFunctionPrototype::createStructure): * runtime/AsyncGeneratorPrototype.cpp: Added. (JSC::AsyncGeneratorPrototype::finishCreation): * runtime/AsyncGeneratorPrototype.h: Added. (JSC::AsyncGeneratorPrototype::create): (JSC::AsyncGeneratorPrototype::createStructure): (JSC::AsyncGeneratorPrototype::AsyncGeneratorPrototype): * runtime/AsyncIteratorPrototype.cpp: Added. (JSC::AsyncIteratorPrototype::finishCreation): * runtime/AsyncIteratorPrototype.h: Added. (JSC::AsyncIteratorPrototype::create): (JSC::AsyncIteratorPrototype::createStructure): (JSC::AsyncIteratorPrototype::AsyncIteratorPrototype): * runtime/CommonIdentifiers.h: * runtime/FunctionConstructor.cpp: (JSC::constructFunctionSkippingEvalEnabledCheck): * runtime/FunctionConstructor.h: * runtime/FunctionExecutable.h: * runtime/JSAsyncGeneratorFunction.cpp: Added. (JSC::JSAsyncGeneratorFunction::JSAsyncGeneratorFunction): (JSC::JSAsyncGeneratorFunction::createImpl): (JSC::JSAsyncGeneratorFunction::create): (JSC::JSAsyncGeneratorFunction::createWithInvalidatedReallocationWatchpoint): * runtime/JSAsyncGeneratorFunction.h: Added. (JSC::JSAsyncGeneratorFunction::allocationSize): (JSC::JSAsyncGeneratorFunction::createStructure): * runtime/JSFunction.cpp: (JSC::JSFunction::getOwnPropertySlot): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildren): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::asyncIteratorPrototype const): (JSC::JSGlobalObject::asyncGeneratorPrototype const): (JSC::JSGlobalObject::asyncGeneratorFunctionPrototype const): (JSC::JSGlobalObject::asyncGeneratorFunctionStructure const): * runtime/Options.h: 2017-08-22 Michael Saboff Implement Unicode RegExp support in the YARR JIT https://bugs.webkit.org/show_bug.cgi?id=174646 Reviewed by Filip Pizlo. This support is only implemented for 64 bit platforms. It wouldn't be too hard to add support for 32 bit platforms with a reasonable number of spare registers. This code slightly refactors register usage to reduce the number of callee save registers used for non-Unicode expressions. For Unicode expressions, there are several more registers used to store constants values for processing surrogate pairs as well as discerning whether a character belongs to the Basic Multilingual Plane (BMP) or one of the Supplemental Planes. This implements JIT support for Unicode expressions very similar to how the interpreter works. Just like in the interpreter, backtracking code uses more space on the stack to save positions. Moved the BackTrackInfo* structs to YarrPattern as separate functions. Added xxxIndex() functions to each of these to simplify how the JIT code reads and writes the structure fields. Given that reading surrogate pairs and transforming them into a single code point takes a little processing, the code that implements reading a Unicode character is implemented as a leaf function added to the end of the JIT'ed code. The calling convention for "tryReadUnicodeCharacterHelper()" is non-standard given that the rest of the code assumes that argument values stay in argument registers for most of the generated code. That helper takes the starting character address in one register, regUnicodeInputAndTrail, and uses another dedicated temporary register, regUnicodeTemp. The result is typically returned in regT0. If another return register is requested, we'll create an inline copy of that function. Added a new flag to CharacterClass to signify if a class has non-BMP characters. This flag is used in optimizeAlternative() where we swap the order of a fixed character class term with a fixed character term that immediately follows it. Since the non-BMP character class may increment "index" when matching, that must be done first before trying to match a fixed character term later in the string. Given the usefulness of the LEA instruction on X86 to create a single pointer value from a base with index and offset, which the YARR JIT uses heavily, I added a new macroAssembler function, getEffectiveAddress64(), with an ARM64 implementation. It just calls x86Lea64() on X86-64. Also added an ImplicitAddress version of load16Unaligned(). (JSC::MacroAssemblerARM64::load16Unaligned): (JSC::MacroAssemblerARM64::getEffectiveAddress64): * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::load16Unaligned): (JSC::MacroAssemblerX86Common::load16): * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::getEffectiveAddress64): * create_regex_tables: * runtime/RegExp.cpp: (JSC::RegExp::compile): * yarr/YarrInterpreter.cpp: * yarr/YarrJIT.cpp: (JSC::Yarr::YarrGenerator::optimizeAlternative): (JSC::Yarr::YarrGenerator::matchCharacterClass): (JSC::Yarr::YarrGenerator::tryReadUnicodeCharImpl): (JSC::Yarr::YarrGenerator::tryReadUnicodeChar): (JSC::Yarr::YarrGenerator::readCharacter): (JSC::Yarr::YarrGenerator::jumpIfCharNotEquals): (JSC::Yarr::YarrGenerator::matchAssertionWordchar): (JSC::Yarr::YarrGenerator::generateAssertionWordBoundary): (JSC::Yarr::YarrGenerator::generatePatternCharacterOnce): (JSC::Yarr::YarrGenerator::generatePatternCharacterFixed): (JSC::Yarr::YarrGenerator::generatePatternCharacterGreedy): (JSC::Yarr::YarrGenerator::backtrackPatternCharacterGreedy): (JSC::Yarr::YarrGenerator::generatePatternCharacterNonGreedy): (JSC::Yarr::YarrGenerator::backtrackPatternCharacterNonGreedy): (JSC::Yarr::YarrGenerator::generateCharacterClassOnce): (JSC::Yarr::YarrGenerator::backtrackCharacterClassOnce): (JSC::Yarr::YarrGenerator::generateCharacterClassFixed): (JSC::Yarr::YarrGenerator::generateCharacterClassGreedy): (JSC::Yarr::YarrGenerator::backtrackCharacterClassGreedy): (JSC::Yarr::YarrGenerator::generateCharacterClassNonGreedy): (JSC::Yarr::YarrGenerator::backtrackCharacterClassNonGreedy): (JSC::Yarr::YarrGenerator::generate): (JSC::Yarr::YarrGenerator::backtrack): (JSC::Yarr::YarrGenerator::generateTryReadUnicodeCharacterHelper): (JSC::Yarr::YarrGenerator::generateEnter): (JSC::Yarr::YarrGenerator::generateReturn): (JSC::Yarr::YarrGenerator::YarrGenerator): (JSC::Yarr::YarrGenerator::compile): * yarr/YarrJIT.h: * yarr/YarrPattern.cpp: (JSC::Yarr::CharacterClassConstructor::CharacterClassConstructor): (JSC::Yarr::CharacterClassConstructor::reset): (JSC::Yarr::CharacterClassConstructor::charClass): (JSC::Yarr::CharacterClassConstructor::addSorted): (JSC::Yarr::CharacterClassConstructor::addSortedRange): (JSC::Yarr::CharacterClassConstructor::hasNonBMPCharacters): (JSC::Yarr::YarrPatternConstructor::setupAlternativeOffsets): * yarr/YarrPattern.h: (JSC::Yarr::CharacterClass::CharacterClass): (JSC::Yarr::BackTrackInfoPatternCharacter::beginIndex): (JSC::Yarr::BackTrackInfoPatternCharacter::matchAmountIndex): (JSC::Yarr::BackTrackInfoCharacterClass::beginIndex): (JSC::Yarr::BackTrackInfoCharacterClass::matchAmountIndex): (JSC::Yarr::BackTrackInfoBackReference::beginIndex): (JSC::Yarr::BackTrackInfoBackReference::matchAmountIndex): (JSC::Yarr::BackTrackInfoAlternative::offsetIndex): (JSC::Yarr::BackTrackInfoParentheticalAssertion::beginIndex): (JSC::Yarr::BackTrackInfoParenthesesOnce::beginIndex): (JSC::Yarr::BackTrackInfoParenthesesTerminal::beginIndex): 2017-08-22 Per Arne Vollan Implement 64-bit MacroAssembler::probe support for Windows. https://bugs.webkit.org/show_bug.cgi?id=175724 Reviewed by Mark Lam. This is needed to enable the DFG. MSVC does no longer support inline assembly for 64-bit, which means we have to put the code in an asm file. * assembler/MacroAssemblerX86Common.cpp: (JSC::booleanTrueForAvoidingNoReturnDeclaration): Deleted. * jit/JITStubsMSVC64.asm: 2017-08-22 Devin Rousso Web Inspector: provide way for ShaderPrograms to be enabled/disabled https://bugs.webkit.org/show_bug.cgi?id=175400 Reviewed by Matt Baker. * inspector/protocol/Canvas.json: Add `setShaderProgramDisabled` command that sets the `disabled` flag on the given shader program to the supplied boolean value. If this value is true, calls to `drawArrays` and `drawElements` when that program is in use will have no effect. 2017-08-22 Keith Miller Unriviewed, fix windows build... for realz. * CMakeLists.txt: 2017-08-22 Saam Barati We are using valueProfileForBytecodeOffset when there may not be a value profile https://bugs.webkit.org/show_bug.cgi?id=175812 Reviewed by Michael Saboff. This patch uses the type system to aid the code around CodeBlock's ValueProfile accessor methods. valueProfileForBytecodeOffset used to return ValueProfile*, so there were callers of this that thought it could return nullptr when there was no such ValueProfile. This was not the case, it always returned a non-null pointer. This patch changes valueProfileForBytecodeOffset to return ValueProfile& and adds a new tryGetValueProfileForBytecodeOffset method that returns ValueProfile* and does the right thing if there is no such ValueProfile. This patch also changes the other ValueProfile accessors on CodeBlock to return ValueProfile& instead of ValueProfile*. Some callers handled the null case unnecessarily, and using the type system to specify the result can't be null removes these useless branches. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::updateAllPredictionsAndCountLiveness): (JSC::CodeBlock::dumpValueProfiles): (JSC::CodeBlock::tryGetValueProfileForBytecodeOffset): (JSC::CodeBlock::valueProfileForBytecodeOffset): (JSC::CodeBlock::validate): * bytecode/CodeBlock.h: (JSC::CodeBlock::valueProfileForArgument): (JSC::CodeBlock::valueProfile): (JSC::CodeBlock::valueProfilePredictionForBytecodeOffset): (JSC::CodeBlock::getFromAllValueProfiles): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleInlining): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::methodOfGettingAValueProfileFor): * dfg/DFGPredictionInjectionPhase.cpp: (JSC::DFG::PredictionInjectionPhase::run): * jit/JIT.h: * jit/JITInlines.h: (JSC::JIT::emitValueProfilingSite): * profiler/ProfilerBytecodeSequence.cpp: (JSC::Profiler::BytecodeSequence::BytecodeSequence): * tools/HeapVerifier.cpp: (JSC::HeapVerifier::validateJSCell): 2017-08-22 Keith Miller Unreviewed, fix windows build... maybe. * CMakeLists.txt: 2017-08-22 Keith Miller Unreviewed, fix cloop build. * JavaScriptCore.xcodeproj/project.pbxproj: 2017-08-22 Per Arne Vollan [Win][Release] Crash when running testmasm executable. https://bugs.webkit.org/show_bug.cgi?id=175772 Reviewed by Mark Lam. We need to save and restore the modified registers in case one or more registers are callee saved on the relevant platforms. * assembler/testmasm.cpp: (JSC::testProbeReadsArgumentRegisters): (JSC::testProbeWritesArgumentRegisters): 2017-08-21 Mark Lam Change probe code to use static_assert instead of COMPILE_ASSERT. https://bugs.webkit.org/show_bug.cgi?id=175762 Reviewed by JF Bastien. * assembler/MacroAssemblerARM.cpp: * assembler/MacroAssemblerARM64.cpp: (JSC::MacroAssembler::probe): Deleted. * assembler/MacroAssemblerARMv7.cpp: * assembler/MacroAssemblerX86Common.cpp: 2017-08-21 Keith Miller Make generate_offset_extractor.rb architectures argument more robust https://bugs.webkit.org/show_bug.cgi?id=175809 Reviewed by Joseph Pecoraro. It turns out that some of our builders pass their architectures as space separated lists. I decided to just make the splitting of our list robust to any reasonable combination of spaces and commas. * offlineasm/generate_offset_extractor.rb: 2017-08-21 Keith Miller Only generate offline asm for the ARCHS (xcodebuild) or the current system (CMake) https://bugs.webkit.org/show_bug.cgi?id=175690 Reviewed by Michael Saboff. This should reduce some of the time we spend building offline asm in our builds (except for linux since they already did this). * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * offlineasm/backends.rb: * offlineasm/generate_offset_extractor.rb: 2017-08-20 Mark Lam Gardening: fix CLoop build. https://bugs.webkit.org/show_bug.cgi?id=175688 Not reviewed. Make these files dependent on ENABLE(MASM_PROBE). * assembler/ProbeContext.cpp: * assembler/ProbeContext.h: * assembler/ProbeStack.cpp: * assembler/ProbeStack.h: 2017-08-20 Mark Lam Enhance MacroAssembler::probe() to allow the probe function to resize the stack frame and alter stack data in one pass. https://bugs.webkit.org/show_bug.cgi?id=175688 Reviewed by JF Bastien. With this patch, the clients of the MacroAssembler::probe() can now change stack values without having to worry about whether there is enough room in the current stack frame for it or not. This is done using the Probe::Context's stack member like so: jit.probe([] (Probe::Context& context) { auto cpu = context.cpu; auto stack = context.stack(); uintptr_t* currentSP = cpu.sp(); // Get a value at the current stack pointer location. auto value = stack.get(currentSP); // Set a value above the current stack pointer (within current frame). stack.set(currentSP + 10, value); // Set a value below the current stack pointer (out of current frame). stack.set(currentSP - 10, value); // Set the new stack pointer. cpu.sp() = currentSP - 20; }); What happens behind the scene: 1. the generated JIT probe code will now call Probe::executeProbe(), and Probe::executeProbe() will in turn call the client's probe function. Probe::executeProbe() receives the Probe::State on the machine stack passed to it by the probe trampoline. Probe::executeProbe() will instantiate a Probe::Context to be passed to the client's probe function. The client will no longer see the Probe::State directly. 2. The Probe::Context comes with a Probe::Stack which serves as a manager of stack pages. Currently, each page is 1K in size. Probe::Context::stack() returns a reference to an instance of Probe::Stack. 3. Invoking get() of set() on Probe::Stack with an address will lead to the following: a. the address will be decoded to a baseAddress that points to the 1K page that contains that address. b. the Probe::Stack will check if it already has a cached 1K page for that baseAddress. If so, go to step (f). Else, continue with step (c). c. the Probe::Stack will malloc a 1K mirror page, and memcpy the 1K stack page for that specified baseAddress to this mirror page. d. the mirror page will be added to the ProbeStack's m_pages HashMap, keyed on the baseAddress. e. the ProbeStack will also cache the last baseAddress and its corresponding mirror page in use. With memory accesses tending to be localized, this will save us from having to look up the page in the HashMap. f. get() will map the requested address to a physical address in the mirror page, and return the value at that location. g. set() will map the requested address to a physical address in the mirror page, and set the value at that location in the mirror page. set() will also set a dirty bit corresponding to the "cache line" that was modified in the mirror page. 4. When the client's probe function returns, Probe::executeProbe() will check if there are stack changes that need to be applied. If stack changes are needed: a. Probe::executeProbe() will adjust the stack pointer to ensure enough stack space is available to flush the dirty stack pages. It will also register a flushStackDirtyPages callback function in the Probe::State. Thereafter, Probe::executeProbe() returns to the probe trampoline. b. the probe trampoline adjusts the stack pointer, moves the Probe::State to a safe place if needed, and then calls the flushStackDirtyPages callback if needed. c. the flushStackDirtyPages() callback iterates the Probe::Stack's m_pages HashMap and flush all dirty "cache lines" to the machine stack. Thereafter, flushStackDirtyPages() returns to the probe trampoline. d. lastly, the probe trampoline will restore all register values and return to the pc set in the Probe::State. To make this patch work, I also had to do the following work: 5. Refactor MacroAssembler::CPUState into Probe::CPUState. Mainly, this means moving the code over to ProbeContext.h. I also added some convenience accessor methods for spr registers. Moved Probe::Context over to its own file ProbeContext.h/cpp. 6. Fix all probe trampolines to pass the address of Probe::executeProbe in addition to the client's probe function and arg. I also took this opportunity to optimize the generated JIT probe code to minimize the amount of memory stores needed. 7. Simplified the ARM64 probe trampoline. The ARM64 probe only supports changing either lr or pc (or neither), but not both at in the same probe invocation. The ARM64 probe trampoline used to have to check for this invariant in the assembly trampoline code. With the introduction of Probe::executeProbe(), we can now do it there and simplify the trampoline. 8. Fix a bug in the old ARM64 probe trampoline for the case where the client changes lr. That code path never worked before, but has now been fixed. 9. Removed trustedImm32FromPtr() helper functions in MacroAssemblerARM and MacroAssemblerARMv7. We can now use move() with TrustedImmPtr, and it does the same thing but in a more generic way. 10. ARMv7's move() emitter may encode a T1 move instruction, which happens to have the same semantics as movs (according to the Thumb spec). This means these instructions may trash the APSR flags before we have a chance to preserve them. This patch changes MacroAssemblerARMv7's probe() to preserve the APSR register early on. This entails adding support for the mrs instruction in the ARMv7Assembler. 10. Change testmasm's testProbeModifiesStackValues() to now modify stack values the easy way. Also fixed testmasm tests which check flag registers to only compare the portions that are modifiable by the client i.e. some masking is applied. This patch has passed the testmasm tests on x86, x86_64, arm64, and armv7. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * assembler/ARMv7Assembler.h: (JSC::ARMv7Assembler::mrs): * assembler/AbstractMacroAssembler.h: * assembler/MacroAssembler.cpp: (JSC::stdFunctionCallback): (JSC::MacroAssembler::probe): * assembler/MacroAssembler.h: (JSC::MacroAssembler::CPUState::gprName): Deleted. (JSC::MacroAssembler::CPUState::sprName): Deleted. (JSC::MacroAssembler::CPUState::fprName): Deleted. (JSC::MacroAssembler::CPUState::gpr): Deleted. (JSC::MacroAssembler::CPUState::spr): Deleted. (JSC::MacroAssembler::CPUState::fpr): Deleted. (JSC:: const): Deleted. (JSC::MacroAssembler::CPUState::fpr const): Deleted. (JSC::MacroAssembler::CPUState::pc): Deleted. (JSC::MacroAssembler::CPUState::fp): Deleted. (JSC::MacroAssembler::CPUState::sp): Deleted. (JSC::MacroAssembler::CPUState::pc const): Deleted. (JSC::MacroAssembler::CPUState::fp const): Deleted. (JSC::MacroAssembler::CPUState::sp const): Deleted. (JSC::Probe::State::gpr): Deleted. (JSC::Probe::State::spr): Deleted. (JSC::Probe::State::fpr): Deleted. (JSC::Probe::State::gprName): Deleted. (JSC::Probe::State::sprName): Deleted. (JSC::Probe::State::fprName): Deleted. (JSC::Probe::State::pc): Deleted. (JSC::Probe::State::fp): Deleted. (JSC::Probe::State::sp): Deleted. * assembler/MacroAssemblerARM.cpp: (JSC::MacroAssembler::probe): * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::trustedImm32FromPtr): Deleted. * assembler/MacroAssemblerARM64.cpp: (JSC::MacroAssembler::probe): (JSC::arm64ProbeError): Deleted. * assembler/MacroAssemblerARMv7.cpp: (JSC::MacroAssembler::probe): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::armV7Condition): (JSC::MacroAssemblerARMv7::trustedImm32FromPtr): Deleted. * assembler/MacroAssemblerPrinter.cpp: (JSC::Printer::printCallback): * assembler/MacroAssemblerPrinter.h: * assembler/MacroAssemblerX86Common.cpp: (JSC::ctiMasmProbeTrampoline): (JSC::MacroAssembler::probe): * assembler/Printer.h: (JSC::Printer::Context::Context): * assembler/ProbeContext.cpp: Added. (JSC::Probe::executeProbe): (JSC::Probe::handleProbeStackInitialization): (JSC::Probe::probeStateForContext): * assembler/ProbeContext.h: Added. (JSC::Probe::CPUState::gprName): (JSC::Probe::CPUState::sprName): (JSC::Probe::CPUState::fprName): (JSC::Probe::CPUState::gpr): (JSC::Probe::CPUState::spr): (JSC::Probe::CPUState::fpr): (JSC::Probe:: const): (JSC::Probe::CPUState::fpr const): (JSC::Probe::CPUState::pc): (JSC::Probe::CPUState::fp): (JSC::Probe::CPUState::sp): (JSC::Probe::CPUState::pc const): (JSC::Probe::CPUState::fp const): (JSC::Probe::CPUState::sp const): (JSC::Probe::Context::Context): (JSC::Probe::Context::gpr): (JSC::Probe::Context::spr): (JSC::Probe::Context::fpr): (JSC::Probe::Context::gprName): (JSC::Probe::Context::sprName): (JSC::Probe::Context::fprName): (JSC::Probe::Context::pc): (JSC::Probe::Context::fp): (JSC::Probe::Context::sp): (JSC::Probe::Context::stack): (JSC::Probe::Context::hasWritesToFlush): (JSC::Probe::Context::releaseStack): * assembler/ProbeStack.cpp: Added. (JSC::Probe::Page::Page): (JSC::Probe::Page::flushWrites): (JSC::Probe::Stack::Stack): (JSC::Probe::Stack::hasWritesToFlush): (JSC::Probe::Stack::flushWrites): (JSC::Probe::Stack::ensurePageFor): * assembler/ProbeStack.h: Added. (JSC::Probe::Page::baseAddressFor): (JSC::Probe::Page::chunkAddressFor): (JSC::Probe::Page::baseAddress): (JSC::Probe::Page::get): (JSC::Probe::Page::set): (JSC::Probe::Page::hasWritesToFlush const): (JSC::Probe::Page::flushWritesIfNeeded): (JSC::Probe::Page::dirtyBitFor): (JSC::Probe::Page::physicalAddressFor): (JSC::Probe::Stack::Stack): (JSC::Probe::Stack::lowWatermark): (JSC::Probe::Stack::get): (JSC::Probe::Stack::set): (JSC::Probe::Stack::newStackPointer const): (JSC::Probe::Stack::setNewStackPointer): (JSC::Probe::Stack::isValid): (JSC::Probe::Stack::pageFor): * assembler/testmasm.cpp: (JSC::testProbeReadsArgumentRegisters): (JSC::testProbeWritesArgumentRegisters): (JSC::testProbePreservesGPRS): (JSC::testProbeModifiesStackPointer): (JSC::testProbeModifiesStackPointerToInsideProbeStateOnStack): (JSC::testProbeModifiesStackPointerToNBytesBelowSP): (JSC::testProbeModifiesProgramCounter): (JSC::testProbeModifiesStackValues): (JSC::run): (): Deleted. (JSC::fillStack): Deleted. (JSC::testProbeModifiesStackWithCallback): Deleted. 2017-08-19 Andy Estes [Payment Request] Add interface stubs https://bugs.webkit.org/show_bug.cgi?id=175730 Reviewed by Youenn Fablet. * runtime/CommonIdentifiers.h: 2017-08-18 Per Arne Vollan Implement 32-bit MacroAssembler::probe support for Windows. https://bugs.webkit.org/show_bug.cgi?id=175449 Reviewed by Mark Lam. This is needed to enable the DFG. * assembler/MacroAssemblerX86Common.cpp: * assembler/testmasm.cpp: (JSC::run): (dllLauncherEntryPoint): * shell/CMakeLists.txt: * shell/PlatformWin.cmake: 2017-08-18 Mark Lam Rename ProbeContext and ProbeFunction to Probe::State and Probe::Function. https://bugs.webkit.org/show_bug.cgi?id=175725 Rubber-stamped by JF Bastien. This is purely a refactoring patch (in preparation for the introduction of a Probe::Context data structure in https://bugs.webkit.org/show_bug.cgi?id=175688 later). This patch does not change any semantics / behavior. * assembler/AbstractMacroAssembler.h: * assembler/MacroAssembler.cpp: (JSC::stdFunctionCallback): (JSC::MacroAssembler::probe): * assembler/MacroAssembler.h: (JSC::ProbeContext::gpr): Deleted. (JSC::ProbeContext::spr): Deleted. (JSC::ProbeContext::fpr): Deleted. (JSC::ProbeContext::gprName): Deleted. (JSC::ProbeContext::sprName): Deleted. (JSC::ProbeContext::fprName): Deleted. (JSC::ProbeContext::pc): Deleted. (JSC::ProbeContext::fp): Deleted. (JSC::ProbeContext::sp): Deleted. * assembler/MacroAssemblerARM.cpp: (JSC::MacroAssembler::probe): * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::trustedImm32FromPtr): * assembler/MacroAssemblerARM64.cpp: (JSC::arm64ProbeError): (JSC::MacroAssembler::probe): * assembler/MacroAssemblerARMv7.cpp: (JSC::MacroAssembler::probe): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::trustedImm32FromPtr): * assembler/MacroAssemblerPrinter.cpp: (JSC::Printer::printCallback): * assembler/MacroAssemblerPrinter.h: * assembler/MacroAssemblerX86Common.cpp: (JSC::MacroAssembler::probe): * assembler/Printer.h: (JSC::Printer::Context::Context): * assembler/testmasm.cpp: (JSC::testProbeReadsArgumentRegisters): (JSC::testProbeWritesArgumentRegisters): (JSC::testProbePreservesGPRS): (JSC::testProbeModifiesStackPointer): (JSC::testProbeModifiesStackPointerToInsideProbeStateOnStack): (JSC::testProbeModifiesStackPointerToNBytesBelowSP): (JSC::testProbeModifiesProgramCounter): (JSC::fillStack): (JSC::testProbeModifiesStackWithCallback): (JSC::run): (JSC::testProbeModifiesStackPointerToInsideProbeContextOnStack): Deleted. 2017-08-17 JF Bastien WebAssembly: const in unreachable code decoded incorrectly, erroneously rejects binary as invalid https://bugs.webkit.org/show_bug.cgi?id=175693 Reviewed by Saam Barati. 64-bit constants in an unreachable context were being decoded as 32-bit constants. This is pretty benign because unreachable code shouldn't occur often. The effect is that 64-bit constants which can't be encoded as 32-bit constants would cause the binary to be rejected. At the same time, 32-bit integer constants should be decoded as signed. * wasm/WasmFunctionParser.h: (JSC::Wasm::FunctionParser::parseUnreachableExpression): 2017-08-17 Robin Morisset Teach DFGFixupPhase.cpp that the current scope is always a cell https://bugs.webkit.org/show_bug.cgi?id=175610 Reviewed by Keith Miller. Also teach it that the argument to with can usually be speculated to be an object, since toObject() is called on it. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compilePushWithScope): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compilePushWithScope): * jit/JITOperations.cpp: * jit/JITOperations.h: 2017-08-17 Matt Baker Web Inspector: remove unused private struct from InspectorScriptProfilerAgent https://bugs.webkit.org/show_bug.cgi?id=175644 Reviewed by Brian Burg. * inspector/agents/InspectorScriptProfilerAgent.h: 2017-08-17 Mark Lam Only use 16 VFP registers if !CPU(ARM_NEON). https://bugs.webkit.org/show_bug.cgi?id=175514 Reviewed by JF Bastien. Deleted q16-q31 FPQuadRegisterID enums in ARMv7Assembler.h. The NEON spec says that there are only 16 128-bit NEON registers. This change is merely to correct the code documentation of these registers. The FPQuadRegisterID are currently unused. * assembler/ARMAssembler.h: (JSC::ARMAssembler::lastFPRegister): (JSC::ARMAssembler::fprName): * assembler/ARMv7Assembler.h: (JSC::ARMv7Assembler::lastFPRegister): (JSC::ARMv7Assembler::fprName): * assembler/MacroAssemblerARM.cpp: * assembler/MacroAssemblerARMv7.cpp: 2017-08-17 Andreas Kling Disable CSS regions at compile time https://bugs.webkit.org/show_bug.cgi?id=175630 Reviewed by Antti Koivisto. * Configurations/FeatureDefines.xcconfig: 2017-08-17 Jacobo Aragunde Pérez [WPE][GTK] Ensure proper casting of data in gvariants https://bugs.webkit.org/show_bug.cgi?id=175667 Reviewed by Michael Catanzaro. g_variant_new requires data to have the correct width for their types, using casting if necessary. Some data of type `unsigned` were being saved to `guint64` types without explicit casting, leading to undefined behavior in some platforms. * inspector/remote/glib/RemoteInspectorGlib.cpp: (Inspector::RemoteInspector::listingForInspectionTarget const): (Inspector::RemoteInspector::listingForAutomationTarget const): (Inspector::RemoteInspector::sendMessageToRemote): 2017-08-17 Yusuke Suzuki [JSC] Avoid code bloating for iteration if block does not have "break" https://bugs.webkit.org/show_bug.cgi?id=173228 Reviewed by Keith Miller. Currently, we always emit code for breaked path when emitting for-of iteration. But we can know that this breaked path can be used when emitting the bytecode. This patch adds LabelScope::breakTargetMayBeBound(), which returns true if the break label may be bound. We emit a breaked path only when it returns true. This reduces bytecode bloating when using for-of iteration. * bytecompiler/BytecodeGenerator.cpp: (JSC::Label::setLocation): (JSC::BytecodeGenerator::newLabel): (JSC::BytecodeGenerator::emitLabel): (JSC::BytecodeGenerator::pushFinallyControlFlowScope): (JSC::BytecodeGenerator::breakTarget): (JSC::BytecodeGenerator::continueTarget): (JSC::BytecodeGenerator::emitEnumeration): * bytecompiler/BytecodeGenerator.h: * bytecompiler/Label.h: (JSC::Label::bind const): (JSC::Label::hasOneRef const): (JSC::Label::isBound const): (JSC::Label::Label): Deleted. * bytecompiler/LabelScope.h: (JSC::LabelScope::hasOneRef const): (JSC::LabelScope::breakTargetMayBeBound const): * bytecompiler/NodesCodegen.cpp: (JSC::ContinueNode::trivialTarget): (JSC::ContinueNode::emitBytecode): (JSC::BreakNode::trivialTarget): (JSC::BreakNode::emitBytecode): 2017-08-17 Csaba Osztrogonác ARM build fix after r220807 and r220834. https://bugs.webkit.org/show_bug.cgi?id=175617 Unreviewed typo fix. * assembler/MacroAssemblerARM.cpp: 2017-08-17 Mark Lam Gardening: build fix for ARM_TRADITIONAL after r220807. https://bugs.webkit.org/show_bug.cgi?id=175617 Not reviewed. * assembler/MacroAssemblerARM.cpp: 2017-08-16 Mark Lam Add back the ability to disable MASM_PROBE from the build. https://bugs.webkit.org/show_bug.cgi?id=175656 Reviewed by Yusuke Suzuki. This is needed for ports that the existing MASM_PROBE implementation doesn't work well with e.g. GTK with ARM_THUMB2. Note that if the DFG_JIT will be disabled by default if !ENABLE(MASM_PROBE). * assembler/AbstractMacroAssembler.h: * assembler/MacroAssembler.cpp: * assembler/MacroAssembler.h: * assembler/MacroAssemblerARM.cpp: * assembler/MacroAssemblerARM64.cpp: * assembler/MacroAssemblerARMv7.cpp: * assembler/MacroAssemblerPrinter.cpp: * assembler/MacroAssemblerPrinter.h: * assembler/MacroAssemblerX86Common.cpp: * assembler/testmasm.cpp: (JSC::run): * b3/B3LowerToAir.cpp: * b3/air/AirPrintSpecial.cpp: * b3/air/AirPrintSpecial.h: 2017-08-16 Dan Bernstein [Cocoa] Older-iOS install name symbols are being exported on other platforms https://bugs.webkit.org/show_bug.cgi?id=175654 Reviewed by Tim Horton. * API/JSBase.cpp: Define the symbols only when targeting iOS. 2017-08-16 Matt Baker Web Inspector: capture async stack trace when workers/main context posts a message https://bugs.webkit.org/show_bug.cgi?id=167084 Reviewed by Brian Burg. * inspector/agents/InspectorDebuggerAgent.h: Add `PostMessage` async call type. 2017-08-16 Mark Lam Enhance MacroAssembler::probe() to support an initializeStackFunction callback. https://bugs.webkit.org/show_bug.cgi?id=175617 Reviewed by JF Bastien. This patch adds a new feature to MacroAssembler::probe() where the probe function can provide a ProbeFunction callback to fill in stack values after the stack pointer has been adjusted. The probe function can use this feature as follows: 1. Set the new sp value in the ProbeContext's CPUState. 2. Set the ProbeContext's initializeStackFunction to a ProbeFunction callback which will do the work of filling in the stack values after the probe trampoline has adjusted the machine stack pointer. 3. Set the ProbeContext's initializeStackArgs to any value that the client wants to pass to the initializeStackFunction callback. 4. Return from the probe function. Upon returning from the probe function, the probe trampoline will adjust the the stack pointer based on the sp value in CPUState. If initializeStackFunction is not set, the probe trampoline will restore registers and return to its caller. If initializeStackFunction is set, the trampoline will move the ProbeContext beyond the range of the stack pointer i.e. it will place the new ProbeContext at an address lower than where CPUState.sp() points. This ensures that the ProbeContext will not be trashed by the initializeStackFunction when it writes to the stack. Then, the trampoline will call back to the initializeStackFunction ProbeFunction to let it fill in the stack values as desired. The initializeStackFunction ProbeFunction will be passed the moved ProbeContext at the new location. initializeStackFunction may now write to the stack at addresses greater or equal to CPUState.sp(), but not below that. initializeStackFunction is also not allowed to change CPUState.sp(). If the initializeStackFunction does not abide by these rules, then behavior is undefined, and bad things may happen. For future reference, some implementation details that this patch needed to be mindful of: 1. When the probe trampoline allocates stack space for the ProbeContext, it should include OUT_SIZE as well. This ensures that it doesn't have to move the ProbeContext on exit if the probe function didn't change the sp. 2. If the trampoline has to move the ProbeContext, it needs to point the machine sp to new ProbeContext first before copying over the ProbeContext data. This protects the new ProbeContext from possibly being trashed by interrupts. 3. When computing the new address of ProbeContext to move to, we need to make sure that it is properly aligned in accordance with stack ABI requirements (just like we did when we allocated the ProbeContext on entry to the probe trampoline). 4. When copying the ProbeContext to its new location, the trampoline should always copy words from low addresses to high addresses. This is because if we're moving the ProbeContext, we'll always be moving it to a lower address. * assembler/MacroAssembler.h: * assembler/MacroAssemblerARM.cpp: * assembler/MacroAssemblerARM64.cpp: * assembler/MacroAssemblerARMv7.cpp: * assembler/MacroAssemblerX86Common.cpp: * assembler/testmasm.cpp: (JSC::testProbePreservesGPRS): (JSC::testProbeModifiesStackPointer): (JSC::fillStack): (JSC::testProbeModifiesStackWithCallback): (JSC::run): 2017-08-16 Csaba Osztrogonác Fix JSCOnly ARM buildbots after r220047 and r220184 https://bugs.webkit.org/show_bug.cgi?id=174993 Reviewed by Carlos Alberto Lopez Perez. * CMakeLists.txt: Generate only one backend on Linux to save build time. 2017-08-16 Andy Estes [Payment Request] Add an ENABLE flag and an experimental feature preference https://bugs.webkit.org/show_bug.cgi?id=175622 Reviewed by Tim Horton. * Configurations/FeatureDefines.xcconfig: 2017-08-15 Robin Morisset We are too conservative about the effects of PushWithScope https://bugs.webkit.org/show_bug.cgi?id=175584 Reviewed by Saam Barati. PushWithScope converts its argument to an object (this can throw a type error, but has no other observable effect), and allocates a new scope, that it then makes the new current scope. We were a bit too conservative in saying that it clobbers the world. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): 2017-08-15 Ryosuke Niwa Make DataTransferItemList work with plain text entries https://bugs.webkit.org/show_bug.cgi?id=175596 Reviewed by Wenson Hsieh. Added DataTransferItem as a common identifier since it's a runtime enabled feature. * runtime/CommonIdentifiers.h: 2017-08-15 Robin Morisset Support the 'with' keyword in FTL https://bugs.webkit.org/show_bug.cgi?id=175585 Reviewed by Saam Barati. Also makes sure that the order of arguments of PushWithScope, op_push_with_scope, JSWithScope::create() and so on is consistent (always parentScope first, the new scopeObject second). We used to go from one to the other at different step which was quite confusing. I picked this order for consistency with CreateActivation that takes its parentScope argument first. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitPushWithScope): * debugger/DebuggerCallFrame.cpp: (JSC::DebuggerCallFrame::evaluateWithScopeExtension): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compilePushWithScope): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compilePushWithScope): * jit/JITOperations.cpp: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/Completion.cpp: (JSC::evaluateWithScopeExtension): * runtime/JSWithScope.cpp: (JSC::JSWithScope::create): * runtime/JSWithScope.h: 2017-08-15 Saam Barati Make VM::scratchBufferForSize thread safe https://bugs.webkit.org/show_bug.cgi?id=175604 Reviewed by Geoffrey Garen and Mark Lam. I want to use the VM::scratchBufferForSize in another patch I'm writing. The use case for my other patch is to call it from the compiler thread. When reading the code, I saw that this API was not thread safe. This patch makes it thread safe. It actually turns out we were calling this API from the compiler thread already when we created FTL::State for an FTL OSR entry compilation, and from FTLLowerDFGToB3. That code was racy and wrong, but is now correct with this patch. * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::~VM): (JSC::VM::gatherConservativeRoots): (JSC::VM::scratchBufferForSize): * runtime/VM.h: (JSC::VM::scratchBufferForSize): Deleted. 2017-08-15 Keith Miller JSC named bytecode offsets should use references rather than pointers https://bugs.webkit.org/show_bug.cgi?id=175601 Reviewed by Saam Barati. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_overrides_has_instance): (JSC::JIT::emit_op_instanceof): (JSC::JIT::emitSlow_op_instanceof): (JSC::JIT::emitSlow_op_instanceof_custom): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_overrides_has_instance): (JSC::JIT::emit_op_instanceof): (JSC::JIT::emitSlow_op_instanceof): (JSC::JIT::emitSlow_op_instanceof_custom): 2017-08-15 Keith Miller Enable named offsets into JSC bytecodes https://bugs.webkit.org/show_bug.cgi?id=175561 Reviewed by Mark Lam. This patch adds the ability to add named offsets into JSC's bytecodes. In the bytecode json file, instead of listing a length, you can now list a set of names and their types. Each opcode with an offsets property will have a struct named after the opcode by in our C++ naming style. For example, op_overrides_has_instance would become OpOverridesHasInstance. The struct has the same memory layout as the instruction list has but comes with handy named accessors. As a first cut I converted the various instanceof bytecodes to use named offsets. As an example op_overrides_has_instance produces the following struct: struct OpOverridesHasInstance { public: Opcode& opcode() { return *reinterpret_cast(&m_opcode); } const Opcode& opcode() const { return *reinterpret_cast(&m_opcode); } int& dst() { return *reinterpret_cast(&m_dst); } const int& dst() const { return *reinterpret_cast(&m_dst); } int& constructor() { return *reinterpret_cast(&m_constructor); } const int& constructor() const { return *reinterpret_cast(&m_constructor); } int& hasInstanceValue() { return *reinterpret_cast(&m_hasInstanceValue); } const int& hasInstanceValue() const { return *reinterpret_cast(&m_hasInstanceValue); } private: friend class LLIntOffsetsExtractor; std::aligned_storage::type m_opcode; std::aligned_storage::type m_dst; std::aligned_storage::type m_constructor; std::aligned_storage::type m_hasInstanceValue; }; * CMakeLists.txt: * DerivedSources.make: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/BytecodeList.json: * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * generate-bytecode-files: * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_overrides_has_instance): (JSC::JIT::emit_op_instanceof): (JSC::JIT::emitSlow_op_instanceof): (JSC::JIT::emitSlow_op_instanceof_custom): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_overrides_has_instance): (JSC::JIT::emit_op_instanceof): (JSC::JIT::emitSlow_op_instanceof): (JSC::JIT::emitSlow_op_instanceof_custom): * llint/LLIntOffsetsExtractor.cpp: * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: 2017-08-15 Mark Lam Update testmasm to use new CPUState APIs. https://bugs.webkit.org/show_bug.cgi?id=175573 Reviewed by Keith Miller. 1. Applied convenience CPUState accessors to minimize casting. 2. Converted the CHECK macro to CHECK_EQ to get more friendly failure debugging messages. 3. Removed the CHECK_DOUBLE_BITWISE_EQ macro. We can just use CHECK_EQ now since casting is (mostly) no longer an issue. 4. Replaced the use of testDoubleWord(id) with bitwise_cast(testWord64(id)) to make it clear that we're comparing against the bit values of testWord64(id). 5. Added a "Completed N tests" message at the end of running all tests. This makes it easy to tell at a glance that testmasm completed successfully versus when it crashed midway in a test. The number of tests also serves as a quick checksum to confirm that we ran the number of tests we expected. * assembler/testmasm.cpp: (WTF::printInternal): (JSC::testSimple): (JSC::testProbeReadsArgumentRegisters): (JSC::testProbeWritesArgumentRegisters): (JSC::testProbePreservesGPRS): (JSC::testProbeModifiesStackPointer): (JSC::testProbeModifiesProgramCounter): (JSC::run): 2017-08-14 Keith Miller Add testing tool to lie to the DFG about profiles https://bugs.webkit.org/show_bug.cgi?id=175487 Reviewed by Saam Barati. This patch adds a new bytecode identity_with_profile that lets us lie to the DFG about what profiles it has seen as the input to another bytecode. Previously, there was no reliable way to force a given profile when we tired up. * bytecode/BytecodeDumper.cpp: (JSC::BytecodeDumper::dumpBytecode): * bytecode/BytecodeIntrinsicRegistry.h: * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/SpeculatedType.cpp: (JSC::speculationFromString): * bytecode/SpeculatedType.h: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitIdWithProfile): * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::BytecodeIntrinsicNode::emit_intrinsic_idWithProfile): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGMayExit.cpp: * dfg/DFGNode.h: (JSC::DFG::Node::getForcedPrediction): * 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): * dfg/DFGValidate.cpp: * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JIT.h: * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_identity_with_profile): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_identity_with_profile): * llint/LowLevelInterpreter.asm: 2017-08-14 Simon Fraser Remove Proximity Events and related code https://bugs.webkit.org/show_bug.cgi?id=175545 Reviewed by Daniel Bates. No platform enables Proximity Events, so remove code inside ENABLE(PROXIMITY_EVENTS) and other related code. * Configurations/FeatureDefines.xcconfig: 2017-08-14 Simon Fraser Remove ENABLE(REQUEST_AUTOCOMPLETE) code, which was disabled everywhere https://bugs.webkit.org/show_bug.cgi?id=175504 Reviewed by Sam Weinig. * Configurations/FeatureDefines.xcconfig: 2017-08-14 Simon Fraser Remove ENABLE_VIEW_MODE_CSS_MEDIA and related code https://bugs.webkit.org/show_bug.cgi?id=175557 Reviewed by Jon Lee. No port cares about the ENABLE(VIEW_MODE_CSS_MEDIA) feature, so remove it. * Configurations/FeatureDefines.xcconfig: 2017-08-14 Robin Morisset Support the 'with' keyword in DFG https://bugs.webkit.org/show_bug.cgi?id=175470 Reviewed by Saam Barati. Not particularly optimized at the moment, the goal is just to avoid the DFG bailing out of any function with this keyword. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compilePushWithScope): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * jit/JITOperations.cpp: * jit/JITOperations.h: 2017-08-14 Mark Lam Add some convenience utility accessor methods to MacroAssembler::CPUState. https://bugs.webkit.org/show_bug.cgi?id=175549 Reviewed by Saam Barati. Previously, in order to read ProbeContext CPUState registers, we used to need to do it this way: ExecState* exec = reinterpret_cast(cpu.fp()); uint32_t i32 = static_cast(cpu.gpr(GPRInfo::regT0)); void* p = reinterpret_cast(cpu.gpr(GPRInfo::regT1)); uint64_t u64 = bitwise_cast(cpu.fpr(FPRInfo::fpRegT0)); With this patch, we can now read them this way instead: ExecState* exec = cpu.fp(); uint32_t i32 = cpu.gpr(GPRInfo::regT0); void* p = cpu.gpr(GPRInfo::regT1); uint64_t u64 = cpu.fpr(FPRInfo::fpRegT0); * assembler/MacroAssembler.h: (JSC:: const): (JSC::MacroAssembler::CPUState::fpr const): (JSC::MacroAssembler::CPUState::pc const): (JSC::MacroAssembler::CPUState::fp const): (JSC::MacroAssembler::CPUState::sp const): (JSC::ProbeContext::pc): (JSC::ProbeContext::fp): (JSC::ProbeContext::sp): 2017-08-12 Filip Pizlo Put the ScopedArgumentsTable's ScopeOffset array in some gigacage https://bugs.webkit.org/show_bug.cgi?id=174921 Reviewed by Mark Lam. Uses CagedUniquePtr<> to cage the ScopeOffset array. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal): * jit/JITPropertyAccess.cpp: (JSC::JIT::emitScopedArgumentsGetByVal): * runtime/ScopedArgumentsTable.cpp: (JSC::ScopedArgumentsTable::create): (JSC::ScopedArgumentsTable::setLength): * runtime/ScopedArgumentsTable.h: 2017-08-14 Mark Lam Gardening: fix Windows build. https://bugs.webkit.org/show_bug.cgi?id=175446 Not reviewed. * assembler/MacroAssemblerX86Common.cpp: (JSC::booleanTrueForAvoidingNoReturnDeclaration): (JSC::ctiMasmProbeTrampoline): 2017-08-12 Csaba Osztrogonác [ARM64] Use x29 and x30 instead of fp and lr to make GCC happy https://bugs.webkit.org/show_bug.cgi?id=175512 Reviewed by Mark Lam. * CMakeLists.txt: Added MacroAssemblerARM64.cpp. * assembler/MacroAssemblerARM64.cpp: Use x29 and x30 instead of fp and lr to make GCC happy. 2017-08-12 Csaba Osztrogonác ARM_TRADITIONAL: static assertion failed: ProbeContext_size_matches_ctiMasmProbeTrampoline https://bugs.webkit.org/show_bug.cgi?id=175513 Reviewed by Mark Lam. * assembler/MacroAssemblerARM.cpp: Added d16-d31 FP registers too. 2017-08-12 Filip Pizlo FTL's compileGetTypedArrayByteOffset needs to do caging https://bugs.webkit.org/show_bug.cgi?id=175366 Reviewed by Saam Barati. While implementing boxing in the DFG, I noticed that there was some missing boxing in the FTL. This fixes the case in GetTypedArrayByteOffset, and files FIXMEs for more such cases. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset): (JSC::FTL::DFG::LowerDFGToB3::cagedMayBeNull): * runtime/ArrayBuffer.h: * runtime/ArrayBufferView.h: * runtime/JSArrayBufferView.h: 2017-08-11 Ryosuke Niwa Replace DATA_TRANSFER_ITEMS by a runtime flag and add a stub implementation https://bugs.webkit.org/show_bug.cgi?id=175474 Reviewed by Wenson Hsieh. * Configurations/FeatureDefines.xcconfig: * runtime/CommonIdentifiers.h: 2017-08-11 Filip Pizlo Caging shouldn't have to use a patchpoint for adding https://bugs.webkit.org/show_bug.cgi?id=175483 Reviewed by Mark Lam. Caging involves doing a Add(ptr, largeConstant). All of B3's heuristics for how to deal with constants and associative operations dictate that you always want to sink constants. For example, Add(Add(a, constant), b) always becomes Add(Add(a, b), constant). This is profitable because in typical code, it reveals downstream optimizations. But it's terrible in the case of caging, because we want the large constant (which is shared by all caging operations) to be hoisted. Reassociating to sink constants obscures the constant in this case. Currently, moveConstants is not smart enough to reassociate, so instead of sinking largeConstant, it tries (and often fails) to sink some other constants instead. Without some hacks, this is a 5% Kraken regression and a 1.6% Octane regression. It's not clear that moveConstants could ever be smart enough to rematerialize that constant and then hoist it - that would require quite a bit of algebraic reasoning. But the only case we know of where our current constant reassociation heuristics are wrong is caging. So, we can get away with some hacks for just stopping B3's reassociation only in this specific case. Previously, we achieved this by concealing the Add(ptr, largeConstant) inside a patchpoint. That's OK, but patchpoints are expensive. They require a SharedTask instance. They require callbacks from the backend, including during register allocation. And they cannot be CSE'd. We do want B3 to know that if we cage the same pointer in two places, both places will compute the same value. This patch improves the situation by introducing the Opaque opcode. This is handled by LowerToAir as if it was Identity, but all prior phases treat it as an unknown pure unary idempotent operation. I.e. they know that Opaque(x) == Opaque(x) and that Opaque(Opaque(x)) == Opaque(x). But they don't know that Opaque(x) == x until LowerToAir. So, you can use Opaque exactly when you know that B3 will mess up your code but Air won't. (Currently we know of no cases where Air messes things up on a large enough scale to warrant new opcodes.) This change is perf-neutral, but may start to help as I add more uses of caged() in the FTL. It also makes the code a bit less ugly. * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::shouldCopyPropagate): (JSC::B3::Air::LowerToAir::lower): * b3/B3Opcode.cpp: (WTF::printInternal): * b3/B3Opcode.h: * b3/B3ReduceStrength.cpp: * b3/B3Validate.cpp: * b3/B3Value.cpp: (JSC::B3::Value::effects const): (JSC::B3::Value::key const): (JSC::B3::Value::isFree const): (JSC::B3::Value::typeFor): * b3/B3Value.h: * b3/B3ValueKey.cpp: (JSC::B3::ValueKey::materialize const): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::caged): * ftl/FTLOutput.cpp: (JSC::FTL::Output::opaque): * ftl/FTLOutput.h: 2017-08-11 Filip Pizlo ScopedArguments overflow storage needs to be in the JSValue gigacage https://bugs.webkit.org/show_bug.cgi?id=174923 Reviewed by Saam Barati. ScopedArguments overflow storage sits at the end of the ScopedArguments object, so we put that object into the JSValue gigacage. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal): * jit/JITPropertyAccess.cpp: (JSC::JIT::emitScopedArgumentsGetByVal): * runtime/ScopedArguments.h: (JSC::ScopedArguments::subspaceFor): (JSC::ScopedArguments::overflowStorage const): 2017-08-11 Filip Pizlo JSLexicalEnvironment needs to be in the JSValue gigacage https://bugs.webkit.org/show_bug.cgi?id=174922 Reviewed by Michael Saboff. We can sorta random access the JSLexicalEnvironment. So, we put it in the JSValue gigacage and make the only random accesses use pointer caging. We don't need to do anything to normal lexical environment accesses. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal): * runtime/JSEnvironmentRecord.h: (JSC::JSEnvironmentRecord::subspaceFor): (JSC::JSEnvironmentRecord::variables): 2017-08-11 Filip Pizlo DirectArguments should be in the JSValue gigacage https://bugs.webkit.org/show_bug.cgi?id=174920 Reviewed by Michael Saboff. This puts DirectArguments in a new subspace for cells that want to be in the JSValue gigacage. All indexed accesses to DirectArguments now do caging. get_from_arguments/put_to_arguments are exempted because they always operate on a DirectArguments that is pointed to directly from the stack, they are required to use fixed offsets, and you can only store JSValues. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetByValOnDirectArguments): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal): * jit/JITPropertyAccess.cpp: (JSC::JIT::emitDirectArgumentsGetByVal): * runtime/DirectArguments.h: (JSC::DirectArguments::subspaceFor): (JSC::DirectArguments::storage): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2017-08-11 Filip Pizlo Unreviewed, add a FIXME. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::caged): 2017-08-10 Sam Weinig WTF::Function does not allow for reference / non-default constructible return types https://bugs.webkit.org/show_bug.cgi?id=175244 Reviewed by Chris Dumez. * runtime/ArrayBuffer.cpp: (JSC::ArrayBufferContents::transferTo): Call reset(), rather than clear() to avoid the call to destroy() in clear(). The destroy call needed to be a no-op anyway, since the data is being moved. 2017-08-11 Mark Lam Gardening: fix CLoop build. https://bugs.webkit.org/show_bug.cgi?id=175446 Not reviewed. * assembler/MacroAssemblerPrinter.cpp: 2017-08-08 Filip Pizlo DFG should do caging https://bugs.webkit.org/show_bug.cgi?id=174918 Reviewed by Saam Barati. Adds the appropriate cage() calls to the DFG, including a cageTypedArrayStorage() helper that does the conditional caging with a watchpoint. This might be a 1% SunSpider slow-down, but it's not clear. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage): (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage): (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset): (JSC::DFG::SpeculativeJIT::compileCreateRest): (JSC::DFG::SpeculativeJIT::compileSpread): (JSC::DFG::SpeculativeJIT::compileNewArrayWithSpread): (JSC::DFG::SpeculativeJIT::compileArraySlice): (JSC::DFG::SpeculativeJIT::compileGetButterfly): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2017-08-11 Yusuke Suzuki Unreviewed, build fix for x86 GTK port https://bugs.webkit.org/show_bug.cgi?id=175446 Use pushfl/popfl instead of pushfd/popfd. * assembler/MacroAssemblerX86Common.cpp: 2017-08-10 Mark Lam Make the MASM_PROBE mechanism mandatory for DFG and FTL builds. https://bugs.webkit.org/show_bug.cgi?id=175446 Reviewed by Saam Barati. * assembler/AbstractMacroAssembler.h: * assembler/MacroAssembler.cpp: (JSC::MacroAssembler::probe): * assembler/MacroAssembler.h: * assembler/MacroAssemblerARM.cpp: (JSC::MacroAssembler::probe): * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::trustedImm32FromPtr): * assembler/MacroAssemblerARM64.cpp: (JSC::MacroAssembler::probe): * assembler/MacroAssemblerARMv7.cpp: (JSC::MacroAssembler::probe): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::trustedImm32FromPtr): * assembler/MacroAssemblerPrinter.cpp: * assembler/MacroAssemblerPrinter.h: * assembler/MacroAssemblerX86Common.cpp: * assembler/testmasm.cpp: (JSC::isSpecialGPR): (JSC::testProbeModifiesProgramCounter): (JSC::run): * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::print): * b3/air/AirPrintSpecial.cpp: * b3/air/AirPrintSpecial.h: 2017-08-10 Mark Lam Apply the UNLIKELY macro to some unlikely things. https://bugs.webkit.org/show_bug.cgi?id=175440 Reviewed by Yusuke Suzuki. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::~CodeBlock): (JSC::CodeBlock::jettison): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleCall): (JSC::DFG::ByteCodeParser::handleVarargsCall): (JSC::DFG::ByteCodeParser::handleGetById): (JSC::DFG::ByteCodeParser::handlePutById): (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::parseCodeBlock): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::JITCompiler): (JSC::DFG::JITCompiler::linkOSRExits): (JSC::DFG::JITCompiler::link): (JSC::DFG::JITCompiler::disassemble): * dfg/DFGJITFinalizer.cpp: (JSC::DFG::JITFinalizer::finalizeCommon): * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::compileOSRExit): * dfg/DFGPlan.cpp: (JSC::DFG::Plan::Plan): * ftl/FTLJITFinalizer.cpp: (JSC::FTL::JITFinalizer::finalizeCommon): * ftl/FTLLink.cpp: (JSC::FTL::link): * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::compileWithoutLinking): (JSC::JIT::link): * runtime/ScriptExecutable.cpp: (JSC::ScriptExecutable::installCode): * runtime/VM.cpp: (JSC::VM::VM): 2017-08-09 Yusuke Suzuki [WTF] ThreadSpecific should not introduce additional indirection https://bugs.webkit.org/show_bug.cgi?id=175187 Reviewed by Mark Lam. * runtime/Identifier.cpp: 2017-08-10 Tim Horton Remove some unused lambda captures so that WebKit builds with -Wunused-lambda-capture https://bugs.webkit.org/show_bug.cgi?id=175436 Reviewed by Simon Fraser. * interpreter/Interpreter.cpp: (JSC::Interpreter::Interpreter): 2017-08-10 Michael Catanzaro Remove ENABLE_GAMEPAD_DEPRECATED https://bugs.webkit.org/show_bug.cgi?id=175361 Reviewed by Carlos Garcia Campos. * Configurations/FeatureDefines.xcconfig: 2017-08-09 Caio Lima [JSC] Create JSSet constructor that accepts it's size as parameter https://bugs.webkit.org/show_bug.cgi?id=173297 Reviewed by Saam Barati. This patch is adding a new constructor to JSSet that gives its expected initial size. It is important to avoid re-hashing and mutiple allocations when we know the final size of JSSet, such as in CodeBlock::setConstantIdentifierSetRegisters. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::setConstantIdentifierSetRegisters): * runtime/HashMapImpl.h: (JSC::HashMapImpl::HashMapImpl): * runtime/JSSet.h: 2017-08-09 Commit Queue Unreviewed, rolling out r220466, r220477, and r220487. https://bugs.webkit.org/show_bug.cgi?id=175411 This change broke existing API tests and follow up fixes did not resolve all the issues. (Requested by ryanhaddad on #webkit). Reverted changesets: https://bugs.webkit.org/show_bug.cgi?id=175244 http://trac.webkit.org/changeset/220466 "WTF::Function does not allow for reference / non-default constructible return types" https://bugs.webkit.org/show_bug.cgi?id=175244 http://trac.webkit.org/changeset/220477 https://bugs.webkit.org/show_bug.cgi?id=175244 http://trac.webkit.org/changeset/220487 2017-08-09 Caitlin Potter Early error on ANY operator before new.target https://bugs.webkit.org/show_bug.cgi?id=157970 Reviewed by Saam Barati. Instead of throwing if any unary operator precedes new.target, only throw if the unary operator updates the reference. The following become legal in JSC: ``` !new.target ~new.target typeof new.target delete new.target void new.target ``` All of which are legal in v8 and SpiderMonkey in strict and sloppy mode * parser/Parser.cpp: (JSC::Parser::parseUnaryExpression): 2017-08-09 Sam Weinig WTF::Function does not allow for reference / non-default constructible return types https://bugs.webkit.org/show_bug.cgi?id=175244 Reviewed by Chris Dumez. * runtime/ArrayBuffer.cpp: (JSC::ArrayBufferContents::transferTo): Call reset(), rather than clear() to avoid the call to destroy() in clear(). The destroy call needed to be a no-op anyway, since the data is being moved. 2017-08-09 Wenson Hsieh [iOS DnD] ENABLE_DRAG_SUPPORT should be turned off for iOS 10 and enabled by default https://bugs.webkit.org/show_bug.cgi?id=175392 Reviewed by Tim Horton and Megan Gardner. Tweak FeatureDefines to enable drag and drop by default, and disable only on unsupported platforms (i.e. iOS 10). * Configurations/FeatureDefines.xcconfig: 2017-08-09 Robin Morisset Make JSC_validateExceptionChecks=1 succeed on JSTests/stress/v8-deltablue-strict.js. https://bugs.webkit.org/show_bug.cgi?id=175358 Reviewed by Mark Lam. * jit/JITOperations.cpp: * runtime/JSObjectInlines.h: (JSC::JSObject::putInlineForJSObject): 2017-08-09 Ryan Haddad Unreviewed, rolling out r220457. This change introduced API test failures. Reverted changeset: "WTF::Function does not allow for reference / non-default constructible return types" https://bugs.webkit.org/show_bug.cgi?id=175244 http://trac.webkit.org/changeset/220457 2017-08-09 Sam Weinig WTF::Function does not allow for reference / non-default constructible return types https://bugs.webkit.org/show_bug.cgi?id=175244 Reviewed by Chris Dumez. * runtime/ArrayBuffer.cpp: (JSC::ArrayBufferContents::transferTo): Call reset(), rather than clear() to avoid the call to destroy() in clear(). The destroy call needed to be a no-op anyway, since the data is being moved. 2017-08-09 Oleksandr Skachkov REGRESSION: 2 test262/test/language/statements/async-function failures https://bugs.webkit.org/show_bug.cgi?id=175334 Reviewed by Yusuke Suzuki. Switch off useAsyncIterator by default * runtime/Options.h: 2017-08-08 Filip Pizlo ICs should do caging https://bugs.webkit.org/show_bug.cgi?id=175295 Reviewed by Saam Barati. Adds the appropriate cage() calls in our inline caches. * bytecode/AccessCase.cpp: (JSC::AccessCase::generateImpl): * bytecode/InlineAccess.cpp: (JSC::InlineAccess::dumpCacheSizesAndCrash): (JSC::InlineAccess::generateSelfPropertyAccess): (JSC::InlineAccess::generateSelfPropertyReplace): (JSC::InlineAccess::generateArrayLength): 2017-08-08 Devin Rousso Web Inspector: Canvas: support editing WebGL shaders https://bugs.webkit.org/show_bug.cgi?id=124211 Reviewed by Matt Baker. * inspector/protocol/Canvas.json: Add `updateShader` command that will change the given shader's source to the provided string, recompile, and relink it to its associated program. Drive-by: add description to `requestShaderSource` command. 2017-08-08 Robin Morisset Make JSC_validateExceptionChecks=1 succeed on JSTests/slowMicrobenchmarks/spread-small-array.js. https://bugs.webkit.org/show_bug.cgi?id=175347 Reviewed by Saam Barati. This is done by making finishCreation explicitely check for exceptions after setConstantRegister and setConstantIdentifiersSetRegisters. I chose to have this check replace the boolean returned previously by these functions for readability. The performance impact should be negligible considering how much more finishCreation does. This fix then caused another issue to appear as it was now clear that finishCreation can throw. And since it is called by ProgramCodeBlock::create(), FunctionCodeBlock::create() and friends, that are in turn called by ScriptExecutable::newCodeBlockFor, this last function also required a few tweaks. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): (JSC::CodeBlock::setConstantIdentifierSetRegisters): (JSC::CodeBlock::setConstantRegisters): * bytecode/CodeBlock.h: * runtime/ScriptExecutable.cpp: (JSC::ScriptExecutable::newCodeBlockFor): 2017-08-08 Michael Catanzaro Unreviewed, fix Ubuntu LTS build https://bugs.webkit.org/show_bug.cgi?id=174490 * inspector/remote/glib/RemoteInspectorGlib.cpp: * inspector/remote/glib/RemoteInspectorServer.cpp: 2017-08-08 Filip Pizlo Baseline JIT should do caging https://bugs.webkit.org/show_bug.cgi?id=175037 Reviewed by Mark Lam. Adds a AssemblyHelpers::cage and cageConditionally. Uses it in the baseline JIT. Also modifies FTL caging to be more defensive when caging is disabled. Relanded with fixed AssemblyHelpers::cageConditionally(). * bytecode/AccessCase.cpp: (JSC::AccessCase::generateImpl): * bytecode/InlineAccess.cpp: (JSC::InlineAccess::dumpCacheSizesAndCrash): (JSC::InlineAccess::generateSelfPropertyAccess): (JSC::InlineAccess::generateSelfPropertyReplace): (JSC::InlineAccess::generateArrayLength): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::caged): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::cage): (JSC::AssemblyHelpers::cageConditionally): * jit/JITPropertyAccess.cpp: (JSC::JIT::emitDoubleLoad): (JSC::JIT::emitContiguousLoad): (JSC::JIT::emitArrayStorageLoad): (JSC::JIT::emitGenericContiguousPutByVal): (JSC::JIT::emitArrayStoragePutByVal): (JSC::JIT::emit_op_get_from_scope): (JSC::JIT::emit_op_put_to_scope): (JSC::JIT::emitIntTypedArrayGetByVal): (JSC::JIT::emitFloatTypedArrayGetByVal): (JSC::JIT::emitIntTypedArrayPutByVal): (JSC::JIT::emitFloatTypedArrayPutByVal): * jsc.cpp: (jscmain): (primitiveGigacageDisabled): Deleted. 2017-08-08 Ryan Haddad Unreviewed, rolling out r220368. This change caused WK1 tests to exit early with crashes. Reverted changeset: "Baseline JIT should do caging" https://bugs.webkit.org/show_bug.cgi?id=175037 http://trac.webkit.org/changeset/220368 2017-08-08 Michael Catanzaro [CMake] Properly test if compiler supports compiler flags https://bugs.webkit.org/show_bug.cgi?id=174490 Reviewed by Konstantin Tokarev. * API/tests/PingPongStackOverflowTest.cpp: (testPingPongStackOverflow): * API/tests/testapi.c: * b3/testb3.cpp: (JSC::B3::testPatchpointLotsOfLateAnys): 2017-08-06 Yusuke Suzuki [Linux] Clear WasmMemory with madvice instead of memset https://bugs.webkit.org/show_bug.cgi?id=175150 Reviewed by Filip Pizlo. In Linux, zeroing pages with memset populates backing store. Instead, we should use madvise with MADV_DONTNEED. It discards pages. And if you access these pages, on-demand-zero-pages will be shown. We also commit grown pages in all OSes. * wasm/WasmMemory.cpp: (JSC::Wasm::commitZeroPages): (JSC::Wasm::Memory::create): (JSC::Wasm::Memory::grow): 2017-08-07 Robin Morisset GetOwnProperty of TypedArray indexed fields is wrongly configurable https://bugs.webkit.org/show_bug.cgi?id=175307 Reviewed by Saam Barati. ``` let a = new Uint8Array(10); let b = Object.getOwnPropertyDescriptor(a, 0); assert(b.configurable === false); ``` should not fail: by section 9.4.5.1 (https://tc39.github.io/ecma262/#sec-integer-indexed-exotic-objects-getownproperty-p) that applies to integer indexed exotic objects, and section 22.2.7 (https://tc39.github.io/ecma262/#sec-properties-of-typedarray-instances) that says that typed arrays are integer indexed exotic objects. * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::getOwnPropertySlotByIndex): 2017-08-07 Filip Pizlo Baseline JIT should do caging https://bugs.webkit.org/show_bug.cgi?id=175037 Reviewed by Mark Lam. Adds a AssemblyHelpers::cage and cageConditionally. Uses it in the baseline JIT. Also modifies FTL caging to be more defensive when caging is disabled. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::caged): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::cage): (JSC::AssemblyHelpers::cageConditionally): * jit/JITPropertyAccess.cpp: (JSC::JIT::emitDoubleLoad): (JSC::JIT::emitContiguousLoad): (JSC::JIT::emitArrayStorageLoad): (JSC::JIT::emitGenericContiguousPutByVal): (JSC::JIT::emitArrayStoragePutByVal): (JSC::JIT::emit_op_get_from_scope): (JSC::JIT::emit_op_put_to_scope): (JSC::JIT::emitIntTypedArrayGetByVal): (JSC::JIT::emitFloatTypedArrayGetByVal): (JSC::JIT::emitIntTypedArrayPutByVal): (JSC::JIT::emitFloatTypedArrayPutByVal): * jsc.cpp: (jscmain): (primitiveGigacageDisabled): Deleted. 2017-08-06 Filip Pizlo Primitive auxiliaries and JSValue auxiliaries should have separate gigacages https://bugs.webkit.org/show_bug.cgi?id=174919 Reviewed by Keith Miller. This adapts JSC to there being two gigacages. To make matters simpler, this turns AlignedMemoryAllocators into per-VM instances rather than singletons. I don't think we were gaining anything by making them be singletons. This makes it easy to teach GigacageAlignedMemoryAllocator that there are multiple kinds of gigacages. We'll have one of those allocators per cage. From there, this change teaches everyone who previously knew about cages that there are two cages. This means having to specify either Gigacage::Primitive or Gigacage::JSValue. In most places, this is easy: typed arrays are Primitive and butterflies are JSValue. But there are a few places where it's not so obvious, so this change introduces some helpers to make it easy to define what cage you want to use in one place and refer to it abstractly. We do this in DirectArguments and GenericArguments.h A lot of the magic of this change is due to CagedBarrierPtr, which combines AuxiliaryBarrier and CagedPtr. This removes one layer of "get()" calls from a bunch of places. * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/AccessCase.cpp: (JSC::AccessCase::generateImpl): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::emitAllocateRawObject): (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage): (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage): (JSC::DFG::SpeculativeJIT::compileNewTypedArray): (JSC::DFG::SpeculativeJIT::emitAllocateButterfly): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileGetButterfly): (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage): (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray): (JSC::FTL::DFG::LowerDFGToB3::compileGetDirectPname): (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject): (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorageWithSizeImpl): (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray): (JSC::FTL::DFG::LowerDFGToB3::caged): * heap/FastMallocAlignedMemoryAllocator.cpp: (JSC::FastMallocAlignedMemoryAllocator::instance): Deleted. * heap/FastMallocAlignedMemoryAllocator.h: * heap/GigacageAlignedMemoryAllocator.cpp: (JSC::GigacageAlignedMemoryAllocator::GigacageAlignedMemoryAllocator): (JSC::GigacageAlignedMemoryAllocator::tryAllocateAlignedMemory): (JSC::GigacageAlignedMemoryAllocator::freeAlignedMemory): (JSC::GigacageAlignedMemoryAllocator::dump const): (JSC::GigacageAlignedMemoryAllocator::instance): Deleted. * heap/GigacageAlignedMemoryAllocator.h: * jsc.cpp: (primitiveGigacageDisabled): (jscmain): (gigacageDisabled): Deleted. * llint/LowLevelInterpreter64.asm: * runtime/ArrayBuffer.cpp: (JSC::ArrayBufferContents::tryAllocate): (JSC::ArrayBuffer::createAdopted): (JSC::ArrayBuffer::createFromBytes): * runtime/AuxiliaryBarrier.h: * runtime/ButterflyInlines.h: (JSC::Butterfly::createUninitialized): (JSC::Butterfly::tryCreate): (JSC::Butterfly::growArrayRight): * runtime/CagedBarrierPtr.h: Added. (JSC::CagedBarrierPtr::CagedBarrierPtr): (JSC::CagedBarrierPtr::clear): (JSC::CagedBarrierPtr::set): (JSC::CagedBarrierPtr::get const): (JSC::CagedBarrierPtr::getMayBeNull const): (JSC::CagedBarrierPtr::operator== const): (JSC::CagedBarrierPtr::operator!= const): (JSC::CagedBarrierPtr::operator bool const): (JSC::CagedBarrierPtr::setWithoutBarrier): (JSC::CagedBarrierPtr::operator* const): (JSC::CagedBarrierPtr::operator-> const): (JSC::CagedBarrierPtr::operator[] const): * runtime/DirectArguments.cpp: (JSC::DirectArguments::overrideThings): (JSC::DirectArguments::unmapArgument): * runtime/DirectArguments.h: (JSC::DirectArguments::isMappedArgument const): * runtime/GenericArguments.h: * runtime/GenericArgumentsInlines.h: (JSC::GenericArguments::initModifiedArgumentsDescriptor): (JSC::GenericArguments::setModifiedArgumentDescriptor): (JSC::GenericArguments::isModifiedArgumentDescriptor): * runtime/HashMapImpl.cpp: (JSC::HashMapImpl::visitChildren): * runtime/HashMapImpl.h: (JSC::HashMapBuffer::create): (JSC::HashMapImpl::buffer const): (JSC::HashMapImpl::rehash): * runtime/JSArray.cpp: (JSC::JSArray::tryCreateUninitializedRestricted): (JSC::JSArray::unshiftCountSlowCase): (JSC::JSArray::setLength): (JSC::JSArray::pop): (JSC::JSArray::push): (JSC::JSArray::fastSlice): (JSC::JSArray::shiftCountWithArrayStorage): (JSC::JSArray::shiftCountWithAnyIndexingType): (JSC::JSArray::unshiftCountWithAnyIndexingType): (JSC::JSArray::fillArgList): (JSC::JSArray::copyToArguments): * runtime/JSArray.h: (JSC::JSArray::tryCreate): * runtime/JSArrayBufferView.cpp: (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext): (JSC::JSArrayBufferView::finalize): * runtime/JSLock.cpp: (JSC::JSLock::didAcquireLock): * runtime/JSObject.cpp: (JSC::JSObject::heapSnapshot): (JSC::JSObject::getOwnPropertySlotByIndex): (JSC::JSObject::putByIndex): (JSC::JSObject::enterDictionaryIndexingMode): (JSC::JSObject::createInitialIndexedStorage): (JSC::JSObject::createArrayStorage): (JSC::JSObject::convertUndecidedToInt32): (JSC::JSObject::convertUndecidedToDouble): (JSC::JSObject::convertUndecidedToContiguous): (JSC::JSObject::constructConvertedArrayStorageWithoutCopyingElements): (JSC::JSObject::convertUndecidedToArrayStorage): (JSC::JSObject::convertInt32ToDouble): (JSC::JSObject::convertInt32ToContiguous): (JSC::JSObject::convertInt32ToArrayStorage): (JSC::JSObject::convertDoubleToContiguous): (JSC::JSObject::convertDoubleToArrayStorage): (JSC::JSObject::convertContiguousToArrayStorage): (JSC::JSObject::setIndexQuicklyToUndecided): (JSC::JSObject::ensureArrayStorageExistsAndEnterDictionaryIndexingMode): (JSC::JSObject::deletePropertyByIndex): (JSC::JSObject::getOwnPropertyNames): (JSC::JSObject::putIndexedDescriptor): (JSC::JSObject::defineOwnIndexedProperty): (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes): (JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength): (JSC::JSObject::getNewVectorLength): (JSC::JSObject::ensureLengthSlow): (JSC::JSObject::reallocateAndShrinkButterfly): (JSC::JSObject::allocateMoreOutOfLineStorage): (JSC::JSObject::getEnumerableLength): * runtime/JSObject.h: (JSC::JSObject::getArrayLength const): (JSC::JSObject::getVectorLength): (JSC::JSObject::putDirectIndex): (JSC::JSObject::canGetIndexQuickly): (JSC::JSObject::getIndexQuickly): (JSC::JSObject::tryGetIndexQuickly const): (JSC::JSObject::canSetIndexQuickly): (JSC::JSObject::setIndexQuickly): (JSC::JSObject::initializeIndex): (JSC::JSObject::initializeIndexWithoutBarrier): (JSC::JSObject::hasSparseMap): (JSC::JSObject::inSparseIndexingMode): (JSC::JSObject::butterfly const): (JSC::JSObject::butterfly): (JSC::JSObject::outOfLineStorage const): (JSC::JSObject::outOfLineStorage): (JSC::JSObject::ensureInt32): (JSC::JSObject::ensureDouble): (JSC::JSObject::ensureContiguous): (JSC::JSObject::ensureArrayStorage): (JSC::JSObject::arrayStorage): (JSC::JSObject::arrayStorageOrNull): (JSC::JSObject::ensureLength): * runtime/RegExpMatchesArray.h: (JSC::tryCreateUninitializedRegExpMatchesArray): * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::~VM): (JSC::VM::primitiveGigacageDisabledCallback): (JSC::VM::primitiveGigacageDisabled): (JSC::VM::gigacageDisabledCallback): Deleted. (JSC::VM::gigacageDisabled): Deleted. * runtime/VM.h: (JSC::VM::gigacageAuxiliarySpace): (JSC::VM::firePrimitiveGigacageEnabledIfNecessary): (JSC::VM::primitiveGigacageEnabled): (JSC::VM::fireGigacageEnabledIfNecessary): Deleted. (JSC::VM::gigacageEnabled): Deleted. * wasm/WasmMemory.cpp: (JSC::Wasm::Memory::create): (JSC::Wasm::Memory::~Memory): (JSC::Wasm::Memory::grow): 2017-08-07 Commit Queue Unreviewed, rolling out r220144. https://bugs.webkit.org/show_bug.cgi?id=175276 "It did not actually speed things up in the way I expected" (Requested by saamyjoon on #webkit). Reverted changeset: "On memory-constrained iOS devices, reduce the rate at which the JS heap grows before a GC to try to keep more memory available for the system" https://bugs.webkit.org/show_bug.cgi?id=175041 http://trac.webkit.org/changeset/220144 2017-08-07 Ryan Haddad Unreviewed, rolling out r220299. This change caused LayoutTest inspector/dom-debugger/dom- breakpoints.html to fail. Reverted changeset: "Web Inspector: capture async stack trace when workers/main context posts a message" https://bugs.webkit.org/show_bug.cgi?id=167084 http://trac.webkit.org/changeset/220299 2017-08-07 Brian Burg Remove CANVAS_PATH compilation guard https://bugs.webkit.org/show_bug.cgi?id=175207 Reviewed by Sam Weinig. * Configurations/FeatureDefines.xcconfig: 2017-08-07 Keith Miller REGRESSION: wasm.yaml/wasm/js-api/dont-mmap-zero-byte-memory.js failing on JSC Debug bots https://bugs.webkit.org/show_bug.cgi?id=175256 Reviewed by Saam Barati. The check in createFromBytes just needed to check that the buffer was not null before calling isCaged. * runtime/ArrayBuffer.cpp: (JSC::ArrayBuffer::createFromBytes): 2017-08-05 Carlos Garcia Campos [GTK][WPE] Add API to provide browser information required by automation https://bugs.webkit.org/show_bug.cgi?id=175130 Reviewed by Brian Burg. Add browserName and browserVersion to RemoteInspector::Client::Capabilities and virtual methods to the Client to get them. * inspector/remote/RemoteInspector.cpp: (Inspector::RemoteInspector::updateClientCapabilities): Update also browserName and browserVersion. * inspector/remote/RemoteInspector.h: * inspector/remote/glib/RemoteInspectorGlib.cpp: (Inspector::RemoteInspector::requestAutomationSession): Call updateClientCapabilities() after the session is requested to ensure they are updated before StartAutomationSession reply is sent. * inspector/remote/glib/RemoteInspectorServer.cpp: Add browserName and browserVersion as return values of StartAutomationSession mesasage. 2017-08-06 Yusuke Suzuki Promise resolve and reject function should have length = 1 https://bugs.webkit.org/show_bug.cgi?id=175242 Reviewed by Saam Barati. Previously we have separate system for "length" and "name" for builtin functions. The builtin functions do not use lazy reifying system. Instead, they have direct properties when instantiating it. While the function created for properties (like Array.prototype.filter) is created by JSFunction::createBuiltin(), function inside these builtin functions are just created by JSFunction::create(). Since it does not set any values for "length", these functions do not have "length" property. So, the resolve and reject functions passed to Promise's executor do not have "length" property. This patch make builtin functions use standard lazy reifying system for "length". So, "length" property of the builtin function just works as if the normal functions do. * runtime/JSFunction.cpp: (JSC::JSFunction::createBuiltinFunction): (JSC::JSFunction::getOwnPropertySlot): (JSC::JSFunction::getOwnNonIndexPropertyNames): (JSC::JSFunction::put): (JSC::JSFunction::deleteProperty): (JSC::JSFunction::defineOwnProperty): (JSC::JSFunction::reifyLazyPropertyIfNeeded): (JSC::JSFunction::reifyLazyPropertyForHostOrBuiltinIfNeeded): (JSC::JSFunction::reifyLazyLengthIfNeeded): (JSC::JSFunction::reifyLazyBoundNameIfNeeded): (JSC::JSFunction::reifyBoundNameIfNeeded): Deleted. * runtime/JSFunction.h: 2017-08-06 Oleksandr Skachkov [ESNext] Async iteration - Implement Async Generator - parser https://bugs.webkit.org/show_bug.cgi?id=175210 Reviewed by Yusuke Suzuki. Current implementation is draft version of Async Iteration. Link to spec https://tc39.github.io/proposal-async-iteration/ Current patch implement only parser part of the Async generator Runtime part will be in next ptches * parser/ASTBuilder.h: (JSC::ASTBuilder::createFunctionMetadata): * parser/Parser.cpp: (JSC::getAsynFunctionBodyParseMode): (JSC::Parser::parseInner): (JSC::Parser::parseAsyncFunctionSourceElements): (JSC::Parser::parseAsyncGeneratorFunctionSourceElements): (JSC::stringArticleForFunctionMode): (JSC::stringForFunctionMode): (JSC::Parser::parseFunctionInfo): (JSC::Parser::parseAsyncFunctionDeclaration): (JSC::Parser::parseClass): (JSC::Parser::parseProperty): (JSC::Parser::parsePropertyMethod): (JSC::Parser::parseAsyncFunctionExpression): * parser/Parser.h: (JSC::Scope::setSourceParseMode): * parser/ParserModes.h: (JSC::isFunctionParseMode): (JSC::isAsyncFunctionParseMode): (JSC::isAsyncArrowFunctionParseMode): (JSC::isAsyncGeneratorFunctionParseMode): (JSC::isAsyncFunctionOrAsyncGeneratorWrapperParseMode): (JSC::isAsyncFunctionWrapperParseMode): (JSC::isAsyncFunctionBodyParseMode): (JSC::isGeneratorMethodParseMode): (JSC::isAsyncMethodParseMode): (JSC::isAsyncGeneratorMethodParseMode): (JSC::isMethodParseMode): (JSC::isGeneratorOrAsyncFunctionBodyParseMode): (JSC::isGeneratorOrAsyncFunctionWrapperParseMode): 2017-08-05 Filip Pizlo REGRESSION (r219895-219897): Number of leaks on Open Source went from 9240 to 235983 and is now at 302372 https://bugs.webkit.org/show_bug.cgi?id=175083 Reviewed by Oliver Hunt. This fixes the leak by making MarkedBlock::specializedSweep call destructors when the block is empty, even if we are using the pop path. Also, this fixes HeapCellInlines.h to no longer include MarkedBlockInlines.h. That's pretty important, since MarkedBlockInlines.h is the GC's internal guts - we don't want to have to recompile the world just because we changed it. Finally, this adds a new testing SPI for waiting for all VMs to finish destructing. This makes it easier to debug leaks. * bytecode/AccessCase.cpp: * bytecode/PolymorphicAccess.cpp: * heap/HeapCell.cpp: (JSC::HeapCell::isLive): * heap/HeapCellInlines.h: (JSC::HeapCell::isLive): Deleted. * heap/MarkedAllocator.cpp: (JSC::MarkedAllocator::tryAllocateWithoutCollecting): (JSC::MarkedAllocator::endMarking): * heap/MarkedBlockInlines.h: (JSC::MarkedBlock::Handle::specializedSweep): * jit/AssemblyHelpers.cpp: * jit/Repatch.cpp: * runtime/TestRunnerUtils.h: * runtime/VM.cpp: (JSC::waitForVMDestruction): (JSC::VM::~VM): 2017-08-05 Mark Lam Move DFG::OSRExitCompiler methods into DFG::OSRExit [step 3]. https://bugs.webkit.org/show_bug.cgi?id=175228 Reviewed by Saam Barati. Merge the 32-bit OSRExit::compileExit() method into the 64-bit version, and delete OSRExit32_64.cpp. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::compileExit): * dfg/DFGOSRExit32_64.cpp: Removed. * jit/GPRInfo.h: (JSC::JSValueSource::payloadGPR const): 2017-08-04 Youenn Fablet [Cache API] Add Cache and CacheStorage IDL definitions https://bugs.webkit.org/show_bug.cgi?id=175201 Reviewed by Brady Eidson. * runtime/CommonIdentifiers.h: 2017-08-04 Mark Lam Fix typo in testmasm.cpp: ENABLE(JSVALUE64) should be USE(JSVALUE64). https://bugs.webkit.org/show_bug.cgi?id=175230 Reviewed by Saam Barati. * assembler/testmasm.cpp: (JSC::testProbeReadsArgumentRegisters): (JSC::testProbeWritesArgumentRegisters): 2017-08-04 Mark Lam Move DFG::OSRExitCompiler methods into DFG::OSRExit [step 2]. https://bugs.webkit.org/show_bug.cgi?id=175214 Rubber-stamped by Michael Saboff. Copy the 64-bit and common methods into DFGOSRExit.cpp, and delete the unused DFGOSRExitCompiler files. Also renamed DFGOSRExitCompiler32_64.cpp to DFGOSRExit32_64.cpp. Also move debugOperationPrintSpeculationFailure() into DFGOSRExit.cpp. It's only used by compileOSRExit(), and will be changed to not be a DFG operation function when we use JIT probes for DFG OSR exits later in https://bugs.webkit.org/show_bug.cgi?id=175144. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGJITCompiler.cpp: * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::emitRestoreArguments): (JSC::DFG::OSRExit::compileOSRExit): (JSC::DFG::OSRExit::compileExit): (JSC::DFG::OSRExit::debugOperationPrintSpeculationFailure): * dfg/DFGOSRExit.h: * dfg/DFGOSRExit32_64.cpp: Copied from Source/JavaScriptCore/dfg/DFGOSRExitCompiler32_64.cpp. * dfg/DFGOSRExitCompiler.cpp: Removed. * dfg/DFGOSRExitCompiler.h: Removed. * dfg/DFGOSRExitCompiler32_64.cpp: Removed. * dfg/DFGOSRExitCompiler64.cpp: Removed. * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGThunks.cpp: 2017-08-04 Matt Baker Web Inspector: capture async stack trace when workers/main context posts a message https://bugs.webkit.org/show_bug.cgi?id=167084 Reviewed by Brian Burg. * inspector/agents/InspectorDebuggerAgent.h: Add `PostMessage` async call type. 2017-08-04 Mark Lam Move DFG::OSRExitCompiler methods into DFG::OSRExit [step 1]. https://bugs.webkit.org/show_bug.cgi?id=175208 Reviewed by Saam Barati. This will minimize the code diff and make it easier to review the patch for https://bugs.webkit.org/show_bug.cgi?id=175144 later. We'll do this patch in 3 steps: 1. Do the code changes to move methods into OSRExit. 2. Copy the 64-bit and common methods into DFGOSRExit.cpp, and delete the unused DFGOSRExitCompiler files. 3. Merge the 32-bit OSRExitCompiler methods into the 64-bit version, and delete DFGOSRExitCompiler32_64.cpp. Splitting this refactoring into these 3 steps also makes it easier to review this patch and understand what is being changed. * dfg/DFGOSRExit.h: * dfg/DFGOSRExitCompiler.cpp: (JSC::DFG::OSRExit::emitRestoreArguments): (JSC::DFG::OSRExit::compileOSRExit): (JSC::DFG::OSRExitCompiler::emitRestoreArguments): Deleted. (): Deleted. * dfg/DFGOSRExitCompiler.h: (JSC::DFG::OSRExitCompiler::OSRExitCompiler): Deleted. (): Deleted. * dfg/DFGOSRExitCompiler32_64.cpp: (JSC::DFG::OSRExit::compileExit): (JSC::DFG::OSRExitCompiler::compileExit): Deleted. * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExit::compileExit): (JSC::DFG::OSRExitCompiler::compileExit): Deleted. * dfg/DFGThunks.cpp: (JSC::DFG::osrExitGenerationThunkGenerator): 2017-08-04 Devin Rousso Web Inspector: add source view for WebGL shader programs https://bugs.webkit.org/show_bug.cgi?id=138593 Reviewed by Matt Baker. * inspector/protocol/Canvas.json: - Add `ShaderType` enum that contains "vertex" and "fragment". - Add `requestShaderSource` command that will return the original source code for a given shader program and shader type. 2017-08-03 Filip Pizlo The allocator used to allocate memory for MarkedBlocks and LargeAllocations should not be the Subspace itself https://bugs.webkit.org/show_bug.cgi?id=175141 Reviewed by Mark Lam. To make it easier to have multiple gigacages and maybe even fancier methods of allocating, this decouples the allocator used to allocate memory from the GC Subspace. This means we no longer have to create a new Subspace subclass to allocate memory a different way. Instead, the allocator is now determined by the AlignedMemoryAllocator object. This also simplifies trading of blocks. Before, Subspaces had to determine if other Subspaces could trade blocks with them using canTradeBlocksWith(). This makes it difficult for two different Subspaces that both use the same underlying allocator to realize that they can trade blocks with each other. Now, you just need to ask the block being stolen and the subspace doing the stealing if they use the same AlignedMemoryAllocator. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * heap/AlignedMemoryAllocator.cpp: Added. (JSC::AlignedMemoryAllocator::AlignedMemoryAllocator): (JSC::AlignedMemoryAllocator::~AlignedMemoryAllocator): * heap/AlignedMemoryAllocator.h: Added. * heap/FastMallocAlignedMemoryAllocator.cpp: Added. (JSC::FastMallocAlignedMemoryAllocator::singleton): (JSC::FastMallocAlignedMemoryAllocator::FastMallocAlignedMemoryAllocator): (JSC::FastMallocAlignedMemoryAllocator::~FastMallocAlignedMemoryAllocator): (JSC::FastMallocAlignedMemoryAllocator::tryAllocateAlignedMemory): (JSC::FastMallocAlignedMemoryAllocator::freeAlignedMemory): (JSC::FastMallocAlignedMemoryAllocator::dump const): * heap/FastMallocAlignedMemoryAllocator.h: Added. * heap/GigacageAlignedMemoryAllocator.cpp: Added. (JSC::GigacageAlignedMemoryAllocator::singleton): (JSC::GigacageAlignedMemoryAllocator::GigacageAlignedMemoryAllocator): (JSC::GigacageAlignedMemoryAllocator::~GigacageAlignedMemoryAllocator): (JSC::GigacageAlignedMemoryAllocator::tryAllocateAlignedMemory): (JSC::GigacageAlignedMemoryAllocator::freeAlignedMemory): (JSC::GigacageAlignedMemoryAllocator::dump const): * heap/GigacageAlignedMemoryAllocator.h: Added. * heap/GigacageSubspace.cpp: Removed. * heap/GigacageSubspace.h: Removed. * heap/LargeAllocation.cpp: (JSC::LargeAllocation::tryCreate): (JSC::LargeAllocation::destroy): * heap/MarkedAllocator.cpp: (JSC::MarkedAllocator::tryAllocateWithoutCollecting): * heap/MarkedBlock.cpp: (JSC::MarkedBlock::tryCreate): (JSC::MarkedBlock::Handle::Handle): (JSC::MarkedBlock::Handle::~Handle): (JSC::MarkedBlock::Handle::didAddToAllocator): (JSC::MarkedBlock::Handle::subspace const): * heap/MarkedBlock.h: (JSC::MarkedBlock::Handle::alignedMemoryAllocator const): (JSC::MarkedBlock::Handle::subspace const): Deleted. * heap/Subspace.cpp: (JSC::Subspace::Subspace): (JSC::Subspace::findEmptyBlockToSteal): (JSC::Subspace::canTradeBlocksWith): Deleted. (JSC::Subspace::tryAllocateAlignedMemory): Deleted. (JSC::Subspace::freeAlignedMemory): Deleted. * heap/Subspace.h: (JSC::Subspace::name const): (JSC::Subspace::alignedMemoryAllocator const): * runtime/JSDestructibleObjectSubspace.cpp: (JSC::JSDestructibleObjectSubspace::JSDestructibleObjectSubspace): * runtime/JSDestructibleObjectSubspace.h: * runtime/JSSegmentedVariableObjectSubspace.cpp: (JSC::JSSegmentedVariableObjectSubspace::JSSegmentedVariableObjectSubspace): * runtime/JSSegmentedVariableObjectSubspace.h: * runtime/JSStringSubspace.cpp: (JSC::JSStringSubspace::JSStringSubspace): * runtime/JSStringSubspace.h: * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: * wasm/js/JSWebAssemblyCodeBlockSubspace.cpp: (JSC::JSWebAssemblyCodeBlockSubspace::JSWebAssemblyCodeBlockSubspace): * wasm/js/JSWebAssemblyCodeBlockSubspace.h: 2017-08-04 Oleksandr Skachkov [ESNext] Async iteration - update feature.json https://bugs.webkit.org/show_bug.cgi?id=175197 Reviewed by Yusuke Suzuki. Update feature.json to add status of the Async Iteration * features.json: 2017-08-04 Matt Lewis Unreviewed, rolling out r220271. Rolling out due to Layout Test failing on iOS Simulator. Reverted changeset: "Remove STREAMS_API compilation guard" https://bugs.webkit.org/show_bug.cgi?id=175165 http://trac.webkit.org/changeset/220271 2017-08-04 Youenn Fablet Remove STREAMS_API compilation guard https://bugs.webkit.org/show_bug.cgi?id=175165 Reviewed by Darin Adler. * Configurations/FeatureDefines.xcconfig: 2017-08-04 Oleksandr Skachkov [EsNext] Async iteration - Add feature flag https://bugs.webkit.org/show_bug.cgi?id=166694 Reviewed by Yusuke Suzuki. Add feature flag to JSC to switch on/off Async Iterator * runtime/Options.h: 2017-08-03 Brian Burg Remove ENABLE(WEB_SOCKET) guards https://bugs.webkit.org/show_bug.cgi?id=167044 Reviewed by Joseph Pecoraro. * Configurations/FeatureDefines.xcconfig: 2017-08-03 Youenn Fablet Remove FETCH_API compilation guard https://bugs.webkit.org/show_bug.cgi?id=175154 Reviewed by Chris Dumez. * Configurations/FeatureDefines.xcconfig: 2017-08-03 Matt Baker Web Inspector: Instrument WebGLProgram created/deleted https://bugs.webkit.org/show_bug.cgi?id=175059 Reviewed by Devin Rousso. Extend the Canvas protocol with types/events for tracking WebGLPrograms. * inspector/protocol/Canvas.json: 2017-08-03 Brady Eidson Add SW IDLs and stub out basic functionality. https://bugs.webkit.org/show_bug.cgi?id=175115 Reviewed by Chris Dumez. * Configurations/FeatureDefines.xcconfig: * runtime/CommonIdentifiers.h: 2017-08-03 Mark Lam Rename ScratchBuffer::activeLengthPtr to addressOfActiveLength. https://bugs.webkit.org/show_bug.cgi?id=175142 Reviewed by Filip Pizlo. The convention in the rest of of JSC for such methods which return the address of a field is to name them "addressOf". We'll rename ScratchBuffer::activeLengthPtr to be consistent with this convention. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileNewArrayWithSpread): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGThunks.cpp: (JSC::DFG::osrExitGenerationThunkGenerator): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNewArray): (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread): * ftl/FTLThunks.cpp: (JSC::FTL::genericGenerationThunkGenerator): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::debugCall): * jit/ScratchRegisterAllocator.cpp: (JSC::ScratchRegisterAllocator::preserveUsedRegistersToScratchBufferForCall): (JSC::ScratchRegisterAllocator::restoreUsedRegistersFromScratchBufferForCall): * runtime/VM.h: (JSC::ScratchBuffer::addressOfActiveLength): (JSC::ScratchBuffer::activeLengthPtr): Deleted. * wasm/WasmBinding.cpp: (JSC::Wasm::wasmToJs): 2017-08-02 Devin Rousso Web Inspector: add stack trace information for each RecordingAction https://bugs.webkit.org/show_bug.cgi?id=174663 Reviewed by Joseph Pecoraro. * inspector/ScriptCallFrame.h: Add `operator==` so that when a ScriptCallFrame object is held in a Vector, calling `find` with an existing value doesn't need require a functor and can use existing code. * interpreter/StackVisitor.h: * interpreter/StackVisitor.cpp: (JSC::StackVisitor::Frame::isWasmFrame const): Inlined in header. 2017-08-02 Yusuke Suzuki Merge WTFThreadData to Thread::current https://bugs.webkit.org/show_bug.cgi?id=174716 Reviewed by Mark Lam. Use Thread::current() instead. * API/JSContext.mm: (+[JSContext currentContext]): (+[JSContext currentThis]): (+[JSContext currentCallee]): (+[JSContext currentArguments]): (-[JSContext beginCallbackWithData:calleeValue:thisValue:argumentCount:arguments:]): (-[JSContext endCallbackWithData:]): * heap/Heap.cpp: (JSC::Heap::requestCollection): * runtime/Completion.cpp: (JSC::checkSyntax): (JSC::checkModuleSyntax): (JSC::evaluate): (JSC::loadAndEvaluateModule): (JSC::loadModule): (JSC::linkAndEvaluateModule): (JSC::importModule): * runtime/Identifier.cpp: (JSC::Identifier::checkCurrentAtomicStringTable): * runtime/InitializeThreading.cpp: (JSC::initializeThreading): * runtime/JSLock.cpp: (JSC::JSLock::didAcquireLock): (JSC::JSLock::willReleaseLock): (JSC::JSLock::dropAllLocks): (JSC::JSLock::grabAllLocks): * runtime/JSLock.h: * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::updateStackLimits): (JSC::VM::committedStackByteCount): * runtime/VM.h: (JSC::VM::isSafeToRecurse const): * runtime/VMEntryScope.cpp: (JSC::VMEntryScope::VMEntryScope): * runtime/VMInlines.h: (JSC::VM::ensureStackCapacityFor): * yarr/YarrPattern.cpp: (JSC::Yarr::YarrPatternConstructor::isSafeToRecurse const): 2017-08-02 Filip Pizlo LLInt should do pointer caging https://bugs.webkit.org/show_bug.cgi?id=175036 Reviewed by Keith Miller. Implementing this in the LLInt was challenging because offlineasm did not previously know how to load from globals. This teaches it how to do that on Darwin/x86_64, which happens to be where the Gigacage is enabled right now. * llint/LLIntOfflineAsmConfig.h: * llint/LowLevelInterpreter64.asm: * offlineasm/ast.rb: * offlineasm/x86.rb: 2017-08-02 Filip Pizlo Sweeping should only scribble when sweeping to free list https://bugs.webkit.org/show_bug.cgi?id=175105 Reviewed by Saam Barati. I just saw a crash on the bots where a destructor call attempt dereferenced scribbled memory. This can happen because the bump path of specializedSweep will scribble in SweepOnly, which replaces the zap word (i.e. 0) with the scribble word (i.e. 0xbadbeef0). This is a recent regression, since we didn't used to do destruction on the bump path. No destruction, no zapping. Looking at the pop path, we only scribble when we SweepToFreeList. This ensures that we only overwrite the zap word when it doesn't matter anyway because we're building a free list. This is a fix for those crashes on the bots because it means that we'll no longer scribble over the zap. * heap/MarkedBlockInlines.h: (JSC::MarkedBlock::Handle::specializedSweep): 2017-08-02 Filip Pizlo All C++ accesses to JSObject::m_butterfly should do caging https://bugs.webkit.org/show_bug.cgi?id=175039 Reviewed by Keith Miller. Makes JSObject::m_butterfly a AuxiliaryBarrier> and adopts the CagedPtr<> API. This ensures that you can't cause C++ code to access a butterfly that has been rewired to point outside the gigacage. * runtime/JSArray.cpp: (JSC::JSArray::setLength): (JSC::JSArray::pop): (JSC::JSArray::push): (JSC::JSArray::shiftCountWithAnyIndexingType): (JSC::JSArray::unshiftCountWithAnyIndexingType): (JSC::JSArray::fillArgList): (JSC::JSArray::copyToArguments): * runtime/JSObject.cpp: (JSC::JSObject::heapSnapshot): (JSC::JSObject::createInitialIndexedStorage): (JSC::JSObject::createArrayStorage): (JSC::JSObject::convertUndecidedToInt32): (JSC::JSObject::convertUndecidedToDouble): (JSC::JSObject::convertUndecidedToContiguous): (JSC::JSObject::convertInt32ToDouble): (JSC::JSObject::convertInt32ToArrayStorage): (JSC::JSObject::convertDoubleToContiguous): (JSC::JSObject::convertDoubleToArrayStorage): (JSC::JSObject::convertContiguousToArrayStorage): (JSC::JSObject::defineOwnIndexedProperty): (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes): (JSC::JSObject::ensureLengthSlow): (JSC::JSObject::allocateMoreOutOfLineStorage): * runtime/JSObject.h: (JSC::JSObject::canGetIndexQuickly): (JSC::JSObject::getIndexQuickly): (JSC::JSObject::tryGetIndexQuickly const): (JSC::JSObject::canSetIndexQuickly): (JSC::JSObject::setIndexQuickly): (JSC::JSObject::initializeIndex): (JSC::JSObject::initializeIndexWithoutBarrier): (JSC::JSObject::butterfly const): (JSC::JSObject::butterfly): 2017-08-02 Filip Pizlo We should be OK with the gigacage being disabled on gmalloc https://bugs.webkit.org/show_bug.cgi?id=175082 Reviewed by Michael Saboff. * jsc.cpp: (jscmain): 2017-08-02 Saam Barati On memory-constrained iOS devices, reduce the rate at which the JS heap grows before a GC to try to keep more memory available for the system https://bugs.webkit.org/show_bug.cgi?id=175041 Reviewed by Filip Pizlo. The testing I have done shows that this new function is a ~10% progression running JetStream on 1GB iOS devices. I've also tried this on a few > 1GB iOS devices, and the testing shows this is either neutral or a regression. Right now, we'll just enable this for <= 1GB devices since it's a win. In the future, we might want to either look into tweaking these parameters or coming up with a new function for > 1GB devices. * heap/Heap.cpp: * runtime/Options.h: 2017-08-01 Filip Pizlo Bmalloc and GC should put auxiliaries (butterflies, typed array backing stores) in a gigacage (separate multi-GB VM region) https://bugs.webkit.org/show_bug.cgi?id=174727 Reviewed by Mark Lam. This adopts the Gigacage for the GigacageSubspace, which we use for Auxiliary allocations. Also, in one place in the code - the FTL codegen for butterfly and typed array access - we "cage" the accesses themselves. Basically, we do masking to ensure that the pointer points into the gigacage. This is neutral on JetStream. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * b3/B3InsertionSet.cpp: (JSC::B3::InsertionSet::execute): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGArgumentsEliminationPhase.cpp: * dfg/DFGClobberize.cpp: (JSC::DFG::readsOverlap): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixedButterflyAccessUncagingPhase.cpp: Added. (JSC::DFG::performFixedButterflyAccessUncaging): * dfg/DFGFixedButterflyAccessUncagingPhase.h: Added. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGHeapLocation.cpp: (WTF::printInternal): * dfg/DFGHeapLocation.h: * dfg/DFGNodeType.h: * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThreadImpl): * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetButterfly): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGTypeCheckHoistingPhase.cpp: (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks): (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileGetButterfly): (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage): (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal): (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt): (JSC::FTL::DFG::LowerDFGToB3::compileStringCharCodeAt): (JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucket): (JSC::FTL::DFG::LowerDFGToB3::compileGetDirectPname): (JSC::FTL::DFG::LowerDFGToB3::compileToLowerCase): (JSC::FTL::DFG::LowerDFGToB3::caged): * heap/GigacageSubspace.cpp: Added. (JSC::GigacageSubspace::GigacageSubspace): (JSC::GigacageSubspace::~GigacageSubspace): (JSC::GigacageSubspace::tryAllocateAlignedMemory): (JSC::GigacageSubspace::freeAlignedMemory): (JSC::GigacageSubspace::canTradeBlocksWith): * heap/GigacageSubspace.h: Added. * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::lastChanceToFinalize): (JSC::Heap::finalize): (JSC::Heap::sweepInFinalize): (JSC::Heap::updateAllocationLimits): (JSC::Heap::shouldDoFullCollection): (JSC::Heap::collectIfNecessaryOrDefer): (JSC::Heap::reportWebAssemblyFastMemoriesAllocated): Deleted. (JSC::Heap::webAssemblyFastMemoriesThisCycleAtThreshold const): Deleted. (JSC::Heap::sweepLargeAllocations): Deleted. (JSC::Heap::didAllocateWebAssemblyFastMemories): Deleted. * heap/Heap.h: * heap/LargeAllocation.cpp: (JSC::LargeAllocation::tryCreate): (JSC::LargeAllocation::destroy): * heap/MarkedAllocator.cpp: (JSC::MarkedAllocator::tryAllocateWithoutCollecting): (JSC::MarkedAllocator::tryAllocateBlock): * heap/MarkedBlock.cpp: (JSC::MarkedBlock::tryCreate): (JSC::MarkedBlock::Handle::Handle): (JSC::MarkedBlock::Handle::~Handle): (JSC::MarkedBlock::Handle::didAddToAllocator): (JSC::MarkedBlock::Handle::subspace const): Deleted. * heap/MarkedBlock.h: (JSC::MarkedBlock::Handle::subspace const): * heap/MarkedSpace.cpp: (JSC::MarkedSpace::~MarkedSpace): (JSC::MarkedSpace::freeMemory): (JSC::MarkedSpace::prepareForAllocation): (JSC::MarkedSpace::addMarkedAllocator): (JSC::MarkedSpace::findEmptyBlockToSteal): Deleted. * heap/MarkedSpace.h: (JSC::MarkedSpace::firstAllocator const): (JSC::MarkedSpace::allocatorForEmptyAllocation const): Deleted. * heap/Subspace.cpp: (JSC::Subspace::Subspace): (JSC::Subspace::canTradeBlocksWith): (JSC::Subspace::tryAllocateAlignedMemory): (JSC::Subspace::freeAlignedMemory): (JSC::Subspace::prepareForAllocation): (JSC::Subspace::findEmptyBlockToSteal): * heap/Subspace.h: (JSC::Subspace::didCreateFirstAllocator): * heap/SubspaceInlines.h: (JSC::Subspace::forEachAllocator): (JSC::Subspace::forEachMarkedBlock): (JSC::Subspace::forEachNotEmptyMarkedBlock): * jit/JITPropertyAccess.cpp: (JSC::JIT::emitDoubleLoad): (JSC::JIT::emitContiguousLoad): (JSC::JIT::emitArrayStorageLoad): (JSC::JIT::emitGenericContiguousPutByVal): (JSC::JIT::emitArrayStoragePutByVal): (JSC::JIT::emit_op_get_from_scope): (JSC::JIT::emit_op_put_to_scope): (JSC::JIT::emitIntTypedArrayGetByVal): (JSC::JIT::emitFloatTypedArrayGetByVal): (JSC::JIT::emitIntTypedArrayPutByVal): (JSC::JIT::emitFloatTypedArrayPutByVal): * jsc.cpp: (fillBufferWithContentsOfFile): (functionReadFile): (gigacageDisabled): (jscmain): * llint/LowLevelInterpreter64.asm: * runtime/ArrayBuffer.cpp: (JSC::ArrayBufferContents::tryAllocate): (JSC::ArrayBuffer::createAdopted): (JSC::ArrayBuffer::createFromBytes): (JSC::ArrayBuffer::tryCreate): * runtime/IndexingHeader.h: * runtime/InitializeThreading.cpp: (JSC::initializeThreading): * runtime/JSArrayBuffer.cpp: * runtime/JSArrayBufferView.cpp: (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext): (JSC::JSArrayBufferView::finalize): * runtime/JSLock.cpp: (JSC::JSLock::didAcquireLock): * runtime/JSObject.h: * runtime/Options.cpp: (JSC::recomputeDependentOptions): * runtime/Options.h: * runtime/ScopedArgumentsTable.h: * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::~VM): (JSC::VM::gigacageDisabledCallback): (JSC::VM::gigacageDisabled): * runtime/VM.h: (JSC::VM::fireGigacageEnabledIfNecessary): (JSC::VM::gigacageEnabled): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer): * wasm/WasmCodeBlock.cpp: (JSC::Wasm::CodeBlock::isSafeToRun): * wasm/WasmMemory.cpp: (JSC::Wasm::makeString): (JSC::Wasm::Memory::create): (JSC::Wasm::Memory::~Memory): (JSC::Wasm::Memory::addressIsInActiveFastMemory): (JSC::Wasm::Memory::grow): (JSC::Wasm::Memory::initializePreallocations): Deleted. (JSC::Wasm::Memory::maxFastMemoryCount): Deleted. * wasm/WasmMemory.h: * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::create): * wasm/js/JSWebAssemblyMemory.cpp: (JSC::JSWebAssemblyMemory::grow): (JSC::JSWebAssemblyMemory::finishCreation): * wasm/js/JSWebAssemblyMemory.h: (JSC::JSWebAssemblyMemory::subspaceFor): 2017-07-31 Mark Lam Added some UNLIKELYs to operationOptimize(). https://bugs.webkit.org/show_bug.cgi?id=174976 Reviewed by JF Bastien. * jit/JITOperations.cpp: 2017-07-31 Keith Miller Make more things LLInt constexprs https://bugs.webkit.org/show_bug.cgi?id=174994 Reviewed by Saam Barati. This patch makes more const values in the LLInt constexprs. It also deletes all of the no longer necessary static_asserts in LLIntData.cpp. Finally, it fixes a typo in parser.rb. * interpreter/ShadowChicken.h: (JSC::ShadowChicken::Packet::tailMarker): * llint/LLIntData.cpp: (JSC::LLInt::Data::performAssertions): * llint/LowLevelInterpreter.asm: * offlineasm/generate_offset_extractor.rb: * offlineasm/parser.rb: 2017-07-31 Matt Lewis Unreviewed, rolling out r220060. This broke our internal builds. Contact reviewer of patch for more information. Reverted changeset: "Merge WTFThreadData to Thread::current" https://bugs.webkit.org/show_bug.cgi?id=174716 http://trac.webkit.org/changeset/220060 2017-07-31 Yusuke Suzuki [JSC] Support optional catch binding https://bugs.webkit.org/show_bug.cgi?id=174981 Reviewed by Saam Barati. This patch implements optional catch binding proposal[1], which is now stage 3. This proposal adds a new `catch` brace with no error value binding. ``` try { ... } catch { ... } ``` Sometimes we do not need to get error value actually. For example, the function returns boolean which means whether the function succeeds. ``` function parse(result) // -> bool { try { parseInner(result); } catch { return false; } return true; } ``` In the above case, we are not interested in the actual error value. Without this syntax, we always need to introduce a binding for an error value that is just ignored. [1]: https://michaelficarra.github.io/optional-catch-binding-proposal/ * bytecompiler/NodesCodegen.cpp: (JSC::TryNode::emitBytecode): * parser/Parser.cpp: (JSC::Parser::parseTryStatement): 2017-07-31 Yusuke Suzuki Merge WTFThreadData to Thread::current https://bugs.webkit.org/show_bug.cgi?id=174716 Reviewed by Sam Weinig. Use Thread::current() instead. * API/JSContext.mm: (+[JSContext currentContext]): (+[JSContext currentThis]): (+[JSContext currentCallee]): (+[JSContext currentArguments]): (-[JSContext beginCallbackWithData:calleeValue:thisValue:argumentCount:arguments:]): (-[JSContext endCallbackWithData:]): * heap/Heap.cpp: (JSC::Heap::requestCollection): * runtime/Completion.cpp: (JSC::checkSyntax): (JSC::checkModuleSyntax): (JSC::evaluate): (JSC::loadAndEvaluateModule): (JSC::loadModule): (JSC::linkAndEvaluateModule): (JSC::importModule): * runtime/Identifier.cpp: (JSC::Identifier::checkCurrentAtomicStringTable): * runtime/InitializeThreading.cpp: (JSC::initializeThreading): * runtime/JSLock.cpp: (JSC::JSLock::didAcquireLock): (JSC::JSLock::willReleaseLock): (JSC::JSLock::dropAllLocks): (JSC::JSLock::grabAllLocks): * runtime/JSLock.h: * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::updateStackLimits): (JSC::VM::committedStackByteCount): * runtime/VM.h: (JSC::VM::isSafeToRecurse const): * runtime/VMEntryScope.cpp: (JSC::VMEntryScope::VMEntryScope): * runtime/VMInlines.h: (JSC::VM::ensureStackCapacityFor): * yarr/YarrPattern.cpp: (JSC::Yarr::YarrPatternConstructor::isSafeToRecurse const): 2017-07-30 Yusuke Suzuki [WTF] Introduce Private Symbols https://bugs.webkit.org/show_bug.cgi?id=174935 Reviewed by Darin Adler. Use SymbolImpl::isPrivate(). * builtins/BuiltinNames.cpp: * builtins/BuiltinNames.h: (JSC::BuiltinNames::isPrivateName): Deleted. * builtins/BuiltinUtils.h: * bytecode/BytecodeIntrinsicRegistry.cpp: (JSC::BytecodeIntrinsicRegistry::lookup): * runtime/CommonIdentifiers.cpp: (JSC::CommonIdentifiers::isPrivateName): Deleted. * runtime/CommonIdentifiers.h: * runtime/ExceptionHelpers.cpp: (JSC::createUndefinedVariableError): * runtime/Identifier.h: (JSC::Identifier::isPrivateName): * runtime/IdentifierInlines.h: (JSC::identifierToSafePublicJSValue): * runtime/ObjectConstructor.cpp: (JSC::objectConstructorAssign): (JSC::defineProperties): (JSC::setIntegrityLevel): (JSC::testIntegrityLevel): (JSC::ownPropertyKeys): * runtime/PrivateName.h: (JSC::PrivateName::PrivateName): * runtime/PropertyName.h: (JSC::PropertyName::isPrivateName): * runtime/ProxyObject.cpp: (JSC::performProxyGet): (JSC::ProxyObject::performInternalMethodGetOwnProperty): (JSC::ProxyObject::performHasProperty): (JSC::ProxyObject::performPut): (JSC::ProxyObject::performDelete): (JSC::ProxyObject::performDefineOwnProperty): 2017-07-29 Keith Miller LLInt offsets extractor should be able to handle C++ constexprs https://bugs.webkit.org/show_bug.cgi?id=174964 Reviewed by Saam Barati. This patch adds new syntax to the offline asm language. The new keyword, constexpr, takes the subsequent identifier and maps it to a C++ constexpr expression. Additionally, if the value is not an identifier you can wrap it in parentheses. e.g. constexpr (myConstexprFunction() + OBJECT_OFFSET(Foo, bar)), which will get converted into: static_cast(myConstexprFunction() + OBJECT_OFFSET(Foo, bar)); This patch also changes the data format the LLIntOffsetsExtractor binary produces. Previously, it would produce unsigned values, after this patch every value is an int64_t. Using an int64_t is useful because it means that we can represent any constant needed. int32_t masks are sign extended then passed then converted to a negative literal sting in the assembler so it will be the constant expected. * llint/LLIntOffsetsExtractor.cpp: (JSC::LLIntOffsetsExtractor::dummy): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter64.asm: * offlineasm/asm.rb: * offlineasm/ast.rb: * offlineasm/generate_offset_extractor.rb: * offlineasm/offsets.rb: * offlineasm/parser.rb: * offlineasm/transform.rb: 2017-07-28 Matt Baker Web Inspector: capture an async stack trace when web content calls addEventListener https://bugs.webkit.org/show_bug.cgi?id=174739 Reviewed by Brian Burg. Allow debugger agents to perform custom logic when asynchronous stack trace data is cleared. For example, the PageDebuggerAgent would clear its list of registered listeners for which call stacks have been recorded. * inspector/agents/InspectorDebuggerAgent.cpp: (Inspector::InspectorDebuggerAgent::clearAsyncStackTraceData): * inspector/agents/InspectorDebuggerAgent.h: 2017-07-28 Mark Lam ObjectToStringAdaptiveStructureWatchpoint should not fire if it's dying imminently. https://bugs.webkit.org/show_bug.cgi?id=174948 Reviewed by Filip Pizlo. ObjectToStringAdaptiveStructureWatchpoint is owned by StructureRareData. If its owner StructureRareData is already known to be dead (in terms of GC liveness) but hasn't been destructed yet (i.e. not swept by the GC yet), we should ignore all requests to fire this watchpoint. If the GC had the chance to sweep the StructureRareData, thereby destructing the ObjectToStringAdaptiveStructureWatchpoint, it (the watchpoint) would have removed itself from the WatchpointSet it was on. Hence, it would not have been fired. But since the watchpoint hasn't been destructed yet, it still remains on the WatchpointSet and needs to guard against being fired in this state. The fix is to simply return early if its owner StructureRareData is not live. This has the effect of the watchpoint fire being a no-op, which is equivalent to the watchpoint not firing as we would expect. This patch also removes some cargo cult copying of watchpoint code which instantiates a StringFireDetail. In a few cases, that StringFireDetail is never used. This patch removes these unnecessary instantiations. * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp: (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal): * runtime/StructureRareData.cpp: (JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal): (JSC::ObjectToStringAdaptiveInferredPropertyValueWatchpoint::handleFire): 2017-07-28 Yusuke Suzuki ASSERTION FAILED: candidate->op() == PhantomCreateRest || candidate->op() == PhantomDirectArguments || candidate->op() == PhantomClonedArguments || candidate->op() == PhantomSpread || candidate->op() == PhantomNewArrayWithSpread https://bugs.webkit.org/show_bug.cgi?id=174900 Reviewed by Saam Barati. In the arguments elimination phase, due to high cost of AI, we intentionally do not run AI. Instead, we use ForceOSRExit etc. (pseudo terminals) not to look into unreachable nodes. The problem is that even transforming phase also checks this pseudo terminals. BB1 1: ForceOSRExit 2: CreateDirectArguments BB2 3: GetButterfly(@2) 4: ForceOSRExit In the above case, @2 is not converted to PhantomDirectArguments. But @3 is processed. And the assertion fires. In this patch, we do not list candidates up after seeing pseudo terminals in basic blocks. * dfg/DFGArgumentsEliminationPhase.cpp: 2017-07-27 Oleksandr Skachkov [ES] Add support finally to Promise https://bugs.webkit.org/show_bug.cgi?id=174503 Reviewed by Yusuke Suzuki. Add support `finally` method to Promise according to the https://bugs.webkit.org/show_bug.cgi?id=174503 Current spec on STAGE 3 https://github.com/tc39/proposal-promise-finally * builtins/PromisePrototype.js: (finally): (const.valueThunk): (globalPrivate.getThenFinally): (const.thrower): (globalPrivate.getCatchFinally): * runtime/JSPromisePrototype.cpp: 2017-07-27 Yusuke Suzuki Unreviewed, build fix for CLoop https://bugs.webkit.org/show_bug.cgi?id=171637 * domjit/DOMJITGetterSetter.h: 2017-07-27 Yusuke Suzuki Hoist DOM binding attribute getter prologue into JavaScriptCore taking advantage of DOMJIT / CheckSubClass https://bugs.webkit.org/show_bug.cgi?id=171637 Reviewed by Darin Adler. Each DOM attribute getter has the code to perform ClassInfo check. But it is largely duplicate and causes code bloating. In this patch, we move ClassInfo check from WebCore to JSC and reduce code size. We introduce DOMAnnotation which has ClassInfo* and DOMJIT::GetterSetter*. If the getter is not DOMJIT getter, this DOMJIT::GetterSetter becomes nullptr. We support such a CustomAccessorGetter in all the JIT tiers. In IC, we drop CheckSubClass completely since IC's Structure check subsumes it. We do not enable this optimization for op_get_by_id_with_this case yet. In DFG and FTL, we emit CheckSubClass node. Which is typically removed by CheckStructure leading to CheckSubClass. And we add DOMAttributeGetterSetter, which is derived class of CustomGetterSetter. It holds DOMAnnotation and perform ClassInfo check. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/AccessCase.cpp: (JSC::AccessCase::generateImpl): * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback): * bytecode/GetByIdVariant.cpp: (JSC::GetByIdVariant::GetByIdVariant): (JSC::GetByIdVariant::operator=): (JSC::GetByIdVariant::attemptToMerge): (JSC::GetByIdVariant::dumpInContext): * bytecode/GetByIdVariant.h: (JSC::GetByIdVariant::customAccessorGetter): (JSC::GetByIdVariant::domAttribute): (JSC::GetByIdVariant::domJIT): Deleted. * bytecode/GetterSetterAccessCase.cpp: (JSC::GetterSetterAccessCase::create): (JSC::GetterSetterAccessCase::GetterSetterAccessCase): (JSC::GetterSetterAccessCase::emitDOMJITGetter): * bytecode/GetterSetterAccessCase.h: (JSC::GetterSetterAccessCase::domAttribute): (JSC::GetterSetterAccessCase::customAccessor): (JSC::GetterSetterAccessCase::domJIT): Deleted. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::instantiateLexicalVariables): * create_hash_table: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::blessCallDOMGetter): (JSC::DFG::ByteCodeParser::handleDOMJITGetter): (JSC::DFG::ByteCodeParser::handleGetById): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNode.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCallDOMGetter): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callCustomGetter): * domjit/DOMJITGetterSetter.h: (JSC::DOMJIT::GetterSetter::GetterSetter): (JSC::DOMJIT::GetterSetter::getter): (JSC::DOMJIT::GetterSetter::compiler): (JSC::DOMJIT::GetterSetter::resultType): (JSC::DOMJIT::GetterSetter::~GetterSetter): Deleted. (JSC::DOMJIT::GetterSetter::setter): Deleted. (JSC::DOMJIT::GetterSetter::thisClassInfo): Deleted. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCallDOMGetter): * jit/Repatch.cpp: (JSC::tryCacheGetByID): * jsc.cpp: (WTF::DOMJITGetter::DOMJITAttribute::DOMJITAttribute): (WTF::DOMJITGetter::DOMJITAttribute::callDOMGetter): (WTF::DOMJITGetter::customGetter): (WTF::DOMJITGetter::finishCreation): (WTF::DOMJITGetterComplex::DOMJITAttribute::DOMJITAttribute): (WTF::DOMJITGetterComplex::DOMJITAttribute::callDOMGetter): (WTF::DOMJITGetterComplex::customGetter): (WTF::DOMJITGetterComplex::finishCreation): (WTF::DOMJITGetter::DOMJITNodeDOMJIT::DOMJITNodeDOMJIT): Deleted. (WTF::DOMJITGetter::DOMJITNodeDOMJIT::slowCall): Deleted. (WTF::DOMJITGetter::domJITNodeGetterSetter): Deleted. (WTF::DOMJITGetterComplex::DOMJITNodeDOMJIT::DOMJITNodeDOMJIT): Deleted. (WTF::DOMJITGetterComplex::DOMJITNodeDOMJIT::slowCall): Deleted. (WTF::DOMJITGetterComplex::domJITNodeGetterSetter): Deleted. * runtime/CustomGetterSetter.h: (JSC::CustomGetterSetter::create): (JSC::CustomGetterSetter::setter): (JSC::CustomGetterSetter::CustomGetterSetter): (): Deleted. * runtime/DOMAnnotation.h: Added. (JSC::operator==): (JSC::operator!=): * runtime/DOMAttributeGetterSetter.cpp: Added. * runtime/DOMAttributeGetterSetter.h: Copied from Source/JavaScriptCore/runtime/CustomGetterSetter.h. (JSC::isDOMAttributeGetterSetter): * runtime/Error.cpp: (JSC::throwDOMAttributeGetterTypeError): * runtime/Error.h: (JSC::throwVMDOMAttributeGetterTypeError): * runtime/JSCustomGetterSetterFunction.cpp: (JSC::JSCustomGetterSetterFunction::customGetterSetterFunctionCall): * runtime/JSObject.cpp: (JSC::JSObject::putInlineSlow): (JSC::JSObject::deleteProperty): (JSC::JSObject::getOwnStaticPropertySlot): (JSC::JSObject::reifyAllStaticProperties): (JSC::JSObject::fillGetterPropertySlot): (JSC::JSObject::findPropertyHashEntry): Deleted. * runtime/JSObject.h: (JSC::JSObject::getOwnNonIndexPropertySlot): (JSC::JSObject::fillCustomGetterPropertySlot): * runtime/Lookup.cpp: (JSC::setUpStaticFunctionSlot): * runtime/Lookup.h: (JSC::HashTableValue::domJIT): (JSC::getStaticPropertySlotFromTable): (JSC::putEntry): (JSC::lookupPut): (JSC::reifyStaticProperty): (JSC::reifyStaticProperties): Each static property table has a new field ClassInfo*. It indicates that which ClassInfo check DOMAttribute registered in this static property table requires. * runtime/ProgramExecutable.cpp: (JSC::ProgramExecutable::initializeGlobalProperties): * runtime/PropertyName.h: * runtime/PropertySlot.cpp: (JSC::PropertySlot::customGetter): (JSC::PropertySlot::customAccessorGetter): * runtime/PropertySlot.h: (JSC::PropertySlot::domAttribute): (JSC::PropertySlot::setCustom): (JSC::PropertySlot::setCacheableCustom): (JSC::PropertySlot::getValue): (JSC::PropertySlot::domJIT): Deleted. * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2017-07-26 Devin Rousso Web Inspector: create protocol for recording Canvas contexts https://bugs.webkit.org/show_bug.cgi?id=174481 Reviewed by Joseph Pecoraro. * inspector/protocol/Canvas.json: - Add `requestRecording` command to mark the provided canvas as having requested a recording. - Add `cancelRecording` command to clear a previously marked canvas and flush any recorded data. - Add `recordingFinished` event that is fired once a recording is finished. * CMakeLists.txt: * DerivedSources.make: * inspector/protocol/Recording.json: Added. - Add `Type` enum that lists the types of recordings - Add `InitialState` type that contains information about the canvas context at the beginning of the recording. - Add `Frame` type that holds a list of actions that were recorded. - Add `Recording` type as the container object of recording data. * inspector/scripts/codegen/generate_js_backend_commands.py: (JSBackendCommandsGenerator.generate_domain): Create an agent for domains with no events or commands. * inspector/InspectorValues.h: Make Array `get` public so that values can be retrieved if needed. 2017-07-26 Brian Burg Remove WEB_TIMING feature flag https://bugs.webkit.org/show_bug.cgi?id=174795 Reviewed by Alex Christensen. * Configurations/FeatureDefines.xcconfig: 2017-07-26 Mark Lam Add the ability to change sp and pc to the ARM64 JIT probe. https://bugs.webkit.org/show_bug.cgi?id=174697 Reviewed by JF Bastien. This patch implements the following: 1. The ARM64 probe now supports modifying the pc and sp. However, lr is not preserved when modifying the pc because it is used as the scratch register for the indirect jump. Hence, the probe handler function may not modify both lr and pc in the same probe invocation. 2. Fix probe tests to use bitwise comparison when comparing double register values. Otherwise, equivalent nan values will be interpreted as not equivalent. 3. Change the minimum offset increment in testProbeModifiesStackPointer to be 16 bytes for ARM64. This is because the ARM64 probe now uses the ldp and stp instructions which require 16 byte alignment for their memory access. * assembler/MacroAssemblerARM64.cpp: (JSC::arm64ProbeError): (JSC::MacroAssembler::probe): (JSC::arm64ProbeTrampoline): Deleted. * assembler/testmasm.cpp: (JSC::isSpecialGPR): (JSC::testProbeReadsArgumentRegisters): (JSC::testProbeWritesArgumentRegisters): (JSC::testProbePreservesGPRS): (JSC::testProbeModifiesStackPointer): (JSC::testProbeModifiesStackPointerToInsideProbeContextOnStack): (JSC::testProbeModifiesStackPointerToNBytesBelowSP): 2017-07-25 JF Bastien WebAssembly: generate smaller binaries https://bugs.webkit.org/show_bug.cgi?id=174818 Reviewed by Filip Pizlo. This patch reduces generated code size for WebAssembly in 2 ways: 1. Use the ZR register when storing zero on ARM64. 2. Synthesize wasm context lazily. This leads to a modest size reduction on both x86-64 and ARM64 for large WebAssembly games, without any performance loss on WasmBench and TitzerBench. The reason this works is that these games, using Emscripten, generate 100k+ tiny functions, and our JIT allocation granule rounds all allocations up to 32 bytes. There are plenty of other simple gains to be had, I've filed a follow-up bug at webkit.org/b/174819 We should further avoid the per-function cost of tiering, which represents the bulk of code generated for small functions. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::storeZero64): * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::storeZero64): * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::createStore): this doesn't make sense for x86 because it constrains register reuse and codegen in a way that doesn't affect ARM64 because it has a dedicated zero register. * b3/air/AirOpcode.opcodes: add the storeZero64 opcode. * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::instanceValue): (JSC::Wasm::B3IRGenerator::restoreWasmContext): (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::B3IRGenerator::materializeWasmContext): Deleted. 2017-07-23 Filip Pizlo B3 should do LICM https://bugs.webkit.org/show_bug.cgi?id=174750 Reviewed by Keith Miller and Saam Barati. Added a LICM phase to B3. This phase is called hoistLoopInvariantValues, to conform to the B3 naming convention for phases (it has to be an imperative). The phase uses NaturalLoops and BackwardsDominators, so this adds those analyses to B3. BackwardsDominators was already available in templatized form. This change templatizes DFG::NaturalLoops so that we can just use it. The LICM phase itself is really simple. We are decently precise with our handling of everything except the relationship between control dependence and side exits. Also added a bunch of tests. This isn't super important. It's perf-neutral on JS benchmarks. FTL already does LICM on DFG SSA IR, and probably all current WebAssembly content has had LICM done to it. That being said, this is a cheap phase so it doesn't hurt to have it. I wrote it because I thought I needed it for bug 174727. It turns out that there's a better way to handle the problem I had, so I ended up not needed it - but by then I had already written it. I think it's good to have it because LICM is one of those core compiler phases; every compiler has it eventually. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * b3/B3BackwardsCFG.h: Added. (JSC::B3::BackwardsCFG::BackwardsCFG): * b3/B3BackwardsDominators.h: Added. (JSC::B3::BackwardsDominators::BackwardsDominators): * b3/B3BasicBlock.cpp: (JSC::B3::BasicBlock::appendNonTerminal): * b3/B3Effects.h: * b3/B3EnsureLoopPreHeaders.cpp: Added. (JSC::B3::ensureLoopPreHeaders): * b3/B3EnsureLoopPreHeaders.h: Added. * b3/B3Generate.cpp: (JSC::B3::generateToAir): * b3/B3HoistLoopInvariantValues.cpp: Added. (JSC::B3::hoistLoopInvariantValues): * b3/B3HoistLoopInvariantValues.h: Added. * b3/B3NaturalLoops.h: Added. (JSC::B3::NaturalLoops::NaturalLoops): * b3/B3Procedure.cpp: (JSC::B3::Procedure::invalidateCFG): (JSC::B3::Procedure::naturalLoops): (JSC::B3::Procedure::backwardsCFG): (JSC::B3::Procedure::backwardsDominators): * b3/B3Procedure.h: * b3/testb3.cpp: (JSC::B3::generateLoop): (JSC::B3::makeArrayForLoops): (JSC::B3::generateLoopNotBackwardsDominant): (JSC::B3::oneFunction): (JSC::B3::noOpFunction): (JSC::B3::testLICMPure): (JSC::B3::testLICMPureSideExits): (JSC::B3::testLICMPureWritesPinned): (JSC::B3::testLICMPureWrites): (JSC::B3::testLICMReadsLocalState): (JSC::B3::testLICMReadsPinned): (JSC::B3::testLICMReads): (JSC::B3::testLICMPureNotBackwardsDominant): (JSC::B3::testLICMPureFoiledByChild): (JSC::B3::testLICMPureNotBackwardsDominantFoiledByChild): (JSC::B3::testLICMExitsSideways): (JSC::B3::testLICMWritesLocalState): (JSC::B3::testLICMWrites): (JSC::B3::testLICMFence): (JSC::B3::testLICMWritesPinned): (JSC::B3::testLICMControlDependent): (JSC::B3::testLICMControlDependentNotBackwardsDominant): (JSC::B3::testLICMControlDependentSideExits): (JSC::B3::testLICMReadsPinnedWritesPinned): (JSC::B3::testLICMReadsWritesDifferentHeaps): (JSC::B3::testLICMReadsWritesOverlappingHeaps): (JSC::B3::testLICMDefaultCall): (JSC::B3::run): * dfg/DFGBasicBlock.h: * dfg/DFGCFG.h: * dfg/DFGNaturalLoops.cpp: Removed. * dfg/DFGNaturalLoops.h: (JSC::DFG::NaturalLoops::NaturalLoops): (JSC::DFG::NaturalLoop::NaturalLoop): Deleted. (JSC::DFG::NaturalLoop::header): Deleted. (JSC::DFG::NaturalLoop::size): Deleted. (JSC::DFG::NaturalLoop::at): Deleted. (JSC::DFG::NaturalLoop::operator[]): Deleted. (JSC::DFG::NaturalLoop::contains): Deleted. (JSC::DFG::NaturalLoop::index): Deleted. (JSC::DFG::NaturalLoop::isOuterMostLoop): Deleted. (JSC::DFG::NaturalLoop::addBlock): Deleted. (JSC::DFG::NaturalLoops::numLoops): Deleted. (JSC::DFG::NaturalLoops::loop): Deleted. (JSC::DFG::NaturalLoops::headerOf): Deleted. (JSC::DFG::NaturalLoops::innerMostLoopOf): Deleted. (JSC::DFG::NaturalLoops::innerMostOuterLoop): Deleted. (JSC::DFG::NaturalLoops::belongsTo): Deleted. (JSC::DFG::NaturalLoops::loopDepth): Deleted. 2017-07-24 Filip Pizlo GC should be fine with trading blocks between destructor and non-destructor blocks https://bugs.webkit.org/show_bug.cgi?id=174811 Reviewed by Mark Lam. Our GC has the ability to trade blocks between MarkedAllocators. A MarkedAllocator is a size-class-within-a-Subspace. The ability to trade helps reduce memory wastage due to fragmentation. Prior to this change, this only worked between blocks that did not have destructors. This was partly a policy decision. But mostly, it was fallout from the way we use the `empty` block set. Here's how `empty` used to work. If a block is empty, we don't run destructors. We say that a block is empty if: A) It has no live objects and its a non-destructor block, or B) We just allocated it (so it has no destructors even if it's a destructor block), or C) We just stole it from another allocator (so it also has no destructors), or D) We just swept the block and ran all destructors. Case (A) is for trading blocks. That's how a different MarkedAllocator would know that this is a block that could be stolen. Cases (B) and (C) need to be detected for correctness, since otherwise we might try to run destructors in blocks that have garbage bits. In that case, the isZapped check won't detect that cells don't need destruction, so without having the `empty` bit we would try to destruct garbage and crash. Currently, we know that we have cases (B) and (C) when the block is empty. Case (D) is necessary for detecting which blocks can be removed when we `shrink` the heap. If we tried to enable trading of blocks between allocators without making any changes to how `empty` works, then it just would not work. We have to set the `empty` bits of blocks that have no live objects in order for those bits to be candidates for trading. But if we do that, then our logic for cases (B-D) will think that the block has no destructible objects. That's bad, since then our destructors won't run and we'll leak memory. This change fixes this issue by decoupling the "do I have destructors" question from the "do I have live objects" question by introducing a new `destructible` bitvector. The GC flags all live blocks as being destructible at the end. We clear the destructible bit in cases (B-D). Cases (B-C) are handled entirely by the new destrictible bit, while case (D) is detected by looking for blocks that are (empty & ~destructible). Then we can simply remove all destructor-oriented special-casing of the `empty` bit. And we can remove destructor-oriented special-casing of block trading. This is a perf-neutral change. We expect most free memory to be in non-destructor blocks anyway, so this change is more about clean-up than perf. But, this could reduce memory usage in some pathological cases. * heap/MarkedAllocator.cpp: (JSC::MarkedAllocator::findEmptyBlockToSteal): (JSC::MarkedAllocator::tryAllocateWithoutCollecting): (JSC::MarkedAllocator::endMarking): (JSC::MarkedAllocator::shrink): (JSC::MarkedAllocator::shouldStealEmptyBlocksFromOtherAllocators): Deleted. * heap/MarkedAllocator.h: * heap/MarkedBlock.cpp: (JSC::MarkedBlock::Handle::lastChanceToFinalize): (JSC::MarkedBlock::Handle::sweep): * heap/MarkedBlockInlines.h: (JSC::MarkedBlock::Handle::specializedSweep): (JSC::MarkedBlock::Handle::finishSweepKnowingSubspace): (JSC::MarkedBlock::Handle::emptyMode): 2017-07-25 Keith Miller Remove Broken CompareEq constant folding phase. https://bugs.webkit.org/show_bug.cgi?id=174846 Reviewed by Saam Barati. This bug happened when we would get code like the following: a: JSConst(Undefined) b: GetLocal(SomeObjectOrUndefined) ... c: CompareEq(Check:ObjectOrOther:b, Check:ObjectOrOther:a) constant folding will turn this into: a: JSConst(Undefined) b: GetLocal(SomeObjectOrUndefined) ... c: CompareEq(Check:ObjectOrOther:b, Other:a) But the SpeculativeJIT/FTL lowering will fail to check b properly which leads to an assertion failure in the AI. I'll follow up with a more robust fix later. For now, I'll remove the case that generates the code. Removing the code appears to be perf neutral. * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): 2017-07-25 Matt Baker Web Inspector: Refactoring: extract async stack trace logic from InspectorInstrumentation https://bugs.webkit.org/show_bug.cgi?id=174738 Reviewed by Brian Burg. Move AsyncCallType enum to InspectorDebuggerAgent, which manages async stack traces. This preserves the call type in JSC, makes the range of possible call types explicit, and is safer than passing ints. * inspector/agents/InspectorDebuggerAgent.cpp: (Inspector::InspectorDebuggerAgent::asyncCallIdentifier): (Inspector::InspectorDebuggerAgent::didScheduleAsyncCall): (Inspector::InspectorDebuggerAgent::didCancelAsyncCall): (Inspector::InspectorDebuggerAgent::willDispatchAsyncCall): * inspector/agents/InspectorDebuggerAgent.h: 2017-07-25 Mark Lam Fix bugs in probe code to change sp on x86, x86_64 and 32-bit ARM. https://bugs.webkit.org/show_bug.cgi?id=174809 Reviewed by Filip Pizlo. 1. When the probe handler function changes the sp register to point to the region of stack in the middle of the ProbeContext on the stack, there is a bug where the ProbeContext's register values to be restored can be over-written before they can be restored. This is now fixed. 2. Added more robust probe tests for changing the sp register. 3. Made existing probe tests to ensure that probe handlers were actually called. 4. Added some verification to testProbePreservesGPRS(). 5. Change all the probe tests to fail early on discovering an error instead of batching till the end of the test. This helps point a finger to the failing issue earlier. This patch was tested on x86, x86_64, and ARMv7. ARM64 probe code will be fixed next in https://bugs.webkit.org/show_bug.cgi?id=174697. * assembler/MacroAssemblerARM.cpp: * assembler/MacroAssemblerARMv7.cpp: * assembler/MacroAssemblerX86Common.cpp: * assembler/testmasm.cpp: (JSC::testProbeReadsArgumentRegisters): (JSC::testProbeWritesArgumentRegisters): (JSC::testProbePreservesGPRS): (JSC::testProbeModifiesStackPointer): (JSC::testProbeModifiesStackPointerToInsideProbeContextOnStack): (JSC::testProbeModifiesStackPointerToNBytesBelowSP): (JSC::testProbeModifiesProgramCounter): (JSC::run): 2017-07-25 Brian Burg Web Automation: add support for uploading files https://bugs.webkit.org/show_bug.cgi?id=174797 Reviewed by Joseph Pecoraro. * inspector/scripts/generate-inspector-protocol-bindings.py: (generate_from_specification): Start generating frontend dispatcher code if the target framework is 'WebKit'. * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py: (CppFrontendDispatcherImplementationGenerator.generate_output): Use a framework include for InspectorFrontendRouter.h since this generated code will be compiled outside of WebCore.framework. * inspector/scripts/tests/all/expected/definitions-with-mac-platform.json-result: * inspector/scripts/tests/generic/expected/commands-with-async-attribute.json-result: * inspector/scripts/tests/generic/expected/commands-with-optional-call-return-parameters.json-result: * inspector/scripts/tests/generic/expected/definitions-with-mac-platform.json-result: * inspector/scripts/tests/generic/expected/domain-availability.json-result: * inspector/scripts/tests/generic/expected/domains-with-varying-command-sizes.json-result: * inspector/scripts/tests/generic/expected/enum-values.json-result: * inspector/scripts/tests/generic/expected/events-with-optional-parameters.json-result: * inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result: * inspector/scripts/tests/generic/expected/same-type-id-different-domain.json-result: * inspector/scripts/tests/generic/expected/shadowed-optional-type-setters.json-result: * inspector/scripts/tests/generic/expected/type-declaration-aliased-primitive-type.json-result: * inspector/scripts/tests/generic/expected/type-declaration-array-type.json-result: * inspector/scripts/tests/generic/expected/type-declaration-enum-type.json-result: * inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result: * inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result: * inspector/scripts/tests/generic/expected/type-with-open-parameters.json-result: * inspector/scripts/tests/generic/expected/worker-supported-domains.json-result: * inspector/scripts/tests/ios/expected/definitions-with-mac-platform.json-result: * inspector/scripts/tests/mac/expected/definitions-with-mac-platform.json-result: Rebaseline code generator tests. 2017-07-24 Mark Lam Gardening: fixed C Loop build after r219790. https://bugs.webkit.org/show_bug.cgi?id=174696 Not reviewed. * assembler/testmasm.cpp: 2017-07-23 Mark Lam Create regression tests for the JIT probe. https://bugs.webkit.org/show_bug.cgi?id=174696 Reviewed by Saam Barati. The new testmasm will test the following: 1. the probe is able to read the value of CPU registers. 2. the probe is able to write the value of CPU registers. 3. the probe is able to preserve all CPU registers. 4. special case of (2): the probe is able to change the value of the stack pointer. 5. special case of (2): the probe is able to change the value of the program counter i.e. the probe can change where the code continues executing upon returning from the probe. Currently, the x86, x86_64, and ARMv7 ports passes the test. ARM64 does not because it does not support changing the sp and pc yet. The ARM64 probe implementation will be fixed in https://bugs.webkit.org/show_bug.cgi?id=174697 later. * Configurations/ToolExecutable.xcconfig: * JavaScriptCore.xcodeproj/project.pbxproj: * assembler/MacroAssembler.h: (JSC::MacroAssembler::CPUState::pc): (JSC::MacroAssembler::CPUState::fp): (JSC::MacroAssembler::CPUState::sp): (JSC::ProbeContext::pc): (JSC::ProbeContext::fp): (JSC::ProbeContext::sp): * assembler/MacroAssemblerARM64.cpp: (JSC::arm64ProbeTrampoline): * assembler/MacroAssemblerPrinter.cpp: (JSC::Printer::printPCRegister): * assembler/testmasm.cpp: Added. (hiddenTruthBecauseNoReturnIsStupid): (usage): (JSC::nextID): (JSC::isPC): (JSC::isSP): (JSC::isFP): (JSC::compile): (JSC::invoke): (JSC::compileAndRun): (JSC::testSimple): (JSC::testProbeReadsArgumentRegisters): (JSC::testProbeWritesArgumentRegisters): (JSC::testFunctionToTrashRegisters): (JSC::testProbePreservesGPRS): (JSC::testProbeModifiesStackPointer): (JSC::testProbeModifiesProgramCounter): (JSC::run): (run): (main): * b3/air/testair.cpp: (usage): * shell/CMakeLists.txt: 2017-07-14 Filip Pizlo It should be easy to decide how WebKit yields https://bugs.webkit.org/show_bug.cgi?id=174298 Reviewed by Saam Barati. Use the new WTF::Thread::yield() function for yielding instead of the C++ function. * heap/Heap.cpp: (JSC::Heap::resumeThePeriphery): * heap/VisitingTimeout.h: * runtime/JSCell.cpp: (JSC::JSCell::lockSlow): (JSC::JSCell::unlockSlow): * runtime/JSCell.h: * runtime/JSCellInlines.h: (JSC::JSCell::lock): (JSC::JSCell::unlock): * runtime/JSLock.cpp: (JSC::JSLock::grabAllLocks): * runtime/SamplingProfiler.cpp: 2017-07-21 Mark Lam Refactor MASM probe CPUState to use arrays for register storage. https://bugs.webkit.org/show_bug.cgi?id=174694 Reviewed by Keith Miller. Using arrays for register storage in CPUState allows us to do away with the huge switch statements to decode each register id. We can now simply index into the arrays. With this patch, we now: 1. Remove the need for macros for defining the list of CPU registers. We can go back to simple enums. This makes the code easier to read. 2. Make the assembler the authority on register names. Most of this code is moved into the assembler from GPRInfo and FPRInfo. GPRInfo and FPRInfo now forwards to the assembler. 3. Make the assembler the authority on the number of registers of each type. 4. Fix a "bug" in ARMv7's lastRegister(). It was previously omitting lr and pc. This is inconsistent with how every other CPU architecture implements lastRegister(). This patch fixes it to return the true last GPR i.e. pc, but updates RegisterSet::reservedHardwareRegisters() to exclude those registers. * assembler/ARM64Assembler.h: (JSC::ARM64Assembler::numberOfRegisters): (JSC::ARM64Assembler::firstSPRegister): (JSC::ARM64Assembler::lastSPRegister): (JSC::ARM64Assembler::numberOfSPRegisters): (JSC::ARM64Assembler::numberOfFPRegisters): (JSC::ARM64Assembler::gprName): (JSC::ARM64Assembler::sprName): (JSC::ARM64Assembler::fprName): * assembler/ARMAssembler.h: (JSC::ARMAssembler::numberOfRegisters): (JSC::ARMAssembler::firstSPRegister): (JSC::ARMAssembler::lastSPRegister): (JSC::ARMAssembler::numberOfSPRegisters): (JSC::ARMAssembler::numberOfFPRegisters): (JSC::ARMAssembler::gprName): (JSC::ARMAssembler::sprName): (JSC::ARMAssembler::fprName): * assembler/ARMv7Assembler.h: (JSC::ARMv7Assembler::lastRegister): (JSC::ARMv7Assembler::numberOfRegisters): (JSC::ARMv7Assembler::firstSPRegister): (JSC::ARMv7Assembler::lastSPRegister): (JSC::ARMv7Assembler::numberOfSPRegisters): (JSC::ARMv7Assembler::numberOfFPRegisters): (JSC::ARMv7Assembler::gprName): (JSC::ARMv7Assembler::sprName): (JSC::ARMv7Assembler::fprName): * assembler/AbstractMacroAssembler.h: (JSC::AbstractMacroAssembler::numberOfRegisters): (JSC::AbstractMacroAssembler::gprName): (JSC::AbstractMacroAssembler::firstSPRegister): (JSC::AbstractMacroAssembler::lastSPRegister): (JSC::AbstractMacroAssembler::numberOfSPRegisters): (JSC::AbstractMacroAssembler::sprName): (JSC::AbstractMacroAssembler::numberOfFPRegisters): (JSC::AbstractMacroAssembler::fprName): * assembler/MIPSAssembler.h: (JSC::MIPSAssembler::numberOfRegisters): (JSC::MIPSAssembler::firstSPRegister): (JSC::MIPSAssembler::lastSPRegister): (JSC::MIPSAssembler::numberOfSPRegisters): (JSC::MIPSAssembler::numberOfFPRegisters): (JSC::MIPSAssembler::gprName): (JSC::MIPSAssembler::sprName): (JSC::MIPSAssembler::fprName): * assembler/MacroAssembler.h: (JSC::MacroAssembler::CPUState::gprName): (JSC::MacroAssembler::CPUState::sprName): (JSC::MacroAssembler::CPUState::fprName): (JSC::MacroAssembler::CPUState::gpr): (JSC::MacroAssembler::CPUState::spr): (JSC::MacroAssembler::CPUState::fpr): (JSC::MacroAssembler::CPUState::pc): (JSC::MacroAssembler::CPUState::fp): (JSC::MacroAssembler::CPUState::sp): (JSC::ProbeContext::gpr): (JSC::ProbeContext::spr): (JSC::ProbeContext::fpr): (JSC::ProbeContext::gprName): (JSC::ProbeContext::sprName): (JSC::ProbeContext::fprName): (JSC::MacroAssembler::numberOfRegisters): Deleted. (JSC::MacroAssembler::numberOfFPRegisters): Deleted. * assembler/MacroAssemblerARM.cpp: * assembler/MacroAssemblerARM64.cpp: (JSC::arm64ProbeTrampoline): * assembler/MacroAssemblerARMv7.cpp: * assembler/MacroAssemblerPrinter.cpp: (JSC::Printer::nextID): (JSC::Printer::printAllRegisters): (JSC::Printer::printPCRegister): (JSC::Printer::printRegisterID): (JSC::Printer::printAddress): * assembler/MacroAssemblerX86Common.cpp: * assembler/X86Assembler.h: (JSC::X86Assembler::numberOfRegisters): (JSC::X86Assembler::firstSPRegister): (JSC::X86Assembler::lastSPRegister): (JSC::X86Assembler::numberOfSPRegisters): (JSC::X86Assembler::numberOfFPRegisters): (JSC::X86Assembler::gprName): (JSC::X86Assembler::sprName): (JSC::X86Assembler::fprName): * jit/FPRInfo.h: (JSC::FPRInfo::debugName): * jit/GPRInfo.h: (JSC::GPRInfo::debugName): * jit/RegisterSet.cpp: (JSC::RegisterSet::reservedHardwareRegisters): 2017-07-21 Yusuke Suzuki [JSC] Introduce static symbols https://bugs.webkit.org/show_bug.cgi?id=158863 Reviewed by Darin Adler. We use StaticSymbolImpl to initialize PrivateNames and builtin Symbols. As a result, we can share the same Symbol values between VMs and threads. And we do not need to allocate Ref for these symbols at runtime. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * builtins/BuiltinNames.cpp: Added. Suppress warning C4307, integral constant overflow. It is intentional in constexpr hash value calculation. * builtins/BuiltinNames.h: (JSC::BuiltinNames::BuiltinNames): * builtins/BuiltinUtils.h: 2017-07-21 Yusuke Suzuki [FTL] Arguments elimination is suppressed by unreachable blocks https://bugs.webkit.org/show_bug.cgi?id=174352 Reviewed by Filip Pizlo. If we do not execute `op_get_by_id`, our value profiling tells us unpredictable and DFG emits ForceOSRExit. The problem is that arguments elimination phase checks escaping even when ForceOSRExit preceeds. Since GetById without information can escape arguments if it is specified, non-executed code including op_get_by_id with arguments can escape arguments. For example, function test(flag) { if (flag) { // This is not executed, but emits GetById with arguments. // It prevents us from eliminating materialization. return arguments.length; } return arguments.length; } noInline(test); while (true) test(false); We do not perform CFA and dead-node clipping yet when performing arguments elimination phase. So this GetById exists and escapes arguments. To solve this problem, our arguments elimination phase checks preceding pseudo-terminal nodes. If it is shown, following GetById does not escape arguments. Compared to performing AI, it is lightweight. But it catches much of typical cases we failed to perform arguments elimination. * dfg/DFGArgumentsEliminationPhase.cpp: * dfg/DFGNode.h: (JSC::DFG::Node::isPseudoTerminal): * dfg/DFGValidate.cpp: 2017-07-20 Chris Dumez Replace calls to Vector::resize() with calls to more efficient shrink() / grow() when applicable https://bugs.webkit.org/show_bug.cgi?id=174660 Reviewed by Geoffrey Garen. Replace calls to Vector::resize() with calls to more efficient shrink() / grow() when applicable. This essentially replaces a branch to figure out if the new size is less or greater than the current size by an assertion. * b3/B3BasicBlockUtils.h: (JSC::B3::clearPredecessors): * b3/B3InferSwitches.cpp: * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::finishAppendingInstructions): * b3/B3ReduceStrength.cpp: * b3/B3SparseCollection.h: (JSC::B3::SparseCollection::packIndices): * b3/B3UseCounts.cpp: (JSC::B3::UseCounts::UseCounts): * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp: * b3/air/AirEmitShuffle.cpp: (JSC::B3::Air::emitShuffle): * b3/air/AirLowerAfterRegAlloc.cpp: (JSC::B3::Air::lowerAfterRegAlloc): * b3/air/AirOptimizeBlockOrder.cpp: (JSC::B3::Air::optimizeBlockOrder): * bytecode/Operands.h: (JSC::Operands::ensureLocals): * bytecode/PreciseJumpTargets.cpp: (JSC::computePreciseJumpTargetsInternal): * dfg/DFGBlockInsertionSet.cpp: (JSC::DFG::BlockInsertionSet::execute): * dfg/DFGBlockMapInlines.h: (JSC::DFG::BlockMap::BlockMap): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::processSetLocalQueue): (JSC::DFG::ByteCodeParser::clearCaches): * dfg/DFGDisassembler.cpp: (JSC::DFG::Disassembler::Disassembler): * dfg/DFGFlowIndexing.cpp: (JSC::DFG::FlowIndexing::recompute): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::registerFrozenValues): * dfg/DFGInPlaceAbstractState.cpp: (JSC::DFG::setLiveValues): * dfg/DFGLICMPhase.cpp: (JSC::DFG::LICMPhase::run): * dfg/DFGLivenessAnalysisPhase.cpp: * dfg/DFGNaturalLoops.cpp: (JSC::DFG::NaturalLoops::NaturalLoops): * dfg/DFGStoreBarrierClusteringPhase.cpp: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): * heap/CodeBlockSet.cpp: (JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced): * heap/MarkedSpace.cpp: (JSC::MarkedSpace::sweepLargeAllocations): * inspector/ContentSearchUtilities.cpp: (Inspector::ContentSearchUtilities::findMagicComment): * interpreter/ShadowChicken.cpp: (JSC::ShadowChicken::update): * parser/ASTBuilder.h: (JSC::ASTBuilder::shrinkOperandStackBy): * parser/Lexer.h: (JSC::Lexer::setOffset): * runtime/RegExpInlines.h: (JSC::RegExp::matchInline): * runtime/RegExpPrototype.cpp: (JSC::genericSplit): * yarr/RegularExpression.cpp: (JSC::Yarr::RegularExpression::match): 2017-07-20 Yusuke Suzuki [WTF] Use ThreadGroup to bookkeep active threads for Mach exception https://bugs.webkit.org/show_bug.cgi?id=174678 Reviewed by Mark Lam. Use Thread& instead. * runtime/JSLock.cpp: (JSC::JSLock::didAcquireLock): 2017-07-19 Yusuke Suzuki [WTF] Implement WTF::ThreadGroup https://bugs.webkit.org/show_bug.cgi?id=174081 Reviewed by Mark Lam. Large part of MachineThreads are now removed and replaced with WTF::ThreadGroup. And SamplingProfiler and others interact with WTF::Thread directly. * API/tests/ExecutionTimeLimitTest.cpp: * heap/MachineStackMarker.cpp: (JSC::MachineThreads::MachineThreads): (JSC::captureStack): (JSC::MachineThreads::tryCopyOtherThreadStack): (JSC::MachineThreads::tryCopyOtherThreadStacks): (JSC::MachineThreads::gatherConservativeRoots): (JSC::ActiveMachineThreadsManager::Locker::Locker): Deleted. (JSC::ActiveMachineThreadsManager::add): Deleted. (JSC::ActiveMachineThreadsManager::remove): Deleted. (JSC::ActiveMachineThreadsManager::contains): Deleted. (JSC::ActiveMachineThreadsManager::ActiveMachineThreadsManager): Deleted. (JSC::activeMachineThreadsManager): Deleted. (JSC::MachineThreads::~MachineThreads): Deleted. (JSC::MachineThreads::addCurrentThread): Deleted. (): Deleted. (JSC::MachineThreads::removeThread): Deleted. (JSC::MachineThreads::removeThreadIfFound): Deleted. (JSC::MachineThreads::MachineThread::MachineThread): Deleted. (JSC::MachineThreads::MachineThread::getRegisters): Deleted. (JSC::MachineThreads::MachineThread::Registers::stackPointer): Deleted. (JSC::MachineThreads::MachineThread::Registers::framePointer): Deleted. (JSC::MachineThreads::MachineThread::Registers::instructionPointer): Deleted. (JSC::MachineThreads::MachineThread::Registers::llintPC): Deleted. (JSC::MachineThreads::MachineThread::captureStack): Deleted. * heap/MachineStackMarker.h: (JSC::MachineThreads::addCurrentThread): (JSC::MachineThreads::getLock): (JSC::MachineThreads::threads): (JSC::MachineThreads::MachineThread::suspend): Deleted. (JSC::MachineThreads::MachineThread::resume): Deleted. (JSC::MachineThreads::MachineThread::threadID): Deleted. (JSC::MachineThreads::MachineThread::stackBase): Deleted. (JSC::MachineThreads::MachineThread::stackEnd): Deleted. (JSC::MachineThreads::threadsListHead): Deleted. * runtime/SamplingProfiler.cpp: (JSC::FrameWalker::isValidFramePointer): (JSC::SamplingProfiler::SamplingProfiler): (JSC::SamplingProfiler::takeSample): (JSC::SamplingProfiler::noticeCurrentThreadAsJSCExecutionThread): * runtime/SamplingProfiler.h: * wasm/WasmMachineThreads.cpp: (JSC::Wasm::resetInstructionCacheOnAllThreads): 2017-07-18 Andy Estes [Xcode] Enable CLANG_WARN_RANGE_LOOP_ANALYSIS https://bugs.webkit.org/show_bug.cgi?id=174631 Reviewed by Tim Horton. * Configurations/Base.xcconfig: * b3/B3FoldPathConstants.cpp: * b3/B3LowerMacros.cpp: * b3/air/AirAllocateRegistersByGraphColoring.cpp: * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::check): (JSC::DFG::ByteCodeParser::planLoad): 2017-07-18 Yusuke Suzuki WTF::Thread should have the threads stack bounds. https://bugs.webkit.org/show_bug.cgi?id=173975 Reviewed by Mark Lam. There is a site in JSC that try to walk another thread's stack. Currently, stack bounds are stored in WTFThreadData which is located in TLS. Thus, only the thread itself can access its own WTFThreadData. We workaround this situation by holding StackBounds in MachineThread in JSC, but StackBounds should be put in WTF::Thread instead. This patch adds StackBounds to WTF::Thread. StackBounds information is tightly coupled with Thread. Thus putting it in WTF::Thread is natural choice. * heap/MachineStackMarker.cpp: (JSC::MachineThreads::MachineThread::MachineThread): (JSC::MachineThreads::MachineThread::captureStack): * heap/MachineStackMarker.h: (JSC::MachineThreads::MachineThread::stackBase): (JSC::MachineThreads::MachineThread::stackEnd): * runtime/VMTraps.cpp: 2017-07-18 Andy Estes [Xcode] Enable CLANG_WARN_OBJC_LITERAL_CONVERSION https://bugs.webkit.org/show_bug.cgi?id=174631 Reviewed by Sam Weinig. * Configurations/Base.xcconfig: 2017-07-18 Joseph Pecoraro Web Inspector: Modernize InjectedScriptSource https://bugs.webkit.org/show_bug.cgi?id=173890 Reviewed by Brian Burg. * inspector/InjectedScript.h: Reorder functions to be slightly better. * inspector/InjectedScriptSource.js: - Convert to classes named InjectedScript and RemoteObject - Align InjectedScript's API with the wrapper C++ interfaces - Move some code to RemoteObject where appropriate (subtype, describe) - Move some code to helper functions (isPrimitiveValue, isDefined) - Refactor for readability and modern features - Remove some unused / unnecessary code 2017-07-18 Mark Lam Butterfly storage need not be initialized for indexing type Undecided. https://bugs.webkit.org/show_bug.cgi?id=174516 Reviewed by Saam Barati. While it's not incorrect to initialize the butterfly storage when the indexingType is Undecided, it is inefficient as we'll end up initializing it again later when we convert the storage to a different indexingType. Some of our code already skips initializing Undecided butterflies. This patch makes it the consistent behavior everywhere. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::emitAllocateRawObject): * runtime/JSArray.cpp: (JSC::JSArray::tryCreateUninitializedRestricted): * runtime/JSArray.h: (JSC::JSArray::tryCreate): * runtime/JSObject.cpp: (JSC::JSObject::ensureLengthSlow): 2017-07-18 Saam Barati AirLowerAfterRegAlloc may incorrectly use a callee save that's live as a scratch register https://bugs.webkit.org/show_bug.cgi?id=174515 Reviewed by Filip Pizlo. AirLowerAfterRegAlloc was computing the set of available scratch registers incorrectly. It was always excluding callee save registers from the set of live registers. It did not guarantee that live callee save registers were not in the set of scratch registers that could get clobbered. That's incorrect as the shuffling code is free to overwrite whatever is in the scratch register it gets passed. * b3/air/AirLowerAfterRegAlloc.cpp: (JSC::B3::Air::lowerAfterRegAlloc): * b3/testb3.cpp: (JSC::B3::functionNineArgs): (JSC::B3::testShuffleDoesntTrashCalleeSaves): (JSC::B3::run): * jit/RegisterSet.h: 2017-07-18 Andy Estes [Xcode] Enable CLANG_WARN_NON_LITERAL_NULL_CONVERSION https://bugs.webkit.org/show_bug.cgi?id=174631 Reviewed by Dan Bernstein. * Configurations/Base.xcconfig: 2017-07-18 Devin Rousso Web Inspector: Add memoryCost to Inspector Protocol objects https://bugs.webkit.org/show_bug.cgi?id=174478 Reviewed by Joseph Pecoraro. For non-array and non-object InspectorValue, calculate memoryCost as the sizeof the object, plus the memoryCost of the data if it is a string. For array InspectorValue, calculate memoryCost as the sum of the memoryCost of all items. For object InspectorValue, calculate memoryCost as the sum of the memoryCost of the string key plus the memoryCost of the InspectorValue for each entry. Test: TestWebKitAPI/Tests/JavaScriptCore/InspectorValue.cpp * inspector/InspectorValues.h: * inspector/InspectorValues.cpp: (Inspector::InspectorValue::memoryCost): (Inspector::InspectorObjectBase::memoryCost): (Inspector::InspectorArrayBase::memoryCost): 2017-07-18 Andy Estes [Xcode] Enable CLANG_WARN_BLOCK_CAPTURE_AUTORELEASING https://bugs.webkit.org/show_bug.cgi?id=174631 Reviewed by Darin Adler. * Configurations/Base.xcconfig: 2017-07-18 Michael Saboff [JSC] There should be a debug option to dump a compiled RegExp Pattern https://bugs.webkit.org/show_bug.cgi?id=174601 Reviewed by Alex Christensen. Added the debug option dumpCompiledRegExpPatterns which will dump the YarrPattern and related objects after a regular expression has been compiled. * runtime/Options.h: * yarr/YarrPattern.cpp: (JSC::Yarr::YarrPattern::compile): (JSC::Yarr::indentForNestingLevel): (JSC::Yarr::dumpUChar32): (JSC::Yarr::PatternAlternative::dump): (JSC::Yarr::PatternTerm::dumpQuantifier): (JSC::Yarr::PatternTerm::dump): (JSC::Yarr::PatternDisjunction::dump): (JSC::Yarr::YarrPattern::dumpPattern): * yarr/YarrPattern.h: (JSC::Yarr::YarrPattern::global): 2017-07-17 Darin Adler Improve use of NeverDestroyed https://bugs.webkit.org/show_bug.cgi?id=174348 Reviewed by Sam Weinig. * heap/MachineStackMarker.cpp: * wasm/WasmMemory.cpp: Removed unneeded includes of NeverDestroyed.h in files that do not make use of NeverDestroyed. 2017-07-17 Michael Catanzaro [CMake] Macros in WebKitMacros.cmake should be prefixed with WEBKIT_ namespace https://bugs.webkit.org/show_bug.cgi?id=174547 Reviewed by Alex Christensen. * CMakeLists.txt: * shell/CMakeLists.txt: 2017-07-17 Saam Barati Remove custom defined RELEASE_ASSERT in DFGObjectAllocationSinkingPhase https://bugs.webkit.org/show_bug.cgi?id=174584 Rubber stamped by Keith Miller. I used it to diagnose a bug. The bug is now fixed. This custom RELEASE_ASSERT is no longer needed. * dfg/DFGObjectAllocationSinkingPhase.cpp: 2017-07-17 Michael Catanzaro -Wformat-truncation warning in ConfigFile.cpp https://bugs.webkit.org/show_bug.cgi?id=174506 Reviewed by Darin Adler. Check if the JSC config filename would be truncated due to exceeding max path length. If so, return ParseError. * runtime/ConfigFile.cpp: (JSC::ConfigFile::parse): 2017-07-17 Konstantin Tokarev [CMake] Create targets before WEBKIT_INCLUDE_CONFIG_FILES_IF_EXISTS is called https://bugs.webkit.org/show_bug.cgi?id=174557 Reviewed by Michael Catanzaro. * CMakeLists.txt: 2017-07-14 Yusuke Suzuki [WTF] Use std::unique_ptr for StackTrace https://bugs.webkit.org/show_bug.cgi?id=174495 Reviewed by Alex Christensen. * runtime/ExceptionScope.cpp: (JSC::ExceptionScope::unexpectedExceptionMessage): * runtime/VM.cpp: (JSC::VM::throwException): 2017-07-14 Yusuke Suzuki [JSC] Use WTFMove to prune liveness in DFGAvailabilityMap https://bugs.webkit.org/show_bug.cgi?id=174423 Reviewed by Saam Barati. * dfg/DFGAvailabilityMap.cpp: (JSC::DFG::AvailabilityMap::pruneHeap): (JSC::DFG::AvailabilityMap::pruneByLiveness): 2017-07-13 Michael Catanzaro Fix compiler warnings when building with GCC 7 https://bugs.webkit.org/show_bug.cgi?id=174463 Reviewed by Darin Adler. * disassembler/udis86/udis86_decode.c: (decode_operand): 2017-07-13 Michael Catanzaro Incorrect assertion in JSC::CallLinkInfo::callTypeFor https://bugs.webkit.org/show_bug.cgi?id=174467 Reviewed by Saam Barati. * bytecode/CallLinkInfo.cpp: (JSC::CallLinkInfo::callTypeFor): 2017-07-13 Joseph Pecoraro Web Inspector: Remove unused and untested Page domain commands https://bugs.webkit.org/show_bug.cgi?id=174429 Reviewed by Timothy Hatcher. * inspector/protocol/Page.json: 2017-07-13 Saam Barati Missing exception check in JSObject::hasInstance https://bugs.webkit.org/show_bug.cgi?id=174455 Reviewed by Mark Lam. * runtime/JSObject.cpp: (JSC::JSObject::hasInstance): 2017-07-13 Caio Lima [ESnext] Implement Object Spread https://bugs.webkit.org/show_bug.cgi?id=167963 Reviewed by Saam Barati. This patch implements ECMA262 stage 3 Object Spread proposal [1]. It's implemented using CopyDataPropertiesNoExclusions to copy all enumerable keys from object being spreaded. The implementation of CopyDataPropertiesNoExclusions follows the CopyDataProperties implementation, however we don't receive excludedNames as parameter. [1] - https://github.com/tc39/proposal-object-rest-spread * builtins/GlobalOperations.js: (globalPrivate.copyDataPropertiesNoExclusions): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitLoad): * bytecompiler/NodesCodegen.cpp: (JSC::PropertyListNode::emitBytecode): (JSC::ObjectSpreadExpressionNode::emitBytecode): * parser/ASTBuilder.h: (JSC::ASTBuilder::createObjectSpreadExpression): (JSC::ASTBuilder::createProperty): * parser/NodeConstructors.h: (JSC::PropertyNode::PropertyNode): (JSC::ObjectSpreadExpressionNode::ObjectSpreadExpressionNode): * parser/Nodes.h: (JSC::ObjectSpreadExpressionNode::expression): * parser/Parser.cpp: (JSC::Parser::parseProperty): * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createObjectSpreadExpression): (JSC::SyntaxChecker::createProperty): 2017-07-12 Mark Lam Gardening: build fix after r219434. https://bugs.webkit.org/show_bug.cgi?id=174441 Not reviewed. Make public some MacroAssembler functions that are needed by the probe implementationq. * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::trustedImm32FromPtr): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::linkCall): 2017-07-12 Mark Lam Move Probe code from AbstractMacroAssembler to MacroAssembler. https://bugs.webkit.org/show_bug.cgi?id=174441 Reviewed by Saam Barati. This is a pure refactoring patch for moving probe code from the AbstractMacroAssembler to MacroAssembler. There is no code behavior change. * assembler/AbstractMacroAssembler.h: (JSC::AbstractMacroAssembler::Address::indexedBy): (JSC::AbstractMacroAssembler::CPUState::gprName): Deleted. (JSC::AbstractMacroAssembler::CPUState::fprName): Deleted. (JSC::AbstractMacroAssembler::CPUState::gpr): Deleted. (JSC::AbstractMacroAssembler::CPUState::fpr): Deleted. (JSC::MacroAssemblerType>::Address::indexedBy): Deleted. * assembler/MacroAssembler.h: (JSC::MacroAssembler::CPUState::gprName): (JSC::MacroAssembler::CPUState::fprName): (JSC::MacroAssembler::CPUState::gpr): (JSC::MacroAssembler::CPUState::fpr): * assembler/MacroAssemblerARM.cpp: (JSC::MacroAssembler::probe): (JSC::MacroAssemblerARM::probe): Deleted. * assembler/MacroAssemblerARM.h: * assembler/MacroAssemblerARM64.cpp: (JSC::MacroAssembler::probe): (JSC::MacroAssemblerARM64::probe): Deleted. * assembler/MacroAssemblerARM64.h: * assembler/MacroAssemblerARMv7.cpp: (JSC::MacroAssembler::probe): (JSC::MacroAssemblerARMv7::probe): Deleted. * assembler/MacroAssemblerARMv7.h: * assembler/MacroAssemblerMIPS.h: * assembler/MacroAssemblerX86Common.cpp: (JSC::MacroAssembler::probe): (JSC::MacroAssemblerX86Common::probe): Deleted. * assembler/MacroAssemblerX86Common.h: 2017-07-12 Saam Barati GenericArguments consults the wrong state when tracking modified argument descriptors and mapped arguments https://bugs.webkit.org/show_bug.cgi?id=174411 Reviewed by Mark Lam. The code for deleting an argument was incorrectly referencing state when it decided if it should unmap or mark a property as having its descriptor modified. This patch fixes the bug where if we delete a property, we would sometimes not unmap an argument when deleting it. * runtime/GenericArgumentsInlines.h: (JSC::GenericArguments::getOwnPropertySlot): (JSC::GenericArguments::getOwnPropertySlotByIndex): (JSC::GenericArguments::deleteProperty): (JSC::GenericArguments::deletePropertyByIndex): 2017-07-12 Commit Queue Unreviewed, rolling out r219176. https://bugs.webkit.org/show_bug.cgi?id=174436 "Can cause infinite recursion on iOS" (Requested by mlam on #webkit). Reverted changeset: "WTF::Thread should have the threads stack bounds." https://bugs.webkit.org/show_bug.cgi?id=173975 http://trac.webkit.org/changeset/219176 2017-07-12 Matt Lewis Unreviewed, rolling out r219401. This revision rolled out the previous patch, but after talking with reviewer, a rebaseline is what was needed.Rolling back in before rebaseline. Reverted changeset: "Unreviewed, rolling out r219379." https://bugs.webkit.org/show_bug.cgi?id=174400 http://trac.webkit.org/changeset/219401 2017-07-12 Matt Lewis Unreviewed, rolling out r219379. This revision caused a consistent failure in the test fast/dom/Window/property-access-on-cached-window-after-frame- removed.html. Reverted changeset: "Remove NAVIGATOR_HWCONCURRENCY" https://bugs.webkit.org/show_bug.cgi?id=174400 http://trac.webkit.org/changeset/219379 2017-07-12 Tooru Fujisawa [:arai] Wrong radix used in Unicode Escape in invalid character error message https://bugs.webkit.org/show_bug.cgi?id=174419 Reviewed by Alex Christensen. * parser/Lexer.cpp: (JSC::Lexer::invalidCharacterMessage): 2017-07-11 Dean Jackson Remove NAVIGATOR_HWCONCURRENCY https://bugs.webkit.org/show_bug.cgi?id=174400 Reviewed by Sam Weinig. * Configurations/FeatureDefines.xcconfig: 2017-07-11 Dean Jackson Rolling out r219372. * Configurations/FeatureDefines.xcconfig: 2017-07-11 Dean Jackson Remove NAVIGATOR_HWCONCURRENCY https://bugs.webkit.org/show_bug.cgi?id=174400 Reviewed by Sam Weinig. * Configurations/FeatureDefines.xcconfig: 2017-07-11 Saam Barati remove the empty JavaScriptCore/wasm/js/WebAssemblyFunctionCell.* files https://bugs.webkit.org/show_bug.cgi?id=174397 Rubber stamped by David Kilzer. * wasm/js/WebAssemblyFunctionCell.cpp: Removed. * wasm/js/WebAssemblyFunctionCell.h: Removed. 2017-07-10 Saam Barati Allocation sinking phase should consider a CheckStructure that would fail as an escape https://bugs.webkit.org/show_bug.cgi?id=174321 Reviewed by Filip Pizlo. When the allocation sinking phase was generating stores to materialize objects in a cycle with each other, it would assume that each materialized object had a valid, non empty, set of structures. This is an OK assumption for the phase to make because how do you materialize an object with no structure? The abstract interpretation part of the phase will model what's in the heap. However, it would sometimes model that a CheckStructure would fail. The phase did nothing special for this; it just stored the empty set of structures for its representation of a particular allocation. However, what the phase proved in such a scenario is that, had the CheckStructure executed, it would have exited. This patch treats such CheckStructures and MultiGetByOffsets as escape points. This will cause the allocation in question to be materialized just before the CheckStructure, and then at execution time, the CheckStructure will exit. I wasn't able to write a test case for this. However, I was able to reproduce this crash by manually editing the IR. I've opened a separate bug to help us create a testing framework for writing tests for hard to reproduce bugs like this: https://bugs.webkit.org/show_bug.cgi?id=174322 * dfg/DFGObjectAllocationSinkingPhase.cpp: 2017-07-10 Devin Rousso Web Inspector: Highlight matching CSS canvas clients when hovering contexts in the Resources tab https://bugs.webkit.org/show_bug.cgi?id=174279 Reviewed by Matt Baker. * inspector/protocol/DOM.json: Add `highlightNodeList` command that will highlight each node in the given list. 2017-07-03 Brian Burg Web Replay: remove some unused code https://bugs.webkit.org/show_bug.cgi?id=173903 Rubber-stamped by Joseph Pecoraro. * CMakeLists.txt: * Configurations/FeatureDefines.xcconfig: * DerivedSources.make: * JavaScriptCore.xcodeproj/project.pbxproj: * inspector/protocol/Replay.json: Removed. * replay/EmptyInputCursor.h: Removed. * replay/EncodedValue.cpp: Removed. * replay/EncodedValue.h: Removed. * replay/InputCursor.h: Removed. * replay/JSInputs.json: Removed. * replay/NondeterministicInput.h: Removed. * replay/scripts/CodeGeneratorReplayInputs.py: Removed. * replay/scripts/CodeGeneratorReplayInputsTemplates.py: Removed. * replay/scripts/tests/expected/fail-on-c-style-enum-no-storage.json-error: Removed. * replay/scripts/tests/expected/fail-on-duplicate-enum-type.json-error: Removed. * replay/scripts/tests/expected/fail-on-duplicate-input-names.json-error: Removed. * replay/scripts/tests/expected/fail-on-duplicate-type-names.json-error: Removed. * replay/scripts/tests/expected/fail-on-enum-type-missing-values.json-error: Removed. * replay/scripts/tests/expected/fail-on-missing-input-member-name.json-error: Removed. * replay/scripts/tests/expected/fail-on-missing-input-name.json-error: Removed. * replay/scripts/tests/expected/fail-on-missing-input-queue.json-error: Removed. * replay/scripts/tests/expected/fail-on-missing-type-mode.json-error: Removed. * replay/scripts/tests/expected/fail-on-missing-type-name.json-error: Removed. * replay/scripts/tests/expected/fail-on-unknown-input-queue.json-error: Removed. * replay/scripts/tests/expected/fail-on-unknown-member-type.json-error: Removed. * replay/scripts/tests/expected/fail-on-unknown-type-mode.json-error: Removed. * replay/scripts/tests/expected/generate-enum-encoding-helpers-with-guarded-values.json-TestReplayInputs.cpp: Removed. * replay/scripts/tests/expected/generate-enum-encoding-helpers-with-guarded-values.json-TestReplayInputs.h: Removed. * replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.cpp: Removed. * replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.h: Removed. * replay/scripts/tests/expected/generate-enum-with-guard.json-TestReplayInputs.cpp: Removed. * replay/scripts/tests/expected/generate-enum-with-guard.json-TestReplayInputs.h: Removed. * replay/scripts/tests/expected/generate-enums-with-same-base-name.json-TestReplayInputs.cpp: Removed. * replay/scripts/tests/expected/generate-enums-with-same-base-name.json-TestReplayInputs.h: Removed. * replay/scripts/tests/expected/generate-event-loop-shape-types.json-error: Removed. * replay/scripts/tests/expected/generate-input-with-guard.json-TestReplayInputs.cpp: Removed. * replay/scripts/tests/expected/generate-input-with-guard.json-TestReplayInputs.h: Removed. * replay/scripts/tests/expected/generate-input-with-vector-members.json-TestReplayInputs.cpp: Removed. * replay/scripts/tests/expected/generate-input-with-vector-members.json-TestReplayInputs.h: Removed. * replay/scripts/tests/expected/generate-inputs-with-flags.json-TestReplayInputs.cpp: Removed. * replay/scripts/tests/expected/generate-inputs-with-flags.json-TestReplayInputs.h: Removed. * replay/scripts/tests/expected/generate-memoized-type-modes.json-TestReplayInputs.cpp: Removed. * replay/scripts/tests/expected/generate-memoized-type-modes.json-TestReplayInputs.h: Removed. * replay/scripts/tests/fail-on-c-style-enum-no-storage.json: Removed. * replay/scripts/tests/fail-on-duplicate-enum-type.json: Removed. * replay/scripts/tests/fail-on-duplicate-input-names.json: Removed. * replay/scripts/tests/fail-on-duplicate-type-names.json: Removed. * replay/scripts/tests/fail-on-enum-type-missing-values.json: Removed. * replay/scripts/tests/fail-on-missing-input-member-name.json: Removed. * replay/scripts/tests/fail-on-missing-input-name.json: Removed. * replay/scripts/tests/fail-on-missing-input-queue.json: Removed. * replay/scripts/tests/fail-on-missing-type-mode.json: Removed. * replay/scripts/tests/fail-on-missing-type-name.json: Removed. * replay/scripts/tests/fail-on-unknown-input-queue.json: Removed. * replay/scripts/tests/fail-on-unknown-member-type.json: Removed. * replay/scripts/tests/fail-on-unknown-type-mode.json: Removed. * replay/scripts/tests/generate-enum-encoding-helpers-with-guarded-values.json: Removed. * replay/scripts/tests/generate-enum-encoding-helpers.json: Removed. * replay/scripts/tests/generate-enum-with-guard.json: Removed. * replay/scripts/tests/generate-enums-with-same-base-name.json: Removed. * replay/scripts/tests/generate-event-loop-shape-types.json: Removed. * replay/scripts/tests/generate-input-with-guard.json: Removed. * replay/scripts/tests/generate-input-with-vector-members.json: Removed. * replay/scripts/tests/generate-inputs-with-flags.json: Removed. * replay/scripts/tests/generate-memoized-type-modes.json: Removed. * runtime/DateConstructor.cpp: (JSC::constructDate): (JSC::dateNow): (JSC::deterministicCurrentTime): Deleted. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::JSGlobalObject): (JSC::JSGlobalObject::setInputCursor): Deleted. * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::inputCursor): Deleted. 2017-07-10 Carlos Garcia Campos Move make-js-file-arrays.py from WebCore to JavaScriptCore https://bugs.webkit.org/show_bug.cgi?id=174024 Reviewed by Michael Catanzaro. It's currently used only by WebCore, but it depends on other JavaScriptCore scripts and it's not WebCore specific at all. I plan to use it to compile the JavaScript atoms used by the WebDriver implementation. Added command line option to pass the namespace to use instead of using WebCore. * JavaScriptCore.xcodeproj/project.pbxproj: * Scripts/make-js-file-arrays.py: Renamed from Source/WebCore/Scripts/make-js-file-arrays.py. (main): 2017-07-09 Yusuke Suzuki [JSC] Drop LineNumberAdder since we no longer treat (not ) as one line terminator https://bugs.webkit.org/show_bug.cgi?id=174296 Reviewed by Mark Lam. Previously, we treat as one line terminator. So we increase line number by one. It caused a problem in scanning template literals. While template literals normalize to , we still needed to increase line number by only one. To handle it correctly, LineNumberAdder is introduced. As of r219263, is counted as two line terminators. So we do not need to have LineNumberAdder. Let's just use shiftLineTerminator() instead. * parser/Lexer.cpp: (JSC::Lexer::parseTemplateLiteral): (JSC::LineNumberAdder::LineNumberAdder): Deleted. (JSC::LineNumberAdder::clear): Deleted. (JSC::LineNumberAdder::add): Deleted. 2017-07-09 Dan Bernstein [Xcode] ICU headers aren’t treated as system headers after r219155 https://bugs.webkit.org/show_bug.cgi?id=174299 Reviewed by Sam Weinig. * Configurations/JavaScriptCore.xcconfig: Pass --system-header-prefix=unicode/ to the C and C++ compilers. * runtime/IntlCollator.cpp: Removed documentation warning suppression. * runtime/IntlDateTimeFormat.cpp: Ditto. * runtime/JSGlobalObject.cpp: Ditto. * runtime/StringPrototype.cpp: Ditto. 2017-07-09 Yusuke Suzuki [JSC] Use fastMalloc / fastFree for STL containers https://bugs.webkit.org/show_bug.cgi?id=174297 Reviewed by Sam Weinig. In some places, we intentionally use STL containers over WTF containers. For example, we sometimes use std::unordered_{set,map} instead of WTF::Hash{Set,Map} because we do not have effective empty / deleted representations in the space of key's value. But just using STL container means using libc's malloc instead of our fast malloc (bmalloc if it is enabled). We introduce WTF::FastAllocator. This is C++ allocator implementation using fastMalloc and fastFree. We specify this allocator to STL containers' template parameter to allocate memory from fastMalloc. This WTF::FastAllocator gives us a chance to use STL containers if it is necessary without compromising memory allocation throughput. * dfg/DFGGraph.h: * dfg/DFGIntegerCheckCombiningPhase.cpp: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::switchStringSlow): * runtime/FunctionHasExecutedCache.h: * runtime/TypeLocationCache.h: 2017-07-08 Yusuke Suzuki Drop NOSNIFF compile flag https://bugs.webkit.org/show_bug.cgi?id=174289 Reviewed by Michael Catanzaro. * Configurations/FeatureDefines.xcconfig: 2017-07-07 AJ Ringer Lower the max_protection for the separated heap https://bugs.webkit.org/show_bug.cgi?id=174281 Reviewed by Oliver Hunt. Switch to vm_protect so we can set maximum page protection. * jit/ExecutableAllocator.cpp: (JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps): (JSC::ExecutableAllocator::allocate): 2017-07-07 Devin Rousso Web Inspector: Show all elements currently using a given CSS Canvas https://bugs.webkit.org/show_bug.cgi?id=173965 Reviewed by Joseph Pecoraro. * inspector/protocol/Canvas.json: - Add `requestCSSCanvasClientNodes` command for getting the node IDs all nodes using this canvas via -webkit-canvas. - Add `cssCanvasClientNodesChanged` event that is dispatched whenever a node is added/removed from the list of -webkit-canvas clients. 2017-07-07 Mark Lam \n\r is not the same as \r\n. https://bugs.webkit.org/show_bug.cgi?id=173053 Reviewed by Keith Miller. * parser/Lexer.cpp: (JSC::Lexer::shiftLineTerminator): (JSC::LineNumberAdder::add): 2017-07-07 Commit Queue Unreviewed, rolling out r219238, r219239, and r219241. https://bugs.webkit.org/show_bug.cgi?id=174265 "fast/workers/dedicated-worker-lifecycle.html is flaky" (Requested by yusukesuzuki on #webkit). Reverted changesets: "[WTF] Implement WTF::ThreadGroup" https://bugs.webkit.org/show_bug.cgi?id=174081 http://trac.webkit.org/changeset/219238 "Unreviewed, build fix after r219238" https://bugs.webkit.org/show_bug.cgi?id=174081 http://trac.webkit.org/changeset/219239 "Unreviewed, CLoop build fix after r219238" https://bugs.webkit.org/show_bug.cgi?id=174081 http://trac.webkit.org/changeset/219241 2017-07-06 Yusuke Suzuki Unreviewed, CLoop build fix after r219238 https://bugs.webkit.org/show_bug.cgi?id=174081 * heap/MachineStackMarker.cpp: 2017-07-05 Yusuke Suzuki [WTF] Implement WTF::ThreadGroup https://bugs.webkit.org/show_bug.cgi?id=174081 Reviewed by Mark Lam. Large part of MachineThreads are now removed and replaced with WTF::ThreadGroup. And SamplingProfiler and others interact with WTF::Thread directly. * API/tests/ExecutionTimeLimitTest.cpp: * heap/MachineStackMarker.cpp: (JSC::MachineThreads::MachineThreads): (JSC::captureStack): (JSC::MachineThreads::tryCopyOtherThreadStack): (JSC::MachineThreads::tryCopyOtherThreadStacks): (JSC::MachineThreads::gatherConservativeRoots): (JSC::ActiveMachineThreadsManager::Locker::Locker): Deleted. (JSC::ActiveMachineThreadsManager::add): Deleted. (JSC::ActiveMachineThreadsManager::remove): Deleted. (JSC::ActiveMachineThreadsManager::contains): Deleted. (JSC::ActiveMachineThreadsManager::ActiveMachineThreadsManager): Deleted. (JSC::activeMachineThreadsManager): Deleted. (JSC::MachineThreads::~MachineThreads): Deleted. (JSC::MachineThreads::addCurrentThread): Deleted. (): Deleted. (JSC::MachineThreads::removeThread): Deleted. (JSC::MachineThreads::removeThreadIfFound): Deleted. (JSC::MachineThreads::MachineThread::MachineThread): Deleted. (JSC::MachineThreads::MachineThread::getRegisters): Deleted. (JSC::MachineThreads::MachineThread::Registers::stackPointer): Deleted. (JSC::MachineThreads::MachineThread::Registers::framePointer): Deleted. (JSC::MachineThreads::MachineThread::Registers::instructionPointer): Deleted. (JSC::MachineThreads::MachineThread::Registers::llintPC): Deleted. (JSC::MachineThreads::MachineThread::captureStack): Deleted. * heap/MachineStackMarker.h: (JSC::MachineThreads::addCurrentThread): (JSC::MachineThreads::getLock): (JSC::MachineThreads::threads): (JSC::MachineThreads::MachineThread::suspend): Deleted. (JSC::MachineThreads::MachineThread::resume): Deleted. (JSC::MachineThreads::MachineThread::threadID): Deleted. (JSC::MachineThreads::MachineThread::stackBase): Deleted. (JSC::MachineThreads::MachineThread::stackEnd): Deleted. (JSC::MachineThreads::threadsListHead): Deleted. * runtime/SamplingProfiler.cpp: (JSC::FrameWalker::isValidFramePointer): (JSC::SamplingProfiler::SamplingProfiler): (JSC::SamplingProfiler::takeSample): (JSC::SamplingProfiler::noticeCurrentThreadAsJSCExecutionThread): * runtime/SamplingProfiler.h: * wasm/WasmMachineThreads.cpp: (JSC::Wasm::resetInstructionCacheOnAllThreads): 2017-07-06 Saam Barati We are missing places where we invalidate the for-in context https://bugs.webkit.org/show_bug.cgi?id=174184 Reviewed by Geoffrey Garen. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::invalidateForInContextForLocal): * bytecompiler/NodesCodegen.cpp: (JSC::EmptyLetExpression::emitBytecode): (JSC::ForInNode::emitLoopHeader): (JSC::ForOfNode::emitBytecode): (JSC::BindingNode::bindValue): 2017-07-06 Yusuke Suzuki Unreviewed, suppress warnings in GCC environment * dfg/DFGObjectAllocationSinkingPhase.cpp: * runtime/IntlCollator.cpp: * runtime/IntlDateTimeFormat.cpp: * runtime/JSGlobalObject.cpp: * runtime/StringPrototype.cpp: 2017-07-05 Saam Barati NewArray in FTLLowerDFGToB3 does not handle speculating on doubles when having a bad time https://bugs.webkit.org/show_bug.cgi?id=174188 Reviewed by Mark Lam. We were calling lowJSValue(edge) when we were speculating the edge as double. This isn't allowed. We should have been using lowDouble. This patch also adds a new option, called useArrayAllocationProfiling, which defaults to true. When false, it will make the array allocation profile not actually sample seen arrays. It'll force the allocation profile's predicted indexing type to be ArrayWithUndecided. Adding this option made it trivial to write a test for this bug. * bytecode/ArrayAllocationProfile.cpp: (JSC::ArrayAllocationProfile::updateIndexingType): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNewArray): * runtime/Options.h: 2017-07-05 Yusuke Suzuki WTF::Thread should have the threads stack bounds. https://bugs.webkit.org/show_bug.cgi?id=173975 Reviewed by Keith Miller. There is a site in JSC that try to walk another thread's stack. Currently, stack bounds are stored in WTFThreadData which is located in TLS. Thus, only the thread itself can access its own WTFThreadData. We workaround this situation by holding StackBounds in MachineThread in JSC, but StackBounds should be put in WTF::Thread instead. This patch moves StackBounds from WTFThreadData to WTF::Thread. StackBounds information is tightly coupled with Thread. Thus putting it in WTF::Thread is natural choice. * heap/MachineStackMarker.cpp: (JSC::MachineThreads::MachineThread::MachineThread): (JSC::MachineThreads::MachineThread::captureStack): * heap/MachineStackMarker.h: (JSC::MachineThreads::MachineThread::stackBase): (JSC::MachineThreads::MachineThread::stackEnd): * runtime/InitializeThreading.cpp: (JSC::initializeThreading): * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::updateStackLimits): (JSC::VM::committedStackByteCount): * runtime/VM.h: (JSC::VM::isSafeToRecurse): * runtime/VMEntryScope.cpp: (JSC::VMEntryScope::VMEntryScope): * runtime/VMInlines.h: (JSC::VM::ensureStackCapacityFor): * runtime/VMTraps.cpp: * yarr/YarrPattern.cpp: (JSC::Yarr::YarrPatternConstructor::isSafeToRecurse): 2017-07-05 Keith Miller Crashing with information should have an abort reason https://bugs.webkit.org/show_bug.cgi?id=174185 Reviewed by Saam Barati. Add crash information for the abstract interpreter and add an enum value for object allocation sinking. * assembler/AbortReason.h: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::verifyEdge): * dfg/DFGGraph.cpp: (JSC::DFG::logDFGAssertionFailure): * dfg/DFGObjectAllocationSinkingPhase.cpp: 2017-07-03 Myles C. Maxfield Remove copy of ICU headers from WebKit https://bugs.webkit.org/show_bug.cgi?id=116407 Reviewed by Alex Christensen. Use WTF's copy of ICU headers. * Configurations/Base.xcconfig: * icu/unicode/localpointer.h: Removed. * icu/unicode/parseerr.h: Removed. * icu/unicode/platform.h: Removed. * icu/unicode/ptypes.h: Removed. * icu/unicode/putil.h: Removed. * icu/unicode/uchar.h: Removed. * icu/unicode/ucnv.h: Removed. * icu/unicode/ucnv_err.h: Removed. * icu/unicode/ucol.h: Removed. * icu/unicode/uconfig.h: Removed. * icu/unicode/ucurr.h: Removed. * icu/unicode/uenum.h: Removed. * icu/unicode/uiter.h: Removed. * icu/unicode/uloc.h: Removed. * icu/unicode/umachine.h: Removed. * icu/unicode/unorm.h: Removed. * icu/unicode/unorm2.h: Removed. * icu/unicode/urename.h: Removed. * icu/unicode/uscript.h: Removed. * icu/unicode/uset.h: Removed. * icu/unicode/ustring.h: Removed. * icu/unicode/utf.h: Removed. * icu/unicode/utf16.h: Removed. * icu/unicode/utf8.h: Removed. * icu/unicode/utf_old.h: Removed. * icu/unicode/utypes.h: Removed. * icu/unicode/uvernum.h: Removed. * icu/unicode/uversion.h: Removed. * runtime/IntlCollator.cpp: * runtime/IntlDateTimeFormat.cpp: (JSC::IntlDateTimeFormat::partTypeString): * runtime/JSGlobalObject.cpp: * runtime/StringPrototype.cpp: (JSC::normalize): (JSC::stringProtoFuncNormalize): 2017-07-05 Devin Rousso Web Inspector: Allow users to log any tracked canvas context https://bugs.webkit.org/show_bug.cgi?id=173397 Reviewed by Joseph Pecoraro. * inspector/protocol/Canvas.json: Add `resolveCanvasContext` command that returns a RemoteObject for the given canvas context. 2017-07-05 Jonathan Bedard Add WebKitPrivateFrameworkStubs for iOS 11 https://bugs.webkit.org/show_bug.cgi?id=173988 Reviewed by David Kilzer. * Configurations/Base.xcconfig: iphoneos and iphonesimulator should use the same directory for private framework stubs. 2017-07-05 JF Bastien WebAssembly: implement name section's module name, skip unknown sections https://bugs.webkit.org/show_bug.cgi?id=172008 Reviewed by Keith Miller. Parse the WebAssembly module name properly, and skip unknown sections. This is useful because as toolchains support new types of names we want to keep displaying the information we know about and simply ignore new information. That capability was designed into WebAssembly's name section. Failure to commit this patch would mean that WebKit won't display stack trace information, which would make developers sad. Module names were added here: https://github.com/WebAssembly/design/pull/1055 Note that this patch doesn't do anything with the parsed name! Two reasons for this: module names aren't supported in binaryen yet, so I can't write a simple binary test; and using the name is a slightly riskier change because it requires changing StackVisitor + StackFrame (where they print "[wasm code]") which requires figuring out the frame's Module. The latter bit isn't trivial because we only know wasm frames from their tag bits, and CodeBlocks are always nullptr. Binaryen bug: https://github.com/WebAssembly/binaryen/issues/1010 I filed #174098 to use the module name. * wasm/WasmFormat.h: (JSC::Wasm::isValidNameType): * wasm/WasmNameSectionParser.cpp: 2017-07-04 Joseph Pecoraro Cleanup some StringBuilder use https://bugs.webkit.org/show_bug.cgi?id=174118 Reviewed by Andreas Kling. * runtime/FunctionConstructor.cpp: (JSC::constructFunctionSkippingEvalEnabledCheck): * tools/FunctionOverrides.cpp: (JSC::parseClause): * wasm/WasmOMGPlan.cpp: * wasm/WasmPlan.cpp: * wasm/WasmValidate.cpp: 2017-07-03 Saam Barati LayoutTest workers/bomb.html is a Crash https://bugs.webkit.org/show_bug.cgi?id=167757 Reviewed by Keith Miller. VMTraps::SignalSender was accessing VM fields even after the VM was destroyed. This happened when the SignalSender thread was in the middle of its work() function while VMTraps was notified that the VM was shutting down. The VM would proceed to run its destructor even after the SignalSender thread finished doing its work. This means that the SignalSender thread was accessing VM field eve after VM was destructed (including itself, since it is transitively owned by the VM). The VM must wait for the SignalSender thread to shutdown before it can continue to destruct itself. * runtime/VMTraps.cpp: (JSC::VMTraps::willDestroyVM): 2017-07-03 Saam Barati DFGBytecodeParser op_to_this does not access the correct instruction offset for to this status https://bugs.webkit.org/show_bug.cgi?id=174110 Reviewed by Michael Saboff. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): 2017-07-03 Saam Barati Add a new assertion to object allocation sinking phase https://bugs.webkit.org/show_bug.cgi?id=174107 Rubber stamped by Filip Pizlo. * dfg/DFGObjectAllocationSinkingPhase.cpp: 2017-07-03 Commit Queue Unreviewed, rolling out r219060. https://bugs.webkit.org/show_bug.cgi?id=174108 crashing constantly when initializing UIWebView (Requested by thorton on #webkit). Reverted changeset: "WTF::Thread should have the threads stack bounds." https://bugs.webkit.org/show_bug.cgi?id=173975 http://trac.webkit.org/changeset/219060 2017-07-03 Matt Lewis Unreviewed, rolling out r219103. Caused multiple build failures. Reverted changeset: "Remove copy of ICU headers from WebKit" https://bugs.webkit.org/show_bug.cgi?id=116407 http://trac.webkit.org/changeset/219103 2017-07-03 Myles C. Maxfield Remove copy of ICU headers from WebKit https://bugs.webkit.org/show_bug.cgi?id=116407 Reviewed by Alex Christensen. Use WTF's copy of ICU headers. * Configurations/Base.xcconfig: * icu/unicode/localpointer.h: Removed. * icu/unicode/parseerr.h: Removed. * icu/unicode/platform.h: Removed. * icu/unicode/ptypes.h: Removed. * icu/unicode/putil.h: Removed. * icu/unicode/uchar.h: Removed. * icu/unicode/ucnv.h: Removed. * icu/unicode/ucnv_err.h: Removed. * icu/unicode/ucol.h: Removed. * icu/unicode/uconfig.h: Removed. * icu/unicode/ucurr.h: Removed. * icu/unicode/uenum.h: Removed. * icu/unicode/uiter.h: Removed. * icu/unicode/uloc.h: Removed. * icu/unicode/umachine.h: Removed. * icu/unicode/unorm.h: Removed. * icu/unicode/unorm2.h: Removed. * icu/unicode/urename.h: Removed. * icu/unicode/uscript.h: Removed. * icu/unicode/uset.h: Removed. * icu/unicode/ustring.h: Removed. * icu/unicode/utf.h: Removed. * icu/unicode/utf16.h: Removed. * icu/unicode/utf8.h: Removed. * icu/unicode/utf_old.h: Removed. * icu/unicode/utypes.h: Removed. * icu/unicode/uvernum.h: Removed. * icu/unicode/uversion.h: Removed. * runtime/IntlCollator.cpp: * runtime/IntlDateTimeFormat.cpp: * runtime/JSGlobalObject.cpp: * runtime/StringPrototype.cpp: 2017-07-03 Saam Barati Add better crash logging for allocation sinking phase https://bugs.webkit.org/show_bug.cgi?id=174102 Rubber stamped by Filip Pizlo. I'm trying to gather better information from crashlogs about why we're crashing in the allocation sinking phase. I'm adding a allocation sinking specific RELEASE_ASSERT as well as marking a few functions as NEVER_INLINE to have the stack traces in the crash trace contain more actionable information. * dfg/DFGObjectAllocationSinkingPhase.cpp: 2017-07-03 Sam Weinig [WebIDL] Remove more unnecessary uses of the preprocessor in idl files https://bugs.webkit.org/show_bug.cgi?id=174083 Reviewed by Alex Christensen. * Configurations/FeatureDefines.xcconfig: Add ENABLE_NAVIGATOR_STANDALONE. 2017-07-03 Andy Estes [Xcode] Add an experimental setting to build with ccache https://bugs.webkit.org/show_bug.cgi?id=173875 Reviewed by Tim Horton. * Configurations/DebugRelease.xcconfig: Included ccache.xcconfig. 2017-07-03 Devin Rousso Web Inspector: Support listing WebGL2 and WebGPU contexts https://bugs.webkit.org/show_bug.cgi?id=173396 Reviewed by Joseph Pecoraro. * inspector/protocol/Canvas.json: * inspector/scripts/codegen/generator.py: (Generator.stylized_name_for_enum_value): Add cases for handling new Canvas.ContextType protocol enumerations: - "webgl2" maps to `WebGL2` - "webgpu" maps to `WebGPU` 2017-07-02 Yusuke Suzuki WTF::Thread should have the threads stack bounds. https://bugs.webkit.org/show_bug.cgi?id=173975 Reviewed by Mark Lam. There is a site in JSC that try to walk another thread's stack. Currently, stack bounds are stored in WTFThreadData which is located in TLS. Thus, only the thread itself can access its own WTFThreadData. We workaround this situation by holding StackBounds in MachineThread in JSC, but StackBounds should be put in WTF::Thread instead. This patch moves StackBounds from WTFThreadData to WTF::Thread. StackBounds information is tightly coupled with Thread. Thus putting it in WTF::Thread is natural choice. * heap/MachineStackMarker.cpp: (JSC::MachineThreads::MachineThread::MachineThread): (JSC::MachineThreads::MachineThread::captureStack): * heap/MachineStackMarker.h: (JSC::MachineThreads::MachineThread::stackBase): (JSC::MachineThreads::MachineThread::stackEnd): * runtime/InitializeThreading.cpp: (JSC::initializeThreading): * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::updateStackLimits): (JSC::VM::committedStackByteCount): * runtime/VM.h: (JSC::VM::isSafeToRecurse): * runtime/VMEntryScope.cpp: (JSC::VMEntryScope::VMEntryScope): * runtime/VMInlines.h: (JSC::VM::ensureStackCapacityFor): * runtime/VMTraps.cpp: * yarr/YarrPattern.cpp: (JSC::Yarr::YarrPatternConstructor::isSafeToRecurse): 2017-07-01 Dan Bernstein [iOS] Remove code only needed when building for iOS 9.x https://bugs.webkit.org/show_bug.cgi?id=174068 Reviewed by Tim Horton. * Configurations/FeatureDefines.xcconfig: * jit/ExecutableAllocator.cpp: * runtime/Options.cpp: (JSC::recomputeDependentOptions): 2017-07-01 Dan Bernstein [macOS] Remove code only needed when building for OS X Yosemite https://bugs.webkit.org/show_bug.cgi?id=174067 Reviewed by Tim Horton. * API/WebKitAvailability.h: * Configurations/Base.xcconfig: * Configurations/DebugRelease.xcconfig: * Configurations/FeatureDefines.xcconfig: * Configurations/Version.xcconfig: 2017-07-01 Yusuke Suzuki Unreviewed, build fix for GCC https://bugs.webkit.org/show_bug.cgi?id=174034 * b3/testb3.cpp: (JSC::B3::testDoubleLiteralComparison): 2017-06-30 Keith Miller Force crashWithInfo to be out of line. https://bugs.webkit.org/show_bug.cgi?id=174028 Reviewed by Filip Pizlo. Update DFG_ASSERT macro to call CRASH_WITH_SECURITY_IMPLICATION_AND_INFO. * dfg/DFGGraph.cpp: (JSC::DFG::logDFGAssertionFailure): (JSC::DFG::Graph::logAssertionFailure): (JSC::DFG::crash): Deleted. (JSC::DFG::Graph::handleAssertionFailure): Deleted. * dfg/DFGGraph.h: 2017-06-30 Yusuke Suzuki [JSC] Use AbstractMacroAssembler::random instead of holding WeakRandom in JIT https://bugs.webkit.org/show_bug.cgi?id=174053 Reviewed by Geoffrey Garen. We already have AbstractMacroAssembler::random() function. Use it instead. * jit/JIT.cpp: (JSC::JIT::JIT): (JSC::JIT::compileWithoutLinking): * jit/JIT.h: 2017-06-30 Yusuke Suzuki [WTF] Drop SymbolRegistry::keyForSymbol https://bugs.webkit.org/show_bug.cgi?id=174052 Reviewed by Sam Weinig. * runtime/SymbolConstructor.cpp: (JSC::symbolConstructorKeyFor): 2017-06-30 Saam Barati B3ReduceStrength should reduce EqualOrUnordered over const float input https://bugs.webkit.org/show_bug.cgi?id=174039 Reviewed by Michael Saboff. We perform this folding for ConstDoubleValue. It is simply an oversight that we didn't do it for ConstFloatValue. * b3/B3ConstFloatValue.cpp: (JSC::B3::ConstFloatValue::equalOrUnorderedConstant): * b3/B3ConstFloatValue.h: * b3/testb3.cpp: (JSC::B3::testFloatEqualOrUnorderedFolding): (JSC::B3::testFloatEqualOrUnorderedFoldingNaN): (JSC::B3::testFloatEqualOrUnorderedDontFold): (JSC::B3::run): 2017-06-30 Matt Baker Web Inspector: AsyncStackTrace nodes can be corrupted when truncating https://bugs.webkit.org/show_bug.cgi?id=173840 Reviewed by Joseph Pecoraro. When truncating an asynchronous stack trace, the parent chain is traversed until a locked node is found. The path from this node to the root is shared by more than one stack trace, and cannot be safely modified. Starting at the first locked node, the path is cloned and becomes a new stack trace tree. However, the clone operation initialized each new AsyncStackTrace node with the original node's parent. This would increment the child count of the original node. When cloning nodes, new nodes should not have their parent set until the next node up the parent chain is cloned. * inspector/AsyncStackTrace.cpp: (Inspector::AsyncStackTrace::truncate): 2017-06-30 Michael Saboff RegExp's anchored with .* with \g flag can return wrong match start for strings with multiple matches https://bugs.webkit.org/show_bug.cgi?id=174044 Reviewed by Oliver Hunt. The .* enclosure optimization didn't respect that we can start matching from a non-zero index. This optimization treats /.*.*/ by first matching the and then finding the extent of the match by going back to the beginning of the line and going forward to the end of the line. The code that went back to the beginning of the line checked for an index of 0 instead of comparing the index to the start position. This start position is passed as the initial index. Added another temporary register to the YARR JIT to contain the start position for platforms that have spare registers. * yarr/Yarr.h: * yarr/YarrInterpreter.cpp: (JSC::Yarr::Interpreter::matchDotStarEnclosure): (JSC::Yarr::Interpreter::Interpreter): * yarr/YarrJIT.cpp: (JSC::Yarr::YarrGenerator::generateDotStarEnclosure): (JSC::Yarr::YarrGenerator::compile): * yarr/YarrPattern.cpp: (JSC::Yarr::YarrPattern::YarrPattern): * yarr/YarrPattern.h: (JSC::Yarr::YarrPattern::reset): 2017-06-30 Saam Barati B3MoveConstants floatZero() returns the wrong ValueKey https://bugs.webkit.org/show_bug.cgi?id=174040 Reviewed by Filip Pizlo. It had a typo where the ValueKey for floatZero() produces a Double instead of a Float. * b3/B3MoveConstants.cpp: 2017-06-30 Saam Barati B3ReduceDoubleToFloat incorrectly reduces operations over two double constants https://bugs.webkit.org/show_bug.cgi?id=174034 Reviewed by Filip Pizlo. B3ReduceDoubleToFloat had a bug in it where it would incorrectly reduce binary operations over double constants into the same binary operation over the double constants casted to floats. This is clearly incorrect as these two things will produce different values. For example: a = DoubleConst(bitwise_cast(0x8000000000000001ull)) b = DoubleConst(bitwise_cast(0x0000000000000000ull)) c = EqualOrUnordered(@a, @b) // produces 0 into: a = FloatConst(static_cast(bitwise_cast(0x8000000000000001ull))) b = FloatConst(static_cast(bitwise_cast(0x0000000000000000ull))) c = EqualOrUnordered(@a, @b) // produces 1 Which produces a different value for @c. * b3/B3ReduceDoubleToFloat.cpp: * b3/testb3.cpp: (JSC::B3::doubleEq): (JSC::B3::doubleNeq): (JSC::B3::doubleGt): (JSC::B3::doubleGte): (JSC::B3::doubleLt): (JSC::B3::doubleLte): (JSC::B3::testDoubleLiteralComparison): (JSC::B3::run): 2017-06-29 Jer Noble Make Legacy EME API controlled by RuntimeEnabled setting. https://bugs.webkit.org/show_bug.cgi?id=173994 Reviewed by Sam Weinig. * Configurations/FeatureDefines.xcconfig: * runtime/CommonIdentifiers.h: 2017-06-30 Ryosuke Niwa Ran sort-Xcode-project-file. * JavaScriptCore.xcodeproj/project.pbxproj: 2017-06-30 Matt Lewis Unreviewed, rolling out r218992. The patch broke the iOS device builds. Reverted changeset: "DFG_ASSERT should allow stuffing registers before trapping." https://bugs.webkit.org/show_bug.cgi?id=174005 http://trac.webkit.org/changeset/218992 2017-06-30 Filip Pizlo RegExpCachedResult::setInput should reify left and right contexts https://bugs.webkit.org/show_bug.cgi?id=173818 Reviewed by Keith Miller. If you don't reify them in setInput, then when you later try to reify them, you'll end up using indices into an old input string to create a substring of a new input string. That never goes well. * runtime/RegExpCachedResult.cpp: (JSC::RegExpCachedResult::setInput): 2017-06-30 Keith Miller DFG_ASSERT should allow stuffing registers before trapping. https://bugs.webkit.org/show_bug.cgi?id=174005 Reviewed by Mark Lam. DFG_ASSERT currently prints error data to stderr before crashing, which is nice for local development. In the wild, however, we can't see this information in crash logs. This patch enables stuffing some of the most useful information from DFG_ASSERTS into up to five registers right before crashing. The values stuffed should not impact any logging during local development. * assembler/AbortReason.h: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::verifyEdge): * dfg/DFGGraph.cpp: (JSC::DFG::logForCrash): (JSC::DFG::Graph::logAssertionFailure): (JSC::DFG::crash): Deleted. (JSC::DFG::Graph::handleAssertionFailure): Deleted. * dfg/DFGGraph.h: 2017-06-29 Saam Barati Calculating postCapacity in unshiftCountSlowCase is wrong https://bugs.webkit.org/show_bug.cgi?id=173992 Reviewed by Keith Miller. This patch fixes a bug inside unshiftCountSlowCase where we would use more memory than we allocated. The bug was when deciding how much extra space we have after the vector we've allocated. This area is called the postCapacity. The largest legal postCapacity value we could use is the space we allocated minus the space we need: largestPossiblePostCapacity = newStorageCapacity - requiredVectorLength; However, the code was calculating the postCapacity as: postCapacity = max(newStorageCapacity - requiredVectorLength, count); where count is how many elements we're appending. Depending on the inputs, count could be larger than (newStorageCapacity - requiredVectorLength). This would cause us to use more memory than we actually allocated. * runtime/JSArray.cpp: (JSC::JSArray::unshiftCountSlowCase): 2017-06-29 Commit Queue Unreviewed, rolling out r218512. https://bugs.webkit.org/show_bug.cgi?id=173981 "It changes the behavior of the JS API's JSEvaluateScript which breaks TurboTax" (Requested by saamyjoon on #webkit). Reverted changeset: "test262: Completion values for control flow do not match the spec" https://bugs.webkit.org/show_bug.cgi?id=171265 http://trac.webkit.org/changeset/218512 2017-06-29 JF Bastien WebAssembly: disable some APIs under CSP https://bugs.webkit.org/show_bug.cgi?id=173892 Reviewed by Daniel Bates. We should disable parts of WebAssembly under Content Security Policy as discussed here: https://github.com/WebAssembly/design/issues/1092 Exactly what should be disabled isn't super clear, so we may as well be conservative and disable many things if developers already opted into CSP. It's easy to loosen what we disable later. This patch disables: - WebAssembly.Instance - WebAssembly.instantiate - WebAssembly.Memory - WebAssembly.Table And leaves: - WebAssembly on the global object - WebAssembly.Module - WebAssembly.compile - WebAssembly.CompileError - WebAssembly.LinkError Nothing because currently unimplmented: - WebAssembly.compileStreaming - WebAssembly.instantiateStreaming That way it won't be possible to call WebAssembly-compiled code, or create memories (which use fancy 4GiB allocations sometimes). Table isn't really useful on its own, and eventually we may make them shareable so without more details it seems benign to disable them (and useless if we don't). I haven't done anything with postMessage, so you can still postMessage a WebAssembly.Module cross-CSP, but you can't instantiate it so it's useless. Because of this I elected to leave WebAssembly.Module and friends available. I haven't added any new directives. It's still unsafe-eval. We can add something else later, but it seems odd to add a WebAssembly as a new capability and tell developers "you should have been using this directive which we just implemented if you wanted to disable WebAssembly which didn't exist when you adopted CSP". So IMO we should keep unsafe-eval as it currently is, add WebAssembly to what it disables, and later consider having two new directives which do each individually or something. In all cases I throw an EvalError *before* other WebAssembly errors would be produced. Note that, as for eval, reporting doesn't work and is tracked by https://webkit.org/b/111869 * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::JSGlobalObject): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::webAssemblyEnabled): (JSC::JSGlobalObject::webAssemblyDisabledErrorMessage): (JSC::JSGlobalObject::setWebAssemblyEnabled): * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::create): * wasm/js/JSWebAssemblyMemory.cpp: (JSC::JSWebAssemblyMemory::create): * wasm/js/JSWebAssemblyMemory.h: * wasm/js/JSWebAssemblyTable.cpp: (JSC::JSWebAssemblyTable::create): * wasm/js/WebAssemblyMemoryConstructor.cpp: (JSC::constructJSWebAssemblyMemory): 2017-06-28 Keith Miller VMTraps has some races https://bugs.webkit.org/show_bug.cgi?id=173941 Reviewed by Michael Saboff. This patch refactors much of the VMTraps API. On the message sending side: 1) No longer uses the Yarr JIT check to determine if we are in RegExp code. That was unsound because RegExp JIT code can be run on compilation threads. Instead it looks at the current frame's code block slot and checks if it is valid, which is the same as what it did for JIT code previously. 2) Only have one signal sender thread, previously, there could be many at once, which caused some data races. Additionally, the signal sender thread is an automatic thread so it will deallocate itself when not in use. On the VMTraps breakpoint side: 1) We now have a true mapping of if we hit a breakpoint instead of a JIT assertion. So the exception handler won't eat JIT assertions anymore. 2) It jettisons all CodeBlocks that have VMTraps breakpoints on them instead of every CodeBlock on the stack. This both prevents us from hitting stale VMTraps breakpoints and also doesn't OSR codeblocks that otherwise don't need to be jettisoned. 3) The old exception handler could theoretically fail for a couple of reasons then resume execution with a clobbered instruction set. This patch will kill the program if the exception handler would fail. This patch also refactors some of the jsc.cpp functions to take the CommandLine options object instead of individual options. Also, there is a new command line option that makes exceptions due to watchdog timeouts an acceptable result. * API/tests/testapi.c: (main): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::installVMTrapBreakpoints): * dfg/DFGCommonData.cpp: (JSC::DFG::pcCodeBlockMap): (JSC::DFG::CommonData::invalidate): (JSC::DFG::CommonData::~CommonData): (JSC::DFG::CommonData::installVMTrapBreakpoints): (JSC::DFG::codeBlockForVMTrapPC): * dfg/DFGCommonData.h: * jsc.cpp: (functionDollarAgentStart): (checkUncaughtException): (checkException): (runWithOptions): (printUsageStatement): (CommandLine::parseArguments): (jscmain): (runWithScripts): Deleted. * runtime/JSLock.cpp: (JSC::JSLock::didAcquireLock): * runtime/VMTraps.cpp: (JSC::sanitizedTopCallFrame): (JSC::VMTraps::tryInstallTrapBreakpoints): (JSC::VMTraps::willDestroyVM): (JSC::VMTraps::fireTrap): (JSC::VMTraps::handleTraps): (JSC::VMTraps::VMTraps): (JSC::VMTraps::~VMTraps): (JSC::findActiveVMAndStackBounds): Deleted. (JSC::installSignalHandler): Deleted. (JSC::VMTraps::addSignalSender): Deleted. (JSC::VMTraps::removeSignalSender): Deleted. (JSC::VMTraps::SignalSender::willDestroyVM): Deleted. (JSC::VMTraps::SignalSender::send): Deleted. * runtime/VMTraps.h: (JSC::VMTraps::~VMTraps): Deleted. (JSC::VMTraps::SignalSender::SignalSender): Deleted. 2017-06-28 Devin Rousso Web Inspector: Instrument active pixel memory used by canvases https://bugs.webkit.org/show_bug.cgi?id=173087 Reviewed by Joseph Pecoraro. * inspector/protocol/Canvas.json: - Add optional `memoryCost` attribute to the `Canvas` type. - Add `canvasMemoryChanged` event that is dispatched when the `memoryCost` of a canvas changes. 2017-06-28 Joseph Pecoraro Web Inspector: Cleanup Protocol JSON files https://bugs.webkit.org/show_bug.cgi?id=173934 Reviewed by Matt Baker. * inspector/protocol/ApplicationCache.json: * inspector/protocol/CSS.json: * inspector/protocol/Console.json: * inspector/protocol/DOM.json: * inspector/protocol/DOMDebugger.json: * inspector/protocol/Debugger.json: * inspector/protocol/LayerTree.json: * inspector/protocol/Network.json: * inspector/protocol/Page.json: * inspector/protocol/Runtime.json: Be more consistent about placement of `description` property. 2017-06-27 Joseph Pecoraro Web Inspector: Remove unused Inspector domain events https://bugs.webkit.org/show_bug.cgi?id=173905 Reviewed by Matt Baker. * inspector/protocol/Inspector.json: 2017-06-28 JF Bastien Ensure that computed new stack pointer values do not underflow. https://bugs.webkit.org/show_bug.cgi?id=173700 Reviewed by Filip Pizlo and Saam Barati, update reviewed by Mark Lam. Patch by Mark Lam, with the following fix: Re-apply this patch, it originally broke the ARM build because the llint code generated `subs xzr, x3, sp` which isn't valid ARM64: the third operand cannot be SP (that encoding would be ZR instead, subtracting zero). Flip the comparison and operands to emit valid code (because the second operand can be SP). 1. Added a RELEASE_ASSERT to BytecodeGenerator::generate() to ensure that m_numCalleeLocals is sane. 2. Added underflow checks in LLInt code and VarargsFrame code. 3. Introduce minimumReservedZoneSize, which is hardcoded to 16K. Ensure that Options::reservedZoneSize() is at least minimumReservedZoneSize. Ensure that Options::softReservedZoneSize() is at least greater than Options::reservedZoneSize() by minimumReservedZoneSize. 4. Ensure that stack checks emitted by JIT tiers include an underflow check if and only if the max size of the frame is greater than Options::reservedZoneSize(). By design, we are guaranteed to have at least Options::reservedZoneSize() bytes of memory at the bottom (end) of the stack. This means that, at any time, the frame pointer must be at least Options::reservedZoneSize() bytes away from the end of the stack. Hence, if the max frame size is less than Options::reservedZoneSize(), there's no way that frame pointer - max frame size can underflow, and we can elide the underflow check. Note that we use Options::reservedZoneSize() instead of Options::softReservedZoneSize() for determine if we need an underflow check. This is because the softStackLimit that is used for stack checks can be set based on Options::reservedZoneSize() during error handling (e.g. when creating strings for instantiating the Error object). Hence, the guaranteed minimum of distance between the frame pointer and the end of the stack is Options::reservedZoneSize() and nor Options::softReservedZoneSize(). Note also that we ensure that Options::reservedZoneSize() is at least minimumReservedZoneSize (i.e. 16K). In typical deployments, Options::reservedZoneSize() may be larger. Using Options::reservedZoneSize() instead of minimumReservedZoneSize gives us more chances to elide underflow checks. * JavaScriptCore.xcodeproj/project.pbxproj: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::generate): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::requiredRegisterCountForExecutionAndExit): * dfg/DFGJITCompiler.cpp: (JSC::DFG::emitStackOverflowCheck): (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::lower): * jit/JIT.cpp: (JSC::JIT::compileWithoutLinking): * jit/SetupVarargsFrame.cpp: (JSC::emitSetupVarargsFrameFastCase): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/MinimumReservedZoneSize.h: Added. * runtime/Options.cpp: (JSC::recomputeDependentOptions): * runtime/VM.cpp: (JSC::VM::updateStackLimits): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::B3IRGenerator): * wasm/js/WebAssemblyFunction.cpp: (JSC::callWebAssemblyFunction): 2017-06-28 Chris Dumez Unreviewed, rolling out r218869. Broke the iOS build Reverted changeset: "Ensure that computed new stack pointer values do not underflow." https://bugs.webkit.org/show_bug.cgi?id=173700 http://trac.webkit.org/changeset/218869 2017-06-28 Chris Dumez Unreviewed, rolling out r218873. Broke the iOS build Reverted changeset: "Gardening: CLoop build fix." https://bugs.webkit.org/show_bug.cgi?id=173700 http://trac.webkit.org/changeset/218873 2017-06-28 Mark Lam Gardening: CLoop build fix. https://bugs.webkit.org/show_bug.cgi?id=173700 Not reviewed. * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): 2017-06-28 Mark Lam Ensure that computed new stack pointer values do not underflow. https://bugs.webkit.org/show_bug.cgi?id=173700 Reviewed by Filip Pizlo and Saam Barati. 1. Added a RELEASE_ASSERT to BytecodeGenerator::generate() to ensure that m_numCalleeLocals is sane. 2. Added underflow checks in LLInt code and VarargsFrame code. 3. Introduce minimumReservedZoneSize, which is hardcoded to 16K. Ensure that Options::reservedZoneSize() is at least minimumReservedZoneSize. Ensure that Options::softReservedZoneSize() is at least greater than Options::reservedZoneSize() by minimumReservedZoneSize. 4. Ensure that stack checks emitted by JIT tiers include an underflow check if and only if the max size of the frame is greater than Options::reservedZoneSize(). By design, we are guaranteed to have at least Options::reservedZoneSize() bytes of memory at the bottom (end) of the stack. This means that, at any time, the frame pointer must be at least Options::reservedZoneSize() bytes away from the end of the stack. Hence, if the max frame size is less than Options::reservedZoneSize(), there's no way that frame pointer - max frame size can underflow, and we can elide the underflow check. Note that we use Options::reservedZoneSize() instead of Options::softReservedZoneSize() for determine if we need an underflow check. This is because the softStackLimit that is used for stack checks can be set based on Options::reservedZoneSize() during error handling (e.g. when creating strings for instantiating the Error object). Hence, the guaranteed minimum of distance between the frame pointer and the end of the stack is Options::reservedZoneSize() and nor Options::softReservedZoneSize(). Note also that we ensure that Options::reservedZoneSize() is at least minimumReservedZoneSize (i.e. 16K). In typical deployments, Options::reservedZoneSize() may be larger. Using Options::reservedZoneSize() instead of minimumReservedZoneSize gives us more chances to elide underflow checks. * JavaScriptCore.xcodeproj/project.pbxproj: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::generate): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::requiredRegisterCountForExecutionAndExit): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::lower): * jit/JIT.cpp: (JSC::JIT::compileWithoutLinking): * jit/SetupVarargsFrame.cpp: (JSC::emitSetupVarargsFrameFastCase): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/MinimumReservedZoneSize.h: Added. * runtime/Options.cpp: (JSC::recomputeDependentOptions): * runtime/VM.cpp: (JSC::VM::updateStackLimits): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::B3IRGenerator): * wasm/js/WebAssemblyFunction.cpp: (JSC::callWebAssemblyFunction): 2017-06-27 JF Bastien WebAssembly: running out of executable memory should throw OoM https://bugs.webkit.org/show_bug.cgi?id=171537 Reviewed by Saam Barati. Both on first compile with BBQ as well as on tier-up with OMG, running out of X memory shouldn't cause the entire program to terminate. An exception will do when compiling initial code (since we don't have any other fallback at the moment), and refusal to tier up will do as well (it'll just be slower). This is useful because programs which generate huge amounts of code simply look like crashes, which developers report to us. Getting a JavaScript exception instead is much clearer. * jit/ExecutableAllocator.cpp: (JSC::ExecutableAllocator::allocate): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::shouldJIT): * runtime/Options.h: * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::prepare): (JSC::Wasm::BBQPlan::complete): * wasm/WasmBinding.cpp: (JSC::Wasm::wasmToJs): (JSC::Wasm::wasmToWasm): * wasm/WasmBinding.h: * wasm/WasmOMGPlan.cpp: (JSC::Wasm::OMGPlan::work): * wasm/js/JSWebAssemblyCodeBlock.cpp: (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock): * wasm/js/JSWebAssemblyCodeBlock.h: * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::finalizeCreation): 2017-06-27 Saam Barati JITStubRoutine::passesFilter should use isJITPC https://bugs.webkit.org/show_bug.cgi?id=173906 Reviewed by JF Bastien. This patch makes JITStubRoutine use the isJITPC abstraction defined inside ExecutableAllocator.h. Before, JITStubRoutine was using a hardcoded platform size constant. This means it'd do the wrong thing if Options::jitMemoryReservationSize() was larger than the defined constant for that platform. This patch also removes a bunch of dead code in that file. * jit/ExecutableAllocator.cpp: * jit/ExecutableAllocator.h: * jit/JITStubRoutine.h: (JSC::JITStubRoutine::passesFilter): (JSC::JITStubRoutine::canPerformRangeFilter): Deleted. (JSC::JITStubRoutine::filteringStartAddress): Deleted. (JSC::JITStubRoutine::filteringExtentSize): Deleted. 2017-06-27 Saam Barati Fix some stale comments in Wasm code base https://bugs.webkit.org/show_bug.cgi?id=173814 Reviewed by Mark Lam. * wasm/WasmBinding.cpp: (JSC::Wasm::wasmToJs): * wasm/WasmOMGPlan.cpp: (JSC::Wasm::runOMGPlanForIndex): 2017-06-27 Caio Lima [ESnext] Implement Object Rest - Implementing Object Rest Destructuring https://bugs.webkit.org/show_bug.cgi?id=167962 Reviewed by Saam Barati. Object Rest/Spread Destructing proposal is in stage 3[1] and this Patch is a prototype implementation of it. A simple change over the parser was necessary to support the new '...' token on Object Pattern destruction rule. In the bytecode generator side, We changed the bytecode generated on ObjectPatternNode::bindValue to store in an set the identifiers of already destructured properties, following spec draft section[2], and then pass it as excludedNames to CopyDataProperties. The rest destructuring calls copyDataProperties to perform the copy of rest properties in rhs. We also implemented CopyDataProperties as private JS global operation on builtins/GlobalOperations.js following it's specification on [3]. It is implemented using Set object to verify if a property is on excludedNames to keep this algorithm with O(n + m) complexity, where n = number of source's own properties and m = excludedNames.length. In this implementation we aren't using excludeList as constant if destructuring pattern contains computed property, i.e. we can just determine the key to be excluded at runtime. If we can define all identifiers in the pattern in compile time, we then create a constant JSSet. This approach gives a good performance improvement, since we allocate the excludeSet just once, reducing GC pressure. [1] - https://github.com/tc39/proposal-object-rest-spread [2] - https://tc39.github.io/proposal-object-rest-spread/#Rest-RuntimeSemantics-PropertyDestructuringAssignmentEvaluation [3] - https://tc39.github.io/proposal-object-rest-spread/#AbstractOperations-CopyDataProperties * builtins/BuiltinNames.h: * builtins/GlobalOperations.js: (globalPrivate.copyDataProperties): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): * bytecompiler/NodesCodegen.cpp: (JSC::ObjectPatternNode::bindValue): * parser/ASTBuilder.h: (JSC::ASTBuilder::appendObjectPatternEntry): (JSC::ASTBuilder::appendObjectPatternRestEntry): (JSC::ASTBuilder::setContainsObjectRestElement): * parser/Nodes.h: (JSC::ObjectPatternNode::appendEntry): (JSC::ObjectPatternNode::setContainsRestElement): * parser/Parser.cpp: (JSC::Parser::parseDestructuringPattern): (JSC::Parser::parseProperty): * parser/SyntaxChecker.h: (JSC::SyntaxChecker::operatorStackPop): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::asyncFunctionStructure): (JSC::JSGlobalObject::setStructure): Deleted. * runtime/JSGlobalObjectFunctions.cpp: (JSC::privateToObject): * runtime/JSGlobalObjectFunctions.h: * runtime/ObjectConstructor.cpp: (JSC::ObjectConstructor::finishCreation): * runtime/SetPrototype.cpp: (JSC::SetPrototype::finishCreation): 2017-06-27 Yusuke Suzuki [JSC] Do not touch VM after notifying Ready in DFG::Worklist https://bugs.webkit.org/show_bug.cgi?id=173888 Reviewed by Saam Barati. After notifying Plan::Ready and releasing Worklist lock, VM can be destroyed. Thus, Plan::vm() can return a destroyed VM. Do not touch it. This causes occasional SEGV / assertion failures in workers/bomb test. * dfg/DFGWorklist.cpp: 2017-06-27 Saam Barati Remove an inaccurate comment inside DFGClobberize.h https://bugs.webkit.org/show_bug.cgi?id=163874 Reviewed by Filip Pizlo. The comment said that Clobberize may or may not be sound if run prior to doing type inference. This is not correct, though. Clobberize *must* be sound prior do doing type inference since we use it inside the BytecodeParser, which is the very first thing the DFG does. * dfg/DFGClobberize.h: (JSC::DFG::clobberize): 2017-06-27 Saam Barati Function constructor needs to follow the spec and validate parameters and body independently https://bugs.webkit.org/show_bug.cgi?id=173303 Reviewed by Keith Miller. The Function constructor must check the arguments and body strings independently for syntax errors. People rely on this specified behavior to verify that a particular string is a valid function body. We used to check these things strings concatenated together, instead of independently. For example, this used to be valid: `Function("/*", "*/){")`. However, we should throw a syntax error here since "(/*)" is not a valid parameter list, and "*/){" is not a valid body. To implement the specified behavior, we check the syntax independently of both the body and the parameter list. To check that the parameter list has valid syntax, we check that it is valid if in a function with an empty body. To check that the body has valid syntax, we check it is valid in a function with an empty parameter list. * runtime/FunctionConstructor.cpp: (JSC::constructFunctionSkippingEvalEnabledCheck): 2017-06-27 Ting-Wei Lan Add missing includes to fix compilation error on FreeBSD https://bugs.webkit.org/show_bug.cgi?id=172919 Reviewed by Mark Lam. * API/JSRemoteInspector.h: * API/tests/GlobalContextWithFinalizerTest.cpp: * API/tests/TypedArrayCTest.cpp: 2017-06-27 Joseph Pecoraro Web Inspector: Crash generating object preview for ArrayIterator https://bugs.webkit.org/show_bug.cgi?id=173754 Reviewed by Saam Barati. When Inspector generates an object preview for an ArrayIterator instance it made a "clone" of the original ArrayIterator instance by constructing a new object with the instance's structure. However, user code could have modified that instance's structure, such as adding / removing properties. The `return` property had special meaning, and our clone did not fill that slot. This approach is brittle in that we weren't satisfying the expectations of an object with a particular Structure, and the original goal of having Web Inspector peek values of built-in Iterators was to avoid observable behavior. This tightens Web Inspector's Iterator preview to only peek values if the Iterators would actually be non-observable. It also builds an ArrayIterator clone like a regular object construction. * inspector/JSInjectedScriptHost.cpp: (Inspector::cloneArrayIteratorObject): Build up the Object from scratch with a new ArrayIterator prototype. (Inspector::JSInjectedScriptHost::iteratorEntries): Only clone and peek iterators if it would not be observable. Also update iteration to be more in line with IterationOperations, such as when we call iteratorClose. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::JSGlobalObject): (JSC::JSGlobalObject::init): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::stringIteratorProtocolWatchpoint): * runtime/JSGlobalObjectInlines.h: (JSC::JSGlobalObject::isStringPrototypeIteratorProtocolFastAndNonObservable): Add a StringIterator WatchPoint in line with the Array/Map/Set iterator watchpoints. * runtime/JSMap.cpp: (JSC::JSMap::isIteratorProtocolFastAndNonObservable): (JSC::JSMap::canCloneFastAndNonObservable): * runtime/JSMap.h: * runtime/JSSet.cpp: (JSC::JSSet::isIteratorProtocolFastAndNonObservable): (JSC::JSSet::canCloneFastAndNonObservable): * runtime/JSSet.h: Promote isIteratorProtocolFastAndNonObservable to a method. * runtime/JSObject.cpp: (JSC::canDoFastPutDirectIndex): * runtime/JSTypeInfo.h: (JSC::TypeInfo::isArgumentsType): Helper to detect if an Object is an Arguments type. 2017-06-26 Saam Barati RegExpPrototype.js builtin uses for-of iteration which is almost certainly incorrect https://bugs.webkit.org/show_bug.cgi?id=173740 Reviewed by Mark Lam. The builtin was using for-of iteration to iterate over an internal list in its algorithm. For-of iteration is observable via user code in the global object, so this approach was wrong as it would break if a user changed the Array iteration protocol in some way. * builtins/RegExpPrototype.js: (replace): 2017-06-26 Mark Lam Renamed DumpRegisterFunctor to DumpReturnVirtualPCFunctor. https://bugs.webkit.org/show_bug.cgi?id=173848 Reviewed by JF Bastien. This functor only dumps the return VirtualPC. * interpreter/Interpreter.cpp: (JSC::DumpReturnVirtualPCFunctor::DumpReturnVirtualPCFunctor): (JSC::Interpreter::dumpRegisters): (JSC::DumpRegisterFunctor::DumpRegisterFunctor): Deleted. (JSC::DumpRegisterFunctor::operator()): Deleted. 2017-06-26 Saam Barati Crash in JSC::Lexer::setCode https://bugs.webkit.org/show_bug.cgi?id=172754 Reviewed by Mark Lam. The lexer was asking one of its buffers to reserve initial space that was O(text size in bytes). For large sources, this would end up causing the vector to overflow and crash. This patch changes this code be like the Lexer's other buffers and to only reserve a small starting buffer. * parser/Lexer.cpp: (JSC::Lexer::setCode): 2017-06-26 Yusuke Suzuki [WTF] Drop Thread::create(obsolete things) API since we can use lambda https://bugs.webkit.org/show_bug.cgi?id=173825 Reviewed by Saam Barati. * jsc.cpp: (startTimeoutThreadIfNeeded): (timeoutThreadMain): Deleted. 2017-06-26 Konstantin Tokarev Unreviewed, add missing header for CLoop * runtime/SymbolTable.cpp: 2017-06-26 Konstantin Tokarev Unreviewed, add missing header icncludes * parser/Lexer.h: 2017-06-25 Konstantin Tokarev Remove excessive headers from JavaScriptCore https://bugs.webkit.org/show_bug.cgi?id=173812 Reviewed by Darin Adler. * API/APIUtils.h: * assembler/LinkBuffer.cpp: * assembler/MacroAssemblerCodeRef.cpp: * b3/air/AirLiveness.h: * b3/air/AirLowerAfterRegAlloc.cpp: * bindings/ScriptValue.cpp: * bindings/ScriptValue.h: * bytecode/AccessCase.cpp: * bytecode/AccessCase.h: * bytecode/ArrayProfile.h: * bytecode/BytecodeDumper.h: * bytecode/BytecodeIntrinsicRegistry.cpp: * bytecode/BytecodeKills.h: * bytecode/BytecodeLivenessAnalysis.h: * bytecode/BytecodeUseDef.h: * bytecode/CallLinkStatus.h: * bytecode/CodeBlock.h: * bytecode/CodeOrigin.h: * bytecode/ComplexGetStatus.h: * bytecode/GetByIdStatus.h: * bytecode/GetByIdVariant.h: * bytecode/InlineCallFrame.h: * bytecode/InlineCallFrameSet.h: * bytecode/Instruction.h: * bytecode/InternalFunctionAllocationProfile.h: * bytecode/JumpTable.h: * bytecode/MethodOfGettingAValueProfile.h: * bytecode/ObjectPropertyConditionSet.h: * bytecode/Operands.h: * bytecode/PolymorphicAccess.h: * bytecode/PutByIdStatus.h: * bytecode/SpeculatedType.cpp: * bytecode/StructureSet.h: * bytecode/StructureStubInfo.h: * bytecode/UnlinkedCodeBlock.h: * bytecode/UnlinkedFunctionExecutable.h: * bytecode/ValueProfile.h: * bytecompiler/BytecodeGenerator.cpp: * bytecompiler/BytecodeGenerator.h: * bytecompiler/Label.h: * bytecompiler/StaticPropertyAnalysis.h: * debugger/DebuggerCallFrame.cpp: * dfg/DFGAbstractInterpreter.h: * dfg/DFGAdjacencyList.h: * dfg/DFGArgumentsUtilities.h: * dfg/DFGArrayMode.h: * dfg/DFGArrayifySlowPathGenerator.h: * dfg/DFGBackwardsPropagationPhase.h: * dfg/DFGBasicBlock.h: * dfg/DFGCallArrayAllocatorSlowPathGenerator.h: * dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h: * dfg/DFGCapabilities.h: * dfg/DFGCommon.h: * dfg/DFGCommonData.h: * dfg/DFGDesiredIdentifiers.h: * dfg/DFGDesiredWatchpoints.h: * dfg/DFGDisassembler.cpp: * dfg/DFGDominators.h: * dfg/DFGDriver.cpp: * dfg/DFGDriver.h: * dfg/DFGEdgeDominates.h: * dfg/DFGFinalizer.h: * dfg/DFGGenerationInfo.h: * dfg/DFGJITCompiler.cpp: * dfg/DFGJITCompiler.h: * dfg/DFGJITFinalizer.h: * dfg/DFGLivenessAnalysisPhase.h: * dfg/DFGMinifiedNode.h: * dfg/DFGMultiGetByOffsetData.h: * dfg/DFGNaturalLoops.cpp: * dfg/DFGNaturalLoops.h: * dfg/DFGNode.h: * dfg/DFGOSRAvailabilityAnalysisPhase.h: * dfg/DFGOSRExit.h: * dfg/DFGOSRExitCompilationInfo.h: * dfg/DFGOSRExitCompiler.cpp: * dfg/DFGOSRExitCompiler.h: * dfg/DFGOSRExitJumpPlaceholder.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPlan.h: * dfg/DFGPreciseLocalClobberize.h: * dfg/DFGPromotedHeapLocation.h: * dfg/DFGRegisteredStructure.h: * dfg/DFGRegisteredStructureSet.h: * dfg/DFGSaneStringGetByValSlowPathGenerator.h: * dfg/DFGSlowPathGenerator.h: * dfg/DFGSnippetParams.h: * dfg/DFGSpeculativeJIT.h: * dfg/DFGToFTLDeferredCompilationCallback.h: * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.h: * dfg/DFGValidate.h: * dfg/DFGValueSource.h: * dfg/DFGVariableEvent.h: * dfg/DFGVariableEventStream.h: * dfg/DFGWorklist.h: * domjit/DOMJITCallDOMGetterSnippet.h: * domjit/DOMJITEffect.h: * ftl/FTLLink.cpp: * ftl/FTLLowerDFGToB3.cpp: * ftl/FTLPatchpointExceptionHandle.h: * heap/AllocatorAttributes.h: * heap/CodeBlockSet.h: * heap/DeferGC.h: * heap/GCSegmentedArray.h: * heap/Heap.cpp: * heap/Heap.h: * heap/IncrementalSweeper.h: * heap/ListableHandler.h: * heap/MachineStackMarker.h: * heap/MarkedAllocator.h: * heap/MarkedBlock.cpp: * heap/MarkedBlock.h: * heap/MarkingConstraint.h: * heap/SlotVisitor.cpp: * heap/SlotVisitor.h: * inspector/ConsoleMessage.cpp: * inspector/ConsoleMessage.h: * inspector/InjectedScript.h: * inspector/InjectedScriptHost.h: * inspector/InjectedScriptManager.cpp: * inspector/JSGlobalObjectInspectorController.cpp: * inspector/JavaScriptCallFrame.h: * inspector/ScriptCallStack.h: * inspector/ScriptCallStackFactory.cpp: * inspector/ScriptDebugServer.h: * inspector/agents/InspectorConsoleAgent.h: * inspector/agents/InspectorDebuggerAgent.cpp: * inspector/agents/InspectorDebuggerAgent.h: * inspector/agents/InspectorHeapAgent.cpp: * inspector/agents/InspectorHeapAgent.h: * inspector/agents/InspectorRuntimeAgent.h: * inspector/agents/InspectorScriptProfilerAgent.cpp: * inspector/agents/InspectorScriptProfilerAgent.h: * inspector/agents/JSGlobalObjectConsoleAgent.h: * inspector/agents/JSGlobalObjectDebuggerAgent.cpp: * inspector/agents/JSGlobalObjectDebuggerAgent.h: * inspector/agents/JSGlobalObjectRuntimeAgent.h: * inspector/augmentable/AlternateDispatchableAgent.h: * interpreter/CLoopStack.h: * interpreter/CachedCall.h: * interpreter/CallFrame.h: * interpreter/Interpreter.cpp: * interpreter/Interpreter.h: * jit/AssemblyHelpers.cpp: * jit/AssemblyHelpers.h: * jit/CCallHelpers.h: * jit/CallFrameShuffler.h: * jit/ExecutableAllocator.h: * jit/GCAwareJITStubRoutine.h: * jit/HostCallReturnValue.h: * jit/ICStats.h: * jit/JIT.cpp: * jit/JIT.h: * jit/JITAddGenerator.h: * jit/JITCall32_64.cpp: * jit/JITCode.h: * jit/JITDisassembler.cpp: * jit/JITExceptions.cpp: * jit/JITMathIC.h: * jit/JITOpcodes.cpp: * jit/JITOperations.cpp: * jit/JITOperations.h: * jit/JITThunks.cpp: * jit/JITThunks.h: * jit/JSInterfaceJIT.h: * jit/PCToCodeOriginMap.h: * jit/PolymorphicCallStubRoutine.h: * jit/RegisterSet.h: * jit/Repatch.h: * jit/SetupVarargsFrame.h: * jit/Snippet.h: * jit/SnippetParams.h: * jit/ThunkGenerators.h: * jsc.cpp: * llint/LLIntCLoop.h: * llint/LLIntEntrypoint.h: * llint/LLIntExceptions.h: * llint/LLIntOfflineAsmConfig.h: * llint/LLIntSlowPaths.cpp: * parser/NodeConstructors.h: * parser/Nodes.cpp: * parser/Nodes.h: * parser/Parser.cpp: * parser/Parser.h: * parser/ParserTokens.h: * parser/SourceProviderCacheItem.h: * profiler/ProfilerBytecodeSequence.h: * profiler/ProfilerDatabase.cpp: * profiler/ProfilerDatabase.h: * profiler/ProfilerOrigin.h: * profiler/ProfilerOriginStack.h: * profiler/ProfilerProfiledBytecodes.h: * profiler/ProfilerUID.h: * runtime/AbstractModuleRecord.h: * runtime/ArrayConstructor.h: * runtime/ArrayConventions.h: * runtime/ArrayIteratorPrototype.h: * runtime/ArrayPrototype.h: * runtime/BasicBlockLocation.h: * runtime/Butterfly.h: * runtime/CallData.cpp: * runtime/CodeCache.h: * runtime/CommonSlowPaths.cpp: * runtime/CommonSlowPaths.h: * runtime/CommonSlowPathsExceptions.cpp: * runtime/Completion.cpp: * runtime/ControlFlowProfiler.h: * runtime/DateInstanceCache.h: * runtime/ErrorConstructor.h: * runtime/ErrorInstance.h: * runtime/ExceptionHelpers.cpp: * runtime/ExceptionHelpers.h: * runtime/ExecutableBase.h: * runtime/FunctionExecutable.h: * runtime/HasOwnPropertyCache.h: * runtime/Identifier.h: * runtime/InternalFunction.h: * runtime/IntlCollator.cpp: * runtime/IntlCollatorPrototype.h: * runtime/IntlDateTimeFormatPrototype.h: * runtime/IntlNumberFormat.cpp: * runtime/IntlNumberFormatPrototype.h: * runtime/IteratorOperations.cpp: * runtime/JSArray.h: * runtime/JSArrayBufferPrototype.h: * runtime/JSCJSValue.h: * runtime/JSCJSValueInlines.h: * runtime/JSCell.h: * runtime/JSFunction.cpp: * runtime/JSFunction.h: * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: * runtime/JSGlobalObject.cpp: * runtime/JSGlobalObject.h: * runtime/JSGlobalObjectDebuggable.cpp: * runtime/JSGlobalObjectDebuggable.h: * runtime/JSGlobalObjectFunctions.cpp: * runtime/JSGlobalObjectFunctions.h: * runtime/JSJob.cpp: * runtime/JSLock.h: * runtime/JSModuleLoader.cpp: * runtime/JSModuleNamespaceObject.h: * runtime/JSModuleRecord.h: * runtime/JSObject.cpp: * runtime/JSObject.h: * runtime/JSRunLoopTimer.h: * runtime/JSTemplateRegistryKey.h: * runtime/JSTypedArrayPrototypes.cpp: * runtime/JSTypedArrayPrototypes.h: * runtime/JSTypedArrays.h: * runtime/LiteralParser.h: * runtime/MatchResult.h: * runtime/MemoryStatistics.h: * runtime/PrivateName.h: * runtime/PromiseDeferredTimer.h: * runtime/ProxyObject.h: * runtime/RegExp.h: * runtime/SamplingProfiler.cpp: * runtime/SmallStrings.h: * runtime/StringPrototype.cpp: * runtime/StringRecursionChecker.h: * runtime/Structure.h: * runtime/SymbolConstructor.h: * runtime/SymbolPrototype.cpp: * runtime/SymbolPrototype.h: * runtime/TypeProfiler.h: * runtime/TypeProfilerLog.h: * runtime/TypedArrayType.h: * runtime/VM.cpp: * runtime/VM.h: * runtime/VMEntryScope.h: * runtime/WeakMapData.h: * runtime/WriteBarrier.h: * tools/FunctionOverrides.cpp: * tools/FunctionOverrides.h: * wasm/WasmBinding.cpp: * wasm/js/JSWebAssemblyCodeBlock.h: * wasm/js/WebAssemblyPrototype.cpp: * yarr/Yarr.h: * yarr/YarrJIT.cpp: * yarr/YarrJIT.h: * yarr/YarrParser.h: 2017-06-24 Yusuke Suzuki [JSC] Clean up Object.entries implementation https://bugs.webkit.org/show_bug.cgi?id=173759 Reviewed by Sam Weinig. This patch cleans up Object.entries implementation. We drop unused private functions. And we merge the implementation into Object.entries. It slightly speeds up Object.entries speed. baseline patched object-entries 148.0101+-5.6627 142.1877+-4.8661 might be 1.0409x faster * builtins/BuiltinNames.h: * builtins/ObjectConstructor.js: (entries): (globalPrivate.enumerableOwnProperties): Deleted. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/ObjectConstructor.cpp: (JSC::ownEnumerablePropertyKeys): Deleted. * runtime/ObjectConstructor.h: 2017-06-24 Joseph Pecoraro Remove Reflect.enumerate https://bugs.webkit.org/show_bug.cgi?id=173806 Reviewed by Yusuke Suzuki. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * inspector/JSInjectedScriptHost.cpp: (Inspector::JSInjectedScriptHost::subtype): (Inspector::JSInjectedScriptHost::getInternalProperties): (Inspector::JSInjectedScriptHost::iteratorEntries): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildren): * runtime/JSPropertyNameIterator.cpp: Removed. * runtime/JSPropertyNameIterator.h: Removed. * runtime/ReflectObject.cpp: (JSC::reflectObjectEnumerate): Deleted. 2017-06-23 Keith Miller Switch VMTraps to use halt instructions rather than breakpoint instructions https://bugs.webkit.org/show_bug.cgi?id=173677 Reviewed by JF Bastien. Using the breakpoint instruction for VMTraps caused issues with lldb. Since we only need some way to stop execution we can, in theory, use any exceptioning instruction we want. I went with the halt instruction on X86 since that is the only one byte instruction that does not breakpoint (in my tests both 0xf1 and 0xd6 produced EXC_BREAKPOINT). On ARM we use the data cache clearing instruction with the zero register, which triggers a segmentation fault. Also, update the platform code to only use signaling VMTraps on where we have an appropriate instruction (x86 and ARM64). * API/tests/ExecutionTimeLimitTest.cpp: (testExecutionTimeLimit): * assembler/ARM64Assembler.h: (JSC::ARM64Assembler::replaceWithVMHalt): (JSC::ARM64Assembler::dataCacheZeroVirtualAddress): (JSC::ARM64Assembler::replaceWithBkpt): Deleted. * assembler/ARMAssembler.h: (JSC::ARMAssembler::replaceWithBkpt): Deleted. * assembler/ARMv7Assembler.h: (JSC::ARMv7Assembler::replaceWithBkpt): Deleted. * assembler/MIPSAssembler.h: (JSC::MIPSAssembler::replaceWithBkpt): Deleted. * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::replaceWithBreakpoint): Deleted. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::replaceWithVMHalt): (JSC::MacroAssemblerARM64::replaceWithBreakpoint): Deleted. * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::storeFence): (JSC::MacroAssemblerARMv7::replaceWithBreakpoint): Deleted. * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::replaceWithBreakpoint): Deleted. * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::replaceWithVMHalt): (JSC::MacroAssemblerX86Common::replaceWithBreakpoint): Deleted. * assembler/X86Assembler.h: (JSC::X86Assembler::replaceWithHlt): (JSC::X86Assembler::replaceWithInt3): Deleted. * dfg/DFGJumpReplacement.cpp: (JSC::DFG::JumpReplacement::installVMTrapBreakpoint): * runtime/VMTraps.cpp: (JSC::SignalContext::SignalContext): (JSC::installSignalHandler): (JSC::SignalContext::adjustPCToPointToTrappingInstruction): Deleted. * wasm/WasmFaultSignalHandler.cpp: (JSC::Wasm::enableFastMemory): 2017-06-22 Saam Barati The lowering of Identity in the DFG backend needs to use ManualOperandSpeculation https://bugs.webkit.org/show_bug.cgi?id=173743 Reviewed by Mark Lam. The code always manually speculates, however, we weren't specifying ManualOperandSpeculation when creating a JSValueOperand. This would fire an assertion in JSValueOperand construction for a node like: Identity(String:@otherNode) I spent about 45 minutes trying to craft a test and came up empty. However, this fixes a debug assertion on an internal Apple website. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2017-06-22 Saam Barati ValueRep(DoubleRep(@v)) can not simply convert to @v https://bugs.webkit.org/show_bug.cgi?id=173687 Reviewed by Mark Lam. Consider this IR: block#x p: Phi() // int32 and double flows into this phi from various control flow d: DoubleRep(@p) some uses of @d here v: ValueRep(DoubleRepUse:@d) a: NewArrayWithSize(Int32:@v) some more nodes here ... Because the flow of ValueRep(DoubleRep(@p)) will not produce an Int32, AI proves that the Int32 check will fail. Constant folding phase removes all nodes after @a and inserts an Unreachable after the NewArrayWithSize node. The IR then looks like this: block#x p: Phi() // int32 and double flows into this phi from various control flow d: DoubleRep(@p) some uses of @d here v: ValueRep(DoubleRepUse:@d) a: NewArrayWithSize(Int32:@v) Unreachable However, there was a strength reduction rule that tries eliminate redundant conversions. It used to convert the program to: block#x p: Phi() // int32 and double flows into this phi from various control flow d: DoubleRep(@p) some uses of @d here a: NewArrayWithSize(Int32:@p) Unreachable However, at runtime, @p will actually be an Int32, so @a will not OSR exit, and we'll crash. This patch removes this strength reduction rule since it does not maintain what would have happened if we executed the program before the rule. This rule is also wrong for other types of programs (I'm not sure we'd actually emit this code, but if such IR were generated, we would previously optimize it incorrectly): @a: Constant(JSTrue) @b: DoubleRep(@a) @c: ValueRep(@b) @d: use(@c) However, the strength reduction rule would've transformed this into: @a: Constant(JSTrue) @d: use(@a) And this would be wrong because node @c before the transformation would have produced the JSValue jsNumber(1.0). This patch was neutral in the benchmark run I did. * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::handleNode): 2017-06-22 JF Bastien ARM64: doubled executable memory limit from 32MiB to 64MiB https://bugs.webkit.org/show_bug.cgi?id=173734 Reviewed by Oliver Hunt. Some WebAssembly programs stress the amount of memory we have available, especially when we consider tiering (BBQ never dies, and is bigger that OMG). Tiering to OMG just piles on more memory, and we're also competing with JavaScript. * jit/ExecutableAllocator.h: 2017-06-22 Joseph Pecoraro Web Inspector: Pausing with a deep call stack can be very slow, avoid eagerly generating object previews https://bugs.webkit.org/show_bug.cgi?id=173698 Reviewed by Matt Baker. When pausing in a deep call stack the majority of the time spent in JavaScriptCore when preparing Inspector pause information is spent generating object previews for the `thisObject` of each of the call frames. In some cases, this could be more than 95% of the time generating pause information. In the common case, only one of these (the top frame) will ever be seen by users. This change avoids eagerly generating object previews up front and let the frontend request previews if they are needed. This introduces the `Runtime.getPreview` protocol command. This can be used to: - Get a preview for a RemoteObject that did not have a preview but could. - Update a preview for a RemoteObject that had a preview. This patch only uses it for the first case, but the second is valid and may be something we want to do in the future. * inspector/protocol/Runtime.json: A new command to get an up to date preview for an object. * inspector/InjectedScript.h: * inspector/InjectedScript.cpp: (Inspector::InjectedScript::getPreview): * inspector/agents/InspectorRuntimeAgent.cpp: (Inspector::InspectorRuntimeAgent::getPreview): * inspector/agents/InspectorRuntimeAgent.h: Plumbing for the new command. * inspector/InjectedScriptSource.js: (InjectedScript.prototype.getPreview): Implementation just uses the existing helper. (InjectedScript.CallFrameProxy): Do not generate a preview for the this object as it may not be shown. Let the frontend request a preview if it wants or needs one. 2017-06-22 Joseph Pecoraro Web Inspector: Remove stale "rawScopes" concept that was never available in JSC https://bugs.webkit.org/show_bug.cgi?id=173686 Reviewed by Mark Lam. * inspector/InjectedScript.cpp: (Inspector::InjectedScript::functionDetails): * inspector/InjectedScriptSource.js: (InjectedScript.prototype.functionDetails): * inspector/JSInjectedScriptHost.cpp: (Inspector::JSInjectedScriptHost::functionDetails): 2017-06-22 Yusuke Suzuki [JSC] Object.values should be implemented in C++ https://bugs.webkit.org/show_bug.cgi?id=173703 Reviewed by Sam Weinig. As the same to Object.assign, Object.values() is also inherently polymorphic. And allocating JSString / Symbol for Identifier and JSArray for Object.keys() result is costly. In this patch, we implement Object.values() in C++. It can avoid above allocations. Furthermore, by using `slot.isTaintedByOpaqueObject()` information, we can skip non-observable JSObject::get() calls. This improves performance by 2.49x. And also now Object.values() beats Object.keys(object).map(key => object[key]) implementation. baseline patched object-values 132.1551+-3.7209 ^ 53.1254+-1.6139 ^ definitely 2.4876x faster object-keys-map-values 78.2008+-2.1378 ? 78.9078+-2.2121 ? * builtins/ObjectConstructor.js: (values): Deleted. * runtime/ObjectConstructor.cpp: (JSC::objectConstructorValues): 2017-06-21 Saam Barati ArrayPrototype.map builtin declares a var it does not use https://bugs.webkit.org/show_bug.cgi?id=173685 Reviewed by Keith Miller. * builtins/ArrayPrototype.js: (map): 2017-06-21 Saam Barati eval virtual call is incorrect in the baseline JIT https://bugs.webkit.org/show_bug.cgi?id=173587 Reviewed by Michael Saboff. When making a virtual call for call_eval, e.g, when the thing we're calling isn't actually eval, we end up calling the caller instead of the callee. This is clearly wrong. The code ends up issuing a load for the Callee in the callers frame instead of the callee we're calling. The fix is simple, we just need to load the real callee. Only the 32-bit baseline JIT had this bug. * jit/JITCall32_64.cpp: (JSC::JIT::compileCallEvalSlowCase): 2017-06-21 Joseph Pecoraro Web Inspector: Using "break on all exceptions" when throwing stack overflow hangs inspector https://bugs.webkit.org/show_bug.cgi?id=172432 Reviewed by Saam Barati. Avoid pausing on StackOverflow and OutOfMemory errors to avoid a hang. We will proceed to improve debugging of these cases in the follow-up bugs. * debugger/Debugger.cpp: (JSC::Debugger::exception): Ignore pausing on these errors. * runtime/ErrorInstance.h: (JSC::ErrorInstance::setStackOverflowError): (JSC::ErrorInstance::isStackOverflowError): (JSC::ErrorInstance::setOutOfMemoryError): (JSC::ErrorInstance::isOutOfMemoryError): * runtime/ExceptionHelpers.cpp: (JSC::createStackOverflowError): * runtime/Error.cpp: (JSC::createOutOfMemoryError): Mark these kinds of errors. 2017-06-21 Saam Barati Make it clear that regenerating ICs are holding the CodeBlock's lock by passing the locker as a parameter https://bugs.webkit.org/show_bug.cgi?id=173609 Reviewed by Keith Miller. This patch makes many of the IC generating functions require a locker as a parameter. We do this in other places in JSC to indicate that a particular API is only valid while a particular lock is held. This is the case when generating ICs. This patch just makes it explicit in the IC generating interface. * bytecode/PolymorphicAccess.cpp: (JSC::PolymorphicAccess::addCases): (JSC::PolymorphicAccess::addCase): (JSC::PolymorphicAccess::commit): (JSC::PolymorphicAccess::regenerate): * bytecode/PolymorphicAccess.h: * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::addAccessCase): (JSC::StructureStubInfo::initStub): Deleted. * bytecode/StructureStubInfo.h: * jit/Repatch.cpp: (JSC::tryCacheGetByID): (JSC::repatchGetByID): (JSC::tryCachePutByID): (JSC::repatchPutByID): (JSC::tryRepatchIn): (JSC::repatchIn): 2017-06-20 Myles C. Maxfield Disable font variations on macOS Sierra and iOS 10 https://bugs.webkit.org/show_bug.cgi?id=173618 Reviewed by Jon Lee. * Configurations/FeatureDefines.xcconfig: 2017-06-20 Keith Miller Fix leak of ModuleInformations in BBQPlan constructors. https://bugs.webkit.org/show_bug.cgi?id=173577 Reviewed by Saam Barati. This patch fixes a leak in the BBQPlan constructiors. Previously, the plans were calling makeRef on the newly constructed objects. This patch fixes the issue and uses adoptRef instead. Additionally, an old, incorrect, attempt to fix the leak is removed. * inspector/remote/cocoa/RemoteInspectorXPCConnection.mm: (Inspector::RemoteInspectorXPCConnection::RemoteInspectorXPCConnection): * jit/JITWorklist.cpp: (JSC::JITWorklist::Thread::Thread): * runtime/PromiseDeferredTimer.cpp: (JSC::PromiseDeferredTimer::addPendingPromise): * runtime/VM.cpp: (JSC::VM::VM): * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::BBQPlan): * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::Plan): 2017-06-20 Devin Rousso Web Inspector: Send context attributes for tracked canvases https://bugs.webkit.org/show_bug.cgi?id=173327 Reviewed by Joseph Pecoraro. * inspector/protocol/Canvas.json: Add ContextAttributes object type that is optionally used for WebGL canvases. 2017-06-20 Konstantin Tokarev Remove excessive include directives from WTF https://bugs.webkit.org/show_bug.cgi?id=173553 Reviewed by Saam Barati. * profiler/ProfilerDatabase.cpp: Added missing include directive. * runtime/SamplingProfiler.cpp: Ditto. 2017-06-20 Oleksandr Skachkov Revert changes in bug#160417 about extending `null` not being a derived class https://bugs.webkit.org/show_bug.cgi?id=169293 Reviewed by Saam Barati. Reverted changes in bug#160417 about extending `null` not being a derived class according to changes in spec: https://github.com/tc39/ecma262/commit/c57ef95c45a371f9c9485bb1c3881dbdc04524a2 * builtins/BuiltinNames.h: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::emitReturn): * bytecompiler/NodesCodegen.cpp: (JSC::ClassExprNode::emitBytecode): 2017-06-20 Saam Barati repatchIn needs to lock the CodeBlock's lock https://bugs.webkit.org/show_bug.cgi?id=173573 Reviewed by Yusuke Suzuki. CodeBlock::propagateTransitions and CodeBlock::visitWeakly grab the CodeBlock's lock before modifying the StructureStubInfo/PolymorphicAccess. When regenerating an IC, we must hold the CodeBlock's to prevent the executing thread from racing with the marking thread. repatchIn was not grabbing the lock. I haven't been able to get it to crash, but this is needed for the same reasons that get and put IC regeneration grab the lock. * jit/Repatch.cpp: (JSC::repatchIn): 2017-06-19 Devin Rousso Web Inspector: create canvas content view and details sidebar panel https://bugs.webkit.org/show_bug.cgi?id=138941 Reviewed by Joseph Pecoraro. * inspector/protocol/Canvas.json: - Add an optional `nodeId` attribute to the `Canvas` type. - Add `requestNode` command for getting the node id of the backing canvas element. - Add `requestContent` command for getting the current image content of the canvas. 2017-06-19 Yusuke Suzuki Unreviewed, build fix for ARM * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::internalCompare32): 2017-06-13 Yusuke Suzuki [DFG] More ArrayIndexOf fixups for various types https://bugs.webkit.org/show_bug.cgi?id=173176 Reviewed by Saam Barati. This patch further expands coverage of ArrayIndexOf optimization in DFG and FTL. 1. We attempt to fold ArrayIndexOf to constant (-1) if we know that its array never contains the given search value. 2. We support Symbol and Other specialization additionally. Especially, Other is useful because null/undefined can be used as a sentinel value. One interesting thing is that Array.prototype.indexOf does not consider holes as undefineds. Thus, var array = [,,,,,,,]; array.indexOf(undefined); // => -1 This can be trivially achieved in JSC because Empty and Undefined are different values. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::fixupArrayIndexOf): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArrayIndexOf): (JSC::DFG::SpeculativeJIT::speculateOther): * dfg/DFGSpeculativeJIT.h: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileArrayIndexOf): 2017-06-19 Caio Lima [ARMv6][DFG] ARM MacroAssembler is always emitting cmn when immediate is 0 https://bugs.webkit.org/show_bug.cgi?id=172972 Reviewed by Mark Lam. We are changing internalCompare32 implementation in ARM MacroAssembler to emit "cmp" when the "right.value" is 0. It is generating wrong comparison cases, since the semantics of cmn is opposite of cmp[1]. One case that it's breaking is "branch32(MacroAssembler::Above, gpr, TrustedImm32(0))", where ends resulting in following assembly code: ``` cmn $r0, #0 bhi
``` However, as cmn is similar to "adds", it will never take the branch when $r0 > 0. In that case, the correct opcode is "cmp". With this patch we will fix current broken tests that uses "branch32(MacroAssembler::Above, gpr, TrustedImm32(0))", such as ForwardVarargs, Spread and GetRestLength. [1] - http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204j/Cihiddid.html * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::internalCompare32): 2017-06-19 Joseph Pecoraro test262: Completion values for control flow do not match the spec https://bugs.webkit.org/show_bug.cgi?id=171265 Reviewed by Saam Barati. * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::shouldBeConcernedWithCompletionValue): When we care about having proper completion values (global code in programs, modules, and eval) insert undefined results for control flow statements. * bytecompiler/NodesCodegen.cpp: (JSC::SourceElements::emitBytecode): Reduce writing a default `undefined` value to the completion result to only once before the last statement we know will produce a value. (JSC::IfElseNode::emitBytecode): (JSC::WithNode::emitBytecode): (JSC::WhileNode::emitBytecode): (JSC::ForNode::emitBytecode): (JSC::ForInNode::emitBytecode): (JSC::ForOfNode::emitBytecode): (JSC::SwitchNode::emitBytecode): Insert an undefined to handle cases where code may break out of an if/else or with statement (break/continue). (JSC::TryNode::emitBytecode): Same handling for break cases. Also, finally block statement completion values are always ignored for the try statement result. (JSC::ClassDeclNode::emitBytecode): Class declarations, like function declarations, produce an empty result. * parser/Nodes.cpp: (JSC::SourceElements::lastStatement): (JSC::SourceElements::hasCompletionValue): (JSC::SourceElements::hasEarlyBreakOrContinue): (JSC::BlockNode::lastStatement): (JSC::BlockNode::singleStatement): (JSC::BlockNode::hasCompletionValue): (JSC::BlockNode::hasEarlyBreakOrContinue): (JSC::ScopeNode::singleStatement): (JSC::ScopeNode::hasCompletionValue): (JSC::ScopeNode::hasEarlyBreakOrContinue): The only non-trivial cases need to loop through their list of statements to determine if this has a completion value or not. Likewise for determining if there is an early break / continue, meaning a break or continue statement with no preceding statement that has a completion value. * parser/Nodes.h: (JSC::StatementNode::next): (JSC::StatementNode::hasCompletionValue): Helper to check if a statement nodes produces a completion value or not. 2017-06-19 Adrian Perez de Castro Missing includes make builds fail with GCC 7.x https://bugs.webkit.org/show_bug.cgi?id=173544 Unreviewed gardening. Fix compilation with GCC 7. * API/tests/CompareAndSwapTest.cpp: * runtime/VMEntryScope.h: 2017-06-17 Keith Miller ArrayBuffer constructor needs to create subclass structures before its buffer https://bugs.webkit.org/show_bug.cgi?id=173510 Reviewed by Yusuke Suzuki. * runtime/JSArrayBufferConstructor.cpp: (JSC::constructArrayBuffer): 2017-06-17 Keith Miller ArrayPrototype methods should use JSValue::toLength for non-Arrays. https://bugs.webkit.org/show_bug.cgi?id=173506 Reviewed by Ryosuke Niwa. This patch changes the result of unshift if old length + unshift.arguments.length > (2 ** 53) - 1 to be a type error. Also, the getLength function, which was always incorrect to use, has been removed. Additionally, some cases where we were using a constant for (2 ** 53) - 1 have been replaced with maxSafeInteger() * interpreter/Interpreter.cpp: (JSC::sizeOfVarargs): * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncToLocaleString): (JSC::arrayProtoFuncPop): (JSC::arrayProtoFuncPush): (JSC::arrayProtoFuncReverse): (JSC::arrayProtoFuncShift): (JSC::arrayProtoFuncSlice): (JSC::arrayProtoFuncSplice): (JSC::arrayProtoFuncUnShift): (JSC::arrayProtoFuncIndexOf): (JSC::arrayProtoFuncLastIndexOf): * runtime/JSArrayInlines.h: (JSC::getLength): Deleted. * runtime/JSCJSValue.cpp: (JSC::JSValue::toLength): * runtime/NumberConstructor.cpp: (JSC::numberConstructorFuncIsSafeInteger): 2017-06-16 Matt Baker Web Inspector: Instrument 2D/WebGL canvas contexts in the backend https://bugs.webkit.org/show_bug.cgi?id=172623 Reviewed by Devin Rousso and Joseph Pecoraro. This patch adds a basic Canvas protocol. It includes Canvas and related types and events for monitoring the lifetime of canvases in the page. * CMakeLists.txt: * DerivedSources.make: * inspector/protocol/Canvas.json: Added. * inspector/scripts/codegen/generator.py: (Generator.stylized_name_for_enum_value): Add special handling for Canvas.ContextType protocol enumeration, so that "canvas-2d" and "webgl" map to `Canvas2D` and `WebGL`. 2017-06-16 Wenson Hsieh [iOS DnD] Upstream iOS drag and drop implementation into OpenSource WebKit https://bugs.webkit.org/show_bug.cgi?id=173366 Reviewed by Tim Horton. Introduce ENABLE_DATA_INTERACTION and ENABLE_DRAG_SUPPORT to FeatureDefines.xcconfig. * Configurations/FeatureDefines.xcconfig: 2017-06-16 Yusuke Suzuki [JSC] Add fast path for Object.assign https://bugs.webkit.org/show_bug.cgi?id=173416 Reviewed by Mark Lam. In Object.assign implementation, we need to ensure that given key is still enumerable own key. This seems duplicate look up. And we want to avoid this. However, we still need to perform this check in the face of Proxy. Proxy can observe that this check is done correctly. In almost all the cases, the above check is duplicate to the subsequent [[Get]] operation. In this patch, we perform this check. But at that time, we investigate `isTaintedByOpaqueObject()`. If it is false, we can say that getOwnPropertySlot is pure. In that case, we can just retrieve the value by calling `slot.getValue()`. This further improves performance of Object.assign. baseline patched object-assign.es6 363.6706+-6.4381 ^ 324.1769+-6.9624 ^ definitely 1.1218x faster * runtime/ObjectConstructor.cpp: (JSC::objectConstructorAssign): 2017-06-16 Michael Saboff Intermittent crash running Internal/Tests/InternalJSTests/Regress/radar-24300617.js https://bugs.webkit.org/show_bug.cgi?id=173488 Reviewed by Filip Pizlo. ClonedArguments lazily sets its callee and interator properties and it used its own inline code to initialize its butterfly. This means that these lazily set properties can have bogus values in those slots. Instead, let's use the standard BUtterfly:tryCreate() method to create the butterfly as it clears out of line properties. * runtime/ClonedArguments.cpp: (JSC::ClonedArguments::createEmpty): 2017-06-16 Mark Lam Interpreter methods for mapping between Opcode and OpcodeID need not be instance methods. https://bugs.webkit.org/show_bug.cgi?id=173491 Reviewed by Keith Miller. The implementation are based on static data. There's no need to get the interpreter instance. Hence, we can make these methods static and avoid doing unnecessary work to compute the interpreter this pointer. Also removed the unused isCallBytecode method. * bytecode/BytecodeBasicBlock.cpp: (JSC::BytecodeBasicBlock::computeImpl): * bytecode/BytecodeDumper.cpp: (JSC::BytecodeDumper::printGetByIdOp): (JSC::BytecodeDumper::printGetByIdCacheStatus): (JSC::BytecodeDumper::dumpBytecode): (JSC::BytecodeDumper::dumpBlock): * bytecode/BytecodeLivenessAnalysis.cpp: (JSC::BytecodeLivenessAnalysis::dumpResults): * bytecode/BytecodeLivenessAnalysisInlines.h: (JSC::BytecodeLivenessPropagation::stepOverInstruction): * bytecode/BytecodeRewriter.cpp: (JSC::BytecodeRewriter::adjustJumpTargetsInFragment): * bytecode/CallLinkStatus.cpp: (JSC::CallLinkStatus::computeFromLLInt): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): (JSC::CodeBlock::propagateTransitions): (JSC::CodeBlock::finalizeLLIntInlineCaches): (JSC::CodeBlock::hasOpDebugForLineAndColumn): (JSC::CodeBlock::usesOpcode): (JSC::CodeBlock::valueProfileForBytecodeOffset): (JSC::CodeBlock::arithProfileForPC): (JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler): * bytecode/PreciseJumpTargets.cpp: (JSC::getJumpTargetsForBytecodeOffset): (JSC::computePreciseJumpTargetsInternal): (JSC::findJumpTargetsForBytecodeOffset): * bytecode/PreciseJumpTargetsInlines.h: (JSC::extractStoredJumpTargetsForBytecodeOffset): * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::applyModification): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * interpreter/Interpreter.cpp: (JSC::Interpreter::Interpreter): (JSC::Interpreter::isOpcode): (): Deleted. * interpreter/Interpreter.h: (JSC::Interpreter::getOpcode): Deleted. (JSC::Interpreter::getOpcodeID): Deleted. (JSC::Interpreter::isCallBytecode): Deleted. * interpreter/InterpreterInlines.h: (JSC::Interpreter::getOpcode): (JSC::Interpreter::getOpcodeID): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): * jit/JITOpcodes.cpp: (JSC::JIT::emitNewFuncCommon): (JSC::JIT::emitNewFuncExprCommon): * jit/JITPropertyAccess.cpp: (JSC::JIT::emitSlow_op_put_by_val): (JSC::JIT::privateCompilePutByVal): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emitSlow_op_put_by_val): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::llint_trace_operand): (JSC::LLInt::llint_trace_value): (JSC::LLInt::LLINT_SLOW_PATH_DECL): * profiler/ProfilerBytecodeSequence.cpp: (JSC::Profiler::BytecodeSequence::BytecodeSequence): 2017-06-16 Matt Lewis Unreviewed, rolling out r218376. The patch cause multiple Layout Test Crashes. Reverted changeset: "Web Inspector: Instrument 2D/WebGL canvas contexts in the backend" https://bugs.webkit.org/show_bug.cgi?id=172623 http://trac.webkit.org/changeset/218376 2017-06-16 Konstantin Tokarev REGRESSION(r166799): LogsPageMessagesToSystemConsoleEnabled corrupts non-ASCII characters https://bugs.webkit.org/show_bug.cgi?id=173470 Reviewed by Joseph Pecoraro. ConsoleClient::printConsoleMessageWithArguments() incorrectly uses const char* overload of StringBuilder::append() that assummes Latin1 encoding, not UTF8. * runtime/ConsoleClient.cpp: (JSC::ConsoleClient::printConsoleMessageWithArguments): 2017-06-15 Mark Lam Add a JSRunLoopTimer registry in VM. https://bugs.webkit.org/show_bug.cgi?id=173429 Reviewed by Filip Pizlo. This way, we can be sure we've got every JSRunLoopTimer instance covered if we need to change their run loop (e.g. when setting to the WebThread's run loop). * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::setRunLoop): Deleted. * heap/Heap.h: (JSC::Heap::runLoop): Deleted. * runtime/JSRunLoopTimer.cpp: (JSC::JSRunLoopTimer::JSRunLoopTimer): (JSC::JSRunLoopTimer::setRunLoop): (JSC::JSRunLoopTimer::~JSRunLoopTimer): * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::registerRunLoopTimer): (JSC::VM::unregisterRunLoopTimer): (JSC::VM::setRunLoop): * runtime/VM.h: (JSC::VM::runLoop): 2017-06-15 Joseph Pecoraro [Cocoa] Modernize some internal initializers to use instancetype instead of id https://bugs.webkit.org/show_bug.cgi?id=173112 Reviewed by Wenson Hsieh. * API/JSContextInternal.h: * API/JSWrapperMap.h: * API/JSWrapperMap.mm: (-[JSObjCClassInfo initForClass:]): (-[JSWrapperMap initWithGlobalContextRef:]): 2017-06-15 Matt Baker Web Inspector: Instrument 2D/WebGL canvas contexts in the backend https://bugs.webkit.org/show_bug.cgi?id=172623 Reviewed by Devin Rousso. This patch adds a basic Canvas protocol. It includes Canvas and related types and events for monitoring the lifetime of canvases in the page. * CMakeLists.txt: * DerivedSources.make: * inspector/protocol/Canvas.json: Added. * inspector/scripts/codegen/generator.py: (Generator.stylized_name_for_enum_value): Add special handling for Canvas.ContextType protocol enumeration, so that "canvas-2d" and "webgl" map to `Canvas2D` and `WebGL`. 2017-06-15 Keith Miller Add logging to MachineStackMarker to try to diagnose crashes in the wild https://bugs.webkit.org/show_bug.cgi?id=173427 Reviewed by Mark Lam. This patch adds some logging to the MachineStackMarker constructor to help figure out where we are seeing crashes. Since macOS does not support os_log_info my hope is that if we set all the callee save registers before making any calls in the C++ code we can figure out which calls is the source of the crash. We also, set all the caller save registers before returning in case some weirdness is happening in the Heap constructor. This logging should not matter from a performance perspective. We only create MachineStackMarkers when we are creating a new VM, which is already expensive. * heap/MachineStackMarker.cpp: (JSC::MachineThreads::MachineThreads): 2017-06-15 Yusuke Suzuki [JSC] Implement Object.assign in C++ https://bugs.webkit.org/show_bug.cgi?id=173414 Reviewed by Saam Barati. Implementing Object.assign in JS is not so good compared to C++ version because, 1. JS version allocates JS array for object own keys. And we allocate JSString / Symbol for each key. But basically, they can be handled as UniquedStringImpl in C++. Allocating these cells are wasteful. 2. While implementing builtins in JS offers some good type speculation chances, Object.assign is inherently super polymorphic. So JS's type profile doesn't help well. 3. We have a chance to introduce various fast path for Object.assign in C++. This patch moves implementation from JS to C++. It achieves the above (1) and (2). (3) is filed in [1]. We can see 1.65x improvement in SixSpeed object-assign.es6. baseline patched object-assign.es6 643.3253+-8.0521 ^ 389.1075+-8.8840 ^ definitely 1.6533x faster [1]: https://bugs.webkit.org/show_bug.cgi?id=173416 * builtins/ObjectConstructor.js: (entries): (assign): Deleted. * runtime/JSCJSValueInlines.h: (JSC::JSValue::putInline): * runtime/JSCell.h: * runtime/JSCellInlines.h: (JSC::JSCell::putInline): * runtime/JSObject.cpp: (JSC::JSObject::put): * runtime/JSObject.h: * runtime/JSObjectInlines.h: (JSC::JSObject::putInlineForJSObject): (JSC::JSObject::putInline): Deleted. * runtime/ObjectConstructor.cpp: (JSC::objectConstructorAssign): 2017-06-14 Dan Bernstein [Cocoa] Objective-C class whose name begins with an underscore can’t be exported to JavaScript https://bugs.webkit.org/show_bug.cgi?id=168578 Reviewed by Geoff Garen. * API/JSWrapperMap.mm: (allocateConstructorForCustomClass): Updated for change to forEachProtocolImplementingProtocol. (-[JSObjCClassInfo allocateConstructorAndPrototype]): Ditto. (-[JSWrapperMap classInfoForClass:]): If the class name begins with an underscore, check if it defines conformance to a JSExport-derived protocol and if so, avoid using the superclass as a substitute as we’d normally do. * API/ObjcRuntimeExtras.h: (forEachProtocolImplementingProtocol): Added a "stop" argument to the block to let callers bail out. * API/tests/JSExportTests.mm: (+[JSExportTests classNamePrefixedWithUnderscoreTest]): New test for this. (runJSExportTests): Run new test. 2017-06-14 Yusuke Suzuki Unreviewed, suppress invalid register alloation validation assertion in 32 bit part 2 https://bugs.webkit.org/show_bug.cgi?id=172421 * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArrayIndexOf): 2017-06-14 Claudio Saavedra REGRESSION: 15 new jsc failures in WPE and GTK+ https://bugs.webkit.org/show_bug.cgi?id=173349 Reviewed by JF Bastien. Recent changes to generateWasm.py are not accounted for from CMake, which leads to WasmOps.h not being regenerated in partial builds. Make generateWasm.py an additional dependency. * CMakeLists.txt: 2017-06-13 Joseph Pecoraro Debugger has unexpected effect on program correctness https://bugs.webkit.org/show_bug.cgi?id=172683 Reviewed by Saam Barati. * inspector/InjectedScriptSource.js: (InjectedScript.RemoteObject.prototype._appendPropertyPreviews): (InjectedScript.RemoteObject.prototype._isPreviewableObjectInternal): (BasicCommandLineAPI): Eliminate for..of use with Arrays from InjectedScriptSource as it can be observable. We still use it for Set / Map iteration which we can eliminate when moving to builtins. 2017-06-13 JF Bastien WebAssembly: fix erroneous signature comment https://bugs.webkit.org/show_bug.cgi?id=173334 Reviewed by Keith Miller. * wasm/WasmSignature.h: 2017-06-13 Michael Saboff Refactor AbsenceOfSetter to AbsenceOfSetEffects https://bugs.webkit.org/show_bug.cgi?id=173322 Reviewed by Filip Pizlo. * bytecode/ObjectPropertyCondition.h: (JSC::ObjectPropertyCondition::absenceOfSetEffectWithoutBarrier): (JSC::ObjectPropertyCondition::absenceOfSetEffect): (JSC::ObjectPropertyCondition::absenceOfSetterWithoutBarrier): Deleted. (JSC::ObjectPropertyCondition::absenceOfSetter): Deleted. * bytecode/ObjectPropertyConditionSet.cpp: (JSC::generateConditionsForPropertySetterMiss): (JSC::generateConditionsForPropertySetterMissConcurrently): * bytecode/PropertyCondition.cpp: (JSC::PropertyCondition::dumpInContext): (JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint): (JSC::PropertyCondition::isStillValid): (WTF::printInternal): * bytecode/PropertyCondition.h: (JSC::PropertyCondition::absenceOfSetEffectWithoutBarrier): (JSC::PropertyCondition::absenceOfSetEffect): (JSC::PropertyCondition::hasPrototype): (JSC::PropertyCondition::hash): (JSC::PropertyCondition::operator==): (JSC::PropertyCondition::absenceOfSetterWithoutBarrier): Deleted. (JSC::PropertyCondition::absenceOfSetter): Deleted. 2017-06-13 JF Bastien WebAssembly: import updated spec tests https://bugs.webkit.org/show_bug.cgi?id=173287 Reviewed by Saam Barati. Import spec tests as of 31c641cc15f2aedbec2fa45a5185f68416df578b, with a few modifications so things work. Fix a bunch of bugs found through this process, and punt a few tests (which I marked as blocked by this bug). Fixes: Fix load / store alignment: r216908 erroneously implemented it as bit alignment instead of byte alignment. It was also missing memory-alignment.js despite it being in the ChangeLog, so add it too. This allows spec-test/align.wast.js to pass. Tables can be imported or in a section. There can be only one, but sections can be empty. An Elements section can exist if there's no Table, as long as it is also empty. Memories can be imported or in a section. There can be only one, but sections can be empty. A Data section can exist if there's no Memory, as long as it is also empty. Prototypes: stringify without .prototype. in the string. WebAssembly.Table.prototype.grow was plain wrong: it takes a delta parameter, not a final size, and throws a RangeError on failure, not a TypeError. Fix compile / instantiate so the reject the promise if given an argument of the wrong type (instead of failing instantly). Fix async on neuter test. Element section shouldn't affect any Table if any of the elements are out of bounds. We need to process it in two passes. Segment section shouldn't affect any Data if any of the segments are out of bounds. We need to process it in two passes. Empty data segments are valid, but only when there is no memory. Their index still gets validated, and has to be zero. Punts: Error messages with context, the test seems overly restrictive but this is minor. compile/instantiate/validate property descriptors. UTF-8 bugs. Temporarily disable NaN tests. We need to go back and implement the following semantics: https://github.com/WebAssembly/spec/pull/414 This doesn't matter as much as getting all the other tests passing. Worth noting for NaNs: f64.no_fold_mul_one (also a NaN test) as well as no_fold_promote_demote (an interesting corner case which we get wrong). mul by one is (assert_return (invoke \"f64.no_fold_mul_one\" (i64.const 0x7ff4000000000000)) (i64.const 0x7ff8000000000000)) which means converting sNaN to qNaN, and promote/demote is (assert_return (invoke \"no_fold_promote_demote\" (i32.const 0x7fa00000)) (i32.const 0x7fc00000)) which is the same. I'm not sure why they're not allowed. * wasm/WasmB3IRGenerator.cpp: * wasm/WasmFunctionParser.h: * wasm/WasmModuleParser.cpp: * wasm/WasmModuleParser.h: * wasm/WasmParser.h: (JSC::Wasm::Parser::consumeUTF8String): * wasm/generateWasm.py: (memoryLog2Alignment): * wasm/js/JSWebAssemblyTable.cpp: (JSC::JSWebAssemblyTable::grow): * wasm/js/JSWebAssemblyTable.h: * wasm/js/WebAssemblyCompileErrorPrototype.cpp: * wasm/js/WebAssemblyInstancePrototype.cpp: * wasm/js/WebAssemblyLinkErrorPrototype.cpp: * wasm/js/WebAssemblyMemoryPrototype.cpp: * wasm/js/WebAssemblyModulePrototype.cpp: * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::evaluate): * wasm/js/WebAssemblyPrototype.cpp: (JSC::webAssemblyCompileFunc): (JSC::resolve): (JSC::instantiate): (JSC::compileAndInstantiate): (JSC::webAssemblyInstantiateFunc): * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp: * wasm/js/WebAssemblyTablePrototype.cpp: (JSC::webAssemblyTableProtoFuncGrow): 2017-06-13 Michael Saboff DFG doesn't properly handle a property that is change to read only in a prototype https://bugs.webkit.org/show_bug.cgi?id=173321 Reviewed by Filip Pizlo. We need to check for ReadOnly as well as a not being a Setter when checking an AbsenceOfSetter. * bytecode/PropertyCondition.cpp: (JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint): 2017-06-13 Daniel Bates Implement W3C Secure Contexts Draft Specification https://bugs.webkit.org/show_bug.cgi?id=158121 Reviewed by Brent Fulgham. Part 4 Adds isSecureContext to the list of common identifiers as needed to support toggling its exposure from a runtime enabled feature flag. * runtime/CommonIdentifiers.h: 2017-06-13 Don Olmstead [JSC] Remove redundant includes in config.h https://bugs.webkit.org/show_bug.cgi?id=173294 Reviewed by Alex Christensen. * config.h: 2017-06-12 Saam Barati We should not claim that SpecEmpty is filtered out of cell checks on 64 bit platforms https://bugs.webkit.org/show_bug.cgi?id=172957 Reviewed by Filip Pizlo. Consider this program: ``` block#1: n: GetClosureVar(..., |this|) // this will load empty JSValue() SetLocal(Cell:@n, locFoo) // Cell check succeeds because JSValue() looks like a cell Branch(#2, #3) Block#3: x: GetLocal(locFoo) y: CheckNotEmpty(@x) ``` If we claim that a cell check filters out the empty value, we will incorrectly eliminate the CheckNotEmpty node @y. This patch fixes AI, FTLLowerDFGToB3, and DFGSpeculativeJIT to no longer make this claim. On 64 bit platforms: - Cell use kind *now allows* the empty value to pass through. - CellOrOther use kind *now allows* for the empty value to pass through - NotCell use kind *no longer allows* the empty value to pass through. * assembler/CPU.h: (JSC::isARMv7IDIVSupported): (JSC::isARM64): (JSC::isX86): (JSC::isX86_64): (JSC::is64Bit): (JSC::is32Bit): (JSC::isMIPS): Make these functions constexpr so we can use them in static variable assignment. * bytecode/SpeculatedType.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileValueToInt32): (JSC::DFG::SpeculativeJIT::compileDoubleRep): (JSC::DFG::SpeculativeJIT::compileLogicalNotStringOrOther): (JSC::DFG::SpeculativeJIT::emitStringOrOtherBranch): (JSC::DFG::SpeculativeJIT::speculateCell): (JSC::DFG::SpeculativeJIT::speculateCellOrOther): (JSC::DFG::SpeculativeJIT::speculateObjectOrOther): (JSC::DFG::SpeculativeJIT::speculateString): (JSC::DFG::SpeculativeJIT::speculateStringOrOther): (JSC::DFG::SpeculativeJIT::speculateSymbol): (JSC::DFG::SpeculativeJIT::speculateNotCell): * dfg/DFGSpeculativeJIT32_64.cpp: * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::fillSpeculateCell): (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot): (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch): * dfg/DFGUseKind.h: (JSC::DFG::typeFilterFor): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileDoubleRep): (JSC::FTL::DFG::LowerDFGToB3::numberOrNotCellToInt32): (JSC::FTL::DFG::LowerDFGToB3::compareEqObjectOrOtherToObject): (JSC::FTL::DFG::LowerDFGToB3::boolify): (JSC::FTL::DFG::LowerDFGToB3::equalNullOrUndefined): (JSC::FTL::DFG::LowerDFGToB3::lowCell): (JSC::FTL::DFG::LowerDFGToB3::lowNotCell): (JSC::FTL::DFG::LowerDFGToB3::isCellOrMisc): (JSC::FTL::DFG::LowerDFGToB3::isNotCellOrMisc): (JSC::FTL::DFG::LowerDFGToB3::isNotCell): (JSC::FTL::DFG::LowerDFGToB3::isCell): (JSC::FTL::DFG::LowerDFGToB3::speculateCellOrOther): (JSC::FTL::DFG::LowerDFGToB3::speculateObjectOrOther): (JSC::FTL::DFG::LowerDFGToB3::speculateString): (JSC::FTL::DFG::LowerDFGToB3::speculateStringOrOther): (JSC::FTL::DFG::LowerDFGToB3::speculateSymbol): 2017-06-12 Yusuke Suzuki Unreviewed, suppress invalid register alloation validation assertion in 32 bit https://bugs.webkit.org/show_bug.cgi?id=172421 * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArrayIndexOf): 2017-06-12 Oleksandr Skachkov We incorrectly allow escaped characters in keyword tokens https://bugs.webkit.org/show_bug.cgi?id=171310 Reviewed by Yusuke Suzuki. According spec it is not allow to use escaped characters in keywords. https://tc39.github.io/ecma262/#sec-reserved-words Current patch implements this requirements. * parser/Lexer.cpp: (JSC::Lexer::parseIdentifierSlowCase): * parser/Parser.cpp: (JSC::Parser::printUnexpectedTokenText): * parser/ParserTokens.h: 2017-06-12 Yusuke Suzuki Unreviewed, add branch64(Cond, BaseIndex, RegisterID) for ARM64 https://bugs.webkit.org/show_bug.cgi?id=172421 * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::branch64): (JSC::MacroAssemblerARM64::branchPtr): 2017-06-12 Commit Queue Unreviewed, rolling out r218093. https://bugs.webkit.org/show_bug.cgi?id=173259 Break builds (Requested by yusukesuzuki on #webkit). Reverted changeset: "Unreviewed, build fix for ARM64" https://bugs.webkit.org/show_bug.cgi?id=172421 http://trac.webkit.org/changeset/218093 2017-06-12 Yusuke Suzuki Unreviewed, build fix for ARM64 https://bugs.webkit.org/show_bug.cgi?id=172421 * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArrayIndexOf): 2017-06-09 Yusuke Suzuki [DFG] Add ArrayIndexOf intrinsic https://bugs.webkit.org/show_bug.cgi?id=172421 Reviewed by Saam Barati. This patch introduces ArrayIndexOfInstrinsic for DFG and FTL optimizations. We emit array check and go fast path if the array is Array::Int32, Array::Double or Array::Continugous. In addition, for Array::Int32 and Array::Double case, we have inlined fast paths. With updated ARES-6 Babylon, Before firstIteration: 45.76 +- 3.87 ms averageWorstCase: 24.41 +- 2.17 ms steadyState: 8.01 +- 0.22 ms After firstIteration: 45.64 +- 4.23 ms averageWorstCase: 23.03 +- 3.34 ms steadyState: 7.33 +- 0.34 ms In SixSpeed. baseline patched map-set-lookup.es5 734.4701+-10.4383 ^ 102.0968+-2.6357 ^ definitely 7.1939x faster map-set.es5 41.1396+-1.0558 ^ 33.1916+-0.7986 ^ definitely 1.2395x faster map-set-object.es5 62.8317+-1.2518 ^ 45.6944+-0.8369 ^ definitely 1.3750x 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/DFGNode.h: (JSC::DFG::Node::hasArrayMode): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArrayIndexOf): (JSC::DFG::SpeculativeJIT::speculateObject): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): (JSC::DFG::SpeculativeJIT::speculateInt32): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileArrayIndexOf): * jit/JITOperations.h: * runtime/ArrayPrototype.cpp: (JSC::ArrayPrototype::finishCreation): * runtime/Intrinsic.cpp: (JSC::intrinsicName): * runtime/Intrinsic.h: 2017-06-11 Keith Miller TypedArray constructor with string shouldn't throw https://bugs.webkit.org/show_bug.cgi?id=173181 Reviewed by JF Bastien. We should be coercing primitive arguments to numbers in the various TypedArray constructors. * runtime/JSGenericTypedArrayViewConstructorInlines.h: (JSC::constructGenericTypedArrayViewWithArguments): 2017-06-11 Yusuke Suzuki [WTF] Make ThreadMessage portable https://bugs.webkit.org/show_bug.cgi?id=172073 Reviewed by Keith Miller. * runtime/MachineContext.h: (JSC::MachineContext::stackPointer): * tools/CodeProfiling.cpp: (JSC::profilingTimer): 2017-06-11 Yusuke Suzuki [JSC] Shrink Structure size https://bugs.webkit.org/show_bug.cgi?id=173239 Reviewed by Mark Lam. We find that the size of our Structure is slightly enlarged due to paddings. By changing the order of members, we can reduce the size from 120 to 112. This is good because 120 and 112 are categorized into different size classes. For 120, we allocate 128 bytes. And for 112, we allocate 112 bytes. We now save 16 bytes per Structure for free. * runtime/ConcurrentJSLock.h: * runtime/Structure.cpp: (JSC::Structure::Structure): * runtime/Structure.h: 2017-06-11 Konstantin Tokarev Unreviewed, attempt to fix JSC tests on Win after r217771 * jsc.cpp: (currentWorkingDirectory): buffer is not NULL-terminated 2017-06-10 Yusuke Suzuki [WTF] Add RegisteredSymbolImpl https://bugs.webkit.org/show_bug.cgi?id=173230 Reviewed by Mark Lam. * runtime/SymbolConstructor.cpp: (JSC::symbolConstructorKeyFor): 2017-06-10 Dan Bernstein Reverted r218056 because it made the IDE reindex constantly. * Configurations/DebugRelease.xcconfig: 2017-06-10 Dan Bernstein [Xcode] With Xcode 9 developer beta, everything rebuilds when switching between command-line and IDE https://bugs.webkit.org/show_bug.cgi?id=173223 Reviewed by Sam Weinig. The rebuilds were happening due to a difference in the compiler options that the IDE and xcodebuild were specifying. Only the IDE was passing the -index-store-path option. To make xcodebuild pass that option, too, set CLANG_INDEX_STORE_ENABLE to YES if it is unset, and specify an appropriate path in CLANG_INDEX_STORE_PATH. * Configurations/DebugRelease.xcconfig: 2017-06-10 Yusuke Suzuki [JSC] Update RegExp.prototype.[@@search]] implementation according to the latest spec https://bugs.webkit.org/show_bug.cgi?id=173227 Reviewed by Mark Lam. The latest spec introduces slight change to RegExp.prototype.[@@search]. This patch applies this change. Basically, this change is done in the slow path of the RegExp.prototype[@@search]. https://tc39.github.io/ecma262/#sec-regexp.prototype-@@search * builtins/RegExpPrototype.js: (search): 2017-06-09 Chris Dumez Update Thread::create() to take in a WTF::Function instead of a std::function https://bugs.webkit.org/show_bug.cgi?id=173175 Reviewed by Mark Lam. * API/tests/CompareAndSwapTest.cpp: (testCompareAndSwap): 2017-06-09 Yusuke Suzuki [DFG] Add verboseDFGOSRExit https://bugs.webkit.org/show_bug.cgi?id=173156 Reviewed by Saam Barati. This patch adds verboseDFGOSRExit which is similar to verboseFTLOSRExit. * dfg/DFGOSRExitCompiler.cpp: * runtime/Options.h: 2017-06-09 Guillaume Emont [JSC][MIPS] Add MacroAssemblerMIPS::xor32(Address, RegisterID) implementation https://bugs.webkit.org/show_bug.cgi?id=173170 Reviewed by Yusuke Suzuki. MIPS does not build since r217711 because it is missing this implementation. This patch fixes the build. * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::xor32): 2017-06-09 Yusuke Suzuki [JSC] FTL does not require dlfcn https://bugs.webkit.org/show_bug.cgi?id=173143 Reviewed by Darin Adler. We no longer use LLVM library. Thus, dlfcn.h is not necessary. Also, ProcessID is not used in FTLLowerDFGToB3.cpp. * ftl/FTLLowerDFGToB3.cpp: 2017-06-09 Yusuke Suzuki [DFG] Add --verboseDFGFailure https://bugs.webkit.org/show_bug.cgi?id=173155 Reviewed by Sam Weinig. Similar to verboseFTLFailure, JSC should have verboseDFGFailure flag to show DFG failures quickly. * dfg/DFGCapabilities.cpp: (JSC::DFG::verboseCapabilities): (JSC::DFG::debugFail): * runtime/Options.cpp: (JSC::recomputeDependentOptions): * runtime/Options.h: 2017-06-09 Yusuke Suzuki [JSC] Drop OS(DARWIN) for VM_TAG_FOR_WEBASSEMBLY_MEMORY https://bugs.webkit.org/show_bug.cgi?id=173147 Reviewed by JF Bastien. Because this value becomes -1 in non-Darwin environments. Thus, we do not need to use OS(DARWIN) here. * wasm/WasmMemory.cpp: 2017-06-09 Daewoong Jang Reduce compiler warnings https://bugs.webkit.org/show_bug.cgi?id=172078 Reviewed by Yusuke Suzuki. * runtime/IntlDateTimeFormat.h: 2017-06-08 Joseph Pecoraro [Cocoa] JSWrapperMap leaks for all JSContexts https://bugs.webkit.org/show_bug.cgi?id=173110 Reviewed by Geoffrey Garen. * API/JSContext.mm: (-[JSContext ensureWrapperMap]): Ensure this allocation gets released. 2017-06-08 Filip Pizlo REGRESSION: js/dom/prototype-chain-caching-with-impure-get-own-property-slot-traps-5.html has a flaky failure https://bugs.webkit.org/show_bug.cgi?id=161156 Reviewed by Saam Barati. Since LLInt does not register impure property watchpoints for self property accesses, it shouldn't try to cache accesses that require a watchpoint. This manifested as a flaky failure because the test would fire the watchpoint after we had usually already tiered up. Without concurrent JIT, we would have always tiered up before getting to the bad case. With concurrent JIT, we would sometimes not tier up by that time. This also adds a test that deterministically failed in LLInt without this change; it does so by just running a lot shorter. * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): 2017-06-08 Keith Miller WebAssembly: We should only create wrappers for functions that can be exported https://bugs.webkit.org/show_bug.cgi?id=173088 Reviewed by Saam Barati. This patch makes it so we only create wrappers for WebAssembly functions that can actually be exported. It appears to be a ~2.5% speedup on WasmBench compile times. This patch also removes most of the old testWasmModuleFunctions api from the jsc CLI. Most of the tests were duplicates of ones in the spec-tests directory. The others I have converted to use the normal API. * jsc.cpp: (GlobalObject::finishCreation): (valueWithTypeOfWasmValue): Deleted. (box): Deleted. (callWasmFunction): Deleted. (functionTestWasmModuleFunctions): Deleted. * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::createJSToWasmWrapper): (JSC::Wasm::parseAndCompile): * wasm/WasmB3IRGenerator.h: * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::prepare): (JSC::Wasm::BBQPlan::compileFunctions): (JSC::Wasm::BBQPlan::complete): * wasm/WasmBBQPlan.h: * wasm/WasmBBQPlanInlines.h: (JSC::Wasm::BBQPlan::initializeCallees): * wasm/WasmCodeBlock.cpp: (JSC::Wasm::CodeBlock::CodeBlock): * wasm/WasmCodeBlock.h: (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace): * wasm/WasmFormat.h: * wasm/WasmOMGPlan.cpp: (JSC::Wasm::OMGPlan::work): 2017-06-07 JF Bastien WebAssembly: test imports and exports with 16-bit characters https://bugs.webkit.org/show_bug.cgi?id=165977 Reviewed by Saam Barati. Add the missing UTF-8 conversions. Improve import failure error messages, otherwise it's hard to figure out which import is wrong. * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::create): * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::finishCreation): (JSC::WebAssemblyModuleRecord::link): 2017-06-07 Devin Rousso Web Inspector: Add ContextMenu item to log WebSocket object to console https://bugs.webkit.org/show_bug.cgi?id=172878 Reviewed by Joseph Pecoraro. * inspector/protocol/Network.json: Add resolveWebSocket command. 2017-06-07 Jon Davis Update feature status for features Supported In Preview https://bugs.webkit.org/show_bug.cgi?id=173071 Reviewed by Darin Adler. Updated Media Capture and Streams, Performance Observer, Resource Timing Level 2, User Timing Level 2, Web Cryptography API, WebGL 2, WebRTC. * features.json: 2017-06-07 Saam Barati Assertion failure in com.apple.WebKit.WebContent.Development in com.apple.JavaScriptCore: JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNullOrUndefined + 141 https://bugs.webkit.org/show_bug.cgi?id=172673 Reviewed by Mark Lam. This patch simply removes this assertion. It's faulty because it races with the main thread when doing concurrent compilation. Consider a program with: - a FrozenValue over an object O and Structure S1. S1 starts off as dfgWatchable() being true. - Structure S2 The DFG IR is like so: a: JSConstant(O) // FrozenValue {O, S1} b: CheckStructure(@a, S2) c: ToThis(@a) d: CheckEq(@c, nullConstant) Branch(@d) The AbstractValue for @a will start off as having a finite structure because S1 is dfgWatchable(). When running AI, we'll notice that node @b will OSR exit, so nodes after @b are unreachable. Later in the compilation, S1 is no longer dfgWatchable(). Now, when running AI, @a will have Top for its structure set. No longer will we think @b exits. The DFG backend asserts that under such a situation, we should have simplified the CheckEq to false. However, this is a racy thing to assert, since the transition from dfgWatchable() to !dfgWatchable() can happen right before we enter the backend. Hence, this assertion is not valid. (Note, the generated code for the above program will never actually execute. Since we noticed S1 as dfgWatchable(), we make the compilation dependent on S1 not transitioning. S1 transitions, so we won't actually run the code that gets compiled.) * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNullOrUndefined): 2017-06-07 Yusuke Suzuki [JSC] has_generic_property never accepts non-String https://bugs.webkit.org/show_bug.cgi?id=173057 Reviewed by Darin Adler. We never pass non-String value to has_generic_property bytecode. * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): 2017-06-06 Fujii Hironori [Win][x86-64] Some callee saved registers aren't preserved https://bugs.webkit.org/show_bug.cgi?id=171266 Reviewed by Saam Barati. * jit/RegisterSet.cpp: (JSC::RegisterSet::calleeSaveRegisters): Added edi and esi for X86_64 Windows. 2017-06-06 Mark Lam Contiguous storage butterfly length should not exceed MAX_STORAGE_VECTOR_LENGTH. https://bugs.webkit.org/show_bug.cgi?id=173035 Reviewed by Geoffrey Garen and Filip Pizlo. Also added and fixed up some assertions. * runtime/ArrayConventions.h: * runtime/JSArray.cpp: (JSC::JSArray::setLength): * runtime/JSObject.cpp: (JSC::JSObject::createInitialIndexedStorage): (JSC::JSObject::ensureLengthSlow): (JSC::JSObject::reallocateAndShrinkButterfly): * runtime/JSObject.h: (JSC::JSObject::ensureLength): * runtime/RegExpObject.cpp: (JSC::collectMatches): * runtime/RegExpPrototype.cpp: (JSC::regExpProtoFuncSplitFast): 2017-06-06 Saam Barati Make sure we restore SP when doing calls that could be to JS https://bugs.webkit.org/show_bug.cgi?id=172946 Reviewed by JF Bastien. I was worried that there was a bug where we'd call JS, JS would tail call, and we'd end up with a bogus SP. However, this bug does not exist since wasm always calls to JS through a stub, and the stub treats SP as a callee save. I wrote a test for this, and also made a note that this is the needed ABI. * wasm/WasmBinding.cpp: (JSC::Wasm::wasmToJs): 2017-06-06 Keith Miller OMG tier up checks should be a patchpoint https://bugs.webkit.org/show_bug.cgi?id=172944 Reviewed by Saam Barati. Tier up checks in BBQ should be done as a patchpoint rather than individual B3 opcodes. In order to reduce code generated out of line in each function. We generate a single stub that pushes all the callee-saves. This looks like a 5-10% compile time speedup. * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::B3IRGenerator::emitTierUpCheck): (JSC::Wasm::B3IRGenerator::addLoop): * wasm/WasmThunks.cpp: (JSC::Wasm::triggerOMGTierUpThunkGenerator): * wasm/WasmThunks.h: 2017-06-06 Darin Adler Cut down use of WTF_ARRAY_LENGTH https://bugs.webkit.org/show_bug.cgi?id=172997 Reviewed by Chris Dumez. * parser/Lexer.cpp: (JSC::singleEscape): Use WTF_ARRAY_LENGTH instead of ARRAY_SIZE. * runtime/NumberPrototype.cpp: (JSC::toStringWithRadix): Use std::end instead of WTF_ARRAY_LENGTH. 2017-06-06 Konstantin Tokarev Add missing includes https://bugs.webkit.org/show_bug.cgi?id=173017 Patch by Thiago Macieira Reviewed by Yusuke Suzuki. This patch fixes compilation with GCC 7. * inspector/InspectorBackendDispatcher.h: 2017-06-06 Filip Pizlo Unreviewed, fix 32-bit build. * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_unreachable): 2017-06-06 Joseph Pecoraro Unreviewed rollout r217807. Caused a test to crash. * heap/HeapSnapshotBuilder.cpp: (JSC::HeapSnapshotBuilder::buildSnapshot): (JSC::HeapSnapshotBuilder::json): (): Deleted. * heap/HeapSnapshotBuilder.h: * runtime/JSObject.cpp: (JSC::JSObject::calculatedClassName): 2017-06-06 Filip Pizlo index out of bound in bytecodebasicblock https://bugs.webkit.org/show_bug.cgi?id=172963 Reviewed by Saam Barati and Mark Lam. We were leaving an unterminated basic block when generating CodeForCall for a class constructor. This was mostly benign since that unterminated block was not reachable, but it does cause an ASSERT. This fixes the issue by appending op_unreachable to that block. I added op_unreachable because this really is the cleanest and most idiomatic way to solve this problem, so even though it makes the change bigger it's probabably worth it. * bytecode/BytecodeDumper.cpp: (JSC::BytecodeDumper::dumpBytecode): * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/Opcode.h: (JSC::isTerminal): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::generate): (JSC::BytecodeGenerator::emitUnreachable): * bytecompiler/BytecodeGenerator.h: * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileUnreachable): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JIT.h: * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_unreachable): * llint/LowLevelInterpreter.asm: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: 2017-06-06 Ryan Haddad Unreviewed, rolling out r217812. This change caused test failures on arm64. Reverted changeset: "OMG tier up checks should be a patchpoint" https://bugs.webkit.org/show_bug.cgi?id=172944 http://trac.webkit.org/changeset/217812 2017-06-06 Carlos Garcia Campos [WPE] Enable remote inspector https://bugs.webkit.org/show_bug.cgi?id=172971 Reviewed by Žan Doberšek. We can just build the current glib remote inspector, without adding a frontend implementation and using a WebKitGTK+ browser as frontend for now. * PlatformWPE.cmake: Add remote inspector files to compilation. * inspector/remote/glib/RemoteInspectorUtils.cpp: (Inspector::backendCommands): Load the inspector resources library. 2017-06-06 Carlos Garcia Campos [GLIB] Make remote inspector DBus protocol common to all glib based ports https://bugs.webkit.org/show_bug.cgi?id=172970 Reviewed by Žan Doberšek. We are currently using "webkitgtk" in the names of DBus interfaces and object paths inside an ifdef with the idea that other ports could use their own names. However, the protocol is the same, so we could use the same names and make all glib based ports compatible to each other. This way we could use the GTK+ MiniBrowser to debug WPE, without having to implement the frontend part in WPE yet. * inspector/remote/glib/RemoteInspectorGlib.cpp: Use webkit instead of webkitgtk and reomve platform idfeds. * inspector/remote/glib/RemoteInspectorServer.cpp: Ditto. 2017-06-06 Carlos Garcia Campos [GTK] Web Process deadlock when closing the remote inspector frontend https://bugs.webkit.org/show_bug.cgi?id=172973 Reviewed by Žan Doberšek. We are taking the remote inspector mutex twice. First close message is received, and receivedCloseMessage() takes the mutex. Then RemoteConnectionToTarget::close() is called that, when connected, calls PageDebuggable::disconnect() that ends up calling RemoteInspector::updateTarget() that also takes the remote inspector mutex. We should release the mutex before calling RemoteConnectionToTarget::close(). * inspector/remote/glib/RemoteInspectorGlib.cpp: (Inspector::RemoteInspector::receivedCloseMessage): 2017-06-05 Saam Barati Try to fix features.json by adding an ESNext section. Unreviewed. * features.json: 2017-06-05 David Kilzer Follow-up: Update JSC's features.json https://bugs.webkit.org/show_bug.cgi?id=172942 Rubber-stamped by Jon Davis. * features.json: Change "Supported in preview" to "Supported" to try to fix . 2017-06-05 Saam Barati We don't properly parse init_expr when the opcode is an unexpected opcode https://bugs.webkit.org/show_bug.cgi?id=172945 Reviewed by JF Bastien. The bug is a simple typo. It should use the constant `true` instead of `false` when invoking the WASM_PARSER_FAIL_IF macro. This failure is already caught by spec tests that fail on arm64 devices. * wasm/WasmModuleParser.cpp: 2017-06-05 Keith Miller OMG tier up checks should be a patchpoint https://bugs.webkit.org/show_bug.cgi?id=172944 Reviewed by Saam Barati. Tier up checks in BBQ should be done as a patchpoint rather than individual B3 opcodes. In order to reduce code generated out of line in each function. We generate a single stub that pushes all the callee-saves. This looks like a 5-10% compile time speedup. * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::B3IRGenerator::emitTierUpCheck): (JSC::Wasm::B3IRGenerator::addLoop): * wasm/WasmThunks.cpp: (JSC::Wasm::triggerOMGTierUpThunkGenerator): * wasm/WasmThunks.h: 2017-06-05 Joseph Pecoraro Remove unused VM members https://bugs.webkit.org/show_bug.cgi?id=172941 Reviewed by Mark Lam. * runtime/HashMapImpl.h: (JSC::HashMapImpl::selectStructure): Deleted. * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2017-06-05 Joseph Pecoraro Web Inspector: Improve ES6 Class instances in Heap Snapshot instances view https://bugs.webkit.org/show_bug.cgi?id=172848 Reviewed by Saam Barati. * heap/HeapSnapshotBuilder.h: * heap/HeapSnapshotBuilder.cpp: Update the snapshot version. Change the node's 0 | 1 internal value to be a 32bit bit flag. This is nice in that it is both compatible with the previous snapshot version and the same size. We can use more flags in the future. (JSC::HeapSnapshotBuilder::json): In cases where the classInfo gives us "Object" check for a better class name by checking (o).__proto__.constructor.name. We avoid this check in cases where (o).hasOwnProperty("constructor") which is the case for most Foo.prototype objects. Otherwise this would get the name of the Foo superclass for the Foo.prototype object. * runtime/JSObject.cpp: (JSC::JSObject::calculatedClassName): Handle some possible edge cases that were not handled before. Such as a JSObject without a GlobalObject, and an object which doesn't have a default getPrototype. Try to make the code a little clearer. 2017-06-05 Saam Barati Update JSC's features.json https://bugs.webkit.org/show_bug.cgi?id=172942 Rubber stamped by Mark Lam. * features.json: 2017-06-04 Konstantin Tokarev Fix build of Windows-specific code with ICU 59.1 https://bugs.webkit.org/show_bug.cgi?id=172729 Reviewed by Darin Adler. Fix conversions from WTF::String to wchar_t* and vice versa. * jsc.cpp: (currentWorkingDirectory): (fetchModuleFromLocalFileSystem): * runtime/DateConversion.cpp: (JSC::formatDateTime): 2017-06-04 Yusuke Suzuki [JSC] Drop unnecessary USE(CF) guard for getenv https://bugs.webkit.org/show_bug.cgi?id=172903 Reviewed by Sam Weinig. getenv is not related to USE(CF) and OS(UNIX). It seems that this ifdef only hits in WinCairo, but WinCairo can use getenv. Moreover, in VM::VM, we already use getenv without any ifdef guard. This patch just drops it. * runtime/VM.cpp: (JSC::enableAssembler): 2017-06-04 Yusuke Suzuki [JSC] Drop OS(DARWIN) for uintptr_t type conflict https://bugs.webkit.org/show_bug.cgi?id=172904 Reviewed by Sam Weinig. In non-Darwin environment, uintptr_t may have the same type to uint64_t. We avoided the compile error by using OS(DARWIN). But, since it depends on cstdint implementaion rather than OS, it is flaky. Instead, we just use template parameter IntegralType. And we describe the type constraint in a SFINAE manner. * dfg/DFGOpInfo.h: (JSC::DFG::OpInfo::OpInfo): 2017-06-03 Csaba Osztrogonác [ARM] Unreviewed buildfix after r217711. * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::xor32): 2017-06-02 Yusuke Suzuki ASSERTION FAILED: "We should only declare a function as a lexically scoped variable in scopes where var declarations aren't allowed. ..." for function redeclaration with async function module export https://bugs.webkit.org/show_bug.cgi?id=168844 Reviewed by Saam Barati. As the same to the exported function declaration, we should set statementDepth = 1 for exported async function declaration. * parser/Parser.cpp: (JSC::DepthManager::DepthManager): (JSC::Parser::parseExportDeclaration): * parser/Parser.h: (JSC::Parser::DepthManager::DepthManager): Deleted. (JSC::Parser::DepthManager::~DepthManager): Deleted. 2017-06-02 Keith Miller Defer installing mach breakpoint handler until watchdog is actually called https://bugs.webkit.org/show_bug.cgi?id=172885 Reviewed by Saam Barati. Eagerly installing the mach breakpoint handler causes issues with Xcode GUI debugging. This hides the issue, so it won't occur as often. * runtime/VMTraps.cpp: (JSC::VMTraps::SignalSender::send): (JSC::VMTraps::VMTraps): Deleted. * runtime/VMTraps.h: 2017-06-02 Filip Pizlo Atomics.load and Atomics.store need to be fully fenced https://bugs.webkit.org/show_bug.cgi?id=172844 Reviewed by Keith Miller. Implement fully fenced loads and stores in FTL using AtomicXchgAdd(0, ptr) for the load and AtomicXchg(value, ptr) for the store. DFG needed no changes because it implements all atomics using a CAS loop. AtomicsObject.cpp now uses new Atomic<> API for fully fences loads and stores. Prior to this change, we used half fences (acquire/release) for atomic loads and stores. This is not correct according to my current understanding of the SAB memory model, which requires that atomic operations are SC with respect to everything not just other atomics. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileAtomicsReadModifyWrite): * ftl/FTLOutput.cpp: (JSC::FTL::Output::atomicWeakCAS): * ftl/FTLOutput.h: * runtime/AtomicsObject.cpp: 2017-06-02 Ryan Haddad Unreviewed, attempt to fix the iOS build after r217711. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::xor32): (JSC::MacroAssemblerARM64::xor64): 2017-06-01 Filip Pizlo GC should use scrambled free-lists https://bugs.webkit.org/show_bug.cgi?id=172793 Reviewed by Mark Lam. Previously, our bump'n'pop allocator would use a conventional linked-list for the free-list. The linked-list would be threaded through free memory, as is the usual convention. This scrambles the next pointers of that free-list. It also scrambles the head pointer, because this leads to a more natural fast-path structure and saves one register on ARM64. The secret with which pointers are scrambled is per-allocator. Allocators choose a new secret every time they do a sweep-to-pop. This doesn't change the behavior of the bump part of bump'n'pop, but it does refactor the code quite a bit. Previously, there were four copies of the allocator fast path: two in MarkedAllocatorInlines.h, one in MarkedAllocator.cpp, and one in AssemblyHelpers.h. The JIT one was obviously different-looking, but the other three were almost identical. This moves all of that logic into FreeList. There are now just two copies of the allocator: FreeListInlines.h and AssemblyHelpers.h. This appears to be just as fast as our previously allocator. * JavaScriptCore.xcodeproj/project.pbxproj: * heap/FreeList.cpp: (JSC::FreeList::FreeList): (JSC::FreeList::~FreeList): (JSC::FreeList::clear): (JSC::FreeList::initializeList): (JSC::FreeList::initializeBump): (JSC::FreeList::contains): (JSC::FreeList::dump): * heap/FreeList.h: (JSC::FreeList::allocationWillFail): (JSC::FreeList::originalSize): (JSC::FreeList::addressOfList): (JSC::FreeList::offsetOfBlock): (JSC::FreeList::offsetOfList): (JSC::FreeList::offsetOfIndex): (JSC::FreeList::offsetOfPayloadEnd): (JSC::FreeList::offsetOfRemaining): (JSC::FreeList::offsetOfOriginalSize): (JSC::FreeList::FreeList): Deleted. (JSC::FreeList::list): Deleted. (JSC::FreeList::bump): Deleted. (JSC::FreeList::operator==): Deleted. (JSC::FreeList::operator!=): Deleted. (JSC::FreeList::operator bool): Deleted. * heap/FreeListInlines.h: Added. (JSC::FreeList::addFreeCell): (JSC::FreeList::allocate): (JSC::FreeList::forEach): (JSC::FreeList::toOffset): (JSC::FreeList::fromOffset): * heap/IncrementalSweeper.cpp: (JSC::IncrementalSweeper::sweepNextBlock): * heap/MarkedAllocator.cpp: (JSC::MarkedAllocator::MarkedAllocator): (JSC::MarkedAllocator::didConsumeFreeList): (JSC::MarkedAllocator::tryAllocateWithoutCollecting): (JSC::MarkedAllocator::tryAllocateIn): (JSC::MarkedAllocator::allocateSlowCaseImpl): (JSC::MarkedAllocator::stopAllocating): (JSC::MarkedAllocator::prepareForAllocation): (JSC::MarkedAllocator::resumeAllocating): (JSC::MarkedAllocator::sweep): (JSC::MarkedAllocator::setFreeList): Deleted. * heap/MarkedAllocator.h: (JSC::MarkedAllocator::freeList): (JSC::MarkedAllocator::isFreeListedCell): Deleted. * heap/MarkedAllocatorInlines.h: (JSC::MarkedAllocator::isFreeListedCell): (JSC::MarkedAllocator::tryAllocate): (JSC::MarkedAllocator::allocate): * heap/MarkedBlock.cpp: (JSC::MarkedBlock::Handle::stopAllocating): (JSC::MarkedBlock::Handle::lastChanceToFinalize): (JSC::MarkedBlock::Handle::resumeAllocating): (JSC::MarkedBlock::Handle::zap): (JSC::MarkedBlock::Handle::sweep): (JSC::MarkedBlock::Handle::isFreeListedCell): (JSC::MarkedBlock::Handle::forEachFreeCell): Deleted. * heap/MarkedBlock.h: * heap/MarkedBlockInlines.h: (JSC::MarkedBlock::Handle::specializedSweep): (JSC::MarkedBlock::Handle::finishSweepKnowingSubspace): (JSC::MarkedBlock::Handle::isFreeListedCell): Deleted. * heap/Subspace.cpp: (JSC::Subspace::finishSweep): * heap/Subspace.h: * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator): * runtime/JSDestructibleObjectSubspace.cpp: (JSC::JSDestructibleObjectSubspace::finishSweep): * runtime/JSDestructibleObjectSubspace.h: * runtime/JSSegmentedVariableObjectSubspace.cpp: (JSC::JSSegmentedVariableObjectSubspace::finishSweep): * runtime/JSSegmentedVariableObjectSubspace.h: * runtime/JSStringSubspace.cpp: (JSC::JSStringSubspace::finishSweep): * runtime/JSStringSubspace.h: * wasm/js/JSWebAssemblyCodeBlockSubspace.cpp: (JSC::JSWebAssemblyCodeBlockSubspace::finishSweep): * wasm/js/JSWebAssemblyCodeBlockSubspace.h: 2017-06-02 Yusuke Suzuki [JSC] Use @globalPrivate for concatSlowPath https://bugs.webkit.org/show_bug.cgi?id=172802 Reviewed by Darin Adler. Use @globalPrivate instead of manually putting it to JSGlobalObject. * builtins/ArrayPrototype.js: (concatSlowPath): Deleted. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): 2017-06-01 Andy Estes REGRESSION (r217626): ENABLE_APPLE_PAY_SESSION_V3 was disabled by mistake https://bugs.webkit.org/show_bug.cgi?id=172828 Reviewed by Beth Dakin. * Configurations/FeatureDefines.xcconfig: 2017-06-01 Keith Miller Undo rollout in r217638 with bug fix https://bugs.webkit.org/show_bug.cgi?id=172824 Unreviewed, reland patch with unused set_state code removed. * API/tests/ExecutionTimeLimitTest.cpp: (dispatchTermitateCallback): (testExecutionTimeLimit): * runtime/JSLock.cpp: (JSC::JSLock::didAcquireLock): * runtime/Options.cpp: (JSC::overrideDefaults): (JSC::Options::initialize): * runtime/Options.h: * runtime/VMTraps.cpp: (JSC::SignalContext::SignalContext): (JSC::SignalContext::adjustPCToPointToTrappingInstruction): (JSC::installSignalHandler): (JSC::VMTraps::SignalSender::send): * tools/SigillCrashAnalyzer.cpp: (JSC::SignalContext::SignalContext): (JSC::SignalContext::dump): (JSC::installCrashHandler): * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::compileFunctions): * wasm/WasmFaultSignalHandler.cpp: (JSC::Wasm::trapHandler): (JSC::Wasm::enableFastMemory): * wasm/WasmMachineThreads.cpp: (JSC::Wasm::resetInstructionCacheOnAllThreads): 2017-06-01 Guillaume Emont [JSC][MIPS] SamplingProfiler::timerLoop() sleeps for 4000+ seconds https://bugs.webkit.org/show_bug.cgi?id=172800 Reviewed by Saam Barati. This fixes a static_cast by making it a cast to int64_t instead, which looks like the original intent. This fixes the sampling-profiler tests in JSTests/stress. * runtime/SamplingProfiler.cpp: (JSC::SamplingProfiler::timerLoop): 2017-06-01 Tomas Popela , Mark Lam RELEASE_ASSERT_NOT_REACHED() in InferredType::kindForFlags() on Big-Endians https://bugs.webkit.org/show_bug.cgi?id=170945 Reviewed by Mark Lam. Re-define PutByIdFlags as a int32_t enum explicitly because it is stored as an int32_t value in UnlinkedInstruction. This prevents a bug on 64-bit big endian architectures where the word order is inverted (when we convert the UnlinkedInstruction into a CodeBlock Instruction), resulting in the PutByIdFlags value not being stored in the 32-bit word that the rest of the code expects it to be in. * bytecode/PutByIdFlags.h: 2017-05-31 Yusuke Suzuki [JSC] Implement String.prototype.concat in JS builtins https://bugs.webkit.org/show_bug.cgi?id=172798 Reviewed by Sam Weinig. Since we have highly effective + operation for strings, implementing String.prototype.concat in JS simplifies the implementation and improves performance by using speculated types. Added microbenchmarks show performance improvement. string-concat-long-convert 1063.2787+-12.9101 ^ 109.0855+-2.8083 ^ definitely 9.7472x faster string-concat-convert 1111.1366+-12.2363 ^ 99.3402+-1.9874 ^ definitely 11.1852x faster string-concat 131.7377+-3.8359 ^ 54.3949+-0.9580 ^ definitely 2.4219x faster string-concat-long 79.4726+-1.9644 ^ 64.6301+-1.4941 ^ definitely 1.2297x faster * builtins/StringPrototype.js: (globalPrivate.stringConcatSlowPath): (concat): * runtime/StringPrototype.cpp: (JSC::StringPrototype::finishCreation): (JSC::stringProtoFuncConcat): Deleted. 2017-05-31 Mark Lam Remove overrides of visitChildren() that do not add any functionality. https://bugs.webkit.org/show_bug.cgi?id=172789 Reviewed by Andreas Kling. * bytecode/UnlinkedModuleProgramCodeBlock.cpp: (JSC::UnlinkedModuleProgramCodeBlock::visitChildren): Deleted. * bytecode/UnlinkedModuleProgramCodeBlock.h: * bytecode/UnlinkedProgramCodeBlock.cpp: (JSC::UnlinkedProgramCodeBlock::visitChildren): Deleted. * bytecode/UnlinkedProgramCodeBlock.h: * wasm/js/WebAssemblyFunction.cpp: (JSC::WebAssemblyFunction::visitChildren): Deleted. * wasm/js/WebAssemblyFunction.h: * wasm/js/WebAssemblyInstanceConstructor.cpp: (JSC::WebAssemblyInstanceConstructor::visitChildren): Deleted. * wasm/js/WebAssemblyInstanceConstructor.h: * wasm/js/WebAssemblyMemoryConstructor.cpp: (JSC::WebAssemblyMemoryConstructor::visitChildren): Deleted. * wasm/js/WebAssemblyMemoryConstructor.h: * wasm/js/WebAssemblyModuleConstructor.cpp: (JSC::WebAssemblyModuleConstructor::visitChildren): Deleted. * wasm/js/WebAssemblyModuleConstructor.h: * wasm/js/WebAssemblyTableConstructor.cpp: (JSC::WebAssemblyTableConstructor::visitChildren): Deleted. * wasm/js/WebAssemblyTableConstructor.h: 2017-05-31 Commit Queue Unreviewed, rolling out r217611 and r217631. https://bugs.webkit.org/show_bug.cgi?id=172785 "caused wasm-hashset-many.html to become flaky." (Requested by keith_miller on #webkit). Reverted changesets: "Reland r216808, underlying lldb bug has been fixed." https://bugs.webkit.org/show_bug.cgi?id=172759 http://trac.webkit.org/changeset/217611 "Use dispatch queues for mach exceptions" https://bugs.webkit.org/show_bug.cgi?id=172775 http://trac.webkit.org/changeset/217631 2017-05-31 Oleksandr Skachkov Rolling out: Prevent async methods named 'function' https://bugs.webkit.org/show_bug.cgi?id=172776 Reviewed by Mark Lam. Rolling out https://bugs.webkit.org/show_bug.cgi?id=172660 r217578, https://bugs.webkit.org/show_bug.cgi?id=172598 r217478 PR to spec was closed, so changes need to roll out. See https://github.com/tc39/ecma262/pull/884#issuecomment-305212494 * parser/Parser.cpp: (JSC::Parser::parseClass): (JSC::Parser::parsePropertyMethod): 2017-05-31 Andy Estes Rename ENABLE_APPLE_PAY_DELEGATE to ENABLE_APPLE_PAY_SESSION_V3 and bump the supported version number https://bugs.webkit.org/show_bug.cgi?id=172366 Reviewed by Daniel Bates. * Configurations/FeatureDefines.xcconfig: 2017-05-31 Keith Miller Reland r216808, underlying lldb bug has been fixed. https://bugs.webkit.org/show_bug.cgi?id=172759 Unreviewed, relanding old patch. See: rdar://problem/31183352 * API/tests/ExecutionTimeLimitTest.cpp: (dispatchTermitateCallback): (testExecutionTimeLimit): * runtime/JSLock.cpp: (JSC::JSLock::didAcquireLock): * runtime/Options.cpp: (JSC::overrideDefaults): (JSC::Options::initialize): * runtime/Options.h: * runtime/VMTraps.cpp: (JSC::SignalContext::SignalContext): (JSC::SignalContext::adjustPCToPointToTrappingInstruction): (JSC::installSignalHandler): (JSC::VMTraps::SignalSender::send): * tools/SigillCrashAnalyzer.cpp: (JSC::SignalContext::SignalContext): (JSC::SignalContext::dump): (JSC::installCrashHandler): * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::compileFunctions): * wasm/WasmFaultSignalHandler.cpp: (JSC::Wasm::trapHandler): (JSC::Wasm::enableFastMemory): * wasm/WasmMachineThreads.cpp: (JSC::Wasm::resetInstructionCacheOnAllThreads): 2017-05-31 Keith Miller Fix leak in PromiseDeferredTimer https://bugs.webkit.org/show_bug.cgi?id=172755 Reviewed by JF Bastien. We were not properly freeing the list of dependencies if we were already tracking the promise before. This is because addPendingPromise takes the list of dependencies as an rvalue-reference. In the case where we were already tracking the promise we append the provided dependency list to the existing list. Since we never bound or rvalue-ref to a non-temporary value we never destructed the Vector, leaking its contents. * runtime/PromiseDeferredTimer.cpp: (JSC::PromiseDeferredTimer::addPendingPromise): 2017-05-30 Oleksandr Skachkov Prevent async methods named 'function' in Object literal https://bugs.webkit.org/show_bug.cgi?id=172660 Reviewed by Saam Barati. Prevent async method named 'function' in object. https://github.com/tc39/ecma262/pull/884 * parser/Parser.cpp: (JSC::Parser::parsePropertyMethod): 2017-05-30 Oleksandr Skachkov ASSERTION FAILED: generator.isConstructor() || generator.derivedContextType() == DerivedContextType::DerivedConstructorContext https://bugs.webkit.org/show_bug.cgi?id=171274 Reviewed by Saam Barati. Current patch allow to use async arrow function within constructor, and allow to access to `this`. Current patch force load 'this' from virtual scope each time as we access to `this` in async arrow function within constructor it is neccessary because async function can be suspended and `superCall` can be called and async function resumed. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitPutGeneratorFields): (JSC::BytecodeGenerator::ensureThis): * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::makeFunction): 2017-05-30 Ali Juma [CredentialManagement] Incorporate IDL updates from latest spec https://bugs.webkit.org/show_bug.cgi?id=172011 Reviewed by Daniel Bates. * runtime/CommonIdentifiers.h: 2017-05-30 Alex Christensen Update libwebrtc configuration https://bugs.webkit.org/show_bug.cgi?id=172727 Reviewed by Geoffrey Garen. * Configurations/FeatureDefines.xcconfig: 2017-05-28 Dan Bernstein [Xcode] ALWAYS_SEARCH_USER_PATHS is set to YES https://bugs.webkit.org/show_bug.cgi?id=172691 Reviewed by Tim Horton. * Configurations/Base.xcconfig: Set ALWAYS_SEARCH_USER_PATHS to NO. * JavaScriptCore.xcodeproj/project.pbxproj: Added ParseInt.h to the JavaScriptCore target. 2017-05-28 Yusuke Suzuki [JSC] Provide better type information of toLength and tighten bytecode https://bugs.webkit.org/show_bug.cgi?id=172690 Reviewed by Sam Weinig. In this patch, we carefully leverage operator + in order to 1. tighten bytecode operator+ emits to_number bytecode. What this bytecode does is the same to @Number() call. It is more efficient, and it is smaller bytecode than @Number() call (load global variable @Number, set up arguments, and call it). 2. offer better type prediction data Now, we have code like length > 0 ? (length < @MAX_SAFE_INTEGER ? length : @MAX_SAFE_INTEGER) : 0 This is not good because DFG prediction propagation phase predicts as Double since @MAX_SAFE_INTEGER is double. But actually it rarely becomes Double. Usually, the result becomes Int32. This patch leverages to_number in a bit interesting way: to_number has value profiling to offer better type prediction. This value profiling can offer a chance to change the prediction to Int32 efficiently. It is a bit tricky. But it is worth doing to speed up our builtin functions, which should leverage all the JSC's tricky things to be optimized. Related microbenchmarks show performance improvement. baseline patched array-prototype-forEach 50.2348+-2.2331 49.7568+-2.3507 array-prototype-map 51.0574+-1.8166 47.9531+-2.1653 might be 1.0647x faster array-prototype-some 52.3926+-1.8882 ^ 48.3632+-2.0852 ^ definitely 1.0833x faster array-prototype-every 52.7394+-2.0712 50.2896+-2.1480 might be 1.0487x faster array-prototype-reduce 54.9994+-2.3638 51.8716+-2.6253 might be 1.0603x faster array-prototype-reduceRight 209.7594+-9.2594 ^ 51.5867+-2.5745 ^ definitely 4.0662x faster * builtins/GlobalOperations.js: (globalPrivate.toInteger): (globalPrivate.toLength): 2017-05-28 Sam Weinig [WebIDL] @@iterator should only be accessed once when disambiguating a union type https://bugs.webkit.org/show_bug.cgi?id=172684 Reviewed by Yusuke Suzuki. * runtime/IteratorOperations.cpp: (JSC::iteratorMethod): (JSC::iteratorForIterable): * runtime/IteratorOperations.h: (JSC::forEachInIterable): Add additional iterator helpers to allow union + sequence conversion code to check for iterability by getting the iterator method, and iterate using that method later on. 2017-05-28 Yusuke Suzuki Unreviewed, build fix for Windows https://bugs.webkit.org/show_bug.cgi?id=172413 Optimized jsDynamicCast for JSMap and JSSet will be handled in [1]. [1]: https://bugs.webkit.org/show_bug.cgi?id=172685 * runtime/JSMap.h: (JSC::isJSMap): (JSC::jsDynamicCast): Deleted. (JSC::>): Deleted. * runtime/JSSet.h: (JSC::isJSSet): (JSC::jsDynamicCast): Deleted. (JSC::>): Deleted. * runtime/MapConstructor.cpp: (JSC::constructMap): * runtime/SetConstructor.cpp: (JSC::constructSet): 2017-05-28 Mark Lam Implement a faster Interpreter::getOpcodeID(). https://bugs.webkit.org/show_bug.cgi?id=172669 Reviewed by Saam Barati. We can implement Interpreter::getOpcodeID() without a hash table lookup by always embedding the OpcodeID in the 32-bit word just before the start of the LLInt handler code that executes each opcode. getOpcodeID() can therefore just read the 32-bits before the opcode address to get its OpcodeID. This is currently only enabled for CPU(X86), CPU(X86_64), CPU(ARM64), CPU(ARM_THUMB2), and only for OS(DARWIN). It'll probably just work for linux as well, but I'll let the Linux folks turn that on after they have verified that it works on linux too. I'll also take this opportunity to clean up how we initialize the opcodeIDTable: 1. we only need to initialize it once per process, not once per VM / interpreter instance. 2. we can initialize it in the Interpreter constructor instead of requiring a separate call to an initialize() function. On debug builds, the Interpreter constructor will also verify that getOpcodeID() is working correctly for each opcode when USE(LLINT_EMBEDDED_OPCODE_ID). * bytecode/BytecodeList.json: * generate-bytecode-files: * interpreter/Interpreter.cpp: (JSC::Interpreter::Interpreter): (JSC::Interpreter::opcodeIDTable): (JSC::Interpreter::initialize): Deleted. * interpreter/Interpreter.h: (JSC::Interpreter::getOpcode): (JSC::Interpreter::getOpcodeID): * llint/LowLevelInterpreter.cpp: * runtime/VM.cpp: (JSC::VM::VM): 2017-05-27 Yusuke Suzuki [JSC] Map and Set constructors should have fast path for cloning https://bugs.webkit.org/show_bug.cgi?id=172413 Reviewed by Saam Barati. In this patch, we add a fast path for cloning in Set and Map constructors. In ARES-6 Air, we have code like `new Set(set)` to clone the given set. At that time, our generic path just iterates the given set object and add it to the newly created one. It is quite slow because we need to follow the iterator protocol inside C++ and we need to call set.add() repeatedly while the given set guarantees the elements are unique. This patch implements clone() function to JSMap and JSSet. Cloning JSMap and JSSet are done really fast without invoking any observable JS functions. To check whether we can use this clone() function in Set and Map constructors, we set several watchpoints. In the case of Set, 1. Set.prototype[Symbol.iterator] is not changed. 2. SetIterator.prototype.next is not changed. 3. Set.prototype.add is not changed. 4. The given Set does not have [Symbol.iterator] function in its instance. 5. The given Set's [[Prototype]] is Set.prototype. 6. Newly created set's [[Prototype]] is Set.prototype. If the above requirements are met, cloning the given Set is not observable to users. Thus we can take a fast path. Currently, we do not integrate this optimization into DFG and FTL. And we do not optimize other iterables. For example, we can optimize Set constructor taking Int32 Array. And we should optimize generic iterator cases too. They are planned as part of a separate bug[1]. This change improves ARES-6 Air by 5.3% in steady state. Baseline: Running... Air ( 1 to go) firstIteration: 76.41 +- 15.60 ms averageWorstCase: 40.63 +- 7.54 ms steadyState: 9.13 +- 0.51 ms Patched: Running... Air ( 1 to go) firstIteration: 75.00 +- 22.54 ms averageWorstCase: 39.18 +- 8.45 ms steadyState: 8.67 +- 0.28 ms [1]: https://bugs.webkit.org/show_bug.cgi?id=172419 * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * runtime/ArrayIteratorAdaptiveWatchpoint.cpp: Removed. * runtime/HashMapImpl.h: (JSC::HashMapBucket::extractValue): (JSC::HashMapImpl::finishCreation): (JSC::HashMapImpl::add): (JSC::HashMapImpl::setUpHeadAndTail): (JSC::HashMapImpl::addNormalizedNonExistingForCloning): (JSC::HashMapImpl::addNormalizedInternal): * runtime/InternalFunction.cpp: (JSC::InternalFunction::createSubclassStructureSlow): (JSC::InternalFunction::createSubclassStructure): Deleted. * runtime/InternalFunction.h: (JSC::InternalFunction::createSubclassStructure): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::JSGlobalObject): (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildren): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::mapIteratorProtocolWatchpoint): (JSC::JSGlobalObject::setIteratorProtocolWatchpoint): (JSC::JSGlobalObject::mapSetWatchpoint): (JSC::JSGlobalObject::setAddWatchpoint): (JSC::JSGlobalObject::mapPrototype): (JSC::JSGlobalObject::jsSetPrototype): (JSC::JSGlobalObject::setStructure): * runtime/JSGlobalObjectInlines.h: (JSC::JSGlobalObject::isMapPrototypeIteratorProtocolFastAndNonObservable): (JSC::JSGlobalObject::isSetPrototypeIteratorProtocolFastAndNonObservable): (JSC::JSGlobalObject::isMapPrototypeSetFastAndNonObservable): (JSC::JSGlobalObject::isSetPrototypeAddFastAndNonObservable): * runtime/JSMap.cpp: (JSC::JSMap::clone): (JSC::JSMap::canCloneFastAndNonObservable): * runtime/JSMap.h: (JSC::jsDynamicCast): (JSC::>): (JSC::JSMap::createStructure): Deleted. (JSC::JSMap::create): Deleted. (JSC::JSMap::set): Deleted. (JSC::JSMap::JSMap): Deleted. * runtime/JSSet.cpp: (JSC::JSSet::clone): (JSC::JSSet::canCloneFastAndNonObservable): * runtime/JSSet.h: (JSC::jsDynamicCast): (JSC::>): (JSC::JSSet::createStructure): Deleted. (JSC::JSSet::create): Deleted. (JSC::JSSet::JSSet): Deleted. * runtime/MapConstructor.cpp: (JSC::constructMap): * runtime/ObjectPropertyChangeAdaptiveWatchpoint.h: Renamed from Source/JavaScriptCore/runtime/ArrayIteratorAdaptiveWatchpoint.h. (JSC::ObjectPropertyChangeAdaptiveWatchpoint::ObjectPropertyChangeAdaptiveWatchpoint): * runtime/SetConstructor.cpp: (JSC::constructSet): 2017-05-27 Yusuke Suzuki [DOMJIT] Move DOMJIT patchpoint infrastructure out of domjit https://bugs.webkit.org/show_bug.cgi?id=172260 Reviewed by Filip Pizlo. DOMJIT::Patchpoint is now used for generalized CheckSubClass. And it becomes mature enough to be used as a general-purpose injectable compiler over all the JIT tiers. We extract DOMJIT::Patchpoint to jit/ and rename it JSC::Snippet. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/AccessCaseSnippetParams.cpp: Renamed from Source/JavaScriptCore/bytecode/DOMJITAccessCasePatchpointParams.cpp. (JSC::SlowPathCallGeneratorWithArguments::generateImpl): (JSC::AccessCaseSnippetParams::emitSlowPathCalls): * bytecode/AccessCaseSnippetParams.h: Renamed from Source/JavaScriptCore/bytecode/DOMJITAccessCasePatchpointParams.h. (JSC::AccessCaseSnippetParams::AccessCaseSnippetParams): * bytecode/GetterSetterAccessCase.cpp: (JSC::GetterSetterAccessCase::emitDOMJITGetter): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::blessCallDOMGetter): (JSC::DFG::ByteCodeParser::handleDOMJITGetter): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.h: * dfg/DFGNode.h: * dfg/DFGSnippetParams.cpp: Renamed from Source/JavaScriptCore/dfg/DFGDOMJITPatchpointParams.cpp. * dfg/DFGSnippetParams.h: Renamed from Source/JavaScriptCore/dfg/DFGDOMJITPatchpointParams.h. (JSC::DFG::SnippetParams::SnippetParams): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::allocateTemporaryRegistersForSnippet): (JSC::DFG::SpeculativeJIT::compileCallDOMGetter): (JSC::DFG::SpeculativeJIT::compileCheckSubClass): (JSC::DFG::allocateTemporaryRegistersForPatchpoint): Deleted. * domjit/DOMJITCallDOMGetterSnippet.h: Renamed from Source/JavaScriptCore/domjit/DOMJITCallDOMGetterPatchpoint.h. (JSC::DOMJIT::CallDOMGetterSnippet::create): * domjit/DOMJITGetterSetter.h: * domjit/DOMJITSignature.h: * domjit/DOMJITValue.h: Removed. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass): (JSC::FTL::DFG::LowerDFGToB3::compileCallDOMGetter): * ftl/FTLSnippetParams.cpp: Renamed from Source/JavaScriptCore/ftl/FTLDOMJITPatchpointParams.cpp. * ftl/FTLSnippetParams.h: Renamed from Source/JavaScriptCore/ftl/FTLDOMJITPatchpointParams.h. (JSC::FTL::SnippetParams::SnippetParams): * jit/Snippet.h: Renamed from Source/JavaScriptCore/domjit/DOMJITPatchpoint.h. (JSC::Snippet::create): (JSC::Snippet::setGenerator): (JSC::Snippet::generator): * jit/SnippetParams.h: Renamed from Source/JavaScriptCore/domjit/DOMJITPatchpointParams.h. (JSC::SnippetParams::~SnippetParams): (JSC::SnippetParams::Value::Value): (JSC::SnippetParams::Value::isGPR): (JSC::SnippetParams::Value::isFPR): (JSC::SnippetParams::Value::isJSValueRegs): (JSC::SnippetParams::Value::gpr): (JSC::SnippetParams::Value::fpr): (JSC::SnippetParams::Value::jsValueRegs): (JSC::SnippetParams::Value::reg): (JSC::SnippetParams::Value::value): (JSC::SnippetParams::SnippetParams): * jit/SnippetReg.h: Renamed from Source/JavaScriptCore/domjit/DOMJITReg.h. (JSC::SnippetReg::SnippetReg): * jit/SnippetSlowPathCalls.h: Renamed from Source/JavaScriptCore/domjit/DOMJITSlowPathCalls.h. * jsc.cpp: (WTF::DOMJITNode::checkSubClassSnippet): (WTF::DOMJITFunctionObject::checkSubClassSnippet): (WTF::DOMJITNode::checkSubClassPatchpoint): Deleted. (WTF::DOMJITFunctionObject::checkSubClassPatchpoint): Deleted. * runtime/ClassInfo.h: 2017-05-26 Keith Miller REEGRESSION(r217459): testapi fails in JSExportTest's wrapperForNSObjectisObject(). https://bugs.webkit.org/show_bug.cgi?id=172654 Reviewed by Mark Lam. The test's intent is to assert that an exception has not been thrown (as indicated by the message string), but the test was erroneously checking for ! the right condition. This is now fixed. * API/tests/JSExportTests.mm: (wrapperForNSObjectisObject): 2017-05-26 Joseph Pecoraro JSContext Inspector: Improve the reliability of automatically pausing in auto-attach https://bugs.webkit.org/show_bug.cgi?id=172664 Reviewed by Matt Baker. Automatically pause on connection was triggering a pause before the frontend may have initialized. Often during frontend initialization the frontend may perform an action that clears the pause state requested by the developer. This change defers the pause until after the frontend has initialized, right before returning to the application's code. * inspector/remote/RemoteControllableTarget.h: * inspector/remote/RemoteInspectionTarget.h: * inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm: (Inspector::RemoteConnectionToTarget::setup): * inspector/remote/glib/RemoteConnectionToTargetGlib.cpp: (Inspector::RemoteConnectionToTarget::setup): * runtime/JSGlobalObjectDebuggable.cpp: (JSC::JSGlobalObjectDebuggable::connect): (JSC::JSGlobalObjectDebuggable::pause): Deleted. * runtime/JSGlobalObjectDebuggable.h: Pass an immediatelyPause boolean on to the controller. Remove the current path that invokes a pause before initialization. * inspector/JSGlobalObjectInspectorController.h: * inspector/JSGlobalObjectInspectorController.cpp: (Inspector::JSGlobalObjectInspectorController::connectFrontend): (Inspector::JSGlobalObjectInspectorController::disconnectFrontend): Manage should immediately pause state. (Inspector::JSGlobalObjectInspectorController::frontendInitialized): (Inspector::JSGlobalObjectInspectorController::pause): Deleted. When initialized, trigger a pause if requested. 2017-05-26 Mark Lam Temporarily commenting out a JSExportTest test until webkit.org/b/172654 is fixed. https://bugs.webkit.org/show_bug.cgi?id=172655 Reviewed by Saam Barati. * API/tests/JSExportTests.mm: (wrapperForNSObjectisObject): 2017-05-26 Mark Lam REGRESSION(216914): testCFStrings encounters an invalid ExecState callee pointer. https://bugs.webkit.org/show_bug.cgi?id=172651 Reviewed by Saam Barati. This is because the assertion utility functions used in testCFStrings() expects to get the JSGlobalContextRef from the global context variable. However, testCFStrings() creates its own JSGlobalContextRef but does not set the global context variable to it. The fix is to make testCFStrings() initialize the global context variable properly. * API/tests/testapi.c: (testCFStrings): 2017-05-26 Yusuke Suzuki Give ModuleProgram the same treatment that we did for ProgramCode in bug#167725 https://bugs.webkit.org/show_bug.cgi?id=167805 Reviewed by Saam Barati. Since ModuleProgramExecutable is executed only once, we can skip compiling code unreachable from the current program count. This can skip massive initialization code. We already do this for global code in bug#167725. This patch extends it to module code. * interpreter/Interpreter.cpp: (JSC::Interpreter::executeModuleProgram): * interpreter/Interpreter.h: * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * runtime/JSModuleRecord.cpp: (JSC::JSModuleRecord::evaluate): * runtime/JSModuleRecord.h: (JSC::JSModuleRecord::moduleProgramExecutable): Deleted. 2017-05-26 Oleksandr Skachkov Prevent async methods named 'function' https://bugs.webkit.org/show_bug.cgi?id=172598 Reviewed by Mark Lam. Prevent async method named 'function' in class. Link to change in ecma262 specification https://github.com/tc39/ecma262/pull/884 * parser/Parser.cpp: (JSC::Parser::parseClass): 2017-05-25 Yusuke Suzuki Unreviewed, build fix for GCC std::tuple does not have implicit constructor. Thus, we cannot use implicit construction with initializer brace. We should specify the name like `GetInst { }`. * bytecompiler/BytecodeGenerator.h: (JSC::StructureForInContext::addGetInst): 2017-05-25 Keith Miller Cleanup tests after r217240 https://bugs.webkit.org/show_bug.cgi?id=172466 Reviewed by Mark Lam. I forgot to make my test an actual test. Also, remove second call runJSExportTests() * API/tests/JSExportTests.mm: (wrapperForNSObjectisObject): * API/tests/testapi.mm: (testObjectiveCAPIMain): 2017-05-25 Michael Saboff The default setting of Option::criticalGCMemoryThreshold is too high for iOS https://bugs.webkit.org/show_bug.cgi?id=172617 Reviewed by Mark Lam. Reducing criticalGCMemoryThreshold to 0.80 eliminated jetsam on iOS devices when tested running JetStream. * runtime/Options.h: 2017-05-25 Saam Barati Our for-in optimization in the bytecode generator does its static analysis incorrectly https://bugs.webkit.org/show_bug.cgi?id=172532 Reviewed by Mark Lam. Our static analysis for when a for-in induction variable is written to tried to its analysis as we generate bytecode. This has issues, since it does not account for the dynamic execution path of the program. Let's consider a program where our old analysis worked: ``` for (let p in o) { o[p]; // We can transform this into a fast get_direct_pname p = 20; o[p]; // We cannot transform this since p has been changed. } ``` However, our static analysis did not account for loops, which exist in JavaScript. e.g, it would incorrectly compile this program as: ``` for (let p in o) { for (let i = 0; i < 20; ++i) { o[p]; // It transforms this to use get_direct_pname even though p will be over-written if we get here from the inner loop back edge! p = 20; o[p]; // We correctly do not transform this. } } ``` Because of this flaw, I've made the optimization more conservative. We now optimistically emit code for the optimized access. However, if a for-in context is *ever* invalidated, before we pop it off the stack, we rewrite the program's optimized accesses to no longer be optimized. To do this, each context keeps track of its optimized accesses. This patch also adds a new bytecode, op_nop, which is just a no-op. It was helpful to add this because reverting get_direct_pname to get_by_val will leave us with an extra instruction word because get_direct_pname is has a length of 7 where get_by_val has a length of 6. This leaves us with an extra slot that we fill with an op_nop. * bytecode/BytecodeDumper.cpp: (JSC::BytecodeDumper::dumpBytecode): * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitGetByVal): (JSC::BytecodeGenerator::popIndexedForInScope): (JSC::BytecodeGenerator::popStructureForInScope): (JSC::BytecodeGenerator::invalidateForInContextForLocal): (JSC::StructureForInContext::pop): (JSC::IndexedForInContext::pop): * bytecompiler/BytecodeGenerator.h: (JSC::StructureForInContext::addGetInst): (JSC::IndexedForInContext::addGetInst): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JIT.h: * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_nop): * llint/LowLevelInterpreter.asm: 2017-05-25 Mark Lam ObjectToStringAdaptiveInferredPropertyValueWatchpoint should not reinstall itself nor handleFire if it's dying shortly. https://bugs.webkit.org/show_bug.cgi?id=172548 Reviewed by Filip Pizlo. Consider the following scenario: 1. A ObjectToStringAdaptiveInferredPropertyValueWatchpoint O1, watches for structure transitions, e.g. structure S2 transitioning to structure S3. In this case, O1 would be installed in S2's watchpoint set. 2. When the structure transition happens, structure S2 will fire watchpoint O1. 3. O1's handler will normally re-install itself in the watchpoint set of the new "transitioned to" structure S3. 4. "Installation" here requires writing into the StructureRareData SD3 of the new structure S3. If SD3 does not exist yet, the installation process will trigger the allocation of StructureRareData SD3. 5. It is possible that the Structure S1, and StructureRareData SD1 that owns the ObjectToStringAdaptiveInferredPropertyValueWatchpoint O1 is no longer reachable by the GC, and therefore will be collected soon. 6. The allocation of SD3 in (4) may trigger the sweeping of the StructureRareData SD1. This, in turn, triggers the deletion of the ObjectToStringAdaptiveInferredPropertyValueWatchpoint O1. After O1 is deleted in (6) and SD3 is allocated in (4), execution continues in AdaptiveInferredPropertyValueWatchpointBase::fire() where O1 gets installed in structure S3's watchpoint set. This is obviously incorrect because O1 is already deleted. The result is that badness happens later when S3's watchpoint set fires its watchpoints and accesses the deleted O1. The fix is to enhance AdaptiveInferredPropertyValueWatchpointBase::fire() to check if "this" is still valid before proceeding to re-install itself or to invoke its handleFire() method. ObjectToStringAdaptiveInferredPropertyValueWatchpoint (which extends AdaptiveInferredPropertyValueWatchpointBase) will override its isValid() method, and return false its owner StructureRareData is no longer reachable by the GC. This ensures that it won't be deleted while it's installed to any watchpoint set. Additional considerations and notes: 1. In the above, I talked about the ObjectToStringAdaptiveInferredPropertyValueWatchpoint being installed in watchpoint sets. What actually happens is that ObjectToStringAdaptiveInferredPropertyValueWatchpoint has 2 members (m_structureWatchpoint and m_propertyWatchpoint) which may be installed in watchpoint sets. The ObjectToStringAdaptiveInferredPropertyValueWatchpoint is not itself a Watchpoint object. But for brevity, in the above, I refer to the ObjectToStringAdaptiveInferredPropertyValueWatchpoint instead of its Watchpoint members. The description of the issue is still accurate given the life-cycle of the Watchpoint members are embedded in the enclosing ObjectToStringAdaptiveInferredPropertyValueWatchpoint object, and hence, they share the same life-cycle. 2. The top of AdaptiveInferredPropertyValueWatchpointBase::fire() removes its m_structureWatchpoint and m_propertyWatchpoint if they have been added to any watchpoint sets. This is safe to do even if the owner StructureRareData is no longer reachable by the GC. This is because the only way we can get to AdaptiveInferredPropertyValueWatchpointBase::fire() is if its Watchpoint members are still installed in some watchpoint set that fired. This means that the AdaptiveInferredPropertyValueWatchpointBase instance has not been deleted yet, because its destructor will automatically remove the Watchpoint members from any watchpoint sets. * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp: (JSC::AdaptiveInferredPropertyValueWatchpointBase::fire): (JSC::AdaptiveInferredPropertyValueWatchpointBase::isValid): * bytecode/AdaptiveInferredPropertyValueWatchpointBase.h: * heap/FreeList.cpp: (JSC::FreeList::contains): * heap/FreeList.h: * heap/HeapCell.h: * heap/HeapCellInlines.h: (JSC::HeapCell::isLive): * heap/MarkedAllocator.h: (JSC::MarkedAllocator::isFreeListedCell): * heap/MarkedBlock.h: * heap/MarkedBlockInlines.h: (JSC::MarkedBlock::Handle::isFreeListedCell): * runtime/StructureRareData.cpp: (JSC::ObjectToStringAdaptiveInferredPropertyValueWatchpoint::isValid): 2017-05-23 Saam Barati We should not mmap zero bytes for a memory in Wasm https://bugs.webkit.org/show_bug.cgi?id=172528 Reviewed by Mark Lam. This patch fixes a bug where we would call into mmap with zero bytes when creating a slow WasmMemory with zero initial page size. This fix is simple: if we don't have any initial bytes, we just call the constructor in WasmMemory that's meant to handle this case. * wasm/WasmMemory.cpp: (JSC::Wasm::Memory::create): 2017-05-23 Brian Burg REGRESSION(r217051): Automation sessions fail to complete bootstrap https://bugs.webkit.org/show_bug.cgi?id=172513 Reviewed by Joseph Pecoraro. The changes to be more strict about typechecking messages were too strict. * inspector/remote/cocoa/RemoteInspectorCocoa.mm: (Inspector::RemoteInspector::receivedSetupMessage): WIRAutomatically is an optional key in the setup message. In the relay, this key gets copied into an NSDictionary as NSNull if the key isn't present in a forwarded command. We need to revert NSNull values to nil, since it's valid to call [nil boolValue] but not [[NSNull null] boolValue]. We also need to allow for nil in the typecheck for this key. 2017-05-23 Myles C. Maxfield Remove dead ENABLE(FONT_LOAD_EVENTS) code https://bugs.webkit.org/show_bug.cgi?id=172517 Rubber-stamped by Simon Fraser. * Configurations/FeatureDefines.xcconfig: 2017-05-23 Saam Barati CFGSimplificationPhase should not merge a block with itself https://bugs.webkit.org/show_bug.cgi?id=172508 Reviewed by Keith Miller. CFGSimplificationPhase can run into or create IR that ends up with a block that has a Jump to itself, and no other predecessors. It should gracefully handle such IR. Before this patch, it would not. The only criteria for merging 'block' with 'targetBlock' used to be that 'targetBlock.predecessors.size() == 1'. The code is written in such a way that if we merge a block with itself, we will infinite loop until we run out of memory. Merging a block with itself does not make sense for a few reasons. First, we're joining the contents of two blocks. What is the definition of joining a block with itself? I suppose we could simply unroll this self loop one level, but that would not be wise because this self loop is by definition unreachable unless it's the root block in the graph (which I think is invalid IR since we'd never generate bytecode that would do this). This patch employs an easy fix: we can't merge a block with itself. * dfg/DFGCFGSimplificationPhase.cpp: (JSC::DFG::CFGSimplificationPhase::canMergeBlocks): (JSC::DFG::CFGSimplificationPhase::run): (JSC::DFG::CFGSimplificationPhase::convertToJump): (JSC::DFG::CFGSimplificationPhase::mergeBlocks): 2017-05-22 Brian Burg Web Inspector: webkit reload policy should match default behavior https://bugs.webkit.org/show_bug.cgi?id=171385 Reviewed by Joseph Pecoraro. Add a new option to Page.reload that allows the test harness to reload its test page using the old reload behavior. The new behavior of revalidating expired cached subresources only is the current default, since only the test harness needs the old behavior. * inspector/protocol/Page.json: 2017-05-22 Keith Miller [Cocoa] An exported Objective C class’s prototype and constructor don't persist across JSContext deallocation https://bugs.webkit.org/show_bug.cgi?id=167708 Reviewed by Geoffrey Garen. This patch moves the Objective C wrapper map to the global object. In order to make this work the JSWrapperMap class no longer holds a reference to the JSContext. Instead, the context must be provided when getting a wrapper. Also, this patch fixes a "bug" where we would observe changes to the Object property on the global object when creating a wrapper for NSObject. * API/APICast.h: (toJSGlobalObject): * API/JSContext.mm: (-[JSContext ensureWrapperMap]): (-[JSContext initWithVirtualMachine:]): (-[JSContext dealloc]): (-[JSContext wrapperMap]): (-[JSContext initWithGlobalContextRef:]): (-[JSContext wrapperForObjCObject:]): (-[JSContext wrapperForJSObject:]): * API/JSWrapperMap.h: * API/JSWrapperMap.mm: (-[JSObjCClassInfo initForClass:]): (-[JSObjCClassInfo allocateConstructorAndPrototypeInContext:]): (-[JSObjCClassInfo wrapperForObject:inContext:]): (-[JSObjCClassInfo constructorInContext:]): (-[JSObjCClassInfo prototypeInContext:]): (-[JSWrapperMap initWithGlobalContextRef:]): (-[JSWrapperMap classInfoForClass:]): (-[JSWrapperMap jsWrapperForObject:inContext:]): (-[JSWrapperMap objcWrapperForJSValueRef:inContext:]): (-[JSObjCClassInfo initWithContext:forClass:]): Deleted. (-[JSObjCClassInfo allocateConstructorAndPrototype]): Deleted. (-[JSObjCClassInfo wrapperForObject:]): Deleted. (-[JSObjCClassInfo constructor]): Deleted. (-[JSObjCClassInfo prototype]): Deleted. (-[JSWrapperMap initWithContext:]): Deleted. (-[JSWrapperMap jsWrapperForObject:]): Deleted. (-[JSWrapperMap objcWrapperForJSValueRef:]): Deleted. * API/tests/JSExportTests.mm: (wrapperLifetimeIsTiedToGlobalObject): (runJSExportTests): * API/tests/testapi.mm: * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::wrapperMap): (JSC::JSGlobalObject::setWrapperMap): 2017-05-22 Filip Pizlo FTL stack overflow handling should not assume that B3 never selects callee-saves in the prologue https://bugs.webkit.org/show_bug.cgi?id=172455 Reviewed by Mark Lam. The FTL needs to run B3's callee-save register restoration before it runs the exception handler's callee-save register restoration. This exposes B3's callee-save register algorithm in AssemblyHelpers so that the FTL can call it. * b3/air/AirGenerate.cpp: (JSC::B3::Air::generate): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::lower): Fix the bug. * heap/Subspace.cpp: Added some debugging support. (JSC::Subspace::allocate): (JSC::Subspace::tryAllocate): (JSC::Subspace::didAllocate): * heap/Subspace.h: * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::addressFor): (JSC::AssemblyHelpers::emitSave): (JSC::AssemblyHelpers::emitRestore): 2017-05-20 Yusuke Suzuki [FTL] Support GetByVal with ArrayStorage and SlowPutArrayStorage https://bugs.webkit.org/show_bug.cgi?id=172216 Reviewed by Saam Barati. This patch adds GetByVal support for ArrayStorage and SlowPutArrayStorage. To lower CheckInBounds in FTL, we add a new GetVectorLength op. It only accepts ArrayStorage and SlowPutArrayStorage, then it produces vector length. CheckInBounds uses this vector length to perform bound checking for ArrayStorage and SlowPutArrayStorage. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGArrayMode.cpp: (JSC::DFG::permitsBoundsCheckLowering): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGHeapLocation.cpp: (WTF::printInternal): * dfg/DFGHeapLocation.h: * dfg/DFGIntegerRangeOptimizationPhase.cpp: * dfg/DFGNode.h: (JSC::DFG::Node::hasArrayMode): * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSSALoweringPhase.cpp: (JSC::DFG::SSALoweringPhase::lowerBoundsCheck): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLAbstractHeapRepository.h: (JSC::FTL::AbstractHeapRepository::forIndexingType): (JSC::FTL::AbstractHeapRepository::forArrayType): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileGetVectorLength): (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal): * jit/JITPropertyAccess.cpp: (JSC::JIT::emitArrayStoragePutByVal): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emitArrayStorageLoad): (JSC::JIT::emitArrayStoragePutByVal): 2017-05-21 Saam Barati We incorrectly throw a syntax error when declaring a top level for-loop iteration variable the same as a parameter https://bugs.webkit.org/show_bug.cgi?id=171041 Reviewed by Yusuke Suzuki. We were treating a for-loop variable declaration potentially as a top level statement, e.g, in a program like this: ``` function foo() { for (let variable of expr) { } } ``` But we should not be. This had the consequence of making this type of program throw a syntax error: ``` function foo(arg) { for (let arg of expr) { } } ``` even though it should not. The fix is simple, we just need to increment the statement depth before parsing anything inside the for loop. * parser/Parser.cpp: (JSC::Parser::parseForStatement): 2017-05-19 Yusuke Suzuki [JSC] Make get_by_val & string "499" to number 499 https://bugs.webkit.org/show_bug.cgi?id=172225 Reviewed by Saam Barati. Property subscript will be converted by ToString. So JS code is not aware of the original type of the subscript value. But our get_by_val can leverage information if the given subscript is number. Thus, passing number instead of string can improve the performance of get_by_val in all the tiers. In this patch, we add BytecodeGenerator::emitNodeForProperty. It attempts to convert the given value to Int32 index constant if the given value is a string that can be converted to Int32. This patch improves SixSpeed map-string.es5 by 9.8x. This accessing form can appear in some code like accessing the result of JSON. map-string.es5 1640.6738+-110.9182 ^ 167.4121+-23.8328 ^ definitely 9.8002x faster * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::emitNodeForProperty): (JSC::BytecodeGenerator::emitNodeForLeftHandSideForProperty): * bytecompiler/NodesCodegen.cpp: (JSC::TaggedTemplateNode::emitBytecode): (JSC::BracketAccessorNode::emitBytecode): (JSC::BytecodeIntrinsicNode::emit_intrinsic_putByValDirect): (JSC::FunctionCallBracketNode::emitBytecode): (JSC::PostfixNode::emitBracket): (JSC::PrefixNode::emitBracket): (JSC::AssignBracketNode::emitBytecode): (JSC::ReadModifyBracketNode::emitBytecode): (JSC::ForInNode::emitLoopHeader): (JSC::ForOfNode::emitBytecode): (JSC::ObjectPatternNode::bindValue): (JSC::AssignmentElementNode::bindValue): 2017-05-21 Saam Barati We overwrite the callee save space on the stack when throwing stack overflow from wasm https://bugs.webkit.org/show_bug.cgi?id=172316 Reviewed by Mark Lam. When throwing a stack overflow exception, the overflow thunk would do the following: move fp, sp populate argument registers call C code However, the C function is allowed to clobber our spilled callee saves that live below fp. The reason I did this move is that when we jump to this code, we've proven that sp is out of bounds on the stack. So we're not allowed to just use its value or keep growing the stack from that point. However, this patch revises this approach to be the same in spirit, but actually correct. We conservatively assume the B3 function we're coming from could have saved all callee saves. So we emit code like this now: add -maxNumCalleeSaveSpace, fp, sp populate argument registers call C code This ensures our callee saves will not be overwritten. Note that fp is still in a valid stack range here, since the thing calling the wasm code did a stack check. Also note that maxNumCalleeSaveSpace is less than our redzone size, so it's safe to decrement sp by this amount. The previously added wasm stack overflow test is an instance crash without this change on arm64. It also appears that this test crashed on some other x86 devices. * wasm/WasmThunks.cpp: (JSC::Wasm::throwStackOverflowFromWasmThunkGenerator): 2017-05-20 Chris Dumez Drop [NoInterfaceObject] from RTCDTMFSender and RTCStatsReport https://bugs.webkit.org/show_bug.cgi?id=172418 Reviewed by Youenn Fablet. Add CommonIdentifiers that are now needed. * runtime/CommonIdentifiers.h: 2017-05-20 Yusuke Suzuki Unreviewed, add scope.release() to propertyIsEnumerable functions. https://bugs.webkit.org/show_bug.cgi?id=172411 * runtime/JSGlobalObjectFunctions.cpp: (JSC::globalFuncPropertyIsEnumerable): * runtime/ObjectPrototype.cpp: (JSC::objectProtoFuncPropertyIsEnumerable): 2017-05-20 Yusuke Suzuki [JSC] Drop MapBase https://bugs.webkit.org/show_bug.cgi?id=172417 Reviewed by Sam Weinig. MapBase is a purely additional indirection. JSMap and JSSet can directly inherit HashMapImpl. Thus MapBase is unnecessary. This patch drops it. It is good because we can eliminate one indirection when accessing to map implementation. Moreover, we can drop one unnecessary allocation per Map and Set. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLAbstractHeapRepository.h: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucket): * runtime/HashMapImpl.cpp: (JSC::HashMapImpl::estimatedSize): (JSC::getHashMapImplKeyClassInfo): Deleted. (JSC::getHashMapImplKeyValueClassInfo): Deleted. * runtime/HashMapImpl.h: (JSC::HashMapImpl::finishCreation): (JSC::HashMapImpl::get): (JSC::HashMapImpl::info): Deleted. (JSC::HashMapImpl::createStructure): Deleted. (JSC::HashMapImpl::create): Deleted. * runtime/JSMap.h: (JSC::JSMap::set): (JSC::JSMap::get): Deleted. * runtime/JSMapIterator.cpp: (JSC::JSMapIterator::finishCreation): * runtime/JSSet.h: (JSC::JSSet::add): Deleted. * runtime/JSSetIterator.cpp: (JSC::JSSetIterator::finishCreation): * runtime/MapBase.cpp: Removed. * runtime/MapBase.h: Removed. * runtime/MapPrototype.cpp: (JSC::mapProtoFuncSize): * runtime/SetConstructor.cpp: (JSC::constructSet): * runtime/SetPrototype.cpp: (JSC::setProtoFuncSize): * runtime/VM.cpp: (JSC::VM::VM): 2017-05-20 Yusuke Suzuki [JSC] Speedup Object.assign for slow case by using propertyIsEnumerable https://bugs.webkit.org/show_bug.cgi?id=172411 Reviewed by Sam Weinig. We use @Reflect.@getOwnPropertyDescriptor() to check 1. the descriptor exists, 2. and the descriptor.enumrable is true But Object::propertyIsEnumerable does the completely same thing without allocating a new object for property descriptor. In this patch, we add a new private function @propertyIsEnumerable, and use it in Object.assign implementation. It does not allocate unnecessary objects. It is good for GC-pressure and performance. This patch improves SixSpeed object-assign.es6 by 1.7x. While this patch does not introduce a fast path for objects that do not have accessors, and it could speed up things further, this patch can speed up the common slow path cases that is the current implementation of Object.assign. object-assign.es6 1103.2487+-21.5602 ^ 621.8478+-34.9875 ^ definitely 1.7741x faster * builtins/BuiltinNames.h: * builtins/ObjectConstructor.js: (globalPrivate.enumerableOwnProperties): (assign): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/JSGlobalObjectFunctions.cpp: (JSC::globalFuncPropertyIsEnumerable): * runtime/JSGlobalObjectFunctions.h: 2017-05-19 Yusuke Suzuki [JSC] Enable testapi on Mac CMake build https://bugs.webkit.org/show_bug.cgi?id=172354 Reviewed by Alex Christensen. This patch makes testapi buildable and runnable for Mac CMake port. * API/tests/DateTests.mm: (+[DateTests JSDateToNSDateTest]): (+[DateTests roundTripThroughJSDateTest]): This test only works with the en_US locale. * shell/CMakeLists.txt: * shell/PlatformMac.cmake: Some of tests rely on ARC. We enable ARC for those files. * shell/PlatformWin.cmake: Clean up. 2017-05-19 Mark Lam [Re-landing] DFG::SpeculativeJIT::pickCanTrample() is wrongly ignoring result registers. https://bugs.webkit.org/show_bug.cgi?id=172383 Reviewed by Filip Pizlo. pickCanTrample() is wrongly assuming that one of regT0 and regT1 is always available as a scratch register. This assumption is wrong if this canTrample register is used for a silentFill() after an operation that returns a result in regT0 or regT1. Turns out the only reason we need the canTrample register is for SetDoubleConstant. We can remove the need for this canTrample register by introducing a moveDouble() pseudo instruction in the MacroAssembler to do the job using the scratchRegister() on X86_64 or the dataMemoryTempRegister() on ARM64. In so doing, we can simplify the silentFill() code and eliminate the bug. Update for re-landing: Changed ARM64 to use scratchRegister() as well. scratchRegister() is the proper way to get the underlying dataMemoryTempRegister() as a scratch register. * assembler/MacroAssembler.h: (JSC::MacroAssembler::moveDouble): * dfg/DFGArrayifySlowPathGenerator.h: * dfg/DFGCallArrayAllocatorSlowPathGenerator.h: (JSC::DFG::CallArrayAllocatorWithVariableStructureVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableStructureVariableSizeSlowPathGenerator): * dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h: * dfg/DFGSaneStringGetByValSlowPathGenerator.h: * dfg/DFGSlowPathGenerator.h: (JSC::DFG::CallSlowPathGenerator::tearDown): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::silentFill): (JSC::DFG::SpeculativeJIT::compileToLowerCase): (JSC::DFG::SpeculativeJIT::compileValueToInt32): (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject): (JSC::DFG::SpeculativeJIT::emitUntypedBitOp): (JSC::DFG::SpeculativeJIT::emitUntypedRightShiftBitOp): (JSC::DFG::SpeculativeJIT::compileArithDiv): (JSC::DFG::SpeculativeJIT::compileArraySlice): (JSC::DFG::SpeculativeJIT::emitSwitchImm): (JSC::DFG::SpeculativeJIT::emitSwitchStringOnString): (JSC::DFG::SpeculativeJIT::compileStoreBarrier): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::silentFill): (JSC::DFG::SpeculativeJIT::silentSpillAllRegisters): (JSC::DFG::SpeculativeJIT::silentFillAllRegisters): (JSC::DFG::SpeculativeJIT::pickCanTrample): Deleted. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch): (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq): (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq): (JSC::DFG::SpeculativeJIT::emitCall): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch): (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq): (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq): (JSC::DFG::SpeculativeJIT::emitCall): (JSC::DFG::SpeculativeJIT::compile): (JSC::DFG::SpeculativeJIT::convertAnyInt): 2017-05-19 Ryan Haddad Unreviewed, rolling out r217156. This change broke the iOS build. Reverted changeset: "DFG::SpeculativeJIT::pickCanTrample() is wrongly ignoring result registers." https://bugs.webkit.org/show_bug.cgi?id=172383 http://trac.webkit.org/changeset/217156 2017-05-19 Mark Lam Add missing exception check. https://bugs.webkit.org/show_bug.cgi?id=172346 Reviewed by Geoffrey Garen. * runtime/JSObject.cpp: (JSC::JSObject::hasInstance): 2017-05-19 Mark Lam DFG::SpeculativeJIT::pickCanTrample() is wrongly ignoring result registers. https://bugs.webkit.org/show_bug.cgi?id=172383 Reviewed by Filip Pizlo. pickCanTrample() is wrongly assuming that one of regT0 and regT1 is always available as a scratch register. This assumption is wrong if this canTrample register is used for a silentFill() after an operation that returns a result in regT0 or regT1. Turns out the only reason we need the canTrample register is for SetDoubleConstant. We can remove the need for this canTrample register by introducing a moveDouble() pseudo instruction in the MacroAssembler to do the job using the scratchRegister() on X86_64 or the dataMemoryTempRegister() on ARM64. In so doing, we can simplify the silentFill() code and eliminate the bug. * assembler/MacroAssembler.h: (JSC::MacroAssembler::moveDouble): * dfg/DFGArrayifySlowPathGenerator.h: * dfg/DFGCallArrayAllocatorSlowPathGenerator.h: (JSC::DFG::CallArrayAllocatorWithVariableStructureVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableStructureVariableSizeSlowPathGenerator): * dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h: * dfg/DFGSaneStringGetByValSlowPathGenerator.h: * dfg/DFGSlowPathGenerator.h: (JSC::DFG::CallSlowPathGenerator::tearDown): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::silentFill): (JSC::DFG::SpeculativeJIT::compileToLowerCase): (JSC::DFG::SpeculativeJIT::compileValueToInt32): (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject): (JSC::DFG::SpeculativeJIT::emitUntypedBitOp): (JSC::DFG::SpeculativeJIT::emitUntypedRightShiftBitOp): (JSC::DFG::SpeculativeJIT::compileArithDiv): (JSC::DFG::SpeculativeJIT::compileArraySlice): (JSC::DFG::SpeculativeJIT::emitSwitchImm): (JSC::DFG::SpeculativeJIT::emitSwitchStringOnString): (JSC::DFG::SpeculativeJIT::compileStoreBarrier): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::silentFill): (JSC::DFG::SpeculativeJIT::silentSpillAllRegisters): (JSC::DFG::SpeculativeJIT::silentFillAllRegisters): (JSC::DFG::SpeculativeJIT::pickCanTrample): Deleted. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch): (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq): (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq): (JSC::DFG::SpeculativeJIT::emitCall): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch): (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq): (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq): (JSC::DFG::SpeculativeJIT::emitCall): (JSC::DFG::SpeculativeJIT::compile): (JSC::DFG::SpeculativeJIT::convertAnyInt): 2017-05-19 Filip Pizlo Deduplicate some code in arrayProtoPrivateFuncConcatMemcpy https://bugs.webkit.org/show_bug.cgi?id=172382 Reviewed by Saam Barati. This is just a small clean-up - my last patch here created some unnecessary code duplication. * runtime/ArrayPrototype.cpp: (JSC::arrayProtoPrivateFuncConcatMemcpy): 2017-05-19 Filip Pizlo arrayProtoPrivateFuncConcatMemcpy needs to be down with firstArray being undecided https://bugs.webkit.org/show_bug.cgi?id=172369 Reviewed by Mark Lam. * heap/Subspace.cpp: Reshaped the code a bit to aid debugging. (JSC::Subspace::allocate): (JSC::Subspace::tryAllocate): * runtime/ArrayPrototype.cpp: (JSC::arrayProtoPrivateFuncConcatMemcpy): Fix the bug! * runtime/ObjectInitializationScope.cpp: Provide even better feedback. (JSC::ObjectInitializationScope::verifyPropertiesAreInitialized): 2017-05-18 Filip Pizlo B3::Value::effects() says that having a fence range implies the fence bit, but on x86_64 we lower loadAcq/storeRel to load/store so the store-before-load fence bit orderings won't be honored https://bugs.webkit.org/show_bug.cgi?id=172306 Reviewed by Michael Saboff. This changes B3 to emit xchg and its variants for fenced stores on x86. This ensures that fenced stores cannot be reordered around other fenced instructions. Previously, B3 emitted normal store instructions for fenced stores. That's wrong because then you get reorderings that are possible in TSO but impossible in SC. Fenced instructions are supposed to be SC with respect for each other. This is imprecise. If you really just wanted a store-release, then every X86 store does this. But, in B3, fenced stores are ARM-style store-release, meaning that they are fenced with respect to all other fences. If we ever did want to say that something is a store release in the traditional sense, then we'd want MemoryValue to have a fence flag. Then, having a fence range without the fence flag would mean the traditional store-release, which lowers to a normal store on x86. But to my knowledge, that traditional store-release is only useful for unlocking spinlocks. We don't use spinlocks in JSC. Adaptive locks require CAS for unlock, and B3 CAS is plenty fast. I think it's OK to have this small imprecision of giving clients an ARM-style store-release on x86 using xchg. The implication of this change is that the FTL no longer violates the SAB memory model. * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::xchg8): (JSC::MacroAssemblerX86Common::xchg16): (JSC::MacroAssemblerX86Common::xchg32): (JSC::MacroAssemblerX86Common::loadAcq8): Deleted. (JSC::MacroAssemblerX86Common::loadAcq8SignedExtendTo32): Deleted. (JSC::MacroAssemblerX86Common::loadAcq16): Deleted. (JSC::MacroAssemblerX86Common::loadAcq16SignedExtendTo32): Deleted. (JSC::MacroAssemblerX86Common::loadAcq32): Deleted. (JSC::MacroAssemblerX86Common::storeRel8): Deleted. (JSC::MacroAssemblerX86Common::storeRel16): Deleted. (JSC::MacroAssemblerX86Common::storeRel32): Deleted. * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::xchg64): (JSC::MacroAssemblerX86_64::loadAcq64): Deleted. (JSC::MacroAssemblerX86_64::storeRel64): Deleted. * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::ArgPromise::inst): (JSC::B3::Air::LowerToAir::trappingInst): (JSC::B3::Air::LowerToAir::tryAppendStoreBinOp): (JSC::B3::Air::LowerToAir::createStore): (JSC::B3::Air::LowerToAir::storeOpcode): (JSC::B3::Air::LowerToAir::appendStore): (JSC::B3::Air::LowerToAir::append): (JSC::B3::Air::LowerToAir::appendTrapping): (JSC::B3::Air::LowerToAir::fillStackmap): (JSC::B3::Air::LowerToAir::lower): * b3/air/AirKind.cpp: (JSC::B3::Air::Kind::dump): * b3/air/AirKind.h: (JSC::B3::Air::Kind::Kind): (JSC::B3::Air::Kind::operator==): (JSC::B3::Air::Kind::hash): * b3/air/AirLowerAfterRegAlloc.cpp: (JSC::B3::Air::lowerAfterRegAlloc): * b3/air/AirLowerMacros.cpp: (JSC::B3::Air::lowerMacros): * b3/air/AirOpcode.opcodes: * b3/air/AirValidate.cpp: * b3/air/opcode_generator.rb: * b3/testb3.cpp: (JSC::B3::correctSqrt): (JSC::B3::testSqrtArg): (JSC::B3::testSqrtImm): (JSC::B3::testSqrtMem): (JSC::B3::testSqrtArgWithUselessDoubleConversion): (JSC::B3::testSqrtArgWithEffectfulDoubleConversion): (JSC::B3::testStoreRelAddLoadAcq32): (JSC::B3::testTrappingLoad): (JSC::B3::testTrappingStore): (JSC::B3::testTrappingLoadAddStore): (JSC::B3::testTrappingLoadDCE): 2017-05-19 Don Olmstead [JSC] Remove PLATFORM(WIN) references https://bugs.webkit.org/show_bug.cgi?id=172294 Reviewed by Yusuke Suzuki. * heap/MachineStackMarker.cpp: (JSC::MachineThreads::removeThread): * llint/LLIntOfflineAsmConfig.h: * runtime/ConfigFile.h: * runtime/VM.cpp: (JSC::VM::updateStackLimits): 2017-05-19 Yusuke Suzuki [JSC][DFG][DOMJIT] Extend CheckDOM to CheckSubClass https://bugs.webkit.org/show_bug.cgi?id=172098 Reviewed by Saam Barati. In this patch, we generalize CheckDOM to CheckSubClass. It can accept any ClassInfo and perform ClassInfo check in DFG / FTL. Now, we add a new function pointer to ClassInfo, checkSubClassPatchpoint. It can create DOMJIT patchpoint for that ClassInfo. It it natural that ClassInfo holds the way to emit DOMJIT::Patchpoint to perform CheckSubClass rather than having it in each DOMJIT getter / function signature annotation. One problem is that it enlarges the size of ClassInfo. But this is the best place to put this function pointer. By doing so, we can add a patchpoint for CheckSubClass in an non-intrusive manner: WebCore can inject patchpoints without interactive JSC. We still have a way to reduce the size of ClassInfo if we move ArrayBuffer related methods out to the other places. This patch touches many files because we add a new function pointer to ClassInfo. But they are basically mechanical change. * API/JSAPIWrapperObject.mm: * API/JSCallbackConstructor.cpp: * API/JSCallbackFunction.cpp: * API/JSCallbackObject.cpp: * API/ObjCCallbackFunction.mm: * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/CodeBlock.cpp: * bytecode/DOMJITAccessCasePatchpointParams.h: (JSC::DOMJITAccessCasePatchpointParams::DOMJITAccessCasePatchpointParams): * bytecode/EvalCodeBlock.cpp: * bytecode/FunctionCodeBlock.cpp: * bytecode/GetterSetterAccessCase.cpp: (JSC::GetterSetterAccessCase::emitDOMJITGetter): * bytecode/ModuleProgramCodeBlock.cpp: * bytecode/ProgramCodeBlock.cpp: * bytecode/UnlinkedCodeBlock.cpp: * bytecode/UnlinkedEvalCodeBlock.cpp: * bytecode/UnlinkedFunctionCodeBlock.cpp: * bytecode/UnlinkedFunctionExecutable.cpp: * bytecode/UnlinkedModuleProgramCodeBlock.cpp: * bytecode/UnlinkedProgramCodeBlock.cpp: * debugger/DebuggerScope.cpp: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleDOMJITGetter): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGDOMJITPatchpointParams.h: (JSC::DFG::DOMJITPatchpointParams::DOMJITPatchpointParams): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::attemptToMakeCallDOM): (JSC::DFG::FixupPhase::fixupCheckSubClass): (JSC::DFG::FixupPhase::fixupCheckDOM): Deleted. * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGNode.h: (JSC::DFG::Node::hasClassInfo): (JSC::DFG::Node::classInfo): (JSC::DFG::Node::hasCheckDOMPatchpoint): Deleted. (JSC::DFG::Node::checkDOMPatchpoint): Deleted. * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCheckSubClass): (JSC::DFG::SpeculativeJIT::compileCheckDOM): Deleted. * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::vm): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * domjit/DOMJITGetterSetter.h: * domjit/DOMJITPatchpointParams.h: (JSC::DOMJIT::PatchpointParams::PatchpointParams): (JSC::DOMJIT::PatchpointParams::vm): * domjit/DOMJITSignature.h: (JSC::DOMJIT::Signature::Signature): (JSC::DOMJIT::Signature::checkDOM): Deleted. * ftl/FTLAbstractHeapRepository.h: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLDOMJITPatchpointParams.h: (JSC::FTL::DOMJITPatchpointParams::DOMJITPatchpointParams): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass): (JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM): Deleted. * inspector/JSInjectedScriptHost.cpp: * inspector/JSInjectedScriptHostPrototype.cpp: * inspector/JSJavaScriptCallFrame.cpp: * inspector/JSJavaScriptCallFramePrototype.cpp: * jsc.cpp: (WTF::DOMJITNode::checkSubClassPatchpoint): (WTF::DOMJITFunctionObject::checkSubClassPatchpoint): (WTF::DOMJITFunctionObject::finishCreation): (WTF::DOMJITCheckSubClassObject::DOMJITCheckSubClassObject): (WTF::DOMJITCheckSubClassObject::createStructure): (WTF::DOMJITCheckSubClassObject::create): (WTF::DOMJITCheckSubClassObject::safeFunction): (WTF::DOMJITCheckSubClassObject::unsafeFunction): (WTF::DOMJITCheckSubClassObject::finishCreation): (GlobalObject::finishCreation): (functionCreateDOMJITCheckSubClassObject): (WTF::DOMJITNode::checkDOMJITNode): Deleted. (WTF::DOMJITFunctionObject::checkDOMJITNode): Deleted. * runtime/AbstractModuleRecord.cpp: * runtime/ArrayBufferNeuteringWatchpoint.cpp: * runtime/ArrayConstructor.cpp: * runtime/ArrayIteratorPrototype.cpp: * runtime/ArrayPrototype.cpp: * runtime/AsyncFunctionConstructor.cpp: * runtime/AsyncFunctionPrototype.cpp: * runtime/AtomicsObject.cpp: * runtime/BooleanConstructor.cpp: * runtime/BooleanObject.cpp: * runtime/BooleanPrototype.cpp: * runtime/ClassInfo.cpp: Copied from Source/JavaScriptCore/tools/JSDollarVM.cpp. (JSC::ClassInfo::dump): * runtime/ClassInfo.h: (JSC::ClassInfo::offsetOfParentClass): * runtime/ClonedArguments.cpp: * runtime/ConsoleObject.cpp: * runtime/CustomGetterSetter.cpp: * runtime/DateConstructor.cpp: * runtime/DateInstance.cpp: * runtime/DatePrototype.cpp: * runtime/DirectArguments.cpp: * runtime/Error.cpp: * runtime/ErrorConstructor.cpp: * runtime/ErrorInstance.cpp: * runtime/ErrorPrototype.cpp: * runtime/EvalExecutable.cpp: * runtime/Exception.cpp: * runtime/ExceptionHelpers.cpp: * runtime/ExecutableBase.cpp: * runtime/FunctionConstructor.cpp: * runtime/FunctionExecutable.cpp: * runtime/FunctionPrototype.cpp: * runtime/FunctionRareData.cpp: * runtime/GeneratorFunctionConstructor.cpp: * runtime/GeneratorFunctionPrototype.cpp: * runtime/GeneratorPrototype.cpp: * runtime/GetterSetter.cpp: * runtime/HashMapImpl.cpp: * runtime/HashMapImpl.h: * runtime/InferredType.cpp: (JSC::InferredType::create): * runtime/InferredTypeTable.cpp: * runtime/InferredValue.cpp: * runtime/InspectorInstrumentationObject.cpp: * runtime/InternalFunction.cpp: * runtime/IntlCollator.cpp: * runtime/IntlCollatorConstructor.cpp: * runtime/IntlCollatorPrototype.cpp: * runtime/IntlDateTimeFormat.cpp: * runtime/IntlDateTimeFormatConstructor.cpp: * runtime/IntlDateTimeFormatPrototype.cpp: * runtime/IntlNumberFormat.cpp: * runtime/IntlNumberFormatConstructor.cpp: * runtime/IntlNumberFormatPrototype.cpp: * runtime/IntlObject.cpp: * runtime/IteratorPrototype.cpp: * runtime/JSAPIValueWrapper.cpp: * runtime/JSArray.cpp: * runtime/JSArrayBuffer.cpp: * runtime/JSArrayBufferConstructor.cpp: * runtime/JSArrayBufferPrototype.cpp: * runtime/JSArrayBufferView.cpp: * runtime/JSAsyncFunction.cpp: * runtime/JSBoundFunction.cpp: * runtime/JSCallee.cpp: * runtime/JSCustomGetterSetterFunction.cpp: * runtime/JSDataView.cpp: * runtime/JSDataViewPrototype.cpp: * runtime/JSEnvironmentRecord.cpp: * runtime/JSFixedArray.cpp: * runtime/JSFunction.cpp: * runtime/JSGeneratorFunction.cpp: * runtime/JSGlobalLexicalEnvironment.cpp: * runtime/JSGlobalObject.cpp: * runtime/JSInternalPromise.cpp: * runtime/JSInternalPromiseConstructor.cpp: * runtime/JSInternalPromiseDeferred.cpp: * runtime/JSInternalPromisePrototype.cpp: * runtime/JSLexicalEnvironment.cpp: * runtime/JSMap.cpp: * runtime/JSMapIterator.cpp: * runtime/JSModuleEnvironment.cpp: * runtime/JSModuleLoader.cpp: * runtime/JSModuleNamespaceObject.cpp: * runtime/JSModuleRecord.cpp: * runtime/JSNativeStdFunction.cpp: * runtime/JSONObject.cpp: * runtime/JSObject.cpp: * runtime/JSPromise.cpp: * runtime/JSPromiseConstructor.cpp: * runtime/JSPromiseDeferred.cpp: * runtime/JSPromisePrototype.cpp: * runtime/JSPropertyNameEnumerator.cpp: * runtime/JSPropertyNameIterator.cpp: * runtime/JSProxy.cpp: * runtime/JSScriptFetcher.cpp: * runtime/JSSet.cpp: * runtime/JSSetIterator.cpp: * runtime/JSSourceCode.cpp: * runtime/JSString.cpp: * runtime/JSStringIterator.cpp: * runtime/JSSymbolTableObject.cpp: * runtime/JSTemplateRegistryKey.cpp: * runtime/JSTypedArrayConstructors.cpp: * runtime/JSTypedArrayPrototypes.cpp: * runtime/JSTypedArrayViewConstructor.cpp: * runtime/JSTypedArrays.cpp: * runtime/JSWeakMap.cpp: * runtime/JSWeakSet.cpp: * runtime/JSWithScope.cpp: * runtime/MapConstructor.cpp: * runtime/MapIteratorPrototype.cpp: * runtime/MapPrototype.cpp: * runtime/MathObject.cpp: * runtime/ModuleLoaderPrototype.cpp: * runtime/ModuleProgramExecutable.cpp: * runtime/NativeErrorConstructor.cpp: * runtime/NativeExecutable.cpp: * runtime/NativeStdFunctionCell.cpp: * runtime/NullGetterFunction.cpp: * runtime/NullSetterFunction.cpp: * runtime/NumberConstructor.cpp: * runtime/NumberObject.cpp: * runtime/NumberPrototype.cpp: * runtime/ObjectConstructor.cpp: * runtime/ObjectPrototype.cpp: * runtime/ProgramExecutable.cpp: * runtime/PropertyTable.cpp: * runtime/ProxyConstructor.cpp: * runtime/ProxyObject.cpp: * runtime/ProxyRevoke.cpp: * runtime/ReflectObject.cpp: * runtime/RegExp.cpp: * runtime/RegExpConstructor.cpp: * runtime/RegExpObject.cpp: * runtime/RegExpPrototype.cpp: * runtime/ScopedArguments.cpp: * runtime/ScopedArgumentsTable.cpp: * runtime/ScriptExecutable.cpp: * runtime/SetConstructor.cpp: * runtime/SetIteratorPrototype.cpp: * runtime/SetPrototype.cpp: * runtime/SparseArrayValueMap.cpp: * runtime/StrictEvalActivation.cpp: * runtime/StringConstructor.cpp: * runtime/StringIteratorPrototype.cpp: * runtime/StringObject.cpp: * runtime/StringPrototype.cpp: * runtime/Structure.cpp: * runtime/StructureChain.cpp: * runtime/StructureRareData.cpp: * runtime/Symbol.cpp: * runtime/SymbolConstructor.cpp: * runtime/SymbolObject.cpp: * runtime/SymbolPrototype.cpp: * runtime/SymbolTable.cpp: * runtime/WeakMapConstructor.cpp: * runtime/WeakMapData.cpp: * runtime/WeakMapPrototype.cpp: * runtime/WeakSetConstructor.cpp: * runtime/WeakSetPrototype.cpp: * testRegExp.cpp: * tools/JSDollarVM.cpp: * tools/JSDollarVMPrototype.cpp: * wasm/JSWebAssembly.cpp: * wasm/js/JSWebAssemblyCodeBlock.cpp: * wasm/js/JSWebAssemblyCompileError.cpp: * wasm/js/JSWebAssemblyInstance.cpp: * wasm/js/JSWebAssemblyLinkError.cpp: * wasm/js/JSWebAssemblyMemory.cpp: * wasm/js/JSWebAssemblyModule.cpp: * wasm/js/JSWebAssemblyRuntimeError.cpp: * wasm/js/JSWebAssemblyTable.cpp: * wasm/js/WebAssemblyCompileErrorConstructor.cpp: * wasm/js/WebAssemblyCompileErrorPrototype.cpp: * wasm/js/WebAssemblyFunction.cpp: * wasm/js/WebAssemblyFunctionBase.cpp: * wasm/js/WebAssemblyInstanceConstructor.cpp: * wasm/js/WebAssemblyInstancePrototype.cpp: * wasm/js/WebAssemblyLinkErrorConstructor.cpp: * wasm/js/WebAssemblyLinkErrorPrototype.cpp: * wasm/js/WebAssemblyMemoryConstructor.cpp: * wasm/js/WebAssemblyMemoryPrototype.cpp: * wasm/js/WebAssemblyModuleConstructor.cpp: * wasm/js/WebAssemblyModulePrototype.cpp: * wasm/js/WebAssemblyModuleRecord.cpp: * wasm/js/WebAssemblyPrototype.cpp: * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp: * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp: * wasm/js/WebAssemblyTableConstructor.cpp: * wasm/js/WebAssemblyTablePrototype.cpp: * wasm/js/WebAssemblyToJSCallee.cpp: * wasm/js/WebAssemblyWrapperFunction.cpp: 2017-05-18 JF Bastien WebAssembly: exports is a getter https://bugs.webkit.org/show_bug.cgi?id=172129 Reviewed by Saam Barati. As updated here: https://github.com/WebAssembly/design/pull/1062 * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::finishCreation): don't putDirect here anymore * wasm/js/JSWebAssemblyInstance.h: (JSC::JSWebAssemblyInstance::moduleNamespaceObject): add accessor * wasm/js/WebAssemblyFunctionBase.cpp: squelch causing a warning * wasm/js/WebAssemblyInstancePrototype.cpp: use LUT (JSC::getInstance): helper, as in surrounding files (JSC::webAssemblyInstanceProtoFuncExports): instead of putDirect * wasm/js/WebAssemblyMemoryPrototype.cpp: pass VM around as for Table (JSC::getMemory): (JSC::webAssemblyMemoryProtoFuncGrow): (JSC::webAssemblyMemoryProtoFuncBuffer): * wasm/js/WebAssemblyTablePrototype.cpp: static everywhere as with other code (JSC::webAssemblyTableProtoFuncLength): (JSC::webAssemblyTableProtoFuncGrow): (JSC::webAssemblyTableProtoFuncGet): (JSC::webAssemblyTableProtoFuncSet): 2017-05-18 Saam Barati Proxy's [[Get]] passes incorrect receiver https://bugs.webkit.org/show_bug.cgi?id=164849 Reviewed by Yusuke Suzuki. * runtime/ProxyObject.cpp: (JSC::performProxyGet): 2017-05-18 Andy Estes ENABLE(APPLE_PAY_DELEGATE) should be NO on macOS Sierra and earlier https://bugs.webkit.org/show_bug.cgi?id=172305 Reviewed by Anders Carlsson. * Configurations/FeatureDefines.xcconfig: 2017-05-18 Saam Barati We need to destroy worker threads in jsc.cpp https://bugs.webkit.org/show_bug.cgi?id=170751 Reviewed by Filip Pizlo. This patch fixes a bug where a $ agent worker would still have compilation threads running after the thread the worker was created on dies. This manifested itself inside DFG AI where we would notice a string constant is atomic, then the worker thread would die, destroying its atomic string table, then we'd notice the same string is no longer atomic, and we'd crash because we'd fail to see the same speculated type for the same JSValue. This patch makes it so that $ agent workers destroy their VM when they're done executing. Before a VM gets destroyed, it ensures that all its compilation threads finish. * jsc.cpp: (functionDollarAgentStart): (runJSC): (jscmain): 2017-05-18 Michael Saboff Add FTL whitelist debugging option https://bugs.webkit.org/show_bug.cgi?id=172321 Reviewed by Saam Barati. * dfg/DFGTierUpCheckInjectionPhase.cpp: (JSC::DFG::ensureGlobalFTLWhitelist): (JSC::DFG::TierUpCheckInjectionPhase::run): * runtime/Options.h: * tools/FunctionWhitelist.cpp: (JSC::FunctionWhitelist::contains): 2017-05-18 Filip Pizlo Constructor calls set this too early https://bugs.webkit.org/show_bug.cgi?id=172302 Reviewed by Saam Barati. We were setting this before evaluating the arguments, so this code: var x = 42; new x(x = function() { }); Would crash because we would pass 42 as this, and create_this would treat it as a cell. Dereferencing a non-cell is guaranteed to crash. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitConstruct): * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::NewExprNode::emitBytecode): (JSC::FunctionCallValueNode::emitBytecode): 2017-05-18 Saam Barati WebAssembly: perform stack checks https://bugs.webkit.org/show_bug.cgi?id=165546 Reviewed by Filip Pizlo. This patch adds stack checks to wasm. It implements it by storing the stack bounds on the Context. Stack checking works as normal, except we do a small optimization for terminal nodes in the call tree (nodes that don't make any calls). These nodes will only do a stack check if their frame size is beyond 1024 bytes. Otherwise, it's assumed the parent that called them did their stack check for them. This is because all things that make calls make sure to do an extra 1024 bytes whenever doing a stack check. We also take into account stack size for potential JS calls when doing stack checks since our JS stubs don't do this on their own. Each frame will ensure it does a stack check large enough for any potential JS call stubs it'll execute. Surprisingly, this patch is neutral on WasmBench and TitzerBench. * llint/LLIntData.cpp: (JSC::LLInt::Data::performAssertions): * llint/LowLevelInterpreter.asm: * runtime/Error.cpp: (JSC::createRangeError): (JSC::addErrorInfoAndGetBytecodeOffset): I fixed a bug here where we assumed that the first frame that has line and column info would be in our stack trace. This is not correct since we limit our stack trace size. If everything in our limited size stack trace is Wasm, then we won't have any frames with line and column info. * runtime/Error.h: * runtime/ExceptionHelpers.cpp: (JSC::createStackOverflowError): * runtime/ExceptionHelpers.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildren): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::webAssemblyToJSCalleeStructure): * runtime/JSType.h: * runtime/Options.h: I've added a new option that controls whether or not we use fast TLS for the wasm context. * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::B3IRGenerator): * wasm/WasmBinding.cpp: (JSC::Wasm::wasmToWasm): * wasm/WasmContext.cpp: (JSC::Wasm::loadContext): (JSC::Wasm::storeContext): * wasm/WasmContext.h: (JSC::Wasm::useFastTLSForContext): * wasm/WasmExceptionType.h: * wasm/WasmMemoryInformation.h: (JSC::Wasm::PinnedRegisterInfo::toSave): * wasm/WasmThunks.cpp: (JSC::Wasm::throwExceptionFromWasmThunkGenerator): (JSC::Wasm::throwStackOverflowFromWasmThunkGenerator): (JSC::Wasm::Thunks::stub): * wasm/WasmThunks.h: * wasm/js/JSWebAssemblyInstance.h: (JSC::JSWebAssemblyInstance::offsetOfCachedStackLimit): (JSC::JSWebAssemblyInstance::cachedStackLimit): (JSC::JSWebAssemblyInstance::setCachedStackLimit): * wasm/js/JSWebAssemblyModule.cpp: (JSC::JSWebAssemblyModule::finishCreation): * wasm/js/WebAssemblyFunction.cpp: (JSC::callWebAssemblyFunction): * wasm/js/WebAssemblyToJSCallee.cpp: Make this a descendent of object. This is needed for correctness because we may call into JS, and then the first JS frame could stack overflow. When it stack overflows, it rolls back one frame to the wasm->js call stub with the wasm->js callee. It gets the lexical global object from this frame, meaning it gets the global object from the callee. Therefore, we must make it an object since all objects have global objects. (JSC::WebAssemblyToJSCallee::create): * wasm/js/WebAssemblyToJSCallee.h: 2017-05-18 Keith Miller WebAssembly API: test with neutered inputs https://bugs.webkit.org/show_bug.cgi?id=163899 Reviewed by JF Bastien. Add tests to check that we properly throw a type error when we get a transferred ArrayBuffer. Also, we should make sure we cannot post message a wasm memory's ArrayBuffer. * API/JSTypedArray.cpp: (JSObjectGetArrayBufferBytesPtr): * runtime/ArrayBuffer.cpp: (JSC::ArrayBuffer::makeShared): (JSC::ArrayBuffer::makeWasmMemory): (JSC::ArrayBuffer::transferTo): (JSC::ArrayBuffer::neuter): (JSC::ArrayBuffer::notifyIncommingReferencesOfTransfer): (JSC::errorMesasgeForTransfer): * runtime/ArrayBuffer.h: (JSC::ArrayBuffer::isLocked): (JSC::ArrayBuffer::isWasmMemory): * wasm/js/JSWebAssemblyMemory.cpp: (JSC::JSWebAssemblyMemory::buffer): (JSC::JSWebAssemblyMemory::grow): 2017-05-18 Joseph Pecoraro Remote Inspector: Be stricter about checking message types https://bugs.webkit.org/show_bug.cgi?id=172259 Reviewed by Brian Burg. * inspector/remote/cocoa/RemoteInspectorCocoa.mm: (Inspector::RemoteInspector::receivedSetupMessage): (Inspector::RemoteInspector::receivedDataMessage): (Inspector::RemoteInspector::receivedDidCloseMessage): (Inspector::RemoteInspector::receivedIndicateMessage): (Inspector::RemoteInspector::receivedConnectionDiedMessage): (Inspector::RemoteInspector::receivedAutomaticInspectionConfigurationMessage): (Inspector::RemoteInspector::receivedAutomaticInspectionRejectMessage): (Inspector::RemoteInspector::receivedAutomationSessionRequestMessage): * inspector/remote/cocoa/RemoteInspectorXPCConnection.mm: (Inspector::RemoteInspectorXPCConnection::deserializeMessage): (Inspector::RemoteInspectorXPCConnection::handleEvent): (Inspector::RemoteInspectorXPCConnection::sendMessage): Bail if we don't receive the expected types for message data. 2017-05-18 Filip Pizlo DFG inlining should be hardened for the no-result case https://bugs.webkit.org/show_bug.cgi?id=172290 Reviewed by Saam Barati. Previously, if we were inlining a setter call, we might have a bad time because the setter's result register is the invalid VirtualRegister(), and much of the intrinsic handling code assumes that the result register is valid. This doesn't usually cause problems because people don't usually point a setter at something that we recognize as an intrinsic. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp: Fix a comment. * dfg/DFGByteCodeParser.cpp: Make RELEASE_ASSERT give accurate stacks. I was getting an absurd stack from the assert I added in DelayedSetLocal. (JSC::DFG::ByteCodeParser::DelayedSetLocal::DelayedSetLocal): Assert so we catch the problem sooner. (JSC::DFG::ByteCodeParser::handleIntrinsicCall): Fix the bug. (JSC::DFG::ByteCodeParser::handleConstantInternalFunction): Fix the bug if constant internal functions were setter-inlineable (they ain't, because the bytecode parser doesn't fold GetSetter). * runtime/Intrinsic.cpp: Added. I needed this to debug. (JSC::intrinsicName): (WTF::printInternal): * runtime/Intrinsic.h: 2017-05-18 Commit Queue Unreviewed, rolling out r217031, r217032, and r217037. https://bugs.webkit.org/show_bug.cgi?id=172293 cause linking errors in Windows (Requested by yusukesuzuki on #webkit). Reverted changesets: "[JSC][DFG][DOMJIT] Extend CheckDOM to CheckSubClass" https://bugs.webkit.org/show_bug.cgi?id=172098 http://trac.webkit.org/changeset/217031 "Unreviewed, rebaseline for newly added ClassInfo" https://bugs.webkit.org/show_bug.cgi?id=172098 http://trac.webkit.org/changeset/217032 "Unreviewed, fix debug and non-JIT build" https://bugs.webkit.org/show_bug.cgi?id=172098 http://trac.webkit.org/changeset/217037 2017-05-17 Yusuke Suzuki Unreviewed, fix debug and non-JIT build https://bugs.webkit.org/show_bug.cgi?id=172098 * jsc.cpp: (WTF::DOMJITFunctionObject::checkSubClassPatchpoint): 2017-05-17 Yusuke Suzuki Unreviewed, rebaseline for newly added ClassInfo https://bugs.webkit.org/show_bug.cgi?id=172098 * wasm/js/WebAssemblyFunctionBase.cpp: 2017-05-16 Yusuke Suzuki [JSC][DFG][DOMJIT] Extend CheckDOM to CheckSubClass https://bugs.webkit.org/show_bug.cgi?id=172098 Reviewed by Saam Barati. In this patch, we generalize CheckDOM to CheckSubClass. It can accept any ClassInfo and perform ClassInfo check in DFG / FTL. Now, we add a new function pointer to ClassInfo, checkSubClassPatchpoint. It can create DOMJIT patchpoint for that ClassInfo. It it natural that ClassInfo holds the way to emit DOMJIT::Patchpoint to perform CheckSubClass rather than having it in each DOMJIT getter / function signature annotation. One problem is that it enlarges the size of ClassInfo. But this is the best place to put this function pointer. By doing so, we can add a patchpoint for CheckSubClass in an non-intrusive manner: WebCore can inject patchpoints without interactive JSC. We still have a way to reduce the size of ClassInfo if we move ArrayBuffer related methods out to the other places. This patch touches many files because we add a new function pointer to ClassInfo. But they are basically mechanical change. * API/JSAPIWrapperObject.mm: * API/JSCallbackConstructor.cpp: * API/JSCallbackFunction.cpp: * API/JSCallbackObject.cpp: * API/ObjCCallbackFunction.mm: * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/CodeBlock.cpp: * bytecode/DOMJITAccessCasePatchpointParams.h: (JSC::DOMJITAccessCasePatchpointParams::DOMJITAccessCasePatchpointParams): * bytecode/EvalCodeBlock.cpp: * bytecode/FunctionCodeBlock.cpp: * bytecode/GetterSetterAccessCase.cpp: (JSC::GetterSetterAccessCase::emitDOMJITGetter): * bytecode/ModuleProgramCodeBlock.cpp: * bytecode/ProgramCodeBlock.cpp: * bytecode/UnlinkedCodeBlock.cpp: * bytecode/UnlinkedEvalCodeBlock.cpp: * bytecode/UnlinkedFunctionCodeBlock.cpp: * bytecode/UnlinkedFunctionExecutable.cpp: * bytecode/UnlinkedModuleProgramCodeBlock.cpp: * bytecode/UnlinkedProgramCodeBlock.cpp: * debugger/DebuggerScope.cpp: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleDOMJITGetter): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGDOMJITPatchpointParams.h: (JSC::DFG::DOMJITPatchpointParams::DOMJITPatchpointParams): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::attemptToMakeCallDOM): (JSC::DFG::FixupPhase::fixupCheckSubClass): (JSC::DFG::FixupPhase::fixupCheckDOM): Deleted. * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGNode.h: (JSC::DFG::Node::hasClassInfo): (JSC::DFG::Node::classInfo): (JSC::DFG::Node::hasCheckDOMPatchpoint): Deleted. (JSC::DFG::Node::checkDOMPatchpoint): Deleted. * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCheckSubClass): (JSC::DFG::SpeculativeJIT::compileCheckDOM): Deleted. * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::vm): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): In DFG, we rename CheckDOM to CheckSubClass. It just holds ClassInfo. And ClassInfo knows how to perform CheckSubClass efficiently. If ClassInfo does not have a way to perform CheckSubClass efficiently, we just perform jsDynamicCast thing in ASM. * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * domjit/DOMJITGetterSetter.h: * domjit/DOMJITPatchpointParams.h: (JSC::DOMJIT::PatchpointParams::PatchpointParams): (JSC::DOMJIT::PatchpointParams::vm): * domjit/DOMJITSignature.h: (JSC::DOMJIT::Signature::Signature): (JSC::DOMJIT::Signature::checkDOM): Deleted. * ftl/FTLAbstractHeapRepository.h: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLDOMJITPatchpointParams.h: (JSC::FTL::DOMJITPatchpointParams::DOMJITPatchpointParams): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass): (JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM): Deleted. * inspector/JSInjectedScriptHost.cpp: * inspector/JSInjectedScriptHostPrototype.cpp: * inspector/JSJavaScriptCallFrame.cpp: * inspector/JSJavaScriptCallFramePrototype.cpp: * jsc.cpp: (WTF::DOMJITNode::checkSubClassPatchpoint): (WTF::DOMJITFunctionObject::checkSubClassPatchpoint): (WTF::DOMJITFunctionObject::finishCreation): (WTF::DOMJITCheckSubClassObject::DOMJITCheckSubClassObject): (WTF::DOMJITCheckSubClassObject::createStructure): (WTF::DOMJITCheckSubClassObject::create): (WTF::DOMJITCheckSubClassObject::safeFunction): (WTF::DOMJITCheckSubClassObject::unsafeFunction): (WTF::DOMJITCheckSubClassObject::finishCreation): (GlobalObject::finishCreation): (functionCreateDOMJITCheckSubClassObject): (WTF::DOMJITNode::checkDOMJITNode): Deleted. (WTF::DOMJITFunctionObject::checkDOMJITNode): Deleted. * runtime/AbstractModuleRecord.cpp: * runtime/ArrayBufferNeuteringWatchpoint.cpp: * runtime/ArrayConstructor.cpp: * runtime/ArrayIteratorPrototype.cpp: * runtime/ArrayPrototype.cpp: * runtime/AsyncFunctionConstructor.cpp: * runtime/AsyncFunctionPrototype.cpp: * runtime/AtomicsObject.cpp: * runtime/BooleanConstructor.cpp: * runtime/BooleanObject.cpp: * runtime/BooleanPrototype.cpp: * runtime/ClassInfo.cpp: Copied from Source/JavaScriptCore/tools/JSDollarVM.cpp. (JSC::ClassInfo::dump): * runtime/ClassInfo.h: (JSC::ClassInfo::offsetOfParentClass): * runtime/ClonedArguments.cpp: * runtime/ConsoleObject.cpp: * runtime/CustomGetterSetter.cpp: * runtime/DateConstructor.cpp: * runtime/DateInstance.cpp: * runtime/DatePrototype.cpp: * runtime/DirectArguments.cpp: * runtime/Error.cpp: * runtime/ErrorConstructor.cpp: * runtime/ErrorInstance.cpp: * runtime/ErrorPrototype.cpp: * runtime/EvalExecutable.cpp: * runtime/Exception.cpp: * runtime/ExceptionHelpers.cpp: * runtime/ExecutableBase.cpp: * runtime/FunctionConstructor.cpp: * runtime/FunctionExecutable.cpp: * runtime/FunctionPrototype.cpp: * runtime/FunctionRareData.cpp: * runtime/GeneratorFunctionConstructor.cpp: * runtime/GeneratorFunctionPrototype.cpp: * runtime/GeneratorPrototype.cpp: * runtime/GetterSetter.cpp: * runtime/HashMapImpl.cpp: * runtime/HashMapImpl.h: * runtime/InferredType.cpp: (JSC::InferredType::create): * runtime/InferredTypeTable.cpp: * runtime/InferredValue.cpp: * runtime/InspectorInstrumentationObject.cpp: * runtime/InternalFunction.cpp: * runtime/IntlCollator.cpp: * runtime/IntlCollatorConstructor.cpp: * runtime/IntlCollatorPrototype.cpp: * runtime/IntlDateTimeFormat.cpp: * runtime/IntlDateTimeFormatConstructor.cpp: * runtime/IntlDateTimeFormatPrototype.cpp: * runtime/IntlNumberFormat.cpp: * runtime/IntlNumberFormatConstructor.cpp: * runtime/IntlNumberFormatPrototype.cpp: * runtime/IntlObject.cpp: * runtime/IteratorPrototype.cpp: * runtime/JSAPIValueWrapper.cpp: * runtime/JSArray.cpp: * runtime/JSArrayBuffer.cpp: * runtime/JSArrayBufferConstructor.cpp: * runtime/JSArrayBufferPrototype.cpp: * runtime/JSArrayBufferView.cpp: * runtime/JSAsyncFunction.cpp: * runtime/JSBoundFunction.cpp: * runtime/JSCallee.cpp: * runtime/JSCustomGetterSetterFunction.cpp: * runtime/JSDataView.cpp: * runtime/JSDataViewPrototype.cpp: * runtime/JSEnvironmentRecord.cpp: * runtime/JSFixedArray.cpp: * runtime/JSFunction.cpp: * runtime/JSGeneratorFunction.cpp: * runtime/JSGlobalLexicalEnvironment.cpp: * runtime/JSGlobalObject.cpp: * runtime/JSInternalPromise.cpp: * runtime/JSInternalPromiseConstructor.cpp: * runtime/JSInternalPromiseDeferred.cpp: * runtime/JSInternalPromisePrototype.cpp: * runtime/JSLexicalEnvironment.cpp: * runtime/JSMap.cpp: * runtime/JSMapIterator.cpp: * runtime/JSModuleEnvironment.cpp: * runtime/JSModuleLoader.cpp: * runtime/JSModuleNamespaceObject.cpp: * runtime/JSModuleRecord.cpp: * runtime/JSNativeStdFunction.cpp: * runtime/JSONObject.cpp: * runtime/JSObject.cpp: * runtime/JSPromise.cpp: * runtime/JSPromiseConstructor.cpp: * runtime/JSPromiseDeferred.cpp: * runtime/JSPromisePrototype.cpp: * runtime/JSPropertyNameEnumerator.cpp: * runtime/JSPropertyNameIterator.cpp: * runtime/JSProxy.cpp: * runtime/JSScriptFetcher.cpp: * runtime/JSSet.cpp: * runtime/JSSetIterator.cpp: * runtime/JSSourceCode.cpp: * runtime/JSString.cpp: * runtime/JSStringIterator.cpp: * runtime/JSSymbolTableObject.cpp: * runtime/JSTemplateRegistryKey.cpp: * runtime/JSTypedArrayConstructors.cpp: * runtime/JSTypedArrayPrototypes.cpp: * runtime/JSTypedArrayViewConstructor.cpp: * runtime/JSTypedArrays.cpp: * runtime/JSWeakMap.cpp: * runtime/JSWeakSet.cpp: * runtime/JSWithScope.cpp: * runtime/MapConstructor.cpp: * runtime/MapIteratorPrototype.cpp: * runtime/MapPrototype.cpp: * runtime/MathObject.cpp: * runtime/ModuleLoaderPrototype.cpp: * runtime/ModuleProgramExecutable.cpp: * runtime/NativeErrorConstructor.cpp: * runtime/NativeExecutable.cpp: * runtime/NativeStdFunctionCell.cpp: * runtime/NullGetterFunction.cpp: * runtime/NullSetterFunction.cpp: * runtime/NumberConstructor.cpp: * runtime/NumberObject.cpp: * runtime/NumberPrototype.cpp: * runtime/ObjectConstructor.cpp: * runtime/ObjectPrototype.cpp: * runtime/ProgramExecutable.cpp: * runtime/PropertyTable.cpp: * runtime/ProxyConstructor.cpp: * runtime/ProxyObject.cpp: * runtime/ProxyRevoke.cpp: * runtime/ReflectObject.cpp: * runtime/RegExp.cpp: * runtime/RegExpConstructor.cpp: * runtime/RegExpObject.cpp: * runtime/RegExpPrototype.cpp: * runtime/ScopedArguments.cpp: * runtime/ScopedArgumentsTable.cpp: * runtime/ScriptExecutable.cpp: * runtime/SetConstructor.cpp: * runtime/SetIteratorPrototype.cpp: * runtime/SetPrototype.cpp: * runtime/SparseArrayValueMap.cpp: * runtime/StrictEvalActivation.cpp: * runtime/StringConstructor.cpp: * runtime/StringIteratorPrototype.cpp: * runtime/StringObject.cpp: * runtime/StringPrototype.cpp: * runtime/Structure.cpp: * runtime/StructureChain.cpp: * runtime/StructureRareData.cpp: * runtime/Symbol.cpp: * runtime/SymbolConstructor.cpp: * runtime/SymbolObject.cpp: * runtime/SymbolPrototype.cpp: * runtime/SymbolTable.cpp: * runtime/WeakMapConstructor.cpp: * runtime/WeakMapData.cpp: * runtime/WeakMapPrototype.cpp: * runtime/WeakSetConstructor.cpp: * runtime/WeakSetPrototype.cpp: * testRegExp.cpp: * tools/JSDollarVM.cpp: * tools/JSDollarVMPrototype.cpp: * wasm/JSWebAssembly.cpp: * wasm/js/JSWebAssemblyCodeBlock.cpp: * wasm/js/JSWebAssemblyCompileError.cpp: * wasm/js/JSWebAssemblyInstance.cpp: * wasm/js/JSWebAssemblyLinkError.cpp: * wasm/js/JSWebAssemblyMemory.cpp: * wasm/js/JSWebAssemblyModule.cpp: * wasm/js/JSWebAssemblyRuntimeError.cpp: * wasm/js/JSWebAssemblyTable.cpp: * wasm/js/WebAssemblyCompileErrorConstructor.cpp: * wasm/js/WebAssemblyCompileErrorPrototype.cpp: * wasm/js/WebAssemblyFunction.cpp: * wasm/js/WebAssemblyInstanceConstructor.cpp: * wasm/js/WebAssemblyInstancePrototype.cpp: * wasm/js/WebAssemblyLinkErrorConstructor.cpp: * wasm/js/WebAssemblyLinkErrorPrototype.cpp: * wasm/js/WebAssemblyMemoryConstructor.cpp: * wasm/js/WebAssemblyMemoryPrototype.cpp: * wasm/js/WebAssemblyModuleConstructor.cpp: * wasm/js/WebAssemblyModulePrototype.cpp: * wasm/js/WebAssemblyModuleRecord.cpp: * wasm/js/WebAssemblyPrototype.cpp: * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp: * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp: * wasm/js/WebAssemblyTableConstructor.cpp: * wasm/js/WebAssemblyTablePrototype.cpp: * wasm/js/WebAssemblyToJSCallee.cpp: * wasm/js/WebAssemblyWrapperFunction.cpp: 2017-05-17 Saam Barati We don't do context switches for Wasm->Wasm call indirect https://bugs.webkit.org/show_bug.cgi?id=172188 Reviewed by Keith Miller. We did not do a context switch when doing an indirect call. This is clearly wrong, since the thing we're making an indirect call to could be from another instance. This patch fixes this oversight by doing a very simple context switch. I've also opened a bug to make indirect calls fast: https://bugs.webkit.org/show_bug.cgi?id=172197 since this patch adds yet another branch to the indirect call path. I've also added tests that either throw or crash before this change. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * wasm/WasmB3IRGenerator.cpp: * wasm/js/JSWebAssemblyTable.h: (JSC::JSWebAssemblyTable::offsetOfJSFunctions): * wasm/js/WebAssemblyFunction.cpp: (JSC::WebAssemblyFunction::visitChildren): (JSC::WebAssemblyFunction::finishCreation): Deleted. * wasm/js/WebAssemblyFunction.h: (JSC::WebAssemblyFunction::instance): Deleted. (JSC::WebAssemblyFunction::offsetOfInstance): Deleted. * wasm/js/WebAssemblyFunctionBase.cpp: Added. (JSC::WebAssemblyFunctionBase::WebAssemblyFunctionBase): (JSC::WebAssemblyFunctionBase::visitChildren): (JSC::WebAssemblyFunctionBase::finishCreation): * wasm/js/WebAssemblyFunctionBase.h: Added. (JSC::WebAssemblyFunctionBase::instance): (JSC::WebAssemblyFunctionBase::offsetOfInstance): * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::link): (JSC::WebAssemblyModuleRecord::evaluate): * wasm/js/WebAssemblyWrapperFunction.cpp: (JSC::WebAssemblyWrapperFunction::create): (JSC::WebAssemblyWrapperFunction::finishCreation): (JSC::WebAssemblyWrapperFunction::visitChildren): * wasm/js/WebAssemblyWrapperFunction.h: 2017-05-17 Filip Pizlo JSC: Incorrect LoadVarargs handling in ArgumentsEliminationPhase::transform https://bugs.webkit.org/show_bug.cgi?id=172208 Reviewed by Saam Barati. * dfg/DFGArgumentsEliminationPhase.cpp: 2017-05-17 Don Olmstead [Win] Support $vm.getpid() https://bugs.webkit.org/show_bug.cgi?id=172248 Reviewed by Mark Lam. * tools/JSDollarVMPrototype.cpp: (JSC::functionGetPID): (JSC::JSDollarVMPrototype::finishCreation): 2017-05-17 Michael Saboff [iOS] The Garbage Collector shouldn't rely on the bmalloc scavenger for up to date memory footprint info https://bugs.webkit.org/show_bug.cgi?id=172186 Reviewed by Geoffrey Garen. The calls to bmalloc::api::memoryFootprint() and ::percentAvailableMemoryInUse() now call the OS to get up to date values. In overCriticalMemoryThreshold(), we get the current value every 100th call and use a cached value the rest of the time. When colleciton is done, we start with a new overCriticalMemoryThreshold value for the next cycle. The choice of 1 out of 100 calls was validated by using JetStream and verifying that it didn't impact performance and still provides timely memory footprint data. With additional debug logging, I determined that we call overCriticalMemoryThreshold() over 20,000 times/second running JetStream. Other logging showed that there were over 1700 calls to overCriticalMemoryThreshold() on average per GC cycle. Dividing both of these numbers by 100 seems reasonable. * heap/Heap.cpp: (JSC::Heap::overCriticalMemoryThreshold): (JSC::Heap::updateAllocationLimits): (JSC::Heap::shouldDoFullCollection): * heap/Heap.h: 2017-05-17 Saam Barati PinnedRegisters should be better modeled in IRC/Briggs https://bugs.webkit.org/show_bug.cgi?id=171955 Reviewed by Filip Pizlo. This patch fixes a bug in Briggs/IRC with respect to pinned registers. Pinned registers were not part of the assignable register file in IRC/Briggs, and this would lead to an asymmetry because they were modeled in the interference graph. The bug is that we use registerCount() to move various Tmps between various lists in the different allocators, and if a Tmp interfered with a pinned register (usually via a Patchpoint's clobbered set), we'd have an interference edge modeled in the degree for that Tmp, but the registerCount() would make us think that this particular Tmp is not assignable. This would lead us to fail to color a colorable graph. Specifically, this happened in our various patchpoint tests that stress the register allocator by forcing the entire register file into arguments for the patchpoint and then doing interesting things with the result, arguments, etc. This patch fixes the bug by coming up with an more natural way to model pinned registers. Pinned registers are now part of the register file. However, pinned registers are live at every point in the program (this is a defining property of a pinned register). In practice, this means that the only Tmps that can be assigned to pinned registers are ones that are coalescing candidates. This means the program has some number of defs for a Tmp T like: MoveType pinnedReg, T Note, if any other defs for T happen, like: Add32, t1, t2, T T will have an interference edge with pinnedReg, since pinnedReg is live at every point in the program. Modeling pinned registers this way allows IRC/Briggs to have no special casing for them. It treats it like any other precolored Tmp. This allows us to do coalescing, biased coloring, etc, which could all lead to a Tmp being assigned to a pinned register. Interestingly, we used to have special handling for the frame pointer register, which in many ways, acts like a pinned register, since FP is always live, and we wanted it to take place in coalescing. The allocator had a side-table interference graph with FP. Interestingly, we didn't even handle this properly everywhere since we could rely on a patchpoint never claiming to clobber FP (this would be illegal). So the code only handled the pseudo-pinned register properties of FP in various places. This patch drops this special casing and pins FP since all pinned registers can take part in coalescing. * b3/B3PatchpointSpecial.h: * b3/B3Procedure.cpp: (JSC::B3::Procedure::mutableGPRs): (JSC::B3::Procedure::mutableFPRs): * b3/B3Procedure.h: * b3/air/AirAllocateRegistersByGraphColoring.cpp: * b3/air/AirCode.cpp: (JSC::B3::Air::Code::Code): (JSC::B3::Air::Code::pinRegister): (JSC::B3::Air::Code::mutableGPRs): (JSC::B3::Air::Code::mutableFPRs): * b3/air/AirCode.h: (JSC::B3::Air::Code::pinnedRegisters): * b3/air/AirSpecial.h: * b3/air/testair.cpp: * b3/testb3.cpp: (JSC::B3::testSimplePatchpointWithOuputClobbersGPArgs): (JSC::B3::testSpillDefSmallerThanUse): (JSC::B3::testLateRegister): (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled): (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled2): (JSC::B3::testMoveConstants): 2017-05-16 Yusuke Suzuki [DFG] Constant Folding Phase should convert MakeRope("", String) => Identity(String) https://bugs.webkit.org/show_bug.cgi?id=172115 Reviewed by Saam Barati. In Fixup phase, we attempt to fold MakeRope to Identity (or reduce arguments) by dropping empty strings. However, when we are in Fixup phase, we do not have much information about constant values. In ARES-6 Babylon, we find that we can constant-fold MakeRope by using constants figured out by CFA. Without it, Babylon repeatedly produces rope strings. To fix this, we introduce MakeRope handling in constant folding phase. It shows 7.5% performance improvement in ARES-6 Babylon steadyState. Before: firstIteration: 50.02 +- 14.56 ms averageWorstCase: 26.52 +- 4.52 ms steadyState: 8.15 +- 0.23 ms After: firstIteration: 49.08 +- 12.90 ms averageWorstCase: 25.16 +- 3.82 ms steadyState: 7.58 +- 0.21 ms * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): 2017-05-16 Yusuke Suzuki Unreviewed, add Objective C files to CMake Mac port https://bugs.webkit.org/show_bug.cgi?id=172103 * shell/PlatformMac.cmake: Added. 2017-05-16 JF Bastien WebAssembly: enforce size limits https://bugs.webkit.org/show_bug.cgi?id=165833 Reviewed by Keith Miller. Use the same limits as V8. * JavaScriptCore.xcodeproj/project.pbxproj: * wasm/WasmLimits.h: Added. * wasm/WasmModuleParser.cpp: * wasm/WasmParser.h: (JSC::Wasm::Parser::consumeUTF8String): 2017-05-15 Yusuke Suzuki [JSC] Build testapi in non Apple ports https://bugs.webkit.org/show_bug.cgi?id=172103 Reviewed by Filip Pizlo. This patch makes JSC testapi buildable in non-Apple ports. We isolate CF related tests in testapi.c. If we do not use CF, we include JavaScript.h instead of JavaScriptCore.h. By running the testapi in Linux, we found that contraints test have a bug: If constraint marker runs after WeakRefs are destroyed, it accesses destroyed WeakRef. This patch also fixes it. * API/tests/CurrentThisInsideBlockGetterTest.h: * API/tests/CustomGlobalObjectClassTest.c: * API/tests/ExecutionTimeLimitTest.cpp: * API/tests/FunctionOverridesTest.cpp: * API/tests/GlobalContextWithFinalizerTest.cpp: * API/tests/JSObjectGetProxyTargetTest.cpp: * API/tests/MultithreadedMultiVMExecutionTest.cpp: * API/tests/PingPongStackOverflowTest.cpp: * API/tests/TypedArrayCTest.cpp: * API/tests/testapi.c: (assertEqualsAsCharactersPtr): (markingConstraint): (testMarkingConstraintsAndHeapFinalizers): (testCFStrings): (main): * shell/CMakeLists.txt: 2017-05-16 JF Bastien WebAssembly: report Memory usage to GC https://bugs.webkit.org/show_bug.cgi?id=170690 Reviewed by Keith Miller. * wasm/js/JSWebAssemblyMemory.cpp: (JSC::JSWebAssemblyMemory::grow): (JSC::JSWebAssemblyMemory::finishCreation): (JSC::JSWebAssemblyMemory::visitChildren): 2017-05-16 JF Bastien WebAssembly: validate load / store alignment https://bugs.webkit.org/show_bug.cgi?id=168836 Reviewed by Keith Miller. * wasm/WasmFunctionParser.h: check the alignment * wasm/generateWasm.py: generate the log2 alignment helper (Wasm): (isSimple): (memoryLog2Alignment): * wasm/generateWasmOpsHeader.py: (memoryLog2AlignmentGenerator): * wasm/wasm.json: fix formatting 2017-05-15 Mark Lam Rolling out r214038 and r213697: Crashes when using computed properties with rest destructuring and object spread. https://bugs.webkit.org/show_bug.cgi?id=172147 Rubber-stamped by Saam Barati. I rolled out every thing in those 2 patches except for the change to make CodeBlock::finishCreation() return a bool plus its clients that depend on this. I made this exception because r214931 relies on this change, and this part of the change looks correct. * builtins/BuiltinNames.h: * builtins/GlobalOperations.js: (globalPrivate.speciesConstructor): (globalPrivate.copyDataProperties): Deleted. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): (JSC::CodeBlock::setConstantIdentifierSetRegisters): Deleted. * bytecode/CodeBlock.h: * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedCodeBlock::addBitVector): (JSC::UnlinkedCodeBlock::constantRegisters): (JSC::UnlinkedCodeBlock::addSetConstant): Deleted. (JSC::UnlinkedCodeBlock::constantIdentifierSets): Deleted. * bytecompiler/BytecodeGenerator.cpp: * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::PropertyListNode::emitBytecode): (JSC::ObjectPatternNode::bindValue): (JSC::ObjectSpreadExpressionNode::emitBytecode): Deleted. * parser/ASTBuilder.h: (JSC::ASTBuilder::createProperty): (JSC::ASTBuilder::appendObjectPatternEntry): (JSC::ASTBuilder::createObjectSpreadExpression): Deleted. (JSC::ASTBuilder::appendObjectPatternRestEntry): Deleted. (JSC::ASTBuilder::setContainsObjectRestElement): Deleted. * parser/NodeConstructors.h: (JSC::PropertyNode::PropertyNode): (JSC::SpreadExpressionNode::SpreadExpressionNode): (JSC::ObjectSpreadExpressionNode::ObjectSpreadExpressionNode): Deleted. * parser/Nodes.h: (JSC::ObjectPatternNode::appendEntry): (JSC::ObjectSpreadExpressionNode::expression): Deleted. (JSC::ObjectPatternNode::setContainsRestElement): Deleted. * parser/Parser.cpp: (JSC::Parser::parseDestructuringPattern): (JSC::Parser::parseProperty): * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createSpreadExpression): (JSC::SyntaxChecker::createProperty): (JSC::SyntaxChecker::operatorStackPop): (JSC::SyntaxChecker::createObjectSpreadExpression): Deleted. * runtime/ObjectConstructor.cpp: (JSC::ObjectConstructor::finishCreation): * runtime/SetPrototype.cpp: (JSC::SetPrototype::finishCreation): 2017-05-15 David Kilzer JSEnvironmentRecord::allocationSizeForScopeSize() and offsetOfVariable(ScopeOffset) should used checked arithmetic Reviewed by Saam Barati. * runtime/JSEnvironmentRecord.h: (JSC::JSEnvironmentRecord::offsetOfVariable): Change to return size_t and use checked arithmetic. (JSC::JSEnvironmentRecord::allocationSizeForScopeSize): Change to use checked arithmetic. 2017-05-15 Mark Lam WorkerRunLoop::Task::performTask() should check !scriptController->isTerminatingExecution(). https://bugs.webkit.org/show_bug.cgi?id=171775 Reviewed by Filip Pizlo. Increased the number of frames captured in VM::nativeStackTraceOfLastThrow() from 25 to 100. From experience, I found that 25 is sometimes not sufficient for our debugging needs. Also added VM::throwingThread() to track which thread an exception was thrown in. This may be useful if the client is entering the VM from different threads. * runtime/ExceptionScope.cpp: (JSC::ExceptionScope::unexpectedExceptionMessage): * runtime/ExceptionScope.h: (JSC::ExceptionScope::exception): (JSC::ExceptionScope::unexpectedExceptionMessage): * runtime/Options.h: - Added the unexpectedExceptionStackTraceLimit option. * runtime/VM.cpp: (JSC::VM::throwException): * runtime/VM.h: (JSC::VM::throwingThread): (JSC::VM::clearException): 2017-05-13 David Kilzer Unused lambda capture in JSContextGroupAddMarkingConstraint() Reviewed by Saam Barati. Fixes the following warning with newer clang: Source/JavaScriptCore/API/JSMarkingConstraintPrivate.cpp:78:11: error: lambda capture 'vm' is not used [-Werror,-Wunused-lambda-capture] [&vm, constraintCallback, userData] ^ * API/JSMarkingConstraintPrivate.cpp: (JSContextGroupAddMarkingConstraint): Remove unused lambda capture for '&vm'. 2017-05-13 David Kilzer [JSC] config.rb fails when checking some clang versions Reviewed by Mark Lam. * offlineasm/config.rb: - Add support for quad-dotted version of Apple clang (800.0.12.1). - Add support for checking open source clang version (5.0.0). 2017-05-13 Commit Queue Unreviewed, rolling out r216808. https://bugs.webkit.org/show_bug.cgi?id=172075 caused lldb to hang when debugging (Requested by smfr on #webkit). Reverted changeset: "Use Mach exceptions instead of signals where possible" https://bugs.webkit.org/show_bug.cgi?id=171865 http://trac.webkit.org/changeset/216808 2017-05-13 Commit Queue Unreviewed, rolling out r216801. https://bugs.webkit.org/show_bug.cgi?id=172072 Many memory corruption crashes on worker threads (Requested by ap on #webkit). Reverted changeset: "WorkerRunLoop::Task::performTask() should check !scriptController->isTerminatingExecution()." https://bugs.webkit.org/show_bug.cgi?id=171775 http://trac.webkit.org/changeset/216801 2017-05-12 Geoffrey Garen [JSC] DFG::Node should not have its own allocator https://bugs.webkit.org/show_bug.cgi?id=160098 Reviewed by Saam Barati. I just rebased the patch from . I ran Octane and JetStream locally on a MacBook Air and I wasn't able to reproduce a regression. Let's land this again and see what the bots say. * JavaScriptCore.xcodeproj/project.pbxproj: * b3/B3SparseCollection.h: (JSC::B3::SparseCollection::packIndices): * dfg/DFGAllocator.h: Removed. * dfg/DFGDriver.cpp: (JSC::DFG::compileImpl): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::Graph): (JSC::DFG::Graph::~Graph): (JSC::DFG::Graph::deleteNode): (JSC::DFG::Graph::packNodeIndices): (JSC::DFG::Graph::addNodeToMapByIndex): Deleted. * dfg/DFGGraph.h: (JSC::DFG::Graph::addNode): (JSC::DFG::Graph::maxNodeCount): (JSC::DFG::Graph::nodeAt): * dfg/DFGLongLivedState.cpp: Removed. * dfg/DFGLongLivedState.h: Removed. * dfg/DFGNode.h: * dfg/DFGNodeAllocator.h: * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThread): (JSC::DFG::Plan::compileInThreadImpl): * dfg/DFGPlan.h: * dfg/DFGWorklist.cpp: * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2017-05-12 Keith Miller Use Mach exceptions instead of signals where possible https://bugs.webkit.org/show_bug.cgi?id=171865 Reviewed by Mark Lam. This patch adds some new JSC options. The first is an option that enables or disables web assembly tier up. The second controls whether or not we use mach exceptions (where available). * API/tests/ExecutionTimeLimitTest.cpp: (dispatchTermitateCallback): (testExecutionTimeLimit): * runtime/JSLock.cpp: (JSC::JSLock::didAcquireLock): * runtime/Options.cpp: (JSC::overrideDefaults): (JSC::Options::initialize): * runtime/Options.h: * runtime/VMTraps.cpp: (JSC::SignalContext::SignalContext): (JSC::SignalContext::adjustPCToPointToTrappingInstruction): (JSC::installSignalHandler): (JSC::VMTraps::SignalSender::send): * tools/SigillCrashAnalyzer.cpp: (JSC::SignalContext::SignalContext): (JSC::SignalContext::dump): (JSC::installCrashHandler): * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::compileFunctions): * wasm/WasmFaultSignalHandler.cpp: (JSC::Wasm::trapHandler): (JSC::Wasm::enableFastMemory): * wasm/WasmMachineThreads.cpp: (JSC::Wasm::resetInstructionCacheOnAllThreads): 2017-05-12 Mark Lam WorkerRunLoop::Task::performTask() should check !scriptController->isTerminatingExecution(). https://bugs.webkit.org/show_bug.cgi?id=171775 Reviewed by Saam Barati. Increased the number of frames captured in VM::nativeStackTraceOfLastThrow() from 25 to 100. From experience, I found that 25 is sometimes not sufficient for our debugging needs. Also added VM::throwingThread() to track which thread an exception was thrown in. This may be useful if the client is entering the VM from different threads. * runtime/ExceptionScope.cpp: (JSC::ExceptionScope::unexpectedExceptionMessage): * runtime/ExceptionScope.h: (JSC::ExceptionScope::exception): (JSC::ExceptionScope::unexpectedExceptionMessage): * runtime/Options.h: - Added the unexpectedExceptionStackTraceLimit option. * runtime/VM.cpp: (JSC::VM::throwException): * runtime/VM.h: (JSC::VM::throwingThread): (JSC::VM::clearException): 2017-05-12 Daniel Bates Cleanup: Make QueueTaskToEventLoopFunctionPtr take JSGlobalObject& https://bugs.webkit.org/show_bug.cgi?id=172021 Reviewed by Mark Lam. Change the function alias for QueueTaskToEventLoopFunctionPtr to take JSGlobalObject& instead of a const JSGlobalObject* as all implementations expect to be passed a non- const, non-null JSGlobalObject object. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::queueMicrotask): * runtime/JSGlobalObject.h: * runtime/VM.cpp: (JSC::VM::queueMicrotask): * runtime/VM.h: Remove JS_EXPORT_PRIVATE annotation from queueMicrotask() as it is only called from JavaScriptCore code. 2017-05-12 Michael Saboff [iOS] Use memory footprint to dynamically adjust behavior of allocators https://bugs.webkit.org/show_bug.cgi?id=171944 Reviewed by Filip Pizlo. This change is iOS only. Added the ability to react to when memory usage is critical. This is defined as memory usage being above the newly added option criticalGCMemoryThreshold. When we are in this critical state, all collections are Full and we limit the amount of memory we allocate between collections to 1/4th the memory above the critical threshold. Changed the calculation of proportionalHeapSize to be based on process memory footprint and not how big the heap is. Also, the values of Options::smallHeapRAMFraction and Options::mediumHeapRAMFraction are overriden so that most of the heap growth is happens using the more agressive Options::smallHeapGrowthFactor. * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::overCriticalMemoryThreshold): (JSC::Heap::shouldDoFullCollection): (JSC::Heap::collectIfNecessaryOrDefer): * heap/Heap.h: * runtime/Options.cpp: (JSC::overrideDefaults): (JSC::Options::initialize): * runtime/Options.h: 2017-05-11 Saam Barati Computing optionalDefArgWidth in CheckSpecial should not consider Scratch roles https://bugs.webkit.org/show_bug.cgi?id=171962 Reviewed by Filip Pizlo. The purpose of getting the result width is to get the width of the result of the arithmetic. It does not care about that the Check happens to define scratches. * b3/B3CheckSpecial.cpp: (JSC::B3::CheckSpecial::forEachArg): * b3/testb3.cpp: (JSC::B3::testCheckMul): (JSC::B3::testCheckMulMemory): (JSC::B3::testCheckMul64): (JSC::B3::testCheckMulFold): (JSC::B3::testCheckMulFoldFail): (JSC::B3::testCheckMulArgumentAliasing64): (JSC::B3::testCheckMulArgumentAliasing32): (JSC::B3::testCheckMul64SShr): 2017-05-11 Saam Barati isValidForm for SimpleAddr should use ptr() instead of tmp() https://bugs.webkit.org/show_bug.cgi?id=171992 Reviewed by Filip Pizlo. Arg::tmp() asserts that its kind is Tmp. Inst::isValidForm for SimpleAddr was using Arg::tmp() instead of ptr() to check if the address Tmp isGP(). It should be using Arg::ptr() instead of Arg::tmp() since Arg::ptr() is designed for SimpleAddr. This patch also fixes an incorrect assertion in the ARM64 macro assembler. We were asserting various atomic ops were only over 32/64 bit operations. However, the code was properly handling 8/16/32/64 bit ops. I changed the assertion to reflect what is actually going on. * assembler/ARM64Assembler.h: (JSC::ARM64Assembler::ldar): (JSC::ARM64Assembler::ldxr): (JSC::ARM64Assembler::ldaxr): (JSC::ARM64Assembler::stxr): (JSC::ARM64Assembler::stlr): (JSC::ARM64Assembler::stlxr): * b3/air/opcode_generator.rb: * b3/testb3.cpp: (JSC::B3::testLoadAcq42): (JSC::B3::testStoreRelAddLoadAcq32): (JSC::B3::testStoreRelAddLoadAcq8): (JSC::B3::testStoreRelAddFenceLoadAcq8): (JSC::B3::testStoreRelAddLoadAcq16): (JSC::B3::testStoreRelAddLoadAcq64): (JSC::B3::testAtomicWeakCAS): (JSC::B3::testAtomicStrongCAS): (JSC::B3::testAtomicXchg): 2017-05-11 Matt Lewis Unreviewed, rolling out r216677. Patch caused layout test crashes. Reverted changeset: "WorkerThread::stop() should call scheduleExecutionTermination() last." https://bugs.webkit.org/show_bug.cgi?id=171775 http://trac.webkit.org/changeset/216677 2017-05-11 Don Olmstead [CMake] Add HAVE check for regex.h https://bugs.webkit.org/show_bug.cgi?id=171950 Reviewed by Michael Catanzaro. * runtime/ConfigFile.cpp: (JSC::ConfigFile::parse): 2017-05-11 Filip Pizlo Callers of JSString::unsafeView() should check exceptions https://bugs.webkit.org/show_bug.cgi?id=171995 Reviewed by Mark Lam. unsafeView() can throw OOME. So, callers of unsafeView() should check for exceptions before trying to access the view. Also, I made the functions surrounding unsafeView() take ExecState* not ExecState&, to comply with the rest of JSC. * dfg/DFGOperations.cpp: * jsc.cpp: (printInternal): (functionDebug): * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncJoin): * runtime/FunctionConstructor.cpp: (JSC::constructFunctionSkippingEvalEnabledCheck): * runtime/IntlCollatorPrototype.cpp: (JSC::IntlCollatorFuncCompare): * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: (JSC::genericTypedArrayViewProtoFuncJoin): * runtime/JSGlobalObjectFunctions.cpp: (JSC::globalFuncParseFloat): * runtime/JSONObject.cpp: (JSC::JSONProtoFuncParse): * runtime/JSString.cpp: (JSC::JSString::getPrimitiveNumber): (JSC::JSString::toNumber): * runtime/JSString.h: (JSC::JSString::getIndex): (JSC::JSRopeString::unsafeView): (JSC::JSRopeString::viewWithUnderlyingString): (JSC::JSString::unsafeView): (JSC::JSString::viewWithUnderlyingString): * runtime/JSStringJoiner.h: (JSC::JSStringJoiner::appendWithoutSideEffects): (JSC::JSStringJoiner::append): * runtime/ParseInt.h: (JSC::toStringView): * runtime/StringPrototype.cpp: (JSC::stringProtoFuncRepeatCharacter): (JSC::stringProtoFuncCharAt): (JSC::stringProtoFuncCharCodeAt): (JSC::stringProtoFuncIndexOf): (JSC::stringProtoFuncNormalize): 2017-05-11 Filip Pizlo Offer SPI to notify clients that GC has happened https://bugs.webkit.org/show_bug.cgi?id=171980 Reviewed by Geoffrey Garen. Sometimes when you're programming with weak references, it's most convenient if the GC tells you when it finishes. This adds exactly such an API. This API is called at the *flip*: the moment when the GC knows for sure which objects are dead and has definitely not allocated any new objects or executed any JS code. The finalization part of the flip, which is where this callback gets called, runs on the "main" thread - i.e. some thread that is attempting to execute JS code and holds the JS lock. This will usually run as a side-effect of some allocation or from the runloop. This means, for example, that if you implemented a vector of weak references and registered a callback to prune the vector of null weak references, then aside from the callback, nobody would ever see a null weak reference in the vector. * API/JSHeapFinalizerPrivate.cpp: Added. (JSContextGroupAddHeapFinalizer): (JSContextGroupRemoveHeapFinalizer): * API/JSHeapFinalizerPrivate.h: Added. * API/tests/testapi.c: (heapFinalizer): (testMarkingConstraintsAndHeapFinalizers): (main): (testMarkingConstraints): Deleted. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * heap/Heap.cpp: (JSC::Heap::finalize): (JSC::Heap::addHeapFinalizerCallback): (JSC::Heap::removeHeapFinalizerCallback): * heap/Heap.h: * heap/HeapFinalizerCallback.cpp: Added. (JSC::HeapFinalizerCallback::dump): * heap/HeapFinalizerCallback.h: Added. (JSC::HeapFinalizerCallback::HeapFinalizerCallback): (JSC::HeapFinalizerCallback::operator==): (JSC::HeapFinalizerCallback::operator!=): (JSC::HeapFinalizerCallback::operator bool): (JSC::HeapFinalizerCallback::run): 2017-05-11 Filip Pizlo JSWeakCreate/Retain/Release should take a JSContextGroupRef and not a JSContextRef https://bugs.webkit.org/show_bug.cgi?id=171979 Reviewed by Mark Lam. Functions that don't execute arbitrary JS but just need access to the VM should take a JSContextGroupRef, not a JSContextRef. * API/JSWeakPrivate.cpp: (JSWeakCreate): (JSWeakRetain): (JSWeakRelease): * API/JSWeakPrivate.h: * API/tests/testapi.c: (testMarkingConstraints): 2017-05-11 Mark Lam WorkerThread::stop() should call scheduleExecutionTermination() last. https://bugs.webkit.org/show_bug.cgi?id=171775 Reviewed by Geoffrey Garen. Increased the number of frames captured in VM::nativeStackTraceOfLastThrow() from 25 to 100. From experience, I found that 25 is sometimes not sufficient for our debugging needs. Also added VM::throwingThread() to track which thread an exception was thrown in. This may be useful if the client is entering the VM from different threads. * runtime/ExceptionScope.cpp: (JSC::ExceptionScope::unexpectedExceptionMessage): (JSC::ExceptionScope::releaseAssertIsTerminatedExecutionException): * runtime/ExceptionScope.h: (JSC::ExceptionScope::exception): (JSC::ExceptionScope::unexpectedExceptionMessage): * runtime/VM.cpp: (JSC::VM::throwException): * runtime/VM.h: (JSC::VM::throwingThread): (JSC::VM::clearException): 2017-05-11 JF Bastien WebAssembly: stop supporting 0xD https://bugs.webkit.org/show_bug.cgi?id=168788 Reviewed by Saam Barati. Only version 1 is supported by other browsers, and there shouldn't be any 0xD binaries in the wild anymore. * wasm/WasmModuleParser.cpp: 2017-05-09 Sam Weinig Remove support for legacy Notifications https://bugs.webkit.org/show_bug.cgi?id=171487 Reviewed by Jon Lee. * Configurations/FeatureDefines.xcconfig: Remove definition of ENABLE_LEGACY_NOTIFICATIONS. 2017-05-10 Commit Queue Unreviewed, rolling out r216635. https://bugs.webkit.org/show_bug.cgi?id=171953 "Some worker tests are failing". (Requested by mlam on #webkit). Reverted changeset: "WorkerThread::stop() should call scheduleExecutionTermination() last." https://bugs.webkit.org/show_bug.cgi?id=171775 http://trac.webkit.org/changeset/216635 2017-05-10 Mark Lam Crash in JavaScriptCore GC when using JSC on dispatch queues (thread_get_state returns NULL stack pointer). https://bugs.webkit.org/show_bug.cgi?id=160337 Not reviewed. Updated a comment per Geoff's suggestion. * heap/MachineStackMarker.cpp: (JSC::MachineThreads::tryCopyOtherThreadStack): 2017-05-10 Mark Lam WorkerThread::stop() should call scheduleExecutionTermination() last. https://bugs.webkit.org/show_bug.cgi?id=171775 Reviewed by Geoffrey Garen. Increased the number of frames captured in VM::nativeStackTraceOfLastThrow() from 25 to 100. From experience, I found that 25 is sometimes not sufficient for our debugging needs. Also added VM::throwingThread() to track which thread an exception was thrown in. This may be useful if the client is entering the VM from different threads. * runtime/ExceptionScope.cpp: (JSC::ExceptionScope::unexpectedExceptionMessage): (JSC::ExceptionScope::releaseAssertIsTerminatedExecutionException): * runtime/ExceptionScope.h: (JSC::ExceptionScope::exception): (JSC::ExceptionScope::unexpectedExceptionMessage): * runtime/VM.cpp: (JSC::VM::throwException): * runtime/VM.h: (JSC::VM::throwingThread): (JSC::VM::clearException): 2017-05-10 Mark Lam Crash in JavaScriptCore GC when using JSC on dispatch queues (thread_get_state returns NULL stack pointer). https://bugs.webkit.org/show_bug.cgi?id=160337 Reviewed by Filip Pizlo and Geoffrey Garen. This is a workaround for . During thread initialization, for some target platforms, thread state is momentarily set to 0 before being filled in with the target thread's real register values. As a result, there's a race condition that may result in us getting a null stackPointer during a GC scan. This issue may manifest with workqueue threads where the OS may choose to recycle a thread for an expired task. The workaround is simply to indicate that there's nothing to copy and return. This is correct because we will only ever observe a null pointer during thread initialization. Hence, by definition, there's nothing there that we need to scan yet, and therefore, nothing that needs to be copied. * heap/MachineStackMarker.cpp: (JSC::MachineThreads::tryCopyOtherThreadStack): 2017-05-10 JF Bastien WebAssembly: support name section https://bugs.webkit.org/show_bug.cgi?id=171263 Reviewed by Keith Miller. The name section is an optional custom section in the WebAssembly spec. At least when debugging, developers expect to be able to use this section to obtain intelligible stack traces, otherwise we just number the wasm functions which is somewhat painful. This patch parses this section, dropping its content eagerly on error, and if there is a name section then backtraces use their value instead of numbers. Otherwise we stick to numbers as before. Note that the format of name sections changed in mid-February: https://github.com/WebAssembly/design/pull/984 And binaryen was only updated in early March: https://github.com/WebAssembly/binaryen/pull/933 * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * interpreter/Interpreter.cpp: (JSC::GetStackTraceFunctor::operator()): * interpreter/StackVisitor.cpp: (JSC::StackVisitor::readNonInlinedFrame): (JSC::StackVisitor::Frame::functionName): * interpreter/StackVisitor.h: (JSC::StackVisitor::Frame::wasmFunctionIndexOrName): * runtime/StackFrame.cpp: (JSC::StackFrame::functionName): * runtime/StackFrame.h: (JSC::StackFrame::StackFrame): (JSC::StackFrame::wasm): * wasm/WasmBBQPlanInlines.h: (JSC::Wasm::BBQPlan::initializeCallees): * wasm/WasmCallee.cpp: (JSC::Wasm::Callee::Callee): * wasm/WasmCallee.h: (JSC::Wasm::Callee::create): (JSC::Wasm::Callee::indexOrName): * wasm/WasmFormat.cpp: (JSC::Wasm::makeString): * wasm/WasmFormat.h: (JSC::Wasm::isValidExternalKind): (JSC::Wasm::isValidNameType): (JSC::Wasm::NameSection::get): * wasm/WasmIndexOrName.cpp: Copied from Source/JavaScriptCore/wasm/WasmCallee.cpp. (JSC::Wasm::IndexOrName::IndexOrName): (JSC::Wasm::makeString): * wasm/WasmIndexOrName.h: Copied from Source/JavaScriptCore/wasm/WasmFormat.cpp. * wasm/WasmModuleInformation.h: * wasm/WasmModuleParser.cpp: * wasm/WasmName.h: Copied from Source/JavaScriptCore/wasm/WasmCallee.cpp. * wasm/WasmNameSectionParser.cpp: Added. * wasm/WasmNameSectionParser.h: Copied from Source/JavaScriptCore/wasm/WasmCallee.cpp. (JSC::Wasm::NameSectionParser::NameSectionParser): * wasm/WasmOMGPlan.cpp: (JSC::Wasm::OMGPlan::work): * wasm/WasmParser.h: (JSC::Wasm::Parser::consumeUTF8String): 2017-05-10 Filip Pizlo Null pointer dereference in WTF::RefPtr::operator!() under slow_path_get_direct_pname https://bugs.webkit.org/show_bug.cgi?id=171801 Reviewed by Michael Saboff. This was a goofy oversight. The for-in optimization relies on the bytecode generator to detect when the loop's index variable gets mutated. We forgot to have the hooks for detecting this in prefix and postfix operations (++i and i++). * bytecompiler/NodesCodegen.cpp: (JSC::PostfixNode::emitResolve): (JSC::PrefixNode::emitResolve): 2017-05-10 Michael Catanzaro [GTK] -Wmissing-field-initializers triggered by RemoteInspectorServer.cpp:128 https://bugs.webkit.org/show_bug.cgi?id=171273 Reviewed by Carlos Garcia Campos. * inspector/remote/glib/RemoteInspectorGlib.cpp: * inspector/remote/glib/RemoteInspectorServer.cpp: 2017-05-10 Adrian Perez de Castro Remove some last remnants of the EFL port https://bugs.webkit.org/show_bug.cgi?id=171922 Reviewed by Antonio Gomes. The EFL port is no more. * PlatformEfl.cmake: Removed. * shell/PlatformEfl.cmake: Removed. 2017-05-09 Filip Pizlo JSInjectedScriptHost should get a copy of the boundArgs https://bugs.webkit.org/show_bug.cgi?id=171897 Reviewed by Joseph Pecoraro. The boundArgs array is very special - it cannot be mutated in any way. So, it makes sense for the inspector to get a copy of it. * inspector/JSInjectedScriptHost.cpp: (Inspector::JSInjectedScriptHost::getInternalProperties): * runtime/JSBoundFunction.cpp: (JSC::JSBoundFunction::boundArgsCopy): * runtime/JSBoundFunction.h: (JSC::JSBoundFunction::boundArgs): 2017-05-09 Mark Lam Unindent some code in Watchdog::shouldTerminate(). https://bugs.webkit.org/show_bug.cgi?id=171896 Rubber stamped by Keith Miller. I should have done this before I landed r213107, but I forgot. Unindenting it now. * runtime/Watchdog.cpp: (JSC::Watchdog::shouldTerminate): 2017-05-09 Michael Saboff Cap the number of FTL compilation threads on iOS to 2 https://bugs.webkit.org/show_bug.cgi?id=171887 Reviewed by Filip Pizlo. Set an iOS specific max of 2 threads. * runtime/Options.h: 2017-05-09 Filip Pizlo Heap::heap() should behave gracefully for null pointers https://bugs.webkit.org/show_bug.cgi?id=171888 Reviewed by Mark Lam. Some callers of Heap::heap() can pass a null cell and they will behave gracefully if we return a null Heap. So, let's do that. This fixes a crash and it does not hurt performance. I'm seeing a possible 0.5% regression with 74% probability. That's a neutral result by our usual 95% standard. * heap/HeapInlines.h: (JSC::Heap::heap): 2017-05-09 Yusuke Suzuki Handle IDLPromise<> properly https://bugs.webkit.org/show_bug.cgi?id=166752 Reviewed by Youenn Fablet. Add JSPromise::resolve static function. This applies `Promise.resolve()` conversion to a given value. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildren): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::promiseResolveFunction): * runtime/JSPromise.cpp: (JSC::JSPromise::resolve): * runtime/JSPromise.h: 2017-05-09 Zan Dobersek Upstream the WPE port https://bugs.webkit.org/show_bug.cgi?id=171110 Reviewed by Alex Christensen. * PlatformWPE.cmake: Added. * shell/PlatformWPE.cmake: Added. 2017-05-09 Saam Barati CallLinkInfos belonging to Wasm->JS stubs need to be informed when we clearCode() from all Executables https://bugs.webkit.org/show_bug.cgi?id=171707 Reviewed by Filip Pizlo. This patch fixes a bug where a Wasm->JS IC call stub would go stale and point into a CodeBlock no longer owned by any executable. The problematic scenario is this: 1. We generate the call IC which has a branch on a callee check. This callee owns the Executable in question. If the branch succeeds, it will call code belonging to a particular CodeBlock associated with that Executable. 2. Heap::deleteAllCodeBlocks is called. This leads the Executable to clear its various CodeBlock references. 3. Wasm has no idea this happened, so now it has stale ICs that point into code from a CodeBlock no longer belonging to an Executable. This patch fixes the bug by informing all JSWebAssemblyCodeBlocks to unlink their CallLinkInfo when Heap::deleteAllCodeBlocks is called. We track all JSWebAssemblyCodeBlocks by creating a new subspace for them. This allows us to quickly iterate over the live JSWebAssemblyCodeBlocks in the heap. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * heap/Heap.cpp: (JSC::Heap::deleteAllCodeBlocks): * heap/Subspace.h: * heap/SubspaceInlines.h: (JSC::Subspace::forEachLiveCell): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: * wasm/js/JSWebAssemblyCodeBlock.cpp: (JSC::JSWebAssemblyCodeBlock::clearJSCallICs): * wasm/js/JSWebAssemblyCodeBlock.h: (JSC::JSWebAssemblyCodeBlock::createStructure): Deleted. (JSC::JSWebAssemblyCodeBlock::functionImportCount): Deleted. (JSC::JSWebAssemblyCodeBlock::module): Deleted. (JSC::JSWebAssemblyCodeBlock::jsEntrypointCalleeFromFunctionIndexSpace): Deleted. (JSC::JSWebAssemblyCodeBlock::wasmEntrypointLoadLocationFromFunctionIndexSpace): Deleted. (JSC::JSWebAssemblyCodeBlock::wasmToJsCallStubForImport): Deleted. (JSC::JSWebAssemblyCodeBlock::offsetOfImportWasmToJSStub): Deleted. (JSC::JSWebAssemblyCodeBlock::codeBlock): Deleted. (JSC::JSWebAssemblyCodeBlock::offsetOfImportStubs): Deleted. (JSC::JSWebAssemblyCodeBlock::allocationSize): Deleted. (JSC::JSWebAssemblyCodeBlock::importWasmToJSStub): Deleted. * wasm/js/JSWebAssemblyCodeBlockSubspace.cpp: Added. (JSC::JSWebAssemblyCodeBlockSubspace::JSWebAssemblyCodeBlockSubspace): (JSC::JSWebAssemblyCodeBlockSubspace::~JSWebAssemblyCodeBlockSubspace): (JSC::JSWebAssemblyCodeBlockSubspace::finishSweep): (JSC::JSWebAssemblyCodeBlockSubspace::destroy): * wasm/js/JSWebAssemblyCodeBlockSubspace.h: Added. 2017-05-08 Saam Barati testWasmBoundsCheck and testCallFunctionWithHellaArguments is broken in testb3 https://bugs.webkit.org/show_bug.cgi?id=171392 Reviewed by Keith Miller. This patch fixes two bugs. The first one is: Inside testb3, we were using the wrong WasmBoundsCheckValue constructor. Everything compiled OK because of implicit casting in C. I've changed one of the constructors to take arguments in a different order so we don't run into this problem again. The second bug was that Air::ShufflePair::inst was assuming that a move from BigImm to its destination is always valid. This is not the case. For example, the store, `Move BigImm, Addr` is not allowed. I refactored the code to be correct by emitting more than one instruction when needeed. When testing my changes, I ran ARM64 testb3 both in debug and release. I ran into many pre-existing failures. I've opened a new bug to fix those here: https://bugs.webkit.org/show_bug.cgi?id=171826 * b3/B3WasmBoundsCheckValue.cpp: (JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue): * b3/B3WasmBoundsCheckValue.h: * b3/air/AirEmitShuffle.cpp: (JSC::B3::Air::ShufflePair::insts): (JSC::B3::Air::ShufflePair::inst): Deleted. * b3/air/AirEmitShuffle.h: * b3/air/AirLowerMacros.cpp: (JSC::B3::Air::lowerMacros): * b3/testb3.cpp: (JSC::B3::testLoadAcq42): (JSC::B3::testStoreRelAddLoadAcq32): (JSC::B3::testStoreRelAddLoadAcq8): (JSC::B3::testStoreRelAddFenceLoadAcq8): (JSC::B3::testStoreRelAddLoadAcq16): (JSC::B3::testStoreRelAddLoadAcq64): (JSC::B3::testSimplePatchpointWithOuputClobbersGPArgs): (JSC::B3::testCheckMul): (JSC::B3::testCheckMulMemory): (JSC::B3::testCheckMul64): (JSC::B3::testCheckMulFold): (JSC::B3::testCheckMulFoldFail): (JSC::B3::testCheckMulArgumentAliasing64): (JSC::B3::testCheckMulArgumentAliasing32): (JSC::B3::testCheckMul64SShr): (JSC::B3::testCallFunctionWithHellaArguments): (JSC::B3::functionWithHellaArguments2): (JSC::B3::testCallFunctionWithHellaArguments2): (JSC::B3::functionWithHellaArguments3): (JSC::B3::testCallFunctionWithHellaArguments3): (JSC::B3::testSpillDefSmallerThanUse): (JSC::B3::testLateRegister): (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled): (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled2): (JSC::B3::testMoveConstants): (JSC::B3::testAtomicWeakCAS): (JSC::B3::testAtomicStrongCAS): (JSC::B3::testAtomicXchg): (JSC::B3::testWasmBoundsCheck): (JSC::B3::run): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer): 2017-05-08 Filip Pizlo Expose a function to get proxy targets https://bugs.webkit.org/show_bug.cgi?id=171797 Reviewed by Mark Lam. This exposes a new private API function, JSObjectGetProxyTarget(), that gets the target of a proxy. It works with both ProxyObject and JSProxy, but it's primarily intended for use with JSProxy. * API/JSObjectRef.cpp: (JSObjectGetProxyTarget): * API/JSObjectRefPrivate.h: * API/tests/JSObjectGetProxyTargetTest.cpp: Added. (testJSObjectGetProxyTarget): * API/tests/JSObjectGetProxyTargetTest.h: Added. * API/tests/testapi.c: (main): * JavaScriptCore.xcodeproj/project.pbxproj: * runtime/ProxyObject.h: * shell/PlatformWin.cmake: 2017-05-08 Mark Lam op_throw_static_error's use of its first operand should be reflected in DFG BytecodeUseDef as well. https://bugs.webkit.org/show_bug.cgi?id=171786 Reviewed by Saam Barati. * bytecode/BytecodeDumper.cpp: (JSC::BytecodeDumper::dumpBytecode): - Fix BytecodeDumper to dump op_throw_static_error correctly. Previously, it was expecting op1 to always be a constant. r206870 changed it to take a variable string as well. * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): - Fix the bug. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): - Move the Phantom of op1 after the ThrowStaticError node, because technically, the ThrowStaticError represents op_throw_static_error, and op_throw_static_error uses op1. In practice, this probably doesn't matter, but let's have the code accurately communicate the behavior we're expecting. 2017-05-08 JF Bastien WebAssembly: don't just emit extended offset adds for patch https://bugs.webkit.org/show_bug.cgi?id=171799 Reviewed by Mark Lam. It isn't necessary to restrict. * b3/air/AirLowerStackArgs.cpp: (JSC::B3::Air::lowerStackArgs): 2017-05-08 Mark Lam Introduce ExceptionScope::assertNoException() and releaseAssertNoException(). https://bugs.webkit.org/show_bug.cgi?id=171776 Reviewed by Keith Miller. Instead of ASSERT(!scope.exception()), we can now do scope.assertNoException(). Ditto for RELEASE_ASSERT and scope.releaseAssertNoException(). The advantage of using ExceptionScope::assertNoException() and releaseAssertNoException() is that if the assertion fails, these utility functions will print the stack trace for where the unexpected exception is detected as well as where the unexpected exception was thrown from. This makes it much easier to debug the source of unhandled exceptions. * debugger/Debugger.cpp: (JSC::Debugger::pauseIfNeeded): * dfg/DFGOperations.cpp: * interpreter/Interpreter.cpp: (JSC::eval): (JSC::notifyDebuggerOfUnwinding): (JSC::Interpreter::executeProgram): (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): (JSC::Interpreter::prepareForRepeatCall): (JSC::Interpreter::execute): (JSC::Interpreter::debug): * interpreter/ShadowChicken.cpp: (JSC::ShadowChicken::functionsOnStack): * jsc.cpp: (GlobalObject::moduleLoaderResolve): (GlobalObject::moduleLoaderFetch): (functionGenerateHeapSnapshot): (functionSamplingProfilerStackTraces): (box): (runWithScripts): * runtime/AbstractModuleRecord.cpp: (JSC::AbstractModuleRecord::finishCreation): * runtime/ArrayPrototype.cpp: (JSC::ArrayPrototype::tryInitializeSpeciesWatchpoint): * runtime/Completion.cpp: (JSC::rejectPromise): * runtime/ErrorInstance.cpp: (JSC::ErrorInstance::sanitizedToString): * runtime/ExceptionHelpers.cpp: (JSC::createError): * runtime/ExceptionScope.cpp: (JSC::ExceptionScope::unexpectedExceptionMessage): * runtime/ExceptionScope.h: (JSC::ExceptionScope::assertNoException): (JSC::ExceptionScope::releaseAssertNoException): (JSC::ExceptionScope::unexpectedExceptionMessage): * runtime/GenericArgumentsInlines.h: (JSC::GenericArguments::defineOwnProperty): * runtime/IntlCollator.cpp: (JSC::IntlCollator::createCollator): (JSC::IntlCollator::resolvedOptions): * runtime/IntlDateTimeFormat.cpp: (JSC::IntlDateTimeFormat::resolvedOptions): (JSC::IntlDateTimeFormat::format): * runtime/IntlNumberFormat.cpp: (JSC::IntlNumberFormat::createNumberFormat): (JSC::IntlNumberFormat::resolvedOptions): * runtime/JSCJSValue.cpp: (JSC::JSValue::putToPrimitiveByIndex): * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: (JSC::genericTypedArrayViewProtoFuncIncludes): (JSC::genericTypedArrayViewProtoFuncIndexOf): (JSC::genericTypedArrayViewProtoFuncLastIndexOf): (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/JSGlobalObjectFunctions.cpp: (JSC::globalFuncHostPromiseRejectionTracker): * runtime/JSModuleEnvironment.cpp: (JSC::JSModuleEnvironment::getOwnPropertySlot): * runtime/JSModuleLoader.cpp: (JSC::JSModuleLoader::finishCreation): * runtime/JSModuleNamespaceObject.cpp: (JSC::JSModuleNamespaceObject::finishCreation): * runtime/JSONObject.cpp: (JSC::Stringifier::toJSON): * runtime/JSObject.cpp: (JSC::JSObject::ordinaryToPrimitive): * runtime/JSPropertyNameEnumerator.h: (JSC::propertyNameEnumerator): * runtime/ObjectConstructor.cpp: (JSC::objectConstructorGetOwnPropertyDescriptors): (JSC::objectConstructorDefineProperty): * runtime/ObjectPrototype.cpp: (JSC::objectProtoFuncHasOwnProperty): * runtime/ProgramExecutable.cpp: (JSC::ProgramExecutable::initializeGlobalProperties): * runtime/ReflectObject.cpp: (JSC::reflectObjectDefineProperty): * runtime/SamplingProfiler.cpp: (JSC::SamplingProfiler::StackFrame::nameFromCallee): * runtime/StringPrototype.cpp: (JSC::stringProtoFuncRepeatCharacter): * runtime/TemplateRegistry.cpp: (JSC::TemplateRegistry::getTemplateObject): * runtime/VM.cpp: (JSC::VM::throwException): * runtime/VM.h: (JSC::VM::nativeStackTraceOfLastThrow): (JSC::VM::clearException): * wasm/WasmB3IRGenerator.cpp: * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::create): 2017-05-06 Bill Ming Fix 32bit Windows build by giving correct parameters to MASM https://bugs.webkit.org/show_bug.cgi?id=170833 Reviewed by Alex Christensen. * CMakeLists.txt: 2017-05-06 Oleksandr Skachkov [ES6] Arrow function. Issue in access to this after eval('super()') within constructor https://bugs.webkit.org/show_bug.cgi?id=171543 Reviewed by Saam Barati. Current patch force to use 'this' within arrow function or eval from virtual scope each time, instead of using thisRegister. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::ensureThis): 2017-05-05 Keith Miller Put does not properly consult the prototype chain https://bugs.webkit.org/show_bug.cgi?id=171754 Reviewed by Saam Barati. We should do a follow up that cleans up the rest of put. See: https://bugs.webkit.org/show_bug.cgi?id=171759 * runtime/JSCJSValue.cpp: (JSC::JSValue::putToPrimitive): * runtime/JSObject.cpp: (JSC::JSObject::putInlineSlow): * runtime/JSObjectInlines.h: (JSC::JSObject::canPerformFastPutInline): 2017-05-05 JF Bastien WebAssembly: Air::Inst::generate crashes on large binary on A64 https://bugs.webkit.org/show_bug.cgi?id=170215 Reviewed by Filip Pizlo. ARM can't encode all offsets in a single instruction. We usualy handle this type of detail early, or the macro assembler uses a scratch register to take care of the large immediate. After register allocation we assumed that we would never get large offsets, and asserted this was the case. That was a fine assumption with JavaScript, but WebAssembly ends up generating stack frames which are too big to encode. There are two places that needed to be fixed: 1. AirGenerate 2. AirLowerStackArgs We now unconditionally pin the dataTempRegister on ARM64, and use it when immediates don't fit. Number 1. is easy: we're just incrementing SP, make sure we can use a scratch register when that happens. Number 2. is more complex: not all Inst can receive a stack argument whose base register isn't SP or FP. Specifically, Patchpoints and Stackmaps get very sad because they just want to know the offset value, but when we materialize the offset as follows: Move (spill337), (spill201), %r0, @8735 Becomes (where %r16 is dataTempRegister): Move $1404, %r16, @8736 Add64 %sp, %r16, @8736 Move (%r16), 2032(%sp), %r0, @8736 The code currently doesn't see through our little dance. To work around this issue we introduce a new Air Arg kind: ExtendedOffsetAddr. This is the same as a regular Addr, but with an offset which may be too big to encode. Opcodes then declare whether their arguments can handle such inputs, and if so we generate them, otherwise we generate Addr as shown above. None of this affects x86 because it can always encode large immediates. This patch also drive-by converts some uses of `override` to `final`. It makes the code easier to grok, and maybe helps the optimizer sometimes but really that doens't matter. * assembler/MacroAssembler.h: * assembler/MacroAssemblerARM64.h: * b3/B3CheckSpecial.cpp: (JSC::B3::CheckSpecial::admitsExtendedOffsetAddr): * b3/B3CheckSpecial.h: * b3/B3Common.cpp: (JSC::B3::pinnedExtendedOffsetAddrRegister): keep the CPU-specific pinning information in a cpp file * b3/B3Common.h: * b3/B3PatchpointSpecial.cpp: (JSC::B3::PatchpointSpecial::admitsExtendedOffsetAddr): * b3/B3PatchpointSpecial.h: * b3/B3StackmapSpecial.cpp: (JSC::B3::StackmapSpecial::isArgValidForRep): (JSC::B3::StackmapSpecial::repForArg): * b3/B3StackmapSpecial.h: * b3/air/AirArg.cpp: (JSC::B3::Air::Arg::isStackMemory): (JSC::B3::Air::Arg::jsHash): (JSC::B3::Air::Arg::dump): (WTF::printInternal): (JSC::B3::Air::Arg::stackAddrImpl): Deleted. There was only one use of this (in AirLowerStackArgs) and it was now confusing to split the logic up between these two. Inline the code that used to be here into its one usepoint instead. * b3/air/AirArg.h: (JSC::B3::Air::Arg::extendedOffsetAddr): (JSC::B3::Air::Arg::isExtendedOffsetAddr): (JSC::B3::Air::Arg::isMemory): (JSC::B3::Air::Arg::base): (JSC::B3::Air::Arg::offset): (JSC::B3::Air::Arg::isGP): (JSC::B3::Air::Arg::isFP): (JSC::B3::Air::Arg::isValidForm): (JSC::B3::Air::Arg::forEachTmpFast): (JSC::B3::Air::Arg::forEachTmp): (JSC::B3::Air::Arg::asAddress): (JSC::B3::Air::Arg::stackAddr): Deleted. * b3/air/AirCCallSpecial.cpp: (JSC::B3::Air::CCallSpecial::isValid): (JSC::B3::Air::CCallSpecial::admitsExtendedOffsetAddr): (JSC::B3::Air::CCallSpecial::generate): * b3/air/AirCCallSpecial.h: * b3/air/AirCode.cpp: (JSC::B3::Air::Code::Code): (JSC::B3::Air::Code::pinRegister): Check that the register wasn't pinned before pinning it. It's likely a bug to pin the same register twice. * b3/air/AirCustom.h: (JSC::B3::Air::PatchCustom::admitsExtendedOffsetAddr): (JSC::B3::Air::CCallCustom::admitsExtendedOffsetAddr): (JSC::B3::Air::ShuffleCustom::admitsExtendedOffsetAddr): (JSC::B3::Air::EntrySwitchCustom::admitsExtendedOffsetAddr): (JSC::B3::Air::WasmBoundsCheckCustom::admitsExtendedOffsetAddr): * b3/air/AirGenerate.cpp: (JSC::B3::Air::generate): * b3/air/AirInst.h: * b3/air/AirInstInlines.h: (JSC::B3::Air::Inst::admitsExtendedOffsetAddr): * b3/air/AirLowerStackArgs.cpp: (JSC::B3::Air::lowerStackArgs): * b3/air/AirPrintSpecial.cpp: (JSC::B3::Air::PrintSpecial::admitsExtendedOffsetAddr): (JSC::B3::Air::PrintSpecial::generate): * b3/air/AirPrintSpecial.h: * b3/air/AirSpecial.h: * b3/air/opcode_generator.rb: 2017-05-05 Oliver Hunt Move trivial String prototype functions to JS builtins https://bugs.webkit.org/show_bug.cgi?id=171737 Reviewed by Saam Barati. Super simple change to migrate all of the old school html-ifying string operations to builtin JS. Core implementation is basically a 1-for-1 match to the spec. * builtins/StringPrototype.js: (globalPrivate.createHTML): (anchor): (big): (blink): (bold): (fixed): (fontcolor): (fontsize): (italics): (link): (small): (strike): (sub): (sup): * runtime/StringPrototype.cpp: (JSC::StringPrototype::finishCreation): (JSC::stringProtoFuncBig): Deleted. (JSC::stringProtoFuncSmall): Deleted. (JSC::stringProtoFuncBlink): Deleted. (JSC::stringProtoFuncBold): Deleted. (JSC::stringProtoFuncFixed): Deleted. (JSC::stringProtoFuncItalics): Deleted. (JSC::stringProtoFuncStrike): Deleted. (JSC::stringProtoFuncSub): Deleted. (JSC::stringProtoFuncSup): Deleted. (JSC::stringProtoFuncFontcolor): Deleted. (JSC::stringProtoFuncFontsize): Deleted. (JSC::stringProtoFuncAnchor): Deleted. (JSC::stringProtoFuncLink): Deleted. 2017-05-05 Don Olmstead [JSC] Remove export from Intrinsic https://bugs.webkit.org/show_bug.cgi?id=171752 Reviewed by Alexey Proskuryakov. * runtime/Intrinsic.h: 2017-05-05 Saam Barati putDirectIndex does not properly do defineOwnProperty https://bugs.webkit.org/show_bug.cgi?id=171591 Reviewed by Geoffrey Garen. This patch fixes putDirectIndex and its JIT implementations to be compatible with the ES6 spec. I think our code became out of date when we implemented ArraySpeciesCreate since ArraySpeciesCreate may return arbitrary objects. We perform putDirectIndex on that arbitrary object. The behavior we want is as if we performed defineProperty({configurable:true, enumerable:true, writable:true}). However, we weren't doing this. putDirectIndex assumed it could just splat data into any descendent of JSObject's butterfly. For example, this means we'd just splat into the butterfly of a typed array, even though a typed array doesn't use its butterfly to store its indexed properties in the usual way. Also, typed array properties are non-configurable, so this operation should throw. This also means if we saw a ProxyObject, we'd just splat into its butterfly, but this is obviously wrong because ProxyObject should intercept the defineProperty operation. This patch fixes this issue by adding a whitelist of cell types that can go down putDirectIndex's fast path. Anything not in that whitelist will simply call into defineOwnProperty. * bytecode/ByValInfo.h: (JSC::jitArrayModePermitsPutDirect): * dfg/DFGArrayMode.cpp: (JSC::DFG::ArrayMode::refine): * jit/JITOperations.cpp: * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncSplice): * runtime/ClonedArguments.cpp: (JSC::ClonedArguments::createStructure): * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::defineOwnProperty): * runtime/JSObject.cpp: (JSC::canDoFastPutDirectIndex): (JSC::JSObject::defineOwnIndexedProperty): (JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength): (JSC::JSObject::putDirectIndexBeyondVectorLength): Deleted. * runtime/JSObject.h: (JSC::JSObject::putDirectIndex): (JSC::JSObject::canSetIndexQuicklyForPutDirect): Deleted. * runtime/JSType.h: 2017-05-05 Guillaume Emont [JSC] include JSCInlines.h in ObjectInitializationScope.cpp https://bugs.webkit.org/show_bug.cgi?id=171744 Reviewed by Mark Lam. * runtime/ObjectInitializationScope.cpp: 2017-05-05 Carlos Garcia Campos [GTK] Assertion failure in Inspector::RemoteInspector::setRemoteInspectorClient when disposing WebKitWebContext https://bugs.webkit.org/show_bug.cgi?id=171644 Reviewed by Michael Catanzaro. Fix ASSERT that requires given client to be a valid pointer, since it's valid to pass nullptr to unset the client. The ASSERT now ensures that client is set or unset. I also renamed the function to setClient because setRemoteInspectorClient is redundant for a class named RemoteInspector. And added a getter too, to check if the remote inspector has a client. * inspector/remote/RemoteInspector.cpp: (Inspector::RemoteInspector::setClient): * inspector/remote/RemoteInspector.h: 2017-05-04 Commit Queue Unreviewed, rolling out r216206. https://bugs.webkit.org/show_bug.cgi?id=171714 Multiple LayoutTests crashing in Document::page() (Requested by ap on #webkit). Reverted changeset: "Remove support for legacy Notifications" https://bugs.webkit.org/show_bug.cgi?id=171487 http://trac.webkit.org/changeset/216206 2017-05-04 Don Olmstead [Win] Remove redundant macros that are set in the CMake config https://bugs.webkit.org/show_bug.cgi?id=171571 Reviewed by Brent Fulgham. * config.h: 2017-05-04 Mark Lam Gardening: Build fix for Windows after r216217. https://bugs.webkit.org/show_bug.cgi?id=171586 Not reviewed. * shell/PlatformWin.cmake: 2017-05-04 Filip Pizlo JSC::Heap should expose a richer API for requesting GCs https://bugs.webkit.org/show_bug.cgi?id=171690 Reviewed by Geoffrey Garen. I want to stop WebCore from requesting synchronous GCs. But various parts of that work may cause regressions, so I'd like to land it separately from the functionality that is needed on the JSC side. This change is mostly a JSC-side refactoring that does not change behavior. In the future I'll land the behavior changes (i.e. not requesting sync GCs). This change allows you to enumerate over synchronousness, so that we can make all APIs take synchronousness as an argument. It replaces the collectAllGarbage API with a collectNow(Synchronousness, GCRequest) API. GCRequest is a new concept, which subsumes std::optional and gives us the ability to register callbacks along with a GC. So, you can ask for an async GC and get a callback when it's done. Also adds ability to request that fastMalloc memory be released after the incremental sweeper finishes. * API/JSBase.cpp: (JSSynchronousGarbageCollectForDebugging): * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * heap/FullGCActivityCallback.cpp: (JSC::FullGCActivityCallback::doCollection): * heap/FullGCActivityCallback.h: * heap/GCRequest.cpp: Added. (JSC::GCRequest::subsumedBy): (JSC::GCRequest::dump): * heap/GCRequest.h: Added. (JSC::GCRequest::GCRequest): * heap/Heap.cpp: (JSC::Heap::collect): (JSC::Heap::collectNow): (JSC::Heap::collectAsync): (JSC::Heap::collectSync): (JSC::Heap::runBeginPhase): (JSC::Heap::runEndPhase): (JSC::Heap::requestCollection): (JSC::Heap::willStartCollection): (JSC::Heap::sweeper): (JSC::Heap::collectNowFullIfNotDoneRecently): (JSC::Heap::shouldDoFullCollection): (JSC::Heap::collectAllGarbage): Deleted. (JSC::Heap::collectAllGarbageIfNotDoneRecently): Deleted. * heap/Heap.h: * heap/HeapSnapshotBuilder.cpp: (JSC::HeapSnapshotBuilder::buildSnapshot): * heap/IncrementalSweeper.cpp: (JSC::IncrementalSweeper::doSweep): * heap/IncrementalSweeper.h: (JSC::IncrementalSweeper::freeFastMallocMemoryAfterSweeping): * heap/MarkedAllocator.cpp: (JSC::MarkedAllocator::doTestCollectionsIfNeeded): * heap/MarkedSpace.cpp: (JSC::MarkedSpace::sweep): * heap/Synchronousness.cpp: Added. (WTF::printInternal): * heap/Synchronousness.h: Added. * inspector/agents/InspectorHeapAgent.cpp: (Inspector::InspectorHeapAgent::gc): * jsc.cpp: (functionGCAndSweep): (runJSC): * tools/JSDollarVMPrototype.cpp: (JSC::JSDollarVMPrototype::gc): * wasm/WasmMemory.cpp: 2017-05-04 Mark Lam NeverDestroyed(ASCIILiteral(...)) is not thread safe. https://bugs.webkit.org/show_bug.cgi?id=171586 Reviewed by Yusuke Suzuki. JavaScriptCore allows multiple VMs to be instantiated, and each of these should be able to run concurrently on different threads. There is code in the VM that allocates NeverDestroyed(ASCIILiteral(...)) to defined immortal strings meant to be shared by all VMs. However, NeverDestroyed(ASCIILiteral(...)) is not thread-safe because each thread will ref and deref the underlying StringImpl. Since this ref and deref is not done in a thread-safe way, the NeverDestroyed may get destroyed due to the ref/deref races. Additionally, each thread may modify the StringImpl by setting its hash and also twiddling its flags. The fix is to use the StaticStringImpl class which is safe for ref/derefing concurrently from different threads. StaticStringImpl is also pre-set with a hash on construction, and its flags are set in such a way as to prevent twiddling at runtime. Hence, we will be able to share a NeverDestroyed between VMs, as long as it is backed by a StaticStringImpl. An alternative solution would be to change all the uses of NeverDestroyed to use per-VM strings. However, this solution is cumbersome, and makes it harder to allocate the intended shared string. It also uses more memory and takes more CPU time because it requires allocating the same string for each VM instance. The StaticStringImpl solution wins out because it is more efficient and is easier to use. The StaticStringImpl solution also can be used in WTF without a layer violation. See Source/WTF/wtf/text/icu/TextBreakIteratorICU.h for an example. Also added the MultithreadedMultiVMExecutionTest which runs multiple VMs in multiple threads, all banging on the BuiltinExecutable's baseConstructorCode NeverDestroyed. The test will manifest the issue reliably (before this fix) if run on an ASAN build. * API/tests/MultithreadedMultiVMExecutionTest.cpp: Added. (threadsList): (startMultithreadedMultiVMExecutionTest): (finalizeMultithreadedMultiVMExecutionTest): * API/tests/MultithreadedMultiVMExecutionTest.h: Added. * API/tests/testapi.c: (main): * JavaScriptCore.xcodeproj/project.pbxproj: * builtins/BuiltinExecutables.cpp: (JSC::BuiltinExecutables::createDefaultConstructor): * inspector/agents/InspectorDebuggerAgent.cpp: (Inspector::objectGroupForBreakpointAction): * replay/scripts/CodeGeneratorReplayInputsTemplates.py: * replay/scripts/tests/expected/generate-enum-encoding-helpers-with-guarded-values.json-TestReplayInputs.cpp: (JSC::InputTraits::type): * replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.cpp: (JSC::InputTraits::type): * replay/scripts/tests/expected/generate-enum-with-guard.json-TestReplayInputs.cpp: (JSC::InputTraits::type): * replay/scripts/tests/expected/generate-enums-with-same-base-name.json-TestReplayInputs.cpp: (JSC::InputTraits::type): * replay/scripts/tests/expected/generate-input-with-guard.json-TestReplayInputs.cpp: (JSC::InputTraits::type): (JSC::InputTraits::type): * replay/scripts/tests/expected/generate-input-with-vector-members.json-TestReplayInputs.cpp: (JSC::InputTraits::type): (JSC::InputTraits::type): * replay/scripts/tests/expected/generate-inputs-with-flags.json-TestReplayInputs.cpp: (JSC::InputTraits::type): (JSC::InputTraits::type): * replay/scripts/tests/expected/generate-memoized-type-modes.json-TestReplayInputs.cpp: (JSC::InputTraits::type): (JSC::InputTraits::type): * runtime/IntlObject.cpp: (JSC::numberingSystemsForLocale): 2017-05-04 Sam Weinig Remove support for legacy Notifications https://bugs.webkit.org/show_bug.cgi?id=171487 Reviewed by Jon Lee. * Configurations/FeatureDefines.xcconfig: Remove definition of ENABLE_LEGACY_NOTIFICATIONS. 2017-05-04 Konstantin Tokarev Fix compilation with ICU 59.1 https://bugs.webkit.org/show_bug.cgi?id=171612 Reviewed by Mark Lam. ICU 59.1 has broken source compatibility. Now it defines UChar as char16_t, which does not allow automatic type conversion from unsigned short in C++ code. * API/JSStringRef.cpp: (JSStringCreateWithCharacters): (JSStringCreateWithCharactersNoCopy): (JSStringGetCharactersPtr): * runtime/DateConversion.cpp: (JSC::formatDateTime): 2017-05-04 Saam Barati stress/call-apply-exponential-bytecode-size.js.no-llint failing on 32-bit debug for OOM on executable memory https://bugs.webkit.org/show_bug.cgi?id=171008 Reviewed by Yusuke Suzuki. This patch lowers the threshold for .call/.apply recursion in an attempt to emit less code and not impact perf. We're currently failing tests on x86-32 by running out of executable memory. If perf gets impacted because of this, then I'll apply a stricter change just to 32-bit platforms. However, if this doesn't negatively impact perf, it's all around better than all platforms emit less bytecode. * bytecompiler/NodesCodegen.cpp: 2017-05-04 Yusuke Suzuki [JSC] Math unary functions should be handled by DFG https://bugs.webkit.org/show_bug.cgi?id=171269 Reviewed by Saam Barati. ArithSin, ArithCos, and ArithLog are just calling a C runtime function. While handling them in DFG is not very effective for performance, they can drop some type checks & value conversions and mark them as pure operations. It is effective if they are involved in some complex optimization phase. Actually, ArithLog is effective in kraken. While a few of Math functions have DFG nodes, basically math functions are pure. And large part of these functions are just calling a C runtime function. This patch generalizes these nodes in DFG as ArithUnary. And we annotate many unary math functions with Intrinsics and convert them to ArithUnary in DFG. It also cleans up duplicate code in ArithSin, ArithCos, and ArithLog. If your math function has some good DFG / FTL optimization rather than calling a C runtime function, you should add a specialized DFG node, like ArithSqrt. We also create a new namespace JSC::Math. Inside it, we collect math functions. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGArithMode.cpp: (JSC::DFG::arithUnaryFunction): (JSC::DFG::arithUnaryOperation): (WTF::printInternal): * dfg/DFGArithMode.h: * dfg/DFGBackwardsPropagationPhase.cpp: (JSC::DFG::BackwardsPropagationPhase::propagate): * 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/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGNode.h: (JSC::DFG::Node::hasArithUnaryType): (JSC::DFG::Node::arithUnaryType): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArithUnary): (JSC::DFG::SpeculativeJIT::compileArithCos): Deleted. (JSC::DFG::SpeculativeJIT::compileArithTan): Deleted. (JSC::DFG::SpeculativeJIT::compileArithSin): Deleted. (JSC::DFG::SpeculativeJIT::compileArithLog): Deleted. * 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::compileArithUnary): (JSC::FTL::DFG::LowerDFGToB3::compileArithSin): Deleted. (JSC::FTL::DFG::LowerDFGToB3::compileArithCos): Deleted. (JSC::FTL::DFG::LowerDFGToB3::compileArithTan): Deleted. (JSC::FTL::DFG::LowerDFGToB3::compileArithLog): Deleted. * ftl/FTLOutput.cpp: (JSC::FTL::Output::doubleUnary): (JSC::FTL::Output::doubleSin): Deleted. (JSC::FTL::Output::doubleCos): Deleted. (JSC::FTL::Output::doubleTan): Deleted. (JSC::FTL::Output::doubleLog): Deleted. * ftl/FTLOutput.h: * runtime/Intrinsic.h: * runtime/MathCommon.cpp: (JSC::Math::log1p): * runtime/MathCommon.h: * runtime/MathObject.cpp: (JSC::MathObject::finishCreation): (JSC::mathProtoFuncACos): (JSC::mathProtoFuncASin): (JSC::mathProtoFuncATan): (JSC::mathProtoFuncCos): (JSC::mathProtoFuncExp): (JSC::mathProtoFuncLog): (JSC::mathProtoFuncSin): (JSC::mathProtoFuncTan): (JSC::mathProtoFuncACosh): (JSC::mathProtoFuncASinh): (JSC::mathProtoFuncATanh): (JSC::mathProtoFuncCbrt): (JSC::mathProtoFuncCosh): (JSC::mathProtoFuncExpm1): (JSC::mathProtoFuncLog1p): (JSC::mathProtoFuncLog10): (JSC::mathProtoFuncLog2): (JSC::mathProtoFuncSinh): (JSC::mathProtoFuncTanh): 2017-05-03 Saam Barati How we build polymorphic cases is wrong when making a call from Wasm https://bugs.webkit.org/show_bug.cgi?id=171527 Reviewed by JF Bastien. This patches fixes a bug when we emit a polymorphic call IC from Wasm. We were incorrectly assuming that if we made a call *from wasm*, then the thing we are *calling to* does not have a CodeBlock. This is obviously wrong. This patch fixes the incorrect assumption. This patch also does two more things: 1. Add a new option that makes us make calls to JS using a slow path instead of using a call IC. 2. Fixes a potential GC bug where we didn't populate JSWebAssemblyCodeBlock's JSWebAssemblyModule pointer. * jit/Repatch.cpp: (JSC::linkPolymorphicCall): * runtime/Options.h: * wasm/WasmBinding.cpp: (JSC::Wasm::wasmToJs): * wasm/js/JSWebAssemblyCodeBlock.cpp: (JSC::JSWebAssemblyCodeBlock::create): (JSC::JSWebAssemblyCodeBlock::finishCreation): * wasm/js/JSWebAssemblyCodeBlock.h: * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::finalizeCreation): 2017-05-03 Keith Miller Array.prototype.sort should also allow a null comparator https://bugs.webkit.org/show_bug.cgi?id=171621 Reviewed by Michael Saboff. It looks like sort not accepting a null comparator causes some pages to stop working. Those pages work in Chrome/Firefox so we should try to match them. * builtins/ArrayPrototype.js: (sort): 2017-05-03 Mark Lam Use the CLoop for CPU(ARM64E). https://bugs.webkit.org/show_bug.cgi?id=171620 Reviewed by Geoffrey Garen. * llint/LLIntOfflineAsmConfig.h: * tools/SigillCrashAnalyzer.cpp: (JSC::SigillCrashAnalyzer::dumpCodeBlock): 2017-05-03 Keith Miller Different behaviour with the .sort(callback) method (unlike Firefox & Chrome) https://bugs.webkit.org/show_bug.cgi?id=47825 Reviewed by Saam Barati. This patch makes our sort function match the behavior of Firefox and Chrome when the result of the comparison function is a boolean. When we first switched to using merge sort, it regressed JQuery sorting of DOM nodes by 30%. The regression was do to the fact that JQuery was using compareDocumentPosition to compare the locations of objects. Since one of the benchmarks would pass a reverse sorted list to the sort function we would end up walking the entire DOM to do comparisons. The solution to this was to merge based on comparison(right, left) rather than comparison(left, right). Although, in practice this does nothing since sort could just as easily receive an already sorted list and we're back in the same spot. The downside of sorting with comparison(right, left) is that to maintain stability when sorting, you only want to merge from right when the comparison function returns a negative value. This is where the problem with booleans comes in. Since booleans toNumber false to 0 and true to 1 both values are "equal". This patch fixes this by special casing boolean return values. * builtins/ArrayPrototype.js: (sort.merge): 2017-05-03 Andy VanWagoner [INTL] Support dashed values in unicode locale extensions https://bugs.webkit.org/show_bug.cgi?id=171480 Reviewed by JF Bastien. Implements the UnicodeExtensionSubtags operation and updates the ResolveLocale operation to use it. This fixes locale extensions with values that include '-'. The following calendars work now: ethiopic-amete-alem islamic-umalqura islamic-tbla islamic-civil islamic-rgsa While updating IntlObject, the comments containing spec text were replaced with a single url at the top of each function pointing to the relevant part of ECMA-402. * runtime/IntlObject.cpp: (JSC::unicodeExtensionSubTags): Added. (JSC::resolveLocale): Updated to latest standard. 2017-05-02 Don Olmstead Build fix after r216078 https://bugs.webkit.org/show_bug.cgi?id=171554 Reviewed by Saam Barati. * API/tests/testapi.c: 2017-05-02 Filip Pizlo Unreviewed, fix pedantic C compilers. * API/tests/testapi.c: (markingConstraint): (testMarkingConstraints): 2017-05-02 Filip Pizlo Unreviewed, fix cmake build. * CMakeLists.txt: 2017-05-02 Filip Pizlo JSC C API should expose GC marking constraints and weak references https://bugs.webkit.org/show_bug.cgi?id=171554 Reviewed by Geoffrey Garen. This exposes an API that lets you participate in the GC's fixpoint. You can ask the GC what is marked and you can tell the GC to mark things. The constraint callback cannot do a whole lot, but it can query marking state and it can dereference weak references. Additionally, this exposes a very simple weak reference API in C. * API/JSMarkingConstraintPrivate.cpp: Added. (JSC::isMarked): (JSC::mark): (JSContextGroupRegisterMarkingConstraint): * API/JSMarkingConstraintPrivate.h: Added. * API/JSWeakPrivate.cpp: Added. (OpaqueJSWeak::OpaqueJSWeak): (JSWeakCreate): (JSWeakRetain): (JSWeakRelease): (JSWeakGetObject): * API/JSWeakPrivate.h: Added. * API/tests/testapi.c: (markingConstraint): (testMarkingConstraints): (main): * JavaScriptCore.xcodeproj/project.pbxproj: * heap/SlotVisitor.h: * heap/SlotVisitorInlines.h: (JSC::SlotVisitor::appendHiddenUnbarriered): (JSC::SlotVisitor::appendHidden): 2017-05-02 Mark Lam JSFixedArray::allocationSize() should not allow for allocation failure. https://bugs.webkit.org/show_bug.cgi?id=171516 Reviewed by Geoffrey Garen. Since JSFixedArray::createFromArray() now handles allocation failures by throwing OutOfMemoryErrors, its helper function allocationSize() (which computes the buffer size to allocate) should also allow for allocation failure on overflow. This issue is covered by the stress/js-fixed-array-out-of-memory.js test when run on 32-bit builds. * runtime/JSFixedArray.h: (JSC::JSFixedArray::tryCreate): (JSC::JSFixedArray::allocationSize): 2017-05-01 Zan Dobersek [aarch64][Linux] m_allowScratchRegister assert hit in MacroAssemblerARM64 under B3::Air::CCallSpecial::generate() https://bugs.webkit.org/show_bug.cgi?id=170672 Reviewed by Filip Pizlo. In Air::CCallSpecial::admitsStack() we reject admitting the callee argument on the stack for ARM64 because that can lead to disallowed usage of the scratch register in MacroAssemblerARM64 when generating a call with an address Arg in Air::CCallSpecial::generate(). The testLinearScanWithCalleeOnStack test is added to testb3. It reproduces the original issue by force-spilling everything on the stack and enforcing the use of the linear scan register allocation by using an optimization level of 1. * b3/air/AirCCallSpecial.cpp: (JSC::B3::Air::CCallSpecial::admitsStack): * b3/testb3.cpp: (JSC::B3::testLinearScanWithCalleeOnStack): (JSC::B3::run): 2017-05-01 David Kilzer Stop using sprintf() in JavaScriptCore debugger Reviewed by Keith Miller. * disassembler/udis86/udis86.c: (ud_insn_hex): Switch from sprintf() to snprintf(). 2017-04-21 Filip Pizlo Air::fixObviousSpills should remove totally redundant instructions https://bugs.webkit.org/show_bug.cgi?id=171131 Reviewed by Saam Barati. This is a modest compile-time-neutral improvement to fixObviousSpills. That phase builds up a classic alias analysis data structure over spills and registers and then uses it to remove the most common spill pathologies we encounter. For example, if you use a spill but the spill is aliased to a register or constant, then we can replace the use of the spill with a use of the register or constant. But that phase was missing perhaps one of the most obvious fixups that its analysis allows us to do: if any instruction creates an alias we already know about, then the instruction is redundant. This turned out to be super important for https://bugs.webkit.org/show_bug.cgi?id=171075. That patch didn't work out, but this kind of optimization might be a good clean-up for many other kinds of optimizations. * b3/air/AirFixObviousSpills.cpp: 2017-04-30 Oleksandr Skachkov We initialize functions too early in an eval https://bugs.webkit.org/show_bug.cgi?id=161099 Reviewed by Saam Barati. Current patch allow to fix problem with scope in function that is declared within eval. Before scope was set inside Interpretator.cpp and it was scope where eval is executed, but in this case function would not see let/const variables and classes declated in eval. This patch devide declaration and binding in two operation, first just declare variable with function name, and second bind variable to function with correct scope * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::generate): (JSC::BytecodeGenerator::BytecodeGenerator): * bytecompiler/BytecodeGenerator.h: * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): 2017-04-30 Oleksandr Skachkov [ES6]. Implement Annex B.3.3 function hoisting rules for eval https://bugs.webkit.org/show_bug.cgi?id=163208 Reviewed by Saam Barati. Current patch implements Annex B.3.3 that is related to hoisting of function declaration in eval. https://tc39.github.io/ecma262/#sec-web-compat-evaldeclarationinstantiation Function declaration in eval should create variable with function name in function scope where eval is invoked or bind to variable if it declared outside of the eval. If variable is created it can be removed by 'delete a;' command. If eval is invoke in block scope that contains let/const variable with the same name as function declaration we do not bind. This patch leads to the following behavior: ''' function foo() { { print(boo); // undefined eval('{ function boo() {}}'); print(boo); // function boo() {} } print(boo); // function boo() {} } function foobar() { { let boo = 10; print(boo); // 10; eval('{ function boo() {}}'); print(boo); // 10; } print(boo) // 10 } function bar() { { var boo = 10; print(boo); // 10 eval('{ function boo() {} }'); print(boo); // function boo() {} } print(boo); // function boo() {} } function bas() { { let boo = 10; eval(' { function boo() {} } '); print(boo); // 10 } print(boo); //Reference Error } ''' Current implementation relies on already implemented 'hoist function in sloppy mode' feature, with small changes. In short it works in following way: during hoisting of function with name S in eval, we are looking for first scope that contains space for variable with name S and if this scope has var type we bind function there To implement this feature was added bytecode ops: op_resolve_scope_for_hoisting_func_decl_in_eval - get variable scope or return undefined if variable can't be binded there. There is a corner case, hoist function in eval within catch block, that is not covered by this patch, and will be fixed in https://bugs.webkit.org/show_bug.cgi?id=168184 * bytecode/BytecodeDumper.cpp: (JSC::BytecodeDumper::dumpBytecode): * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finalizeLLIntInlineCaches): * bytecode/EvalCodeBlock.h: (JSC::EvalCodeBlock::functionHoistingCandidate): (JSC::EvalCodeBlock::numFunctionHoistingCandidates): * bytecode/UnlinkedEvalCodeBlock.h: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary): (JSC::BytecodeGenerator::emitResolveScopeForHoistingFuncDeclInEval): * bytecompiler/BytecodeGenerator.h: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNode.h: (JSC::DFG::Node::hasIdentifier): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileResolveScopeForHoistingFuncDeclInEval): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * 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::compileResolveScopeForHoistingFuncDeclInEval): * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JIT.h: * jit/JITOperations.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval): * llint/LowLevelInterpreter.asm: * parser/Parser.cpp: (JSC::Parser::parseFunctionDeclarationStatement): * parser/Parser.h: (JSC::Scope::getSloppyModeHoistedFunctions): (JSC::Parser::declareFunction): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: * runtime/EvalExecutable.h: (JSC::EvalExecutable::numFunctionHoistingCandidates): (JSC::EvalExecutable::numTopLevelFunctionDecls): (JSC::EvalExecutable::numberOfFunctionDecls): Deleted. * runtime/JSScope.cpp: (JSC::JSScope::resolve): (JSC::JSScope::resolveScopeForHoistingFuncDeclInEval): * runtime/JSScope.h: 2017-04-29 Oleksandr Skachkov Deep nesting is leading to ReferenceError for hoisted function https://bugs.webkit.org/show_bug.cgi?id=171456 Reviewed by Yusuke Suzuki. Current patch fix error that appears during hoisting of the function in block scope. Error happens only when exist some deep scope that lead to increase scope stack, after which list of the hosted candidates do not copied to updated scope stack. * parser/Parser.h: (JSC::Scope::Scope): 2017-04-29 Yusuke Suzuki [JSC] LabelScopePtr is not necessary https://bugs.webkit.org/show_bug.cgi?id=171474 Reviewed by Geoffrey Garen. Originally, LabelScopePtr is introduced because LabelScopes uses Vector<> instead of SegmentedVector<>. LabelScopePtr holds the pointer to the vector owner and index instead of the pointer to LabelScope directly since Vector<> can relocate LocalScopes inside it. The reason why LabelScopes use Vector instead is that there is code copying this vector. SegmentedVector<> prohibits copying since it is so costly. So, we used Vector<> here instead of SegmentedVector<>. But the latest code does not have copying code for LabelScopes. Thus, we can take the same design to Label and RegisterID. Just use SegmentedVector<> and Ref<>/RefPtr<>. This patch removes LabelScopePtr since it is no longer necessary. And use SegmentedVector for LabelScopes. * bytecompiler/BytecodeGenerator.cpp: (JSC::reclaim): (JSC::BytecodeGenerator::reclaimFreeRegisters): (JSC::BytecodeGenerator::newLabelScope): (JSC::BytecodeGenerator::newLabel): (JSC::BytecodeGenerator::pushFinallyControlFlowScope): (JSC::BytecodeGenerator::breakTarget): (JSC::BytecodeGenerator::continueTarget): (JSC::BytecodeGenerator::emitEnumeration): * bytecompiler/BytecodeGenerator.h: * bytecompiler/LabelScope.h: (JSC::LabelScope::LabelScope): (JSC::LabelScope::breakTarget): (JSC::LabelScope::continueTarget): (JSC::LabelScope::type): (JSC::LabelScope::name): (JSC::LabelScope::scopeDepth): (JSC::LabelScope::ref): (JSC::LabelScope::deref): (JSC::LabelScope::refCount): (JSC::LabelScopePtr::LabelScopePtr): Deleted. (JSC::LabelScopePtr::operator=): Deleted. (JSC::LabelScopePtr::~LabelScopePtr): Deleted. (JSC::LabelScopePtr::operator!): Deleted. (JSC::LabelScopePtr::operator*): Deleted. (JSC::LabelScopePtr::operator->): Deleted. (JSC::LabelScopePtr::null): Deleted. * bytecompiler/NodesCodegen.cpp: (JSC::DoWhileNode::emitBytecode): (JSC::WhileNode::emitBytecode): (JSC::ForNode::emitBytecode): (JSC::ForInNode::emitBytecode): (JSC::ContinueNode::trivialTarget): (JSC::ContinueNode::emitBytecode): (JSC::BreakNode::trivialTarget): (JSC::BreakNode::emitBytecode): (JSC::SwitchNode::emitBytecode): (JSC::LabelNode::emitBytecode): 2017-04-28 Mark Lam Revert instrumentation from https://bugs.webkit.org/show_bug.cgi?id=170086 that is no longer needed. https://bugs.webkit.org/show_bug.cgi?id=170094 Reviewed by JF Bastien and Keith Miller. * heap/Heap.cpp: (JSC::Heap::resumeThePeriphery): 2017-04-27 Andy VanWagoner [INTL] Implement the caseFirst option for Intl.Collator https://bugs.webkit.org/show_bug.cgi?id=158188 Reviewed by Geoffrey Garen. Implements the caseFirst option and unicode locale extension. The caseFirst option explicitly determines whether upper or lower case comes first. * runtime/IntlCollator.cpp: (JSC::sortLocaleData): Added kf data. (JSC::searchLocaleData): Added kf data. (JSC::IntlCollator::initializeCollator): Set caseFirst option. (JSC::IntlCollator::createCollator): Set new attributes on ICU collator. (JSC::IntlCollator::caseFirstString): Added. (JSC::IntlCollator::resolvedOptions): Added caseFirst property. * runtime/IntlCollator.h: 2017-04-27 Mark Lam Fix some RELEASE_ASSERT failures caused by OutOfMemoryErrors. https://bugs.webkit.org/show_bug.cgi?id=171404 Reviewed by Saam Barati. 1. Added some tryAllocate() functions in JSCellInlines.h. 2. Consolidated the implementations of allocateCell() template functions into a single tryAllocateCellHelper() to reduce redundancy and eliminate needing to copy-paste for variations of allocateCell and tryAllocateCell. 3. Changed JSFixedArray::createFromArray() and constructEmptyArray() to check for allocation failure and throw an OutOfMemoryError. It was already possible to throw errors from these functions for other reasons. So, their clients are already ready to handle OOMEs. * ftl/FTLOperations.cpp: (JSC::FTL::operationMaterializeObjectInOSR): * runtime/JSCInlines.h: * runtime/JSCell.h: * runtime/JSCellInlines.h: (JSC::tryAllocateCellHelper): (JSC::allocateCell): (JSC::tryAllocateCell): * runtime/JSFixedArray.h: (JSC::JSFixedArray::createFromArray): (JSC::JSFixedArray::tryCreate): (JSC::JSFixedArray::create): Deleted. * runtime/JSGlobalObject.h: (JSC::constructEmptyArray): 2017-04-27 Joseph Pecoraro Support for promise rejection events (unhandledrejection) https://bugs.webkit.org/show_bug.cgi?id=150358 Reviewed by Saam Barati. Patch by Joseph Pecoraro and Yusuke Suzuki. Implement support for promise.[[PromiseIsHandled]] and the HostPromiseRejectionTracker hook for HTML to track promise rejections: https://tc39.github.io/ecma262/#sec-host-promise-rejection-tracker https://html.spec.whatwg.org/multipage/webappapis.html#unhandled-promise-rejections * builtins/BuiltinNames.h: New private symbols. * builtins/PromiseOperations.js: (globalPrivate.newHandledRejectedPromise): Utility to create a rejected promise with [[PromiseIsHandled]] to true. (globalPrivate.rejectPromise): (globalPrivate.initializePromise): * builtins/PromisePrototype.js: (then): Implement standard behavior of [[PromiseIsHandled]] and the host hook. * runtime/JSPromise.cpp: (JSC::JSPromise::isHandled): * runtime/JSPromise.h: C++ accessors for the [[PromiseIsHandled]] state. * bytecode/BytecodeIntrinsicRegistry.cpp: (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry): * bytecode/BytecodeIntrinsicRegistry.h: Expose private values for the Reject / Handle enum values in built-ins. * jsc.cpp: * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::promiseResolveFunction): Add a new GlobalObjectMethodTable hook matching the promise rejection hook. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildren): * runtime/JSGlobalObjectFunctions.cpp: (JSC::globalFuncHostPromiseRejectionTracker): * runtime/JSGlobalObjectFunctions.h: Plumb the builtin hook through to the optional GlobalObjectMethodTable hook. * inspector/InjectedScriptSource.js: (InjectedScript.prototype.createFakeValueDescriptor): Silence possible rejected promises created internally via Web Inspector. 2017-04-27 Saam Barati B3::FoldPathConstants does not consider the fall through case for Switch https://bugs.webkit.org/show_bug.cgi?id=171390 Reviewed by Filip Pizlo. foldPathConstants was not taking into account a Switch's default case when it tried to constant propagate the switch's operand value. e.g, we incorrectly transformed this code: ``` x = argumentGPR0; switch (x) { case 10: return 20; case 0: default: return x == 0; } ``` into: ``` x = argumentGPR0; switch (x) { case 10: return 20; case 0: default: return 1; } ``` Because we didn't take into account the default case, we incorrectly optimized the code as if case 0's block was only reachable if x is equal to zero. This is obviously not true, since it's the same block as the default case. This fix ensures that we can run the WebAssembly Tanks demo even when we set webAssemblyBBQOptimizationLevel=2. * b3/B3FoldPathConstants.cpp: * b3/B3SwitchValue.cpp: (JSC::B3::SwitchValue::fallThrough): (JSC::B3::SwitchValue::removeCase): Deleted. * b3/B3SwitchValue.h: * b3/testb3.cpp: (JSC::B3::testCallFunctionWithHellaArguments): (JSC::B3::testSwitchSameCaseAsDefault): (JSC::B3::testWasmBoundsCheck): (JSC::B3::run): 2017-04-27 Keith Miller WebAssembly: Don't tier up the same function twice https://bugs.webkit.org/show_bug.cgi?id=171397 Reviewed by Filip Pizlo. Because we don't CAS the tier up count on function entry/loop backedge and we use the least significant to indicate whether or not tier up has already started we could see the following: Threads A and B are running count in memory is (0): A: load tier up count (0) B: load tier up count (0) A: decrement count to -2 and see we need to check for tier up (0) A: store -2 to count (-2) A: exchangeOr(1) to tier up count (-1) B: decrement count to -2 and see we need to check for tier up (-1) B: store -2 to count (-2) B: exchangeOr(1) to tier up count (-1) This would cause us to tier up the same function twice, which we would rather avoid. * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::emitTierUpCheck): * wasm/WasmTierUpCount.h: (JSC::Wasm::TierUpCount::TierUpCount): (JSC::Wasm::TierUpCount::loopDecrement): (JSC::Wasm::TierUpCount::functionEntryDecrement): (JSC::Wasm::TierUpCount::shouldStartTierUp): 2017-04-27 Keith Miller REGRESSION (r215843): ASSERTION FAILED: !m_completionTasks[0].first in JSC::Wasm::Plan::tryRemoveVMAndCancelIfLast(JSC::VM &) https://bugs.webkit.org/show_bug.cgi?id=171380 Reviewed by JF Bastien. This patch fixes the association of VMs to Wasm::Plans. For validation we want all the completion tasks to be associate with a VM. For BBQ, we want the main task to not be associated with any VM. * jsc.cpp: (functionTestWasmModuleFunctions): * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::BBQPlan): * wasm/WasmBBQPlan.h: * wasm/WasmCodeBlock.cpp: (JSC::Wasm::CodeBlock::CodeBlock): (JSC::Wasm::CodeBlock::compileAsync): * wasm/WasmCodeBlock.h: (JSC::Wasm::CodeBlock::create): * wasm/WasmModule.cpp: (JSC::Wasm::makeValidationCallback): (JSC::Wasm::Module::validateSync): (JSC::Wasm::Module::validateAsync): (JSC::Wasm::Module::getOrCreateCodeBlock): (JSC::Wasm::Module::compileSync): (JSC::Wasm::Module::compileAsync): * wasm/WasmModule.h: * wasm/WasmOMGPlan.cpp: (JSC::Wasm::OMGPlan::OMGPlan): (JSC::Wasm::runOMGPlanForIndex): * wasm/WasmOMGPlan.h: * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::Plan): (JSC::Wasm::Plan::runCompletionTasks): (JSC::Wasm::Plan::addCompletionTask): (JSC::Wasm::Plan::tryRemoveVMAndCancelIfLast): * wasm/WasmPlan.h: (JSC::Wasm::Plan::dontFinalize): * wasm/js/WebAssemblyInstanceConstructor.cpp: (JSC::constructJSWebAssemblyInstance): * wasm/js/WebAssemblyPrototype.cpp: (JSC::webAssemblyValidateFunc): 2017-04-27 Saam Barati Restore some caching functionality that got accidentally removed when doing Wasm PIC patches https://bugs.webkit.org/show_bug.cgi?id=171382 Reviewed by Keith Miller. When I created Wasm::CodeBlock, I accidentally removed caching the creation of JSWebAssemblyCodeBlocks. This patch restores it. It's worth keeping JSWebAssemblyModule's JSWebAssemblyCodeBlock cache because creating a JSWebAssemblyCodeBlock does non trivial work by creating the various IC call stubs. * wasm/js/JSWebAssemblyCodeBlock.h: (JSC::JSWebAssemblyCodeBlock::codeBlock): * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::finalizeCreation): (JSC::JSWebAssemblyInstance::create): * wasm/js/JSWebAssemblyModule.h: 2017-04-27 Mark Lam Audit and fix incorrect uses of JSArray::tryCreateForInitializationPrivate(). https://bugs.webkit.org/show_bug.cgi?id=171344 Reviewed by Filip Pizlo. JSArray::tryCreateForInitializationPrivate() should only be used in performance critical paths, and should always be used with care because it creates an uninitialized object that needs to be initialized by its client before the object can be released into the system. Before the object is fully initialized: a. the client should not re-enter the VM to execute JS code, and b. GC should not run. This is because until the object is fully initialized, it is an inconsistent state that the GC and JS code will not be happy about. In this patch, we do the following: 1. Renamed JSArray::tryCreateForInitializationPrivate() to JSArray::tryCreateUninitializedRestricted() because "private" is a bit ambiguous and can be confused with APIs that are called freely within WebKit but are not meant for clients of WebKit. In this case, we intend for use of this API to be restricted to only a few carefully considered and crafted cases. 2. Introduce the ObjectInitializationScope RAII object which covers the period when the uninitialized object is created and gets initialized. ObjectInitializationScope will asserts that either the object is created fully initialized (in the case where the object structure is not an "original" structure) or if created uninitialized, is fully initialized at the end of the scope. If the object is created uninitialized, the ObjectInitializationScope also ensures that we do not GC nor re-enter the VM to execute JS code. This is achieved by enabling DisallowGC and DisallowVMReentry scopes. tryCreateUninitializedRestricted() and initializeIndex() now requires an ObjectInitializationScope instance. The ObjectInitializationScope replaces the VM& argument because it can be used to pass the VM& itself. This is a small optimization that makes passing the ObjectInitializationScope free even on release builds. 3. Factored a DisallowScope out of DisallowGC, and make DisallowGC extend it. Introduce a DisallowVMReentry class that extends DisallowScope. 4. Fixed a bug found by the ObjectInitializationScope. The bug is that there are scenarios where the structure passed to tryCreateUninitializedRestricted() that may not be an "original" structure. As a result, initializeIndex() would end up allocating new structures, and therefore trigger a GC. The fix is to detect that the structure passed to tryCreateUninitializedRestricted() is not an "original" one, and pre-initialize the array with 0s. This bug was detected by existing tests. Hence, no new test needed. 5. Replaced all inappropriate uses of tryCreateUninitializedRestricted() with tryCreate(). Inappropriate uses here means code that is not in performance critical paths. Similarly, replaced accompanying uses of initializeIndex() with putDirectIndex(). This patch is performance neutral (according to the JSC command line benchmarks). * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGOperations.cpp: * ftl/FTLOperations.cpp: (JSC::FTL::operationMaterializeObjectInOSR): * heap/DeferGC.cpp: * heap/DeferGC.h: (JSC::DisallowGC::DisallowGC): (JSC::DisallowGC::initialize): (JSC::DisallowGC::scopeReentryCount): (JSC::DisallowGC::setScopeReentryCount): (JSC::DisallowGC::~DisallowGC): Deleted. (JSC::DisallowGC::isGCDisallowedOnCurrentThread): Deleted. * heap/GCDeferralContextInlines.h: (JSC::GCDeferralContext::~GCDeferralContext): * heap/Heap.cpp: (JSC::Heap::collectIfNecessaryOrDefer): * runtime/ArrayPrototype.cpp: (JSC::arrayProtoPrivateFuncConcatMemcpy): * runtime/ClonedArguments.cpp: (JSC::ClonedArguments::createWithInlineFrame): (JSC::ClonedArguments::createByCopyingFrom): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/DisallowScope.h: Added. (JSC::DisallowScope::DisallowScope): (JSC::DisallowScope::~DisallowScope): (JSC::DisallowScope::isInEffectOnCurrentThread): (JSC::DisallowScope::enable): (JSC::DisallowScope::enterScope): (JSC::DisallowScope::exitScope): * runtime/DisallowVMReentry.cpp: Added. * runtime/DisallowVMReentry.h: Added. (JSC::DisallowVMReentry::DisallowVMReentry): (JSC::DisallowVMReentry::initialize): (JSC::DisallowVMReentry::scopeReentryCount): (JSC::DisallowVMReentry::setScopeReentryCount): * runtime/InitializeThreading.cpp: (JSC::initializeThreading): * runtime/JSArray.cpp: (JSC::JSArray::tryCreateUninitializedRestricted): (JSC::JSArray::fastSlice): (JSC::JSArray::tryCreateForInitializationPrivate): Deleted. * runtime/JSArray.h: (JSC::JSArray::tryCreateUninitializedRestricted): (JSC::JSArray::tryCreate): (JSC::constructArray): (JSC::constructArrayNegativeIndexed): (JSC::JSArray::tryCreateForInitializationPrivate): Deleted. (JSC::createArrayButterfly): Deleted. * runtime/JSCellInlines.h: (JSC::allocateCell): * runtime/JSObject.h: (JSC::JSObject::initializeIndex): (JSC::JSObject::initializeIndexWithoutBarrier): * runtime/ObjectInitializationScope.cpp: Added. (JSC::ObjectInitializationScope::ObjectInitializationScope): (JSC::ObjectInitializationScope::~ObjectInitializationScope): (JSC::ObjectInitializationScope::notifyAllocated): (JSC::ObjectInitializationScope::verifyPropertiesAreInitialized): * runtime/ObjectInitializationScope.h: Added. (JSC::ObjectInitializationScope::ObjectInitializationScope): (JSC::ObjectInitializationScope::vm): (JSC::ObjectInitializationScope::notifyAllocated): * runtime/Operations.h: (JSC::isScribbledValue): (JSC::scribble): * runtime/RegExpMatchesArray.cpp: (JSC::createEmptyRegExpMatchesArray): * runtime/RegExpMatchesArray.h: (JSC::tryCreateUninitializedRegExpMatchesArray): (JSC::createRegExpMatchesArray): * runtime/VMEntryScope.cpp: (JSC::VMEntryScope::VMEntryScope): 2017-04-27 Carlos Garcia Campos [GTK] Remote inspector should support inspecting targets with previous version of backend commands https://bugs.webkit.org/show_bug.cgi?id=171267 Reviewed by Michael Catanzaro. Rename GetTargetList DBus method as SetupInspectorClient since this method is actually called only once by client right after connecting to the server. The method now receives the client backend commands hash as argument and returns the contents of the backend commands file in case the hash doesn't match with the local version. * PlatformGTK.cmake: Add RemoteInspectorUtils to compilation. * inspector/remote/glib/RemoteInspectorServer.cpp: (Inspector::RemoteInspectorServer::setupInspectorClient): * inspector/remote/glib/RemoteInspectorServer.h: * inspector/remote/glib/RemoteInspectorUtils.cpp: Added. (Inspector::backendCommands): (Inspector::backendCommandsHash): * inspector/remote/glib/RemoteInspectorUtils.h: Added. 2017-04-27 Yusuke Suzuki [JSC] Handle PhantomSpread in LoadVarargs as the same to the others https://bugs.webkit.org/show_bug.cgi?id=171262 Reviewed by Saam Barati. This is follow-up patch after r215720. In that patch, accidentally we did not apply the same change to LoadVarargs in argument elimination phase. This patch just does the same rewriting to handle PhantomSpread correctly. * dfg/DFGArgumentsEliminationPhase.cpp: 2017-04-26 Joseph Pecoraro Web Inspector: Uint8ClampedArray should be treated like an array, not an object https://bugs.webkit.org/show_bug.cgi?id=171364 Reviewed by Sam Weinig. * inspector/JSInjectedScriptHost.cpp: (Inspector::JSInjectedScriptHost::subtype): Treat Uint8ClampedArray (like other Typed Arrays) as an array. 2017-04-26 Saam Barati Print Wasm function index in stack trace https://bugs.webkit.org/show_bug.cgi?id=171349 Reviewed by JF Bastien. This patch prints a Callee's index in the function index space in Error.stack. This will lead to stack traces that have lines of text like: wasm function index: 4@[wasm code] We don't ascribe indices to everything in wasm. Specifically, the Wasm->JS call stub callee does not get a name, and neither does the JS -> Wasm entrypoint. * interpreter/Interpreter.cpp: (JSC::GetStackTraceFunctor::operator()): * interpreter/StackVisitor.cpp: (JSC::StackVisitor::readNonInlinedFrame): (JSC::StackVisitor::Frame::functionName): * interpreter/StackVisitor.h: (JSC::StackVisitor::Frame::wasmFunctionIndex): * runtime/StackFrame.cpp: (JSC::StackFrame::functionName): * runtime/StackFrame.h: (JSC::StackFrame::StackFrame): (JSC::StackFrame::wasm): (JSC::StackFrame::hasBytecodeOffset): (JSC::StackFrame::bytecodeOffset): * wasm/WasmBBQPlanInlines.h: (JSC::Wasm::BBQPlan::initializeCallees): * wasm/WasmCallee.cpp: (JSC::Wasm::Callee::Callee): * wasm/WasmCallee.h: (JSC::Wasm::Callee::create): (JSC::Wasm::Callee::index): * wasm/WasmOMGPlan.cpp: (JSC::Wasm::OMGPlan::work): 2017-04-26 Keith Miller Follow up to r215843 https://bugs.webkit.org/show_bug.cgi?id=171361 Reviewed by Saam Barati. This patch fixes some style comments Saam didn't get a chance to request before I landed: https://bugs.webkit.org/show_bug.cgi?id=170134. It renames Wasm::CodeBlock::m_wasmEntrypoints to m_wasmIndirectCallEntrypoints, as well as fixes some copyrights and indentation. * wasm/WasmBBQPlan.cpp: * wasm/WasmCodeBlock.cpp: (JSC::Wasm::CodeBlock::CodeBlock): * wasm/WasmCodeBlock.h: (JSC::Wasm::CodeBlock::wasmEntrypointLoadLocationFromFunctionIndexSpace): * wasm/WasmOMGPlan.cpp: (JSC::Wasm::OMGPlan::work): * wasm/WasmTierUpCount.h: (JSC::Wasm::TierUpCount::TierUpCount): (JSC::Wasm::TierUpCount::loopDecrement): (JSC::Wasm::TierUpCount::functionEntryDecrement): (JSC::Wasm::TierUpCount::shouldStartTierUp): (JSC::Wasm::TierUpCount::count): 2017-04-26 Saam Barati ASSERTION FAILED: inIndex != notFound in JSC::invalidParameterInSourceAppender() https://bugs.webkit.org/show_bug.cgi?id=170924 Reviewed by Mark Lam. The error message handler for "in" was searching for the literal string "in". However, our parser incorrectly allows escaped characters to be part of keywords. So this is parsed as "in" in JSC: "i\u006E". It should not be parsed that way. I opened https://bugs.webkit.org/show_bug.cgi?id=171310 to address this issue. Regardless, the error message handlers should handle unexpected text gracefully. All functions that try to augment error messages with the goal of providing a more textual context for the error message should use the original error message instead of crashing when they detect unexpected text. This patch also changes the already buggy code that tries to find the base of a function call. That could would fail for code like this: "zoo.bar("/abc\)*/");". See https://bugs.webkit.org/show_bug.cgi?id=146304 It would think that the base is "z". However, the algorithm that tries to find the base can often tell when it fails, and when it does, it should happily return the approximate text error message instead of thinking that the base is "z". * runtime/ExceptionHelpers.cpp: (JSC::functionCallBase): (JSC::notAFunctionSourceAppender): (JSC::invalidParameterInSourceAppender): 2017-04-26 Keith Miller WebAssembly: Implement tier up https://bugs.webkit.org/show_bug.cgi?id=170134 Reviewed by Filip Pizlo. This patch implements tier up for wasm functions. Unlike with JS code, wasm code needs to be able to tier up concurrently with the running code. Since JS code is synchronous we can always link on the running thread, wasm, however, can run the same code on more than one thread. In order to make patching work correctly, we need to ensure that all patches of callsites are aligned. On ARM we get this for free since every call is a near call. On X86 we ensure that the 32-bit relative offset is 32-bit aligned. This patch also modifies how Wasm::Plan works. Now Plan is a abstract super class and there are two subclasses, which correspond to the different tiers of our wasm engine. The first, Build Bytecode Quickly (BBQ) tier, roughly does what the old plan code did before. The new tier, Optimized Machine code Generation (OMG), can be called at any point by BBQ code and compiles exactly one function. Once an OMGPlan finishes it will link it's code internally then reset the instruction cache of all running wasm threads, via, a ThreadMessage. Once the instruction caches have been reset all the other functions will be patched to call the new code. * JavaScriptCore.xcodeproj/project.pbxproj: * assembler/AbstractMacroAssembler.h: (JSC::AbstractMacroAssembler::ensureCacheLineSpace): * assembler/CodeLocation.h: (JSC::CodeLocationThreadSafeNearCall::CodeLocationThreadSafeNearCall): * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::threadSafePatchableNearCall): * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::threadSafeNearCall): * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::threadSafePatchableNearCall): * b3/air/AirEmitShuffle.cpp: (JSC::B3::Air::ShufflePair::inst): (JSC::B3::Air::ShufflePair::opcode): Deleted. * b3/air/AirEmitShuffle.h: * jsc.cpp: (functionTestWasmModuleFunctions): * runtime/JSLock.cpp: (JSC::JSLock::didAcquireLock): * runtime/Options.h: * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::materializeWasmContext): (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::B3IRGenerator::constant): (JSC::Wasm::B3IRGenerator::emitTierUpCheck): (JSC::Wasm::B3IRGenerator::addLoop): (JSC::Wasm::B3IRGenerator::addTopLevel): (JSC::Wasm::B3IRGenerator::addBlock): (JSC::Wasm::createJSToWasmWrapper): (JSC::Wasm::parseAndCompile): * wasm/WasmB3IRGenerator.h: * wasm/WasmBBQPlan.cpp: Copied from Source/JavaScriptCore/wasm/WasmPlan.cpp. (JSC::Wasm::BBQPlan::BBQPlan): (JSC::Wasm::BBQPlan::stateString): (JSC::Wasm::BBQPlan::moveToState): (JSC::Wasm::BBQPlan::parseAndValidateModule): (JSC::Wasm::BBQPlan::prepare): (JSC::Wasm::BBQPlan::ThreadCountHolder::ThreadCountHolder): (JSC::Wasm::BBQPlan::ThreadCountHolder::~ThreadCountHolder): (JSC::Wasm::BBQPlan::compileFunctions): (JSC::Wasm::BBQPlan::complete): (JSC::Wasm::BBQPlan::work): * wasm/WasmBBQPlan.h: Copied from Source/JavaScriptCore/wasm/WasmPlan.h. * wasm/WasmBBQPlanInlines.h: Copied from Source/JavaScriptCore/wasm/WasmPlanInlines.h. (JSC::Wasm::BBQPlan::initializeCallees): * wasm/WasmBinding.cpp: (JSC::Wasm::wasmToWasm): * wasm/WasmCallee.h: (JSC::Wasm::Callee::entrypoint): * wasm/WasmCodeBlock.cpp: (JSC::Wasm::CodeBlock::CodeBlock): * wasm/WasmCodeBlock.h: (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace): (JSC::Wasm::CodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace): (JSC::Wasm::CodeBlock::wasmEntrypointLoadLocationFromFunctionIndexSpace): (JSC::Wasm::CodeBlock::tierUpCount): (JSC::Wasm::CodeBlock::mode): * wasm/WasmFormat.h: (JSC::Wasm::CallableFunction::CallableFunction): (JSC::Wasm::CallableFunction::offsetOfWasmEntrypointLoadLocation): * wasm/WasmMachineThreads.cpp: Copied from Source/JavaScriptCore/wasm/WasmPlanInlines.h. (JSC::Wasm::wasmThreads): (JSC::Wasm::startTrackingCurrentThread): (JSC::Wasm::resetInstructionCacheOnAllThreads): * wasm/WasmMachineThreads.h: Copied from Source/JavaScriptCore/wasm/WasmCallee.h. * wasm/WasmModule.cpp: (JSC::Wasm::makeValidationResult): (JSC::Wasm::makeValidationCallback): (JSC::Wasm::Module::validateSync): (JSC::Wasm::Module::validateAsync): * wasm/WasmModule.h: (JSC::Wasm::Module::codeBlockFor): * wasm/WasmOMGPlan.cpp: Added. (JSC::Wasm::OMGPlan::OMGPlan): (JSC::Wasm::OMGPlan::work): (JSC::Wasm::runOMGPlanForIndex): * wasm/WasmOMGPlan.h: Copied from Source/JavaScriptCore/wasm/WasmPlanInlines.h. * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::Plan): (JSC::Wasm::Plan::runCompletionTasks): (JSC::Wasm::Plan::addCompletionTask): (JSC::Wasm::Plan::waitForCompletion): (JSC::Wasm::Plan::tryRemoveVMAndCancelIfLast): (JSC::Wasm::Plan::fail): (JSC::Wasm::Plan::stateString): Deleted. (JSC::Wasm::Plan::moveToState): Deleted. (JSC::Wasm::Plan::parseAndValidateModule): Deleted. (JSC::Wasm::Plan::prepare): Deleted. (JSC::Wasm::Plan::ThreadCountHolder::ThreadCountHolder): Deleted. (JSC::Wasm::Plan::ThreadCountHolder::~ThreadCountHolder): Deleted. (JSC::Wasm::Plan::compileFunctions): Deleted. (JSC::Wasm::Plan::complete): Deleted. * wasm/WasmPlan.h: (JSC::Wasm::Plan::exports): Deleted. (JSC::Wasm::Plan::internalFunctionCount): Deleted. (JSC::Wasm::Plan::takeModuleInformation): Deleted. (JSC::Wasm::Plan::takeCallLinkInfos): Deleted. (JSC::Wasm::Plan::takeWasmToWasmExitStubs): Deleted. (JSC::Wasm::Plan::hasWork): Deleted. (JSC::Wasm::Plan::hasBeenPrepared): Deleted. * wasm/WasmTierUpCount.h: Renamed from Source/JavaScriptCore/wasm/WasmPlanInlines.h. (JSC::Wasm::TierUpCount::TierUpCount): (JSC::Wasm::TierUpCount::loopDecrement): (JSC::Wasm::TierUpCount::functionEntryDecrement): (JSC::Wasm::TierUpCount::shouldStartTierUp): (JSC::Wasm::TierUpCount::count): * wasm/WasmWorklist.cpp: * wasm/WasmWorklist.h: (JSC::Wasm::Worklist::nextTicket): * wasm/js/JSWebAssemblyCodeBlock.cpp: * wasm/js/JSWebAssemblyCodeBlock.h: (JSC::JSWebAssemblyCodeBlock::wasmEntrypointLoadLocationFromFunctionIndexSpace): (JSC::JSWebAssemblyCodeBlock::wasmToJsCallStubForImport): (JSC::JSWebAssemblyCodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace): Deleted. * wasm/js/JSWebAssemblyTable.cpp: (JSC::JSWebAssemblyTable::setFunction): * wasm/js/WebAssemblyFunction.cpp: (JSC::WebAssemblyFunction::create): (JSC::WebAssemblyFunction::WebAssemblyFunction): * wasm/js/WebAssemblyFunction.h: (JSC::WebAssemblyFunction::signatureIndex): (JSC::WebAssemblyFunction::wasmEntrypointLoadLocation): (JSC::WebAssemblyFunction::callableFunction): (JSC::WebAssemblyFunction::offsetOfWasmEntrypointLoadLocation): (JSC::WebAssemblyFunction::wasmEntrypoint): Deleted. (JSC::WebAssemblyFunction::offsetOfWasmEntrypoint): Deleted. * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::link): (JSC::WebAssemblyModuleRecord::evaluate): * wasm/js/WebAssemblyPrototype.cpp: (JSC::webAssemblyValidateFunc): * wasm/js/WebAssemblyWrapperFunction.cpp: (JSC::WebAssemblyWrapperFunction::WebAssemblyWrapperFunction): (JSC::WebAssemblyWrapperFunction::create): * wasm/js/WebAssemblyWrapperFunction.h: (JSC::WebAssemblyWrapperFunction::signatureIndex): (JSC::WebAssemblyWrapperFunction::wasmEntrypointLoadLocation): (JSC::WebAssemblyWrapperFunction::callableFunction): (JSC::WebAssemblyWrapperFunction::wasmEntrypoint): Deleted. 2017-04-26 Caitlin Potter [JSC] fix RETURN_IF_EXCEPTION() placement in ownPropertyKeys() https://bugs.webkit.org/show_bug.cgi?id=171330 Reviewed by Mark Lam. Ensure RETURN_IF_EXCEPTION() following invokation of the filterPropertyIfNeeded() lambda. * runtime/ObjectConstructor.cpp: (JSC::ownPropertyKeys): 2017-04-26 Caitlin Potter [JSC] Object.keys() must discard property names with no PropertyDescriptor https://bugs.webkit.org/show_bug.cgi?id=171291 Reviewed by Yusuke Suzuki. Proxy objects can produce an arbitrary list of property names from the "ownKeys" trap, however the Object.keys() algorithm is required to discard names which do not have a PropertyDescriptor. This also applies to other uses of the EnumerableOwnProperties() algorithm (https://tc39.github.io/ecma262/#sec-enumerableownproperties) Related to https://bugs.chromium.org/p/v8/issues/detail?id=6290 * runtime/ObjectConstructor.cpp: (JSC::ownPropertyKeys): 2017-04-25 Andy VanWagoner Unhandled enumeration values in IntlDateTimeFormat.cpp https://bugs.webkit.org/show_bug.cgi?id=171241 Reviewed by JF Bastien. Added some missing cases of the UDateFormatField to partTypeString, and made them conditional to the ICU version that added them. This should remove the warnings that appear on platform builds using the newer system ICU headers. * runtime/IntlDateTimeFormat.cpp: (JSC::IntlDateTimeFormat::partTypeString): 2017-04-25 Commit Queue Unreviewed, rolling out r215476. https://bugs.webkit.org/show_bug.cgi?id=171304 "It broke JSBench" (Requested by saamyjoon on #webkit). Reverted changeset: "[ES6]. Implement Annex B.3.3 function hoisting rules for eval" https://bugs.webkit.org/show_bug.cgi?id=163208 http://trac.webkit.org/changeset/215476 2017-04-25 Saam Barati JSArray::isArrayPrototypeIteratorProtocolFastAndNonObservable is wrong because it does not do the necessary checks on the base object https://bugs.webkit.org/show_bug.cgi?id=171150 Reviewed by Sam Weinig. This patch fixes a huge oversight from the patch that introduced op_spread/Spread. The original patch did not account for the base object having Symbol.iterator or getters that could change the iterator protocol. This patch fixes the oversight both in the C code, as well as the DFG/FTL backends. We only perform the memcpy version of spread if we've proven that it's guaranteed to be side-effect free (no indexed getters), and if the iterator protocol is guaranteed to be the original protocol. To do this, we must prove that: 1. The protocol on Array.prototype hasn't changed (this is the same as the introductory patch for op_spread). 2. The base object's __proto__ is Array.prototype 3. The base object does not have indexed getters 4. The base object does not have Symbol.iterator property. * dfg/DFGGraph.cpp: (JSC::DFG::Graph::canDoFastSpread): * dfg/DFGGraph.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileSpread): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileSpread): * runtime/JSArray.cpp: (JSC::JSArray::isIteratorProtocolFastAndNonObservable): * runtime/JSArray.h: * runtime/JSArrayInlines.h: (JSC::JSArray::isIteratorProtocolFastAndNonObservable): Deleted. * runtime/JSGlobalObject.h: * runtime/JSGlobalObjectInlines.h: (JSC::JSGlobalObject::isArrayPrototypeIteratorProtocolFastAndNonObservable): (JSC::JSGlobalObject::isArrayIteratorProtocolFastAndNonObservable): Deleted. 2017-04-25 Mark Lam Array.prototype.slice() should ensure that end >= begin. https://bugs.webkit.org/show_bug.cgi?id=170989 Reviewed by Saam Barati. * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncSlice): 2017-04-25 Don Olmstead [Win] Use Clang's __has_declspec_attribute for export macros https://bugs.webkit.org/show_bug.cgi?id=171240 Reviewed by Alex Christensen. * runtime/JSExportMacros.h: 2017-04-25 Saam Barati Unreviewed. Attempt armv7k build fix after r215720 I think we're just missing an include for the definition of ExecState::r(). * runtime/JSFixedArray.cpp: 2017-04-25 Daniel Bates [Cocoa][Win] Enable of X-Content-Type-Options: nosniff header https://bugs.webkit.org/show_bug.cgi?id=136452 Reviewed by Brent Fulgham. Enable X-Content-Type-Options: nosniff on Mac, iOS and Windows platforms. * Configurations/FeatureDefines.xcconfig: 2017-04-25 Mark Lam Local CSE wrongly CSEs array accesses with different result types. https://bugs.webkit.org/show_bug.cgi?id=170990 Reviewed by Saam Barati. The fix is to use different LocationKind enums for the different type of array result types. This makes the HeapLocation values different based on the result types, and allows CSE to discern between them. * dfg/DFGCSEPhase.cpp: * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGHeapLocation.cpp: (WTF::printInternal): * dfg/DFGHeapLocation.h: (JSC::DFG::indexedPropertyLocForResultType): 2017-04-25 Mark Lam Make DFG SpeculatedType dumps easier to read. https://bugs.webkit.org/show_bug.cgi?id=171280 Reviewed by Saam Barati. Adding a pretty printer to insert |s between each type string and changing the dumped strings to match the SpeculatedType names case-wise. * bytecode/SpeculatedType.cpp: (JSC::PrettyPrinter::PrettyPrinter): (JSC::PrettyPrinter::print): (JSC::dumpSpeculation): * bytecode/SpeculatedType.h: 2017-04-25 JF Bastien lowerStackArgs: check Arg::addr.isValidForm when falling back to SP offsets https://bugs.webkit.org/show_bug.cgi?id=171278 Reviewed by Filip Pizlo. lowerStackArgs checked that the FP offsets it tries to generate are valid form, but didn't check that the fallback was valid form. This lead to stackAddr's assertion being dead, and the MaroAssembler asserting way later on move / add when handed a huge immediate. * b3/air/AirArg.cpp: (JSC::B3::Air::Arg::stackAddrImpl): 2017-04-25 Zan Dobersek [aarch64] moveConditionally32(), moveConditionallyTest32() should move from/to 64-bit registers https://bugs.webkit.org/show_bug.cgi?id=170891 Reviewed by Saam Barati. moveConditionally32() and moveConditionallyTest32() operations in MacroAssemblerARM64 properly perform comparisons and tests on 32-bit values, but end up performing the moves from and to 32-bit registers. Move operations should instead be done on 64-bit registers, just like on the X86_64 platform. This is achieved by specifying 64 as the data size for the csel instructions. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::moveConditionally32): (JSC::MacroAssemblerARM64::moveConditionallyTest32): 2017-04-24 Joseph Pecoraro test262: test262/test/language/expressions/object/method-definition/early-errors-object-method-duplicate-parameters.js https://bugs.webkit.org/show_bug.cgi?id=171190 Reviewed by Saam Barati. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon): (JSC::BytecodeGenerator::emitNewFunction): * bytecompiler/NodesCodegen.cpp: (JSC::FunctionNode::emitBytecode): (JSC::Scope::setSourceParseMode): * parser/ParserModes.h: (JSC::isFunctionParseMode): (JSC::isMethodParseMode): (JSC::isGeneratorOrAsyncFunctionWrapperParseMode): (JSC::isGeneratorParseMode): (JSC::isGeneratorWrapperParseMode): * runtime/FunctionExecutable.h: * runtime/JSFunction.cpp: (JSC::JSFunction::getOwnPropertySlot): Add a new GeneratorWrapperMethodMode parse mode. The other function types (async, arrow) already have a FunctionMode and a MethodMode. Give generators one as well. This lets isMethodParseMode actually be accurate. * parser/Parser.cpp: (JSC::Parser::parseInner): (JSC::Parser::isArrowFunctionParameters): (JSC::Parser::parseFormalParameters): (JSC::stringForFunctionMode): (JSC::Parser::parseFunctionParameters): (JSC::Parser::parseFunctionInfo): (JSC::Parser::parseClass): (JSC::Parser::parsePropertyMethod): * parser/Parser.h: Add a duplicate parameter failure if there are duplicate parameters in method syntax. 2017-04-24 Andy VanWagoner Clean up ICU headers https://bugs.webkit.org/show_bug.cgi?id=170997 Reviewed by JF Bastien. Update all icu headers to 55.1 * icu/LICENSE: Update copyright * icu/README: Explain ICU headers for OS X better * icu/unicode/localpointer.h: (LocalPointer::LocalPointer): (LocalPointer::adoptInsteadAndCheckErrorCode): * icu/unicode/platform.h: * icu/unicode/putil.h: * icu/unicode/ucal.h: * icu/unicode/uchar.h: * icu/unicode/ucnv.h: * icu/unicode/ucol.h: * icu/unicode/uconfig.h: * icu/unicode/ucurr.h: * icu/unicode/udatpg.h: * icu/unicode/udisplaycontext.h: * icu/unicode/uformattable.h: * icu/unicode/uloc.h: * icu/unicode/umachine.h: * icu/unicode/unum.h: * icu/unicode/unumsys.h: * icu/unicode/urename.h: * icu/unicode/uscript.h: * icu/unicode/uset.h: * icu/unicode/ustring.h: * icu/unicode/utf8.h: * icu/unicode/utypes.h: 2017-04-24 Yusuke Suzuki [JSC] Use JSFixedArray directly when using call_varargs https://bugs.webkit.org/show_bug.cgi?id=171057 Reviewed by Saam Barati. Previously we always emit new_array_with_spread when calling call(...args). But this array is unnecessary if varargs operation can handle Spread directly. This patch implements a peep-hole optimization in the bytecode compiler layer to omit new_array_with_spread. This is very simple and effective because this peep-hole optimization is quite common when using (...args) style calls and this optimization works all the tiers. While we can implement the phase to omit this NewArrayWithSpread in argument elimination phase, it only works for FTL. While such an optimization can work with complex data flow, this peep-hole optimization can optimize a common case easily. For now, Spread and PhantomSpread can be directly drained by CallVarargs and LoadVarargs related operations. We modify DFG and FTL to handle this correctly. This shows six-speed improvement. spread.es6 89.4300+-2.0236 ^ 69.6015+-1.7278 ^ definitely 1.2849x faster spread-generator.es6 344.7879+-5.9147 ^ 331.2712+-6.8610 ^ definitely 1.0408x faster * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitCall): (JSC::BytecodeGenerator::emitConstruct): * dfg/DFGArgumentsEliminationPhase.cpp: * dfg/DFGPreciseLocalClobberize.h: (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileSpread): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs): (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs): (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargsWithSpread): * interpreter/Interpreter.cpp: (JSC::sizeOfVarargs): (JSC::loadVarargs): * parser/Nodes.h: (JSC::ArrayNode::elements): * runtime/JSFixedArray.cpp: (JSC::JSFixedArray::copyToArguments): * runtime/JSFixedArray.h: 2017-04-24 Yusuke Suzuki [WTF] Move JSC tools/StackTrace to WTF and unify stack trace dump code https://bugs.webkit.org/show_bug.cgi?id=171199 Reviewed by Mark Lam. This patch adds a utility method to produce demangled names with dladdr. It fixes several memory leaks because the result of abi::__cxa_demangle() needs to be `free`-ed. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * inspector/JSGlobalObjectInspectorController.cpp: (Inspector::JSGlobalObjectInspectorController::appendAPIBacktrace): * runtime/SamplingProfiler.cpp: (JSC::SamplingProfiler::StackFrame::displayName): * tools/CellProfile.h: * tools/CodeProfile.cpp: (JSC::CodeProfile::report): (JSC::symbolName): Deleted. 2017-04-24 Joseph Pecoraro Web Inspector: ObjC RWIProtocol codegen should better handle optional members https://bugs.webkit.org/show_bug.cgi?id=171251 Reviewed by Brian Burg. * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py: (ObjCProtocolTypesImplementationGenerator._generate_getter_for_member): * inspector/scripts/codegen/objc_generator.py: (ObjCGenerator.protocol_to_objc_expression_for_member): (ObjCGenerator.protocol_to_objc_code_block_for_object_member): Always be safe and nil check object property accesses, optional or not. * inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result: * inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result: Rebaselined inspector generator tests. 2017-04-24 Saam Barati ASSERTION FAILED: m_table seen with workers/wasm-hashset LayoutTests https://bugs.webkit.org/show_bug.cgi?id=171119 Reviewed by Keith Miller. The HashSet of timer set notification callbacks can be accessed and augmented simultaneously from different threads. e.g, the worker thread can augment it while the wasm compilation thread will access it. Therefore, accesses must be guarded by a lock. * runtime/JSRunLoopTimer.cpp: (JSC::JSRunLoopTimer::scheduleTimer): (JSC::JSRunLoopTimer::addTimerSetNotification): (JSC::JSRunLoopTimer::removeTimerSetNotification): * runtime/JSRunLoopTimer.h: 2017-04-24 Joseph Pecoraro test262: test262/test/language/computed-property-names/class/static/getter-prototype.js https://bugs.webkit.org/show_bug.cgi?id=170897 Reviewed by Saam Barati. * parser/ASTBuilder.h: (JSC::ASTBuilder::createArguments): (JSC::ASTBuilder::createArgumentsList): Reorder so all the createProperty methods are grouped together. * parser/Parser.h: * parser/Parser.cpp: (JSC::Parser::parseClass): (JSC::Parser::parseProperty): (JSC::Parser::parseGetterSetter): Refine the conditions for syntax errors for getter/setter properties names. "prototype" is not allowed as a static and "constructor" is not all when non-static. * runtime/JSObject.cpp: (JSC::JSObject::putGetter): (JSC::JSObject::putSetter): Throw exceptions. These methods are only used by this path via op_put_getter_by_val / op_put_setter_by_val. 2017-04-24 Joseph Pecoraro test262: test262/test/language/statements/for-of/dstr-array-elem-init-fn-name-arrow.js https://bugs.webkit.org/show_bug.cgi?id=171160 Reviewed by JF Bastien. * parser/ASTBuilder.h: (JSC::ASTBuilder::tryInferNameInPattern): (JSC::ASTBuilder::tryInferNameInPatternWithIdentifier): We supported getting the name from a BindingNode. We extend this to support getting the name from a ResolveNode inside of an AssignmentElementNode. * parser/Nodes.h: (JSC::DestructuringPatternNode::isAssignmentElementNode): (JSC::AssignmentElementNode::isAssignmentElementNode): Make it possible to identify an assignment element node. 2017-04-24 Alex Christensen Reduce copies and allocations in SharedBuffer::append https://bugs.webkit.org/show_bug.cgi?id=170956 Reviewed by Andreas Kling. * runtime/ArrayBuffer.h: 2017-04-24 Carlos Garcia Campos [GTK] Switch to use ENABLE_REMOTE_INSPECTOR instead of ENABLE_INSPECTOR_SERVER for the remote inspector https://bugs.webkit.org/show_bug.cgi?id=166680 Reviewed by Michael Catanzaro. Add GTK+ port implementation of RemoteInspector. * PlatformGTK.cmake: * inspector/remote/RemoteConnectionToTarget.h: * inspector/remote/RemoteInspector.h: * inspector/remote/glib/RemoteConnectionToTargetGlib.cpp: Added. (Inspector::RemoteConnectionToTarget::RemoteConnectionToTarget): (Inspector::RemoteConnectionToTarget::~RemoteConnectionToTarget): (Inspector::RemoteConnectionToTarget::setup): (Inspector::RemoteConnectionToTarget::sendMessageToTarget): (Inspector::RemoteConnectionToTarget::close): (Inspector::RemoteConnectionToTarget::targetClosed): (Inspector::RemoteConnectionToTarget::targetIdentifier): (Inspector::RemoteConnectionToTarget::sendMessageToFrontend): * inspector/remote/glib/RemoteInspectorGlib.cpp: Added. (Inspector::RemoteInspector::singleton): (Inspector::RemoteInspector::RemoteInspector): (Inspector::RemoteInspector::start): (Inspector::RemoteInspector::stopInternal): (Inspector::RemoteInspector::setupConnection): (Inspector::dbusConnectionCallAsyncReadyCallback): (Inspector::RemoteInspector::listingForInspectionTarget): (Inspector::RemoteInspector::listingForAutomationTarget): (Inspector::RemoteInspector::pushListingsNow): (Inspector::RemoteInspector::pushListingsSoon): (Inspector::RemoteInspector::updateAutomaticInspectionCandidate): (Inspector::RemoteInspector::sendAutomaticInspectionCandidateMessage): (Inspector::RemoteInspector::sendMessageToRemote): (Inspector::RemoteInspector::receivedGetTargetListMessage): (Inspector::RemoteInspector::receivedSetupMessage): (Inspector::RemoteInspector::receivedDataMessage): (Inspector::RemoteInspector::receivedCloseMessage): (Inspector::RemoteInspector::setup): (Inspector::RemoteInspector::sendMessageToTarget): (Inspector::RemoteInspector::requestAutomationSession): * inspector/remote/glib/RemoteInspectorServer.cpp: Added. (Inspector::generateConnectionID): (Inspector::RemoteInspectorServer::singleton): (Inspector::RemoteInspectorServer::~RemoteInspectorServer): (Inspector::RemoteInspectorServer::interfaceInfo): (Inspector::RemoteInspectorServer::start): (Inspector::RemoteInspectorServer::newConnectionCallback): (Inspector::RemoteInspectorServer::connectionClosedCallback): (Inspector::RemoteInspectorServer::newConnection): (Inspector::dbusConnectionCallAsyncReadyCallback): (Inspector::RemoteInspectorServer::setTargetList): (Inspector::RemoteInspectorServer::clientConnectionClosedCallback): (Inspector::RemoteInspectorServer::getTargetList): (Inspector::RemoteInspectorServer::setup): (Inspector::RemoteInspectorServer::close): (Inspector::RemoteInspectorServer::clientConnectionClosed): (Inspector::RemoteInspectorServer::connectionClosed): (Inspector::RemoteInspectorServer::sendMessageToBackend): (Inspector::RemoteInspectorServer::sendMessageToFrontend): (Inspector::RemoteInspectorServer::startAutomationSession): * inspector/remote/glib/RemoteInspectorServer.h: Added. (Inspector::RemoteInspectorServer::isRunning): 2017-04-24 Joseph Pecoraro test262: test262/test/language/expressions/generators/yield-as-label.js https://bugs.webkit.org/show_bug.cgi?id=170979 Reviewed by Saam Barati. * parser/Parser.cpp: (JSC::Parser::parseVariableDeclarationList): (JSC::Parser::parseDestructuringPattern): (JSC::Parser::parseFormalParameters): Converge on "Cannot" instead of "Can't" in error messages. (JSC::Parser::parseFunctionInfo): Disallow "yield" as the generator function name in function expressions. This refers to the difference between Declaration and Expression, where only GeneratorExpression explicitly has [+Yield] disallowing yield for the generator name: GeneratorDeclaration[Yield, Await, Default]: function * BindingIdentifier[?Yield, ?Await] ... GeneratorExpression: function * BindingIdentifier[+Yield, ~Await]opt ... (JSC::Parser::parseExpressionOrLabelStatement): Disallow "yield" as a label name in strict mode or inside a generator. (JSC::Parser::parseProperty): Disallow "yield" or any keyword in object literal shorthands. * parser/Parser.h: (JSC::Parser::getToken): (JSC::Parser::isDisallowedIdentifierLet): (JSC::Parser::isDisallowedIdentifierYield): (JSC::Parser::disallowedIdentifierLetReason): (JSC::Parser::disallowedIdentifierYieldReason): Follow pattern for improved error messages based on context. 2017-04-23 Commit Queue Unreviewed, rolling out r215674. https://bugs.webkit.org/show_bug.cgi?id=171212 Possible unintended commit. This patch was on the wrong bug. (Requested by JoePeck on #webkit). Reverted changeset: "test262: test262/test/language/expressions/generators/yield- as-label.js" https://bugs.webkit.org/show_bug.cgi?id=170979 http://trac.webkit.org/changeset/215674 2017-04-23 Joseph Pecoraro test262: test262/test/built-ins/Number/prototype/toPrecision/nan.js https://bugs.webkit.org/show_bug.cgi?id=171197 Reviewed by Saam Barati. * runtime/NumberPrototype.cpp: (JSC::numberProtoFuncToExponential): (JSC::numberProtoFuncToFixed): (JSC::numberProtoFuncToPrecision): Refine the order of operations to match the spec. 2017-04-23 Joseph Pecoraro test262: test262/test/language/expressions/generators/yield-as-label.js https://bugs.webkit.org/show_bug.cgi?id=170979 Reviewed by Saam Barati. * parser/Parser.cpp: (JSC::Parser::parseVariableDeclarationList): (JSC::Parser::parseDestructuringPattern): (JSC::Parser::parseFormalParameters): Converge on "Cannot" instead of "Can't" in error messages. (JSC::Parser::parseFunctionInfo): Disallow "yield" as the generator function name in function expressions. This refers to the difference between Declaration and Expression, where only GeneratorExpression explicitly has [+Yield] disallowing yield for the generator name: GeneratorDeclaration[Yield, Await, Default]: function * BindingIdentifier[?Yield, ?Await] ... GeneratorExpression: function * BindingIdentifier[+Yield, ~Await]opt ... (JSC::Parser::parseExpressionOrLabelStatement): Disallow "yield" as a label name in strict mode or inside a generator. (JSC::Parser::parseProperty): Disallow "yield" or any keyword in object literal shorthands. * parser/Parser.h: (JSC::Parser::getToken): (JSC::Parser::isDisallowedIdentifierLet): (JSC::Parser::isDisallowedIdentifierYield): (JSC::Parser::disallowedIdentifierLetReason): (JSC::Parser::disallowedIdentifierYieldReason): Follow pattern for improved error messages based on context. 2017-04-23 Joseph Pecoraro test262: test262/test/built-ins/Number/parseFloat.js https://bugs.webkit.org/show_bug.cgi?id=171193 Reviewed by Yusuke Suzuki. * runtime/CommonIdentifiers.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildren): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::parseFloatFunction): Expose parseFloat on the global object to be shared with Number constructor. * runtime/NumberConstructor.cpp: (JSC::NumberConstructor::finishCreation): parseFloat uses the same value as the global parseFloat. 2017-04-22 Yusuke Suzuki [JSC] Use DoublyLinkedList for MachineThread https://bugs.webkit.org/show_bug.cgi?id=171171 Reviewed by Mark Lam. MachineThread can use WTF::DoublyLinkedList to simplify its implementation. We should not use Vector<> etc. since we do not want to call allocations during suspending and resuming threads. * heap/MachineStackMarker.cpp: (JSC::MachineThreads::MachineThreads): (JSC::MachineThreads::~MachineThreads): (JSC::MachineThreads::addCurrentThread): (JSC::MachineThreads::removeThreadIfFound): (JSC::MachineThreads::MachineThread::MachineThread): (JSC::MachineThreads::tryCopyOtherThreadStacks): * heap/MachineStackMarker.h: (JSC::MachineThreads::threadsListHead): * runtime/SamplingProfiler.cpp: (JSC::FrameWalker::isValidFramePointer): * runtime/VMTraps.cpp: (JSC::findActiveVMAndStackBounds): 2017-04-22 JF Bastien WebAssembly: Module.exports, Module.imports, Module.customSections are wrong https://bugs.webkit.org/show_bug.cgi?id=171078 Reviewed by Saam Barati. They're static properties of Module, not instance properties of a module. https://github.com/WebAssembly/design/blob/master/JS.md#webassemblymoduleexports * wasm/js/WebAssemblyModuleConstructor.cpp: (JSC::webAssemblyModuleCustomSections): (JSC::webAssemblyModuleImports): (JSC::webAssemblyModuleExports): * wasm/js/WebAssemblyModulePrototype.cpp: (JSC::webAssemblyModuleProtoCustomSections): Deleted. (JSC::webAssemblyModuleProtoImports): Deleted. (JSC::webAssemblyModuleProtoExports): Deleted. 2017-04-21 Saam Barati SharedArrayBuffer-opt.js fails with Briggs https://bugs.webkit.org/show_bug.cgi?id=170948 Reviewed by Michael Saboff. The bug was not actually with Briggs, but instead was with our X86-64 MacroAssembler. Michael fixed the bug here: https://trac.webkit.org/changeset/215618/webkit The issue was we weren't adding the REX byte for AtomicXchg8, leading to the incorrect encoding for the result register depending on which register it was. If you look at this code, you'll see the issue: Int32 @38 = AtomicXchg(@59, @64, width = 8, range = 0, fenceRange = 0, ControlDependent|Fence|Writes:0|Reads:0, DFG:@49) AtomicXchg8 %rsi, (%rax,%rdx), @38 0x2dcb5bc0015e: lock xchg %dh, (%rax,%rdx) Int32 @66 = Const32(255, DFG:@49) Int32 @67 = BitAnd(@38, $255(@66), DFG:@49) ZeroExtend8To32 %rsi, %rax, @67 0x2dcb5bc00162: movzx %sil, %eax Air thought the result was in the lower 8 bits of %rsi, however, the code we emitted stored it in the [8-15] bits of %rdx. Since this issue is fixed, I'm turning Briggs back on. * b3/air/AirAllocateRegistersByGraphColoring.h: (JSC::B3::Air::useIRC): 2017-04-20 Mark Lam Refactor MASM probe to allow printing of custom types. https://bugs.webkit.org/show_bug.cgi?id=171101 Reviewed by JF Bastien. For example, this allows us to add MASM printing of CodeBlock* and Air::Args. In general, MASM print can be used like dataLog, except that it generates JITted code for doing the dataLogging later when the JITted code runs. MASM print can print any value type that a specialized Printer template or a setPrinter() function implemented for that type. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * assembler/MacroAssembler.h: * assembler/MacroAssemblerPrinter.cpp: (JSC::Printer::printAllRegisters): (JSC::Printer::printPCRegister): (JSC::Printer::printRegisterID): (JSC::Printer::printFPRegisterID): (JSC::Printer::printAddress): (JSC::Printer::printMemory): (JSC::Printer::printCallback): (JSC::printIndent): Deleted. (JSC::printCPU): Deleted. (JSC::printCPURegisters): Deleted. (JSC::printPC): Deleted. (JSC::printRegister): Deleted. (JSC::printMemory): Deleted. (JSC::MacroAssemblerPrinter::printCallback): Deleted. * assembler/MacroAssemblerPrinter.h: (JSC::AllRegisters::AllRegisters): (JSC::Printer::Printer::Printer): (JSC::Printer::Printer::Printer): (JSC::Printer::Printer::Printer): (JSC::Printer::Printer::Printer): (JSC::Printer::Printer::Printer): (JSC::Printer::Printer::Printer): (JSC::Printer::Printer>::Printer): (JSC::MacroAssembler::print): (JSC::MacroAssemblerPrinter::print): Deleted. (JSC::MacroAssemblerPrinter::PrintArg::PrintArg): Deleted. (JSC::MacroAssemblerPrinter::appendPrintArg): Deleted. - Refactored to move the underlying PrintRecord (and associated data structures) out to Printer.cpp/h. - MacroAssemblerPrinter.cpp/h now only add custom Printers for MASM types like RegisterID and Memory. It also defines the implementation of MacroAssembler::print(). As before, JIT code that wishes to use MacroAssembler::print() needs to #include "MacroAssemblerPrinter.h". - Also added the ability to specify an optional indentation (in number of chars) when MASM printing AllRegisters. This is useful because AllRegisters prints a block of data unlike other printers which print inline. * assembler/Printer.cpp: Added. (JSC::Printer::printConstCharString): (JSC::Printer::printIntptr): (JSC::Printer::printUintptr): (JSC::Printer::printPointer): (JSC::Printer::setPrinter): * assembler/Printer.h: Added. (JSC::Printer::Context::Context): (JSC::Printer::PrintRecord::PrintRecord): (JSC::Printer::appendPrinter): (JSC::Printer::makePrintRecordList): (JSC::Printer::Printer::Printer): (JSC::Printer::setPrinter): (JSC::Printer::Printer::Printer): - Data structures for creating a list of PrintRecords. Classes which wish to add custom support for MASM printing can #include "Printer.h" and implement either: 1. a specialized Printer template, or 2. a setPrinter() function. See Printer and Printer in AirPrintSpecial.h for examples of (1). See CodeBlock's setPrinter() for an example of (2). * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::print): * b3/air/AirPrintSpecial.cpp: Added. (JSC::B3::Air::PrintSpecial::PrintSpecial): (JSC::B3::Air::PrintSpecial::~PrintSpecial): (JSC::B3::Air::PrintSpecial::forEachArg): (JSC::B3::Air::PrintSpecial::isValid): (JSC::B3::Air::PrintSpecial::admitsStack): (JSC::B3::Air::PrintSpecial::reportUsedRegisters): (JSC::B3::Air::PrintSpecial::generate): (JSC::B3::Air::PrintSpecial::extraEarlyClobberedRegs): (JSC::B3::Air::PrintSpecial::extraClobberedRegs): (JSC::B3::Air::PrintSpecial::dumpImpl): (JSC::B3::Air::PrintSpecial::deepDumpImpl): (JSC::Printer::printAirArg): * b3/air/AirPrintSpecial.h: Added. (JSC::Printer::appendAirArg): (JSC::Printer::appendAirArgs): (JSC::Printer::Printer::Printer): (JSC::Printer::Printer::Printer): - Add the print() operation for use in LowerToAir. print() will emit a PrintSpecial that will ultimately emit a MASM print to print what we want. - LowerToAir's print() adds the ability to print Air::Args. - Unlike in the baseline JIT and the DFG, LowerToAir's print() can perturb the usage of registers. This is because PrintSpecial is a patch point, and it prevents certain optimizations. If not used carefully, an attempt to print() an Arg by taking a Tmp, can force the B3 Value into a Tmp earlier than it would otherwise do so. So, use LowerToAir's print() with care. * bytecode/CodeBlock.cpp: (JSC::setPrinter): - Now we can MASM print CodeBlock*. (WTF::printInternal): - Now we can dataLog CodeBlock* (including null CodeBlock pointers). * bytecode/CodeBlock.h: * runtime/VM.cpp: (JSC::VM::throwException): - Use the new ability to dataLog CodeBlock*. No need to do an explicit null check before printing anymore. 2017-04-21 Keith Miller Unreviewed, rolling out r215634. underlying build issues should have been fixed Reverted changeset: "Unreviewed, rolling out r215620 and r215623." https://bugs.webkit.org/show_bug.cgi?id=171139 http://trac.webkit.org/changeset/215634 2017-04-21 Commit Queue Unreviewed, rolling out r215620 and r215623. https://bugs.webkit.org/show_bug.cgi?id=171139 broke arm64 build (Requested by keith_miller on #webkit). Reverted changesets: "Add signaling API" https://bugs.webkit.org/show_bug.cgi?id=170976 http://trac.webkit.org/changeset/215620 "Unreviewed, fix Cloop build." http://trac.webkit.org/changeset/215623 2017-04-21 Keith Miller Remove LL/SC from Atomics https://bugs.webkit.org/show_bug.cgi?id=171141 Reviewed by Saam Barati. Adding load link and store conditionally was not an actual progression and the existing code is causing problems for users of Atomics. So let's get rid of it. * heap/LargeAllocation.h: (JSC::LargeAllocation::testAndSetMarked): * heap/MarkedBlock.h: (JSC::MarkedBlock::testAndSetMarked): * heap/SlotVisitor.cpp: (JSC::SlotVisitor::setMarkedAndAppendToMarkStack): 2017-04-21 Keith Miller Unreviewed, fix Cloop build. * jit/ExecutableAllocator.h: (JSC::isJITPC): 2017-04-20 Keith Miller Add signaling API https://bugs.webkit.org/show_bug.cgi?id=170976 Reviewed by Filip Pizlo. Update various uses of sigaction to use the new signaling API. Also switch VMTraps to use the thread message system instead of rolling it's own. * jit/ExecutableAllocator.h: (JSC::isJITPC): * runtime/VMTraps.cpp: (JSC::installSignalHandler): (JSC::VMTraps::VMTraps): (JSC::VMTraps::SignalSender::send): (JSC::handleSigusr1): Deleted. (JSC::handleSigtrap): Deleted. (JSC::installSignalHandlers): Deleted. * runtime/VMTraps.h: * tools/SigillCrashAnalyzer.cpp: (JSC::installCrashHandler): (JSC::handleCrash): Deleted. * wasm/WasmFaultSignalHandler.cpp: (JSC::Wasm::trapHandler): (JSC::Wasm::enableFastMemory): 2017-04-21 Michael Saboff X86-64 Assembler doesn't handle xchg with byte register src https://bugs.webkit.org/show_bug.cgi?id=171118 Reviewed by Saam Barati. * assembler/X86Assembler.h: (JSC::X86Assembler::xchgb_rm): Use oneByteOp8() since these are 8 bit opcodes. 2017-04-21 Andy VanWagoner [INTL] Implement Intl.DateTimeFormat.prototype.formatToParts https://bugs.webkit.org/show_bug.cgi?id=169458 Reviewed by JF Bastien. Use udat_formatForFields to iterate through the parts of a formatted date string. Make formatToParts and related functions dependent on ICU version >= 55. * icu/unicode/udat.h: Update to 55.1. * icu/unicode/ufieldpositer.h: Added from 55.1. * icu/unicode/uvernum.h: Update to 55.1 * runtime/IntlDateTimeFormat.cpp: (JSC::IntlDateTimeFormat::partTypeString): Convert UDateFormatField to string. (JSC::IntlDateTimeFormat::formatToParts): Return parts of formatted date string. * runtime/IntlDateTimeFormat.h: * runtime/IntlDateTimeFormatPrototype.cpp: (JSC::IntlDateTimeFormatPrototypeFuncFormatToParts): Add prototype function formatToParts. 2017-04-20 Konstantin Tokarev [cmake] Define FORWARDING_HEADERS_DIR in WebKitFS and use it everywhere https://bugs.webkit.org/show_bug.cgi?id=171071 Reviewed by Michael Catanzaro. "${DERIVED_SOURCES_DIR}/ForwardingHeaders" path occurs very often in the build system files. GTK-specifc FORWARDING_HEADERS_DIR variable should be available for all ports. * CMakeLists.txt: * PlatformWin.cmake: 2017-04-20 Konstantin Tokarev Remove unused lamda captures https://bugs.webkit.org/show_bug.cgi?id=171098 Reviewed by Yusuke Suzuki. * bytecompiler/NodesCodegen.cpp: (JSC::ArrayNode::emitBytecode): * ftl/FTLState.cpp: (JSC::FTL::State::State): * wasm/WasmB3IRGenerator.cpp: 2017-04-20 Yusuke Suzuki [JSC][FTL] FTL should support Arrayify https://bugs.webkit.org/show_bug.cgi?id=169596 Reviewed by Saam Barati. This patch simply expands the coverage of FTL by supporting Arrayify. While ArrayifyToStructure is already supported, Arrayify is not supported in FTL. While supporting Arrayify in FTL itself does not offer so much performance difference from DFG's one, no FTL support for Arrayify prevents us applying FTL to the code including Arrayify. * dfg/DFGArrayMode.cpp: (JSC::DFG::toIndexingShape): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileArrayify): (JSC::FTL::DFG::LowerDFGToB3::compileCheckArray): (JSC::FTL::DFG::LowerDFGToB3::isArrayTypeForArrayify): (JSC::FTL::DFG::LowerDFGToB3::isArrayTypeForCheckArray): (JSC::FTL::DFG::LowerDFGToB3::compileArrayifyToStructure): Deleted. (JSC::FTL::DFG::LowerDFGToB3::isArrayType): Deleted. 2017-04-20 Mark Lam virtualThunkFor() needs to materialize its of tagMaskRegister for tail calls. https://bugs.webkit.org/show_bug.cgi?id=171079 Reviewed by Saam Barati. This is needed because tail calls would restore callee saved registers (and therefore, potentially clobber the tag registers) before jumping to the thunk. * jit/ThunkGenerators.cpp: (JSC::virtualThunkFor): 2017-04-20 Mark Lam Build fix after r215592. https://bugs.webkit.org/show_bug.cgi?id=171088 Not reviewed. * assembler/MacroAssemblerPrinter.h: 2017-04-20 Mark Lam Update the MASM probe to only take 1 arg instead of 2 (in addition to the callback function). https://bugs.webkit.org/show_bug.cgi?id=171088 Reviewed by Michael Saboff and Saam Barati. Experience shows that we never use the 2nd arg. So, let's remove it to reduce the footprint at each probe site. Also fix the MacroAssembler::print() function so that it is a no-op when !ENABLE(MASM_PROBE). This will allow us to have print() statements in JIT code without a lot of #if ENABLE(MASM_PROBE)s later. * assembler/AbstractMacroAssembler.h: * assembler/MacroAssembler.cpp: (JSC::stdFunctionCallback): (JSC::MacroAssembler::probe): * assembler/MacroAssembler.h: * assembler/MacroAssemblerARM.cpp: (JSC::MacroAssemblerARM::probe): * assembler/MacroAssemblerARM.h: * assembler/MacroAssemblerARM64.cpp: (JSC::MacroAssemblerARM64::probe): * assembler/MacroAssemblerARM64.h: * assembler/MacroAssemblerARMv7.cpp: (JSC::MacroAssemblerARMv7::probe): * assembler/MacroAssemblerARMv7.h: * assembler/MacroAssemblerPrinter.cpp: (JSC::MacroAssemblerPrinter::printCallback): * assembler/MacroAssemblerPrinter.h: (JSC::MacroAssemblerPrinter::print): (JSC::MacroAssembler::print): * assembler/MacroAssemblerX86Common.cpp: (JSC::MacroAssemblerX86Common::probe): * assembler/MacroAssemblerX86Common.h: 2017-04-20 Matt Baker Web Inspector: Add regular expression support to XHR breakpoints https://bugs.webkit.org/show_bug.cgi?id=170099 Reviewed by Joseph Pecoraro. * inspector/protocol/DOMDebugger.json: New optional `isRegex` parameter denotes whether `url` contains a regular expression. 2017-04-15 Filip Pizlo Optimize SharedArrayBuffer in the DFG+FTL https://bugs.webkit.org/show_bug.cgi?id=164108 Reviewed by Saam Barati. This adds atomics intrinsics to the DFG and wires them through to the DFG and FTL backends. This was super easy in the FTL since B3 already has comprehensive atomic intrinsics, which are more powerful than what we need right now. In the DFG backend, I went with an easy-to-write implementation that just reduces everything to a weak CAS loop. It's very inefficient with registers (it needs ~8) but it's the DFG backend, so it's not obvious how much we care. To make the rare cases easy to handle, I refactored AtomicsObject.cpp so that the operations for the slow paths can share code with the native functions. This also fixes register handling in the X86 implementations of CAS, in the case that expectedAndResult is not %rax. This also fixes the ARM64 implementation of branchWeakCAS. I adapted the CascadeLock from WTF/benchmarks/ToyLocks.h as a microbenchmark of lock performance. This benchmark performs 2.5x faster, in both the contended and uncontended case, thanks to this change. It's still about 3x slower than native. I investigated this only a bit. I suspect that the story will be different in asm.js code, which will get constant-folding of the typed array backing store by virtue of how it uses lexically scoped variables as pointers to the heap arrays. It's worth noting that the native lock I was comparing against, the very nicely-tuned CascadeLock, is at the very high end of lock throughput under virtually all conditions (uncontended, microcontended, held for a long time). I also compared to WTF::Lock and others, and the only ones that performed better in this microbenchmark were spinlocks. I don't recommend using those. So, when I say this is 3x slower than native, I really mean that it's 3x slower than the fastest native lock that I have in my arsenal. Also worth noting is that I experimented with exposing Atomics.yield(), which uses sched_yield, as a way of testing if adding a yield loop to the JS cascadeLock would help. It does not help. I did not investigate why. * assembler/AbstractMacroAssembler.h: (JSC::AbstractMacroAssembler::JumpList::append): * assembler/CPU.h: (JSC::is64Bit): (JSC::is32Bit): * b3/B3Common.h: (JSC::B3::is64Bit): Deleted. (JSC::B3::is32Bit): Deleted. * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::appendTrapping): (JSC::B3::Air::LowerToAir::appendCAS): (JSC::B3::Air::LowerToAir::appendGeneralAtomic): * 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/DFGNode.h: (JSC::DFG::Node::hasHeapPrediction): (JSC::DFG::Node::hasArrayMode): * dfg/DFGNodeType.h: (JSC::DFG::isAtomicsIntrinsic): (JSC::DFG::numExtraAtomicsArgs): * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSSALoweringPhase.cpp: (JSC::DFG::SSALoweringPhase::handleNode): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::loadFromIntTypedArray): (JSC::DFG::SpeculativeJIT::setIntTypedArrayLoadResult): (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray): (JSC::DFG::SpeculativeJIT::getIntTypedArrayStoreOperand): (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLAbstractHeapRepository.cpp: (JSC::FTL::AbstractHeapRepository::decorateFencedAccess): (JSC::FTL::AbstractHeapRepository::computeRangesAndDecorateInstructions): * ftl/FTLAbstractHeapRepository.h: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileAtomicsReadModifyWrite): (JSC::FTL::DFG::LowerDFGToB3::compileAtomicsIsLockFree): (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal): (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal): (JSC::FTL::DFG::LowerDFGToB3::pointerIntoTypedArray): (JSC::FTL::DFG::LowerDFGToB3::loadFromIntTypedArray): (JSC::FTL::DFG::LowerDFGToB3::storeType): (JSC::FTL::DFG::LowerDFGToB3::setIntTypedArrayLoadResult): (JSC::FTL::DFG::LowerDFGToB3::getIntTypedArrayStoreOperand): (JSC::FTL::DFG::LowerDFGToB3::vmCall): * ftl/FTLOutput.cpp: (JSC::FTL::Output::store): (JSC::FTL::Output::store32As8): (JSC::FTL::Output::store32As16): (JSC::FTL::Output::atomicXchgAdd): (JSC::FTL::Output::atomicXchgAnd): (JSC::FTL::Output::atomicXchgOr): (JSC::FTL::Output::atomicXchgSub): (JSC::FTL::Output::atomicXchgXor): (JSC::FTL::Output::atomicXchg): (JSC::FTL::Output::atomicStrongCAS): * ftl/FTLOutput.h: (JSC::FTL::Output::store32): (JSC::FTL::Output::store64): (JSC::FTL::Output::storePtr): (JSC::FTL::Output::storeFloat): (JSC::FTL::Output::storeDouble): * jit/JITOperations.h: * runtime/AtomicsObject.cpp: (JSC::atomicsFuncAdd): (JSC::atomicsFuncAnd): (JSC::atomicsFuncCompareExchange): (JSC::atomicsFuncExchange): (JSC::atomicsFuncIsLockFree): (JSC::atomicsFuncLoad): (JSC::atomicsFuncOr): (JSC::atomicsFuncStore): (JSC::atomicsFuncSub): (JSC::atomicsFuncWait): (JSC::atomicsFuncWake): (JSC::atomicsFuncXor): (JSC::operationAtomicsAdd): (JSC::operationAtomicsAnd): (JSC::operationAtomicsCompareExchange): (JSC::operationAtomicsExchange): (JSC::operationAtomicsIsLockFree): (JSC::operationAtomicsLoad): (JSC::operationAtomicsOr): (JSC::operationAtomicsStore): (JSC::operationAtomicsSub): (JSC::operationAtomicsXor): * runtime/AtomicsObject.h: 2017-04-19 Youenn Fablet [Mac] Allow customizing H264 encoder https://bugs.webkit.org/show_bug.cgi?id=170829 Reviewed by Alex Christensen. * Configurations/FeatureDefines.xcconfig: 2017-04-19 Michael Saboff Tune GC related JSC options for iOS https://bugs.webkit.org/show_bug.cgi?id=171019 Reviewed by Mark Lam. Always set these GC options on iOS. * runtime/Options.cpp: (JSC::overrideDefaults): 2017-04-19 JF Bastien WebAssembly: fast memory cleanups https://bugs.webkit.org/show_bug.cgi?id=170909 Reviewed by Saam Barati. * b3/B3LowerToAir.cpp: correct comment, and make wasm-independent (JSC::B3::Air::LowerToAir::lower): * b3/B3Procedure.h: * b3/B3Validate.cpp: * b3/B3Value.cpp: (JSC::B3::Value::effects): * b3/B3WasmBoundsCheckValue.cpp: have the creator pass in a maximum, so we don't have to know so much about wasm here (JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue): (JSC::B3::WasmBoundsCheckValue::cloneImpl): (JSC::B3::WasmBoundsCheckValue::dumpMeta): * b3/B3WasmBoundsCheckValue.h: (JSC::B3::WasmBoundsCheckValue::boundsType): (JSC::B3::WasmBoundsCheckValue::bounds): * b3/air/AirCode.h: * b3/air/AirCustom.h: (JSC::B3::Air::WasmBoundsCheckCustom::generate): * b3/testb3.cpp: (JSC::B3::testWasmBoundsCheck): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer): (JSC::Wasm::createJSToWasmWrapper): remove dead code * wasm/WasmMemory.cpp: don't GC if no memory could possibly be free'd (JSC::Wasm::Memory::initializePreallocations): verbose-only code, and copy-pasta bug 2017-04-19 Mark Lam B3StackmapSpecial should handle when stackmap values are not recoverable from a Def'ed arg. https://bugs.webkit.org/show_bug.cgi?id=170973 Reviewed by Filip Pizlo. In the event of an arithmetic overflow on a binary sub instruction (where the result register is same as one of the operand registers), the CheckSub FTL operation will try to recover the original value in the clobbered result register. This recover is done by adding the other operand value to the result register. However, this recovery method only works if the width of the original value in the result register is less or equal to the width of the expected result. If the width of the original operand value (e.g. a JSInt32) is wider than the result (e.g. a machine Int32), then the sub operation would have zero extended the result and cleared the upper 32-bits of the result register. Recovery by adding back the other operand will not restore the JSValue tag in the upper word. This poses a problem if the stackmap value for the operand relies on that same clobbered register. The fix is to detect this potential scenario (i.e. width of the Def's arg < width of a stackmap value). If this condition is detected, we'll declare the stackmap value to be LateColdUse to ensure that the register allocator gives it a different register if needed so that it's not dependent on the clobbered register. * b3/B3CheckSpecial.cpp: (JSC::B3::CheckSpecial::forEachArg): * b3/B3PatchpointSpecial.cpp: (JSC::B3::PatchpointSpecial::forEachArg): * b3/B3StackmapSpecial.cpp: (JSC::B3::StackmapSpecial::forEachArgImpl): * b3/B3StackmapSpecial.h: 2017-04-19 JF Bastien Unreviewed, rolling out r215520. Broke Debian 8 Reverted changeset: "[INTL] Implement Intl.DateTimeFormat.prototype.formatToParts" https://bugs.webkit.org/show_bug.cgi?id=169458 http://trac.webkit.org/changeset/215520 2017-04-19 JF Bastien WebAssembly: limit slow memories https://bugs.webkit.org/show_bug.cgi?id=170825 Reviewed by Saam Barati. We limits the number of fast memories, partly because ASLR. The code then falls back to slow memories. It first tries to virtually allocated any declared maximum (and in there, physically the initial), and if that fails it tries to physically allocate the initial without any extra. This can still be used to cause a bunch of virtual allocation. This patch imposes soft limit on slow memories as well. The total virtual maximum for slow memories is set at the same (theoretical) value as that for fast memories. Anything exceeding that limit causes allocation/grow to fail. * wasm/WasmMemory.cpp: 2017-04-19 JF Bastien Cannot compile JavaScriptCore/runtime/VMTraps.cpp on FreeBSD because std::pair has a non-trivial copy constructor https://bugs.webkit.org/show_bug.cgi?id=170875 Reviewed by Mark Lam. WTF::ExpectedDetail::ConstexprBase doesn't have a user-defined copy constructor, and its implicitly-defined copy constructor is deleted because the default std::pair implementation on FreeBSD has a non-trivial copy constructor. /usr/include/c++/v1/__config says _LIBCPP_TRIVIAL_PAIR_COPY_CTOR is disabled in order to keep ABI compatibility: https://svnweb.freebsd.org/changeset/base/261801. That's a huge bummer, and I'm not a fan of broken stdlibs, but in this case it's pretty nice to have a custom named type anyways and costs nothing. * runtime/VMTraps.cpp: (JSC::findActiveVMAndStackBounds): (JSC::handleSigusr1): (JSC::handleSigtrap): 2017-04-19 Andy VanWagoner [INTL] Implement Intl.DateTimeFormat.prototype.formatToParts https://bugs.webkit.org/show_bug.cgi?id=169458 Reviewed by JF Bastien. Use udat_formatForFields to iterate through the parts of a formatted date string. * icu/unicode/udat.h: Update to 55.1. * icu/unicode/ufieldpositer.h: Added from 55.1. * runtime/IntlDateTimeFormat.cpp: (JSC::IntlDateTimeFormat::partTypeString): Convert UDateFormatField to string. (JSC::IntlDateTimeFormat::formatToParts): Return parts of formatted date string. * runtime/IntlDateTimeFormat.h: * runtime/IntlDateTimeFormatPrototype.cpp: (JSC::IntlDateTimeFormatPrototypeFuncFormatToParts): Add prototype function formatToParts. 2017-04-19 JF Bastien WebAssembly: don't expose any WebAssembly JS object if JIT is off https://bugs.webkit.org/show_bug.cgi?id=170782 Reviewed by Saam Barati. It's unexpected that we expose the global WebAssembly object if no JIT is present because it can't be used to compile or instantiate. Other APIs such as Memory should also be Inaccessible in those circumstances. Also ensure that we don't pre-allocate fast memories if WebAssembly won't be used, and don't mark our intention to use a fast TLS slot for WebAssembly. * runtime/Options.cpp: (JSC::recomputeDependentOptions): 2017-04-19 Yusuke Suzuki r211670 broke double to int conversion. https://bugs.webkit.org/show_bug.cgi?id=170961 Reviewed by Mark Lam. In this patch, we take a template parameter way. While it reduces duplicate code, it effectively produces optimized code for operationToInt32SensibleSlow, and fixes kraken pbkdf2 regression on Linux. And this patch also fixes undefined behavior by changing int32_t to uint32_t. If exp is 31, missingOne is 1 << 31, INT32_MIN. Thus missingOne - 1 will cause int32_t overflow, and it is an undefined behavior. * runtime/MathCommon.cpp: (JSC::operationToInt32SensibleSlow): * runtime/MathCommon.h: (JSC::toInt32Internal): (JSC::toInt32): 2017-04-18 Mark Lam r211670 broke double to int conversion. https://bugs.webkit.org/show_bug.cgi?id=170961 Reviewed by Yusuke Suzuki. This is because operationToInt32SensibleSlow() assumes that left shifts of greater than 31 bits on an 31-bit value will produce a 0. However, the spec says that "if the value of the right operand is negative or is greater or equal to the number of bits in the promoted left operand, the behavior is undefined." See http://en.cppreference.com/w/cpp/language/operator_arithmetic#Bitwise_shift_operators. This patch fixes this by restoring the check to prevent a shift of greater than 31 bits. It also consolidates the optimization in operationToInt32SensibleSlow() back into toInt32() so that we don't have 2 copies of the same code with only a slight variation. JSC benchmarks shows that performance is neutral with this patch. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileValueToInt32): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::sensibleDoubleToInt32): * runtime/MathCommon.cpp: (JSC::operationToInt32SensibleSlow): Deleted. * runtime/MathCommon.h: (JSC::toInt32): 2017-04-18 Oleksandr Skachkov [ES6]. Implement Annex B.3.3 function hoisting rules for eval https://bugs.webkit.org/show_bug.cgi?id=163208 Reviewed by Saam Barati. Current patch implements Annex B.3.3 that is related to hoisting of function declaration in eval. https://tc39.github.io/ecma262/#sec-web-compat-evaldeclarationinstantiation Function declaration in eval should create variable with function name in function scope where eval is invoked or bind to variable if it declared outside of the eval. If variable is created it can be removed by 'delete a;' command. If eval is invoke in block scope that contains let/const variable with the same name as function declaration we do not bind. This patch leads to the following behavior: ''' function foo() { { print(boo); // undefined eval('{ function boo() {}}'); print(boo); // function boo() {} } print(boo); // function boo() {} } function foobar() { { let boo = 10; print(boo); // 10; eval('{ function boo() {}}'); print(boo); // 10; } print(boo) // 10 } function bar() { { var boo = 10; print(boo); // 10 eval('{ function boo() {} }'); print(boo); // function boo() {} } print(boo); // function boo() {} } function bas() { { let boo = 10; eval(' { function boo() {} } '); print(boo); // 10 } print(boo); //Reference Error } ''' Current implementation relies on already implemented 'hoist function in sloppy mode' feature, with small changes. In short it works in following way: during hoisting of function with name S in eval, we are looking for first scope that contains space for variable with name S and if this scope has var type we bind function there To implement this feature was added bytecode ops: op_resolve_scope_for_hoisting_func_decl_in_eval - get variable scope or return undefined if variable can't be binded there. There is a corner case, hoist function in eval within catch block, that is not covered by this patch, and will be fixed in https://bugs.webkit.org/show_bug.cgi?id=168184 * bytecode/BytecodeDumper.cpp: (JSC::BytecodeDumper::dumpBytecode): * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finalizeLLIntInlineCaches): * bytecode/EvalCodeBlock.h: (JSC::EvalCodeBlock::functionHoistingCandidate): (JSC::EvalCodeBlock::numFunctionHoistingCandidates): * bytecode/UnlinkedEvalCodeBlock.h: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary): (JSC::BytecodeGenerator::emitResolveScopeForHoistingFuncDeclInEval): * bytecompiler/BytecodeGenerator.h: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNode.h: (JSC::DFG::Node::hasIdentifier): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileResolveScopeForHoistingFuncDeclInEval): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * 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::compileResolveScopeForHoistingFuncDeclInEval): * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JIT.h: * jit/JITOperations.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval): * llint/LowLevelInterpreter.asm: * parser/Parser.cpp: (JSC::Parser::parseFunctionDeclarationStatement): * parser/Parser.h: (JSC::Scope::getSloppyModeHoistedFunctions): (JSC::Parser::declareFunction): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: * runtime/EvalExecutable.h: (JSC::EvalExecutable::numFunctionHoistingCandidates): (JSC::EvalExecutable::numTopLevelFunctionDecls): (JSC::EvalExecutable::numberOfFunctionDecls): Deleted. * runtime/JSScope.cpp: (JSC::JSScope::resolve): (JSC::JSScope::resolveScopeForHoistingFuncDeclInEval): * runtime/JSScope.h: 2017-04-18 Saam Barati Follow up to address Mark's comments after r215453 Rubber stamped by Mark Lam. This patch chooses better names for things, adhering to Mark's suggestions in https://bugs.webkit.org/show_bug.cgi?id=139847 * bytecompiler/NodesCodegen.cpp: (JSC::CallFunctionCallDotNode::emitBytecode): (JSC::ApplyFunctionCallDotNode::emitBytecode): * parser/NodeConstructors.h: (JSC::CallFunctionCallDotNode::CallFunctionCallDotNode): (JSC::ApplyFunctionCallDotNode::ApplyFunctionCallDotNode): * parser/Nodes.h: * parser/Parser.cpp: (JSC::recordCallOrApplyDepth): (JSC::Parser::parseMemberExpression): * parser/Parser.h: (JSC::Parser::CallOrApplyDepthScope::CallOrApplyDepthScope): (JSC::Parser::CallOrApplyDepthScope::distanceToInnermostChild): (JSC::Parser::CallOrApplyDepthScope::~CallOrApplyDepthScope): (JSC::Parser::CallOrApplyDepth::CallOrApplyDepth): Deleted. (JSC::Parser::CallOrApplyDepth::maxChildDepth): Deleted. (JSC::Parser::CallOrApplyDepth::~CallOrApplyDepth): Deleted. 2017-04-18 Yusuke Suzuki [DFG] Convert ValueAdd(Int32, String) => MakeRope(ToString(Int32), String) https://bugs.webkit.org/show_bug.cgi?id=170943 Reviewed by Geoffrey Garen. This patch converts ValueAdd(Int32, String) to MakeRope(ToString(Int32), String). This has 2 great features. 1. MakeRope(ToString(Int32), String) is less clobbering. While ValueAdd ends up calling functions, VM knows much about MakeRope(ToString(Int32), String) and VM knows it is less clobbering. It encourages LICM and other operations that is conservatively executed because of ValueAdd's clobbering. 2. Simply, MakeRope(ToString(Int32), String) is faster than ValueAdd. While ValueAdd ends up calling a generic function, our ToString(Int32) calls well-optimized toString operation. And later, MakeRope can fall into the fast path that just takes a string from a free list. It is simply faster than ValueAdd. We ensure that this patch shows performance improvement in attached benchmarks. baseline patched number-to-string-with-add-empty 16.2763+-3.3930 ^ 10.3142+-1.0967 ^ definitely 1.5780x faster number-to-string-with-add-in-loop 168.7621+-10.9738 ^ 15.5307+-3.3179 ^ definitely 10.8664x faster number-to-string-with-add 18.8557+-4.8292 11.6901+-2.5650 might be 1.6130x faster In SixSpeed, baseline patched template_string_tag.es5 200.1027+-20.6871 ^ 25.7925+-11.4052 ^ definitely 7.7582x faster template_string_tag.es6 331.3913+-12.1750 ^ 286.6958+-26.0441 ^ definitely 1.1559x faster for-of-array.es5 412.4344+-23.2517 ^ 272.8707+-47.2118 ^ definitely 1.5115x faster for-of-array.es6 504.0082+-65.5045 ^ 300.3277+-12.8193 ^ definitely 1.6782x faster * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::createToString): * dfg/DFGPredictionPropagationPhase.cpp: 2017-04-18 Michael Saboff REGRESSION(215272): microbenchmark/seal-and-do-work and microbenchmark/freeze-and-do-work are 27x slower https://bugs.webkit.org/show_bug.cgi?id=170881 Reviewed by Saam Barati. * runtime/ObjectConstructor.cpp: (JSC::objectConstructorSeal): (JSC::objectConstructorFreeze): Restored fast paths for final objects that don't have indexed properties. 2017-04-18 Yusuke Suzuki [DFG] Use Phantom for base instead of getter when inlining intrinsic getter https://bugs.webkit.org/show_bug.cgi?id=170947 Reviewed by Saam Barati. getter does not need to be live after OSR Exit. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleGetById): 2017-04-18 Yusuke Suzuki Unreviewed, follow-up patch after r215459 https://bugs.webkit.org/show_bug.cgi?id=170940 Reviewed by Filip Pizlo. CheckCell can cause OSRExit. Thus Phantom should be placed after CheckCell. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::emitFunctionChecks): (JSC::DFG::ByteCodeParser::handleGetById): 2017-04-18 Yusuke Suzuki [DFG] Drop unknown use of CheckCell's child2 to work ObjectAllocationSinking for Array iterator object https://bugs.webkit.org/show_bug.cgi?id=170940 Reviewed by Filip Pizlo. The second argument of CheckCell is not used in meaningful way. It is just *use* the node. The problem is that it effectively *use* the child2 in ObjectAllocationSinking phase, and prevent us from eliminating object allocations. Actually, it materializes Array iterator when inlining `next()`. Instead, we should use Phantom in such a case. It improves destructuring.es6 in SixSpeed 2.5x. destructuring.es6 308.5184+-25.3490 ^ 119.5680+-15.0520 ^ definitely 2.5803x faster Note that SixSpeed tested in arewefastyet executes all the tests in one process while our SixSpeed tests each one in isolated way. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::emitFunctionChecks): (JSC::DFG::ByteCodeParser::handleGetById): 2017-04-18 Yusuke Suzuki [JSC][GTK] glib RunLoop does not accept negative start interval https://bugs.webkit.org/show_bug.cgi?id=170775 Reviewed by Saam Barati. * heap/GCActivityCallback.cpp: (JSC::GCActivityCallback::scheduleTimer): 2017-04-17 Saam Barati BytecodeGenerator ".call" and ".apply" is exponential in nesting depth https://bugs.webkit.org/show_bug.cgi?id=139847 Reviewed by Oliver Hunt. The BytecodeGenerator's .apply(...) and .call(...) code would emit bytecode for the evaluation of its arguments twice. This is exponential, specifically, 2^n, where n is the nesting depth of .call(...) or .apply(...) inside other .call(...) or .apply(...). The reason we emit code for the arguments twice is that we try to emit efficient code for when .call or .apply is Function.prototype.call or Function.prototype.apply. Because of this, we compare .call/.apply to Function.prototype.call/.apply, and if they're the same, we emit a specialized function call in bytecode. Otherwise, we emit the generalized version. This patch makes it so that each .call(...) and .apply(...) records its max inner nesting depth. Then, we only perform the optimization for the bottom k (where k = 6) layers of the nesting tree. The reason we apply the optimization to the bottom k layers instead of top k layers is that we'll produce less code this way. * bytecompiler/NodesCodegen.cpp: (JSC::CallFunctionCallDotNode::emitBytecode): (JSC::ApplyFunctionCallDotNode::emitBytecode): * parser/ASTBuilder.h: (JSC::ASTBuilder::makeFunctionCallNode): * parser/NodeConstructors.h: (JSC::CallFunctionCallDotNode::CallFunctionCallDotNode): (JSC::ApplyFunctionCallDotNode::ApplyFunctionCallDotNode): * parser/Nodes.h: * parser/Parser.cpp: (JSC::recordCallOrApplyDepth): (JSC::Parser::parseMemberExpression): * parser/Parser.h: (JSC::Parser::CallOrApplyDepth::CallOrApplyDepth): (JSC::Parser::CallOrApplyDepth::maxChildDepth): (JSC::Parser::CallOrApplyDepth::~CallOrApplyDepth): * parser/SyntaxChecker.h: (JSC::SyntaxChecker::makeFunctionCallNode): 2017-04-17 Mark Lam JSArray::appendMemcpy() needs to handle copying from Undecided indexing type too. https://bugs.webkit.org/show_bug.cgi?id=170896 Reviewed by JF Bastien and Keith Miller. * runtime/JSArray.cpp: (JSC::JSArray::appendMemcpy): 2017-04-17 Joseph Pecoraro Web Inspector: Doesn't show size of compressed content correctly https://bugs.webkit.org/show_bug.cgi?id=155112 Reviewed by Alex Christensen and Timothy Hatcher. * inspector/protocol/Network.json: New, exact size metrics, available after the load completes. 2017-04-17 Youenn Fablet Disable outdated WritableStream API https://bugs.webkit.org/show_bug.cgi?id=170749 Reviewed by Alex Christensen. * Configurations/FeatureDefines.xcconfig: 2017-04-17 Yusuke Suzuki [JSCOnly] Fix build failures in macOS https://bugs.webkit.org/show_bug.cgi?id=170887 Reviewed by Alex Christensen. Align ICU header configuration to MacCMake port. * PlatformJSCOnly.cmake: 2017-04-17 JF Bastien B3: don't allow unsigned offsets in Value https://bugs.webkit.org/show_bug.cgi?id=170692 Reviewed by Filip Pizlo. MemoryValue and similar B3 opcode classes always expects a signed offset. Giving it an out-of-bounds unsigned offset causes implementation-defined behavior, which can cause badness as I just fixed in WebAssembly. This patch makes it impossible to create a Value opcodes with an unsigned value, or with an overly-large value. * b3/B3AtomicValue.cpp: (JSC::B3::AtomicValue::AtomicValue): * b3/B3AtomicValue.h: * b3/B3Common.h: (JSC::B3::isRepresentableAs): * b3/B3EliminateCommonSubexpressions.cpp: * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::scaleForShl): (JSC::B3::Air::LowerToAir::effectiveAddr): (JSC::B3::Air::LowerToAir::addr): (JSC::B3::Air::LowerToAir::tryAppendLea): * b3/B3MemoryValue.cpp: (JSC::B3::MemoryValue::isLegalOffsetImpl): (JSC::B3::MemoryValue::MemoryValue): * b3/B3MemoryValue.h: * b3/B3MemoryValueInlines.h: (JSC::B3::MemoryValue::isLegalOffsetImpl): * b3/B3MoveConstants.cpp: * b3/B3ReduceStrength.cpp: * b3/B3StackmapSpecial.cpp: (JSC::B3::StackmapSpecial::repForArg): * b3/B3Value.h: * b3/air/AirArg.cpp: (JSC::B3::Air::Arg::stackAddrImpl): * b3/air/AirArg.h: (JSC::B3::Air::Arg::addr): (JSC::B3::Air::Arg::stack): (JSC::B3::Air::Arg::callArg): (JSC::B3::Air::Arg::stackAddr): (JSC::B3::Air::Arg::index): (JSC::B3::Air::Arg::offset): (JSC::B3::Air::Arg::isValidAddrForm): (JSC::B3::Air::Arg::isValidIndexForm): (JSC::B3::Air::Arg::asTrustedImm32): (JSC::B3::Air::Arg::asAddress): (JSC::B3::Air::Arg::asBaseIndex): * b3/air/AirLowerStackArgs.cpp: (JSC::B3::Air::lowerStackArgs): * b3/testb3.cpp: (JSC::B3::testMulArgStore): (JSC::B3::testStore32): (JSC::B3::testStoreConstant): (JSC::B3::testStoreConstantPtr): (JSC::B3::testStoreAddLoad32): (JSC::B3::testStoreAddLoadImm32): (JSC::B3::testStoreAddLoad8): (JSC::B3::testStoreAddLoadImm8): (JSC::B3::testStoreAddLoad16): (JSC::B3::testStoreAddLoadImm16): (JSC::B3::testStoreAddLoad64): (JSC::B3::testStoreAddLoadImm64): (JSC::B3::testStoreAddLoad32Index): (JSC::B3::testStoreAddLoadImm32Index): (JSC::B3::testStoreAddLoad64Index): (JSC::B3::testStoreAddLoadImm64Index): (JSC::B3::testStoreSubLoad): (JSC::B3::testStoreAddLoadInterference): (JSC::B3::testStoreAddAndLoad): (JSC::B3::testStoreNegLoad32): (JSC::B3::testStoreNegLoadPtr): (JSC::B3::testLoadOffset): (JSC::B3::testLoadOffsetNotConstant): (JSC::B3::testLoadOffsetUsingAdd): (JSC::B3::testLoadOffsetUsingAddInterference): (JSC::B3::testLoadOffsetUsingAddNotConstant): (JSC::B3::testStoreLoadStackSlot): (JSC::B3::testLoad): (JSC::B3::testInterpreter): (JSC::B3::testTrappingStore): (JSC::B3::testTrappingLoadAddStore): (JSC::B3::testWasmAddress): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::fixupPointerPlusOffset): (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer): (JSC::Wasm::B3IRGenerator::emitLoadOp): (JSC::Wasm::B3IRGenerator::emitStoreOp): 2017-04-16 Joseph Pecoraro test262: test262/test/built-ins/Object/prototype/toLocaleString/primitive_this_value.js https://bugs.webkit.org/show_bug.cgi?id=170882 Reviewed by Saam Barati. * runtime/ObjectPrototype.cpp: (JSC::objectProtoFuncToLocaleString): We should be using the this value without ToObject conversion both when getting the potential accessor and calling it. In strict mode, the this value will remain its simple value, in non-strict it is still converted. 2017-04-16 Joseph Pecoraro test262: test262/test/built-ins/isNaN/toprimitive-not-callable-throws.js https://bugs.webkit.org/show_bug.cgi?id=170888 Reviewed by Saam Barati. * runtime/ExceptionHelpers.h: * runtime/ExceptionHelpers.cpp: (JSC::createInvalidInstanceofParameterErrorHasInstanceValueNotFunction): Fix up this function name. * runtime/JSObject.cpp: (JSC::callToPrimitiveFunction): When called with @@isPrimitive, bail on undefined or null and throw a type error if the value is not callable. (JSC::JSObject::toPrimitive): Use throw scope to check for exception. 2017-04-16 Joseph Pecoraro test262: test262/test/language/expressions/tagged-template/template-object.js https://bugs.webkit.org/show_bug.cgi?id=170878 Reviewed by Saam Barati. * runtime/JSArray.cpp: (JSC::JSArray::put): The fast path for setting an Array's length should check if length is writable before checking for and possibly throwing a RangeError. 2017-04-16 Joseph Pecoraro test262: test262/test/built-ins/Object/getOwnPropertyNames/15.2.3.4-4-44.js https://bugs.webkit.org/show_bug.cgi?id=170879 Reviewed by Saam Barati. * runtime/StringObject.h: * runtime/StringObject.cpp: (JSC::StringObject::getOwnPropertyNames): (JSC::StringObject::getOwnNonIndexPropertyNames): Ensure 'length' comes after all indexed properties by moving it out to the getOwnNonIndexPropertyNames method which is called inside of getOwnPropertyNames after JSObject handles indices. 2017-04-16 Joseph Pecoraro test262: test262/test/built-ins/Date/prototype/Symbol.toPrimitive/name.js https://bugs.webkit.org/show_bug.cgi?id=170884 Reviewed by Yusuke Suzuki. * runtime/DatePrototype.cpp: (JSC::DatePrototype::finishCreation): * runtime/FunctionPrototype.cpp: (JSC::FunctionPrototype::addFunctionProperties): * runtime/RegExpPrototype.cpp: (JSC::RegExpPrototype::finishCreation): * runtime/SymbolPrototype.cpp: (JSC::SymbolPrototype::finishCreation): Give symbol property functions proper function names. This addresses function.name but not function.toString(). 2017-04-15 Joseph Pecoraro test262: test262/test/language/global-code/new.target-arrow.js https://bugs.webkit.org/show_bug.cgi?id=170872 Reviewed by Saam Barati. * parser/Parser.cpp: (JSC::Parser::Parser): Mark the global code scope. (JSC::Parser::parseMemberExpression): If new.target is detected in an arrow function defined in global scope throw a SyntaxError. * parser/Parser.h: (JSC::Scope::Scope): (JSC::Scope::setIsGlobalCodeScope): (JSC::Scope::isGlobalCodeScope): Marker for a global code scope. * parser/ParserModes.h: (JSC::isModuleParseMode): (JSC::isProgramParseMode): (JSC::isProgramOrModuleParseMode): Helper for detecting global code based on parse mode. 2017-04-14 Nikita Vasilyev Web Inspector: WebSockets: messages with non-latin letters are displayed incorrectly https://bugs.webkit.org/show_bug.cgi?id=170760 Reviewed by Joseph Pecoraro. Add payloadLength property, which is used to display size. When payloadLength is unavailable, it is calculated from payloadData by Web Inspector frontend. This fixes Web Inspector: WebSockets: Transferred size is incorrect. * inspector/protocol/Network.json: 2017-04-14 Saam Barati ParseInt intrinsic in DFG backend doesn't properly flush its operands https://bugs.webkit.org/show_bug.cgi?id=170865 Reviewed by Mark Lam and Geoffrey Garen. The DFG backend code needed to first call .gpr()/.jsValueRegs() before calling flushRegisters(), or the input JSValueOperand would not be flushed. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileParseInt): 2017-04-14 Mark Lam Update architectures in xcconfig files. https://bugs.webkit.org/show_bug.cgi?id=170867 Reviewed by Joseph Pecoraro. * Configurations/Base.xcconfig: * Configurations/FeatureDefines.xcconfig: * Configurations/JavaScriptCore.xcconfig: * Configurations/ToolExecutable.xcconfig: 2017-04-14 Keith Miller WebAssembly: B3IRGenerator should use phis for result types https://bugs.webkit.org/show_bug.cgi?id=170863 Reviewed by Filip Pizlo. Currently, we use variables for the result types of control flow in Wasm. We did this originally since we weren't sure that the phis we generated would be optimal. Since then, we have verified that the edges in wasm control flow ensure that each upsilon will dominate its phi so we don't need to use variables. * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::ControlData::ControlData): (JSC::Wasm::B3IRGenerator::addTopLevel): (JSC::Wasm::B3IRGenerator::addBlock): (JSC::Wasm::B3IRGenerator::addLoop): (JSC::Wasm::B3IRGenerator::unify): 2017-04-14 Alex Christensen Fix Windows build after r215368. https://bugs.webkit.org/show_bug.cgi?id=170641 * CMakeLists.txt: Add new directory containing files needed in WebCore. 2017-04-14 Caitlin Potter [JSC] use ExpressionErrorClassifier for AwaitExpression operand https://bugs.webkit.org/show_bug.cgi?id=170844 Reviewed by Saam Barati. In parseAssignmentExpression(), several cover grammars are handled, and use ExpressionErrorClassifier to record hints about which grammars to try. In parseAwaitExpression(), the hints recorded during parsing of the operand need to be discarded, because if they propagate to the outer parseAssignmentExpression(), the hints will lead the parser down invalid branches that should be skipped. This change adds an additional ExpressionErrorClassifier to parseAwaitExpression(), in order to discard hints recorded trying to parse the operand. * parser/Parser.cpp: (JSC::Parser::parseAwaitExpression): 2017-04-14 Saam Barati WebAssembly: There is a short window of time where a CodeBlock could be destroyed before all of its async compilation callbacks are called https://bugs.webkit.org/show_bug.cgi?id=170641 Reviewed by Keith Miller. There is an unlikely race when a CodeBlock compilation fails, the module compiles a new CodeBlock for that memory mode, all while the CodeBlock is notifying its callbacks that it has finished. There is a chance that the Module could deref its failed CodeBlock at that point, destroying it, before the callbacks were able to grab a Ref to the CodeBlock. This patch fixes the race by having the callbacks ref the CodeBlock. This patch also has the Plan clear out all of its callbacks once it gets completed. This adds an extra defense to anybody that grabs refs to the Plan in the callback. * wasm/WasmCodeBlock.cpp: (JSC::Wasm::CodeBlock::CodeBlock): (JSC::Wasm::CodeBlock::compileAsync): * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::complete): 2017-04-13 Filip Pizlo Air::RegLiveness should be constraint-based https://bugs.webkit.org/show_bug.cgi?id=170817 Reviewed by Saam Barati. Previously, I changed the Air liveness analyses based on Air::Liveness<> to be constraint-based and this was a significant speed-up. Now I'm adding the same functionality to RegLiveness. This is a 1% speed-up on wasm B3 -O1 compile times. * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp: * b3/air/AirLivenessAdapter.h: (JSC::B3::Air::LivenessAdapter::LivenessAdapter): (JSC::B3::Air::LivenessAdapter::prepareToCompute): (JSC::B3::Air::LivenessAdapter::actionsAt): * b3/air/AirRegLiveness.cpp: (JSC::B3::Air::RegLiveness::RegLiveness): (JSC::B3::Air::RegLiveness::LocalCalcForUnifiedTmpLiveness::LocalCalcForUnifiedTmpLiveness): (JSC::B3::Air::RegLiveness::LocalCalcForUnifiedTmpLiveness::execute): (JSC::B3::Air::RegLiveness::LocalCalc::execute): Deleted. * b3/air/AirRegLiveness.h: (JSC::B3::Air::RegLiveness::Actions::Actions): (JSC::B3::Air::RegLiveness::LocalCalcBase::LocalCalcBase): (JSC::B3::Air::RegLiveness::LocalCalcBase::live): (JSC::B3::Air::RegLiveness::LocalCalcBase::isLive): (JSC::B3::Air::RegLiveness::LocalCalc::LocalCalc): (JSC::B3::Air::RegLiveness::LocalCalc::execute): (JSC::B3::Air::RegLiveness::LocalCalc::live): Deleted. (JSC::B3::Air::RegLiveness::LocalCalc::isLive): Deleted. 2017-04-13 JF Bastien WebAssembly: fix windows build https://bugs.webkit.org/show_bug.cgi?id=170832 Reviewed by Mark Lam. My previous patch re-declared isIOS which AssemblerCommon.h already provided, and which was already included by Options.cpp. * runtime/Options.cpp: 2017-04-13 Saam Barati WebAssembly: We should be able to postMessage a JSWebAssemblyModule https://bugs.webkit.org/show_bug.cgi?id=170573 Reviewed by Filip Pizlo. This patch adds a callback to JSRunLoopTimer to notify clients that a timer has been set. This is used inside WorkerRunLoop in WebCore so that its RunLoop can perform an iteration when it sees that a timer got set. * JavaScriptCore.xcodeproj/project.pbxproj: * runtime/JSRunLoopTimer.cpp: (JSC::JSRunLoopTimer::scheduleTimer): (JSC::JSRunLoopTimer::addTimerSetNotification): (JSC::JSRunLoopTimer::removeTimerSetNotification): * runtime/JSRunLoopTimer.h: * wasm/WasmCodeBlock.cpp: (JSC::Wasm::CodeBlock::~CodeBlock): * wasm/WasmCodeBlock.h: * wasm/WasmModule.cpp: (JSC::Wasm::Module::~Module): (JSC::Wasm::Module::signatureIndexFromFunctionIndexSpace): (JSC::Wasm::makeValidationCallback): (JSC::Wasm::Module::validateSync): (JSC::Wasm::Module::validateAsync): (JSC::Wasm::Module::validateSyncImpl): Deleted. (JSC::Wasm::Module::makeValidationCallback): Deleted. * wasm/WasmModule.h: (JSC::Wasm::Module::validateSync): Deleted. (JSC::Wasm::Module::validateAsync): Deleted. (JSC::Wasm::Module::signatureIndexFromFunctionIndexSpace): Deleted. (JSC::Wasm::Module::nonNullCodeBlock): Deleted. * wasm/js/JSWebAssemblyCodeBlock.cpp: (JSC::JSWebAssemblyCodeBlock::create): * wasm/js/JSWebAssemblyCodeBlock.h: (JSC::JSWebAssemblyCodeBlock::create): Deleted. * wasm/js/JSWebAssemblyModule.cpp: (JSC::JSWebAssemblyModule::source): * wasm/js/JSWebAssemblyModule.h: (JSC::JSWebAssemblyModule::source): Deleted. * wasm/js/WebAssemblyFunction.cpp: (JSC::callWebAssemblyFunction): * wasm/js/WebAssemblyModulePrototype.cpp: 2017-04-13 Mark Lam Should use flushDirect() when flushing the scopeRegister due to needsScopeRegister(). https://bugs.webkit.org/show_bug.cgi?id=170661 Reviewed by Filip Pizlo. Previously, we were using flush() to flush the outermost frame's scopeRegister. This is incorrect because flush() expects the VirtualRegister value passed to it to be that of the top most inlined frame. In the event that we reach a terminal condition while inside an inlined frame, flush() will end up flushing the wrong register. The fix is simply to use flushDirect() instead. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::flush): 2017-04-13 Andy VanWagoner Change Intl prototypes to plain objects https://bugs.webkit.org/show_bug.cgi?id=168178 Reviewed by JF Bastien. * builtins/StringPrototype.js: (localeCompare): Create default Collator once instead of using prototype. * runtime/IntlCollatorPrototype.cpp: (JSC::IntlCollatorPrototype::IntlCollatorPrototype): * runtime/IntlCollatorPrototype.h: * runtime/IntlDateTimeFormatPrototype.cpp: (JSC::IntlDateTimeFormatPrototype::IntlDateTimeFormatPrototype): * runtime/IntlDateTimeFormatPrototype.h: * runtime/IntlNumberFormatPrototype.cpp: (JSC::IntlNumberFormatPrototype::IntlNumberFormatPrototype): * runtime/IntlNumberFormatPrototype.h: * runtime/IntlObject.cpp: (JSC::IntlObject::finishCreation): Don't set constructor on each prototype. 2017-04-13 Oliver Hunt allocationSize should use safe arithmetic by default https://bugs.webkit.org/show_bug.cgi?id=170804 Reviewed by JF Bastien. Make all allocationSize() functions work in terms of Checked * runtime/DirectArguments.h: (JSC::DirectArguments::offsetOfSlot): (JSC::DirectArguments::allocationSize): * runtime/HashMapImpl.h: (JSC::HashMapBuffer::allocationSize): * runtime/JSArray.h: (JSC::JSArray::allocationSize): * runtime/JSArrayBufferView.h: (JSC::JSArrayBufferView::allocationSize): * runtime/JSAsyncFunction.h: (JSC::JSAsyncFunction::allocationSize): * runtime/JSFixedArray.h: (JSC::JSFixedArray::allocationSize): * runtime/JSFunction.h: (JSC::JSFunction::allocationSize): * runtime/JSGeneratorFunction.h: (JSC::JSGeneratorFunction::allocationSize): * runtime/JSModuleNamespaceObject.h: * runtime/JSObject.h: (JSC::JSFinalObject::allocationSize): * runtime/JSWrapperObject.h: (JSC::JSWrapperObject::allocationSize): * runtime/ScopedArguments.h: (JSC::ScopedArguments::allocationSize): * runtime/VM.h: (JSC::ScratchBuffer::allocationSize): * wasm/js/JSWebAssemblyCodeBlock.h: (JSC::JSWebAssemblyCodeBlock::offsetOfImportStubs): (JSC::JSWebAssemblyCodeBlock::allocationSize): * wasm/js/JSWebAssemblyInstance.h: (JSC::JSWebAssemblyInstance::allocationSize): 2017-04-13 JF Bastien WebAssembly: manage memory better https://bugs.webkit.org/show_bug.cgi?id=170628 Reviewed by Keith Miller, Michael Saboff. WebAssembly fast memories weren't managed very well. This patch refactors it and puts us in a good position to further improve our fast memory handling in the future. We now cache fast memories at a process granularity, but make sure that they don't consume dirty pages. We add a cap to the total number of allocated fast memories to avoid ASLR degradation. We teach the GC about memories as a kind of resource it should care about because it didn't have visibility into the amount of memory each represented. This allows benchmarks which allocate memories back-to-back to reliably get fast memories 100% of the time, even on a system under load, which wasn't the case before. This reliability yields roughly 8% perf bump on x86-64 WasmBench. The GC heuristic is as follows: each time we allocate a fast memory we notify the GC, which then keeps track of the total number of fast memories allocated since it last GC'd. We separately keep track of the total number of fast memories which have ever existed at any point in time (cached + allocated). This is a monotonically-increasing high watermark. The GC will force a full collection if, since it last ran, half or more of the high watermark of fast memories was allocated. At the same time, if we fail obtaining a fast memory from the cache we do a GC to try to find one. If that fails we'll allocate a new one (this can also fail, then we go to slow memory). This can also be improved, but it's a good start. This currently disables fast memories on iOS because getting fast memories isn't a guaranteed thing. Rather, we get quite a few of them and achieve significant speedups, but benchmarks which allocate memories back-to-back end up falling behind because the GC can conservatively hold onto memories, which then yields a perf cliff. That cliff isn't reliable, WasmBench gets roughly 10 of 18 fast memories when in theory it should get all of them fast (as MacOS does). The patch significantly improves the state of iOS though, and in a follow-up we could re-enable fast memories. Part of this good positioning is a facility to pre-allocate fast memories very early at startup, before any fragmentation occurs. This is currently disabled but worked extremely reliably on iOS. Once we fix the above issues we'll want to re-visit and turn on pre-allocation. We also avoid locking for fast memory identification when performing signal handling. I'm very nervous about acquiring locks in a signal handler because in general signals can happen when we've messed up. This isn't the case with fast memories: we're raising a signal on purpose and handling it. However this doesn't mean we won't mess up elsewhere! This will get more complicated once we add support for multiple threads sharing memories and being able to grow their memories. One example: the code calls CRASH(), which executes the following code in release: *(int *)(uintptr_t)0xbbadbeef = 0; This is a segfault, which our fast memory signal handler tries to handle. It does so by first figuring out whether 0xbbadbeef is in a fast memory region, reqiring a lock. If we CRASH() while holding the lock then our thread self-deadlocks, giving us no crash report and a bad user experience. Avoiding a lock therefore it's not about speed or reduced contention. In fact, I'd use something else than a FIFO if these were a concern. We're also doing syscalls, which dwarf any locking cost. We now only allocate 4GiB + redzone of 64k * 128 for fast memories instead of 8GiB. This patch reuses the logic from B3::WasmBoundsCheck to perform bounds checks when accesses could exceed the redzone. We'll therefore benefit from CSE goodness when it reaches WasmBoundsCheck. See bug #163469. * b3/B3LowerToAir.cpp: fix a baaaaddd bug where unsigned->signed conversion allowed out-of-bounds reads by -2GiB. I'll follow-up in bug #170692 to prevent this type of bug once and for all. (JSC::B3::Air::LowerToAir::lower): * b3/B3Validate.cpp: update WasmBoundsCheck validation. * b3/B3Value.cpp: (JSC::B3::Value::effects): update WasmBoundsCheck effects. * b3/B3WasmBoundsCheckValue.cpp: (JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue): (JSC::B3::WasmBoundsCheckValue::redzoneLimit): (JSC::B3::WasmBoundsCheckValue::dumpMeta): * b3/B3WasmBoundsCheckValue.h: (JSC::B3::WasmBoundsCheckValue::maximum): * b3/air/AirCustom.cpp: (JSC::B3::Air::WasmBoundsCheckCustom::isValidForm): * b3/testb3.cpp: (JSC::B3::testWasmBoundsCheck): * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::reportWebAssemblyFastMemoriesAllocated): (JSC::Heap::webAssemblyFastMemoriesThisCycleAtThreshold): (JSC::Heap::updateAllocationLimits): (JSC::Heap::didAllocateWebAssemblyFastMemories): (JSC::Heap::shouldDoFullCollection): (JSC::Heap::collectIfNecessaryOrDefer): * heap/Heap.h: * runtime/InitializeThreading.cpp: (JSC::initializeThreading): * runtime/Options.cpp: * runtime/Options.h: * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::fixupPointerPlusOffset): (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer): (JSC::Wasm::B3IRGenerator::emitLoadOp): (JSC::Wasm::B3IRGenerator::emitStoreOp): (JSC::Wasm::createJSToWasmWrapper): * wasm/WasmFaultSignalHandler.cpp: (JSC::Wasm::trapHandler): * wasm/WasmMemory.cpp: Rewrite. (JSC::Wasm::makeString): (JSC::Wasm::Memory::initializePreallocations): (JSC::Wasm::Memory::createImpl): (JSC::Wasm::Memory::create): (JSC::Wasm::Memory::~Memory): (JSC::Wasm::Memory::fastMappedRedzoneBytes): (JSC::Wasm::Memory::fastMappedBytes): (JSC::Wasm::Memory::maxFastMemoryCount): (JSC::Wasm::Memory::addressIsInActiveFastMemory): (JSC::Wasm::Memory::grow): * wasm/WasmMemory.h: (Memory::maxFastMemoryCount): (Memory::addressIsInActiveFastMemory): * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::finishCreation): (JSC::JSWebAssemblyInstance::visitChildren): (JSC::JSWebAssemblyInstance::globalMemoryByteSize): * wasm/js/JSWebAssemblyInstance.h: * wasm/js/JSWebAssemblyMemory.cpp: (JSC::JSWebAssemblyMemory::grow): (JSC::JSWebAssemblyMemory::finishCreation): (JSC::JSWebAssemblyMemory::visitChildren): 2017-04-13 Yusuke Suzuki [JSC] Use proper ifdef guard for code using MachineContext https://bugs.webkit.org/show_bug.cgi?id=170800 Reviewed by Carlos Alberto Lopez Perez. This patch drops MachineContext use if it is not available. This situation can be considered like, building WebKit with musl. In that case, we simply disable features that rely on MachineContext. Examples are wasm fast memory, sampling profiler, and code profiling. * runtime/Options.cpp: (JSC::overrideDefaults): * tools/CodeProfiling.cpp: (JSC::CodeProfiling::begin): (JSC::CodeProfiling::end): Previously, PLATFORM(GTK) is excluded. But it is not obvious why it is excluded. This patch just includes such platforms. * wasm/WasmFaultSignalHandler.cpp: (JSC::Wasm::enableFastMemory): 2017-04-12 Dan Bernstein [Mac] Future-proof .xcconfig files https://bugs.webkit.org/show_bug.cgi?id=170802 Reviewed by Tim Horton. * Configurations/Base.xcconfig: * Configurations/DebugRelease.xcconfig: * Configurations/FeatureDefines.xcconfig: * Configurations/Version.xcconfig: 2017-04-12 Joseph Pecoraro test262: test262/test/built-ins/NativeErrors/EvalError/proto.js https://bugs.webkit.org/show_bug.cgi?id=170668 Reviewed by Keith Miller. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): The [[Prototype]] of NativeError Constructor's should be the %Error%. https://tc39.github.io/ecma262/#sec-properties-of-the-nativeerror-constructors 2017-04-12 Joseph Pecoraro test262: test262/test/language/literals/regexp/u-dec-esc.js https://bugs.webkit.org/show_bug.cgi?id=170687 Reviewed by Michael Saboff. * yarr/YarrParser.h: (JSC::Yarr::Parser::parseEscape): * yarr/YarrPattern.cpp: (JSC::Yarr::YarrPattern::errorMessage): (JSC::Yarr::YarrPattern::compile): * yarr/YarrPattern.h: In unicoe patterns, invalid backreferences are an error. 2017-04-12 Filip Pizlo Move common stack allocation utilities out of AirAllocateStackByGraphColoring.cpp https://bugs.webkit.org/show_bug.cgi?id=170799 Reviewed by Michael Saboff and Keith Miller. When I added stack allocation to allocateRegistersByLinearScan, I reused a handful of utility functions from AirAllocateStackByGraphColoring.cpp. I accomplished this by putting their declarations in AirAllocateStackByGraphColoring.h. That was pretty weird. This patch moves a family of stack allocation helper functions out of AirAllocateStackByGraphColoring.cpp and into the new AirStackAllocation.h|cpp. The linear scan stack allocator no longer has to include the other stack allocator's header, which addresses my OCD. I moved the functions transitively reachable from the two functions that the linear scan allocator needed. This forced me to give them better names (i.e. no "fooBarImpl") and short descriptive comments. I think that such comments are useful in code that is doing a convoluted version of some theoretical concept. No behavior change. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp: * b3/air/AirAllocateStackByGraphColoring.cpp: (JSC::B3::Air::allocateStackByGraphColoring): (JSC::B3::Air::allocateEscapedStackSlots): Deleted. (JSC::B3::Air::updateFrameSizeBasedOnStackSlots): Deleted. * b3/air/AirAllocateStackByGraphColoring.h: * b3/air/AirStackAllocation.cpp: Added. (JSC::B3::Air::attemptAssignment): (JSC::B3::Air::assign): (JSC::B3::Air::allocateAndGetEscapedStackSlotsWithoutChangingFrameSize): (JSC::B3::Air::allocateEscapedStackSlots): (JSC::B3::Air::updateFrameSizeBasedOnStackSlots): * b3/air/AirStackAllocation.h: Added. 2017-04-12 Filip Pizlo B3 -O1 should not allocateStackByGraphColoring https://bugs.webkit.org/show_bug.cgi?id=170742 Reviewed by Keith Miller. One of B3 -O1's longest running phases is allocateStackByGraphColoring. One approach to this would be to make that phase cheaper. But it's weird that this phase reruns liveness after register allocation already ran liveness. If only it could reuse the liveness computed by register allocation then it would run a lot faster. At -O2, we do not want this, since we run phases between register allocation and stack allocation, and those phases are free to change the liveness of spill slots (in fact, fixObviousSpills will both shorten and lengthen live ranges because of load and store elimination, respectively). But at -O1, we don't really need to run any phases between register and stack allocation. This changes Air's backend in the following ways: - Linear scan does stack allocation. This means that we don't need to run allocateStackByGraphColoring at all. In reality, we reuse some of its innards, but we don't run the expensive part of it (liveness->interference->coalescing->coloring). This is a speed-up because we only run liveness once and reuse it for both register and stack allocation. - Phases that previously ran between register and stack allocation are taken care of, each in its own special way: -> handleCalleSaves: this is now a utility function called by both allocateStackByGraphColoring and allocateRegistersAndStackByLinearScan. -> fixObviousSpills: we didn't run this at -O1, so nothing needs to be done. -> lowerAfterRegAlloc: this needed to be able to run before stack allocation because it could change register usage (vis a vis callee saves) and it could introduce spill slots. I changed this phase to have a secondary mode for when it runs after stack allocation. - The part of allocateStackByGraphColoring that lowered stack addresses and took care of the call arg area is now a separate phase called lowerStackArgs. We run this phase regardless of optimization level. It's a cheap and general lowering. This also removes spillEverything, because we never use that phase, we never test it, and it got in the way in this refactoring. This is a 21% speed-up on wasm -O1 compile times. This does not significantly change -O1 throughput. We had already disabled allocateStack's most important optimization (spill coalescing). This probably regresses average stack frame size, but I didn't measure by how much. Stack frame size is really not that important. The algorithm in allocateStackByGraphColoring is about much more than optimal frame size; it also tries to avoid having to zero-extend 32-bit spills, it kills dead code, and of course it coalesces. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * b3/B3Procedure.cpp: (JSC::B3::Procedure::calleeSaveRegisterAtOffsetList): (JSC::B3::Procedure::calleeSaveRegisters): Deleted. * b3/B3Procedure.h: * b3/B3StackmapGenerationParams.cpp: (JSC::B3::StackmapGenerationParams::unavailableRegisters): * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp: Copied from Source/JavaScriptCore/b3/air/AirAllocateRegistersByLinearScan.cpp. (JSC::B3::Air::allocateRegistersAndStackByLinearScan): (JSC::B3::Air::allocateRegistersByLinearScan): Deleted. * b3/air/AirAllocateRegistersAndStackByLinearScan.h: Copied from Source/JavaScriptCore/b3/air/AirAllocateRegistersByLinearScan.h. * b3/air/AirAllocateRegistersByLinearScan.cpp: Removed. * b3/air/AirAllocateRegistersByLinearScan.h: Removed. * b3/air/AirAllocateStackByGraphColoring.cpp: (JSC::B3::Air::allocateEscapedStackSlots): (JSC::B3::Air::updateFrameSizeBasedOnStackSlots): (JSC::B3::Air::allocateStackByGraphColoring): * b3/air/AirAllocateStackByGraphColoring.h: * b3/air/AirArg.cpp: (JSC::B3::Air::Arg::stackAddr): * b3/air/AirArg.h: (JSC::B3::Air::Arg::stackAddr): Deleted. * b3/air/AirCode.cpp: (JSC::B3::Air::Code::addStackSlot): (JSC::B3::Air::Code::setCalleeSaveRegisterAtOffsetList): (JSC::B3::Air::Code::calleeSaveRegisterAtOffsetList): (JSC::B3::Air::Code::dump): * b3/air/AirCode.h: (JSC::B3::Air::Code::setStackIsAllocated): (JSC::B3::Air::Code::stackIsAllocated): (JSC::B3::Air::Code::calleeSaveRegisters): * b3/air/AirGenerate.cpp: (JSC::B3::Air::prepareForGeneration): (JSC::B3::Air::generate): * b3/air/AirHandleCalleeSaves.cpp: (JSC::B3::Air::handleCalleeSaves): * b3/air/AirHandleCalleeSaves.h: * b3/air/AirLowerAfterRegAlloc.cpp: (JSC::B3::Air::lowerAfterRegAlloc): * b3/air/AirLowerStackArgs.cpp: Added. (JSC::B3::Air::lowerStackArgs): * b3/air/AirLowerStackArgs.h: Added. * b3/testb3.cpp: (JSC::B3::testPinRegisters): * ftl/FTLCompile.cpp: (JSC::FTL::compile): * jit/RegisterAtOffsetList.h: * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::parseAndCompile): 2017-04-12 Michael Saboff Implement Object.isFrozen() and Object.isSealed() per ECMA spec https://bugs.webkit.org/show_bug.cgi?id=170753 Reviewed by Mark Lam. * runtime/ObjectConstructor.cpp: (JSC::testIntegrityLevel): Added local helper as described in the ECMA standard. (JSC::objectConstructorSeal): (JSC::objectConstructorFreeze): Eliminated incomplete special handling of JSFinalObjects. (JSC::objectConstructorIsSealed): (JSC::objectConstructorIsFrozen): Refactored to use the new testIntegrityLevel() helper. 2017-04-12 Yusuke Suzuki Use HAVE(MACHINE_CONTEXT) instead of USE(MACHINE_CONTEXT) https://bugs.webkit.org/show_bug.cgi?id=170770 Rubber stamped by Mark Lam. * heap/MachineStackMarker.cpp: (JSC::MachineThreads::MachineThread::Registers::framePointer): (JSC::MachineThreads::MachineThread::Registers::instructionPointer): (JSC::MachineThreads::MachineThread::Registers::llintPC): * runtime/MachineContext.h: (JSC::MachineContext::stackPointer): (JSC::MachineContext::framePointer): (JSC::MachineContext::instructionPointer): (JSC::MachineContext::argumentPointer<1>): (JSC::MachineContext::llintInstructionPointer): 2017-04-12 Yusuke Suzuki [JSC] Clean up heap/MachineStackMarker by introducing USE(MACHINE_CONTEXT) https://bugs.webkit.org/show_bug.cgi?id=170770 Reviewed by Mark Lam. We use USE(MACHINE_CONTEXT) to clean up runtime/MachineContext.h. And we clean up heap/MachineStackMarker.cpp by using MachineContext functions. * heap/MachineStackMarker.cpp: (JSC::MachineThreads::MachineThread::Registers::stackPointer): (JSC::MachineThreads::MachineThread::Registers::framePointer): (JSC::MachineThreads::MachineThread::Registers::instructionPointer): (JSC::MachineThreads::MachineThread::Registers::llintPC): * heap/MachineStackMarker.h: * runtime/MachineContext.h: (JSC::MachineContext::stackPointer): (JSC::MachineContext::framePointer): (JSC::MachineContext::instructionPointer): (JSC::MachineContext::argumentPointer<1>): (JSC::MachineContext::llintInstructionPointer): 2017-04-12 Yusuke Suzuki [WTF] Introduce Thread class and use RefPtr and align Windows Threading implementation semantics to Pthread one https://bugs.webkit.org/show_bug.cgi?id=170502 Reviewed by Mark Lam. * API/tests/CompareAndSwapTest.cpp: (testCompareAndSwap): * JavaScriptCore.xcodeproj/project.pbxproj: * b3/air/testair.cpp: * b3/testb3.cpp: (JSC::B3::run): * bytecode/SuperSampler.cpp: (JSC::initializeSuperSampler): * dfg/DFGWorklist.cpp: * disassembler/Disassembler.cpp: * heap/Heap.cpp: (JSC::Heap::lastChanceToFinalize): (JSC::Heap::notifyIsSafeToCollect): * heap/Heap.h: * heap/MachineStackMarker.cpp: (JSC::MachineThreads::~MachineThreads): (JSC::MachineThreads::addCurrentThread): (JSC::MachineThreads::removeThread): (JSC::MachineThreads::removeThreadIfFound): (JSC::MachineThreads::MachineThread::MachineThread): (JSC::MachineThreads::MachineThread::getRegisters): (JSC::MachineThreads::MachineThread::Registers::stackPointer): (JSC::MachineThreads::MachineThread::Registers::framePointer): (JSC::MachineThreads::MachineThread::Registers::instructionPointer): (JSC::MachineThreads::MachineThread::Registers::llintPC): (JSC::MachineThreads::MachineThread::captureStack): (JSC::MachineThreads::tryCopyOtherThreadStack): (JSC::MachineThreads::tryCopyOtherThreadStacks): (pthreadSignalHandlerSuspendResume): Deleted. (JSC::threadData): Deleted. (JSC::MachineThreads::Thread::Thread): Deleted. (JSC::MachineThreads::Thread::createForCurrentThread): Deleted. (JSC::MachineThreads::Thread::operator==): Deleted. (JSC::MachineThreads::machineThreadForCurrentThread): Deleted. (JSC::MachineThreads::ThreadData::ThreadData): Deleted. (JSC::MachineThreads::ThreadData::~ThreadData): Deleted. (JSC::MachineThreads::ThreadData::suspend): Deleted. (JSC::MachineThreads::ThreadData::resume): Deleted. (JSC::MachineThreads::ThreadData::getRegisters): Deleted. (JSC::MachineThreads::ThreadData::Registers::stackPointer): Deleted. (JSC::MachineThreads::ThreadData::Registers::framePointer): Deleted. (JSC::MachineThreads::ThreadData::Registers::instructionPointer): Deleted. (JSC::MachineThreads::ThreadData::Registers::llintPC): Deleted. (JSC::MachineThreads::ThreadData::freeRegisters): Deleted. (JSC::MachineThreads::ThreadData::captureStack): Deleted. * heap/MachineStackMarker.h: (JSC::MachineThreads::MachineThread::suspend): (JSC::MachineThreads::MachineThread::resume): (JSC::MachineThreads::MachineThread::threadID): (JSC::MachineThreads::MachineThread::stackBase): (JSC::MachineThreads::MachineThread::stackEnd): (JSC::MachineThreads::threadsListHead): (JSC::MachineThreads::Thread::operator!=): Deleted. (JSC::MachineThreads::Thread::suspend): Deleted. (JSC::MachineThreads::Thread::resume): Deleted. (JSC::MachineThreads::Thread::getRegisters): Deleted. (JSC::MachineThreads::Thread::freeRegisters): Deleted. (JSC::MachineThreads::Thread::captureStack): Deleted. (JSC::MachineThreads::Thread::platformThread): Deleted. (JSC::MachineThreads::Thread::stackBase): Deleted. (JSC::MachineThreads::Thread::stackEnd): Deleted. * jit/ICStats.cpp: (JSC::ICStats::ICStats): (JSC::ICStats::~ICStats): * jit/ICStats.h: * jsc.cpp: (functionDollarAgentStart): (startTimeoutThreadIfNeeded): * runtime/JSLock.cpp: (JSC::JSLock::lock): * runtime/JSLock.h: (JSC::JSLock::ownerThread): (JSC::JSLock::currentThreadIsHoldingLock): * runtime/SamplingProfiler.cpp: (JSC::FrameWalker::isValidFramePointer): (JSC::SamplingProfiler::SamplingProfiler): (JSC::SamplingProfiler::createThreadIfNecessary): (JSC::SamplingProfiler::takeSample): * runtime/SamplingProfiler.h: * runtime/VM.h: (JSC::VM::ownerThread): * runtime/VMTraps.cpp: (JSC::findActiveVMAndStackBounds): (JSC::VMTraps::SignalSender::send): (JSC::VMTraps::fireTrap): 2017-04-11 Dean Jackson Disable outdated WritableStream API https://bugs.webkit.org/show_bug.cgi?id=170749 Reviewed by Tim Horton. The API we implement is no longer accurate. Disable it until we are compatible with the new specification * Configurations/FeatureDefines.xcconfig: 2017-04-11 Yusuke Suzuki Unreviewed, build fix for CF ports after r215241 https://bugs.webkit.org/show_bug.cgi?id=170725 * heap/GCActivityCallback.cpp: (JSC::GCActivityCallback::nextFireTime): 2017-04-11 Yusuke Suzuki [WebCore][JSC] ResourceUsageData.{timeOfNextEdenCollection,timeOfNextFullCollection} should be MonotonicTime https://bugs.webkit.org/show_bug.cgi?id=170725 Reviewed by Sam Weinig. This patch makes GCActivityCallback return MonotonicTime instead of raw double value. * heap/GCActivityCallback.cpp: (JSC::GCActivityCallback::nextFireTime): * heap/GCActivityCallback.h: 2017-04-11 Guillaume Emont [jsc] Add missing MacroAssemblerMIPS::or32() implementation https://bugs.webkit.org/show_bug.cgi?id=169714 Reviewed by Michael Catanzaro. * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::or32): Added or32(TrustedImm32, Address). 2017-04-11 Joseph Pecoraro test262: test262/test/annexB/language/comments/multi-line-html-close.js https://bugs.webkit.org/show_bug.cgi?id=170648 Reviewed by Keith Miller. * parser/Lexer.cpp: (JSC::Lexer::lex): A multi-line comment that contains a line terminator is itself treated like a line terminator. An HTML Close Comment that comes after it can therefore treat it like it is at the start of a line, because it was immediately preceeded by the equivalent of a line terminator. 2017-04-11 Joseph Pecoraro test262: test262/test/built-ins/Array/S15.4.3_A2.2.js https://bugs.webkit.org/show_bug.cgi?id=170652 Reviewed by Michael Saboff. * runtime/ArrayConstructor.cpp: (JSC::ArrayConstructor::finishCreation): * runtime/BooleanConstructor.cpp: (JSC::BooleanConstructor::finishCreation): * runtime/DateConstructor.cpp: (JSC::DateConstructor::finishCreation): * runtime/FunctionConstructor.cpp: (JSC::FunctionConstructor::finishCreation): * runtime/JSArrayBufferConstructor.cpp: (JSC::JSArrayBufferConstructor::finishCreation): * runtime/NumberConstructor.cpp: (JSC::NumberConstructor::finishCreation): * runtime/ObjectConstructor.cpp: (JSC::ObjectConstructor::finishCreation): * runtime/RegExpConstructor.cpp: (JSC::RegExpConstructor::finishCreation): * runtime/StringConstructor.cpp: (JSC::StringConstructor::finishCreation): * runtime/SymbolConstructor.cpp: (JSC::SymbolConstructor::finishCreation): Ensure the "length" property on these native constructors is configurable (deletable). 2017-04-11 Yusuke Suzuki Unreviewed, build fix for Windows after r215228 part 2 https://bugs.webkit.org/show_bug.cgi?id=170723 Since GCActivityCallback class is annotated exported, we do not need to annotate each member. * heap/GCActivityCallback.h: 2017-04-11 Yusuke Suzuki [JSC][GTK] Use RunLoop::Timer in GTK port https://bugs.webkit.org/show_bug.cgi?id=170723 Reviewed by Carlos Garcia Campos. This patch makes GTK port use RunLoop::Timer for JSRunLoopTimer. Only Cocoa-based ports use platform-specific Timer because it has additional feature that changes RunLoop to the WebThread one. And we enable Heap timers in all the ports including JSCOnly port. * heap/EdenGCActivityCallback.cpp: (JSC::EdenGCActivityCallback::lastGCLength): * heap/EdenGCActivityCallback.h: * heap/FullGCActivityCallback.cpp: (JSC::FullGCActivityCallback::lastGCLength): * heap/FullGCActivityCallback.h: * heap/GCActivityCallback.cpp: (JSC::GCActivityCallback::GCActivityCallback): (JSC::GCActivityCallback::doWork): (JSC::GCActivityCallback::scheduleTimer): (JSC::GCActivityCallback::cancelTimer): (JSC::GCActivityCallback::nextFireTime): (JSC::GCActivityCallback::didAllocate): * heap/GCActivityCallback.h: * heap/IncrementalSweeper.cpp: (JSC::IncrementalSweeper::doWork): (JSC::IncrementalSweeper::doSweep): * heap/IncrementalSweeper.h: * heap/StopIfNecessaryTimer.cpp: (JSC::StopIfNecessaryTimer::scheduleSoon): * runtime/JSRunLoopTimer.cpp: (JSC::JSRunLoopTimer::setRunLoop): (JSC::JSRunLoopTimer::scheduleTimer): (JSC::JSRunLoopTimer::cancelTimer): (JSC::JSRunLoopTimer::JSRunLoopTimer): (JSC::JSRunLoopTimer::~JSRunLoopTimer): (JSC::JSRunLoopTimer::timerDidFireCallback): * runtime/JSRunLoopTimer.h: * runtime/PromiseDeferredTimer.cpp: (JSC::PromiseDeferredTimer::scheduleWorkSoon): 2017-04-11 Guillaume Emont [jsc][mips] Add missing MacroAssembler functions after r214187 https://bugs.webkit.org/show_bug.cgi?id=170089 Reviewed by Yusuke Suzuki. * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::loadFloat): Added. (JSC::MacroAssemblerMIPS::storeFloat): Added. 2017-04-11 Yusuke Suzuki [JSC] Enable JSRunLoopTimer for JSCOnly and Windows https://bugs.webkit.org/show_bug.cgi?id=170655 Reviewed by Carlos Garcia Campos. * runtime/JSRunLoopTimer.cpp: (JSC::JSRunLoopTimer::JSRunLoopTimer): (JSC::JSRunLoopTimer::scheduleTimer): (JSC::JSRunLoopTimer::cancelTimer): * runtime/JSRunLoopTimer.h: 2017-04-10 Alex Christensen Revert r215217 https://bugs.webkit.org/show_bug.cgi?id=170703 * Configurations/FeatureDefines.xcconfig: 2017-04-10 Alex Christensen Continue enabling WebRTC https://bugs.webkit.org/show_bug.cgi?id=170703 Reviewed by Youenn Fablet. * Configurations/FeatureDefines.xcconfig: 2017-04-10 Mark Lam Move ProbeContext and ProbeFunction out of AbstractMacroAssembler. https://bugs.webkit.org/show_bug.cgi?id=170681 Reviewed by Michael Saboff. This is a refactoring step towards enabling custom probe printers the way printInternal() works for dataLog. * assembler/AbstractMacroAssembler.h: (JSC::AbstractMacroAssembler::ProbeContext::gpr): Deleted. (JSC::AbstractMacroAssembler::ProbeContext::fpr): Deleted. (JSC::AbstractMacroAssembler::ProbeContext::gprName): Deleted. (JSC::AbstractMacroAssembler::ProbeContext::fprName): Deleted. * assembler/MacroAssembler.cpp: (JSC::stdFunctionCallback): (JSC::MacroAssembler::probe): * assembler/MacroAssembler.h: (JSC::ProbeContext::gpr): (JSC::ProbeContext::fpr): (JSC::ProbeContext::gprName): (JSC::ProbeContext::fprName): * assembler/MacroAssemblerARM.cpp: (JSC::MacroAssemblerARM::probe): * assembler/MacroAssemblerARM64.cpp: (JSC::arm64ProbeTrampoline): (JSC::MacroAssemblerARM64::probe): * assembler/MacroAssemblerARMv7.cpp: (JSC::MacroAssemblerARMv7::probe): * assembler/MacroAssemblerPrinter.cpp: * assembler/MacroAssemblerPrinter.h: * assembler/MacroAssemblerX86Common.cpp: (JSC::MacroAssemblerX86Common::probe): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::abstractStructure): (JSC::FTL::DFG::LowerDFGToB3::probe): Deleted. - Deleted because this became a useless place-holder after the transition to B3. 2017-04-10 Keith Miller WebAssembly: Fix B3IRGenerator for BrTable https://bugs.webkit.org/show_bug.cgi?id=170685 Reviewed by JF Bastien. For some reason this didn't get included in r215141. This fixes an issue with BrTable and loops where we would use the loop's return type as the branch target type. * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::ControlData::resultForBranch): (JSC::Wasm::B3IRGenerator::unifyValuesWithBlock): 2017-04-08 Oliver Hunt Remove use of strcpy from JSC https://bugs.webkit.org/show_bug.cgi?id=170646 Reviewed by Mark Lam. Replace the use of strcpy with memcpy as strcpy keeps on tripping various analyser warnings even though its trivially safe in this case. Essentially code hygiene, no change in behaviour, no perf impact. * dfg/DFGDisassembler.cpp: (JSC::DFG::Disassembler::dumpDisassembly): 2017-04-09 Joseph Pecoraro test262: test262/test/annexB/language/expressions/object/__proto__-fn-name.js https://bugs.webkit.org/show_bug.cgi?id=170650 Reviewed by Saam Barati. * parser/Parser.cpp: (JSC::Parser::parseClass): (JSC::Parser::parseProperty): There needs to be special handling of: PropertyDefinition : PropertyName ':' AssignmentExpression When the property name is __proto__. In this case the SetFunctionName path does not happen, so the name "__proto__" is not inferred on any anonymous function. See: https://tc39.github.io/ecma262/#sec-__proto__-property-names-in-object-initializers * parser/Parser.h: * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createProperty): * parser/ASTBuilder.h: (JSC::ASTBuilder::createProperty): Add an extra parameter to see if inferring / setting names are allowed. 2017-04-09 Joseph Pecoraro test262: test262/test/annexB/language/literals/regexp/identity-escape.js https://bugs.webkit.org/show_bug.cgi?id=170651 Reviewed by Saam Barati. * yarr/YarrParser.h: (JSC::Yarr::Parser::parseEscape): For \8 and \9 match just the number "8" or "9" instead of both "\\" and the number. See: https://tc39.github.io/ecma262/#sec-decimalescape 2017-04-08 Youenn Fablet WebRTC tests gardening https://bugs.webkit.org/show_bug.cgi?id=170508 Reviewed by Eric Carlson. * Configurations/FeatureDefines.xcconfig: 2017-04-07 Keith Miller WebAssembly: Fix issue with BrTable targeting a Loop https://bugs.webkit.org/show_bug.cgi?id=170638 Reviewed by Saam Barati. This fixes the same issue V8 had in: https://github.com/WebAssembly/spec/pull/456#event-1033547537 * wasm/WasmValidate.cpp: (JSC::Wasm::Validate::ControlData::branchTargetSignature): 2017-04-07 Keith Miller Add a PriorityQueue class https://bugs.webkit.org/show_bug.cgi?id=170579 Reviewed by Saam Barati. Update Wasm::Worklist to use WTF::PriorityQueue. * wasm/WasmWorklist.cpp: (JSC::Wasm::Worklist::enqueue): (JSC::Wasm::Worklist::completePlanSynchronously): (JSC::Wasm::Worklist::stopAllPlansForVM): (JSC::Wasm::Worklist::~Worklist): (JSC::Wasm::Worklist::iterate): Deleted. * wasm/WasmWorklist.h: (JSC::Wasm::Worklist::isHigherPriority): (JSC::Wasm::Worklist::Comparator::operator()): Deleted. 2017-04-07 Yuichiro Kikura WebGPU: implement ComputeCommandEncoder and related components https://bugs.webkit.org/show_bug.cgi?id=170444 Reviewed by Alex Christensen. I added some identifiers related with WebGPUComputeCommandEncoder based on the proposal. https://webkit.org/wp-content/uploads/webgpu-api-proposal.html * runtime/CommonIdentifiers.h: 2017-04-07 Saam Barati WebAssembly: Module::getOrCreateCodeBlock is wrong https://bugs.webkit.org/show_bug.cgi?id=170612 Reviewed by Keith Miller. When we were getting a module's CodeBlock, we were checking if !runnable(), and if !runnable(), we were re-creating the CodeBlock. This is wrong, since !runnable() is true while the CodeBlock is compiling. Instead, we should check if we've finished compiling, and if so, if that compilation failed. * wasm/WasmModule.cpp: (JSC::Wasm::Module::getOrCreateCodeBlock): 2017-04-07 Saam Barati WebAssembly: Make to a compilation API that allows for multi-VM concurrent compilations of Wasm Modules https://bugs.webkit.org/show_bug.cgi?id=170488 Reviewed by JF Bastien. This patch adds a class called Wasm::Module. It contains the bits from JSWebAssemblyModule that were not VM specific. JSWebAssemblyModule now has a Ref. Similarly, there is now a Wasm::CodeBlock, which owns the non-VM-specific bits that JSWebAssemblyCodeBlock used to own. This patch also simplifies how we verify and compile code. Wasm::Module now has an API for both sync/async validation and compilation. This API abstracts away how Wasm::Plan works. This is hopefully the last patch needed before we can implement window.postMessage for a JSWebAssemblyModule. I think all that's needed now to implement postMessage is simply creating a new JSWebAssemblyModule with the underlying Wasm::Module. This patch is neutral on WasmBench. Finally, this patch changes the promise deferred timer to allow for new tasks to be added while we're executing a task. Before, we'd deadlock if this happened. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * jsc.cpp: (functionTestWasmModuleFunctions): * runtime/PromiseDeferredTimer.cpp: (JSC::PromiseDeferredTimer::doWork): (JSC::PromiseDeferredTimer::scheduleWorkSoon): * runtime/PromiseDeferredTimer.h: * wasm/WasmB3IRGenerator.cpp: * wasm/WasmBinding.cpp: (JSC::Wasm::wasmToJs): (JSC::Wasm::wasmToWasm): (JSC::Wasm::exitStubGenerator): Deleted. * wasm/WasmBinding.h: * wasm/WasmCodeBlock.cpp: Added. (JSC::Wasm::CodeBlock::CodeBlock): (JSC::Wasm::CodeBlock::waitUntilFinished): (JSC::Wasm::CodeBlock::compileAsync): (JSC::Wasm::CodeBlock::isSafeToRun): * wasm/WasmCodeBlock.h: Added. (JSC::Wasm::CodeBlock::create): (JSC::Wasm::CodeBlock::compilationFinished): (JSC::Wasm::CodeBlock::runnable): (JSC::Wasm::CodeBlock::errorMessage): (JSC::Wasm::CodeBlock::functionImportCount): (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace): (JSC::Wasm::CodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace): * wasm/WasmModule.cpp: Added. (JSC::Wasm::Module::Module): (JSC::Wasm::makeValidationResult): (JSC::Wasm::Module::validateSyncImpl): (JSC::Wasm::Module::getOrCreateCodeBlock): (JSC::Wasm::Module::compileSync): (JSC::Wasm::Module::makeValidationCallback): (JSC::Wasm::Module::compileAsync): * wasm/WasmModule.h: Added. (JSC::Wasm::Module::create): (JSC::Wasm::Module::validateSync): (JSC::Wasm::Module::validateAsync): (JSC::Wasm::Module::signatureIndexFromFunctionIndexSpace): (JSC::Wasm::Module::moduleInformation): (JSC::Wasm::Module::nonNullCodeBlock): * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::Plan): (JSC::Wasm::Plan::addCompletionTask): (JSC::Wasm::Plan::prepare): (JSC::Wasm::Plan::compileFunctions): (JSC::Wasm::Plan::complete): (JSC::Wasm::Plan::tryRemoveVMAndCancelIfLast): (JSC::Wasm::Plan::cancel): Deleted. * wasm/WasmPlan.h: (JSC::Wasm::Plan::dontFinalize): (JSC::Wasm::Plan::takeWasmToWasmExitStubs): (JSC::Wasm::Plan::mode): (JSC::Wasm::Plan::takeWasmExitStubs): Deleted. (JSC::Wasm::Plan::vm): Deleted. * wasm/WasmWorklist.cpp: (JSC::Wasm::Worklist::stopAllPlansForVM): * wasm/js/JSWebAssemblyCodeBlock.cpp: (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock): (JSC::JSWebAssemblyCodeBlock::isSafeToRun): (JSC::JSWebAssemblyCodeBlock::initialize): Deleted. * wasm/js/JSWebAssemblyCodeBlock.h: (JSC::JSWebAssemblyCodeBlock::create): (JSC::JSWebAssemblyCodeBlock::functionImportCount): (JSC::JSWebAssemblyCodeBlock::jsEntrypointCalleeFromFunctionIndexSpace): (JSC::JSWebAssemblyCodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace): (JSC::JSWebAssemblyCodeBlock::wasmToJsCallStubForImport): (JSC::JSWebAssemblyCodeBlock::mode): Deleted. (JSC::JSWebAssemblyCodeBlock::initialized): Deleted. (JSC::JSWebAssemblyCodeBlock::plan): Deleted. (JSC::JSWebAssemblyCodeBlock::runnable): Deleted. (JSC::JSWebAssemblyCodeBlock::errorMessage): Deleted. (JSC::JSWebAssemblyCodeBlock::setJSEntrypointCallee): Deleted. (JSC::JSWebAssemblyCodeBlock::setWasmEntrypointCallee): Deleted. * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::finalizeCreation): (JSC::JSWebAssemblyInstance::addUnitializedCodeBlock): Deleted. * wasm/js/JSWebAssemblyInstance.h: (JSC::JSWebAssemblyInstance::initialized): Deleted. * wasm/js/JSWebAssemblyModule.cpp: (JSC::JSWebAssemblyModule::createStub): (JSC::JSWebAssemblyModule::JSWebAssemblyModule): (JSC::JSWebAssemblyModule::finishCreation): * wasm/js/JSWebAssemblyModule.h: (JSC::JSWebAssemblyModule::moduleInformation): (JSC::JSWebAssemblyModule::signatureIndexFromFunctionIndexSpace): (JSC::JSWebAssemblyModule::module): * wasm/js/WebAssemblyFunction.cpp: (JSC::WebAssemblyFunction::create): * wasm/js/WebAssemblyInstanceConstructor.cpp: (JSC::constructJSWebAssemblyInstance): * wasm/js/WebAssemblyModuleConstructor.cpp: (JSC::WebAssemblyModuleConstructor::createModule): * wasm/js/WebAssemblyPrototype.cpp: (JSC::reject): (JSC::webAssemblyCompileFunc): (JSC::resolve): (JSC::instantiate): (JSC::compileAndInstantiate): (JSC::webAssemblyValidateFunc): 2017-04-07 Carlos Garcia Campos [GTK] Update the priorities used in glib main loop sources https://bugs.webkit.org/show_bug.cgi?id=170457 Reviewed by Žan Doberšek. * runtime/JSRunLoopTimer.cpp: (JSC::JSRunLoopTimer::JSRunLoopTimer): 2017-04-06 Filip Pizlo Rename allocateStack to allocateStackByGraphColoring. Rubber stamped by Saam Barati. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * b3/air/AirAllocateStack.cpp: Removed. * b3/air/AirAllocateStack.h: Removed. * b3/air/AirAllocateStackByGraphColoring.cpp: Copied from Source/JavaScriptCore/b3/air/AirAllocateStack.cpp. (JSC::B3::Air::allocateStackByGraphColoring): (JSC::B3::Air::allocateStack): Deleted. * b3/air/AirAllocateStackByGraphColoring.h: Copied from Source/JavaScriptCore/b3/air/AirAllocateStack.h. * b3/air/AirGenerate.cpp: (JSC::B3::Air::prepareForGeneration): 2017-04-06 Michael Saboff Cannot Object.seal() or Object.freeze() global "this" https://bugs.webkit.org/show_bug.cgi?id=170549 Reviewed by Mark Lam. Needed to implement JSProxy::isExtensible() which returns the results of calling the same on wrapped object. Implemented step 11 of Runtime Semantics: EvalDeclarationInstantiation from the ECMAScript spec to properly return a TypeError object when attempting to add properties to a non-extensible global object. * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): * runtime/JSProxy.cpp: (JSC::JSProxy::isExtensible): * runtime/JSProxy.h: 2017-04-06 Filip Pizlo Linear scan should run liveness only once https://bugs.webkit.org/show_bug.cgi?id=170569 Reviewed by Keith Miller. Air has a longstanding design bug that Tmps from different banks are indexed independently. This means that all of our analyses over Tmps do separate GP and FP passes. This does have some marginal benefits (the rest of the algorithm is specialized for Bank) but it's probably net bad. However, I don't want to think about solving that general problem. Instead, this just makes linear scan use a UnifiedTmpLiveness that uses a single "linear" indexing for GP and FP. This lets me avoid the much larger refactoring (which would involve substantial changes in graph coloring) while getting the bulk of the benefit (liveness runs once, instead of twice, for linear scan). This patch implements a lot of plumbing to make it possible for Liveness<> to view Tmps as having a unified indexing scheme. Tmp calls this LinearlyIndexed (to match the naming convention of AbsolutelyIndexed and Indexed), while AirLiveness calls this UnifiedTmpLiveness. With this change, -O1 never does any liveness analysis that uses separate GP and FP passes. I think this eliminates any urgency from the larger Tmp indexing bug. We can probably live with graph coloring doing separate passes. This is a ~6% speed-up for wasm -O1 compile times. I think this means that linear scan is no longer the longest pole in the tent. * JavaScriptCore.xcodeproj/project.pbxproj: * b3/B3VariableLiveness.h: (JSC::B3::VariableLivenessAdapter::prepareToCompute): * b3/air/AirAllocateRegistersByLinearScan.cpp: (JSC::B3::Air::allocateRegistersByLinearScan): * b3/air/AirCode.h: (JSC::B3::Air::Code::forEachTmp): * b3/air/AirLiveness.h: * b3/air/AirLivenessAdapter.h: (JSC::B3::Air::LivenessAdapter::Actions::Actions): (JSC::B3::Air::LivenessAdapter::LivenessAdapter): (JSC::B3::Air::LivenessAdapter::adapter): (JSC::B3::Air::LivenessAdapter::prepareToCompute): (JSC::B3::Air::LivenessAdapter::actionsAt): (JSC::B3::Air::LivenessAdapter::forEachUse): (JSC::B3::Air::LivenessAdapter::forEachDef): (JSC::B3::Air::TmpLivenessAdapter::numIndices): (JSC::B3::Air::UnifiedTmpLivenessAdapter::UnifiedTmpLivenessAdapter): (JSC::B3::Air::UnifiedTmpLivenessAdapter::numIndices): (JSC::B3::Air::UnifiedTmpLivenessAdapter::acceptsBank): (JSC::B3::Air::UnifiedTmpLivenessAdapter::acceptsRole): (JSC::B3::Air::UnifiedTmpLivenessAdapter::valueToIndex): (JSC::B3::Air::UnifiedTmpLivenessAdapter::indexToValue): * b3/air/AirLivenessConstraints.h: Removed. * b3/air/AirRegLiveness.h: (JSC::B3::Air::RegLiveness::LocalCalc::LocalCalc): * b3/air/AirTmp.cpp: * b3/air/AirTmp.h: * b3/air/AirTmpInlines.h: (JSC::B3::Air::Tmp::LinearlyIndexed::LinearlyIndexed): (JSC::B3::Air::Tmp::LinearlyIndexed::index): (JSC::B3::Air::Tmp::linearlyIndexed): (JSC::B3::Air::Tmp::indexEnd): (JSC::B3::Air::Tmp::absoluteIndexEnd): (JSC::B3::Air::Tmp::linearIndexEnd): (JSC::B3::Air::Tmp::tmpForAbsoluteIndex): (JSC::B3::Air::Tmp::tmpForLinearIndex): * b3/air/AirTmpMap.h: Added. (JSC::B3::Air::TmpMap::TmpMap): (JSC::B3::Air::TmpMap::resize): (JSC::B3::Air::TmpMap::clear): (JSC::B3::Air::TmpMap::operator[]): (JSC::B3::Air::TmpMap::append): 2017-04-06 Ryan Haddad Unreviewed, rolling out r215046. This change broke internal builds. Reverted changeset: "WebRTC tests gardening" https://bugs.webkit.org/show_bug.cgi?id=170508 http://trac.webkit.org/changeset/215046 2017-04-06 Joseph Pecoraro Web Inspector: Show all headers in the Request Headers section of the Resource details sidebar https://bugs.webkit.org/show_bug.cgi?id=16531 Reviewed by Timothy Hatcher. * inspector/protocol/Network.json: Optional refined list of request headers in Metrics. 2017-04-06 Filip Pizlo B3 -O1 should generate better code than -O0 https://bugs.webkit.org/show_bug.cgi?id=170563 Reviewed by Michael Saboff. Prior to this change, code generated by -O1 ran slower than code generated by -O0. This turned out to be because of reduceStrength optimizations that increase live ranges and create register pressure, which then creates problems for linear scan. It seemed obvious that canonicalizations that help isel, constant folding, and one-for-one strength reductions should stay. It also seemed obvious that SSA and CFG simplification are fast and harmless. So, I focused on removing: - CSE, which increases live ranges. This is a risky optimization when we know that we've chosen to use a bad register allocator. - Sophisticated strength reductions that create more code, like the insane division optimization. - Anything that inserts basic blocks. CSE appeared to be the cause of half of the throughput regression of -O1 but none of the compile time. This change also reduces the running time of reduceStrength by making it not a fixpoint at optLevel<2. This makes wasm -O1 compile 17% faster. This makes wasm -O1 run 19% faster. This makes -O1 code run 3% faster than -O0, and compile about 4% slower than -O0. We may yet end up choosing to use -O0, but at least now -O1 isn't totally useless. * b3/B3ReduceStrength.cpp: 2017-04-06 Jon Davis Updates feature status for recently shipped features https://bugs.webkit.org/show_bug.cgi?id=170359 Reviewed by Brian Burg. Changed "Done" status to "Supported". * features.json: 2017-04-06 Youenn Fablet WebRTC tests gardening https://bugs.webkit.org/show_bug.cgi?id=170508 Reviewed by Eric Carlson. * Configurations/FeatureDefines.xcconfig: 2017-04-06 Guillaume Emont [JSC][MIPS][DFG] Use x86 generic HasOwnProperty https://bugs.webkit.org/show_bug.cgi?id=170222 Reviewed by Yusuke Suzuki. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): use the X86 special version for HasOwnProperty on MIPS too. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): use the X86 special version for HasOwnProperty on MIPS too. 2017-04-05 Saam Barati REGRESSION fix bad isWasm() test by ensuring proper Wasm callee bit pattern https://bugs.webkit.org/show_bug.cgi?id=170494 Reviewed by Yusuke Suzuki and Mark Lam. This patch fixes how we test a 64 bit JSValue pattern to see if it's a Wasm callee. We now tag Wasm::Callee's with 0b011 in their lower 3 bits. The new test is for a Wasm Callee is as follows: isWasm(uint64_t x) { return x & 0xffff000000000007 == 3; } This test works because the lower 3 bits of the non-number immediate values are as follows: undefined: 0b010 null: 0b010 true: 0b111 false: 0b110 The test rejects all of these because none have just the value 3 in their lower 3 bits. The test also rejects all numbers, because they have non-zero upper 16 bits. The test also rejects normal cells because they won't have the number 3 as their lower 3 bits. Note, this bit pattern also allows the normal JSValue isCell(), etc, predicates to work on a Wasm::Callee because the various tests will fail if you bit casted a boxed Wasm::Callee* to a JSValue. isCell() would fail since it sees TagBitTypeOther. The other tests also trivially fail, since it won't be a number, and it won't be equal to null, undefined, true, or false. The isBoolean() predicate will fail because we won't have TagBitBool set. * interpreter/CallFrame.h: (JSC::ExecState::guaranteedJSValueCallee): (JSC::ExecState::calleeAsValue): Deleted. * interpreter/CalleeBits.h: (JSC::CalleeBits::boxWasm): (JSC::CalleeBits::isWasm): (JSC::CalleeBits::asWasmCallee): * jit/JITOperations.cpp: * runtime/JSCJSValue.h: 2017-04-05 Keith Miller WebAssembly: Plans should be able to have more than one completion task. https://bugs.webkit.org/show_bug.cgi?id=170516 Reviewed by Saam Barati. This patch also eliminates the need for blocked tasks on the PromiseDeferredTimer and pendingPromise on Wasm::Plan. * runtime/PromiseDeferredTimer.cpp: (JSC::PromiseDeferredTimer::doWork): (JSC::PromiseDeferredTimer::cancelPendingPromise): (JSC::PromiseDeferredTimer::scheduleBlockedTask): Deleted. * runtime/PromiseDeferredTimer.h: * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::Plan): (JSC::Wasm::Plan::addCompletionTask): (JSC::Wasm::Plan::complete): * wasm/WasmPlan.h: (JSC::Wasm::Plan::setMode): (JSC::Wasm::Plan::mode): (JSC::Wasm::Plan::setModeAndPromise): Deleted. (JSC::Wasm::Plan::pendingPromise): Deleted. * wasm/WasmWorklist.cpp: (JSC::Wasm::Worklist::enqueue): * wasm/js/WebAssemblyInstanceConstructor.cpp: (JSC::constructJSWebAssemblyInstance): * wasm/js/WebAssemblyPrototype.cpp: (JSC::instantiate): 2017-04-05 Guilherme Iscaro Do not use BLX for immediates (ARM-32) https://bugs.webkit.org/show_bug.cgi?id=170351 Reviewed by Mark Lam. Currently the offline asm generator for 32-bit ARM code translates the 'call' meta-instruction (which may be found in LowLevelInterpreter.asm and friends) to the ARM's BLX instrunction. The BLX instruction may be used for labels (immediates) and registers and one side effect of BLX is that it may switch the processor's instruction set. A 'BLX register' instruction will change/remain the processor state to ARM if the register_bit[0] is set to 0 or change/remain to Thumb if register_bit[0] is set to 1. However, a 'BLX label' instruction will always switch the processor state. It switches ARM to thumb and vice-versa. This behaviour is unwanted, since the C++ code and the offlineasm generated code are both compiled using the same instruction set, thus a instruction set change will likely produce a crash. In order to fix the problem the BL instruction can be used for labels. It will branch just like BLX, but it won't change the instruction set. It's important to note that Darwin is not affected by this problem, thus to minimize the impact of this change the BL instruction will only be used on non-darwin targets. BLX reference: http://infocenter.arm.com/help/topic/com.arm.doc.dui0489i/CIHBJCDC.html?resultof=%22%62%6c%78%22%20 * offlineasm/arm.rb: 2017-04-05 Keith Miller WebAssembly: We shouldn't need to pin size registers if we have a fast memory. https://bugs.webkit.org/show_bug.cgi?id=170504 Reviewed by Mark Lam. * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::createJSToWasmWrapper): (JSC::Wasm::parseAndCompile): * wasm/WasmMemoryInformation.h: (JSC::Wasm::PinnedRegisterInfo::toSave): 2017-04-05 Yusuke Suzuki [JSC] Suppress warnings in GCC https://bugs.webkit.org/show_bug.cgi?id=170501 Reviewed by Keith Miller. Should use ASSERT_NOT_REACHED since return-type pragma is only enabled under ASSERT_DISABLED environment. We shoud use ASSERT_NOTREACHED to emit assertions in debug build. It effectively catches bugs while keeping performance in release build. * b3/B3Opcode.cpp: (JSC::B3::storeOpcode): * b3/B3Width.h: (JSC::B3::mask): * runtime/Options.cpp: (JSC::parse): * wasm/WasmSections.h: (JSC::Wasm::makeString): * wasm/WasmSignature.cpp: (JSC::Wasm::SignatureInformation::tryCleanup): * wasm/generateWasmValidateInlinesHeader.py: 2017-04-05 Carlos Garcia Campos Implement PromiseDeferredTimer for non CF based ports https://bugs.webkit.org/show_bug.cgi?id=170391 Reviewed by Yusuke Suzuki. RunLoop handling is only implemented for CF causing several wasm tests to fail for other ports. * jsc.cpp: (runJSC): Remove CF ifdefs. * runtime/PromiseDeferredTimer.cpp: (JSC::PromiseDeferredTimer::doWork): Add non CF implementation using WTF RunLoop. (JSC::PromiseDeferredTimer::runRunLoop): Ditto. * runtime/PromiseDeferredTimer.h: 2017-04-05 Carlos Garcia Campos WebAssembly: several tests added in r214504 crash when building with GCC https://bugs.webkit.org/show_bug.cgi?id=170390 Reviewed by Saam Barati. The pattern foo->bar([f = WTFMove(foo)]{}); crashes when building with GCC, I assume the move happens before the foo is used to invoke the function. * wasm/js/WebAssemblyPrototype.cpp: (JSC::webAssemblyCompileFunc): Use p.vm() instead of plan->vm(), because plan is moved by the lambda. (JSC::instantiate): Ditto. (JSC::compileAndInstantiate): Ditto. 2017-03-16 Yusuke Suzuki [JSC] Generate TemplateObjects at linking time https://bugs.webkit.org/show_bug.cgi?id=169743 Reviewed by Keith Miller. Currently, the code calls getTemplateObject to get appropriate template objects at runtime. But this template object is constant value and never changed. So instead of creating it at runtime, we should create it at linking time and store it in the constant registers. * builtins/BuiltinNames.h: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): (JSC::CodeBlock::setConstantRegisters): * bytecode/CodeBlock.h: * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::shrinkToFit): * bytecode/UnlinkedCodeBlock.h: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::addTemplateRegistryKeyConstant): (JSC::BytecodeGenerator::emitGetTemplateObject): * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::TaggedTemplateNode::emitBytecode): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::getTemplateObject): Deleted. * runtime/JSTemplateRegistryKey.cpp: * runtime/JSTemplateRegistryKey.h: (JSC::isTemplateRegistryKey): 2017-04-04 Mark Lam On ARM64, DFG::SpeculativeJIT::compileArithMod() failed to ensure result is of DataFormatInt32. https://bugs.webkit.org/show_bug.cgi?id=170473 Reviewed by Saam Barati. In Unchecked mode, when DFG::SpeculativeJIT::compileArithMod() detects that the divisor is 0, we want it to return 0. The result is expected to be of DataFormatIn32. The ARM implementation just returns the value in the divisor register. However, the divisor in this case can be of DataFormatJSInt32. On ARM64, returning the divisor register yields the wrong result format because the same register also holds the upper 32-bit of the JSValue encoding. The fix is to return an immediate 0 instead. Also turned on the assertion in jitAssertIsInt32 for ARM64. This assertion being disabled may have contributed to this bug going unnoticed all this time. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArithMod): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::jitAssertIsInt32): 2017-04-04 Filip Pizlo Air::eliminateDeadCode should not repeatedly process the same live instructions https://bugs.webkit.org/show_bug.cgi?id=170490 Reviewed by Keith Miller. This makes the eliminateDeadCode() fixpoint somewhat worklist-based: we track the set of Insts that might be dead. Every time we detect that one is live, we remove it from the set. This is a big (>2x) speed-up because lots of Insts are immediately found to be live. This is a ~1% wasm -O1 compile time progression. * b3/air/AirEliminateDeadCode.cpp: (JSC::B3::Air::eliminateDeadCode): 2017-04-04 Filip Pizlo Air::eliminateDeadCode() should not use a HashSet https://bugs.webkit.org/show_bug.cgi?id=170487 Reviewed by Saam Barati. Introduce TmpSet, which is like a HashSet. Use this to make eliminateDeadCode() about 50% faster, resulting in a 1% wasm -O1 compile time progression. * JavaScriptCore.xcodeproj/project.pbxproj: * b3/air/AirEliminateDeadCode.cpp: (JSC::B3::Air::eliminateDeadCode): * b3/air/AirTmpSet.h: Added. (JSC::B3::Air::TmpSet::TmpSet): (JSC::B3::Air::TmpSet::add): (JSC::B3::Air::TmpSet::remove): (JSC::B3::Air::TmpSet::contains): (JSC::B3::Air::TmpSet::size): (JSC::B3::Air::TmpSet::isEmpty): (JSC::B3::Air::TmpSet::iterator::iterator): (JSC::B3::Air::TmpSet::iterator::operator*): (JSC::B3::Air::TmpSet::iterator::operator++): (JSC::B3::Air::TmpSet::iterator::operator==): (JSC::B3::Air::TmpSet::iterator::operator!=): (JSC::B3::Air::TmpSet::begin): (JSC::B3::Air::TmpSet::end): 2017-04-04 Keith Miller WebAssembly: ModuleInformation should be a ref counted thing that can be shared across threads. https://bugs.webkit.org/show_bug.cgi?id=170478 Reviewed by Saam Barati. ModuleInformation has been moved to its own file and is now ThreadSafeRefCounted. All the Strings we used to keep in the ModuleInformation have been switched to Vector this has the advantage that it can be passed across threads. However, this does mean that we need to decode the utf8 strings in each thread. This is likely not a problem because: 1) most modules have few imports/exports/custom sections. 2) most of the time they are ascii so the conversion is cheap. 3) we only have to do it once per thread, and there shouldn't be too many. This patch also removes moduleSignatureIndicesToUniquedSignatureIndices since that information can already be recovered from the SignatureInformation. * JavaScriptCore.xcodeproj/project.pbxproj: * jsc.cpp: (functionTestWasmModuleFunctions): * runtime/Identifier.h: (JSC::Identifier::fromString): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::parseAndCompile): * wasm/WasmB3IRGenerator.h: * wasm/WasmFormat.cpp: (JSC::Wasm::makeString): (JSC::Wasm::ModuleInformation::~ModuleInformation): Deleted. * wasm/WasmFormat.h: (JSC::Wasm::makeString): (JSC::Wasm::ModuleInformation::functionIndexSpaceSize): Deleted. (JSC::Wasm::ModuleInformation::isImportedFunctionFromFunctionIndexSpace): Deleted. (JSC::Wasm::ModuleInformation::signatureIndexFromFunctionIndexSpace): Deleted. (JSC::Wasm::ModuleInformation::importFunctionCount): Deleted. (JSC::Wasm::ModuleInformation::internalFunctionCount): Deleted. * wasm/WasmFunctionParser.h: (JSC::Wasm::FunctionParser::FunctionParser): * wasm/WasmModuleInformation.cpp: Copied from Source/JavaScriptCore/wasm/WasmValidate.h. (JSC::Wasm::ModuleInformation::~ModuleInformation): * wasm/WasmModuleInformation.h: Added. (JSC::Wasm::ModuleInformation::functionIndexSpaceSize): (JSC::Wasm::ModuleInformation::isImportedFunctionFromFunctionIndexSpace): (JSC::Wasm::ModuleInformation::signatureIndexFromFunctionIndexSpace): (JSC::Wasm::ModuleInformation::importFunctionCount): (JSC::Wasm::ModuleInformation::internalFunctionCount): (JSC::Wasm::ModuleInformation::ModuleInformation): * wasm/WasmModuleParser.cpp: * wasm/WasmModuleParser.h: (JSC::Wasm::ModuleParser::ModuleParser): * wasm/WasmParser.h: (JSC::Wasm::Parser::consumeUTF8String): * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::Plan): (JSC::Wasm::Plan::parseAndValidateModule): (JSC::Wasm::Plan::prepare): (JSC::Wasm::Plan::compileFunctions): (JSC::Wasm::Plan::complete): (JSC::Wasm::Plan::cancel): * wasm/WasmPlan.h: (JSC::Wasm::Plan::internalFunctionCount): (JSC::Wasm::Plan::takeModuleInformation): * wasm/WasmSignature.cpp: (JSC::Wasm::SignatureInformation::get): * wasm/WasmSignature.h: * wasm/WasmValidate.cpp: (JSC::Wasm::validateFunction): * wasm/WasmValidate.h: * wasm/js/JSWebAssemblyHelpers.h: (JSC::createSourceBufferFromValue): * wasm/js/JSWebAssemblyModule.cpp: (JSC::JSWebAssemblyModule::createStub): (JSC::JSWebAssemblyModule::JSWebAssemblyModule): (JSC::JSWebAssemblyModule::finishCreation): * wasm/js/JSWebAssemblyModule.h: (JSC::JSWebAssemblyModule::moduleInformation): (JSC::JSWebAssemblyModule::source): * wasm/js/WebAssemblyInstanceConstructor.cpp: (JSC::constructJSWebAssemblyInstance): * wasm/js/WebAssemblyModuleConstructor.cpp: (JSC::WebAssemblyModuleConstructor::createModule): * wasm/js/WebAssemblyModulePrototype.cpp: (JSC::webAssemblyModuleProtoCustomSections): (JSC::webAssemblyModuleProtoImports): (JSC::webAssemblyModuleProtoExports): * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::link): * wasm/js/WebAssemblyModuleRecord.h: * wasm/js/WebAssemblyPrototype.cpp: (JSC::webAssemblyCompileFunc): (JSC::instantiate): (JSC::compileAndInstantiate): 2017-04-04 Filip Pizlo B3::fixSSA() needs a tune-up https://bugs.webkit.org/show_bug.cgi?id=170485 Reviewed by Saam Barati. After the various optimizations to liveness, register allocation, and other phases, the fixSSA() phase now looks like one of the top offenders. This includes a bunch of changes to make this phase run faster. This is a ~7% wasm -O1 compile time progression. Here's what I did: - We now use IndexSparseSet instead of IndexMap for tracking variable values. This makes it cheaper to chew through small blocks while there is a non-trivial number of total variables. - We now do a "local SSA conversion" pass before anything else. This eliminates obvious Get's. If we were using temporary Variables, it would eliminate many of those. That's useful for when we use demoteValues() and duplciateTails(). For wasm -O1, we mainly care about the fact that it makes a bunch of Set's dead. - We now do a Set DCE pass after the local SSA but before SSA conversion. This ensures that any block-local live intervals of Variables disappear and don't need further consideration. - We now cache the reaching defs calculation. - We now perform the reaching defs calculation lazily. * b3/B3FixSSA.cpp: (JSC::B3::demoteValues): (JSC::B3::fixSSA): * b3/B3SSACalculator.cpp: (JSC::B3::SSACalculator::reachingDefAtTail): * b3/B3VariableLiveness.cpp: (JSC::B3::VariableLiveness::VariableLiveness): * b3/air/AirLiveness.h: (JSC::B3::Air::Liveness::Liveness): * dfg/DFGLivenessAnalysisPhase.cpp: (JSC::DFG::LivenessAnalysisPhase::LivenessAnalysisPhase): Deleted. (JSC::DFG::LivenessAnalysisPhase::run): Deleted. (JSC::DFG::LivenessAnalysisPhase::processBlock): Deleted. 2017-04-04 Joseph Pecoraro Remove stale LLVM Header Path includes from JavaScriptCore https://bugs.webkit.org/show_bug.cgi?id=170483 Reviewed by Mark Lam. * Configurations/Base.xcconfig: 2017-04-04 Filip Pizlo B3::LowerToAir incorrectly selects BitXor(AtomicStrongCAS(...), $1) https://bugs.webkit.org/show_bug.cgi?id=169867 Reviewed by Saam Barati. The BitXor(AtomicWeakCAS(...), $1) optimization makes a lot of sense because we an fold the BitXor into the CAS condition read-out. But there is no version of this that is profitable or correct for AtomicStrongCAS. The inversion case is handled by Equal(AtomicStrongCAS(...), ...) becoming NotEqual(AtomicStrongCAS(...), ...), and we alraedy handle that separately. So, the fix here is to make the BitXor CAS pattern only recognize AtomicWeakCAS. * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::lower): * b3/testb3.cpp: (JSC::B3::testAtomicStrongCAS): 2017-04-04 Saam Barati WebAssembly: JSWebAssemblyCallee should not be a JSCell https://bugs.webkit.org/show_bug.cgi?id=170135 Reviewed by Michael Saboff. This patch is perhaps the last big change to the design of fundamental Wasm API to allow for PIC. It changes JSWebAssemblyCallee into a thing called Wasm::Callee. It serves the same purpose as before, except Wasm::Callee is not a JSCell. I had to refactor the various parts of the runtime that will see CallFrame's with Wasm::Callee's in the callee slot. Thankfully, the parts of the runtime that Wasm touches are limited. The main refactoring is changing the exception handling code, such as taking a stack trace, to be friendly to seeing a non JSCell callee. The callee() function on ExecState now returns a class I added in this patch called CalleeBits. CalleeBits will tell you if the callee is a JSCell or a Wasm::Callee. We tag Wasm::Callee's with a 1 in their lower bit so we can easily tell what is and isn't a Wasm::Callee. The stub that calls out from Wasm to JS still puts a JSCell callee into the call frame, even though the callee logically represents a Wasm frame. The reason for this is that we use the call IC infrastructure to make a call out to JS code, and the code that writes the IC expects a JSCell as the callee. This is knowingly part of our design. When we do structured cloning of Wasm Modules, we'll need to regenerate these JS call stubs. * API/JSContextRef.cpp: (BacktraceFunctor::operator()): * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * debugger/Debugger.cpp: (JSC::Debugger::pauseIfNeeded): (JSC::Debugger::currentDebuggerCallFrame): * debugger/DebuggerCallFrame.cpp: (JSC::DebuggerCallFrame::create): (JSC::DebuggerCallFrame::DebuggerCallFrame): (JSC::DebuggerCallFrame::currentPosition): (JSC::DebuggerCallFrame::positionForCallFrame): * debugger/DebuggerCallFrame.h: * interpreter/CallFrame.cpp: (JSC::CallFrame::vmEntryGlobalObject): (JSC::CallFrame::wasmAwareLexicalGlobalObject): (JSC::CallFrame::isAnyWasmCallee): (JSC::CallFrame::callerSourceOrigin): * interpreter/CallFrame.h: (JSC::ExecState::calleeAsValue): (JSC::ExecState::jsCallee): (JSC::ExecState::callee): (JSC::ExecState::unsafeCallee): (JSC::ExecState::scope): (JSC::ExecState::iterate): * interpreter/CalleeBits.h: Added. (JSC::CalleeBits::CalleeBits): (JSC::CalleeBits::operator=): (JSC::CalleeBits::boxWasm): (JSC::CalleeBits::isWasm): (JSC::CalleeBits::isCell): (JSC::CalleeBits::asCell): (JSC::CalleeBits::asWasmCallee): (JSC::CalleeBits::rawPtr): * interpreter/Interpreter.cpp: (JSC::GetStackTraceFunctor::operator()): (JSC::Interpreter::getStackTrace): (JSC::notifyDebuggerOfUnwinding): (JSC::UnwindFunctor::UnwindFunctor): (JSC::UnwindFunctor::operator()): (JSC::UnwindFunctor::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer): (JSC::Interpreter::unwind): (JSC::Interpreter::notifyDebuggerOfExceptionToBeThrown): * interpreter/Interpreter.h: * interpreter/Register.h: (JSC::Register::pointer): * interpreter/ShadowChicken.cpp: (JSC::ShadowChicken::update): * interpreter/ShadowChickenInlines.h: (JSC::ShadowChicken::iterate): * interpreter/StackVisitor.cpp: (JSC::StackVisitor::StackVisitor): (JSC::StackVisitor::readFrame): (JSC::StackVisitor::readNonInlinedFrame): (JSC::StackVisitor::readInlinedFrame): (JSC::StackVisitor::Frame::calleeSaveRegisters): (JSC::StackVisitor::Frame::functionName): (JSC::StackVisitor::Frame::dump): * interpreter/StackVisitor.h: (JSC::StackVisitor::Frame::callee): (JSC::StackVisitor::visit): * jit/Repatch.cpp: (JSC::linkFor): (JSC::linkPolymorphicCall): * jsc.cpp: (callWasmFunction): (functionTestWasmModuleFunctions): * runtime/ArrayPrototype.cpp: * runtime/Error.cpp: (JSC::addErrorInfoAndGetBytecodeOffset): * runtime/ErrorInstance.cpp: (JSC::ErrorInstance::finishCreation): * runtime/JSCell.cpp: (JSC::JSCell::isAnyWasmCallee): Deleted. * runtime/JSCell.h: * runtime/JSCellInlines.h: (JSC::ExecState::vm): * runtime/JSFunction.cpp: (JSC::RetrieveArgumentsFunctor::operator()): (JSC::RetrieveCallerFunctionFunctor::operator()): * runtime/JSGlobalObject.cpp: * runtime/SamplingProfiler.cpp: (JSC::FrameWalker::recordJSFrame): (JSC::SamplingProfiler::processUnverifiedStackTraces): * runtime/SamplingProfiler.h: (JSC::SamplingProfiler::UnprocessedStackFrame::UnprocessedStackFrame): * runtime/StackFrame.cpp: (JSC::StackFrame::sourceURL): (JSC::StackFrame::functionName): * runtime/StackFrame.h: (JSC::StackFrame::wasm): * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::throwException): * runtime/VM.h: * wasm/JSWebAssembly.h: * wasm/WasmB3IRGenerator.cpp: * wasm/WasmBinding.cpp: (JSC::Wasm::wasmToWasm): * wasm/WasmCallee.cpp: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyCallee.cpp. (JSC::Wasm::Callee::Callee): (JSC::JSWebAssemblyCallee::JSWebAssemblyCallee): Deleted. (JSC::JSWebAssemblyCallee::finishCreation): Deleted. (JSC::JSWebAssemblyCallee::destroy): Deleted. * wasm/WasmCallee.h: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyCallee.h. (JSC::Wasm::Callee::create): (JSC::JSWebAssemblyCallee::create): Deleted. (JSC::JSWebAssemblyCallee::createStructure): Deleted. (JSC::JSWebAssemblyCallee::entrypoint): Deleted. (JSC::JSWebAssemblyCallee::calleeSaveRegisters): Deleted. * wasm/WasmContext.h: * wasm/WasmPlan.cpp: * wasm/WasmPlan.h: * wasm/WasmPlanInlines.h: (JSC::Wasm::Plan::initializeCallees): * wasm/WasmThunks.cpp: (JSC::Wasm::throwExceptionFromWasmThunkGenerator): * wasm/js/JSWebAssemblyCallee.cpp: Removed. * wasm/js/JSWebAssemblyCallee.h: Removed. * wasm/js/JSWebAssemblyCodeBlock.cpp: (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock): (JSC::JSWebAssemblyCodeBlock::initialize): (JSC::JSWebAssemblyCodeBlock::visitChildren): * wasm/js/JSWebAssemblyCodeBlock.h: (JSC::JSWebAssemblyCodeBlock::create): (JSC::JSWebAssemblyCodeBlock::jsEntrypointCalleeFromFunctionIndexSpace): (JSC::JSWebAssemblyCodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace): (JSC::JSWebAssemblyCodeBlock::wasmToJsCallStubForImport): (JSC::JSWebAssemblyCodeBlock::offsetOfImportWasmToJSStub): (JSC::JSWebAssemblyCodeBlock::setJSEntrypointCallee): (JSC::JSWebAssemblyCodeBlock::setWasmEntrypointCallee): (JSC::JSWebAssemblyCodeBlock::offsetOfImportStubs): (JSC::JSWebAssemblyCodeBlock::allocationSize): (JSC::JSWebAssemblyCodeBlock::importWasmToJSStub): (JSC::JSWebAssemblyCodeBlock::callees): Deleted. (JSC::JSWebAssemblyCodeBlock::offsetOfCallees): Deleted. * wasm/js/JSWebAssemblyInstance.h: (JSC::JSWebAssemblyInstance::webAssemblyToJSCallee): * wasm/js/JSWebAssemblyModule.cpp: * wasm/js/WebAssemblyFunction.cpp: (JSC::callWebAssemblyFunction): (JSC::WebAssemblyFunction::create): (JSC::WebAssemblyFunction::WebAssemblyFunction): (JSC::WebAssemblyFunction::visitChildren): (JSC::WebAssemblyFunction::finishCreation): * wasm/js/WebAssemblyFunction.h: (JSC::WebAssemblyFunction::wasmEntrypoint): (JSC::WebAssemblyFunction::jsEntrypoint): (JSC::WebAssemblyFunction::offsetOfWasmEntrypoint): (JSC::WebAssemblyFunction::offsetOfWasmEntryPointCode): Deleted. * wasm/js/WebAssemblyModuleConstructor.cpp: * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::link): (JSC::WebAssemblyModuleRecord::evaluate): 2017-04-04 Keith Miller WasmBench asserts in debug jsc https://bugs.webkit.org/show_bug.cgi?id=170462 Reviewed by Saam Barati. The assertion should have been an if. * wasm/WasmWorklist.cpp: 2017-04-04 Filip Pizlo Air::lowerAfterRegAlloc should bail early if it finds no Shuffles or ColdCCalls https://bugs.webkit.org/show_bug.cgi?id=170305 Reviewed by Saam Barati. This reduces and sometimes completely eliminates the need to run lowerAfterRegAlloc(). This lowers the Shuffle for the arguments of a CCall before register allocation unless the CCall arguments require a real shuffle (like if the CCall arguments were argument registers). This lowers a ColdCCall like a CCall for optLevel<2. Finally, lowerAfterRegAlloc() now checks if there are any Shuffles or CCalls before it does anything else. For wasm at -O1, this means that the phase doesn't run at all. This is a ~3% wasm -O1 compile time progression. To make this easy, I changed optLevel into a property of Procedure and Code rather than an argument we thread through everything. I like how Procedure and Code are dumping ground classes. This does not bother me. Note that I cloned optLevel into Procedure and Code so that it's cheap to query inside Air phases. * b3/B3Compile.cpp: (JSC::B3::compile): * b3/B3Compile.h: * b3/B3Generate.cpp: (JSC::B3::prepareForGeneration): (JSC::B3::generateToAir): * b3/B3Generate.h: * b3/B3Procedure.cpp: (JSC::B3::Procedure::setOptLevel): * b3/B3Procedure.h: (JSC::B3::Procedure::optLevel): * b3/air/AirCode.h: (JSC::B3::Air::Code::isPinned): (JSC::B3::Air::Code::setOptLevel): (JSC::B3::Air::Code::optLevel): * b3/air/AirEmitShuffle.cpp: (JSC::B3::Air::ShufflePair::bank): (JSC::B3::Air::ShufflePair::opcode): (JSC::B3::Air::ShufflePair::inst): (JSC::B3::Air::emitShuffle): * b3/air/AirEmitShuffle.h: (JSC::B3::Air::moveFor): * b3/air/AirGenerate.cpp: (JSC::B3::Air::prepareForGeneration): * b3/air/AirGenerate.h: * b3/air/AirLowerAfterRegAlloc.cpp: (JSC::B3::Air::lowerAfterRegAlloc): * b3/air/AirLowerMacros.cpp: (JSC::B3::Air::lowerMacros): * b3/testb3.cpp: (JSC::B3::compileProc): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::parseAndCompile): 2017-04-04 Filip Pizlo Don't need to Air::reportUsedRegisters for wasm at -O1 https://bugs.webkit.org/show_bug.cgi?id=170459 Reviewed by Saam Barati. I did some refactorings to Liveness<> to try to understand its performance. Based on this I concluded that the bigger immediate issue is just removing unnecessary phases from -O1. This removes Air::reportUsedRegisters() from -O1 if the user has indicated that he is not interested in StackmapGenerationParams::usedRegisters(). The logic here is a bit weird because of how Air does spill code generation. The register allocator's spiller will emit spill code using identifiable spill slots, which allows subsequent phases to register-allocate the spill slots. We do this by a forward flow CSE phase called fixObviousSpills (which is a terrible name since there is no longer anything obvious about some of the spills that this phase can fix!). As is most natural for CSEs over 3AC, it rewires the uses of redundant computations rather than removing the redundant computations. This means that if a spill got "fixed", there may be either or both of the following: - Dead loads from the stack. - Dead stores to the stack. We know that a load from the stack is dead if the register is dead at the point of the load. We know that a store to the stack is dead if the spill slot is dead at the point of the store. Unfortunately, liveness analysis - over either registers or spill slots - is expensive. Fortunately, allocateStack() already does liveness analysis over spill slots. So, we baked elimination of stores to the stack into that phase. That aspect of clean-up after the spill CSE comes for free. Also fortunately for the FTL, we have to do reportUsedRegisters() anyway. This is a phase that enables StackmapGenerationParams::usedRegisters() to work, which then enables the FTL's patchpoints to do crazy slow-path live range splitting. So, Air's strategy for the load fix-up after spill CSE is to do it as part of reportUsedRegisters(). This patch introduces the Procedure::setNeedsUsedRegisters() API. But if you set needsUsedRegisters to false then we will still run reportUsedRegisters() at -O2 as an optimization - it removes dead loads from the stack that are left behind from fixObviousSpills(). This is a ~6% compile time progression at -O1. * b3/B3Procedure.h: (JSC::B3::Procedure::setNeedsUsedRegisters): (JSC::B3::Procedure::needsUsedRegisters): * b3/B3StackmapGenerationParams.h: * b3/B3VariableLiveness.cpp: (JSC::B3::VariableLiveness::VariableLiveness): * b3/air/AirCode.cpp: (JSC::B3::Air::Code::needsUsedRegisters): * b3/air/AirCode.h: * b3/air/AirGenerate.cpp: (JSC::B3::Air::prepareForGeneration): * b3/air/AirLiveness.h: (JSC::B3::Air::Liveness::Liveness): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::parseAndCompile): 2017-04-03 Filip Pizlo Air liveness should build constraints and solve them rather than repeatedly parsing IR https://bugs.webkit.org/show_bug.cgi?id=170421 Reviewed by Saam Barati. Inst::forEach<> is expensive. The LivenessAdapter uses forEach with a particularly gnarly lambda that has many extra checks. Therefore, a lot of the time spent in liveness analysis is just recomputing forEach<> and that lambda to get uses and defs. This introduces LivenessConstraints<>, which is a liveness constraint system based on Adapter. It basically caches the results of doing forEach. It'll give you the uses and defs at each instruction boundary. This is a ~5% compile time progression at optLevel=1. It's also a ~3% compile time progression at optLevel=2. * JavaScriptCore.xcodeproj/project.pbxproj: * b3/air/AirLivenessAdapter.h: (JSC::B3::Air::LivenessAdapter::LivenessAdapter): (JSC::B3::Air::LivenessAdapter::forEachUse): (JSC::B3::Air::LivenessAdapter::forEachDef): * b3/air/AirLivenessConstraints.h: Added. (JSC::B3::Air::LivenessConstraints::Actions::Actions): (JSC::B3::Air::LivenessConstraints::LivenessConstraints): (JSC::B3::Air::LivenessConstraints::at): 2017-04-03 Mark Lam Fix incorrect capacity delta calculation reported in SparseArrayValueMap::add(). https://bugs.webkit.org/show_bug.cgi?id=170412 Reviewed by Filip Pizlo. Here's an example of code that will trigger underflow in the "deprecatedExtraMemory" reported by SparseArrayValueMap::add() that is added to Heap::m_deprecatedExtraMemorySize: arr = new Array; Object.defineProperty(arr, 18, ({writable: true, configurable: true})); for (var i = 0; i < 3; ++i) { Array.prototype.push.apply(arr, ["", () => {}, {}]); Array.prototype.sort.apply(arr, [() => {}, []]); } However, Heap::m_deprecatedExtraMemorySize is only 1 of 3 values that are added up to form the result of Heap::extraMemorySize(). Heap::m_extraMemorySize and Heap::m_arrayBuffers.size() are the other 2. While Heap::m_arrayBuffers.size() is bounded by actual allocated memory, both Heap::m_deprecatedExtraMemorySize and Heap::m_extraMemorySize are added to without any bounds checks, and they are only reset to 0 at the start of a full GC. As a result, if we have a long sequence of eden GCs with a lot of additions to Heap::m_extraMemorySize and/or Heap::m_deprecatedExtraMemorySize, then these values could theoretically overflow. Coupling this with the underflow from SparseArrayValueMap::add(), the result for Heap::extraMemorySize() can easily overflow. Note: Heap::extraMemorySize() is used to compute the value currentHeapSize. If multiple conditions line up just right, the above overflows can result in this debug assertion failure during an eden GC: ASSERT(currentHeapSize >= m_sizeAfterLastCollect); Otherwise, the effects of the overflows will only result in the computed currentHeapSize not being representative of actual memory usage, and therefore, a full GC may be triggered earlier or later than is ideal. This patch ensures that SparseArrayValueMap::add() cannot underflow Heap::m_deprecatedExtraMemorySize. It also adds overflows checks in the calculations of Heap::m_deprecatedExtraMemorySize, Heap::m_extraMemorySize, and Heap::extraMemorySize() so that their values are saturated appropriately to ensure that GC collections are triggered based on representative memory usage. * heap/Heap.cpp: (JSC::Heap::deprecatedReportExtraMemorySlowCase): (JSC::Heap::extraMemorySize): (JSC::Heap::updateAllocationLimits): (JSC::Heap::reportExtraMemoryVisited): * runtime/SparseArrayValueMap.cpp: (JSC::SparseArrayValueMap::add): 2017-04-03 Filip Pizlo Move the Liveness<> adapters from AirLiveness.h to AirLivenessAdapter.h. Rubber stamped by Keith Miller. This will make it easier to write other code that uses those adapters. * JavaScriptCore.xcodeproj/project.pbxproj: * b3/air/AirLiveness.h: (JSC::B3::Air::LivenessAdapter::LivenessAdapter): Deleted. (JSC::B3::Air::LivenessAdapter::blockSize): Deleted. (JSC::B3::Air::LivenessAdapter::forEachUse): Deleted. (JSC::B3::Air::LivenessAdapter::forEachDef): Deleted. (JSC::B3::Air::TmpLivenessAdapter::TmpLivenessAdapter): Deleted. (JSC::B3::Air::TmpLivenessAdapter::numIndices): Deleted. (JSC::B3::Air::TmpLivenessAdapter::acceptsBank): Deleted. (JSC::B3::Air::TmpLivenessAdapter::acceptsRole): Deleted. (JSC::B3::Air::TmpLivenessAdapter::valueToIndex): Deleted. (JSC::B3::Air::TmpLivenessAdapter::indexToValue): Deleted. (JSC::B3::Air::StackSlotLivenessAdapter::StackSlotLivenessAdapter): Deleted. (JSC::B3::Air::StackSlotLivenessAdapter::numIndices): Deleted. (JSC::B3::Air::StackSlotLivenessAdapter::acceptsBank): Deleted. (JSC::B3::Air::StackSlotLivenessAdapter::acceptsRole): Deleted. (JSC::B3::Air::StackSlotLivenessAdapter::valueToIndex): Deleted. (JSC::B3::Air::StackSlotLivenessAdapter::indexToValue): Deleted. * b3/air/AirLivenessAdapter.h: Added. (JSC::B3::Air::LivenessAdapter::LivenessAdapter): (JSC::B3::Air::LivenessAdapter::blockSize): (JSC::B3::Air::LivenessAdapter::forEachUse): (JSC::B3::Air::LivenessAdapter::forEachDef): (JSC::B3::Air::TmpLivenessAdapter::TmpLivenessAdapter): (JSC::B3::Air::TmpLivenessAdapter::numIndices): (JSC::B3::Air::TmpLivenessAdapter::acceptsBank): (JSC::B3::Air::TmpLivenessAdapter::acceptsRole): (JSC::B3::Air::TmpLivenessAdapter::valueToIndex): (JSC::B3::Air::TmpLivenessAdapter::indexToValue): (JSC::B3::Air::StackSlotLivenessAdapter::StackSlotLivenessAdapter): (JSC::B3::Air::StackSlotLivenessAdapter::numIndices): (JSC::B3::Air::StackSlotLivenessAdapter::acceptsBank): (JSC::B3::Air::StackSlotLivenessAdapter::acceptsRole): (JSC::B3::Air::StackSlotLivenessAdapter::valueToIndex): (JSC::B3::Air::StackSlotLivenessAdapter::indexToValue): 2017-04-03 Filip Pizlo WTF::Liveness should have an API that focuses on actions at instruction boundaries https://bugs.webkit.org/show_bug.cgi?id=170407 Reviewed by Keith Miller. Adopt changes to the WTF::Liveness<> API. Instead of having separate functions for the early/late versions of uses and defs, we now have just a use/def API. Those automatically take care of eary/late issues as needed. This reduces the API surface between WTF::Liveness<> and its clients, which makes it easier to implement some other optimizations I'm thinking about. * b3/B3VariableLiveness.h: (JSC::B3::VariableLivenessAdapter::forEachUse): (JSC::B3::VariableLivenessAdapter::forEachDef): (JSC::B3::VariableLivenessAdapter::forEachEarlyUse): Deleted. (JSC::B3::VariableLivenessAdapter::forEachLateUse): Deleted. (JSC::B3::VariableLivenessAdapter::forEachEarlyDef): Deleted. (JSC::B3::VariableLivenessAdapter::forEachLateDef): Deleted. * b3/air/AirLiveness.h: (JSC::B3::Air::LivenessAdapter::blockSize): (JSC::B3::Air::LivenessAdapter::forEachUse): (JSC::B3::Air::LivenessAdapter::forEachDef): (JSC::B3::Air::LivenessAdapter::forEachEarlyUse): Deleted. (JSC::B3::Air::LivenessAdapter::forEachLateUse): Deleted. (JSC::B3::Air::LivenessAdapter::forEachEarlyDef): Deleted. (JSC::B3::Air::LivenessAdapter::forEachLateDef): Deleted. 2017-04-03 Filip Pizlo Inst::forEachArg could compile to more compact code https://bugs.webkit.org/show_bug.cgi?id=170406 Reviewed by Sam Weinig. Prior to this change, Inst::forEachArg compiled to a ginormous ALWAYS_INLINE switch statement. It had one case for each opcode, and then each of those cases would have a switch statement over the number of operands. Then the cases of that switch statement would have a sequence of calls to the passed lambda. This meant that every user of forEachArg would generate an insane amount of code. It also meant that the inlining achieved nothing, since the lambda would surely then not be inlined - and if it was, then the icache pressure due to code bloat would surely negate any benefits. This replaces that code with a loop over a compact look-up table. We use the opcode and number of operands as keys into that look-up table. The table only takes about 20KB. It has one byte for each argument in each overload of each opcode. I can't measure any reproducible change in performance, but the JavaScriptCore framework binary shrinks by 2.7 MB. This is a 15% reduction in JavaScriptCore binary size. * JavaScriptCore.xcodeproj/project.pbxproj: * b3/B3Width.h: * b3/air/AirCustom.h: (JSC::B3::Air::PatchCustom::forEachArg): * b3/air/AirFormTable.h: Added. (JSC::B3::Air::decodeFormRole): (JSC::B3::Air::decodeFormBank): (JSC::B3::Air::decodeFormWidth): * b3/air/AirInst.h: * b3/air/opcode_generator.rb: 2017-04-03 Keith Miller WebAssembly: remove lastAllocatedMode from Memory https://bugs.webkit.org/show_bug.cgi?id=170405 Reviewed by Mark Lam. It's not used anymore so there isn't any point in keeping it around. * wasm/WasmMemory.cpp: (JSC::Wasm::Memory::createImpl): (JSC::Wasm::Memory::lastAllocatedMode): Deleted. * wasm/WasmMemory.h: 2017-04-03 Zan Dobersek [jsc] Add patchableJumpSize() for MIPS https://bugs.webkit.org/show_bug.cgi?id=169716 Reviewed by Yusuke Suzuki. * assembler/MIPSAssembler.h: (JSC::MIPSAssembler::patchableJumpSize): Added. * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::patchableJumpSize): Added. 2017-04-03 Guillaume Emont [jsc] implement MIPSAssembler::relinkJumpToNop() https://bugs.webkit.org/show_bug.cgi?id=169720 Reviewed by Yusuke Suzuki. * assembler/MIPSAssembler.h: (JSC::MIPSAssembler::relinkJumpToNop): Added. 2017-04-02 Carlos Garcia Campos Share implementation of JSRunLoopTimer::timerDidFire https://bugs.webkit.org/show_bug.cgi?id=170392 Reviewed by Michael Catanzaro. The code is cross-platform but it's duplicated in CF and GLib implementations, it could be shared instead. * runtime/JSRunLoopTimer.cpp: (JSC::JSRunLoopTimer::timerDidFire): Move common implementation here. (JSC::JSRunLoopTimer::setRunLoop): Use timerDidFireCallback. (JSC::JSRunLoopTimer::timerDidFireCallback): Call JSRunLoopTimer::timerDidFire(). * runtime/JSRunLoopTimer.h: 2017-04-01 Oleksandr Skachkov Object with numerical keys with gaps gets filled by NaN values https://bugs.webkit.org/show_bug.cgi?id=164412 Reviewed by Mark Lam. This patch fixes issue when object have two properties with name as number. The issue appears when during invoking convertDoubleToArrayStorage, array is filled by pNaN and method converting it to real NaN. This happeneds because a pNaN in a Double array is a hole, and Double arrays cannot have NaN values. To fix issue we need to check value and clear it if it pNaN. * runtime/JSObject.cpp: (JSC::JSObject::convertDoubleToArrayStorage): 2017-03-31 Saam Barati WebAssembly: Make our calls out to JS PIC friendly https://bugs.webkit.org/show_bug.cgi?id=170261 Reviewed by Keith Miller. This patch removes a direct call from the module to the Wasm to JS stub. Instead, we do an indirect call to the stub by loading the stub's executable address off of the CodeBlock. This is to make the code we emit for comply with requirements needed for PIC. Adding this indirection is not ideal. Although this patch is neutral on WasmBench, we really want to get back to a world where we have an IC call infrastructure. This patch is obviously a regression on some types of programs. I've filed this bug to make sure we implement a PIC compliant Wasm to JS call IC: https://bugs.webkit.org/show_bug.cgi?id=170375 * wasm/WasmB3IRGenerator.cpp: * wasm/WasmFormat.h: * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::complete): * wasm/js/JSWebAssemblyCodeBlock.cpp: (JSC::JSWebAssemblyCodeBlock::initialize): * wasm/js/JSWebAssemblyCodeBlock.h: (JSC::JSWebAssemblyCodeBlock::create): (JSC::JSWebAssemblyCodeBlock::offsetOfImportWasmToJSStub): (JSC::JSWebAssemblyCodeBlock::offsetOfCallees): (JSC::JSWebAssemblyCodeBlock::allocationSize): (JSC::JSWebAssemblyCodeBlock::importWasmToJSStub): * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::addUnitializedCodeBlock): * wasm/js/JSWebAssemblyInstance.h: (JSC::JSWebAssemblyInstance::offsetOfCodeBlock): 2017-03-31 Keith Miller WebAssembly: webAssemblyB3OptimizationLevel should use defaultB3OptLevel by default https://bugs.webkit.org/show_bug.cgi?id=170378 Reviewed by Saam Barati. * runtime/Options.h: * wasm/WasmB3IRGenerator.h: 2017-03-31 Keith Miller WebAssembly: Add compilation level option https://bugs.webkit.org/show_bug.cgi?id=170374 Reviewed by Mark Lam. This patch adds an option, webAssemblyB3OptimizationLevel, which changes the optimization mode wasm passes to B3. * runtime/Options.h: * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::compileFunctions): 2017-03-31 Saam Barati WebAssembly: Strip WasmParser and WasmFunctionParser from knowing about VM https://bugs.webkit.org/show_bug.cgi?id=170312 Reviewed by Mark Lam. This is another step towards PIC-ifying Wasm. This patch removes the VM field that is no longer used. * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::parseAndCompile): * wasm/WasmB3IRGenerator.h: * wasm/WasmFunctionParser.h: (JSC::Wasm::FunctionParser::FunctionParser): * wasm/WasmModuleParser.h: (JSC::Wasm::ModuleParser::ModuleParser): * wasm/WasmParser.h: (JSC::Wasm::Parser::Parser): * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::parseAndValidateModule): (JSC::Wasm::Plan::compileFunctions): * wasm/WasmValidate.cpp: (JSC::Wasm::validateFunction): * wasm/WasmValidate.h: 2017-03-31 Saam Barati WebAssembly: Ref count Signature and SignatureInformation should not care about VM https://bugs.webkit.org/show_bug.cgi?id=170316 Reviewed by Keith Miller. This is yet again another step towards PIC-ifying Wasm. Signature should be ref counted so we can tell when no code is holding onto a Signature. This makes it easy to free unused Signatures. Also, this patch rids SignatureInfo of any VM knowledge. Now, there is just a single SignatureInfo that lives in a process. * runtime/VM.h: * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::createJSToWasmWrapper): (JSC::Wasm::parseAndCompile): * wasm/WasmB3IRGenerator.h: * wasm/WasmBinding.cpp: (JSC::Wasm::wasmToJs): * wasm/WasmCallingConvention.h: (JSC::Wasm::CallingConvention::loadArguments): * wasm/WasmFormat.h: * wasm/WasmFunctionParser.h: (JSC::Wasm::FunctionParser::FunctionParser): * wasm/WasmModuleParser.cpp: * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::parseAndValidateModule): (JSC::Wasm::Plan::compileFunctions): (JSC::Wasm::Plan::complete): * wasm/WasmSignature.cpp: (JSC::Wasm::Signature::hash): (JSC::Wasm::Signature::tryCreate): (JSC::Wasm::SignatureInformation::SignatureInformation): (JSC::Wasm::SignatureInformation::singleton): (JSC::Wasm::SignatureInformation::adopt): (JSC::Wasm::SignatureInformation::get): (JSC::Wasm::SignatureInformation::tryCleanup): (JSC::Wasm::Signature::create): Deleted. (JSC::Wasm::Signature::createInvalid): Deleted. (JSC::Wasm::Signature::destroy): Deleted. (JSC::Wasm::SignatureInformation::~SignatureInformation): Deleted. * wasm/WasmSignature.h: (JSC::Wasm::Signature::allocatedSize): (JSC::Wasm::Signature::operator==): * wasm/WasmValidate.cpp: (JSC::Wasm::validateFunction): * wasm/WasmValidate.h: * wasm/js/JSWebAssemblyModule.cpp: (JSC::JSWebAssemblyModule::destroy): * wasm/js/WebAssemblyFunction.cpp: (JSC::callWebAssemblyFunction): * wasm/js/WebAssemblyFunction.h: * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::link): (JSC::WebAssemblyModuleRecord::evaluate): * wasm/js/WebAssemblyWrapperFunction.cpp: (JSC::WebAssemblyWrapperFunction::create): * wasm/js/WebAssemblyWrapperFunction.h: 2017-03-31 Mark Lam Array.prototype.splice() should not be using JSArray::tryCreateForInitializationPrivate(). https://bugs.webkit.org/show_bug.cgi?id=170303 Reviewed by Filip Pizlo. This is because it needs to call getProperty() later to get the values for initializing the array. getProperty() can execute arbitrary code and potentially trigger the GC. This is not allowed for clients of JSArray::tryCreateForInitializationPrivate(). * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncSplice): (JSC::copySplicedArrayElements): Deleted. 2017-03-31 Oleksandr Skachkov String.prototype.replace incorrectly applies "special replacement parameters" when passed a function https://bugs.webkit.org/show_bug.cgi?id=170151 Reviewed by Saam Barati. This patch fixes issue for String.prototype.replace when passed a function with special symbols "$$". It happeneds because substituteBackreferences applies unconditionally, but according to the spec it should be applied only for text 21.1.3.16.8 https://tc39.github.io/ecma262/#sec-string.prototype.replace * runtime/StringPrototype.cpp: (JSC::replaceUsingStringSearch): 2017-03-30 Saam Barati WebAssembly: When Wasm calls to C, it should use Wasm::Context* instead of ExecState* to get VM https://bugs.webkit.org/show_bug.cgi?id=170185 Reviewed by Michael Saboff. This is one more step in the direction of PIC-ified Wasm. When we lift WasmCallee above VM, we will no longer be able to get VM from ExecState*. This patch ensures that we don't do that from within the Wasm runtime. Instead, we use the Wasm::Context* to get the VM. This patch also adds a new class, Wasm::Thunks. There is a single Wasm::Thunks that lives in the process. It is responsible for generating a thunk that Wasm relies on. The only such thunk right now is the exception throwing thunk. This patch also rids WasmFaultSignalHandler from any knowledge of VM. Previously, it relied on VM to get the exception handling thunk. The only part of the Wasm runtime that will be allowed to get VM& from ExecState will be WasmBinding. In the future, we plan to keep the calls out to JS to keep a JSCell as the callee. * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareOSREntry): * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): * interpreter/Interpreter.cpp: (JSC::UnwindFunctor::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer): (JSC::AssemblyHelpers::copyCalleeSavesToVMEntryFrameCalleeSavesBufferImpl): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer): * jit/ThunkGenerators.cpp: (JSC::throwExceptionFromWasmThunkGenerator): Deleted. * jit/ThunkGenerators.h: * runtime/InitializeThreading.cpp: (JSC::initializeThreading): * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::getAllCalleeSaveRegisterOffsets): * runtime/VM.h: (JSC::VM::topVMEntryFrameOffset): (JSC::VM::getAllCalleeSaveRegisterOffsets): Deleted. * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::emitExceptionCheck): * wasm/WasmFaultSignalHandler.cpp: (JSC::Wasm::trapHandler): * wasm/WasmMemory.cpp: (JSC::Wasm::tryGetFastMemory): * wasm/WasmThunks.cpp: Added. (JSC::Wasm::throwExceptionFromWasmThunkGenerator): (JSC::Wasm::Thunks::initialize): (JSC::Wasm::Thunks::singleton): (JSC::Wasm::Thunks::stub): (JSC::Wasm::Thunks::existingStub): * wasm/WasmThunks.h: Added. * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance): * wasm/js/JSWebAssemblyInstance.h: (JSC::JSWebAssemblyInstance::offsetOfVM): * wasm/js/JSWebAssemblyMemory.cpp: (JSC::JSWebAssemblyMemory::grow): * wasm/js/JSWebAssemblyMemory.h: * wasm/js/WebAssemblyMemoryPrototype.cpp: (JSC::webAssemblyMemoryProtoFuncGrow): 2017-03-30 Mark Lam IntlObject should not be using JSArray::initializeIndex(). https://bugs.webkit.org/show_bug.cgi?id=170302 Reviewed by Saam Barati. JSArray::initializeIndex() is only meant to be used with arrays created using JSArray::tryCreateForInitializationPrivate() under very constrained conditions. * runtime/IntlObject.cpp: (JSC::canonicalizeLocaleList): (JSC::intlObjectFuncGetCanonicalLocales): 2017-03-30 Filip Pizlo Air should support linear scan for optLevel<2 https://bugs.webkit.org/show_bug.cgi?id=170161 Reviewed by Saam Barati. This changes the default opt level of B3 to 2. It makes the other opt levels useful by adding a new register allocator. This new linear scan allocator will produce significantly worse code. But it will produce that code a lot faster than IRC or Briggs. The opt levels are: 0: no optimizations, linear scan 1: some optimizations, linear scan 2: full optimizations, graph coloring (IRC or Briggs based on CPU) What we used to call optLevel=1 is not called optLevel=2, or better yet, optLevel=B3::defaultOptLevel(). We no longer have anything like the old optLevel=0 (which did no optimizations but ran graph coloring). allocateRegistersByLinearScan() faithfully implements Massimiliano Poletto and Vivek Sarkar's famous algorithm. It uses the variant that handles clobbered registers by avoiding assigning ranges to those registers if the range overlaps a clobber. It's engineered to allocate registers very quickly and generate inefficient code without falling off a cliff. The new optLevel=1 speeds up B3 by a factor of 2, and results in a 80% throughput regression. Linear scan runs 4.7x faster than graph coloring on average. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * b3/B3BasicBlockUtils.h: (JSC::B3::blocksInPreOrder): (JSC::B3::blocksInPostOrder): * b3/B3BlockWorklist.h: * b3/B3CFG.h: (JSC::B3::CFG::newMap): * b3/B3Common.h: (JSC::B3::defaultOptLevel): * b3/B3Compile.h: * b3/B3DuplicateTails.cpp: * b3/B3EliminateCommonSubexpressions.cpp: * b3/B3FixSSA.cpp: (JSC::B3::demoteValues): (JSC::B3::fixSSA): * b3/B3FixSSA.h: * b3/B3Generate.cpp: (JSC::B3::prepareForGeneration): (JSC::B3::generateToAir): * b3/B3Generate.h: * b3/B3HeapRange.cpp: Removed. * b3/B3HeapRange.h: (JSC::B3::HeapRange::HeapRange): Deleted. (JSC::B3::HeapRange::top): Deleted. (JSC::B3::HeapRange::operator==): Deleted. (JSC::B3::HeapRange::operator!=): Deleted. (JSC::B3::HeapRange::operator|): Deleted. (JSC::B3::HeapRange::operator bool): Deleted. (JSC::B3::HeapRange::begin): Deleted. (JSC::B3::HeapRange::end): Deleted. (JSC::B3::HeapRange::overlaps): Deleted. * b3/B3LowerToAir.cpp: * b3/B3MoveConstants.cpp: * b3/B3PhiChildren.h: * b3/B3Procedure.cpp: (JSC::B3::Procedure::dump): (JSC::B3::Procedure::deleteOrphans): (JSC::B3::Procedure::setBlockOrderImpl): * b3/B3ReduceDoubleToFloat.cpp: * b3/B3ReduceStrength.cpp: * b3/B3SSACalculator.h: * b3/B3UseCounts.h: * b3/air/AirAllocateRegistersByGraphColoring.cpp: * b3/air/AirAllocateRegistersByLinearScan.cpp: Added. (JSC::B3::Air::allocateRegistersByLinearScan): * b3/air/AirAllocateRegistersByLinearScan.h: Added. * b3/air/AirAllocateStack.cpp: (JSC::B3::Air::allocateStack): * b3/air/AirArg.cpp: (WTF::printInternal): * b3/air/AirArg.h: (JSC::B3::Air::Arg::activeAt): (JSC::B3::Air::Arg::timing): (JSC::B3::Air::Arg::forEachPhase): * b3/air/AirBasicBlock.h: * b3/air/AirBlockWorklist.h: * b3/air/AirCFG.h: (JSC::B3::Air::CFG::newMap): * b3/air/AirEliminateDeadCode.cpp: (JSC::B3::Air::eliminateDeadCode): * b3/air/AirFixObviousSpills.cpp: * b3/air/AirFixPartialRegisterStalls.cpp: (JSC::B3::Air::fixPartialRegisterStalls): * b3/air/AirFixSpillsAfterTerminals.cpp: Added. (JSC::B3::Air::fixSpillsAfterTerminals): * b3/air/AirFixSpillsAfterTerminals.h: Added. * b3/air/AirGenerate.cpp: (JSC::B3::Air::prepareForGeneration): (JSC::B3::Air::generate): * b3/air/AirGenerate.h: * b3/air/AirGenerationContext.h: * b3/air/AirInsertionSet.h: * b3/air/AirInst.cpp: (JSC::B3::Air::Inst::needsPadding): * b3/air/AirLowerAfterRegAlloc.cpp: (JSC::B3::Air::lowerAfterRegAlloc): * b3/air/AirLowerEntrySwitch.cpp: (JSC::B3::Air::lowerEntrySwitch): * b3/air/AirOpcode.opcodes: * b3/air/AirPhaseInsertionSet.cpp: Added. (JSC::B3::Air::PhaseInsertionSet::execute): * b3/air/AirPhaseInsertionSet.h: Added. (JSC::B3::Air::PhaseInsertion::PhaseInsertion): (JSC::B3::Air::PhaseInsertion::phase): (JSC::B3::Air::PhaseInsertion::operator<): (JSC::B3::Air::PhaseInsertionSet::PhaseInsertionSet): (JSC::B3::Air::PhaseInsertionSet::appendInsertion): (JSC::B3::Air::PhaseInsertionSet::insertInst): (JSC::B3::Air::PhaseInsertionSet::insert): * b3/air/AirRegLiveness.h: (JSC::B3::Air::RegLiveness::LocalCalc::LocalCalc): * b3/air/AirSpillEverything.cpp: (JSC::B3::Air::spillEverything): * b3/air/AirTmp.cpp: * b3/air/AirTmp.h: (JSC::B3::Air::Tmp::tmpForIndex): * b3/air/AirTmpInlines.h: (JSC::B3::Air::Tmp::Indexed::Indexed): (JSC::B3::Air::Tmp::Indexed::index): (JSC::B3::Air::Tmp::AbsolutelyIndexed::AbsolutelyIndexed): (JSC::B3::Air::Tmp::AbsolutelyIndexed::index): (JSC::B3::Air::Tmp::indexed): (JSC::B3::Air::Tmp::absolutelyIndexed): (JSC::B3::Air::Tmp::tmpForAbsoluteIndex): * b3/testb3.cpp: (JSC::B3::compile): (JSC::B3::testMulLoadTwice): * jit/RegisterSet.h: (JSC::RegisterSet::add): (JSC::RegisterSet::remove): * runtime/Options.h: * wasm/WasmB3IRGenerator.h: 2017-03-30 Youenn Fablet Clean up RTCDataChannel https://bugs.webkit.org/show_bug.cgi?id=169732 Reviewed by Chris Dumez. * runtime/CommonIdentifiers.h: Adding RTCDataChannelEvent. 2017-03-30 Saam Barati WebAssembly: pass Wasm::Context* to vmEntryToWasm when not using fast TLS https://bugs.webkit.org/show_bug.cgi?id=170182 Reviewed by Mark Lam. This is one more step in the direction of PIC-ified Wasm. I'm removing assumptions that a wasm callee is a cell. We used to use the callee to get the WasmContext off the callee's VM. Instead, this patch makes it so that we pass in the context as a parameter to the JS entrypoint. * heap/MarkedBlock.h: (JSC::MarkedBlock::offsetOfVM): Deleted. * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::loadWasmContext): (JSC::AssemblyHelpers::storeWasmContext): (JSC::AssemblyHelpers::loadWasmContextNeedsMacroScratchRegister): (JSC::AssemblyHelpers::storeWasmContextNeedsMacroScratchRegister): * jsc.cpp: (functionTestWasmModuleFunctions): * runtime/VM.h: (JSC::VM::wasmContextOffset): Deleted. * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::materializeWasmContext): (JSC::Wasm::B3IRGenerator::restoreWasmContext): (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::createJSToWasmWrapper): * wasm/WasmContext.cpp: (JSC::Wasm::loadContext): (JSC::Wasm::storeContext): (JSC::loadWasmContext): Deleted. (JSC::storeWasmContext): Deleted. * wasm/WasmContext.h: (JSC::Wasm::useFastTLS): (JSC::Wasm::useFastTLSForContext): * wasm/WasmMemoryInformation.cpp: (JSC::Wasm::PinnedRegisterInfo::get): * wasm/WasmMemoryInformation.h: (JSC::Wasm::useFastTLS): Deleted. (JSC::Wasm::useFastTLSForWasmContext): Deleted. * wasm/js/WebAssemblyFunction.cpp: (JSC::callWebAssemblyFunction): 2017-03-30 JF Bastien WebAssembly: fix misc JS API implementation inconsistencies https://bugs.webkit.org/show_bug.cgi?id=170187 Reviewed by Keith Miller. Auto-generate lookup tables. Methods should be on prototype. Exception returns should be idiomatic. * wasm/JSWebAssembly.cpp: validate / compile / instantiate should be on the prototype (JSC::JSWebAssembly::create): (JSC::JSWebAssembly::finishCreation): (JSC::reject): Deleted. (JSC::webAssemblyCompileFunc): Deleted. (JSC::resolve): Deleted. (JSC::instantiate): Deleted. (JSC::compileAndInstantiate): Deleted. (JSC::webAssemblyInstantiateFunc): Deleted. (JSC::webAssemblyValidateFunc): Deleted. * wasm/JSWebAssembly.h: * wasm/js/WebAssemblyMemoryPrototype.cpp: move from JSWebAssembly.cpp (JSC::webAssemblyMemoryProtoFuncBuffer): (JSC::WebAssemblyMemoryPrototype::create): (JSC::WebAssemblyMemoryPrototype::finishCreation): * wasm/js/WebAssemblyMemoryPrototype.h: * wasm/js/WebAssemblyPrototype.cpp: (JSC::reject): (JSC::webAssemblyCompileFunc): (JSC::resolve): (JSC::instantiate): (JSC::compileAndInstantiate): (JSC::webAssemblyInstantiateFunc): (JSC::webAssemblyValidateFunc): (JSC::webAssemblyFunctionValidate): Deleted. (JSC::webAssemblyFunctionCompile): Deleted. * wasm/js/WebAssemblyTablePrototype.cpp: (JSC::webAssemblyTableProtoFuncGrow): (JSC::webAssemblyTableProtoFuncGet): (JSC::webAssemblyTableProtoFuncSet): (JSC::WebAssemblyTablePrototype::create): (JSC::WebAssemblyTablePrototype::finishCreation): * wasm/js/WebAssemblyTablePrototype.h: 2017-03-29 Keith Miller Unreviewed, fix the build, again. Hopefully for the last time, again! * runtime/Options.cpp: 2017-03-29 Keith Miller Unreviewed, fix the build, again. Hopefully for the last time! * runtime/Options.cpp: (JSC::parse): 2017-03-29 Keith Miller Unreviewed, windows build fix. * runtime/Options.cpp: (JSC::parse): 2017-03-29 Keith Miller WebAssembly: B3IRGenerator should pool constants https://bugs.webkit.org/show_bug.cgi?id=170266 Reviewed by Filip Pizlo. This patch adds a HashMap to B3IRGenerator that contains all the constants used in a function. B3IRGenerator then uses an InsertionSet to add all those constants to the root BB. This doesn't appear to be a compile time improvement but it could be valuable in the future. * b3/B3Opcode.h: (JSC::B3::opcodeForConstant): * b3/B3Procedure.cpp: (JSC::B3::Procedure::addConstant): * b3/B3Procedure.h: * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::B3IRGenerator::constant): (JSC::Wasm::B3IRGenerator::insertConstants): (JSC::Wasm::B3IRGenerator::addConstant): (JSC::Wasm::B3IRGenerator::dump): (JSC::Wasm::parseAndCompile): (JSC::Wasm::B3IRGenerator::emitChecksForModOrDiv): (JSC::Wasm::B3IRGenerator::zeroForType): Deleted. * wasm/generateWasmB3IRGeneratorInlinesHeader.py: (generateConstCode): 2017-03-29 Saam Barati LinkBuffer and ExecutableAllocator shouldn't have anything to do with VM https://bugs.webkit.org/show_bug.cgi?id=170210 Reviewed by Mark Lam. This is one more step in the direction of PIC-ified Wasm. LinkBuffer and ExecutableAllocator have no business knowing about VM. * assembler/LinkBuffer.cpp: (JSC::LinkBuffer::allocate): * assembler/LinkBuffer.h: (JSC::LinkBuffer::LinkBuffer): (JSC::LinkBuffer::vm): Deleted. * b3/B3Compile.cpp: (JSC::B3::compile): * b3/B3Compile.h: * b3/air/testair.cpp: * b3/testb3.cpp: (JSC::B3::compileProc): (JSC::B3::compileAndRun): (JSC::B3::testLoadAcq42): (JSC::B3::testAddArgZeroImmZDef): (JSC::B3::testAddLoadTwice): (JSC::B3::testMulLoadTwice): (JSC::B3::testMulAddArgsLeft): (JSC::B3::testMulAddArgsRight): (JSC::B3::testMulAddArgsLeft32): (JSC::B3::testMulAddArgsRight32): (JSC::B3::testMulSubArgsLeft): (JSC::B3::testMulSubArgsRight): (JSC::B3::testMulSubArgsLeft32): (JSC::B3::testMulSubArgsRight32): (JSC::B3::testMulNegArgs): (JSC::B3::testMulNegArgs32): (JSC::B3::testCompareFloatToDoubleThroughPhi): (JSC::B3::testDoubleToFloatThroughPhi): (JSC::B3::testReduceFloatToDoubleValidates): (JSC::B3::testDoubleProducerPhiToFloatConversion): (JSC::B3::testDoubleProducerPhiToFloatConversionWithDoubleConsumer): (JSC::B3::testDoubleProducerPhiWithNonFloatConst): (JSC::B3::testIToD64Arg): (JSC::B3::testIToF64Arg): (JSC::B3::testIToD32Arg): (JSC::B3::testIToF32Arg): (JSC::B3::testIToD64Mem): (JSC::B3::testIToF64Mem): (JSC::B3::testIToD32Mem): (JSC::B3::testIToF32Mem): (JSC::B3::testIToDReducedToIToF64Arg): (JSC::B3::testIToDReducedToIToF32Arg): (JSC::B3::testStoreRelAddLoadAcq32): (JSC::B3::testStoreRelAddLoadAcq8): (JSC::B3::testStoreRelAddFenceLoadAcq8): (JSC::B3::testStoreRelAddLoadAcq16): (JSC::B3::testStoreRelAddLoadAcq64): (JSC::B3::testBranch): (JSC::B3::testBranchPtr): (JSC::B3::testDiamond): (JSC::B3::testBranchNotEqual): (JSC::B3::testBranchNotEqualCommute): (JSC::B3::testBranchNotEqualNotEqual): (JSC::B3::testBranchEqual): (JSC::B3::testBranchEqualEqual): (JSC::B3::testBranchEqualCommute): (JSC::B3::testBranchEqualEqual1): (JSC::B3::testBranchLoadPtr): (JSC::B3::testBranchLoad32): (JSC::B3::testBranchLoad8S): (JSC::B3::testBranchLoad8Z): (JSC::B3::testBranchLoad16S): (JSC::B3::testBranchLoad16Z): (JSC::B3::testBranch8WithLoad8ZIndex): (JSC::B3::testComplex): (JSC::B3::testSimpleCheck): (JSC::B3::testCheckFalse): (JSC::B3::testCheckTrue): (JSC::B3::testCheckLessThan): (JSC::B3::testCheckMegaCombo): (JSC::B3::testCheckTrickyMegaCombo): (JSC::B3::testCheckTwoMegaCombos): (JSC::B3::testCheckTwoNonRedundantMegaCombos): (JSC::B3::testCheckAddImm): (JSC::B3::testCheckAddImmCommute): (JSC::B3::testCheckAddImmSomeRegister): (JSC::B3::testCheckAdd): (JSC::B3::testCheckAdd64): (JSC::B3::testCheckAddFold): (JSC::B3::testCheckAddFoldFail): (JSC::B3::testCheckAddSelfOverflow64): (JSC::B3::testCheckAddSelfOverflow32): (JSC::B3::testCheckSubImm): (JSC::B3::testCheckSubBadImm): (JSC::B3::testCheckSub): (JSC::B3::testCheckSub64): (JSC::B3::testCheckSubFold): (JSC::B3::testCheckSubFoldFail): (JSC::B3::testCheckNeg): (JSC::B3::testCheckNeg64): (JSC::B3::testCheckMul): (JSC::B3::testCheckMulMemory): (JSC::B3::testCheckMul2): (JSC::B3::testCheckMul64): (JSC::B3::testCheckMulFold): (JSC::B3::testCheckMulFoldFail): (JSC::B3::testCheckMul64SShr): (JSC::B3::testSwitch): (JSC::B3::testSwitchChillDiv): (JSC::B3::testSwitchTargettingSameBlock): (JSC::B3::testSwitchTargettingSameBlockFoldPathConstant): (JSC::B3::testBasicSelect): (JSC::B3::testSelectTest): (JSC::B3::testSelectCompareDouble): (JSC::B3::testSelectDouble): (JSC::B3::testSelectDoubleTest): (JSC::B3::testSelectDoubleCompareDouble): (JSC::B3::testSelectFloatCompareFloat): (JSC::B3::testSelectFold): (JSC::B3::testSelectInvert): (JSC::B3::testCheckSelect): (JSC::B3::testCheckSelectCheckSelect): (JSC::B3::testCheckSelectAndCSE): (JSC::B3::testTrivialInfiniteLoop): (JSC::B3::testFoldPathEqual): (JSC::B3::testLShiftSelf32): (JSC::B3::testRShiftSelf32): (JSC::B3::testURShiftSelf32): (JSC::B3::testLShiftSelf64): (JSC::B3::testRShiftSelf64): (JSC::B3::testURShiftSelf64): (JSC::B3::testPatchpointDoubleRegs): (JSC::B3::testSpillDefSmallerThanUse): (JSC::B3::testSpillUseLargerThanDef): (JSC::B3::testLateRegister): (JSC::B3::testInterpreter): (JSC::B3::testEntrySwitchSimple): (JSC::B3::testEntrySwitchNoEntrySwitch): (JSC::B3::testEntrySwitchWithCommonPaths): (JSC::B3::testEntrySwitchWithCommonPathsAndNonTrivialEntrypoint): (JSC::B3::testEntrySwitchLoop): (JSC::B3::testSomeEarlyRegister): (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled): (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled2): (JSC::B3::testPatchpointTerminalReturnValue): (JSC::B3::testMemoryFence): (JSC::B3::testStoreFence): (JSC::B3::testLoadFence): (JSC::B3::testPCOriginMapDoesntInsertNops): (JSC::B3::testPinRegisters): (JSC::B3::testX86LeaAddAddShlLeft): (JSC::B3::testX86LeaAddAddShlRight): (JSC::B3::testX86LeaAddAdd): (JSC::B3::testX86LeaAddShlRight): (JSC::B3::testX86LeaAddShlLeftScale1): (JSC::B3::testX86LeaAddShlLeftScale2): (JSC::B3::testX86LeaAddShlLeftScale4): (JSC::B3::testX86LeaAddShlLeftScale8): (JSC::B3::testAddShl32): (JSC::B3::testAddShl64): (JSC::B3::testAddShl65): (JSC::B3::testLoadBaseIndexShift2): (JSC::B3::testLoadBaseIndexShift32): (JSC::B3::testOptimizeMaterialization): (JSC::B3::testAtomicWeakCAS): (JSC::B3::testAtomicStrongCAS): (JSC::B3::testAtomicXchg): (JSC::B3::testDepend32): (JSC::B3::testDepend64): (JSC::B3::testWasmBoundsCheck): (JSC::B3::testWasmAddress): (JSC::B3::run): (JSC::B3::compile): Deleted. * bytecode/PolymorphicAccess.cpp: (JSC::PolymorphicAccess::regenerate): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): * dfg/DFGLazyJSValue.cpp: (JSC::DFG::LazyJSValue::emit): * dfg/DFGOSRExitCompiler.cpp: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): * dfg/DFGThunks.cpp: (JSC::DFG::osrExitGenerationThunkGenerator): (JSC::DFG::osrEntryThunkGenerator): * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLLazySlowPath.cpp: (JSC::FTL::LazySlowPath::generate): * ftl/FTLLink.cpp: (JSC::FTL::link): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct): (JSC::FTL::DFG::LowerDFGToB3::compileTailCall): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs): (JSC::FTL::DFG::LowerDFGToB3::compileCallEval): * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): * ftl/FTLOSRExitHandle.cpp: (JSC::FTL::OSRExitHandle::emitExitThunk): * ftl/FTLSlowPathCall.cpp: (JSC::FTL::SlowPathCallContext::makeCall): * ftl/FTLSlowPathCall.h: (JSC::FTL::callOperation): * ftl/FTLState.h: * ftl/FTLThunks.cpp: (JSC::FTL::genericGenerationThunkGenerator): (JSC::FTL::slowPathCallThunkGenerator): * ftl/FTLThunks.h: (JSC::FTL::generateIfNecessary): (JSC::FTL::Thunks::getSlowPathCallThunk): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::emitDumbVirtualCall): * jit/AssemblyHelpers.h: * jit/ExecutableAllocator.cpp: (JSC::ExecutableAllocator::initializeAllocator): (JSC::ExecutableAllocator::singleton): (JSC::ExecutableAllocator::ExecutableAllocator): (JSC::ExecutableAllocator::allocate): * jit/ExecutableAllocator.h: * jit/JIT.cpp: (JSC::JIT::compileWithoutLinking): * jit/JITCall.cpp: (JSC::JIT::compileCallEvalSlowCase): * jit/JITMathIC.h: (JSC::JITMathIC::generateOutOfLine): * jit/JITOpcodes.cpp: (JSC::JIT::privateCompileHasIndexedProperty): * jit/JITOpcodes32_64.cpp: (JSC::JIT::privateCompileHasIndexedProperty): * jit/JITOperations.cpp: * jit/JITOperations.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::stringGetByValStubGenerator): (JSC::JIT::privateCompileGetByVal): (JSC::JIT::privateCompileGetByValWithCachedId): (JSC::JIT::privateCompilePutByVal): (JSC::JIT::privateCompilePutByValWithCachedId): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::stringGetByValStubGenerator): * jit/JITStubRoutine.h: * jit/Repatch.cpp: (JSC::ftlThunkAwareRepatchCall): (JSC::linkPolymorphicCall): * jit/SpecializedThunkJIT.h: (JSC::SpecializedThunkJIT::finalize): * jit/ThunkGenerators.cpp: (JSC::throwExceptionFromCallSlowPathGenerator): (JSC::linkCallThunkGenerator): (JSC::linkPolymorphicCallThunkGenerator): (JSC::virtualThunkFor): (JSC::nativeForGenerator): (JSC::arityFixupGenerator): (JSC::unreachableGenerator): (JSC::boundThisNoArgsFunctionCallGenerator): (JSC::throwExceptionFromWasmThunkGenerator): * llint/LLIntThunks.cpp: (JSC::LLInt::generateThunkWithJumpTo): * runtime/SamplingProfiler.cpp: (JSC::SamplingProfiler::takeSample): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: * runtime/VMTraps.cpp: (JSC::VMTraps::tryInstallTrapBreakpoints): * tools/VMInspector.cpp: * wasm/WasmBinding.cpp: (JSC::Wasm::wasmToJs): (JSC::Wasm::wasmToWasm): (JSC::Wasm::exitStubGenerator): * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::complete): * yarr/YarrJIT.cpp: (JSC::Yarr::YarrGenerator::compile): (JSC::Yarr::jitCompile): 2017-03-29 Keith Miller WebAssembly: Worklist should periodically check in to see if there are higher priority jobs to do. https://bugs.webkit.org/show_bug.cgi?id=170204 Reviewed by Saam Barati. This patch makes it so that Wasm::Plan's compileFunctions method can return periodically to its caller. The main use for this is if a user asynchronously compiles a wasm module then later synchronously compiles another module. In this case we want to be able to pause compilation of other worklists. This patch also adds support for size_t Options. * runtime/Options.cpp: (JSC::parse): (JSC::Option::dump): (JSC::Option::operator==): * runtime/Options.h: * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::moveToState): (JSC::Wasm::Plan::ThreadCountHolder::~ThreadCountHolder): (JSC::Wasm::Plan::compileFunctions): * wasm/WasmPlan.h: * wasm/WasmWorklist.cpp: 2017-03-29 Mark Lam Remove obsolete references to HeapTimer in JavaScriptCore.order. https://bugs.webkit.org/show_bug.cgi?id=170252 Reviewed by Saam Barati. The HeapTimer was renamed to JSRunLoopTimer back in r214504. These HeapTimer entries are now no longer meaningful. * JavaScriptCore.order: 2017-03-29 JF Bastien WebAssembly: add shell-only Memory mode helper https://bugs.webkit.org/show_bug.cgi?id=170227 Reviewed by Mark Lam. * jsc.cpp: (GlobalObject::finishCreation): (functionWebAssemblyMemoryMode): * wasm/WasmMemory.h: * wasm/js/JSWebAssemblyInstance.h: * wasm/js/JSWebAssemblyMemory.h: 2017-03-29 Keith Miller WebAssembly: pack OpcodeOrigin to fit in a pointer https://bugs.webkit.org/show_bug.cgi?id=170244 Reviewed by Michael Saboff. This patch makes it so we don't have to have allocate the OpcodeOrigin and can just pack all the data into the pointer B3::Origin already has. * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::parseAndCompile): * wasm/WasmOpcodeOrigin.cpp: (JSC::Wasm::OpcodeOrigin::dump): * wasm/WasmOpcodeOrigin.h: (JSC::Wasm::OpcodeOrigin::OpcodeOrigin): (JSC::Wasm::OpcodeOrigin::opcode): (JSC::Wasm::OpcodeOrigin::location): 2017-03-29 JF Bastien WebAssembly: NFC s/goto/lambda/g https://bugs.webkit.org/show_bug.cgi?id=170242 Reviewed by Mark Lam. Lambdas are more in-style than the goto I just used. * wasm/WasmMemory.cpp: (JSC::Wasm::tryGetFastMemory): 2017-03-28 Saam Barati AssemblyHelpers should not have a VM field https://bugs.webkit.org/show_bug.cgi?id=170207 Reviewed by Yusuke Suzuki. APIs that need VM should take one as a parameter. When doing position independent code for Wasm, we can't tie code generation to a VM. * b3/B3Compile.cpp: (JSC::B3::compile): * b3/air/testair.cpp: * b3/testb3.cpp: (JSC::B3::testEntrySwitchSimple): (JSC::B3::testEntrySwitchNoEntrySwitch): (JSC::B3::testEntrySwitchWithCommonPaths): (JSC::B3::testEntrySwitchWithCommonPathsAndNonTrivialEntrypoint): (JSC::B3::testEntrySwitchLoop): * bytecode/AccessCase.cpp: (JSC::AccessCase::generateWithGuard): (JSC::AccessCase::generateImpl): * bytecode/DOMJITAccessCasePatchpointParams.cpp: (JSC::SlowPathCallGeneratorWithArguments::generateImpl): * bytecode/InlineAccess.cpp: (JSC::InlineAccess::dumpCacheSizesAndCrash): (JSC::InlineAccess::generateSelfPropertyAccess): (JSC::InlineAccess::generateSelfPropertyReplace): (JSC::InlineAccess::generateArrayLength): (JSC::InlineAccess::rewireStubAsJump): * bytecode/InlineAccess.h: * bytecode/PolymorphicAccess.cpp: (JSC::AccessGenerationState::emitExplicitExceptionHandler): (JSC::PolymorphicAccess::regenerate): * bytecode/PolymorphicAccess.h: (JSC::AccessGenerationState::AccessGenerationState): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::JITCompiler): (JSC::DFG::JITCompiler::compileExceptionHandlers): (JSC::DFG::JITCompiler::link): (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): (JSC::DFG::JITCompiler::exceptionCheck): * dfg/DFGJITCompiler.h: (JSC::DFG::JITCompiler::exceptionCheckWithCallFrameRollback): (JSC::DFG::JITCompiler::fastExceptionCheck): (JSC::DFG::JITCompiler::vm): * dfg/DFGOSRExitCompiler.cpp: * dfg/DFGOSRExitCompiler.h: * dfg/DFGOSRExitCompiler32_64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::adjustAndJumpToTarget): * dfg/DFGOSRExitCompilerCommon.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::emitAllocateRawObject): (JSC::DFG::SpeculativeJIT::checkArray): (JSC::DFG::SpeculativeJIT::compileCurrentBlock): (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject): (JSC::DFG::SpeculativeJIT::compileMakeRope): (JSC::DFG::SpeculativeJIT::compileGetGlobalObject): (JSC::DFG::SpeculativeJIT::compileNewFunctionCommon): (JSC::DFG::SpeculativeJIT::compileCreateActivation): (JSC::DFG::SpeculativeJIT::compileCreateDirectArguments): (JSC::DFG::SpeculativeJIT::compileSpread): (JSC::DFG::SpeculativeJIT::compileArraySlice): (JSC::DFG::SpeculativeJIT::compileNukeStructureAndSetButterfly): (JSC::DFG::SpeculativeJIT::compileNewStringObject): (JSC::DFG::SpeculativeJIT::compileNewTypedArray): (JSC::DFG::SpeculativeJIT::compileStoreBarrier): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::emitAllocateJSObjectWithKnownSize): (JSC::DFG::SpeculativeJIT::emitAllocateJSObject): (JSC::DFG::SpeculativeJIT::emitAllocateVariableSizedJSObject): (JSC::DFG::SpeculativeJIT::emitAllocateDestructibleObject): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): (JSC::DFG::SpeculativeJIT::compileLogicalNot): (JSC::DFG::SpeculativeJIT::emitBranch): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined): (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNullOrUndefined): (JSC::DFG::SpeculativeJIT::emitCall): (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot): (JSC::DFG::SpeculativeJIT::compileLogicalNot): (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch): (JSC::DFG::SpeculativeJIT::emitBranch): (JSC::DFG::SpeculativeJIT::compile): (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize): * dfg/DFGThunks.cpp: (JSC::DFG::osrEntryThunkGenerator): * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLJITFinalizer.h: * ftl/FTLLazySlowPath.cpp: (JSC::FTL::LazySlowPath::generate): * ftl/FTLLazySlowPathCall.h: (JSC::FTL::createLazyCallGenerator): * ftl/FTLLink.cpp: (JSC::FTL::link): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::lower): (JSC::FTL::DFG::LowerDFGToB3::compileCreateActivation): (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction): (JSC::FTL::DFG::LowerDFGToB3::compileCreateDirectArguments): (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray): (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope): (JSC::FTL::DFG::LowerDFGToB3::compileNotifyWrite): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs): (JSC::FTL::DFG::LowerDFGToB3::compileCallEval): (JSC::FTL::DFG::LowerDFGToB3::compileIsObjectOrNull): (JSC::FTL::DFG::LowerDFGToB3::compileIsFunction): (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject): (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation): (JSC::FTL::DFG::LowerDFGToB3::compileCheckTraps): (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorageWithSizeImpl): (JSC::FTL::DFG::LowerDFGToB3::allocateObject): (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray): (JSC::FTL::DFG::LowerDFGToB3::buildTypeOf): * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): * ftl/FTLSlowPathCall.h: (JSC::FTL::callOperation): * ftl/FTLState.h: (JSC::FTL::State::vm): * ftl/FTLThunks.cpp: (JSC::FTL::genericGenerationThunkGenerator): (JSC::FTL::slowPathCallThunkGenerator): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::jitReleaseAssertNoException): (JSC::AssemblyHelpers::callExceptionFuzz): (JSC::AssemblyHelpers::emitJumpIfException): (JSC::AssemblyHelpers::emitExceptionCheck): (JSC::AssemblyHelpers::emitNonPatchableExceptionCheck): (JSC::AssemblyHelpers::emitLoadStructure): (JSC::AssemblyHelpers::emitRandomThunk): (JSC::AssemblyHelpers::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer): (JSC::AssemblyHelpers::emitConvertValueToBoolean): (JSC::AssemblyHelpers::debugCall): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::AssemblyHelpers): (JSC::AssemblyHelpers::codeBlock): (JSC::AssemblyHelpers::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer): (JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToVMEntryFrameCalleeSavesBuffer): (JSC::AssemblyHelpers::barrierBranch): (JSC::AssemblyHelpers::barrierStoreLoadFence): (JSC::AssemblyHelpers::mutatorFence): (JSC::AssemblyHelpers::storeButterfly): (JSC::AssemblyHelpers::nukeStructureAndStoreButterfly): (JSC::AssemblyHelpers::jumpIfMutatorFenceNotNeeded): (JSC::AssemblyHelpers::emitAllocateJSObjectWithKnownSize): (JSC::AssemblyHelpers::emitAllocateJSObject): (JSC::AssemblyHelpers::emitAllocateVariableSizedCell): (JSC::AssemblyHelpers::emitAllocateVariableSizedJSObject): (JSC::AssemblyHelpers::emitAllocateDestructibleObject): (JSC::AssemblyHelpers::vm): Deleted. (JSC::AssemblyHelpers::debugCall): Deleted. * jit/CCallHelpers.cpp: (JSC::CCallHelpers::ensureShadowChickenPacket): * jit/CCallHelpers.h: (JSC::CCallHelpers::CCallHelpers): (JSC::CCallHelpers::jumpToExceptionHandler): * jit/JIT.cpp: (JSC::JIT::emitEnterOptimizationCheck): (JSC::JIT::privateCompileExceptionHandlers): * jit/JIT.h: (JSC::JIT::exceptionCheck): (JSC::JIT::exceptionCheckWithCallFrameRollback): * jit/JITMathIC.h: (JSC::JITMathIC::generateOutOfLine): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_instanceof): (JSC::JIT::emit_op_is_undefined): (JSC::JIT::emit_op_jfalse): (JSC::JIT::emit_op_jeq_null): (JSC::JIT::emit_op_jneq_null): (JSC::JIT::emit_op_jtrue): (JSC::JIT::emit_op_throw): (JSC::JIT::emit_op_catch): (JSC::JIT::emit_op_eq_null): (JSC::JIT::emit_op_neq_null): (JSC::JIT::emitSlow_op_loop_hint): (JSC::JIT::emit_op_log_shadow_chicken_prologue): (JSC::JIT::emit_op_log_shadow_chicken_tail): * jit/JITOpcodes32_64.cpp: (JSC::JIT::privateCompileCTINativeCall): (JSC::JIT::emit_op_new_object): (JSC::JIT::emit_op_jfalse): (JSC::JIT::emit_op_jtrue): (JSC::JIT::emit_op_throw): (JSC::JIT::emit_op_catch): (JSC::JIT::emit_op_create_this): (JSC::JIT::emit_op_log_shadow_chicken_prologue): (JSC::JIT::emit_op_log_shadow_chicken_tail): * jit/JITPropertyAccess.cpp: (JSC::JIT::emitWriteBarrier): * jit/JSInterfaceJIT.h: (JSC::JSInterfaceJIT::JSInterfaceJIT): (JSC::JSInterfaceJIT::vm): * jit/Repatch.cpp: (JSC::tryCacheGetByID): (JSC::tryCachePutByID): (JSC::linkPolymorphicCall): (JSC::resetGetByID): (JSC::resetPutByID): * jit/SetupVarargsFrame.cpp: (JSC::emitSetupVarargsFrameFastCase): * jit/SetupVarargsFrame.h: * jit/SpecializedThunkJIT.h: (JSC::SpecializedThunkJIT::loadArgumentWithSpecificClass): * jit/ThunkGenerators.cpp: (JSC::throwExceptionFromCallSlowPathGenerator): (JSC::linkCallThunkGenerator): (JSC::linkPolymorphicCallThunkGenerator): (JSC::virtualThunkFor): (JSC::nativeForGenerator): (JSC::randomThunkGenerator): (JSC::boundThisNoArgsFunctionCallGenerator): (JSC::throwExceptionFromWasmThunkGenerator): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::parseAndCompile): * wasm/WasmBinding.cpp: (JSC::Wasm::wasmToJs): (JSC::Wasm::wasmToWasm): 2017-03-28 Keith Miller WebAssembly: We should have Origins https://bugs.webkit.org/show_bug.cgi?id=170217 Reviewed by Mark Lam. This patch adds wasm origins for B3::Values, called OpcodeOrigin. Currently, OpcodeOrigin just tracks the original opcode and the location of that opcode. Here's a sample: BB#0: ; frequency = 1.000000 Int64 @4 = Patchpoint(generator = 0x10f487fa8, earlyClobbered = [], lateClobbered = [], usedRegisters = [], resultConstraint = SomeRegister) Int64 @5 = FramePointer() Void @8 = Store(@4, @5, offset = 24, ControlDependent|Writes:Top) Int64 @10 = Const64(0) Void @12 = Store($0(@10), @5, offset = 16, ControlDependent|Writes:Top) Int64 @13 = Patchpoint(generator = 0x10f4be7f0, earlyClobbered = [], lateClobbered = [], usedRegisters = [], resultConstraint = SomeRegister, ExitsSideways|ControlDependent|WritesPinned|ReadsPinned|Fence|Writes:Top|Reads:Top) Int64 @16 = ArgumentReg(%rdi) Int64 @18 = ArgumentReg(%rsi) Int32 @22 = Trunc(@18, Wasm: {opcode: I64Rotl, location: 5}) Int64 @23 = RotL(@16, @22, Wasm: {opcode: I64Rotl, location: 5}) Void @27 = Return(@23, Terminal, Wasm: {opcode: End, location: 6}) * JavaScriptCore.xcodeproj/project.pbxproj: * b3/B3Value.cpp: (JSC::B3::Value::deepDump): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::setParser): (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState): (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer): (JSC::Wasm::B3IRGenerator::emitLoadOp): (JSC::Wasm::B3IRGenerator::emitStoreOp): (JSC::Wasm::B3IRGenerator::addConstant): (JSC::Wasm::B3IRGenerator::addLoop): (JSC::Wasm::B3IRGenerator::unify): (JSC::Wasm::parseAndCompile): (JSC::Wasm::B3IRGenerator::emitChecksForModOrDiv): (JSC::Wasm::getMemoryBaseAndSize): Deleted. * wasm/WasmFunctionParser.h: (JSC::Wasm::FunctionParser::currentOpcode): (JSC::Wasm::FunctionParser::currentOpcodeStartingOffset): (JSC::Wasm::FunctionParser::FunctionParser): * wasm/WasmOpcodeOrigin.cpp: Added. (JSC::Wasm::OpcodeOrigin::dump): * wasm/WasmOpcodeOrigin.h: Added. (JSC::Wasm::OpcodeOrigin::OpcodeOrigin): * wasm/WasmValidate.cpp: (JSC::Wasm::Validate::setParser): * wasm/generateWasmB3IRGeneratorInlinesHeader.py: (CodeGenerator.generate): (generateB3OpCode): (generateConstCode): 2017-03-28 JF Bastien WebAssembly: option to crash if no fast memory is available https://bugs.webkit.org/show_bug.cgi?id=170219 Reviewed by Mark Lam. * runtime/Options.h: * wasm/WasmMemory.cpp: (JSC::Wasm::webAssemblyCouldntGetFastMemory): (JSC::Wasm::tryGetFastMemory): 2017-03-28 Mark Lam The Mutator should not be able to steal the conn if the Collector hasn't reached the NotRunning phase yet. https://bugs.webkit.org/show_bug.cgi?id=170213 Reviewed by Filip Pizlo. The current condition for stealing the conn isn't tight enough. Restricting the stealing to when m_currentPhase == NotRunning ensures that the Collector is really done running. No test because this issue only manifests with a race condition that is difficult to reproduce on demand. * heap/Heap.cpp: (JSC::Heap::requestCollection): 2017-03-28 Keith Miller WebAssembly: Make WebAssembly.instantiate/compile truly asynchronous https://bugs.webkit.org/show_bug.cgi?id=169187 Reviewed by Saam Barati. This patch allows WebAssembly compilations to happen asynchronously. To do so, it refactors how much of the compilation happens and adds new infrastructure for async promises. First, there is a new class, PromiseDeferredTimer that lives on the VM. PromiseDeferredTimer will manage the life-cycle of async pending promises and any dependencies that promise needs. PromiseDeferredTimer automagically releases the pending promise and dependencies once the JSPromiseDeferred is resolved or rejected. Additionally, PromiseDeferredTimer provides a mechanism to poll the run-loop whenever the async task needs to synchronize with the JS thread. Normally, that will be whenever the async task finishes. In the case of Web Assembly we also use this feature for the compile + instantiate case, where we might have more work after the first async task completes (more on that later). The next class is Wasm::Worklist, which is used to manage Wasm compilation tasks. The worklist class works similarly to the DFG/FTL Worklists. It has a pool of threads that it manages. One interesting aspect of Wasm Worklist is that it can synchronously compile a plan that is already potentially running asynchronously. This can occur if a user calls WebAssembly.instantiate() then new WebAssembly.instantiate() on the same module. In that case the Wasm Worklist will bump the priority of the running pending Plan and block the JS thread. This patch also makes some of the Wasm Plan code cleaner. Since we now defer all compilation to instantiation time, we no longer need to guess at which memory we are going to get. Also, Wasm Plans now track the work they have done with a state enum. Finally, this patch makes renamed HeapTimer to JSRunLoopTimer. It also adds changes test262AsyncTest to a more generic testing infrastructure. Now, in addition to the old functionality, you can call asyncTest() with the number of tests you expect. When the jsc CLI exits, it will guarantee that asyncTestPassed() is called that many times. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * heap/GCActivityCallback.h: * heap/IncrementalSweeper.cpp: (JSC::IncrementalSweeper::scheduleTimer): (JSC::IncrementalSweeper::IncrementalSweeper): * heap/IncrementalSweeper.h: * heap/StopIfNecessaryTimer.cpp: (JSC::StopIfNecessaryTimer::StopIfNecessaryTimer): * heap/StopIfNecessaryTimer.h: * heap/StrongInlines.h: * jsc.cpp: (GlobalObject::finishCreation): (printInternal): (functionAsyncTestStart): (functionAsyncTestPassed): (functionTestWasmModuleFunctions): (CommandLine::parseArguments): (runJSC): * runtime/JSPromiseDeferred.cpp: (JSC::JSPromiseDeferred::resolve): (JSC::JSPromiseDeferred::reject): * runtime/JSPromiseDeferred.h: (JSC::JSPromiseDeferred::promiseAsyncPending): * runtime/JSRunLoopTimer.cpp: Renamed from Source/JavaScriptCore/heap/HeapTimer.cpp. (JSC::JSRunLoopTimer::JSRunLoopTimer): (JSC::JSRunLoopTimer::setRunLoop): (JSC::JSRunLoopTimer::~JSRunLoopTimer): (JSC::JSRunLoopTimer::timerDidFire): (JSC::JSRunLoopTimer::scheduleTimer): (JSC::JSRunLoopTimer::cancelTimer): (JSC::JSRunLoopTimer::invalidate): * runtime/JSRunLoopTimer.h: Copied from Source/JavaScriptCore/heap/HeapTimer.h. * runtime/Options.h: * runtime/PromiseDeferredTimer.cpp: Added. (JSC::PromiseDeferredTimer::PromiseDeferredTimer): (JSC::PromiseDeferredTimer::doWork): (JSC::PromiseDeferredTimer::runRunLoop): (JSC::PromiseDeferredTimer::addPendingPromise): (JSC::PromiseDeferredTimer::cancelPendingPromise): (JSC::PromiseDeferredTimer::scheduleWorkSoon): (JSC::PromiseDeferredTimer::scheduleBlockedTask): * runtime/PromiseDeferredTimer.h: Renamed from Source/JavaScriptCore/heap/HeapTimer.h. (JSC::PromiseDeferredTimer::stopRunningTasks): * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::~VM): * runtime/VM.h: * wasm/JSWebAssembly.cpp: (JSC::reject): (JSC::webAssemblyCompileFunc): (JSC::resolve): (JSC::instantiate): (JSC::compileAndInstantiate): (JSC::webAssemblyInstantiateFunc): (JSC::webAssemblyValidateFunc): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer): (JSC::Wasm::B3IRGenerator::memoryKind): (JSC::Wasm::parseAndCompile): * wasm/WasmB3IRGenerator.h: * wasm/WasmFormat.h: (JSC::Wasm::ModuleInformation::internalFunctionCount): * wasm/WasmFunctionParser.h: * wasm/WasmMemory.h: * wasm/WasmMemoryInformation.cpp: (JSC::Wasm::MemoryInformation::MemoryInformation): * wasm/WasmMemoryInformation.h: (JSC::Wasm::MemoryInformation::maximum): (JSC::Wasm::MemoryInformation::hasReservedMemory): Deleted. (JSC::Wasm::MemoryInformation::takeReservedMemory): Deleted. (JSC::Wasm::MemoryInformation::mode): Deleted. * wasm/WasmModuleParser.cpp: * wasm/WasmModuleParser.h: (JSC::Wasm::ModuleParser::ModuleParser): * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::Plan): (JSC::Wasm::Plan::stateString): (JSC::Wasm::Plan::moveToState): (JSC::Wasm::Plan::fail): (JSC::Wasm::Plan::parseAndValidateModule): (JSC::Wasm::Plan::prepare): (JSC::Wasm::Plan::ThreadCountHolder::ThreadCountHolder): (JSC::Wasm::Plan::ThreadCountHolder::~ThreadCountHolder): (JSC::Wasm::Plan::compileFunctions): (JSC::Wasm::Plan::complete): (JSC::Wasm::Plan::waitForCompletion): (JSC::Wasm::Plan::cancel): (JSC::Wasm::Plan::run): Deleted. (JSC::Wasm::Plan::initializeCallees): Deleted. * wasm/WasmPlan.h: (JSC::Wasm::Plan::dontFinalize): (JSC::Wasm::Plan::exports): (JSC::Wasm::Plan::internalFunctionCount): (JSC::Wasm::Plan::takeModuleInformation): (JSC::Wasm::Plan::takeCallLinkInfos): (JSC::Wasm::Plan::takeWasmExitStubs): (JSC::Wasm::Plan::setModeAndPromise): (JSC::Wasm::Plan::mode): (JSC::Wasm::Plan::pendingPromise): (JSC::Wasm::Plan::vm): (JSC::Wasm::Plan::errorMessage): (JSC::Wasm::Plan::failed): (JSC::Wasm::Plan::hasWork): (JSC::Wasm::Plan::hasBeenPrepared): * wasm/WasmPlanInlines.h: Copied from Source/JavaScriptCore/wasm/WasmB3IRGenerator.h. (JSC::Wasm::Plan::initializeCallees): * wasm/WasmValidate.cpp: * wasm/WasmWorklist.cpp: Added. (JSC::Wasm::Worklist::priorityString): (JSC::Wasm::Worklist::QueueElement::setToNextPriority): (JSC::Wasm::Worklist::iterate): (JSC::Wasm::Worklist::enqueue): (JSC::Wasm::Worklist::completePlanSynchronously): (JSC::Wasm::Worklist::stopAllPlansForVM): (JSC::Wasm::Worklist::Worklist): (JSC::Wasm::Worklist::~Worklist): (JSC::Wasm::existingWorklistOrNull): (JSC::Wasm::ensureWorklist): * wasm/WasmWorklist.h: Added. (JSC::Wasm::Worklist::nextTicket): (JSC::Wasm::Worklist::Comparator::operator()): * wasm/js/JSWebAssemblyCallee.h: * wasm/js/JSWebAssemblyCodeBlock.cpp: (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock): (JSC::JSWebAssemblyCodeBlock::initialize): (JSC::JSWebAssemblyCodeBlock::isSafeToRun): * wasm/js/JSWebAssemblyCodeBlock.h: (JSC::JSWebAssemblyCodeBlock::create): (JSC::JSWebAssemblyCodeBlock::initialized): (JSC::JSWebAssemblyCodeBlock::plan): (JSC::JSWebAssemblyCodeBlock::runnable): (JSC::JSWebAssemblyCodeBlock::errorMessage): (JSC::JSWebAssemblyCodeBlock::callees): * wasm/js/JSWebAssemblyHelpers.h: (JSC::createSourceBufferFromValue): * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::finishCreation): (JSC::JSWebAssemblyInstance::visitChildren): (JSC::JSWebAssemblyInstance::addUnitializedCodeBlock): (JSC::JSWebAssemblyInstance::finalizeCreation): (JSC::JSWebAssemblyInstance::create): (JSC::JSWebAssemblyInstance::setMemory): Deleted. * wasm/js/JSWebAssemblyInstance.h: (JSC::JSWebAssemblyInstance::codeBlock): (JSC::JSWebAssemblyInstance::initialized): (JSC::JSWebAssemblyInstance::module): (JSC::JSWebAssemblyInstance::importFunction): (JSC::JSWebAssemblyInstance::setMemory): (JSC::JSWebAssemblyInstance::table): (JSC::JSWebAssemblyInstance::importFunctions): (JSC::JSWebAssemblyInstance::setImportFunction): Deleted. (JSC::JSWebAssemblyInstance::setTable): Deleted. * wasm/js/JSWebAssemblyModule.cpp: (JSC::JSWebAssemblyModule::createStub): (JSC::JSWebAssemblyModule::JSWebAssemblyModule): (JSC::JSWebAssemblyModule::finishCreation): (JSC::JSWebAssemblyModule::setCodeBlock): (JSC::JSWebAssemblyModule::buildCodeBlock): Deleted. (JSC::JSWebAssemblyModule::create): Deleted. (JSC::JSWebAssemblyModule::codeBlock): Deleted. * wasm/js/JSWebAssemblyModule.h: (JSC::JSWebAssemblyModule::moduleInformation): (JSC::JSWebAssemblyModule::codeBlock): (JSC::JSWebAssemblyModule::source): (JSC::JSWebAssemblyModule::takeReservedMemory): Deleted. (JSC::JSWebAssemblyModule::codeBlockFor): Deleted. * wasm/js/WebAssemblyInstanceConstructor.cpp: (JSC::constructJSWebAssemblyInstance): (JSC::WebAssemblyInstanceConstructor::createInstance): Deleted. * wasm/js/WebAssemblyModuleConstructor.cpp: (JSC::WebAssemblyModuleConstructor::createModule): * wasm/js/WebAssemblyModulePrototype.cpp: (JSC::webAssemblyModuleProtoImports): (JSC::webAssemblyModuleProtoExports): * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::finishCreation): (JSC::WebAssemblyModuleRecord::link): (JSC::WebAssemblyModuleRecord::evaluate): * wasm/js/WebAssemblyModuleRecord.h: 2017-03-28 Yusuke Suzuki WebAssembly: add fallback to use pinned register to load/store state https://bugs.webkit.org/show_bug.cgi?id=169773 Reviewed by Saam Barati. This patch adds a new pinned register to hold JSWebAssemblyInstance, which is used to represent the context of running Wasm code. While we use fast TLS to hold the context in macOS, we do not have any system reserved fast TLS slot in the other systems. This pinned register approach is used in these systems. These changes decouple VM from Wasm module to make Wasm module position independent code. While using fast TLS could be beneficial in x64 systems which number of registers is relatively small, pinned register approach could be beneficial in ARM64 which has plenty of registers. In macOS, we can switch the implementation with the runtime flag. Thus macOS port can compare the performance and decide which implementation is used after landing this patch. * heap/MarkedBlock.h: (JSC::MarkedBlock::offsetOfVM): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::loadWasmContext): (JSC::AssemblyHelpers::storeWasmContext): (JSC::AssemblyHelpers::loadWasmContextNeedsMacroScratchRegister): (JSC::AssemblyHelpers::storeWasmContextNeedsMacroScratchRegister): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::loadWasmContext): Deleted. (JSC::AssemblyHelpers::storeWasmContext): Deleted. (JSC::AssemblyHelpers::loadWasmContextNeedsMacroScratchRegister): Deleted. (JSC::AssemblyHelpers::storeWasmContextNeedsMacroScratchRegister): Deleted. * jit/Repatch.cpp: (JSC::webAssemblyOwner): (JSC::linkFor): (JSC::linkPolymorphicCall): (JSC::isWebAssemblyToJSCallee): Deleted. * jit/ThunkGenerators.cpp: (JSC::throwExceptionFromWasmThunkGenerator): * llint/LLIntData.cpp: (JSC::LLInt::Data::performAssertions): * llint/LowLevelInterpreter.asm: * runtime/JSCell.cpp: (JSC::JSCell::isAnyWasmCallee): * runtime/JSCellInlines.h: (JSC::isWebAssemblyToJSCallee): * runtime/JSType.h: * runtime/StackFrame.cpp: (JSC::StackFrame::functionName): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: (JSC::VM::wasmContextOffset): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::materializeWasmContext): (JSC::Wasm::B3IRGenerator::restoreWasmContext): (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::getMemoryBaseAndSize): (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState): (JSC::Wasm::createJSToWasmWrapper): (JSC::Wasm::loadWasmContext): Deleted. (JSC::Wasm::storeWasmContext): Deleted. (JSC::Wasm::restoreWebAssemblyGlobalState): Deleted. * wasm/WasmBinding.cpp: (JSC::Wasm::wasmToJs): * wasm/WasmContext.cpp: (JSC::loadWasmContext): (JSC::storeWasmContext): * wasm/WasmContext.h: * wasm/WasmMemoryInformation.cpp: (JSC::Wasm::getPinnedRegisters): (JSC::Wasm::PinnedRegisterInfo::get): (JSC::Wasm::PinnedRegisterInfo::PinnedRegisterInfo): * wasm/WasmMemoryInformation.h: (JSC::Wasm::PinnedRegisterInfo::toSave): (JSC::Wasm::useFastTLS): (JSC::Wasm::useFastTLSForWasmContext): * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::finishCreation): (JSC::JSWebAssemblyInstance::visitChildren): * wasm/js/JSWebAssemblyInstance.h: (JSC::JSWebAssemblyInstance::offsetOfCallee): * wasm/js/JSWebAssemblyModule.cpp: (JSC::JSWebAssemblyModule::finishCreation): (JSC::JSWebAssemblyModule::visitChildren): * wasm/js/JSWebAssemblyModule.h: (JSC::JSWebAssemblyModule::callee): * wasm/js/WebAssemblyFunction.cpp: (JSC::callWebAssemblyFunction): (JSC::WebAssemblyFunction::create): * wasm/js/WebAssemblyToJSCallee.cpp: (JSC::WebAssemblyToJSCallee::create): (JSC::WebAssemblyToJSCallee::createStructure): (JSC::WebAssemblyToJSCallee::finishCreation): (JSC::WebAssemblyToJSCallee::visitChildren): (JSC::WebAssemblyToJSCallee::destroy): Deleted. * wasm/js/WebAssemblyToJSCallee.h: 2017-03-28 Brian Burg Web Inspector: Add "Disable Caches" option that only applies to the inspected page while Web Inspector is open https://bugs.webkit.org/show_bug.cgi?id=169865 Reviewed by Joseph Pecoraro. * inspector/protocol/Network.json: Rename the command for disabling resource caching to match the WebCore::Page flag. This also removes the possibility that this could be confused for the old, buggy command that this patch rips out. 2017-03-25 Yusuke Suzuki [JSC] Move platformThreadSignal to WTF https://bugs.webkit.org/show_bug.cgi?id=170097 Reviewed by Mark Lam. It is a small clean up towards https://bugs.webkit.org/show_bug.cgi?id=170027. platformThreadSignal uses PlatformThread in JSC, but it can be implemented in WTF ThreadIdentifier. * runtime/JSLock.cpp: (JSC::JSLock::lock): * runtime/JSLock.h: (JSC::JSLock::ownerThread): (JSC::JSLock::currentThreadIsHoldingLock): * runtime/PlatformThread.h: (JSC::platformThreadSignal): Deleted. * runtime/VM.h: (JSC::VM::ownerThread): * runtime/VMTraps.cpp: (JSC::VMTraps::SignalSender::send): 2017-03-28 JF Bastien WebAssembly: implement Module imports/exports https://bugs.webkit.org/show_bug.cgi?id=166982 Reviewed by Saam Barati. As defined in: https://github.com/WebAssembly/design/commit/18cbacb90cd3584dd5c9aa3d392e4e55f66af6ab * wasm/WasmFormat.h: (JSC::Wasm::makeString): use uppercase instead, it was only used for diagnostic but is now used for the expected JS property's capitalization * wasm/js/WebAssemblyModulePrototype.cpp: (JSC::webAssemblyModuleProtoImports): (JSC::webAssemblyModuleProtoExports): 2017-03-27 JF Bastien WebAssembly: JSWebAssemblyCodeBlock.h belongs in JavaScriptCore/wasm/js not JavaScriptCore/wasm https://bugs.webkit.org/show_bug.cgi?id=170160 Reviewed by Mark Lam. * JavaScriptCore.xcodeproj/project.pbxproj: * wasm/js/JSWebAssemblyCodeBlock.h: Renamed from Source/JavaScriptCore/wasm/JSWebAssemblyCodeBlock.h. 2017-03-27 JF Bastien WebAssembly: misc memory testing https://bugs.webkit.org/show_bug.cgi?id=170137 Reviewed by Keith Miller. * wasm/js/WebAssemblyInstanceConstructor.cpp: (JSC::WebAssemblyInstanceConstructor::createInstance): improve error messages 2017-03-27 Michael Saboff Add ARM64 system instructions to disassembler https://bugs.webkit.org/show_bug.cgi?id=170084 Reviewed by Saam Barati. This changes adds support for MRS and MSR instructions, and refactors the DMB disassembly to handle all of the barrier instructions. * disassembler/ARM64/A64DOpcode.cpp: (JSC::ARM64Disassembler::A64DOpcodeMSRImmediate::format): (JSC::ARM64Disassembler::A64DOpcodeMSROrMRSRegister::format): (JSC::ARM64Disassembler::A64DOpcodeSystemSync::format): (JSC::ARM64Disassembler::A64DOpcodeDmb::format): Deleted. * disassembler/ARM64/A64DOpcode.h: (JSC::ARM64Disassembler::A64DOpcodeSystem::lBit): (JSC::ARM64Disassembler::A64DOpcodeSystem::op0): (JSC::ARM64Disassembler::A64DOpcodeSystem::op1): (JSC::ARM64Disassembler::A64DOpcodeSystem::crN): (JSC::ARM64Disassembler::A64DOpcodeSystem::crM): (JSC::ARM64Disassembler::A64DOpcodeSystem::op2): (JSC::ARM64Disassembler::A64DOpcodeMSROrMRSRegister::opName): (JSC::ARM64Disassembler::A64DOpcodeMSROrMRSRegister::systemRegister): (JSC::ARM64Disassembler::A64DOpcodeSystemSync::opName): (JSC::ARM64Disassembler::A64DOpcodeSystemSync::option): (JSC::ARM64Disassembler::A64DOpcodeDmb::opName): Deleted. (JSC::ARM64Disassembler::A64DOpcodeDmb::option): Deleted. (JSC::ARM64Disassembler::A64DOpcodeDmb::crM): Deleted. 2017-03-26 Filip Pizlo B3::fixSSA should do liveness pruning https://bugs.webkit.org/show_bug.cgi?id=170111 Reviewed by Saam Barati. This moves all of the logic of Air::Liveness<> to WTF::Liveness<> and then uses that to create B3::VariableLiveness. Then this uses VariableLiveness::LiveAtHead to prune Phi construction. This makes B3::fixSSA run twice as fast. This is a 13% progression on WasmBench compile times. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * b3/B3BasicBlock.h: (JSC::B3::BasicBlock::get): * b3/B3FixSSA.cpp: (JSC::B3::fixSSA): * b3/B3VariableLiveness.cpp: Added. (JSC::B3::VariableLiveness::VariableLiveness): (JSC::B3::VariableLiveness::~VariableLiveness): * b3/B3VariableLiveness.h: Added. (JSC::B3::VariableLivenessAdapter::VariableLivenessAdapter): (JSC::B3::VariableLivenessAdapter::numIndices): (JSC::B3::VariableLivenessAdapter::valueToIndex): (JSC::B3::VariableLivenessAdapter::indexToValue): (JSC::B3::VariableLivenessAdapter::blockSize): (JSC::B3::VariableLivenessAdapter::forEachEarlyUse): (JSC::B3::VariableLivenessAdapter::forEachLateUse): (JSC::B3::VariableLivenessAdapter::forEachEarlyDef): (JSC::B3::VariableLivenessAdapter::forEachLateDef): * b3/air/AirCFG.h: Added. (JSC::B3::Air::CFG::CFG): (JSC::B3::Air::CFG::root): (JSC::B3::Air::CFG::newMap): (JSC::B3::Air::CFG::successors): (JSC::B3::Air::CFG::predecessors): (JSC::B3::Air::CFG::index): (JSC::B3::Air::CFG::node): (JSC::B3::Air::CFG::numNodes): (JSC::B3::Air::CFG::dump): * b3/air/AirCode.cpp: (JSC::B3::Air::Code::Code): * b3/air/AirCode.h: (JSC::B3::Air::Code::cfg): * b3/air/AirLiveness.h: (JSC::B3::Air::LivenessAdapter::LivenessAdapter): (JSC::B3::Air::LivenessAdapter::blockSize): (JSC::B3::Air::LivenessAdapter::forEachEarlyUse): (JSC::B3::Air::LivenessAdapter::forEachLateUse): (JSC::B3::Air::LivenessAdapter::forEachEarlyDef): (JSC::B3::Air::LivenessAdapter::forEachLateDef): (JSC::B3::Air::TmpLivenessAdapter::TmpLivenessAdapter): (JSC::B3::Air::TmpLivenessAdapter::numIndices): (JSC::B3::Air::StackSlotLivenessAdapter::StackSlotLivenessAdapter): (JSC::B3::Air::StackSlotLivenessAdapter::numIndices): (JSC::B3::Air::StackSlotLivenessAdapter::indexToValue): (JSC::B3::Air::Liveness::Liveness): (JSC::B3::Air::Liveness::LocalCalc::LocalCalc): Deleted. (JSC::B3::Air::Liveness::LocalCalc::Iterable::Iterable): Deleted. (JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::iterator): Deleted. (JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::operator++): Deleted. (JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::operator*): Deleted. (JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::operator==): Deleted. (JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::operator!=): Deleted. (JSC::B3::Air::Liveness::LocalCalc::Iterable::begin): Deleted. (JSC::B3::Air::Liveness::LocalCalc::Iterable::end): Deleted. (JSC::B3::Air::Liveness::LocalCalc::Iterable::contains): Deleted. (JSC::B3::Air::Liveness::LocalCalc::live): Deleted. (JSC::B3::Air::Liveness::LocalCalc::isLive): Deleted. (JSC::B3::Air::Liveness::LocalCalc::execute): Deleted. (JSC::B3::Air::Liveness::rawLiveAtHead): Deleted. (JSC::B3::Air::Liveness::Iterable::Iterable): Deleted. (JSC::B3::Air::Liveness::Iterable::iterator::iterator): Deleted. (JSC::B3::Air::Liveness::Iterable::iterator::operator*): Deleted. (JSC::B3::Air::Liveness::Iterable::iterator::operator++): Deleted. (JSC::B3::Air::Liveness::Iterable::iterator::operator==): Deleted. (JSC::B3::Air::Liveness::Iterable::iterator::operator!=): Deleted. (JSC::B3::Air::Liveness::Iterable::begin): Deleted. (JSC::B3::Air::Liveness::Iterable::end): Deleted. (JSC::B3::Air::Liveness::Iterable::contains): Deleted. (JSC::B3::Air::Liveness::liveAtHead): Deleted. (JSC::B3::Air::Liveness::liveAtTail): Deleted. (JSC::B3::Air::Liveness::workset): Deleted. 2017-03-25 Filip Pizlo Air::Liveness shouldn't need HashSets https://bugs.webkit.org/show_bug.cgi?id=170102 Reviewed by Yusuke Suzuki. This converts Air::Liveness<> to no longer use HashSets or BitVectors. This turns out to be easy because it's cheap enough to do a sorted merge of the things being added to liveAtHead and the things in the predecessors' liveAtTail. This turns out to be faster - it's a 2% overall compile time progression on WasmBench. * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::lower): Add a FIXME unrelated to this patch. * b3/air/AirLiveness.h: (JSC::B3::Air::AbstractLiveness::AbstractLiveness): (JSC::B3::Air::AbstractLiveness::LocalCalc::LocalCalc): (JSC::B3::Air::AbstractLiveness::rawLiveAtHead): (JSC::B3::Air::AbstractLiveness::liveAtHead): (JSC::B3::Air::AbstractLiveness::liveAtTail): * b3/air/AirTmp.h: (JSC::B3::Air::Tmp::bank): (JSC::B3::Air::Tmp::tmpIndex): * dfg/DFGStoreBarrierClusteringPhase.cpp: 2017-03-26 Filip Pizlo Air should use RegisterSet for RegLiveness https://bugs.webkit.org/show_bug.cgi?id=170108 Reviewed by Yusuke Suzuki. The biggest change here is the introduction of the new RegLiveness class. This is a drop-in replacement for the old RegLiveness, which was a specialization of AbstractLiveness<>, but it's about 30% faster. It gets its speed boost from just using sets everywhere, which is efficient for registers since RegisterSet is just two (on x86-64) or three 32-bit (on ARM64) statically allocated words. This looks like a 1% compile time progression on WasmBench. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * b3/B3TimingScope.cpp: Records phase timing totals. (JSC::B3::TimingScope::TimingScope): (JSC::B3::TimingScope::~TimingScope): * b3/B3TimingScope.h: * b3/air/AirAllocateRegistersByGraphColoring.cpp: (JSC::B3::Air::allocateRegistersByGraphColoring): * b3/air/AirLiveness.h: Move code around and rename a bit to make it more like RegLiveness; in particular we want the `iterator` to be called `iterator` not `Iterator`, and we want it to be internal to its iterable. Also rename this template to Liveness, to match the header filename. (JSC::B3::Air::Liveness::Liveness): (JSC::B3::Air::Liveness::LocalCalc::LocalCalc): (JSC::B3::Air::Liveness::LocalCalc::Iterable::Iterable): (JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::iterator): (JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::operator++): (JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::operator*): (JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::operator==): (JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::operator!=): (JSC::B3::Air::Liveness::LocalCalc::Iterable::begin): (JSC::B3::Air::Liveness::LocalCalc::Iterable::end): (JSC::B3::Air::Liveness::Iterable::Iterable): (JSC::B3::Air::Liveness::Iterable::iterator::iterator): (JSC::B3::Air::RegLivenessAdapter::RegLivenessAdapter): Deleted. (JSC::B3::Air::RegLivenessAdapter::numIndices): Deleted. (JSC::B3::Air::RegLivenessAdapter::acceptsBank): Deleted. (JSC::B3::Air::RegLivenessAdapter::acceptsRole): Deleted. (JSC::B3::Air::RegLivenessAdapter::valueToIndex): Deleted. (JSC::B3::Air::RegLivenessAdapter::indexToValue): Deleted. (JSC::B3::Air::AbstractLiveness::AbstractLiveness): Deleted. (JSC::B3::Air::AbstractLiveness::LocalCalc::LocalCalc): Deleted. (JSC::B3::Air::AbstractLiveness::LocalCalc::Iterator::Iterator): Deleted. (JSC::B3::Air::AbstractLiveness::LocalCalc::Iterator::operator++): Deleted. (JSC::B3::Air::AbstractLiveness::LocalCalc::Iterator::operator*): Deleted. (JSC::B3::Air::AbstractLiveness::LocalCalc::Iterator::operator==): Deleted. (JSC::B3::Air::AbstractLiveness::LocalCalc::Iterator::operator!=): Deleted. (JSC::B3::Air::AbstractLiveness::LocalCalc::Iterable::Iterable): Deleted. (JSC::B3::Air::AbstractLiveness::LocalCalc::Iterable::begin): Deleted. (JSC::B3::Air::AbstractLiveness::LocalCalc::Iterable::end): Deleted. (JSC::B3::Air::AbstractLiveness::LocalCalc::Iterable::contains): Deleted. (JSC::B3::Air::AbstractLiveness::LocalCalc::live): Deleted. (JSC::B3::Air::AbstractLiveness::LocalCalc::isLive): Deleted. (JSC::B3::Air::AbstractLiveness::LocalCalc::execute): Deleted. (JSC::B3::Air::AbstractLiveness::rawLiveAtHead): Deleted. (JSC::B3::Air::AbstractLiveness::Iterable::Iterable): Deleted. (JSC::B3::Air::AbstractLiveness::Iterable::iterator::iterator): Deleted. (JSC::B3::Air::AbstractLiveness::Iterable::iterator::operator*): Deleted. (JSC::B3::Air::AbstractLiveness::Iterable::iterator::operator++): Deleted. (JSC::B3::Air::AbstractLiveness::Iterable::iterator::operator==): Deleted. (JSC::B3::Air::AbstractLiveness::Iterable::iterator::operator!=): Deleted. (JSC::B3::Air::AbstractLiveness::Iterable::begin): Deleted. (JSC::B3::Air::AbstractLiveness::Iterable::end): Deleted. (JSC::B3::Air::AbstractLiveness::Iterable::contains): Deleted. (JSC::B3::Air::AbstractLiveness::liveAtHead): Deleted. (JSC::B3::Air::AbstractLiveness::liveAtTail): Deleted. (JSC::B3::Air::AbstractLiveness::workset): Deleted. * b3/air/AirLogRegisterPressure.cpp: * b3/air/AirLowerAfterRegAlloc.cpp: * b3/air/AirRegLiveness.cpp: Added. (JSC::B3::Air::RegLiveness::RegLiveness): (JSC::B3::Air::RegLiveness::~RegLiveness): (JSC::B3::Air::RegLiveness::LocalCalc::execute): * b3/air/AirRegLiveness.h: Added. (JSC::B3::Air::RegLiveness::LocalCalc::LocalCalc): (JSC::B3::Air::RegLiveness::LocalCalc::live): (JSC::B3::Air::RegLiveness::LocalCalc::isLive): (JSC::B3::Air::RegLiveness::liveAtHead): (JSC::B3::Air::RegLiveness::liveAtTail): * b3/air/AirReportUsedRegisters.cpp: * jit/RegisterSet.h: (JSC::RegisterSet::add): (JSC::RegisterSet::remove): (JSC::RegisterSet::contains): (JSC::RegisterSet::subsumes): (JSC::RegisterSet::iterator::iterator): (JSC::RegisterSet::iterator::operator*): (JSC::RegisterSet::iterator::operator++): (JSC::RegisterSet::iterator::operator==): (JSC::RegisterSet::iterator::operator!=): (JSC::RegisterSet::begin): (JSC::RegisterSet::end): 2017-03-25 Filip Pizlo Fix wasm by returning after we do TLS. Rubber stamped by Keith Miller. * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::storeWasmContext): 2017-03-24 Mark Lam Add some instrumentation in Heap::resumeThePeriphery() to help debug an issue. https://bugs.webkit.org/show_bug.cgi?id=170086 Reviewed by Saam Barati. Adding some instrumentation in Heap::resumeThePeriphery() to dump some Heap state just before we RELEASE_ASSERT_NOT_REACHED. * heap/Heap.cpp: (JSC::Heap::resumeThePeriphery): 2017-03-24 JF Bastien WebAssembly: store state in TLS instead of on VM https://bugs.webkit.org/show_bug.cgi?id=169611 Reviewed by Filip Pizlo. Using thread-local storage instead of VM makes code more position independent. We used to store the WebAssembly top Instance (the latest one in the call stack) on VM, now we instead store it in TLS. This top Instance is used to access a bunch of state such as Memory location, size, table (for call_indirect), etc. Instead of calling it "top", which is confusing, we now just call it WasmContext. Making the code PIC means future patches will be able to postMessage and structured clone into IDB without having to recompile the code. This wasn't possible before because we hard-coded the address of VM at compilation time. That doesn't work between workers, and doesn't work across reloads (which IDB is intended to do). It'll also potentially make code faster once we start tuning what's in TLS, what's in which of the 4 free slots, and what's in pinned registers. I'm leaving this tuning for later because there's lower lying fruit for us to pick. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * assembler/AbstractMacroAssembler.h: * assembler/AllowMacroScratchRegisterUsageIf.h: Copied from assembler/AllowMacroScratchRegisterUsage.h. (JSC::AllowMacroScratchRegisterUsageIf::AllowMacroScratchRegisterUsageIf): (JSC::AllowMacroScratchRegisterUsageIf::~AllowMacroScratchRegisterUsageIf): * assembler/MacroAssembler.h: (JSC::MacroAssembler::storeToTLSPtr): we previously didn't have the code required to store to TLS, only to load * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::loadFromTLSPtrNeedsMacroScratchRegister): (JSC::MacroAssemblerARM64::storeToTLS32): (JSC::MacroAssemblerARM64::storeToTLS64): (JSC::MacroAssemblerARM64::storeToTLSPtrNeedsMacroScratchRegister): * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::loadFromTLSPtrNeedsMacroScratchRegister): (JSC::MacroAssemblerX86Common::storeToTLS32): (JSC::MacroAssemblerX86Common::storeToTLSPtrNeedsMacroScratchRegister): * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::loadFromTLS64): was loading 32-bit instead of 64-bit (JSC::MacroAssemblerX86_64::storeToTLS64): * assembler/X86Assembler.h: (JSC::X86Assembler::movl_rm): (JSC::X86Assembler::movq_rm): * b3/testb3.cpp: (JSC::B3::testFastTLSLoad): (JSC::B3::testFastTLSStore): (JSC::B3::run): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::loadWasmContext): (JSC::AssemblyHelpers::storeWasmContext): (JSC::AssemblyHelpers::loadWasmContextNeedsMacroScratchRegister): (JSC::AssemblyHelpers::storeWasmContextNeedsMacroScratchRegister): * jit/Repatch.cpp: (JSC::webAssemblyOwner): * jit/ThunkGenerators.cpp: (JSC::throwExceptionFromWasmThunkGenerator): * runtime/Options.h: * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::loadWasmContext): (JSC::Wasm::storeWasmContext): (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::getMemoryBaseAndSize): (JSC::Wasm::restoreWebAssemblyGlobalState): (JSC::Wasm::createJSToWasmWrapper): (JSC::Wasm::parseAndCompile): * wasm/WasmBinding.cpp: (JSC::Wasm::materializeImportJSCell): (JSC::Wasm::wasmToJs): (JSC::Wasm::wasmToWasm): * wasm/WasmContext.cpp: Added. (JSC::loadWasmContext): (JSC::storeWasmContext): * wasm/WasmContext.h: Added. Replaces "top" JSWebAssemblyInstance. * wasm/js/WebAssemblyFunction.cpp: (JSC::callWebAssemblyFunction): * wasm/js/WebAssemblyInstanceConstructor.h: 2017-03-24 JF Bastien WebAssembly: spec-tests/memory.wast.js fails in debug https://bugs.webkit.org/show_bug.cgi?id=169794 Reviewed by Keith Miller. The failure was due to empty memories (with maximum size 0). Those only occur in tests and in code that's trying to trip us. This patch adds memory mode "none" which represents no memory. It can work with either bounds checked or signaling code because it never contains loads and stores. The spec tests which were failing did the following: > (module (memory (data)) (func (export "memsize") (result i32) (current_memory))) > (assert_return (invoke "memsize") (i32.const 0)) > (module (memory (data "")) (func (export "memsize") (result i32) (current_memory))) > (assert_return (invoke "memsize") (i32.const 0)) > (module (memory (data "x")) (func (export "memsize") (result i32) (current_memory))) > (assert_return (invoke "memsize") (i32.const 1)) * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::memoryKind): * wasm/WasmMemory.cpp: (JSC::Wasm::tryGetFastMemory): (JSC::Wasm::releaseFastMemory): (JSC::Wasm::Memory::Memory): (JSC::Wasm::Memory::createImpl): (JSC::Wasm::Memory::create): (JSC::Wasm::Memory::grow): (JSC::Wasm::Memory::makeString): * wasm/WasmMemory.h: * wasm/WasmMemoryInformation.cpp: (JSC::Wasm::MemoryInformation::MemoryInformation): * wasm/js/JSWebAssemblyCodeBlock.cpp: (JSC::JSWebAssemblyCodeBlock::isSafeToRun): * wasm/js/JSWebAssemblyModule.cpp: (JSC::JSWebAssemblyModule::codeBlock): (JSC::JSWebAssemblyModule::finishCreation): * wasm/js/JSWebAssemblyModule.h: (JSC::JSWebAssemblyModule::codeBlock): (JSC::JSWebAssemblyModule::codeBlockFor): 2017-03-24 Mark Lam Array memcpy'ing fast paths should check if we're having a bad time if they cannot handle it. https://bugs.webkit.org/show_bug.cgi?id=170064 Reviewed by Geoffrey Garen. * runtime/ArrayPrototype.cpp: (JSC::arrayProtoPrivateFuncConcatMemcpy): * runtime/JSArray.cpp: (JSC::JSArray::fastSlice): 2017-03-23 Yusuke Suzuki [JSC] Use jsNontrivialString agressively for ToString(Int52) https://bugs.webkit.org/show_bug.cgi?id=170002 Reviewed by Sam Weinig. We use the same logic used for Int32 to use jsNontvirialString. After single character check, produced string is always longer than 1. Thus, we can use jsNontrivialString. * runtime/NumberPrototype.cpp: (JSC::int52ToString): 2017-03-23 Yusuke Suzuki [JSC] Use WeakRandom for SamplingProfiler interval fluctuation https://bugs.webkit.org/show_bug.cgi?id=170045 Reviewed by Mark Lam. It is unnecessary to use cryptographicallyRandomNumber for SamplingProfiler interval fluctuation. Use WeakRandom instead. * runtime/SamplingProfiler.cpp: (JSC::SamplingProfiler::SamplingProfiler): (JSC::SamplingProfiler::timerLoop): * runtime/SamplingProfiler.h: 2017-03-23 Mark Lam Array.prototype.splice behaves incorrectly when the VM is "having a bad time". https://bugs.webkit.org/show_bug.cgi?id=170025 Reviewed by Saam Barati. * runtime/ArrayPrototype.cpp: (JSC::copySplicedArrayElements): (JSC::arrayProtoFuncSplice): 2017-03-23 Yusuke Suzuki [JSC][DFG] Make addShouldSpeculateAnyInt more conservative to avoid regression caused by Double <-> Int52 conversions https://bugs.webkit.org/show_bug.cgi?id=169998 Reviewed by Saam Barati. Double <-> Int52 and JSValue <-> Int52 conversions are not so cheap. Thus, Int52Rep is super carefully emitted. We make addShouldSpeculateAnyInt more conservative to avoid regressions caused by the above conversions. We select ArithAdd(Int52, Int52) only when this calculation is beneficial compared to added Int52Rep conversions. This patch tighten the conditions of addShouldSpeculateAnyInt. 1. Honor DoubleConstant. When executing imaging-darkroom, we have a thing like that, 132:< 2:loc36> DoubleConstant(Double|UseAsOther, AnyIntAsDouble, Double: 4607182418800017408, 1.000000, bc#114) 1320:< 1:loc38> Int52Rep(Check:Int32:@82, Int52|PureInt, Int32, Exits, bc#114) 1321:< 1:loc39> Int52Constant(Int52|PureInt, Boolint32Nonboolint32Int52, Double: 4607182418800017408, 1.000000, bc#114) 133: ArithSub(Int52Rep:@1320, Int52Rep:@1321, Int52|MustGen, Int52, CheckOverflow, Exits, bc#114) The LHS of ArithSub says predicting Boolint32, and the rhs says AnyIntAsDouble. Thus we select ArithSub(Int52, Int52) instead of ArithSub(Double, Double). However, it soon causes OSR exits. In imaging-darkroom, LHS's Int32 prediction will be broken. While speculating Int32 in the above situation is reasonable approach since the given LHS says predicting Int32, this causes severe performance regression. Previously, we always select ArithSub(Double, Double). So accidentally, we do not encounter this misprediction issue. One thing can be found that we have DoubleConstant in the RHS. It means that we have `1.0` instead of `1` in the code. We can see the code like `lhs - 1.0` instead of `lhs - 1` in imaging-darkroom. It offers good information that lhs and the resulting value would be double. Handling the above ArithSub in double seems more appropriate rather than handling it in Int52. So, in this patch, we honor DoubleConstant. If we find DoubleConstant on one operand, we give up selecting Arith[Sub,Add](Int52, Int52). This change removes OSR exits occurr in imaging-darkroom right now. 2. Two Int52Rep(Double) conversions are not desirable. We allow AnyInt ArithAdd only when the one operand of the binary operation should be speculated AnyInt. It is a bit conservative decision. This is because Double to Int52 conversion is not so cheap. Frequent back-and-forth conversions between Double and Int52 rather hurt the performance. If the one operand of the operation is already Int52, the cost for constructing ArithAdd becomes cheap since only one Double to Int52 conversion could be required. This recovers some regression in assorted tests while keeping kraken crypto improvements. 3. Avoid frequent Int52 to JSValue conversions. Int52 to JSValue conversion is not so cheap. Thus, we would like to avoid such situations. So, in this patch, we allow Arith(Int52, Int52) with AnyIntAsDouble operand only when the node is used as number. By doing so, we avoid the case like, converting Int52, performing ArithAdd, and soon converting back to JSValue. The above 3 changes recover the regression measured in microbenchmarks/int52-back-and-forth.js and assorted benchmarks. And still it keeps kraken crypto improvements. baseline patched imaging-darkroom 201.112+-3.192 ^ 189.532+-2.883 ^ definitely 1.0611x faster stanford-crypto-pbkdf2 103.953+-2.325 100.926+-2.396 might be 1.0300x faster stanford-crypto-sha256-iterative 35.103+-1.071 ? 36.049+-1.143 ? might be 1.0270x slower * dfg/DFGGraph.h: (JSC::DFG::Graph::addShouldSpeculateAnyInt): == Rolled over to ChangeLog-2017-03-23 ==